Lokaler Hostcache
Um sicherzustellen, dass die Citrix Virtual Apps and Desktops-Sitedatenbank immer verfügbar ist, empfiehlt Citrix, mit einer fehlertoleranten SQL Server-Bereitstellung zu beginnen, indem die Best Practices für Hochverfügbarkeit von Microsoft befolgt werden. (Informationen zu unterstützten SQL Server-Hochverfügbarkeitsfunktionen finden Sie unter Datenbanken.) Netzwerkprobleme und -unterbrechungen können jedoch dazu führen, dass Benutzer keine Verbindung zu ihren Anwendungen oder Desktops herstellen können.
Die Funktion „Lokaler Hostcache“ ermöglicht die Fortsetzung von Verbindungsbroker-Vorgängen an einem Standort, wenn ein Ausfall auftritt. Ein Ausfall tritt auf, wenn die Verbindung zwischen einem Delivery Controller™ und der Sitedatenbank in einer lokalen Citrix®-Umgebung fehlschlägt. Der lokale Hostcache wird aktiviert, wenn die Sitedatenbank 90 Sekunden lang nicht erreichbar ist.
Ab XenApp und XenDesktop 7.16 wurde die Verbindungsleasing-Funktion (eine frühere Hochverfügbarkeitsfunktion in früheren Versionen) aus dem Produkt entfernt und ist nicht mehr verfügbar.
Dateninhalt
Der lokale Hostcache enthält die folgenden Informationen, die eine Untermenge der Informationen in der Hauptdatenbank darstellen:
- Identitäten von Benutzern und Gruppen, denen Rechte für vom Standort veröffentlichte Ressourcen zugewiesen sind.
- Identitäten von Benutzern, die derzeit oder kürzlich veröffentlichte Ressourcen vom Standort verwendet haben.
- Identitäten von VDA-Maschinen (einschließlich Remote-PC-Zugriffsmaschinen), die am Standort konfiguriert sind.
- Identitäten (Namen und IP-Adressen) von Client-Citrix Receiver™-Maschinen, die aktiv zum Herstellen einer Verbindung zu veröffentlichten Ressourcen verwendet werden.
Er enthält auch Informationen zu aktuell aktiven Verbindungen, die hergestellt wurden, während die Hauptdatenbank nicht verfügbar war:
- Ergebnisse jeder von Citrix Receiver durchgeführten Endpunktanalyse von Clientmaschinen.
- Identitäten von Infrastrukturmaschinen (wie NetScaler Gateway- und StoreFront™-Servern), die am Standort beteiligt sind.
- Daten, Uhrzeiten und Arten der jüngsten Benutzeraktivitäten.
Funktionsweise
Die folgende Grafik veranschaulicht die Komponenten des Local Host Cache und die Kommunikationspfade während des normalen Betriebs.
Während des normalen Betriebs
- Der Hauptbroker (Citrix Broker Service) auf einem Controller akzeptiert Verbindungsanfragen von StoreFront. Der Broker kommuniziert mit der Sitedatenbank, um Benutzer mit VDAs zu verbinden, die beim Controller registriert sind.
- Der Citrix Config Synchronizer Service (CSS) prüft etwa alle 5 Minuten beim Broker, ob Änderungen vorgenommen wurden. Diese Änderungen können vom Administrator initiiert (z. B. Ändern einer Eigenschaft einer Bereitstellungsgruppe) oder Systemaktionen (z. B. Maschinenzuweisungen) sein.
-
Wenn seit der vorherigen Prüfung eine Konfigurationsänderung aufgetreten ist, synchronisiert (kopiert) der CSS Informationen auf einen sekundären Broker auf dem Controller. (Der sekundäre Broker wird auch als High Availability Service bezeichnet.)
Alle Konfigurationsdaten werden kopiert, nicht nur die Elemente, die sich seit der vorherigen Prüfung geändert haben. Der CSS importiert die Konfigurationsdaten in eine Microsoft SQL Server Express LocalDB-Datenbank auf dem Controller. Diese Datenbank wird als Local Host Cache-Datenbank bezeichnet. Der CSS stellt sicher, dass die Informationen in der Local Host Cache-Datenbank mit den Informationen in der Sitedatenbank übereinstimmen. Die Local Host Cache-Datenbank wird bei jeder Synchronisierung neu erstellt.
Microsoft SQL Server Express LocalDB (das von der Local Host Cache-Datenbank verwendet wird) wird automatisch installiert, wenn Sie einen Controller installieren. (Sie können diese Installation untersagen, wenn Sie einen Controller über die Befehlszeile installieren.) Die Local Host Cache-Datenbank kann nicht von mehreren Controllern gemeinsam genutzt werden. Sie müssen die Local Host Cache-Datenbank nicht sichern. Sie wird jedes Mal neu erstellt, wenn eine Konfigurationsänderung erkannt wird.
- Wenn seit der letzten Prüfung keine Änderungen aufgetreten sind, werden keine Daten kopiert.
Die folgende Grafik veranschaulicht die Änderungen in den Kommunikationspfaden, wenn der Hauptbroker den Kontakt zur Sitedatenbank verliert (ein Ausfall beginnt).
Während eines Ausfalls
Wenn ein Ausfall beginnt:
- Der sekundäre Broker beginnt, Verbindungsanfragen abzuhören und zu verarbeiten.
- Wenn der Ausfall beginnt, verfügt der sekundäre Broker nicht über aktuelle VDA-Registrierungsdaten, aber wenn ein VDA mit ihm kommuniziert, wird ein Registrierungsprozess ausgelöst. Während dieses Prozesses erhält der sekundäre Broker auch aktuelle Sitzungsinformationen über diesen VDA.
- Während der sekundäre Broker Verbindungen verarbeitet, überwacht der Brokering Principal die Verbindung weiterhin. Wenn die Verbindung wiederhergestellt ist, weist der Brokering Principal den sekundären Broker an, das Abhören von Verbindungsinformationen einzustellen, und der Brokering Principal nimmt die Brokering-Vorgänge wieder auf. Wenn ein VDA das nächste Mal mit dem Brokering Principal kommuniziert, wird ein Registrierungsprozess ausgelöst. Der sekundäre Broker entfernt alle verbleibenden VDA-Registrierungen aus dem vorherigen Ausfall. Der CSS nimmt die Synchronisierung von Informationen wieder auf, sobald er feststellt, dass Konfigurationsänderungen in der Bereitstellung vorgenommen wurden.
In dem unwahrscheinlichen Fall, dass ein Ausfall während einer Synchronisierung beginnt, wird der aktuelle Import verworfen und die letzte bekannte Konfiguration verwendet.
Das Ereignisprotokoll enthält Informationen zu Synchronisierungen und Ausfällen.
Für den Betrieb im Ausfallmodus gibt es keine zeitliche Begrenzung.
Der Übergang zwischen Normal- und Ausfallmodus hat keine Auswirkungen auf bestehende Sitzungen. Er wirkt sich nur auf das Starten neuer Sitzungen aus.
Sie können auch absichtlich einen Ausfall auslösen. Weitere Informationen dazu, warum und wie dies zu tun ist, finden Sie unter Ausfall erzwingen.
Sites mit mehreren Controllern
Neben anderen Aufgaben stellt der CSS dem sekundären Broker routinemäßig Informationen über alle Controller in der Zone zur Verfügung. (Wenn Ihre Bereitstellung keine mehreren Zonen enthält, betrifft diese Aktion alle Controller in der Site.) Mit diesen Informationen kennt jeder sekundäre Broker alle Peer-Sekundärbroker, die auf anderen Controllern in der Zone ausgeführt werden.
Die sekundären Broker kommunizieren über einen separaten Kanal miteinander. Diese Broker verwenden eine alphabetische Liste der FQDN-Namen der Maschinen, auf denen sie ausgeführt werden, um zu bestimmen (zu wählen), welcher sekundäre Broker die Broker-Vorgänge in der Zone übernimmt, falls ein Ausfall auftritt. Während des Ausfalls registrieren sich alle VDAs beim gewählten sekundären Broker. Die nicht gewählten sekundären Broker in der Zone lehnen eingehende Verbindungs- und VDA-Registrierungsanfragen aktiv ab.
Wenn ein gewählter sekundärer Broker während eines Ausfalls ausfällt, wird ein anderer sekundärer Broker gewählt, der die Aufgabe übernimmt, und die VDAs registrieren sich beim neu gewählten sekundären Broker.
Wenn während eines Ausfalls ein Controller neu gestartet wird:
- Wenn dieser Controller nicht der gewählte Broker ist, hat der Neustart keine Auswirkungen.
- Wenn dieser Controller der gewählte Broker ist, wird ein anderer Controller gewählt, wodurch sich die VDAs registrieren. Nachdem der neu gestartete Controller hochgefahren ist, übernimmt er automatisch das Brokering, wodurch sich die VDAs erneut registrieren. In diesem Szenario kann die Leistung während der Registrierungen beeinträchtigt werden.
Wenn Sie einen Controller während des normalen Betriebs ausschalten und ihn dann während eines Ausfalls einschalten, kann der lokale Host-Cache auf diesem Controller nicht verwendet werden, wenn er als Broker gewählt wird.
Die Ereignisprotokolle enthalten Informationen zu Wahlen.
Was während eines Ausfalls nicht verfügbar ist und andere Unterschiede
Für den Betrieb im Ausfallmodus gibt es keine zeitliche Begrenzung. Citrix empfiehlt jedoch, die Konnektivität so schnell wie möglich wiederherzustellen.
Während eines Ausfalls:
- Sie können Studio nicht verwenden.
-
Sie haben nur eingeschränkten Zugriff auf das PowerShell SDK.
- Sie müssen zuerst:
- Einen Registrierungsschlüssel
EnableCssTestModemit dem Wert 1 hinzufügen:New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1 - Port 89 verwenden:
Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ContollerDNSName, DesktopGroupName, RegistrationState
- Einen Registrierungsschlüssel
- Nach Ausführung dieser Befehle können Sie zugreifen auf:
- Alle
Get-Broker*-Cmdlets.
- Alle
- Sie müssen zuerst:
- Hypervisor-Anmeldeinformationen können nicht vom Hostdienst abgerufen werden. Alle Maschinen befinden sich im unbekannten Energiezustand, und es können keine Energieoperationen ausgeführt werden. VMs auf dem Host, die eingeschaltet sind, können jedoch für Verbindungsanfragen verwendet werden.
- Eine zugewiesene Maschine kann nur verwendet werden, wenn die Zuweisung während des normalen Betriebs erfolgte. Neue Zuweisungen können während eines Ausfalls nicht vorgenommen werden.
- Die automatische Registrierung und Konfiguration von Remote-PC-Zugriffsmaschinen ist nicht möglich. Maschinen, die während des normalen Betriebs registriert und konfiguriert wurden, sind jedoch nutzbar.
- Benutzer von servergehosteten Anwendungen und Desktops verwenden möglicherweise mehr Sitzungen als ihre konfigurierten Sitzungslimits, wenn sich die Ressourcen in verschiedenen Zonen befinden.
- Benutzer können Anwendungen und Desktops nur von registrierten VDAs in der Zone starten, die den aktuell aktiven/gewählten sekundären Broker enthält. Zonenübergreifende Starts (von einem sekundären Broker in einer Zone zu einem VDA in einer anderen Zone) werden während eines Ausfalls nicht unterstützt.
- Wenn ein Ausfall der Sitedatenbank auftritt, bevor ein geplanter Neustart für VDAs in einer Bereitstellungsgruppe beginnt, beginnen die Neustarts, wenn der Ausfall endet. Dies kann unbeabsichtigte Folgen haben. Weitere Informationen finden Sie unter Geplante Neustarts aufgrund von Datenbankausfall verzögert.
- Zonenpräferenz kann nicht konfiguriert werden. Wenn konfiguriert, werden Präferenzen beim Starten von Sitzungen nicht berücksichtigt.
- Tag-Einschränkungen, bei denen Tags zur Kennzeichnung von Zonen verwendet werden, werden für den Sitzungsstart nicht unterstützt. Wenn solche Tag-Einschränkungen konfiguriert sind und die Option Erweiterte Integritätsprüfung eines StoreFront-Stores aktiviert ist, können Sitzungen gelegentlich nicht gestartet werden.
Unterstützung für Anwendungen und Desktops
Der lokale Hostcache unterstützt servergehostete Anwendungen und Desktops sowie statische (zugewiesene) Desktops.
Der lokale Hostcache unterstützt Desktop-VDAs in gepoolten Bereitstellungsgruppen wie folgt:
-
Standardmäßig sind energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen (erstellt von MCS oder Citrix Provisioning™), bei denen die Eigenschaft
ShutdownDesktopsAfterUseaktiviert ist, während eines lokalen Hostcache-Ereignisses nicht für neue Verbindungen verfügbar. Sie können diese Standardeinstellung ändern, um die Verwendung dieser Desktops während des lokalen Hostcaches zu ermöglichen.Während des Ausfalls können Sie sich jedoch nicht auf die Energieverwaltung verlassen. (Die Energieverwaltung wird fortgesetzt, nachdem der normale Betrieb wieder aufgenommen wurde.) Außerdem können diese Desktops Daten vom vorherigen Benutzer enthalten, da sie nicht neu gestartet wurden.
-
Um das Standardverhalten zu überschreiben, muss es standortweit und für jede betroffene Bereitstellungsgruppe aktiviert werden. Führen Sie die folgenden PowerShell-Cmdlets aus.
Standortweit:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $trueFühren Sie für jede betroffene Bereitstellungsgruppe den folgenden PowerShell-Befehl aus:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $trueDas Aktivieren dieser Funktion in der Site und den Bereitstellungsgruppen hat keinen Einfluss darauf, wie die konfigurierte Eigenschaft
ShutdownDesktopsAfterUsewährend des normalen Betriebs funktioniert. Wenn diese Funktion aktiviert ist, werden VDAs nach Abschluss des LHC-Ereignisses nicht automatisch neu gestartet. Energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen können Daten aus früheren Sitzungen beibehalten, bis der VDA neu gestartet wird. Dies kann auftreten, wenn sich ein Benutzer während Nicht-LHC-Vorgängen vom VDA abmeldet oder der Neustart manuell ausgelöst werden kann.
Wichtig:
Ohne die Aktivierung von ReuseMachinesWithoutShutdownInOutageAllowed auf Site-Ebene und ReuseMachinesWithoutShutdownInOutage auf Bereitstellungsgruppenebene schlagen alle Sitzungsstartversuche für energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen während eines Local Host Cache-Ereignisses fehl.
Überlegungen zur RAM-Größe
Der LocalDB-Dienst kann ca. 1,2 GB RAM verwenden (bis zu 1 GB für den Datenbank-Cache plus 200 MB für den Betrieb von SQL Server Express LocalDB). Der sekundäre Broker kann bis zu 1 GB RAM verwenden, wenn ein Ausfall über einen längeren Zeitraum mit vielen Anmeldungen andauert (z. B. 12 Stunden bei 10.000 Benutzern). Diese Speicheranforderungen gelten zusätzlich zu den normalen RAM-Anforderungen für den Controller, sodass Sie die gesamte RAM-Kapazität möglicherweise erhöhen müssen.
Wenn Sie eine SQL Server Express-Installation für die Sitedatenbank verwenden, verfügt der Server über zwei sqlserver.exe-Prozesse.
Überlegungen zur CPU-Kern- und Socket-Konfiguration
Die CPU-Konfiguration eines Controllers, insbesondere die Anzahl der für die SQL Server Express LocalDB verfügbaren Kerne, wirkt sich direkt auf die Leistung des Local Host Cache aus, sogar stärker als die Speicherzuweisung. Dieser CPU-Mehraufwand wird nur während des Ausfallzeitraums beobachtet, wenn die Datenbank nicht erreichbar ist und der sekundäre Broker aktiv ist.
Obwohl LocalDB mehrere Kerne (bis zu 4) verwenden kann, ist es auf einen einzigen Socket beschränkt. Das Hinzufügen weiterer Sockets verbessert die Leistung nicht (z. B. 4 Sockets mit jeweils 1 Kern). Stattdessen empfiehlt Citrix die Verwendung mehrerer Sockets mit mehreren Kernen. In Citrix-Tests lieferte eine 2x3-Konfiguration (2 Sockets, 3 Kerne) eine bessere Leistung als 4x1- und 6x1-Konfigurationen.
Überlegungen zum Speicher
Wenn Benutzer während eines Ausfalls auf Ressourcen zugreifen, wächst die LocalDB. Bei einem An-/Abmeldetest mit 10 Anmeldungen pro Sekunde wuchs die Datenbank beispielsweise alle 2-3 Minuten um 1 MB. Wenn der normale Betrieb wieder aufgenommen wird, wird die lokale Datenbank neu erstellt und der Speicherplatz freigegeben. Es muss jedoch ausreichend Speicherplatz auf dem Laufwerk verfügbar sein, auf dem die LocalDB installiert ist, um das Datenbankwachstum während eines Ausfalls zu ermöglichen. Der Local Host Cache verursacht während eines Ausfalls auch mehr E/A-Vorgänge: ca. 3 MB Schreibvorgänge pro Sekunde, mit mehreren hunderttausend Lesevorgängen.
Überlegungen zur Leistung
Während eines Ausfalls verarbeitet ein sekundärer Broker alle Verbindungen. In Sites (oder Zonen), die während des normalen Betriebs die Last auf mehrere Controller verteilen, muss der gewählte sekundäre Broker während eines Ausfalls möglicherweise viel mehr Anfragen verarbeiten als normal. Daher ist der CPU-Bedarf höher. Jeder sekundäre Broker in der Site (Zone) muss die zusätzliche Last bewältigen können, die durch die Local Host Cache-Datenbank und alle betroffenen VDAs entsteht, da der während eines Ausfalls gewählte sekundäre Broker wechseln kann.
VDI-Grenzwerte:
- In einer VDI-Bereitstellung mit einer einzigen Zone können während eines Ausfalls bis zu 10.000 VDAs effektiv verwaltet werden.
- In einer VDI-Bereitstellung mit mehreren Zonen können während eines Ausfalls bis zu 10.000 VDAs pro Zone effektiv verwaltet werden, bis zu einem Maximum von 40.000 VDAs in der Site. Zum Beispiel können die folgenden Sites während eines Ausfalls effektiv verwaltet werden:
- Eine Site mit vier Zonen, die jeweils 10.000 VDAs enthalten.
- Eine Site mit sieben Zonen, eine davon mit 10.000 VDAs und sechs weitere mit jeweils 5.000 VDAs.
Während eines Ausfalls kann die Lastverwaltung innerhalb der Site beeinträchtigt werden. Lastauswerter (und insbesondere Regeln für die Sitzungsanzahl) können überschritten werden.
Während der Zeit, die alle VDAs für die Registrierung bei einem sekundären Broker benötigen, verfügt dieser Dienst möglicherweise nicht über vollständige Informationen zu aktuellen Sitzungen. Eine Benutzerverbindungsanforderung während dieses Intervalls kann daher zum Starten einer neuen Sitzung führen, obwohl eine Wiederverbindung mit einer vorhandenen Sitzung möglich gewesen wäre. Dieses Intervall (während der „neue“ sekundäre Broker bei der erneuten Registrierung Sitzungsinformationen von allen VDAs abruft) ist unvermeidlich. Sitzungen, die bei Beginn eines Ausfalls verbunden sind, sind während des Übergangsintervalls nicht betroffen, neue Sitzungen und Sitzungswiederverbindungen jedoch möglicherweise.
Dieses Intervall tritt immer dann auf, wenn VDAs sich registrieren müssen:
- Ein Ausfall beginnt: Beim Migrieren von einem primären Broker zu einem sekundären Broker.
- Ausfall des sekundären Brokers während eines Ausfalls: Beim Migrieren von einem ausgefallenen sekundären Broker zu einem neu gewählten sekundären Broker.
- Wiederherstellung nach einem Ausfall: Wenn der normale Betrieb wieder aufgenommen wird und der primäre Broker die Kontrolle wieder übernimmt.
Sie können das Intervall verringern, indem Sie den Registrierungswert HeartbeatPeriodMs des Citrix Broker Protocols senken (Standard = 600000 ms, d. h. 10 Minuten). Dieser Heartbeat-Wert ist doppelt so lang wie das Intervall, das der VDA für Pings verwendet, sodass der Standardwert alle 5 Minuten einen Ping ergibt.
Der folgende Befehl ändert den Heartbeat beispielsweise auf fünf Minuten (300000 Millisekunden), was alle 2,5 Minuten einen Ping zur Folge hat:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
Seien Sie vorsichtig, wenn Sie den Heartbeat-Wert ändern. Eine Erhöhung der Frequenz führt zu einer höheren Last auf den Controllern, sowohl im Normalbetrieb als auch im Ausfallmodus.
Das Intervall kann nicht vollständig eliminiert werden, egal wie schnell sich die VDAs registrieren.
Die Synchronisierungszeit zwischen sekundären Brokern nimmt mit der Anzahl der Objekte (z. B. VDAs, Anwendungen, Gruppen) zu. Das Synchronisieren von 5000 VDAs kann beispielsweise 10 Minuten oder länger dauern.
Unterschiede zu XenApp 6.x-Versionen
Obwohl diese Local Host Cache-Implementierung den Namen der Local Host Cache-Funktion in XenApp 6.x und früheren XenApp-Versionen teilt, gibt es erhebliche Verbesserungen. Diese Implementierung ist robuster und unempfindlicher gegenüber Beschädigungen. Die Wartungsanforderungen sind minimiert, z. B. entfällt die Notwendigkeit periodischer dsmaint-Befehle. Dieser Local Host Cache ist technisch eine völlig andere Implementierung.
Lokalen Hostcache verwalten
Damit der lokale Hostcache ordnungsgemäß funktioniert, muss die PowerShell-Ausführungsrichtlinie auf jedem Controller auf RemoteSigned, Unrestricted oder Bypass eingestellt sein.
SQL Server Express LocalDB
Die Microsoft SQL Server Express LocalDB-Software, die der lokale Hostcache verwendet, wird automatisch installiert, wenn Sie einen Controller installieren oder einen Controller von einer Version vor 7.9 aktualisieren. Nur der sekundäre Broker kommuniziert mit dieser Datenbank. Sie können keine PowerShell-Cmdlets verwenden, um Änderungen an dieser Datenbank vorzunehmen. Die LocalDB kann nicht über Controller hinweg gemeinsam genutzt werden.
Die SQL Server Express LocalDB-Datenbanksoftware wird installiert, unabhängig davon, ob der lokale Hostcache aktiviert ist.
Um die Installation zu verhindern, installieren oder aktualisieren Sie den Controller mit dem Befehl XenDesktopServerSetup.exe und fügen Sie die Option /exclude "Local Host Cache Storage (LocalDB)" hinzu. Beachten Sie jedoch, dass die Funktion Lokaler Hostcache ohne die Datenbank nicht funktioniert und Sie keine andere Datenbank mit dem sekundären Broker verwenden können.
Die Installation dieser LocalDB-Datenbank hat keinen Einfluss darauf, ob Sie SQL Server Express als Sitedatenbank installieren.
Informationen zum Ersetzen einer älteren SQL Server Express LocalDB-Version durch eine neuere Version finden Sie unter SQL Server Express LocalDB ersetzen.
Standardeinstellungen nach Produktinstallation und Upgrade
Bei einer Neuinstallation von Citrix Virtual Apps and Desktops (Mindestversion 7.16) ist der lokale Hostcache aktiviert.
Nach einem Upgrade (auf Version 7.16 oder höher) ist der lokale Hostcache aktiviert, wenn weniger als 10.000 VDAs in der gesamten Bereitstellung vorhanden sind.
Lokalen Hostcache aktivieren und deaktivieren
-
Um den lokalen Hostcache zu aktivieren, geben Sie Folgendes ein:
Set-BrokerSite -LocalHostCacheEnabled $trueUm festzustellen, ob der lokale Hostcache aktiviert ist, geben Sie
Get-BrokerSiteein. Überprüfen Sie, ob die EigenschaftLocalHostCacheEnabledTrueist. -
Um den Local Host Cache zu deaktivieren, geben Sie Folgendes ein:
Set-BrokerSite -LocalHostCacheEnabled $false
Hinweis: Ab XenApp und XenDesktop 7.16 wurde Connection Leasing (die Funktion, die dem Local Host Cache ab Version 7.6 vorausging) aus dem Produkt entfernt und ist nicht mehr verfügbar.
Überprüfen, ob der Local Host Cache funktioniert
So überprüfen Sie, ob der Local Host Cache eingerichtet ist und ordnungsgemäß funktioniert:
- Stellen Sie sicher, dass Synchronisierungsimporte erfolgreich abgeschlossen werden. Überprüfen Sie die Ereignisprotokolle.
- Stellen Sie sicher, dass die SQL Server Express LocalDB-Datenbank auf jedem Delivery Controller erstellt wurde. Dies bestätigt, dass der sekundäre Broker bei Bedarf übernehmen kann.
- Navigieren Sie auf dem Delivery Controller-Server zu
C:\Windows\ServiceProfiles\NetworkService. - Überprüfen Sie, ob
HaDatabaseName.mdfundHaDatabaseName_log.ldferstellt wurden.
- Navigieren Sie auf dem Delivery Controller-Server zu
- Erzwingen Sie einen Ausfall auf den Delivery Controllern. Nachdem Sie überprüft haben, dass der Local Host Cache funktioniert, versetzen Sie alle Controller wieder in den Normalmodus. Dies kann etwa 15 Minuten dauern.
Ereignisprotokolle
Ereignisprotokolle zeigen an, wann Synchronisierungen und Ausfälle auftreten. In den Ereignisanzeige-Protokollen wird der Ausfallmodus als HA-Modus bezeichnet.*
Config Synchronizer Service:
Während des normalen Betriebs können die folgenden Ereignisse auftreten, wenn der CSS die Konfigurationsdaten mithilfe des Local Host Cache-Brokers in die Local Host Cache-Datenbank importiert.
- 503: Der Citrix Config Sync Service hat eine aktualisierte Konfiguration empfangen. Dieses Ereignis zeigt den Beginn des Synchronisierungsprozesses an.
- 504: Der Citrix Config Sync Service hat eine aktualisierte Konfiguration importiert. Der Konfigurationsimport wurde erfolgreich abgeschlossen.
- 505: Der Citrix Config Sync Service hat einen Importfehler gemeldet. Der Konfigurationsimport wurde nicht erfolgreich abgeschlossen. Wenn eine frühere erfolgreiche Konfiguration verfügbar ist, wird diese bei einem Ausfall verwendet. Sie ist jedoch gegenüber der aktuellen Konfiguration veraltet. Wenn keine frühere Konfiguration verfügbar ist, kann der Dienst während eines Ausfalls nicht am Session Brokering teilnehmen. In diesem Fall lesen Sie den Abschnitt Problembehandlung und wenden Sie sich an den Citrix Support.
- 507: Der Citrix Config Sync Service hat einen Import abgebrochen, da sich das System im Ausfallmodus befindet und der Local Host Cache-Broker für das Brokering verwendet wird. Der Dienst hat eine neue Konfiguration erhalten, der Import wurde jedoch aufgrund eines aufgetretenen Ausfalls abgebrochen. Dies ist ein erwartetes Verhalten.
- 510: Keine Konfigurationsdienst-Konfigurationsdaten vom primären Konfigurationsdienst empfangen.
- 517: Es gab ein Problem bei der Kommunikation mit dem primären Broker.
- 518: Das Config Sync-Skript wurde abgebrochen, da der sekundäre Broker (High Availability Service) nicht ausgeführt wird.
High Availability Service:
Dieser Dienst wird auch als Local Host Cache-Broker bezeichnet.
- 3502: Ein Ausfall ist aufgetreten, und der Local Host Cache-Broker führt Brokering-Vorgänge aus.
- 3503: Ein Ausfall wurde behoben, und der normale Betrieb wurde wieder aufgenommen.
- 3504: Zeigt an, welcher Local Host Cache-Broker gewählt wurde, sowie andere am Wahlprozess beteiligte Local Host Cache-Broker.
Einen Ausfall erzwingen
Möglicherweise möchten Sie absichtlich einen Ausfall erzwingen.
- Wenn Ihr Netzwerk wiederholt ausfällt und wiederhergestellt wird. Das Erzwingen eines Ausfalls, bis die Netzwerkprobleme behoben sind, verhindert einen kontinuierlichen Übergang zwischen Normal- und Ausfallmodus (und die daraus resultierenden häufigen VDA-Registrierungsstürme).
- Zum Testen eines Notfallwiederherstellungsplans.
- Um sicherzustellen, dass der Local Host Cache ordnungsgemäß funktioniert.
- Beim Ersetzen oder Warten des Sitedatenbankservers.
Um einen Ausfall zu erzwingen, bearbeiten Sie die Registrierung jedes Servers, der einen Delivery Controller enthält. Erstellen und setzen Sie in HKLM\Software\Citrix\DesktopServer\LHC OutageModeForced als REG_DWORD auf 1. Diese Einstellung weist den Local Host Cache-Broker an, in den Ausfallmodus zu wechseln, unabhängig vom Status der Datenbank. Wenn Sie den Wert auf 0 setzen, wird der Local Host Cache-Broker aus dem Ausfallmodus genommen.
Um Ereignisse zu überprüfen, überwachen Sie die Protokolldatei Current_HighAvailabilityService in C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.
Problembehandlung
Es stehen mehrere Tools zur Problembehandlung zur Verfügung, wenn ein Synchronisierungsimport in die Local Host Cache-Datenbank fehlschlägt und ein 505-Ereignis protokolliert wird.
CDF-Tracing: Enthält Optionen für die Module ConfigSyncServer und BrokerLHC. Diese Optionen werden zusammen mit anderen Broker-Modulen das Problem wahrscheinlich identifizieren.
Bericht: Wenn ein Synchronisierungsimport fehlschlägt, können Sie einen Bericht generieren. Dieser Bericht stoppt bei dem Objekt, das den Fehler verursacht. Diese Berichtsfunktion beeinträchtigt die Synchronisierungsgeschwindigkeit, daher empfiehlt Citrix, sie bei Nichtgebrauch zu deaktivieren.
Um einen CSS-Trace-Bericht zu aktivieren und zu erstellen, geben Sie den folgenden Befehl ein:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1
Der HTML-Bericht wird unter C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html veröffentlicht.
Nachdem der Bericht generiert wurde, geben Sie den folgenden Befehl ein, um die Berichtsfunktion zu deaktivieren:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
Brokerkonfiguration exportieren: Bietet die exakte Konfiguration für Debugging-Zwecke.
Export-BrokerConfiguration | Out-File <file-pathname>
Zum Beispiel Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.