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 (LHC) 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 Hauptbroker (Citrix Brokerdienst) auf einem Controller akzeptiert Verbindungsanfragen von StoreFront und kommuniziert zur Verbindung zwischen beim Controller registrierten Benutzern und VDAs mit der Sitedatenbank.
- In regelmäßigen Abständen (eine Minute nach Abschluss der vorherigen Prüfung) wird die Konfiguration des Hauptbrokers auf Änderungen geprüft. Änderungen können von PowerShell-/Studio-Aktionen (z. B. Ändern der Eigenschaft einer Bereitstellungsgruppe) oder Systemaktionen (z. B. Maschinenzuweisungen) hervorgerufen werden.
- Wenn seit der letzten Prüfung eine Änderung gemacht wurde, synchronisiert (d. h. kopiert) CSS (Citrix Config Sync-Dienst) die Informationen an CAS (Citrix Dienst für hohe Verfügbarkeit) auf dem Controller. (In einigen Teilen der Dokumentation wird der Dienst für hohe Verfügbarkeit als “sekundärer Broker” bezeichnet.) Alle Brokerkonfigurationsdaten, nicht nur die seit der letzten Überprüfung geänderten Elemente, werden kopiert. Der Dienst für hohe Verfügbarkeit importiert die Daten in eine Microsoft SQL Server Express-LocalDB-Datenbank auf dem Controller. Der CSS stellt sicher, dass die Informationen in dieser Datenbank mit den Informationen in der Sitedatenbank übereinstimmen. Die LocalDB-Datenbank wird bei jeder Synchronisierung neu erstellt.
- 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).
Wenn ein Ausfall beginnt:
- Der Hauptbroker kann nicht mehr mit der Sitedatenbank kommunizieren und beendet das Lauschen auf StoreFront- und VDA-Informationen (X in der Abbildung). Der Hauptbroker weist dann den Dienst für hohe Verfügbarkeit an, auf Verbindungsanforderungen zu lauschen und diese zu verarbeiten (rote gestrichelte Linie in der Abbildung). Der Dienst für hohe Verfügbarkeit verwirft alle Anrufe vom CSS ab.
- Bei Ausfallbeginn hat der Dienst für hohe Verfügbarkeit keine aktuellen VDA-Registrierungsdaten, aber sobald der VDA mit ihm kommuniziert, wird eine Neuregistrierung ausgelöst. Während dieses Vorgangs erhält der Dienst für hohe Verfügbarkeit auch aktuelle Sitzungsinformationen zu dem betreffenden VDA.
- Während der Dienst für hohe Verfügbarkeit Verbindungen verarbeitet, überwacht der Hauptbroker weiterhin die Verbindung mit der Sitedatenbank. Wenn die Verbindung wiederhergestellt ist, weist der Hauptbroker den Dienst für hohe Verfügbarkeit an, das Lauschen auf Verbindungsinformationen einzustellen, und nimmt das Verbindungsbrokering wieder auf. Wenn ein VDA das nächste Mal mit dem Hauptbroker kommuniziert, wird eine Neuregistrierung ausgelöst. Der Dienst für hohe Verfügbarkeit entfernt alle verbleibenden VDA-Registrierungen aus dem vorherigen Ausfall und aktualisiert wieder die LocalDB-Datenbank mit den vom CSS empfangenen Konfigurationsänderungen.
Der Wechsel zwischen dem normalen und dem Ausfallmodus wirkt sich nicht auf bestehende Sitzungen aus, sondern nur auf den Start neuer Sitzungen.
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. Weitere Informationen finden Sie unter “Überwachen” weiter unten.
Sie können einen Ausfall auch absichtlich auslösen. Informationen dazu, wozu dies dient und wie Sie dabei vorgehen finden Sie im Abschnitt “Erzwingen eines Ausfalls” weiter unten.
Sites mit mehreren Controllern
Unter anderem hat der CSS die Aufgabe, den Dienst für hohe Verfügbarkeit 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 Dienst für hohe Verfügbarkeit über alle anderen Dienste für hohe Verfügbarkeit informiert.
Die Dienste für hohe Verfügbarkeit kommunizieren miteinander über einen anderen Kanal. Anhand einer alphabetischen Liste der FQDNs der Maschinen, auf denen sie ausgeführt werden, ermitteln (wählen) sie, welcher Dienst für hohe Verfügbarkeit bei einem Ausfall das Brokering in der Zone übernimmt. Bei einem Ausfall registrieren sich alle VDAs bei dem gewählten Dienst für hohe Verfügbarkeit neu. Die nicht gewählten Dienste für hohe Verfügbarkeit in der Zone weisen eingehende Verbindungs- und VDA-Registrierungsanfragen aktiv ab.
Wenn ein gewählter Dienst für hohe Verfügbarkeit während eines Ausfalls ausfällt, wird ein anderer Dienst zur Übernahme ausgewä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 primären Broker, hat der Neustart keine Auswirkungen.
- Handelt es sich um den gewählten primären Broker, wird ein anderer Controller gewählt und somit werden die VDAs neu registriert. Wenn der Neustart des Controllers beendet ist, übernimmt er automatisch das Brokering und somit werden die VDAs erneut neu registriert. In diesem Szenario kann es während der erneuten Registrierung 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 primärer Broker ausgewählt wurde.
Das Ereignisprotokoll enthält Informationen zu diesen Wahlen. Weitere Informationen finden Sie unter “Überwachen” weiter unten.
Designüberlegungen und -anforderungen
Es gibt keine zeitliche Begrenzung für den Betrieb in Ausfallmodus. Allerdings sollten Sie den Normalbetrieb so schnell wie möglich wiederherstellen.
Während eines Ausfalls nicht verfügbare Elemente und weitere Unterschiede
- Sie können Studio nicht verwenden und keine PowerShell-Cmdlets ausführen.
- 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 Dienst für hohe Verfügbarkeit enthält. Startvorgänge über Zonen hinweg (von einem Dienst für hohe Verfügbarkeit 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.
- 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.
Der lokale Hostcache wird für servergehostete Anwendungen und Desktops und statische (zugewiesene) Desktops unterstützt.
Standardmäßig sind energieverwaltete Desktop-VDAs in gepoolten (über MCS oder Citrix Provisioning erstellten) Bereitstellungsgruppen, für die die Eigenschaft ShutdownDesktopsAfterUse aktiviert ist, während eines Ereignisses mit dem lokalen Hostcache nicht für neue Verbindungen verfügbar. Sie können diese Standardeinstellung ändern, damit solche Desktops während des Ereignisses 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:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
Das Aktivieren dieses Features für die Site und Bereitstellungsgruppen wirkt sich nicht auf die Funktionsweise der Eigenschaft “ShutdownDesktopsAfterUse” wä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 Dienst für hohe Verfügbarkeit 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 Dienst für hohe Verfügbarkeit 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 ein 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 zusätzliche E/A-Vorgänge: ca. 3 MB Schreibvorgänge pro Sekunde bei mehreren Hunderttausend Lesevorgängen.
Leistung
Bei einem Ausfall verarbeitet ein einziger Dienst für hohe Verfügbarkeit alle Verbindungen. In Sites (oder Zonen) mit Lastausgleich zwischen mehreren Controllern muss der gewählte Dienst für hohe Verfügbarkeit daher möglicherweise viel mehr Anfragen verarbeiten als im Normalbetrieb. Die CPU-Anforderungen sind somit höher. Jeder einzelne Dienst für hohe Verfügbarkeit in der Site (Zone) muss in der Lage sein, die zusätzliche, von der LocalDB und allen betroffenen VDAs verursachte Last zu verarbeiten, da der gewählte Dienst für hohe Verfügbarkeit 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 Neuregistrierung aller VDAs bei einem Dienst für hohe Verfügbarkeit benötigt wird, hat dieser 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” Dienst für hohe Verfügbarkeit) 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 neu registrieren müssen:
- Ausfallbeginn: bei der Migration von einem Hauptbroker zu einem Dienst für hohe Verfügbarkeit
- Ausfall des Diensts für hohe Verfügbarkeit während eines Ausfalls: Bei der Migration von einem ausgefallenen Dienst für hohe Verfügbarkeit zu einem neu gewählten.
- 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 (Standardwert = 600000 ms, d. h. 10 Minuten) verringern. 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 Diensten für hohe Verfügbarkeit erhöht sich mit steigender Anzahl der Objekte (VDAs, Anwendungen, Gruppen usw.). Die Synchronisierung von 5000 VDAs kann beispielsweise zehn Minuten oder länger dauern. Informationen zu Synchronisierungseinträgen im Ereignisprotokoll finden Sie unter Überwachen.
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. Die LocalDB erfordert keine Wartung durch den Administrator. Nur der Dienst für hohe Verfügbarkeit 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 Sie 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 Dienst für hohe Verfügbarkeit 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 Eigenschaft “LocalHostCacheEnabled” auf “True” festgelegt 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:
- Stellen Sie sicher, dass Synchronisierungsimporte erfolgreich abgeschlossen werden. Überprüfen Sie die Ereignisprotokolle.
- Stellen Sie sicher, dass die LocalDB von SQL Server Express auf jedem Delivery Controller erstellt wurde. Dadurch wird bestätigt, dass der Dienst für hohe Verfügbarkeit bei Bedarf übernehmen kann.
- Navigieren Sie auf dem Delivery Controller-Server zu C:\Windows\ServiceProfiles\NetworkService.
- Überprüfen Sie, ob HaDatabaseName.mdf und HaDatabaseName_log.ldf erstellt wurde.
- 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 ca. 15 Minuten dauern, um eine VDA-Registrierungsflut zu vermeiden.
Erzwingen eines Ausfalls
In folgenden Situationen kann das Erzwingen eines Datenbankausfalls 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 vermieden.
- Zum Testen eines Notfallwiederherstellungsplans
- Beim Ersetzen oder Warten des Sitedatenbankservers
Zum Erzwingen eines Ausfalls bearbeiten Sie die Registrierung aller Server, die einen Delivery Controller enthalten. Legen Sie unter HKLM\Software\Citrix\DesktopServer\LHC OutageModeForced als REG_DWORD auf 1 fest. Dadurch wird der Broker angewiesen, unabhängig vom Zustand der Datenbank in den Ausfallmodus zu wechseln. Wenn Sie den Wert auf 0 festlegen, wird der Ausfallmodus auf dem Server beendet.
Überwachung
Ereignisprotokolle enthalten Informationen zu Synchronisierungen und Ausfällen.
Config Synchronizer Service:
Im Normalbetrieb können beim Kopieren und Exportieren der Brokerkonfiguration durch den CSS und beim Importieren in die LocalDB unter Einsatz des Dienst für hohe Verfügbarkeit die folgenden Ereignisse auftreten.
- 503: Es wurde eine Änderung an der Konfiguration des Hauptbrokers erkannt und ein Import wird gestartet.
- 504: Die Brokerkonfiguration wurde erfolgreich kopiert, exportiert und in die LocalDB importiert.
- 505: Der Import in die LocalDB ist fehlgeschlagen (siehe weiter unten).
- 507: Import wurde aufgrund eines ausstehenden Ausfalls abgebrochen. Wenn ein Ausfall während einer Synchronisierung beginnt, wird der aktuelle Import verworfen und die letzte bekannte Konfiguration verwendet.
- 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:
- 3502: Ein Ausfall ist aufgetreten und der Dienst für hohe Verfügbarkeit hat das Brokering übernommen.
- 3503: Ein Ausfall wurde behandelt und der Normalbetrieb wieder aufgenommen.
- 3504: Gibt an, welcher Dienst für hohe Verfügbarkeit gewählt wurde und welche anderen bei der Wahl beteiligt waren.
Problembehandlung
Mehrere Problembehandlungstools sind verfügbar, wenn ein Synchronisierungsimport in die LocalDB 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: Sie können einen Bericht mit Informationen zu dem Fehlerpunkt erstellen. 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 Folgendes ein:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1
Der HTML-Bericht wird in folgendem Ordner gespeichert: C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html.
Wenn der Bericht generiert wurde, deaktivieren Sie das Berichtsfeature mit folgendem Befehl:
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.