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 Funktion „Verbindungsleasing“ (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 veröffentlichte Ressourcen vom Standort verwenden oder kürzlich 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 mit veröffentlichten Ressourcen verwendet werden.
Es enthält auch Informationen für aktuell aktive 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™-Server), die am Standort beteiligt sind.
- Datum, Uhrzeit und Art der letzten Aktivitäten von Benutzern.
Funktionsweise
Die folgende Grafik veranschaulicht die Komponenten des lokalen Hostcaches 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 letzten 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 letzten 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 verbieten, 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 der Kommunikationspfade, 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 zu diesem 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 Informationssynchronisierung wieder auf, wenn 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 zuletzt 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 betrifft nur den Start neuer Sitzungen.
Sie können auch absichtlich einen Ausfall auslösen. Weitere Informationen dazu, warum und wie dies geschieht, finden Sie unter Ausfall erzwingen.
Sites mit mehreren Controllern
Neben anderen Aufgaben versorgt der CSS den sekundären Broker routinemäßig mit Informationen über alle Controller in der Zone. (Wenn Ihre Bereitstellung keine mehreren Zonen enthält, betrifft diese Aktion alle Controller in der Site.) Mit diesen Informationen weiß jeder sekundäre Broker über alle gleichrangigen sekundären Broker Bescheid, 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-Operationen 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 VDAs registriert werden. Nachdem der neu gestartete Controller hochgefahren ist, übernimmt er automatisch das Brokering, wodurch VDAs erneut registriert werden. 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 Hostcache 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, ControllerDNSName, DesktopGroupName, RegistrationState
- Einen Registrierungsschlüssel
- Nachdem Sie diese Befehle ausgeführt haben, 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.
- Servergehostete Anwendungen und Desktop-Benutzer könnten mehr Sitzungen nutzen, als ihre konfigurierten Sitzungslimits zulassen, 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 eintritt, bevor ein geplanter Neustart für VDAs in einer Bereitstellungsgruppe beginnt, beginnen die Neustarts, wenn der Ausfall behoben ist. 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 Sitzungsstart nicht berücksichtigt.
- Tag-Einschränkungen, bei denen Tags zur Bezeichnung von Zonen verwendet werden, werden für Sitzungsstarts 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 zeitweise 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 für neue Verbindungen nicht verfügbar. Sie können diese Standardeinstellung ändern, um die Verwendung dieser Desktops während des lokalen Hostcaches zu ermöglichen.Sie können sich jedoch während des Ausfalls nicht auf die Energieverwaltung verlassen. (Die Energieverwaltung wird nach Wiederaufnahme des normalen Betriebs fortgesetzt.) 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 $true
Um die Einstellung der Bereitstellungsgruppe standardmäßig zu aktivieren, führen Sie den folgenden PowerShell-Befehl aus:
Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true
Diese Einstellung gilt für alle neuen Bereitstellungsgruppen, die nach dem Aktivieren dieser Einstellung erstellt werden.
Um diese Einstellung für die vorhandenen Bereitstellungsgruppen zu aktivieren, führen Sie den folgenden PowerShell-Befehl aus:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
Das Aktivieren dieser Funktion in der Site und den Bereitstellungsgruppen hat keinen Einfluss darauf, wie die konfigurierte ShutdownDesktopsAfterUse-Eigenschaft während des normalen Betriebs funktioniert. Wenn diese Funktion aktiviert ist, starten VDAs nach Abschluss des LHC-Ereignisses nicht automatisch neu. 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 kann manuell ausgelöst werden.
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 ungefähr 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 (zum Beispiel 12 Stunden mit 10.000 Benutzern). Diese Speicheranforderungen kommen zu den normalen RAM-Anforderungen für den Controller hinzu, daher müssen Sie möglicherweise die gesamte RAM-Kapazität erhöhen.
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 Kerne, die der SQL Server Express LocalDB zur Verfügung stehen, wirkt sich direkt auf die Leistung des Local Host Cache aus, sogar mehr als die Speicherzuweisung. Dieser CPU-Overhead wird nur während des Ausfallzeitraums beobachtet, wenn die Datenbank nicht erreichbar und der sekundäre Broker aktiv ist.
Obwohl LocalDB mehrere Kerne verwenden kann (bis zu 4), ist es auf einen einzigen Socket beschränkt. Das Hinzufügen weiterer Sockets verbessert die Leistung nicht (zum Beispiel 4 Sockets mit jeweils 1 Kern). Stattdessen empfiehlt Citrix die Verwendung mehrerer Sockets mit mehreren Kernen. Bei Citrix-Tests lieferte eine 2x3-Konfiguration (2 Sockets, 3 Kerne) eine bessere Leistung als 4x1- und 6x1-Konfigurationen.
Überlegungen zum Speicherplatz
Wenn Benutzer während eines Ausfalls auf Ressourcen zugreifen, wächst die LocalDB. Zum Beispiel wuchs die Datenbank während eines Anmelde-/Abmeldetests mit 10 Anmeldungen pro Sekunde um 1 MB alle 2-3 Minuten. 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: ungefähr 3 MB Schreibvorgänge pro Sekunde, mit mehreren hunderttausend Lesevorgängen.
Überlegungen zur Leistung
Während eines Ausfalls übernimmt ein sekundärer Broker alle Verbindungen. In Sites (oder Zonen), die im Normalbetrieb die Last auf mehrere Controller verteilen, muss der gewählte sekundäre Broker während eines Ausfalls möglicherweise wesentlich mehr Anfragen als üblich bearbeiten. 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 sich der während eines Ausfalls gewählte sekundäre Broker ändern 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 mit 10.000 VDAs und sechs mit jeweils 5.000 VDAs.
Während eines Ausfalls kann die Lastverwaltung innerhalb der Site beeinträchtigt sein. Lastausgleicher (und insbesondere Sitzungsanzahlregeln) können überschritten werden.
Während der Zeit, die alle VDAs benötigen, um sich bei einem sekundären Broker zu registrieren, verfügt dieser Dienst möglicherweise nicht über vollständige Informationen zu aktuellen Sitzungen. Eine Benutzerverbindungsanfrage in diesem Intervall kann daher zum Start einer neuen Sitzung führen, obwohl eine Wiederverbindung zu einer bestehenden 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 beim Beginn eines Ausfalls verbunden sind, sind während des Übergangsintervalls nicht betroffen, aber neue Sitzungen und Sitzungswiederverbindungen könnten es sein.
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 verkürzen, indem Sie den Registrierungswert HeartbeatPeriodMs des Citrix Broker Protocols senken (Standard = 600000 ms, also 10 Minuten). Dieser Heartbeat-Wert ist doppelt so hoch 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 größeren 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 Implementierung des lokalen Hostcaches den Namen der lokalen Hostcache-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. Der Wartungsaufwand wird minimiert, z. B. entfällt die Notwendigkeit regelmäßiger dsmaint-Befehle. Dieser lokale Hostcache 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“ festgelegt sein.
SQL Server Express LocalDB
Die von Local Host Cache verwendete Microsoft SQL Server Express LocalDB-Software 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 von mehreren Controllern gemeinsam genutzt werden.
Die SQL Server Express LocalDB-Datenbanksoftware wird unabhängig davon installiert, 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 Local Host Cache-Funktion 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 früheren 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) wird der Local Host Cache aktiviert, wenn weniger als 10.000 VDAs in der gesamten Bereitstellung vorhanden sind.
Local Host Cache aktivieren und deaktivieren
-
So aktivieren Sie den Local Host Cache:
Set-BrokerSite -LocalHostCacheEnabled $trueUm festzustellen, ob der Local Host Cache aktiviert ist, geben Sie
Get-BrokerSiteein. Überprüfen Sie, ob die EigenschaftLocalHostCacheEnabledTrueist. -
So deaktivieren Sie den Local Host Cache:
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 korrekt eingerichtet ist und 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 konnte einen Import nicht durchführen. Der Konfigurationsimport wurde nicht erfolgreich abgeschlossen. Wenn eine zuvor 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 empfangen, der Import wurde jedoch aufgrund eines Ausfalls abgebrochen. Dies ist ein erwartetes Verhalten.
- 510: Keine Konfigurationsdaten des Konfigurationsdienstes vom primären Konfigurationsdienst empfangen.
- 517: Bei der Kommunikation mit dem primären Broker ist ein Problem aufgetreten.
- 518: Das Config Sync-Skript wurde abgebrochen, da der sekundäre Broker (High Availability Service) nicht ausgeführt wird.
High Availability Service:
Dieser Dienst ist auch als Local Host Cache-Broker bekannt.
- 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.
- 3507: Bietet alle 2 Minuten eine Statusaktualisierung des Local Host Cache, die anzeigt, dass der Local Host Cache-Modus auf dem gewählten Broker aktiv ist. Enthält eine Zusammenfassung des Ausfalls, einschließlich Ausfalldauer, VDA-Registrierung und Sitzungsinformationen.
- 3508: Meldet, dass der Local Host Cache auf dem gewählten Broker nicht mehr aktiv ist und der normale Betrieb wiederhergestellt wurde. Enthält eine Zusammenfassung des Ausfalls, einschließlich Ausfalldauer, Anzahl der Maschinen, die sich während des Local Host Cache-Ereignisses registriert haben, und Anzahl der erfolgreichen Starts während des LHC-Ereignisses.
- 3509: Benachrichtigt, dass der Local Host Cache auf dem/den nicht gewählten Broker(n) aktiv ist. Enthält alle 2 Minuten eine Ausfalldauer und zeigt den gewählten Broker an.
- 3510: Meldet, dass der Local Host Cache auf dem/den nicht gewählten Broker(n) nicht mehr aktiv ist. Enthält die Ausfalldauer und zeigt den gewählten Broker an.
Einen Ausfall erzwingen
Möglicherweise möchten Sie absichtlich einen Ausfall erzwingen.
- Wenn Ihr Netzwerk wiederholt ausfällt. 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 Site-Datenbankservers.
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 den Wert OutageModeForced als REG_DWORD auf 1. Diese Einstellung weist den Local Host Cache-Broker an, in den Ausfallmodus zu wechseln, unabhängig vom Zustand der Datenbank. Das Setzen des Werts auf 0 beendet den Ausfallmodus des Local Host Cache-Brokers.
Um Ereignisse zu überprüfen, überwachen Sie die Protokolldatei Current_HighAvailabilityService in C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.
Problembehandlung
Mehrere Tools zur Problembehandlung stehen zur Verfügung, wenn ein Synchronisierungsimport in die Local Host Cache-Datenbank fehlschlägt und ein 505-Ereignis gemeldet 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
Broker-Konfiguration exportieren: Bietet die genaue Konfiguration für Debugging-Zwecke.
Export-BrokerConfiguration | Out-File <file-pathname>
Zum Beispiel Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.
PowerShell-Befehle für den lokalen Hostcache
Sie können den lokalen Hostcache (LHC) auf Ihren Delivery Controllern mithilfe von PowerShell-Befehlen verwalten.
Das PowerShell-Modul befindet sich an folgendem Speicherort auf den Delivery Controllern:
C:\Program Files\Citrix\Broker\Service\ControlScripts
Wichtig:
Führen Sie dieses Modul nur auf den Delivery Controllern aus.
PowerShell-Modul importieren
Um das Modul zu importieren, führen Sie Folgendes auf Ihrem Delivery Controller aus.
cd C:\Program Files\Citrix\Broker\Service\ControlScripts
Import-Module .\HighAvailabilityServiceControl.psm1
PowerShell-Befehle zur Verwaltung von LHC
Die folgenden Befehle helfen Ihnen, den LHC-Modus auf den Delivery Controllern zu aktivieren und zu verwalten.
| Cmdlets | Funktion |
|---|---|
Enable-LhcForcedOutageMode |
Versetzt den Broker in den LHC-Modus. LHC-Datenbankdateien müssen vom ConfigSync-Dienst erfolgreich erstellt worden sein, damit Enable-LhcForcedOutageMode ordnungsgemäß funktioniert. Dieses Cmdlet erzwingt LHC nur auf dem Delivery Controller, auf dem es ausgeführt wurde. Damit LHC aktiv wird, muss dieser Befehl auf allen Delivery Controllern innerhalb der Zone ausgeführt werden. |
Disable-LhcForcedOutageMode |
Nimmt den Broker aus dem LHC-Modus. Dieses Cmdlet deaktiviert den LHC-Modus nur auf dem Delivery Controller, auf dem es ausgeführt wurde. Disable-LhcForcedOutageMode muss auf allen Delivery Controllern innerhalb der Zone ausgeführt werden. |
Set-LhcConfigSyncIntervalOverride |
Legt das Intervall fest, in dem der Citrix Config Synchronizer Service (CSS) nach Konfigurationsänderungen innerhalb der Site sucht. Das Zeitintervall kann zwischen 60 Sekunden (einer Minute) und 3600 Sekunden (einer Stunde) liegen. Diese Einstellung gilt nur für den Delivery Controller, auf dem sie ausgeführt wurde. Um Konsistenz über alle Delivery Controller hinweg zu gewährleisten, sollten Sie dieses Cmdlet auf jedem Delivery Controller ausführen. Beispiel: Set-LhcConfigSyncIntervalOverride -Seconds 1200
|
Clear-LhcConfigSyncIntervalOverride |
Legt das Intervall fest, in dem der Citrix Config Synchronizer Service (CSS) nach Konfigurationsänderungen innerhalb der Site sucht, auf den Standardwert von 300 Sekunden (fünf Minuten). Diese Einstellung gilt nur für den Delivery Controller, auf dem sie ausgeführt wurde. Um Konsistenz über alle Delivery Controller hinweg zu gewährleisten, sollten Sie dieses Cmdlet auf jedem Delivery Controller ausführen. |
Enable-LhcHighAvailabilitySDK |
Ermöglicht den Zugriff auf alle Get-Broker* Cmdlets auf dem Delivery Controller, auf dem es ausgeführt wurde. |
Disable-LhcHighAvailabilitySDK |
Deaktiviert den Zugriff auf die Broker-Cmdlets auf dem Delivery Controller, auf dem es ausgeführt wurde. |
Hinweis:
- Verwenden Sie Port 89, wenn Sie die
Get-Broker*Cmdlets auf dem Delivery Controller ausführen. Beispiel:
Get-BrokerMachine -AdminAddress localhost:89- Wenn nicht im LHC-Modus, hält der LHC-Broker auf dem Delivery Controller nur Konfigurationsinformationen vor.
- Im LHC-Modus hält der LHC-Broker auf dem gewählten Delivery Controller die folgenden Informationen vor:
- Ressourcenzustände
- Sitzungsdetails
- VDA-Registrierungen
- Konfigurationsinformationen