Citrix Virtual Apps and Desktops

FAQ

  1. Come posso controllare le configurazioni del server di log in esecuzione, come MAX_RESERVE_DAYS?

    È possibile controllare i valori dell’ambiente del container utilizzando uno dei seguenti comandi:

    docker inspect logserver |findstr MAX_RESERVE_DAYS Oppure controllando l’ambiente del container: docker exec -it logserver env |grep MAX_RESERVE_DAYS

    Se non viene restituito nulla, significa che il server di log sta utilizzando il valore predefinito: MAX_RESERVE_DAYS=7

  2. Devo acquistare licenze Docker Desktop quando installo l’immagine container del server di log su Windows?

    Sì. È necessaria una licenza Docker Desktop valida.

  3. Devo utilizzare un nuovo server per l’installazione del server di log?

    Sì. Si consiglia di utilizzare un server dedicato per l’installazione del server di log per garantire prestazioni e isolamento.

  4. Qual è la capacità di acquisizione sostenuta di un singolo AOT Log Server? Quali sono i limiti massimi e sicuri di eventi al secondo (EPS)?

    Un singolo AOT Log Server supporta una capacità di acquisizione sostenuta di 10.000 eventi al secondo (EPS). Questo valore rappresenta sia il massimo che la soglia operativa sicura per l’acquisizione continua.

  5. Quanti componenti può gestire un singolo AOT Log Server? Esiste un limite massimo?

    Un singolo server di log può connettere fino a 128.000 componenti, ma può elaborare solo circa 10.000 log al secondo. Quindi il numero di macchine è raramente il problema: il vero fattore di dimensionamento è quanti log i suoi utenti generano durante l’attività di picco.

  6. Qual è la tolleranza ai picchi dell’AOT Log Server? Quanti picchi improvvisi di log può gestire senza perdita o superamento del backlog?

    L’AOT Log Server può gestire picchi a breve termine fino a 2 volte la normale frequenza degli eventi senza perdere log. Se il volume dei log supera questo limite (ad esempio, 5 volte), il sistema non sarà in grado di rendere persistenti gli eventi in modo affidabile e OpenSearch inizierà a eliminare i log perché non può indicizzarli abbastanza velocemente.

  7. L’AOT Log Server può comprimere i log? Quale rapporto di compressione dovremmo aspettarci?

    Sì. L’AOT Log Server utilizza l’algoritmo di compressione LZ4 predefinito per l’archiviazione dei log in OpenSearch. Il rapporto di compressione tipico è di circa 2:1, il che significa che i dati di log sono ridotti a meno della metà della loro dimensione originale, mantenendo al contempo prestazioni di lettura/scrittura veloci.

  8. Per ogni tipo di infrastruttura (on-premise a sito singolo, on-premise a più siti, cloud a regione singola, cloud a più regioni, ibrido, MSP/tenant), dove dovrebbe essere distribuito l’AOT Log Server e perché?

    L’AOT Log Server dovrebbe essere sempre distribuito nella stessa linea di vista dei VDA. Ciò garantisce una connettività stabile e aiuta a mantenere una bassa latenza tra i componenti che generano i log e il server di log che li acquisisce. Finché ogni componente (VDA, DDC, StoreFront, Gateway, ecc.) può raggiungere in modo affidabile il server di log, l’ambiente funzionerà correttamente.

  9. Abbiamo bisogno di un server di log per regione, o tutto può essere centralizzato? Che dire della latenza e dell’egress?

    È possibile centralizzare il server di log, ma i clienti dovrebbero valutare le implicazioni in termini di latenza e costi di egress per il loro ambiente. La latenza tra le regioni può influire sull’acquisizione dei log, specialmente durante i periodi di alto volume. Se la latenza di andata e ritorno è elevata, picchi o raffiche di log possono causare ritardi, accumulo di backlog o potenziale perdita durante i carichi di picco. Potrebbero essere applicati costi di egress quando i log attraversano i confini regionali o del cloud.

  10. Quali sono le specifiche hardware minime per supportare 1.000 macchine con l’AOT Log Server?

    Per ambienti con un massimo di 1.000 macchine, sono necessari: 1 nodo (server di log + OpenSearch combinati), 4 vCPU, 8 GB di RAM, 2.000 IOPS minimo (SSD o NVMe consigliati), NIC da 1 Gbps. Questa configurazione è adatta per distribuzioni piccole o a sito singolo con volume di log moderato.

  11. Come posso risolvere i problemi se c’è un problema con il server di log?

    LogServer è in esecuzione come container Docker, quindi tutti i comandi Docker possono essere utilizzati per individuare i problemi:

    docker logs logserver
    docker inspect logserver
    <!--NeedCopy-->
    

    Inoltre, l’utente può collegarsi al container in esecuzione e visualizzare i log del server di log stesso:

    docker exec –it logserver bash
    <!--NeedCopy-->
    

    Nella shell bash del container Docker del server di log, l’utente può verificare lo stato di integrità del server di log e di OpenSearch:

    curl http://localhost:5000/Ping
    curl http://localhost:9200/_cluster/health?pretty
    <!--NeedCopy-->
    

    E controllare i log all’interno del container:

    tail Config/applogs.txt
    tail Config/weblogs.txt
    <!--NeedCopy-->
    

    Se sono necessari ulteriori log, l’utente può modificare LOG_LEVEL=0 in StartLogServer.sh/StartLogServer.bat e riavviare il server di log tramite questi file di script. I log dettagliati includeranno quindi tutti i livelli TRACE, DEBUG, INFO, WARN, ERROR.

FAQ

In questo articolo