Cache host locale
Per garantire che il database del sito Citrix Virtual Apps and Desktops sia sempre disponibile, Citrix consiglia di iniziare con una distribuzione SQL Server a tolleranza di errore, seguendo le best practice di Microsoft per l’alta disponibilità. (Per le funzionalità di alta disponibilità di SQL Server supportate, vedere Database.) Tuttavia, problemi e interruzioni di rete possono impedire agli utenti di connettersi alle proprie applicazioni o desktop.
La funzionalità Cache host locale consente alle operazioni di brokering delle connessioni in un sito di continuare quando si verifica un’interruzione. Un’interruzione si verifica quando la connessione tra un Delivery Controller™ e il database del sito fallisce in un ambiente Citrix® on-premise. La Cache host locale si attiva quando il database del sito è inaccessibile per 90 secondi.
A partire da XenApp e XenDesktop 7.16, la funzionalità di leasing delle connessioni (una funzionalità di alta disponibilità precedente nelle versioni precedenti) è stata rimossa dal prodotto e non è più disponibile.
Contenuto dei dati
La Cache host locale include le seguenti informazioni, che sono un sottoinsieme delle informazioni presenti nel database principale:
- Identità di utenti e gruppi a cui sono assegnati i diritti alle risorse pubblicate dal sito.
- Identità di utenti che stanno attualmente utilizzando, o che hanno recentemente utilizzato, risorse pubblicate dal sito.
- Identità delle macchine VDA (incluse le macchine Remote PC Access) configurate nel sito.
- Identità (nomi e indirizzi IP) delle macchine client Citrix Receiver™ attivamente utilizzate per connettersi alle risorse pubblicate.
Contiene anche informazioni per le connessioni attualmente attive che sono state stabilite mentre il database principale non era disponibile:
- Risultati di qualsiasi analisi degli endpoint delle macchine client eseguita da Citrix Receiver.
- Identità delle macchine dell’infrastruttura (come i server NetScaler Gateway e StoreFront™) coinvolte nel sito.
- Date, orari e tipi di attività recenti degli utenti.
Come funziona
La seguente grafica illustra i componenti della Cache host locale e i percorsi di comunicazione durante le operazioni normali.
Durante le operazioni normali
- Il broker principale (Citrix Broker Service) su un Controller accetta le richieste di connessione da StoreFront. Il broker comunica con il database del sito per connettere gli utenti ai VDA registrati con il Controller.
- Il Citrix Config Synchronizer Service (CSS) verifica con il broker circa ogni 5 minuti se sono state apportate modifiche. Tali modifiche possono essere avviate dall’amministratore (ad esempio, la modifica di una proprietà di un gruppo di consegna) o azioni di sistema (ad esempio, assegnazioni di macchine).
-
Se si è verificata una modifica della configurazione dall’ultimo controllo, il CSS sincronizza (copia) le informazioni a un broker secondario sul Controller. (Il broker secondario è anche noto come High Availability Service.)
Tutti i dati di configurazione vengono copiati, non solo gli elementi modificati dall’ultimo controllo. Il CSS importa i dati di configurazione in un database Microsoft SQL Server Express LocalDB sul Controller. Questo database è denominato database della Cache host locale. Il CSS garantisce che le informazioni nel database della Cache host locale corrispondano alle informazioni nel database del sito. Il database della Cache host locale viene ricreato ogni volta che si verifica una sincronizzazione.
Microsoft SQL Server Express LocalDB (utilizzato dal database della Cache host locale) viene installato automaticamente quando si installa un Controller. (È possibile impedire questa installazione quando si installa un Controller dalla riga di comando.) Il database della Cache host locale non può essere condiviso tra i Controller. Non è necessario eseguire il backup del database della Cache host locale. Viene ricreato ogni volta che viene rilevata una modifica della configurazione.
- Se non sono state apportate modifiche dall’ultimo controllo, nessun dato viene copiato.
La seguente grafica illustra le modifiche nei percorsi di comunicazione se il broker principale perde il contatto con il database del sito (inizia un’interruzione).
Durante un’interruzione
Quando inizia un’interruzione:
- Il broker secondario inizia ad ascoltare ed elaborare le richieste di connessione.
- Quando inizia l’interruzione, il broker secondario non dispone dei dati di registrazione VDA correnti, ma quando un VDA comunica con esso, viene attivato un processo di registrazione. Durante tale processo, il broker secondario ottiene anche le informazioni sulla sessione corrente relative a quel VDA.
- Mentre il broker secondario gestisce le connessioni, il Brokering Principal continua a monitorare la connessione. Quando la connessione viene ripristinata, il Brokering Principal istruisce il broker secondario a smettere di ascoltare le informazioni di connessione e il Brokering Principal riprende le operazioni di brokering. La prossima volta che un VDA comunica con il Brokering Principal, viene attivato un processo di registrazione. Il broker secondario rimuove tutte le registrazioni VDA rimanenti dalla precedente interruzione. Il CSS riprende a sincronizzare le informazioni quando apprende che si sono verificate modifiche alla configurazione nella distribuzione.
Nell’improbabile eventualità che un’interruzione inizi durante una sincronizzazione, l’importazione corrente viene scartata e viene utilizzata l’ultima configurazione nota.
Il registro eventi fornisce informazioni su sincronizzazioni e interruzioni.
Non è imposto alcun limite di tempo per il funzionamento in modalità interruzione.
La transizione tra la modalità normale e la modalità interruzione non influisce sulle sessioni esistenti. Influisce solo sull’avvio di nuove sessioni.
È anche possibile attivare intenzionalmente un’interruzione. Vedere Forzare un’interruzione per i dettagli sul perché e come farlo.
Siti con più Controller
Tra gli altri suoi compiti, il CSS fornisce regolarmente al broker secondario informazioni su tutti i Controller nella zona. (Se la distribuzione non contiene più zone, questa azione interessa tutti i Controller nel sito.) Avendo tali informazioni, ogni broker secondario conosce tutti i broker secondari peer in esecuzione su altri Controller nella zona.
I broker secondari comunicano tra loro su un canale separato. Tali broker utilizzano un elenco alfabetico di nomi FQDN delle macchine su cui sono in esecuzione per determinare (eleggere) quale broker secondario gestirà le operazioni di brokering nella zona in caso di interruzione. Durante l’interruzione, tutti i VDA si registrano con il broker secondario eletto. I broker secondari non eletti nella zona rifiutano attivamente le richieste di connessione in entrata e di registrazione VDA.
Se un broker secondario eletto fallisce durante un’interruzione, un altro broker secondario viene eletto per subentrare e i VDA si registrano con il broker secondario appena eletto.
Durante un’interruzione, se un Controller viene riavviato:
- Se quel Controller non è il broker eletto, il riavvio non ha alcun impatto.
- Se quel Controller è il broker eletto, viene eletto un Controller diverso, causando la registrazione dei VDA. Dopo l’accensione del Controller riavviato, esso assume automaticamente il brokering, il che causa una nuova registrazione dei VDA. In questo scenario, le prestazioni possono essere influenzate durante le registrazioni.
Se si spegne un Controller durante le operazioni normali e poi lo si riaccende durante un’interruzione, la Cache host locale non può essere utilizzata su quel Controller se è eletto come broker.
I registri eventi forniscono informazioni sulle elezioni.
Cosa non è disponibile durante un’interruzione e altre differenze
Non è imposto alcun limite di tempo per il funzionamento in modalità interruzione. Tuttavia, Citrix consiglia di ripristinare la connettività il più rapidamente possibile.
Durante un’interruzione:
- Non è possibile utilizzare Studio.
-
Si ha accesso limitato all’SDK PowerShell.
- È necessario prima:
- Aggiungere una chiave di registro
EnableCssTestModecon un valore di 1:New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1 - Utilizzare la porta 89:
Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
- Aggiungere una chiave di registro
- Dopo aver eseguito questi comandi, è possibile accedere a:
- Tutti i cmdlet
Get-Broker*.
- Tutti i cmdlet
- È necessario prima:
- Le credenziali dell’hypervisor non possono essere ottenute dal servizio Host. Tutte le macchine sono in stato di alimentazione sconosciuto e non è possibile emettere operazioni di alimentazione. Tuttavia, le VM sull’host che sono accese possono essere utilizzate per le richieste di connessione.
- Una macchina assegnata può essere utilizzata solo se l’assegnazione è avvenuta durante le operazioni normali. Nuove assegnazioni non possono essere effettuate durante un’interruzione.
- L’iscrizione e la configurazione automatica delle macchine Remote PC Access non sono possibili. Tuttavia, le macchine che sono state iscritte e configurate durante il normale funzionamento sono utilizzabili.
- Gli utenti di applicazioni e desktop ospitati su server potrebbero utilizzare più sessioni rispetto ai limiti di sessione configurati, se le risorse sono in zone diverse.
- Gli utenti possono avviare applicazioni e desktop solo da VDA registrati nella zona contenente il broker secondario attualmente attivo/eletto. Gli avvii tra zone (da un broker secondario in una zona a un VDA in una zona diversa) non sono supportati durante un’interruzione.
- Se si verifica un’interruzione del database del sito prima che inizi un riavvio pianificato per i VDA in un gruppo di consegna, i riavvii iniziano quando l’interruzione termina. Ciò può avere risultati imprevisti. Per maggiori informazioni, vedere Riavvii pianificati ritardati a causa di un’interruzione del database.
- La preferenza di zona non può essere configurata. Se configurate, le preferenze non vengono considerate per l’avvio della sessione.
- Le restrizioni dei tag in cui i tag vengono utilizzati per designare le zone non sono supportate per gli avvii di sessione. Quando tali restrizioni dei tag sono configurate e l’opzione controllo avanzato dello stato di un archivio StoreFront è abilitata, le sessioni potrebbero occasionalmente non riuscire ad avviarsi.
Supporto per applicazioni e desktop
LHC supporta i seguenti tipi di VDA e modelli di consegna:
| Tipo di VDA | Modello di consegna | Disponibilità VDA durante gli eventi LHC |
|---|---|---|
| OS multi-sessione | Applicazioni e desktop | Sempre disponibile. |
| OS single-sessione statico (assegnato) | Desktop | Sempre disponibile. |
| OS single-sessione casuale (in pool) con gestione dell’alimentazione
|
Desktop
|
Non disponibile per impostazione predefinita. Tutti i tentativi di avvio di sessione per i VDA con gestione dell’alimentazione in gruppi di consegna in pool falliranno per impostazione predefinita.
È possibile renderli disponibili per nuove connessioni durante gli eventi LHC. Per maggiori informazioni, vedere Abilitare l’uso di Web Studio e Abilitare l’uso di PowerShell. Importante: l’abilitazione dell’accesso a macchine in pool single-sessione con gestione dell’alimentazione può causare la presenza di dati e modifiche delle sessioni utente precedenti nelle sessioni successive. |
Nota:
L’abilitazione dell’accesso ai VDA desktop con gestione dell’alimentazione in gruppi di consegna in pool non influisce sul funzionamento della proprietà
ShutdownDesktopsAfterUseconfigurata durante le operazioni normali. Quando l’accesso a questi desktop durante LHC è abilitato, i VDA non si riavviano automaticamente al termine dell’evento LHC. I VDA desktop con gestione dell’alimentazione in gruppi di consegna in pool possono conservare i dati delle sessioni precedenti fino al riavvio dei VDA. Un riavvio del VDA può verificarsi quando un utente si disconnette dal VDA durante operazioni non-LHC o quando gli amministratori riavviano il VDA.
Abilitare LHC per VDA in pool OS single-sessione con gestione dell’alimentazione tramite Web Studio
Utilizzando Web Studio, è possibile rendere tali macchine disponibili per nuove connessioni durante gli eventi LHC su base per gruppo di consegna:
- Per abilitare questa funzionalità durante la creazione del gruppo di consegna, vedere Creare gruppi di consegna.
- Per abilitare questa funzionalità per un gruppo di consegna esistente, vedere Gestire gruppi di consegna.
Nota:
Questa impostazione è disponibile in Web Studio solo per i gruppi di consegna di desktop in pool che distribuiscono VDA con gestione dell’alimentazione.
Abilitare LHC per VDA in pool con OS a sessione singola e gestione dell’alimentazione tramite PowerShell
Per abilitare LHC per i VDA in un gruppo di consegna specifico, seguire questi passaggi:
-
Abilitare questa funzionalità a livello di sito eseguendo questo comando:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true -
Abilitare LHC per un gruppo di consegna eseguendo questo comando con il nome del gruppo di consegna specificato:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
Per modificare la disponibilità predefinita di LHC per i gruppi di consegna in pool di nuova creazione con VDA con gestione dell’alimentazione, eseguire il comando seguente:
Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true
Considerazioni sulle dimensioni della RAM
Il servizio LocalDB può utilizzare circa 1,2 GB di RAM (fino a 1 GB per la cache del database, più 200 MB per l’esecuzione di SQL Server Express LocalDB). Il broker secondario può utilizzare fino a 1 GB di RAM se un’interruzione dura per un intervallo prolungato con molti accessi (ad esempio, 12 ore con 10.000 utenti). Questi requisiti di memoria si aggiungono ai normali requisiti di RAM per il Controller, quindi potrebbe essere necessario aumentare la capacità totale di RAM.
Se si utilizza un’installazione di SQL Server Express per il database del sito, il server avrà due processi sqlserver.exe.
Considerazioni sulla configurazione di core e socket della CPU
La configurazione della CPU di un Controller, in particolare il numero di core disponibili per SQL Server Express LocalDB, influisce direttamente sulle prestazioni della Local Host Cache, anche più dell’allocazione della memoria. Questo overhead della CPU si osserva solo durante il periodo di interruzione quando il database non è raggiungibile e il broker secondario è attivo.
Sebbene LocalDB possa utilizzare più core (fino a 4), è limitato a un solo socket. L’aggiunta di più socket non migliorerà le prestazioni (ad esempio, avere 4 socket con 1 core ciascuno). Invece, Citrix consiglia di utilizzare più socket con più core. Nei test Citrix, una configurazione 2x3 (2 socket, 3 core) ha fornito prestazioni migliori rispetto alle configurazioni 4x1 e 6x1.
Considerazioni sull’archiviazione
Quando gli utenti accedono alle risorse durante un’interruzione, il LocalDB cresce. Ad esempio, durante un test di accesso/disconnessione eseguito a 10 accessi al secondo, il database è cresciuto di 1 MB ogni 2-3 minuti. Quando le operazioni normali riprendono, il database locale viene ricreato e lo spazio viene restituito. Tuttavia, deve essere disponibile spazio sufficiente sull’unità in cui è installato il LocalDB per consentire la crescita del database durante un’interruzione. La Local Host Cache comporta anche più I/O durante un’interruzione: circa 3 MB di scritture al secondo, con diverse centinaia di migliaia di letture.
Considerazioni sulle prestazioni
Durante un’interruzione, un broker secondario gestisce tutte le connessioni, quindi nei siti (o zone) che bilanciano il carico tra più Controller durante le operazioni normali, il broker secondario eletto potrebbe dover gestire molte più richieste del normale durante un’interruzione. Pertanto, le richieste della CPU saranno più elevate. Ogni broker secondario nel sito (zona) deve essere in grado di gestire il carico aggiuntivo imposto dal database della Local Host Cache e da tutti i VDA interessati, perché il broker secondario eletto durante un’interruzione può cambiare.
Limiti VDI:
- In una distribuzione VDI a zona singola, è possibile gestire efficacemente fino a 10.000 VDA durante un’interruzione.
- In una distribuzione VDI multi-zona, è possibile gestire efficacemente fino a 10.000 VDA in ogni zona durante un’interruzione, per un massimo di 40.000 VDA nel sito. Ad esempio, ciascuno dei seguenti siti può essere gestito efficacemente durante un’interruzione:
- Un sito con quattro zone, ciascuna contenente 10.000 VDA.
- Un sito con sette zone, una contenente 10.000 VDA e sei contenenti 5.000 VDA ciascuna.
Durante un’interruzione, la gestione del carico all’interno del sito può essere influenzata. I valutatori di carico (e in particolare le regole di conteggio delle sessioni) possono essere superati.
Durante il tempo necessario a tutti i VDA per registrarsi con un broker secondario, tale servizio potrebbe non disporre di informazioni complete sulle sessioni correnti. Pertanto, una richiesta di connessione utente durante tale intervallo può comportare l’avvio di una nuova sessione, anche se era possibile la riconnessione a una sessione esistente. Questo intervallo (mentre il “nuovo” broker secondario acquisisce le informazioni sulla sessione da tutti i VDA durante la ri-registrazione) è inevitabile. Le sessioni connesse all’inizio di un’interruzione non sono interessate durante l’intervallo di transizione, ma le nuove sessioni e le riconnessioni di sessione potrebbero esserlo.
Questo intervallo si verifica ogni volta che i VDA devono registrarsi:
- Inizio di un’interruzione: durante la migrazione da un broker principale a un broker secondario.
- Guasto del broker secondario durante un’interruzione: durante la migrazione da un broker secondario guasto a un broker secondario appena eletto.
- Ripristino da un’interruzione: quando le operazioni normali riprendono e il broker principale riprende il controllo.
È possibile ridurre l’intervallo abbassando il valore del registro HeartbeatPeriodMs del protocollo Citrix Broker (predefinito = 600000 ms, ovvero 10 minuti). Questo valore di heartbeat è il doppio dell’intervallo utilizzato dal VDA per i ping, quindi il valore predefinito si traduce in un ping ogni 5 minuti.
Ad esempio, il comando seguente modifica l’heartbeat a cinque minuti (300000 millisecondi), il che si traduce in un ping ogni 2,5 minuti:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
Usare cautela quando si modifica il valore dell’heartbeat. L’aumento della frequenza comporta un carico maggiore sui Controller sia in modalità normale che in modalità di interruzione.
L’intervallo non può essere eliminato del tutto, indipendentemente dalla velocità con cui i VDA si registrano.
Il tempo necessario per la sincronizzazione tra i broker secondari aumenta con il numero di oggetti (come VDA, applicazioni, gruppi). Ad esempio, la sincronizzazione di 5000 VDA potrebbe richiedere 10 minuti o più per essere completata.
Differenze rispetto alle versioni di XenApp 6.x
Sebbene questa implementazione della Local Host Cache condivida il nome della funzionalità Local Host Cache nelle versioni di XenApp 6.x e precedenti, ci sono miglioramenti significativi. Questa implementazione è più robusta e immune alla corruzione. I requisiti di manutenzione sono ridotti al minimo, come l’eliminazione della necessità di comandi dsmaint periodici. Questa Local Host Cache è un’implementazione tecnicamente del tutto diversa.
Gestire la Local Host Cache
Affinché la Local Host Cache funzioni correttamente, la policy di esecuzione di PowerShell su ogni Controller deve essere impostata su RemoteSigned, Unrestricted o Bypass.
SQL Server Express LocalDB
Il software Microsoft SQL Server Express LocalDB utilizzato dalla Local Host Cache viene installato automaticamente quando si installa un Controller o si esegue l’aggiornamento di un Controller da una versione precedente alla 7.9. Solo il broker secondario comunica con questo database. Non è possibile utilizzare i cmdlet di PowerShell per modificare alcunché di questo database. Il LocalDB non può essere condiviso tra i Controller.
Il software del database SQL Server Express LocalDB viene installato indipendentemente dal fatto che la Local Host Cache sia abilitata.
Per impedirne l’installazione, installare o aggiornare il Controller utilizzando il comando XenDesktopServerSetup.exe e includere l’opzione /exclude "Local Host Cache Storage (LocalDB)". Tuttavia, tenere presente che la funzionalità Local Host Cache non funzionerà senza il database e non è possibile utilizzare un database diverso con il broker secondario.
L’installazione di questo database LocalDB non ha alcun effetto sull’installazione di SQL Server Express da utilizzare come database del sito.
Per informazioni sulla sostituzione di una versione precedente di SQL Server Express LocalDB con una versione più recente, vedere Sostituire SQL Server Express LocalDB.
Impostazioni predefinite dopo l’installazione e l’aggiornamento del prodotto
Durante una nuova installazione di Citrix Virtual Apps and Desktops (versione minima 7.16), la Local Host Cache è abilitata.
Dopo un aggiornamento (alla versione 7.16 o successiva), la Local Host Cache è abilitata se ci sono meno di 10.000 VDA nell’intera distribuzione.
Abilitare e disabilitare la Local Host Cache
- Per abilitare la Local Host Cache, immettere:
Set-BrokerSite -LocalHostCacheEnabled $true
Per determinare se la Cache host locale è abilitata, immettere Get-BrokerSite. Verificare che la proprietà LocalHostCacheEnabled sia True.
-
Per disabilitare la Cache host locale, immettere:
Set-BrokerSite -LocalHostCacheEnabled $false
Ricorda: A partire da XenApp e XenDesktop 7.16, il leasing delle connessioni (la funzionalità che ha preceduto la Cache host locale a partire dalla versione 7.6) è stato rimosso dal prodotto e non è più disponibile.
Verificare che la Cache host locale funzioni
Per verificare che la Cache host locale sia configurata e funzioni correttamente:
- Assicurarsi che le importazioni di sincronizzazione vengano completate correttamente. Controllare i registri eventi.
- Assicurarsi che il database SQL Server Express LocalDB sia stato creato su ogni Controller di consegna. Ciò conferma che il broker secondario può subentrare, se necessario.
- Sul server del Controller di consegna, accedere a
C:\Windows\ServiceProfiles\NetworkService. - Verificare che
HaDatabaseName.mdfeHaDatabaseName_log.ldfsiano stati creati.
- Sul server del Controller di consegna, accedere a
- Forzare un’interruzione sui Controller di consegna. Dopo aver verificato che la Cache host locale funziona, ricordarsi di riportare tutti i Controller in modalità normale. Questa operazione può richiedere circa 15 minuti.
Registri eventi
I registri eventi indicano quando si verificano sincronizzazioni e interruzioni. Nei registri del visualizzatore eventi, la modalità di interruzione è indicata come modalità HA.*
Servizio di sincronizzazione configurazione:
Durante le normali operazioni, possono verificarsi i seguenti eventi quando il CSS importa i dati di configurazione nel database della Cache host locale utilizzando il broker della Cache host locale.
- 503: Il servizio Citrix Config Sync ha ricevuto una configurazione aggiornata. Questo evento indica l’inizio del processo di sincronizzazione.
- 504: Il servizio Citrix Config Sync ha importato una configurazione aggiornata. L’importazione della configurazione è stata completata correttamente.
- 505: Il servizio Citrix Config Sync non è riuscito a eseguire un’importazione. L’importazione della configurazione non è stata completata correttamente. Se è disponibile una configurazione precedente riuscita, viene utilizzata in caso di interruzione. Tuttavia, sarà obsoleta rispetto alla configurazione corrente. Se non è disponibile alcuna configurazione precedente, il servizio non può partecipare al brokering delle sessioni durante un’interruzione. In questo caso, consultare la sezione Risoluzione dei problemi e contattare il supporto Citrix.
- 507: Il servizio Citrix Config Sync ha abbandonato un’importazione perché il sistema è in modalità di interruzione e il broker della Cache host locale viene utilizzato per il brokering. Il servizio ha ricevuto una nuova configurazione, ma l’importazione è stata abbandonata a causa di un’interruzione. Questo è un comportamento previsto.
- 510: Nessun dato di configurazione del servizio di configurazione ricevuto dal servizio di configurazione primario.
- 517: Si è verificato un problema di comunicazione con il Broker primario.
- 518: Script di sincronizzazione configurazione interrotto perché il Broker secondario (Servizio di alta disponibilità) non è in esecuzione.
Servizio di alta disponibilità:
Questo servizio è noto anche come broker della Cache host locale.
- 3502: Si è verificata un’interruzione e il broker della Cache host locale sta eseguendo operazioni di brokering.
- 3503: Un’interruzione è stata risolta e le normali operazioni sono riprese.
- 3504: Indica quale broker della Cache host locale è stato eletto, oltre ad altri broker della Cache host locale coinvolti nell’elezione.
- 3507: Fornisce un aggiornamento dello stato della Cache host locale ogni 2 minuti, indicando che la modalità Cache host locale è attiva sul broker eletto. Contiene un riepilogo dell’interruzione, inclusa la durata dell’interruzione, la registrazione VDA e le informazioni sulla sessione.
- 3508: Annuncia che la Cache host locale non è più attiva sul broker eletto e che le normali operazioni sono state ripristinate. Contiene un riepilogo dell’interruzione, inclusa la durata dell’interruzione, il numero di macchine registrate durante l’evento della Cache host locale e il numero di avvii riusciti durante l’evento LHC.
- 3509: Notifica che la Cache host locale è attiva sui broker non eletti. Contiene una durata dell’interruzione ogni 2 minuti e indica il broker eletto.
- 3510: Annuncia che la Cache host locale non è più attiva sui broker non eletti. Contiene la durata dell’interruzione e indica il broker eletto.
Forzare un’interruzione
Potrebbe essere necessario forzare deliberatamente un’interruzione.
- Se la rete si attiva e disattiva ripetutamente. Forzare un’interruzione fino a quando i problemi di rete non vengono risolti impedisce la transizione continua tra le modalità normale e di interruzione (e le conseguenti frequenti tempeste di registrazione VDA).
- Per testare un piano di ripristino di emergenza.
- Per contribuire a garantire che la Cache host locale funzioni correttamente.
- Durante la sostituzione o la manutenzione del server del database del sito.
Per forzare un’interruzione, modificare il registro di ogni server contenente un Controller di consegna. In HKLM\Software\Citrix\DesktopServer\LHC, creare e impostare OutageModeForced come REG_DWORD su 1. Questa impostazione indica al broker della Cache host locale di entrare in modalità di interruzione, indipendentemente dallo stato del database. L’impostazione del valore su 0 fa uscire il broker della Cache host locale dalla modalità di interruzione.
Per verificare gli eventi, monitorare il file di registro Current_HighAvailabilityService in C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.
Risoluzione dei problemi
Sono disponibili diversi strumenti di risoluzione dei problemi quando un’importazione di sincronizzazione nel database della Cache host locale fallisce e viene registrato un evento 505.
Traccia CDF: Contiene opzioni per i moduli ConfigSyncServer e BrokerLHC. Tali opzioni, insieme ad altri moduli broker, probabilmente identificheranno il problema.
Report: Se un’importazione di sincronizzazione fallisce, è possibile generare un report. Questo report si interrompe all’oggetto che causa l’errore. Questa funzionalità di report influisce sulla velocità di sincronizzazione, quindi Citrix consiglia di disabilitarla quando non in uso.
Per abilitare e produrre un report di traccia CSS, immettere il seguente comando:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1
Il report HTML viene pubblicato in C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html.
Dopo aver generato il report, immettere il seguente comando per disabilitare la funzionalità di report:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
Esportare la configurazione del broker: Fornisce la configurazione esatta per scopi di debug.
Export-BrokerConfiguration | Out-File <file-pathname>
Ad esempio, Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.
Comandi PowerShell della Cache host locale
È possibile gestire la Cache host locale (LHC) sui Controller di consegna utilizzando i comandi PowerShell.
Il modulo PowerShell si trova nella seguente posizione sui Controller di consegna:
C:\Program Files\Citrix\Broker\Service\ControlScripts
Importante:
Eseguire questo modulo solo sui Controller di consegna.
Importare il modulo PowerShell
Per importare il modulo, eseguire quanto segue sul Controller di consegna.
cd C:\Program Files\Citrix\Broker\Service\ControlScripts
Import-Module .\HighAvailabilityServiceControl.psm1
Comandi PowerShell per gestire LHC
I seguenti comandi consentono di attivare e gestire la modalità LHC sui Controller di consegna.
| Cmdlet | Funzione |
|---|---|
Enable-LhcForcedOutageMode |
Imposta il Broker in modalità LHC. I file del database LHC devono essere stati creati correttamente dal servizio ConfigSync affinché Enable-LhcForcedOutageMode funzioni correttamente. Questo cmdlet forza LHC solo sul Controller di consegna su cui è stato eseguito. Affinché LHC diventi attivo, questo comando deve essere eseguito su tutti i Controller di consegna all’interno della zona. |
Disable-LhcForcedOutageMode |
Disattiva la modalità LHC dal Broker. Questo cmdlet disabilita la modalità LHC solo sul Controller di consegna su cui è stato eseguito. Disable-LhcForcedOutageMode deve essere eseguito su tutti i Controller di consegna all’interno della zona. |
Set-LhcConfigSyncIntervalOverride |
Imposta l’intervallo con cui il servizio Citrix Config Synchronizer (CSS) verifica le modifiche di configurazione all’interno del sito. L’intervallo di tempo può variare da 60 secondi (un minuto) a 3600 secondi (un’ora). Questa impostazione si applica solo al Controller di consegna su cui è stata eseguita. Per coerenza tra i Controller di consegna, considerare di eseguire questo cmdlet su ogni Controller di consegna. Ad esempio: Set-LhcConfigSyncIntervalOverride -Seconds 1200
|
Clear-LhcConfigSyncIntervalOverride |
Imposta l’intervallo con cui il servizio Citrix Config Synchronizer (CSS) verifica le modifiche di configurazione all’interno del sito sul valore predefinito di 300 secondi (cinque minuti). Questa impostazione si applica solo al Controller di consegna su cui è stata eseguita. Per coerenza tra i Controller di consegna, considerare di eseguire questo cmdlet su ogni Controller di consegna. |
Enable-LhcHighAvailabilitySDK |
Abilita l’accesso a tutti i cmdlet Get-Broker* all’interno del Controller di consegna su cui è stato eseguito. |
Disable-LhcHighAvailabilitySDK |
Disabilita l’accesso ai cmdlet del Broker all’interno del Controller di consegna su cui è stato eseguito. |
Nota:
- Utilizzare la porta 89 quando si eseguono i cmdlet
Get-Broker*sul Controller di consegna. Ad esempio:
Get-BrokerMachine -AdminAddress localhost:89- Quando non è in modalità LHC, il Broker LHC sul Controller di consegna contiene solo informazioni di configurazione.
- Durante la modalità LHC, il Broker LHC sul Controller di consegna eletto contiene le seguenti informazioni:
- Stati delle risorse
- Dettagli della sessione
- Registrazioni VDA
- Informazioni di configurazione