Citrix Virtual Apps and Desktops

FAQ

August 28, 2026

Grazie al contributo di:

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
È necessario acquistare licenze Docker Desktop quando si installa l’immagine del container del server di log su Windows?

Sì. È richiesta una licenza Docker Desktop valida.
È consigliabile 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.
Qual è la capacità di acquisizione sostenuta di un singolo server di log AOT? Quali sono i limiti massimi e sicuri di eventi al secondo (EPS)?

Un singolo server di log AOT supporta una capacità di acquisizione sostenuta di 10.000 eventi al secondo (EPS). Questo valore rappresenta sia il massimo che la soglia operativa di sicurezza per l’acquisizione continua.
Quanti componenti può gestire un singolo server di log AOT? 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 tuoi utenti generano durante l’attività di picco.
Qual è la tolleranza ai picchi del server di log AOT? Quanti picchi improvvisi di log può gestire senza perdita o violazione del backlog?

Il server di log AOT può gestire picchi a breve termine fino a 2 volte la normale frequenza degli eventi senza perdere i 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.
Il server di log AOT può comprimere i log? Quale rapporto di compressione dovremmo aspettarci?

Sì. Il server di log AOT utilizza l’algoritmo di compressione LZ4 predefinito per archiviare i 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.
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 il server di log AOT e perché?

Il server di log AOT 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.
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 di latenza e costo 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 punta. Possono essere applicati costi di egress quando i log attraversano i confini regionali o del cloud.
AOT consuma una larghezza di banda di rete o risorse di sistema significative?

No. AOT è progettato per avere un impatto minimo su endpoint, VDA o qualsiasi componente e sulle prestazioni di rete.

AOT raccoglie i log continuamente e li carica sul server di log AOT quasi in tempo reale tramite HTTPS. I singoli record di log sono tipicamente di dimensioni molto ridotte (spesso solo pochi kilobyte), il che aiuta a minimizzare l’overhead di rete durante il normale funzionamento.

La larghezza di banda complessiva consumata dipende dal numero di sessioni attive, dai componenti abilitati e dall’attività dell’ambiente. Nella maggior parte delle distribuzioni, il traffico di log AOT rappresenta una percentuale molto piccola dell’utilizzo complessivo della rete.

AOT utilizza anche la compressione per ridurre i requisiti di archiviazione e ottimizzare il trasferimento dei dati al server di log.
Quali sono le specifiche hardware minime per supportare 1.000 macchine con il server di log AOT?

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 minimi (SSD o NVMe consigliati), NIC da 1 Gbps. Questa configurazione è adatta per distribuzioni piccole o a sito singolo con un volume di log moderato.
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 trovare i problemi:
```
docker logs logserver
docker inspect logserver

```
E inoltre, l’utente potrebbe collegarsi al container in esecuzione e visualizzare i log del logserver stesso:
```
docker exec –it logserver bash

```
Nella shell bash del container Docker del logserver, l’utente può verificare lo stato di salute del logserver e di OpenSearch:
```
curl http://localhost:5000/Ping
curl http://localhost:9200/_cluster/health?pretty

```
E controllare i log all’interno del container:
```
tail Config/applogs.txt
tail Config/weblogs.txt

```
Se sono necessari più log, l’utente può modificare LOG_LEVEL=0 in StartLogServer.sh/StartLogServer.bat e riavviare il logserver tramite questi file di script. I log dettagliati includeranno quindi tutti i livelli TRACE, DEBUG, INFO, WARN, ERROR.
Recuperare un disco di archiviazione del Log Server scollegato in modo improprio

Se si rimuove o si scollega il disco di archiviazione del Log Server direttamente dall’hypervisor o dal provider cloud senza prima scollegarlo dall’interfaccia utente di amministrazione di Citrix Connector Appliance, il Connector Appliance mantiene la configurazione di archiviazione e presuppone che il disco sia ancora collegato. Di conseguenza, il disco precedentemente collegato rimane configurato nel Connector Appliance, il collegamento di un nuovo disco fallisce e potrebbe essere visualizzato un errore simile a: Un disco locale è già montato sul provider.

Opzione 1 (consigliata): Se il disco originale è ancora disponibile:
1. Ricollegare il disco originale alla VM del Connector Appliance dall’hypervisor o dal provider cloud.
2. Riavviare il Connector Appliance.
3. Dopo che l’appliance si è avviata correttamente, scollegare il disco utilizzando l’interfaccia utente di amministrazione del Connector Appliance.
4. È ora possibile collegare un nuovo disco, se necessario.
Opzione 2: Se il disco originale non è più disponibile, rimuovere manualmente la configurazione di archiviazione obsoleta eseguendo la seguente richiesta API. Recuperare un token di autorizzazione ed eseguire il comando appropriato:

Linux:
```
curl -X POST "https://<connector-fqdn>/storage/$detach" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
-d '{"targetProvider":"logserver-provider","storageType":"local"}'

```
Windows:
```
curl -X POST "https://<connector-fqdn>/storage/$detach" ^
-H "Content-Type: application/json" ^
-H "Authorization: Bearer <token>" ^
-d "{\"targetProvider\":\"logserver-provider\",\"storageType\":\"local\"}"

```
Nota:

L’API potrebbe restituire un errore anche se la configurazione di archiviazione obsoleta viene rimossa correttamente. Verificare la configurazione di archiviazione prima di riprovare l’allegato del disco.

Come buona pratica, scollegare sempre il disco di archiviazione del server di log dall’interfaccia utente di amministrazione di Connector Appliance prima di rimuovere o scollegare il disco dall’hypervisor o dal provider cloud. Ciò garantisce che Connector Appliance pulisca la sua configurazione di archiviazione e prevenga riferimenti di archiviazione obsoleti.

La versione ufficiale di questo prodotto è in lingua inglese. Qualsiasi versione non in lingua inglese viene fornita unicamente per comodità dell'utente e può includere contenuti oggetto di traduzione automatica. Per ulteriori informazioni, fare riferimento al Machine Translation Disclaimer di cui alla pagina Cloud Software Group home.

È stato utile?

FAQ

August 28, 2026

Grazie al contributo di:

August 28, 2026

Grazie al contributo di:

In questo articolo

È stato utile?