Lokaler Hostcache
Um sicherzustellen, dass die Citrix Virtual Apps and Desktops-Sitedatenbank immer verfügbar ist, empfiehlt Citrix, unter Befolgung der bewährten Methoden zur hohen Verfügbarkeit von Microsoft mit einer fehlertoleranten SQL Server-Bereitstellung zu beginnen. (Eine Liste der unterstützten SQL Server-Features für hohe Verfügbarkeit finden Sie unter Datenbanken.) Aufgrund von Netzwerkproblemen und Unterbrechungen können Benutzer jedoch evtl. keine Verbindung mit ihren Anwendungen oder Desktops herstellen.
Der lokale Hostcache ermöglicht bei einem Systemausfall das fortgesetzte Verbindungsbrokering in einer Site. Es kommt zu einem Ausfall, wenn ein Fehler bei der Verbindung zwischen einem Delivery Controller und der Sitedatenbank in einer On-Premises-Citrix Umgebung auftritt Der lokale Hostcache wird aktiviert, wenn die Sitekonfigurationsdatenbank für 90 Sekunden nicht verfügbar ist.
Ab XenApp und XenDesktop 7.16 gibt es das Feature “Verbindungsleasing” (eine Vorgängerfunktion für hohe Verfügbarkeit) nicht mehr.
Dateninhalt
Der lokale Hostcache enthält folgende Informationen (die eine Teilmenge der Informationen in der Hauptdatenbank sind):
- Identität der Benutzer und Gruppen, denen Rechte für die in der Site veröffentlichte Ressourcen zugewiesen wurden.
- Identität der Benutzer, die Ressourcen der Site gerade verwenden oder kürzlich verwendet haben.
- Identität von VDA-Maschinen (einschließlich Remote-PC-Zugriffsmaschinen), die in der Site konfiguriert sind.
- Identität (Name und IP-Adresse) von Citrix Receiver-Clientmaschinen, die aktiv für die Verbindung mit veröffentlichten Ressourcen verwendet werden.
Er enthält außerdem Informationen zu aktiven Verbindungen, die eingerichtet wurden, während die Hauptdatenbank nicht verfügbar war:
- Ergebnisse jeglicher von Citrix Receiver durchgeführten Clientmaschinen-Endpunktanalyse.
- Identität von Infrastrukturmaschinen (z. B. NetScaler Gateway- und StoreFront-Server), die mit der Site zu tun haben.
- Datum und Uhrzeit und Art kürzlich erfolgter Aktivitäten von Benutzern.
Funktionsweise
Die folgende Abbildung zeigt die Komponenten des lokalen Hostcaches und die im Normalbetrieb verwendeten Kommunikationspfade:
Normalbetrieb
- Der principal broker (auch “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
- Citrix Config Sync-Dienst (CSS) überprüft ungefähr jede Minute bei dem Broker, ob Änderungen vorgenommen wurden. Änderungen können von einem Administrator (z. B. Ändern der Eigenschaft einer Bereitstellungsgruppe) oder durch Systemaktionen (z. B. Maschinenzuweisungen) hervorgerufen werden.
-
Wenn seit der letzten Überprüfung eine Konfigurationsänderung stattgefunden hat, synchronisiert (kopiert) der CSS die Informationen auf einen sekundären Broker auf dem Controller. (Der sekundäre Broker wird auch als “Dienst für hohe Verfügbarkeit” bezeichnet.)
Dabei werden nicht nur die seit der letzten Prüfung geänderten Elemente, sondern alle Konfigurationsdaten kopiert. Der CSS importiert die Konfigurationsdaten in eine Microsoft SQL Server Express-LocalDB-Datenbank auf dem Controller. Diese Datenbank wird als lokale Hostcachedatenbank bezeichnet. Der CSS stellt sicher, dass die Informationen in der lokalen Hostcachedatenbank des sekundären Brokers mit den Informationen in der Sitedatenbank übereinstimmen. Die lokale Hostcachedatenbank wird bei jeder Synchronisierung neu erstellt.
SQL Server Express LocalDB zur Verwendung mit dem lokalen Hostcache wird automatisch installiert, wenn Sie einen Controller installieren. (Sie können diese Installation unterbinden, wenn Sie einen Controller über die Befehlszeile installieren.) Die lokale Hostcachedatenbank kann nicht für mehrere Controller freigegeben werden. Sie müssen die lokale Hostcachedatenbank nicht sichern. Sie wird jedes Mal neu erstellt, wenn eine Konfigurationsänderung erkannt wird.
- Wenn seit der letzten Prüfung keine Änderungen erfolgt sind, werden keine Daten kopiert.
Die folgende Abbildung zeigt die Änderungen an den Kommunikationspfaden, wenn der Hauptbroker die Verbindung mit der Sitedatenbank verliert (d. h. zu Beginn eines Ausfalls).
Bei einem Ausfall
Wenn ein Ausfall beginnt:
- Der sekundäre Broker beginnt auf Verbindungsanforderungen zu prüfen und diese zu verarbeiten.
- Bei Ausfallbeginn hat der sekundäre Broker keine aktuellen VDA-Registrierungsdaten, doch wenn ein VDA mit ihm kommuniziert, wird eine Registrierung ausgelöst. Während dieses Vorgangs erhält der sekundäre Broker auch aktuelle Sitzungsinformationen zu dem betreffenden VDA.
- Während der sekundäre Broker Verbindungen verarbeitet, überwacht der Brokerprinzipal weiterhin die Verbindung. Wenn die Verbindung wiederhergestellt ist, weist der Brokerprinzipal den sekundären Broker an, die Prüfung auf Verbindungsinformationen einzustellen, und nimmt das Verbindungsbrokering wieder auf. Wenn ein VDA das nächste Mal mit dem Brokerprinzipal kommuniziert, wird eine Neuregistrierung ausgelöst. Der sekundäre Broker entfernt alle verbleibenden VDA-Registrierungen aus dem vorherigen Ausfall. Der CSS nimmt die Synchronisierung von Informationen wieder auf, wenn er Konfigurationsänderungen in der Bereitstellung erkennt.
Im 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 über Synchronisierungen und Ausfälle.
Es gibt keine zeitliche Begrenzung für den Betrieb in Ausfallmodus.
Der Wechsel zwischen dem normalen und dem Ausfallmodus wirkt sich nicht auf bestehende Sitzungen aus. Er wirkt sich nur auf den Start neuer Sitzungen aus.
Sie können einen Ausfall auch absichtlich auslösen. Informationen zu Zweck und Vorgehensweise finden Sie unter Erzwingen eines Ausfalls.
Sites mit mehreren Controllern
Unter anderem hat der CSS die Aufgabe, den sekundären Broker regelmäßig mit Informationen zu allen Controllern in der Zone zu versorgen. (Enthält Ihre Bereitstellung nicht mehrere Zonen, wirkt sich diese Aktion auf alle Controller in der Site aus.) Anhand dieser Informationen ist jeder sekundäre Broker über sekundäre Peerbroker, die auf anderen Controllern in der Zone ausgeführt werden, informiert.
Die sekundären Broker kommunizieren miteinander über einen anderen Kanal. Anhand einer alphabetischen Liste der FQDNs der Maschinen, auf denen sie ausgeführt werden, ermitteln (wählen) diese Broker, welcher sekundäre Broker bei einem Ausfall das Brokering in der Zone übernimmt. Bei einem Ausfall registrieren sich alle VDAs bei dem gewählten sekundären Broker. Die nicht gewählten sekundären Broker in der Zone weisen eingehende Verbindungs- und VDA-Registrierungsanfragen aktiv ab.
Wenn ein gewählter sekundärer Broker während eines Ausfalls selbst ausfällt, wird stattdessen ein anderer sekundärer Broker gewählt und die VDAs registrieren sich bei diesem.
Wird bei einem Ausfall ein Controller neu gestartet, passiert Folgendes:
- Handelt es sich bei dem Controller nicht um den gewählten Broker, hat der Neustart keine Auswirkungen.
- Handelt es sich um den gewählten Broker, wird ein anderer Controller gewählt und somit werden die VDAs registriert. Wenn der Neustart des Controllers beendet ist, übernimmt er automatisch das Brokering und somit werden die VDAs erneut registriert. In diesem Szenario kann es während der Registrierungen zu Leistungseinbußen kommen.
Wenn Sie einen Controller während des normalen Betriebs ausschalten und dann während eines Ausfalls einschalten, kann der lokale Hostcache auf diesem Controller nicht verwendet werden, wenn dieser als Broker ausgewählt wurde.
Die Ereignisprotokolle enthalten Informationen zu diesen Wahlen.
Während eines Ausfalls nicht verfügbare Elemente und weitere Unterschiede
Es gibt keine zeitliche Begrenzung für den Betrieb in Ausfallmodus. Citrix empfiehlt jedoch, die Verbindung so schnell wie möglich wiederherzustellen.
Bei einem Ausfall:
- Sie können Studio nicht verwenden.
-
Sie haben eingeschränkten Zugriff auf das PowerShell-SDK.
- Sie müssen zuerst Folgendes tun:
- Fügen Sie einen Registrierungsschlüssel
EnableCssTestModemit dem Wert 1 hinzu:New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1 - Verwenden Sie Port 89:
Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
- Fügen Sie einen Registrierungsschlüssel
- Nachdem Sie diese Befehle ausgeführt haben, können Sie auf Folgendes zugreifen:
- Alle
Get-Broker*-Cmdlets. - Die Energieverwaltungs-Cmdlets
New-BrokerHostingPowerAction,Set-BrokerHostingPowerActionundRemove-BrokerHostingPowerAction.
- Alle
- Sie müssen zuerst Folgendes tun:
- Hypervisor-Anmeldeinformationen können nicht vom Hostdienst abgerufen werden. Bei allen Maschinen ist der Energiezustand unbekannt, es können keine Energievorgänge ausgelöst werden. Auf dem Host eingeschaltete VMs können jedoch für Verbindungsanfragen verwendet werden.
- Zugewiesene Maschinen können nur verwendet werden, wenn die Zuweisung während des normalen Betriebs erfolgte. Neue Zuweisungen sind bei einem Ausfall nicht möglich.
- Die automatische Registrierung und Konfiguration von Remote-PC-Zugriff-Maschinen ist nicht möglich. Im normalen Betrieb registrierte und konfigurierte Maschinen können dagegen verwendet werden.
- Benutzer servergehosteter Anwendungen und Desktops können möglicherweise mehr Sitzungen verwenden als das für sie konfigurierte Sitzungslimit zulässt, wenn die Ressourcen in verschiedenen Zonen sind.
- 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. Startvorgänge über Zonen hinweg (von einem sekundären Broker in einer Zone zu einem VDA in einer anderen Zone) werden während eines Ausfalls nicht unterstützt.
- Fällt vor einem geplanten Neustart von VDAs in einer Bereitstellungsgruppe die Sitedatenbank aus, beginnt der Neustart erst nach Ende des Ausfalls. Dies kann zu unbeabsichtigten Ergebnissen führen. Weitere Informationen finden Sie unter Verzögerung geplanter Neustarts aufgrund eines Datenbankausfalls.
- Die Zonenpräferenz kann nicht konfiguriert werden. Eventuell konfigurierte Präferenzen werden für den Sitzungsstart nicht berücksichtigt.
- Tagbeschränkungen, bei denen Tags zur Bezeichnung von Zonen verwendet werden, werden für Sitzungsstarts nicht unterstützt. Wenn solche Tagbeschränkungen konfiguriert sind und die Option Erweiterte Integritätsprüfung eines StoreFront-Stores aktiviert ist, können Sitzungen sporadisch evtl. nicht gestartet werden.
Unterstützung für Anwendungen und Desktops
Der lokale Hostcache unterstützt servergehostete Anwendungen und Desktops und statische (zugewiesene) Desktops.
Der lokale Hostcache unterstützt Desktop-VDAs in gepoolten Bereitstellungsgruppen wie folgt:
-
Standardmäßig werden energieverwaltete Desktop-VDAs in gepoolten (und mit MCS oder Citrix Provisioning erstellten) Bereitstellungsgruppen, für die die Eigenschaft
ShutdownDesktopsAfterUseaktiviert ist, bei einem Ausfall in den Wartungsmodus versetzt. Sie können diese Standardeinstellung ändern, damit solche Desktops während eines Ausfalls verwendet werden können.Während des Ausfalls können Sie sich jedoch nicht auf die Energieverwaltung verlassen. (Die Energieverwaltung wird bei Wiederaufnahme des Normalbetriebs wieder aufgenommen.) Solche Desktops können außerdem Daten des vorherigen Benutzers enthalten, weil sie nicht neu gestartet wurden.
-
Um das Standardverhalten außer Kraft zu setzen, müssen Sie es Site-übergreifend für jede betroffene Bereitstellungsgruppe aktivieren. Führen Sie folgende PowerShell-Cmdlets aus:
Siteweit:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $trueFühren Sie den folgenden PowerShell-Befehl für jede betroffene Bereitstellungsgruppe aus:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $trueDas Aktivieren dieses Features für die Site und Bereitstellungsgruppen wirkt sich nicht auf die Funktionsweise der Eigenschaft
ShutdownDesktopsAfterUsewährend des normalen Betriebs aus. Wenn dieses Feature 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 bei Nicht-LHC-Vorgängen vom VDA abmeldet oder der Neustart manuell ausgelöst werden kann.
Wichtig:
Ohne die Aktivierung von ReuseMachinesWithoutShutdownInOutageAllowed auf Siteebene und ReuseMachinesWithoutShutdownInOutage auf Bereitstellungsgruppenebene schlagen alle Sitzungsstartversuche für energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen während eines lokalen Hostcache-Ereignisses fehl.
RAM-Größe
Der LocalDB-Dienst kann ca. 1,2 GB RAM belegen (bis zu 1 GB für den Datenbankcache plus 200 MB für das Ausführen von SQL Server Express LocalDB). Der sekundäre Broker kann bis zu 1 GB RAM belegen, wenn ein Ausfall länger andauert und viele Anmeldungen erfolgen (z. B. 12 Stunden mit 10.000 Benutzern). Diese Speicheranforderungen verstehen sich zusätzlich zu den normalen RAM-Anforderungen des Controllers, d. h. Sie müssen möglicherweise die RAM-Kapazität erhöhen.
Wenn Sie SQL Server Express für die Sitedatenbank verwenden, gibt es zwei sqlserver.exe-Prozesse.
CPU-Kern- und Socketkonfiguration
Die CPU-Konfiguration eines Controllers, insbesondere die Zahl der für die SQL Server Express-LocalDB verfügbaren Kerne, wirkt sich direkt und in einem noch höheren Maß als die Speicherbelegung auf die Leistung des lokalen Hostcaches aus. Der CPU-Mehraufwand tritt nur während eines Ausfalls auf, wenn die Datenbank nicht erreichbar und der sekundäre Broker aktiv ist.
Die LocalDB kann zwar bis zu 4 Kerne verwenden, ist aber auf ein einziges Socket beschränkt. Durch Hinzufügen weiterer Sockets (z. B. mit 4 Sockets mit je 1 Kern) lässt sich die Leistung nicht verbessern. Stattdessen empfiehlt Citrix die Verwendung von mehreren Sockets mit mehreren Kernen. Bei von Citrix durchgeführten Tests lieferte eine 2x3-Konfiguration (2 Sockets, 3 Kerne) eine bessere Leistung als eine 4x1- oder 6x1-Konfiguration.
Speicher
Wenn Benutzer bei einem Ausfall auf Ressourcen zugreifen, wächst die LocalDB. Bei einem An-/Abmeldetest mit 10 Anmeldungen pro Sekunde vergrößerte sich die Datenbank beispielsweise alle 2 bis 3 Minuten um 1 MB. Bei Wiederaufnahme des Normalbetriebs wird die lokale Datenbank neu erstellt und der Speicherplatz wieder zurückgegeben. Auf dem Laufwerk, auf dem die LocalDB installiert ist, muss ausreichend Speicherplatz für das Wachstum der Datenbank vorhanden sein. Beim lokalen Hostcache erfolgen während eines Ausfalls außerdem weitere E/A-Vorgänge: ca. 3 MB Schreibvorgänge pro Sekunde bei mehreren Hunderttausend Lesevorgängen.
Leistung
Bei einem Ausfall verarbeitet ein sekundärer Broker alle Verbindungen. In Sites (oder Zonen) mit Lastausgleich zwischen mehreren Controllern muss der sekundäre Broker daher möglicherweise viel mehr Anfragen verarbeiten als im Normalbetrieb. Die CPU-Anforderungen sind somit höher. Jeder sekundäre Broker in der Site (Zone) muss in der Lage sein, die zusätzliche, von der lokalen Hostcachedatenbank und allen betroffenen VDAs verursachte Last zu verarbeiten, da der sekundäre Broker bei einem Ausfall wechseln kann.
VDI-Grenzwerte:
- In einer einzonigen VDI-Bereitstellung können während eines Ausfalls bis zu 10.000 VDAS effektiv bewältigt werden.
- In einer VDI-Bereitstellung mit mehreren Zonen können bis zu 10.000 VDAs pro Zone und insgesamt bis zu 40.000 VDAs pro Site gehandhabt werden. Beispielsweise ist ein effektives Handling der folgenden Sites während eines Ausfalls möglich:
- Eine Site mit vier Zonen mit je 10.000 VDAs
- Eine Site mit sieben Zonen, von denen eine 10.000 VDAs enthält und die restlichen sechs je 5.000 VDAs
Bei einem Ausfall kann die Lastverwaltung der Site beeinträchtigt werden. Lastauswertungsprogramme (und insbesondere Sitzungszahlregeln) werden möglicherweise überschritten.
Während der Zeit, die für die Registrierung aller VDAs bei einem sekundären Broker benötigt wird, hat der Dienst evtl. nicht alle Informationen über die aktuellen Sitzungen. Die Verbindungsanfrage eines Benutzers kann während dieses Zeitraums daher zum Start einer neuen Sitzung führen, obwohl eine Wiederverbindung mit einer vorhandenen Sitzung möglich wäre. Dieses Intervall (des Abrufs von Sitzungsinformationen bei allen VDAs durch den “neuen” sekundären Broker) ist unvermeidlich. Auf Sitzungen, die bei Ausfallbeginn verbunden waren, hat das Übergangsintervall keine Auswirkungen, doch bei neuen Sitzungen und erneuten Sitzungsverbindungen ist eine Beeinträchtigung möglich.
Das Intervall tritt immer dann auf, wenn die VDAs sich registrieren müssen:
- Ausfallbeginn: bei der Migration von einem Hauptbroker zu einem sekundären Broker
- Fehler am sekundären Broker während eines Ausfalls: bei der Migration von dem fehlerhaften sekundären Broker zu dem neu gewählten sekundären Broker
- Wiederherstellung nach Ausfall: bei Wiederaufnahme des Normalbetriebs und der erneuten Übernahme der Steuerung durch den Hauptbroker
Sie können das Intervall verringern, indem Sie den Registrierungswert HeartbeatPeriodMs für Citrix Broker Protocol verringern (Standardwert = 600000 ms, d. h. 10 Minuten). Dieser Taktwert ist doppelt so lang wie das Intervall, das der VDA für Pings verwendet. Der Standardwert führt zu einem Ping alle 5 Minuten.
Mit dem folgenden Befehl ändern Sie beispielsweise den Heartbeat auf fünf Minuten (300.000 Millisekunden), was alle 2,5 Minuten zu einem Ping führt:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
Seien Sie vorsichtig, wenn Sie den Heartbeatwert ändern. Eine Erhöhung führt zu einer größeren Last auf den Controllern im normalen und im Ausfallmodus.
Das Intervall kann nicht vollständig eliminiert werden, egal wie schnell die VDAs registrieren.
Die Dauer der Synchronisierung zwischen den sekundären Brokern erhöht sich mit steigender Anzahl der Objekte (VDAs, Anwendungen, Gruppen usw.). Die Synchronisierung von 5000 VDAs kann beispielsweise 10 Minuten oder länger dauern.
Unterschiede zu XenApp 6.x-Versionen
Die neue Implementierung des lokalen Hostcache hat zwar denselben Namen wie ein Feature in XenApp-Releases bis 6.x, weist jedoch einige wichtige Verbesserungen auf. Diese Implementierung ist robuster und beschädigungsresistent. Die Wartungsanforderungen wurden auf ein Minimum begrenzt (z. B. sind keine regelmäßigen dsmaint-Befehle mehr erforderlich). Der neue lokale Hostcache ist technisch völlig anders implementiert.
Verwalten des lokalen Hostcache
Damit der lokale Hostcache ordnungsgemäß funktioniert, muss die PowerShell-Ausführungsrichtlinie für jeden Controller auf “RemoteSigned”, “Unrestricted” oder “Bypass” festgelegt sein.
SQL Server Express-LocalDB
Die vom lokalen Hostcache verwendete Microsoft SQL Server Express-LocalDB wird automatisch installiert, wenn Sie einen Controller installieren oder von einer Version vor 7.9 aktualisieren. Nur der sekundäre Broker kommuniziert mit dieser Datenbank. Sie können PowerShell-Cmdlets nicht verwenden, um Änderungen an dieser Datenbank vorzunehmen. Die LocalDB kann nicht für mehrere Controller freigegeben werden.
Die Datenbanksoftware der SQL Server Express-LocalDB wird unabhängig davon installiert, ob der lokale Hostcache aktiviert wird.
Um die Installation zu verhindern, installieren bzw. aktualisieren Sie den Controller mit dem Befehl XenDesktopServerSetup.exe und verwenden die Option /exclude "Local Host Cache Storage (LocalDB)". Der lokale Hostcache funktioniert allerdings nicht ohne die Datenbank und Sie können keine andere Datenbank für den sekundären Broker verwenden.
Die Installation der LocalDB-Datenbank ist irrelevant für die Entscheidung, ob Sie SQL Server Express zur Verwendung als Sitedatenbank installieren.
Informationen zum Ersetzen einer älteren Version von SQL Server Express LocalDB durch eine neuere finden Sie unter Ersetzen von SQL Server Express LocalDB.
Standardeinstellungen nach Installation bzw. Upgrade des Produkts
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 lokale Hostcache aktiviert, wenn die Bereitstellung insgesamt weniger als 10.000 VDAs umfasst.
Aktivieren und Deaktivieren des lokalen Hostcaches
-
Zum Aktivieren des lokalen Hostcache geben Sie Folgendes ein:
Set-BrokerSite -LocalHostCacheEnabled $trueUm zu ermitteln, ob der lokale Hostcache aktiviert ist, geben Sie Folgendes ein:
Get-BrokerSite. Überprüfen Sie, ob die EigenschaftLocalHostCacheEnabledaufTruegesetzt ist. -
Zum Deaktivieren des lokalen Hostcache geben Sie Folgendes ein:
Set-BrokerSite -LocalHostCacheEnabled $false
Ab XenApp und XenDesktop 7.16 gibt es das Verbindungsleasing (Vorgängerfeature des lokalen Hostcache ab Version 7.6) nicht mehr.
Funktionsprüfung des lokalen Hostcache
Überprüfung des lokalen Hostcache auf korrekte Einrichtung und fehlerfreien Betrieb:
- Vergewissern Sie sich, dass Synchronisierungsimporte erfolgreich abgeschlossen werden. Überprüfen Sie die Ereignisprotokolle.
- Vergewissern Sie sich, dass die LocalDB von SQL Server Express auf jedem Delivery Controller erstellt wurde. Dadurch wird bestätigt, dass der sekundäre Broker bei Bedarf übernehmen kann.
- Gehen Sie auf dem Delivery Controller-Server zu
C:\Windows\ServiceProfiles\NetworkService. - Überprüfen Sie, ob
HaDatabaseName.mdfundHaDatabaseName_log.ldferstellt wurden.
- Gehen Sie auf dem Delivery Controller-Server zu
- Erzwingen Sie einen Ausfall bei den Delivery Controllern. Vergessen Sie nicht, nach der Funktionsprüfung des lokalen Hostcache alle Controller wieder in den normalen Modus zu versetzen. Dies kann ungefähr 15 Minuten dauern.
Ereignisprotokolle
Ereignisprotokolle enthalten Informationen zu Synchronisierungen und Ausfällen. In Ereignisanzeige-Protokollen wird der Ausfallmodus als HA modebezeichnet.*
Config Synchronizer Service:
Im Normalbetrieb können die folgenden Ereignisse auftreten, wenn der CSS die Konfigurationsdaten mit dem lokalen Hostcachebrokers in die lokale Hostcachedatenbank importiert.
- 503: Der Citrix Config Sync-Dienst erhielt eine aktualisierte Konfiguration. Das Ereignis zeigt den Beginn des Synchronisationsprozesses an.
- 504: Der Citrix Config Sync-Dienst hat eine aktualisierte Konfiguration importiert. Der Konfigurationsimport wurde erfolgreich abgeschlossen.
- 505: Fehler bei einem Import in den Citrix Config Sync-Dienst. Der Konfigurationsimport wurde nicht erfolgreich abgeschlossen. Wenn eine frühere, erfolgreich importierte Konfiguration verfügbar ist, wird diese bei einem Ausfall verwendet. Sie ist jedoch im Vergleich zur aktuellen Konfiguration veraltet. Wenn keine vorherige Konfiguration vorliegt, kann sich der Dienst bei einem Ausfall nicht an der Sitzungsvermittlung beteiligen. Lesen Sie in diesem Fall den Abschnitt Fehlerbehebung und wenden Sie sich an den Citrix Support.
- 507: Der Citrix Config Sync Service hat einen Importvorgang abgebrochen, weil ein Systemausfall vorliegt und der lokale Hostcachebroker für die Vermittlung verwendet wird. Der Dienst hat eine neue Konfiguration erhalten, der Import wurde jedoch abgebrochen, da ein Ausfall aufgetreten ist. Dieses Verhalten wird erwartet.
- 510: Es wurden keine Konfigurationsdienst-Konfigurationsdaten vom primären Konfigurationsdienst empfangen.
- 517: Ein Problem ist bei der Kommunikation mit dem primären Broker aufgetreten.
- 518: Das Config Sync-Skript wurde abgebrochen, weil der sekundäre Broker (Hohe Verfügbarkeit) nicht ausgeführt wird.
Dienst für hohe Verfügbarkeit:
Dieser Dienst wird auch als lokaler Hostcachebroker bezeichnet.
- 3502: Ein Ausfall ist aufgetreten und der lokale Hostcachebroker führt Brokervorgänge durch.
- 3503: Ein Ausfall wurde behandelt und der Normalbetrieb wieder aufgenommen.
- 3504: Gibt an, welcher lokale Hostcachebroker gewählt wurde und welche anderen lokalen Hostcachebroker bei der Wahl beteiligt waren.
- 3507: Stellt alle 2 Minuten eine Statusaktualisierung des lokalen Hostcache bereit, die angibt, dass der Modus “Lokaler Hostcache” auf dem ausgewählten Broker aktiv ist. Enthält eine Zusammenfassung des Ausfalls, einschließlich Ausfalldauer, VDA-Registrierung und Sitzungsinformationen.
- 3508: Gibt an, dass der lokale Hostcache auf dem ausgewählten Broker nicht mehr aktiv ist und dass der normale Betrieb wiederhergestellt wurde. Enthält eine Zusammenfassung des Ausfalls, einschließlich Ausfalldauer, Anzahl der Maschinen, die während des lokalen Hostcache-Ereignisses registriert wurden, und der Anzahl erfolgreicher Starts während des lokalen Hostcache-Ereignisses.
- 3509: Gibt an, dass der lokale Hostcache auf dem bzw. den nicht ausgewählten Broker(n) aktiv ist. Liefert alle 2 Minuten Angaben zur Ausfalldauer und gibt den ausgewählten Broker an.
- 3510: Gibt an, dass der lokale Hostcache auf dem bzw. den nicht ausgewählten Broker(n) nicht mehr aktiv ist. Enthält die Ausfalldauer und gibt den ausgewählten Broker an.
Erzwingen eines Ausfalls
In folgenden Situationen kann das Erzwingen eines Ausfalls erforderlich sein:
- Die Netzwerkverbindung wird wiederholt unterbrochen. Durch das Erzwingen eines Ausfalls bis zum Beheben des Netzwerkproblems werden fortlaufende Übergänge zwischen normalem Modus und Ausfallmodus (und somit häufige VDA-Registrierungen) vermieden.
- Zum Testen eines Notfallwiederherstellungsplans
- Zur Prüfung des ordnungsgemäßen Betriebs des lokalen Hostcache
- Beim Ersetzen oder Warten des Sitedatenbankservers
Zum Erzwingen eines Ausfalls bearbeiten Sie die Registrierung aller Server, die einen Delivery Controller enthalten. Erstellen Sie für HKLM\Software\Citrix\DesktopServer\LHC OutageModeForced und legen Sie REG_DWORD auf 1 fest. Durch diese Einstellung wird der lokale Hostcachebroker angewiesen, unabhängig vom Zustand der Datenbank in den Ausfallmodus zu wechseln. Wenn Sie den Wert auf 0 festlegen, wird der Ausfallmodus auf dem lokalen Hostcachebroker beendet.
Überprüfen Sie die Ereignisse in der Protokolldatei Current_HighAvailabilityService in C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.
Problembehandlung
Mehrere Problembehandlungstools sind verfügbar, wenn ein Synchronisierungsimport in die lokale Hostcachedatenbank fehlschlägt und ein 505-Ereignis verzeichnet wird.
Ablaufverfolgung mit CDF: Enthält Optionen für die Module ConfigSyncServer und BrokerLHC. In Kombination mit anderen Brokermodulen kann mit diesen Optionen das Problem in der Regel identifiziert werden.
Bericht: Wenn ein Synchronisierungsimport fehlschlägt, können Sie einen Bericht erstellen. Der Bericht endet mit dem Objekt, das den Fehler verursacht hat. Das Berichtsfeature wirkt sich auf die Synchronisierungsgeschwindigkeit aus. Deshalb empfiehlt Citrix, es zu deaktivieren, wenn es nicht verwendet wird.
Zum Aktivieren von CSS und Erstellen eines Ablaufverfolgungsberichts geben Sie 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.
Wenn der Bericht generiert wurde, deaktivieren Sie das Berichtsfeature durch Eingabe des folgenden Befehls:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
Exportieren der Brokerkonfiguration: stellt die exakte Konfiguration zum Debuggen zur Verfügung.
Export-BrokerConfiguration | Out-File <file-pathname>
Beispiel: Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.