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 di SQL Server con tolleranza di errore, seguendo le procedure consigliate per l’alta disponibilità di Microsoft. Per le funzionalità di alta disponibilità di SQL Server supportate, vedere Database. Tuttavia, se vi sono problemi di rete e interruzioni del collegamento, può risultare impossibile per gli utenti connettersi alle proprie applicazioni o desktop.
La funzione cache host locale consente la continuazione delle operazioni di intermediazione della connessione in un sito quando si verifica un’interruzione. Un’interruzione si verifica quando la connessione tra un Delivery Controller e il database del sito non riesce in un ambiente Citrix locale. La cache host locale si attiva quando il database del sito è inaccessibile per 90 secondi.
A partire da XenApp e XenDesktop 7.16, la funzione di leasing della connessione (una funzione delle versioni precedenti che precedeva l’alta disponibilità) è stata rimossa dal prodotto e non è più disponibile.
Contenuto di dati
La cache host locale include le seguenti informazioni, che sono un sottoinsieme delle informazioni contenute nel database principale:
- Identità degli utenti e dei gruppi a cui vengono assegnati diritti sulle risorse pubblicate dal sito.
- Identità degli utenti che attualmente utilizzano o che hanno recentemente utilizzato le risorse pubblicate dal sito.
- Identità delle macchine VDA (incluse le macchine Accesso remoto PC) configurate nel sito.
- Identità (nomi e indirizzi IP) delle macchine client Citrix Receiver utilizzate attivamente per connettersi alle risorse pubblicate.
Contiene inoltre informazioni per le connessioni attualmente attive che sono state stabilite mentre il database principale non era disponibile:
- Risultati di tutte le analisi endpoint del computer client eseguite da Citrix Receiver.
- Identità delle macchine dell’infrastruttura (quali NetScaler Gateway e server StoreFront) coinvolte nel sito.
- Date, orari e tipi delle attività recenti svolte dagli utenti.
Come funziona
L’immagine seguente illustra i componenti della cache host locale e i percorsi di comunicazione durante le normali operazioni.
Durante le normali operazioni
- Il broker principale (Citrix Broker Service) che si trova su un controller accetta richieste di connessione da StoreFront. Il broker comunica con il database del sito per connettere gli utenti con i VDA registrati con il controller.
- Citrix Config Synchronizer Service (CSS) controlla il broker circa ogni 5 minuti per verificare 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 le azioni di sistema (come le assegnazioni di macchine).
-
Se la configurazione è cambiata dopo il controllo precedente, CSS sincronizza (copia) le informazioni con un broker secondario presente nel controller. Il broker secondario è noto anche come servizio High Availability.
Vengono copiati tutti i dati di configurazione, non solo gli elementi che sono cambiati dopo il controllo precedente. Il CSS importa i dati di configurazione in un database Microsoft SQL Server Express LocalDB sul controller. Questo database viene denominato database della cache host locale. CSS assicura che le informazioni contenute nel database della cache host locale corrispondano alle informazioni presenti nel database del sito. Il database della cache host locale viene ricreato a ogni sincronizzazione.
Microsoft SQL Server Express LocalDB (utilizzato dal database della cache host locale) viene installato automaticamente quando si installa un controller. È possibile vietarne l’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 vi sono state modifiche dopo l’ultimo controllo, non vengono copiati dati.
L’immagine seguente illustra come cambiano i percorsi di comunicazione se il broker principale perde il contatto con il database del sito (quando inizia un’interruzione).
Durante un’interruzione
Quando inizia un’interruzione:
- Il broker secondario inizia l’ascolto e l’elaborazione delle 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 riceve anche le informazioni sulla sessione corrente relative a quel VDA.
- Mentre il broker secondario gestisce le connessioni, il broker principale continua a monitorare la connessione. Quando la connessione viene ripristinata, il broker principale chiede al broker secondario di interrompere l’ascolto delle informazioni sulla connessione e ricomincia a svolgere le operazioni di mediazione. La volta successiva che un VDA comunica con il broker principale, viene attivato un processo di registrazione. Il broker secondario rimuove le registrazioni VDA che sono rimaste dall’interruzione precedente. Il CSS riprende la sincronizzazione delle informazioni quando rileva che sono state apportate modifiche della configurazione nella distribuzione.
Nell’improbabile caso in cui un’interruzione inizi durante una sincronizzazione, l’importazione corrente viene eliminata e viene utilizzata l’ultima configurazione nota.
Nel registro eventi sono disponibili informazioni su sincronizzazioni e interruzioni.
Non è previsto alcun limite di tempo per il funzionamento in modalità di interruzione.
La transizione tra modalità normale e di interruzione non influisce sulle sessioni esistenti. Influisce solo sul lancio di nuove sessioni.
È inoltre possibile attivare intenzionalmente un’interruzione. Per dettagli su perché e come farlo, vedere Forzare un’interruzione.
Siti con più controller
Tra le altre attività che svolge, il CSS fornisce regolarmente al broker secondario informazioni su tutti i controller della zona. Se la distribuzione non è dotata di più zone, questa azione ha effetto su tutti i controller del sito. Avendo queste informazioni, ogni broker secondario conosce tutti i broker secondari peer in esecuzione sugli altri controller della zona.
I broker secondari comunicano tra loro su un canale separato. Questi broker utilizzano un elenco alfabetico di nomi FQDN delle macchine su cui sono in esecuzione per determinare (scegliere) quale broker secondario medierà le operazioni nella zona in caso di interruzione. Durante l’interruzione, tutti i VDA si registrano presso il broker secondario scelto. I broker secondari non scelti della zona rifiutano attivamente le richieste di connessione e di registrazione VDA in entrata.
Se un broker secondario scelto si arresta durante un’interruzione, viene scelto un altro broker secondario al suo posto e i VDA si registrano presso il broker secondario appena scelto.
In caso di interruzione, se un controller viene riavviato:
- Se quel controller non è il broker scelto, il riavvio non ha alcun impatto.
- Se il controller è il broker scelto, ne viene scelto un altro, facendo registrare i VDA. Dopo l’accensione, il controller riavviato assume automaticamente il ruolo di mediazione, facendo nuovamente registrare i VDA. In questo scenario, durante le registrazioni le prestazioni possono risentirne.
Se si spegne un controller durante le normali operazioni e quindi lo si accende durante un’interruzione, la cache host locale non può essere utilizzata su quel controller se viene scelto come broker.
Nei registri eventi sono disponibili informazioni sulla scelta dei broker.
Cosa non è disponibile durante un’interruzione e altre differenze
Non è previsto alcun limite di tempo per il funzionamento in modalità di interruzione. Tuttavia, Citrix consiglia di ripristinare la connettività nel modo più rapido possibile.
Durante un’interruzione:
- Non è possibile utilizzare Studio.
-
È disponibile un accesso limitato a PowerShell SDK.
- È necessario innanzitutto:
- Aggiungere una chiave
EnableCssTestModedel Registro di sistema con un valore di 1:New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1 - Usare la porta 89:
Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
- Aggiungere una chiave
- Dopo aver eseguito questi comandi, è possibile accedere a:
- Tutti i cmdlet
Get-Broker*.
- Tutti i cmdlet
- È necessario innanzitutto:
- Le credenziali 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 macchine virtuali dell’host che sono alimentate possono essere utilizzate per le richieste di connessione.
- Una macchina assegnata può essere utilizzata solo se l’assegnazione si è verificata durante le normali operazioni. Non è possibile effettuare nuove assegnazioni durante un’interruzione.
- La registrazione e la configurazione automatica delle macchine Accesso remoto al PC non sono possibili. Tuttavia, le macchine che sono state registrate e configurate durante il normale funzionamento sono utilizzabili.
- Le applicazioni ospitate da server e gli utenti desktop potrebbero utilizzare più sessioni rispetto ai limiti di sessione configurati, se le risorse si trovano in zone diverse.
- Gli utenti possono avviare applicazioni e desktop solo da VDA registrati nella zona contenente il broker secondario attualmente attivo/scelto. Gli avvii tra una zona e l’altra (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 dell’inizio di un riavvio pianificato per i VDA di un gruppo di consegna, i riavvii iniziano al termine dell’interruzione. Questo può avere risultati imprevisti. Per ulteriori informazioni, vedere Riavvii pianificati ritardati a causa di un’interruzione del database.
- La preferenza di zona non può essere configurata. Se è configurata, le preferenze non vengono prese in considerazione per l’avvio della sessione.
- Le restrizioni sui tag in cui i tag vengono utilizzati per designare le zone non sono supportate per l’avvio delle sessioni. Quando sono configurate restrizioni di tag e l’opzione di controllo avanzato di integrità di uno store StoreFront è abilitata, alcune delle sessioni potrebbero non avviarsi.
Supporto di applicazioni e desktop
La cache host locale supporta applicazioni e desktop ospitati da server e desktop statici (assegnati).
La cache host locale supporta i VDA desktop nei gruppi di consegna in pool, come indicato di seguito:
-
Per impostazione predefinita, i VDA desktop con gestione dell’alimentazione in gruppi di consegna in pool (creati da MCS o Citrix Provisioning) con la proprietà
ShutdownDesktopsAfterUseabilitata non sono disponibili per le nuove connessioni durante un evento della cache host locale. È possibile modificare questa impostazione predefinita per consentire l’utilizzo di tali desktop durante l’evento della cache host locale.Tuttavia, non è possibile fare affidamento sulla gestione dell’alimentazione durante l’interruzione. La gestione dell’alimentazione riprende dopo il ripresa delle normali operazioni. Inoltre, tali desktop potrebbero contenere dati dell’utente precedente, perché non sono stati riavviati.
-
Per ignorare il comportamento predefinito, è necessario abilitarlo in tutto il sito e per ogni gruppo di consegna interessato. Eseguire i seguenti cmdlet PowerShell.
A livello del sito:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $truePer ogni gruppo di consegna interessato, eseguire il seguente comando PowerShell:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $trueL’attivazione di questa funzione nel sito e nei gruppi di consegna non influisce sul funzionamento della proprietà
ShutdownDesktopsAfterUseconfigurata durante le normali operazioni.
Importante:
Senza abilitare ReuseMachinesWithoutShutdownInOutageAllowed a livello di sito e ReuseMachinesWithoutShutdownInOutage a livello di gruppo di consegna, tutti i tentativi di avvio della sessione di VDA desktop ad alimentazione gestita in gruppi di consegna in pool non riusciranno durante un evento Local Host Cache.
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 e 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 un intervallo prolungato, durante il quale si verificano 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 della 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 del core e del socket della CPU
La configurazione della CPU di un controller, soprattutto il numero di core disponibili per SQL Server Express LocalDB, influisce direttamente sulle prestazioni della cache dell’host locale, ancor più dell’allocazione della memoria. Questo sovraccarico della CPU viene osservato solo durante il periodo di interruzione quando il database è irraggiungibile 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 migliora le prestazioni (ad esempio, 4 socket con 1 core ciascuna). Citrix consiglia invece 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
Man mano che gli utenti accedono alle risorse durante un’interruzione, LocalDB si ingrandisce. Ad esempio, durante un test di accesso/scollegamento eseguito con 10 accessi al secondo, il database è cresciuto di 1 MB ogni 2-3 minuti. Quando riprende il normale funzionamento, il database locale viene ricreato e lo spazio viene restituito. Tuttavia, deve essere disponibile spazio sufficiente sull’unità in cui è installato LocalDB per consentire l’aumento di dimensioni del database durante un’interruzione. La cache host locale include anche più I/O durante un’interruzione: circa 3 MB di scritture al secondo, accompagnate da 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 normali operazioni, il broker secondario eletto potrebbe dover gestire molte più richieste del normale durante un’interruzione. Pertanto, le richieste della CPU saranno più elevate. Ciascun broker secondario del sito (zona) deve essere in grado di gestire il carico aggiuntivo imposto dal database della cache host locale e da tutti i VDA interessati, poiché il broker secondario selezionato durante un’interruzione può cambiare.
Limiti VDI:
- In una distribuzione VDI a zona singola, durante un’interruzione è possibile gestire in modo efficace fino a 10.000 VDA.
- In una distribuzione VDI multi-zona, durante un’interruzione, è possibile gestire in modo efficace fino a 10.000 VDA in ogni zona fino a un massimo di 40.000 VDA nel sito. Ad esempio, durante un’interruzione ognuno dei seguenti siti può essere gestito in modo efficace:
- 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 vi possono essere ripercussioni sulla gestione del carico all’interno del sito. Possono essere superati i valutatori del carico (e in particolare le regole del conteggio delle sessioni).
Durante il tempo richiesto a tutti i VDA per registrarsi con un broker secondario, tale servizio potrebbe non avere informazioni complete sulle sessioni correnti. Pertanto, una richiesta di connessione da parte di un utente durante tale intervallo può comportare l’avvio di una nuova sessione, anche se era possibile riconnettersi a una sessione esistente. Questo intervallo (mentre il “nuovo” broker secondario acquisisce informazioni sulla sessione da tutti i VDA durante la nuova registrazione) è inevitabile. Le sessioni connesse all’avvio di un’interruzione non sono colpite durante l’intervallo di transizione, ma potrebbero risentirne nuove sessioni e riconnessioni di sessione.
Questo intervallo si verifica ogni volta che i VDA devono registrarsi:
- Inizia un’interruzione: quando si esegue la migrazione da un broker principale a un broker secondario.
- Errore del broker secondario durante un’interruzione: durante la migrazione da un broker secondario che non è riuscito a un broker secondario appena eletto.
- Ripristino da un’interruzione: quando le normali operazioni riprendono e il broker principale riprende il controllo.
È possibile ridurre l’intervallo abbassando il valore del Registro di sistema HeartbeatPeriodMs del Citrix Broker Protocol (valore predefinito = 600000 ms, ovvero 10 minuti). Questo valore di heartbeat è doppio rispetto all’intervallo utilizzato dal VDA per i ping, quindi il valore predefinito genera un ping ogni 5 minuti.
Ad esempio, il seguente comando porta il valore di 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
Prestare attenzione quando si cambia il valore di heartbeat. L’aumento della frequenza si traduce in un carico maggiore sui controller sia in modalità normale che in modalità di interruzione.
L’intervallo non può essere completamente eliminato, indipendentemente dalla rapidità con cui si registra il VDA.
Il tempo necessario per la sincronizzazione tra 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
Questa implementazione della cache host locale condivide il nome della funzionalità di cache host locale in XenApp 6.x e versioni precedenti di XenApp, ma ha subito miglioramenti significativi. Questa implementazione è più robusta e immune alla corruzione. I requisiti di manutenzione sono ridotti al minimo, ad esempio eliminando la necessità di comandi dsmaint periodici. Questa cache host locale è un’implementazione completamente diversa dal punto di vista tecnico.
Gestire la cache host locale
Per il corretto funzionamento della cache host locale, il criterio di esecuzione di PowerShell su ciascun controller deve essere impostato su RemoteSigned, Unrestricted o Bypass.
SQL Server Express LocalDB
Il software Microsoft SQL Server Express LocalDB utilizzato dalla cache host locale viene installato automaticamente quando si installa un controller o si aggiorna un controller da una versione precedente alla 7.9. Solo il broker secondario comunica con questo database. Non è possibile utilizzare i cmdlet PowerShell per apportare alcuna modifica a questo database. LocalDB non può essere condiviso tra i controller.
Il software di database SQL Server Express LocalDB viene installato indipendentemente dal fatto che la cache host locale sia abilitata o meno.
Per impedirne l’installazione, installare o aggiornare il controller utilizzando il comando XenDesktopServerSetup.exe includendo l’opzione /exclude "Local Host Cache Storage (LocalDB)". Tuttavia, tenere presente che la funzione cache host locale non funzionerà senza il database e non sarà possibile utilizzare un database diverso con il broker secondario.
L’installazione di questo database LocalDB non influisce sull’installazione di SQL Server Express per l’utilizzo come database del sito.
Per informazioni sulla sostituzione di una versione precedente di SQL Server Express LocalDB con una versione più recente, vedere Sostituzione di 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 cache host locale è abilitata.
Dopo un aggiornamento (alla versione 7.16 o successiva), la cache host locale viene attivata se sono presenti meno di 10.000 VDA nell’intera distribuzione.
Abilitare e disabilitare la cache host locale
-
Per abilitare cache host locale, immettere:
Set-BrokerSite -LocalHostCacheEnabled $truePer determinare se la cache host locale è abilitata, immettere
Get-BrokerSite. Controllare che la proprietàLocalHostCacheEnabledsiaTrue. -
Per disabilitare la cache host locale, immettere:
Set-BrokerSite -LocalHostCacheEnabled $false
Ricordare: a partire da XenApp e XenDesktop 7.16, il leasing di connessione (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 dell’host locale funzioni
Per verificare che la cache host locale sia correttamente configurata e in funzione:
- Assicurarsi che le importazioni di sincronizzazione siano completate correttamente. Controllare i registri degli eventi.
- Assicurarsi che il database SQL Server Express LocalDB sia stato creato su ciascun Delivery Controller. Ciò conferma che il broker secondario può subentrare, se necessario.
- Nel server del Delivery Controller, passare a
C:\Windows\ServiceProfiles\NetworkService. - Verificare che vengano creati
HaDatabaseName.mdfeHaDatabaseName_log.ldf.
- Nel server del Delivery Controller, passare a
- Forzare un’interruzione sui Delivery Controller. Dopo aver verificato che la cache locale host funziona, ricordare di rimettere 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 viene definita modalità HA. *
Servizio Config Synchronizer:
Durante le normali operazioni, possono verificarsi gli eventi di cui sotto quando il CSS importa i dati di configurazione nel database della cache host locale utilizzando il broker cache host locale.
- 503: Citrix Config Sync Service ha ricevuto una configurazione aggiornata. Questo evento indica l’inizio del processo di sincronizzazione.
- 504: Citrix Config Sync Service ha importato una configurazione aggiornata. L’importazione della configurazione è stata completata correttamente.
- 505: Citrix Config Sync Service non è riuscito a effettuare un’importazione. L’importazione della configurazione non è stata completata correttamente. Se è disponibile, viene utilizzata una precedente configurazione riuscita in caso di interruzione. Tuttavia, sarà obsoleta rispetto alla configurazione corrente. Se non è disponibile alcuna configurazione precedente, il servizio non può partecipare alla mediazione della sessione durante un’interruzione. In questo caso, consultare la sezione Risoluzione dei problemi e contattare il Supporto Citrix.
- 507: Citrix Config Sync Service ha abbandonato un’importazione perché il sistema è in modalità di interruzione e viene utilizzato il broker cache host locale per la mediazione. 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 Configuration Service ricevuto dal servizio di configurazione principale.
- 517: si è verificato un problema di comunicazione con il Broker principale.
- 518: lo script Config Sync si è interrotto perché il Broker secondario (High Availability Service) non è in esecuzione.
High Availability Service:
Questo servizio è noto anche come broker cache host locale.
- 3502: si è verificata un’interruzione e il broker cache host locale sta eseguendo operazioni di mediazione.
- 3503: è stata risolta un’interruzione e sono riprese le normali operazioni.
- 3504: indica quale broker cache host locale viene scelto, oltre ad altri broker cache host locale coinvolti nella scelta.
- 3507: fornisce un aggiornamento dello stato della cache host locale ogni 2 minuti; questo indica che la modalità Cache host locale è attiva sul broker selezionato. Contiene un riepilogo dell’interruzione, inclusa la durata dell’interruzione, la registrazione del VDA e le informazioni sulla sessione.
- 3508: annuncia che la cache host locale non è più attiva sul broker scelto e le normali operazioni sono state ripristinate. Contiene un riepilogo dell’interruzione che include 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 scelti. Contiene una durata di interruzione ogni 2 minuti e indica il broker scelto.
- 3510: annuncia che la cache host locale non è più attiva sui broker non scelti. Contiene la durata dell’interruzione e indica il broker scelto.
Forzare un’interruzione
Potrebbe essere utile forzare deliberatamente un’interruzione.
- Se la rete continua a disattivarsi e riattivarsi. Forzare un’interruzione fino a quando non vengono risolti i problemi di rete impedisce la transizione continua tra modalità normale e di interruzione (e le frequenti tempeste di registrazione VDA che ne derivano).
- Per verificare un piano di ripristino di emergenza.
- Per aiutare a garantire che 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 ciascun server contenente un Delivery Controller. In HKLM\Software\Citrix\DesktopServer\LHC, creare e impostare OutageModeForced come REG_DWORD su 1. Questa impostazione indica al broker cache host locale di accedere alla modalità di interruzione, indipendentemente dallo stato del database. Impostando il valore su 0 si fa uscire il broker cache host locale dalla modalità di interruzione.
Per verificare gli eventi, monitorare il file di log Current_HighAvailabilityService al percorso C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.
Risoluzione dei problemi
Sono disponibili diversi strumenti per la risoluzione dei problemi quando un’importazione di sincronizzazione nel database della cache host locale non riesce e viene pubblicato un evento 505.
CDF tracing: contiene opzioni per i moduli ConfigSyncServer e BrokerLHC. Queste opzioni, insieme ad altri moduli broker, probabilmente identificheranno il problema.
Report: se un’importazione di sincronizzazione non riesce, è possibile generare un rapporto. Questo rapporto si arresta all’oggetto che causa l’errore. Questa funzione di report influisce sulla velocità di sincronizzazione, pertanto 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 è pubblicato all’indirizzo C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html.
Dopo aver generato il report, immettere il seguente comando per disabilitare la funzione di reporting:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
Export the broker configuration (Esporta 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 Delivery Controller utilizzando i comandi PowerShell.
Il modulo PowerShell si trova nella seguente posizione sui Delivery Controller:
C:\Program Files\Citrix\Broker\Service\ControlScripts
Importante:
Eseguire questo modulo solo sui Delivery Controller.
Importare il modulo PowerShell
Per importare il modulo, eseguire il seguente comando sul Delivery Controller.
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 Delivery Controller.
| Cmdlet | Funzione |
|---|---|
Enable-LhcForcedOutageMode |
Mettere il broker in modalità LHC. I file di database LHC devono essere stati creati correttamente dal servizio ConfigSync per assicurare che Enable-LhcForcedOutageMode funzioni correttamente. Questo cmdlet forza LHC solo sul Delivery Controller su cui è stato eseguito. Affinché LHC diventi attivo, questo comando deve essere eseguito su tutti i Delivery Controller all’interno della zona. |
Disable-LhcForcedOutageMode |
Consente di escludere il Broker dalla modalità LHC. Questo cmdlet disabilita solo la modalità LHC sul Delivery Controller su cui è stato eseguito. Disable-LhcForcedOutageMode deve essere eseguito su tutti i Delivery Controller all’interno della zona. |
Set-LhcConfigSyncIntervalOverride |
Imposta l’intervallo con cui Citrix Config Synchronizer Service (CSS) verifica se sono state apportate modifiche alla 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 Delivery Controller in cui è stata eseguita. Per garantire la coerenza tra i Delivery Controller, è consigliabile eseguire questo cmdlet in ciascun Delivery Controller. Ad esempio: Set-LhcConfigSyncIntervalOverride -Seconds 1200
|
Clear-LhcConfigSyncIntervalOverride |
Imposta l’intervallo con cui Citrix Config Synchronizer Service (CSS) verifica le modifiche alla configurazione all’interno del sito sul valore predefinito di 300 secondi (cinque minuti). Questa impostazione si applica solo al Delivery Controller in cui è stata eseguita. Per garantire la coerenza tra i Delivery Controller, è consigliabile eseguire questo cmdlet in ciascun Delivery Controller. |
Enable-LhcHighAvailabilitySDK |
Consente l’accesso a tutti i cmdlet Get-Broker* all’interno del Delivery Controller in cui è stato eseguito. |
Disable-LhcHighAvailabilitySDK |
Disabilita l’accesso ai cmdlet Broker all’interno del Delivery Controller in cui è stato eseguito. |
Nota:
- Utilizzare la porta 89 quando si eseguono i cmdlet
Get-Broker*nel Delivery Controller. Ad esempio:
Get-BrokerMachine -AdminAddress localhost:89- Quando non è in modalità LHC, l’LHC Broker sul Delivery Controller contiene solo le informazioni di configurazione.
- Durante la modalità LHC, il broker LHC presente sul Delivery Controller selezionato contiene le seguenti informazioni:
- Stati delle risorse
- Dettagli della sessione
- Registrazioni dei VDA
- Informazioni sulla configurazione