Lokaler Hostcache
Dieser Artikel bietet einen vollständigen Überblick über die Funktion des lokalen Hostcaches (LHC) und konzentriert sich dabei auf dessen Fähigkeit, die Geschäftskontinuität aufrechtzuerhalten. Er erläutert die Funktionalität des LHC sowohl während des normalen Betriebs als auch bei Aktivierung des LHC-Modus. Darüber hinaus bietet der Artikel Anleitungen zu Konfigurationsprüfungen, Fehlerbehebung, PowerShell-Befehlen für die LHC-Verwaltung und der Überwachung des Ereignisprotokolls für die LHC-Integrität.
Überblick
Der LHC gewährleistet den Endbenutzerzugriff auf Apps und Desktops, wenn Cloud Connectors aufgrund einer Netzwerkunterbrechung oder eines Problems mit Citrix Cloud™ die Verbindung zu Citrix Cloud verlieren. Aktive Sitzungen werden bei Aktivierung des LHC-Modus nicht beeinträchtigt, und neue Sitzungen werden über den auf den Cloud Connectors ausgeführten LHC-Broker vermittelt.
Der LHC ist standardmäßig aktiviert, es ist jedoch wichtig sicherzustellen, dass Ihre Umgebung ordnungsgemäß für den LHC konfiguriert ist. Während Fehlkonfigurationen den normalen Brokering-Vorgang möglicherweise nicht stören, können sie die LHC-Leistung beeinträchtigen und bei aktivem LHC-Modus zu Unterbrechungen für Endbenutzer führen. Um eine optimale LHC-Funktionalität zu gewährleisten, überprüfen Sie Ihren Knoten Zones in Studio auf zonenbezogene Fehler und Warnungen, die von Citrix erkannt wurden. Lesen Sie außerdem den Leitfaden Check resiliency configurations und den Artikel Avoid Common Misconfigurations that Can Negatively Impact DaaS Resiliency für eine umfassende Checkliste zur LHC-Konfiguration.
Wichtig:
Der LHC wird nur aktiviert, wenn Cloud Connectors Datenverkehr von StoreFront empfangen oder wenn die Dienstkontinuität aktiviert ist. Weitere Informationen dazu, wie die Dienstkontinuität den lokalen Hostcache nutzen kann, um den Benutzerzugriff auf Apps und Desktops während Dienstunterbrechungen aufrechtzuerhalten, finden Sie unter Dienstkontinuität.
Funktionsweise
Während des normalen Betriebs kommuniziert der Remote Broker Provider Service auf einem Cloud Connector mit Citrix Cloud für alle Brokering-Vorgänge. Der Citrix Config Synchronizer Service (CSS) prüft regelmäßig auf Konfigurationsänderungen in Citrix Cloud und synchronisiert diese Daten mit dem LHC-Broker auf dem Cloud Connector. Wenn Cloud Connectors die Verbindung zu Citrix Cloud verlieren oder Citrix Cloud ein Problem aufweist, wird der LHC-Modus aktiviert und gewährleistet den fortgesetzten Zugriff auf Anwendungen und Desktops.
Während des normalen Brokering-Betriebs
-

- Der Citrix Remote Broker Provider Service auf einem Cloud Connector akzeptiert Verbindungsanfragen von StoreFront. Der Remote Broker Provider Service kommuniziert mit Citrix Cloud, um Benutzer mit VDAs zu verbinden, die bei Citrix Cloud registriert sind.
- Der CSS prüft etwa alle 5 Minuten beim Cloud-Broker in Citrix Cloud, ob Konfigurationsänderungen vorgenommen wurden. Diese Änderungen können vom Administrator initiiert (z. B. Ändern einer Bereitstellungsgruppeneigenschaft) oder Systemaktionen (z. B. Maschinenzuweisungen) sein.
-
Wenn seit der letzten Prüfung eine Konfigurationsänderung aufgetreten ist, synchronisiert der CSS die Informationen mit dem LHC-Broker auf dem Cloud Connector. (Der LHC-Broker wird auch als High Availability Service oder HA-Broker 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 Cloud Connector. 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 Site-Datenbank in Citrix Cloud übereinstimmen.
Microsoft SQL Server Express LocalDB (von der LHC-Datenbank verwendet) wird automatisch installiert, wenn Sie einen Cloud Connector installieren. Die LHC-Datenbank kann nicht über Cloud Connectors hinweg gemeinsam genutzt werden. Sie müssen die LHC-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 die Konfigurationsdaten nicht kopiert.
Wenn der LHC-Modus aktiv wird
-

- Der LHC-Broker beginnt, auf Verbindungsinformationen zu lauschen und Verbindungsanfragen zu verarbeiten.
- Wenn die Cloud Connectors zum ersten Mal die Verbindung zu Citrix Cloud verlieren, verfügt der LHC-Broker nicht über aktuelle VDA-Registrierungsdaten. Wenn jedoch ein VDA mit ihm kommuniziert, wird ein Registrierungsprozess ausgelöst. Während dieses Prozesses erhält der LHC-Broker auch aktuelle Sitzungsinformationen für diesen VDA.
-
Während der LHC-Broker Verbindungen verarbeitet, überwacht der Remote Broker Provider Service weiterhin die Verbindung zu Citrix Cloud. Wenn die Verbindung wiederhergestellt ist, weist der Remote Broker Provider Service den LHC-Broker an, das Lauschen auf Verbindungsinformationen einzustellen, und Citrix Cloud nimmt die Brokering-Vorgänge wieder auf. Wenn ein VDA das nächste Mal über den Remote Broker Provider Service mit Citrix Cloud kommuniziert, wird ein Registrierungsprozess ausgelöst. Der LHC-Broker entfernt alle verbleibenden VDA-Registrierungen aus der Zeit, als der LHC-Modus aktiv war. Der CSS nimmt die Synchronisierung von Informationen wieder auf, sobald er erfährt, dass Konfigurationsänderungen in Citrix Cloud aufgetreten sind.
-
In dem unwahrscheinlichen Fall, dass der LHC während einer Synchronisierung beginnt, wird der aktuelle Import verworfen und die letzte bekannte Konfiguration verwendet.
-
Das Ereignisprotokoll zeigt an, wann Synchronisierungen stattfinden und der LHC-Modus aktiviert wird.
-
Für den Betrieb im LHC-Modus gibt es keine zeitliche Begrenzung.
- Sie können den LHC-Modus auch manuell auslösen. Weitere Informationen dazu, warum und wie dies geschieht, finden Sie unter LHC-Modus erzwingen.
Zonen mit mehreren Cloud Connectors
-
Neben anderen Aufgaben versorgt der CSS den LHC-Broker routinemäßig mit Informationen über alle Cloud Connectors in der Zone. Mit diesen Informationen kennt jeder LHC-Broker alle Peer-LHC-Broker, die auf anderen Cloud Connectors in der Zone ausgeführt werden.
-
Die LHC-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 LHC-Broker die Vorgänge in der Zone vermitteln wird, wenn die Zone in den LHC-Modus wechselt. Während des LHC-Modus registrieren sich alle VDAs erneut beim gewählten LHC-Broker. Die nicht gewählten LHC-Broker in der Zone lehnen eingehende Verbindungs- und VDA-Registrierungsanfragen aktiv ab.
Wichtig:
Konnektoren innerhalb einer Zone müssen unter
http://<FQDN_OF_PEER_CONNECTOR>:80/Citrix/CdsController/ISecondaryBrokerElectionerreichbar sein. Wenn Konnektoren unter dieser Adresse nicht kommunizieren können, werden möglicherweise mehrere Broker gewählt, und es treten Startfehler im LHC-Modus auf.
Im LHC-Modus, wenn ein Cloud Connector neu gestartet wird oder der LHC-Broker ausfällt:
- Wenn dieser Cloud Connector nicht der gewählte LHC-Broker ist, hat der Neustart keine Auswirkungen.
- Wenn dieser Cloud Connector der gewählte LHC-Broker ist, wird der LHC-Broker auf dem nächsten Cloud Connector gewählt, wodurch sich VDAs registrieren. Die Wahlreihenfolge basiert auf der alphabetischen Reihenfolge des FQDN der Cloud Connectors. Sobald der LHC-Broker wieder aktiv ist, werden die LHC-Operationen auf dem ersten Connector in alphabetischer Reihenfolge fortgesetzt, was dazu führen kann, dass sich VDAs erneut registrieren. In diesem Szenario kann die Leistung während der Registrierungen beeinträchtigt werden.
Weitere Informationen zu Ereignissen im Zusammenhang mit LHC-Broker-Wahlen finden Sie unter Ereignisprotokolle.
Lokaler Hostcache-Dateninhalt
Die LHC-Datenbank enthält die folgenden Daten, die eine Untermenge der Daten in der Hauptdatenbank darstellen:
- Identitäten von Benutzern und Gruppen, denen Rechte für von der Site veröffentlichte Ressourcen zugewiesen sind.
- Identitäten von Benutzern, die derzeit oder kürzlich veröffentlichte Ressourcen von der Site verwendet haben.
- Identitäten von VDA-Maschinen (einschließlich Remote-PC-Zugriffsmaschinen), die in der Site konfiguriert sind.
- Identitäten (Namen und IP-Adressen) von Client-Citrix Workspace™-App-Maschinen, die aktiv zum Herstellen einer Verbindung zu veröffentlichten Ressourcen verwendet werden.
Sie enthält auch die folgenden Informationen für aktuell aktive Verbindungen, die im LHC-Modus hergestellt wurden:
- Ergebnisse jeder Client-Maschinen-Endpunktanalyse, die von der Citrix Workspace-App durchgeführt wurde.
- Identitäten von Infrastrukturmaschinen (wie Citrix Gateway- und StoreFront-Servern), die an der Site beteiligt sind.
- Datum, Uhrzeit und Art der letzten Aktivitäten von Benutzern
Lokaler Hostcache-Zustände
Es gibt mehrere Zustände während des gesamten Zyklus des Eintritts und Austritts aus dem LHC-Modus. Das folgende Diagramm beschreibt die Zustände für den Eintritt und Austritt aus dem LHC-Modus.

- Im Zustand Normaler Betrieb sind alle Komponenten fehlerfrei, und alle Brokering-Transaktionen werden vom Cloud-Broker abgewickelt. - - Der CSS repliziert aktiv die Konfigurationen vom Cloud-Broker auf die Cloud Connectors.
Wenn Integritätsprüfungen fehlschlagen, wechseln die Cloud Connectors in den Zustand HA ausstehend. In diesem Zustand wird eine umfassende Integritätsprüfung eingeleitet, um die nächsten Schritte zu bestimmen. Die Konnektoren interagieren mit anderen Konnektoren in der Zone, um deren Integritätsstatus zu ermitteln.
- Die Entscheidung, von **HA ausstehend** zu **Initial HA** zu wechseln, basiert auf dem Integritätsstatus aller Konnektoren in einer bestimmten Zone. Wenn die Integritätsprüfungen erfolgreich sind, wechseln die Konnektoren/Controller zurück in den Zustand **Normaler Betrieb**. Alternativ, wenn die Integritätsprüfungen weiterhin fehlschlagen, wechseln die Konnektoren/Controller in den Zustand **Initial HA**.
- Im Zustand **Initial HA** übernimmt der LHC-Broker auf dem gewählten Konnektor die Brokering-Verantwortlichkeiten. Alle VDAs in der aktuellen Zone, die zuvor registriert waren, registrieren sich nun beim LHC-Broker auf dem Cloud Connector. Es kann bis zu 5 Minuten dauern, bis sich alle VDAs beim HA-Dienst neu registriert haben. Am Ende von **Initial HA** werden Integritätsprüfungen eingeleitet. Wenn alle Integritätsprüfungen erfolgreich sind, wechselt der Zustand zu **Wiederherstellung ausstehend**, andernfalls wechselt der Zustand zu **Erweitertes HA**.
- Integritätsprüfungen finden während des Zeitraums von **Erweitertes HA** weiterhin statt. Wenn Integritätsprüfungen während des **Erweitertes HA** erfolgreich sind, wechselt der Zustand zu **Wiederherstellung ausstehend**. Es gibt keine maximale Dauer, für die ein Konnektor im Zustand **Erweitertes HA** verbleiben kann.
- **Wiederherstellung ausstehend** dient als Pufferzeitraum, um sicherzustellen, dass die Dienste vollständig fehlerfrei sind, bevor der Übergang aus dem LHC-Modus erfolgt. Wenn eine der Integritätsprüfungen während **Wiederherstellung ausstehend** fehlschlägt, wechselt der Zustand zurück zu **Erweitertes HA**.
- Wenn alle Integritätsprüfungen während des gesamten 10-minütigen Zeitraums von **Wiederherstellung ausstehend** erfolgreich sind, wechselt der Zustand zu **Normaler Betrieb**. Mit diesem Übergang endet der LHC-Modus, und alle VDAs in der Zone, die beim LHC-Broker registriert waren, registrieren sich nun beim Cloud-Broker neu. Diese erneute Registrierung kann wiederum bis zu 5 Minuten dauern.
Wichtige Überlegungen im LHC-Modus
Beachten Sie im LHC-Modus die folgenden Auswirkungen:
| Aspekt | Auswirkung im LHC-Modus |
|---|---|
| Studio-Zugriff | Kann je nach Art der Störung unzugänglich sein. VDAs in Zonen, die im LHC-Modus betrieben werden, werden in Studio als Nicht registriert angezeigt, da sie beim LHC-Broker registriert sind. |
| Remote PowerShell SDK-Zugriff
|
Eingeschränkter Zugriff.
SDK-Authentifizierung festlegen: Führen Sie Get-XDAuthentication -ProfileName WindowsCurrentUser aus, um zu verhindern, dass der SDK-Proxy Cmdlet-Aufrufe umleitet. Nach diesen Änderungen können Sie alle Get-Broker-Cmdlets verwenden.
Hinweis: Fügen Sie den Parameter -AdminAddress localhost:89 in den anfänglichen Cmdlet-Aufruf ein.
Beispiel: Get-BrokerMachine -AdminAddress localhost:89
|
| Überwachungsdaten | Monitor-Funktionen zeigen keine Aktivitäten an, wenn der LHC-Modus aktiv ist. Eine Untermenge der Überwachungsdaten ist im Dashboard des lokalen Hostcaches auf der Seite Trends in Monitor verfügbar. |
| Hypervisor-Anmeldeinformationen | Können nicht vom Hostdienst abgerufen werden. Maschinen in unbekanntem Energiezustand, keine Energieoperationen möglich. Eingeschaltete VMs für Verbindungen nutzbar. |
| Zugewiesene Maschinen | Nur nutzbar, wenn sie während des normalen Betriebs zugewiesen wurden. Neue Zuweisungen sind im LHC-Modus nicht möglich. |
| Remote-PC-Zugriffsmaschinen | Automatische Registrierung und Konfiguration werden nicht unterstützt. Maschinen, die während des normalen Betriebs registriert und konfiguriert wurden, sind nutzbar. |
| Sitzungslimits für servergehostete Anwendungen und Desktops | Benutzer können mehr Sitzungen nutzen, als ihre konfigurierten Sitzungslimits zulassen, wenn sich die Ressourcen in verschiedenen Zonen befinden. |
| Zonenverhalten | Jede Zone agiert unabhängig. Wenn die StoreFront-Funktion erweiterte Integritätsprüfung aktiviert ist, kann StoreFront Startanforderungen im LHC-Modus an die entsprechende Zone weiterleiten und Sitzungsstartfehler vermeiden. |
| Geplante VDA-Neustarts | Wenn der LHC-Modus aktiviert wird, bevor ein geplanter Neustart für VDAs in einer Bereitstellungsgruppe beginnt, beginnen die Neustarts, wenn der LHC-Modus beendet wird und der normale Brokering-Betrieb wieder aufgenommen wird, was möglicherweise unerwartete Neustarts verursachen kann, wenn die Zone den LHC-Modus verlässt. Weitere Informationen und Konfigurationen, die dieses Verhalten ändern können, finden Sie unter Geplante Neustarts aufgrund von Datenbankausfall verzögert. |
| Zonenpräferenz | Zonenpräferenz-Konfigurationen werden für den Sitzungsstart nicht berücksichtigt. |
| Tag-Einschränkungen | Für Bereitstellungsgruppen mit VDAs in mehreren Zonen können Tag-Einschränkungen zu Startfehlern führen, wenn getaggte VDAs nicht in allen Zonen vorhanden sind. |
Hinweis:
Die Verwendung von
$XDSDKAuthfür die SDK-Authentifizierung ist ab Juni 2025 veraltet. Einzelheiten finden Sie unter Veraltet.
Anwendungs- und Desktop-Unterstützung
LHC unterstützt die folgenden VDA-Typen und Bereitstellungsmodelle:
|VDA-Typ|Bereitstellungsmodell|VDA-Verfügbarkeit im LHC-Modus| |—|—|—|
-
Multi-Session-OS Anwendungen und Desktops Immer verfügbar. -
Single-Session-OS statisch (zugewiesen) Desktops Immer verfügbar. -
Energieverwaltetes Single-Session-OS zufällig (gepoolt) Desktops Standardmäßig nur für eine Sitzung verfügbar. -
^^ ^^ ^^ Sie können sie so konfigurieren, dass sie während LHC immer für neue Sitzungen verfügbar sind. Weitere Informationen finden Sie unter Aktivieren mit Studio und Aktivieren mit PowerShell. -
^^ ^^ ^^ Wichtig: Das Aktivieren des Zugriffs auf energieverwaltete Single-Session-Pool-Maschinen kann dazu führen, dass Daten und Änderungen aus früheren Benutzersitzungen in nachfolgenden Sitzungen vorhanden sind.
-
Hinweis:
Das Aktivieren des Zugriffs auf energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen hat keinen Einfluss darauf, wie die konfigurierte
ShutdownDesktopsAfterUse-Eigenschaft während des normalen Betriebs funktioniert. Wenn der Zugriff auf diese Desktops während LHC aktiviert ist, werden VDAs nach der Rückkehr zum normalen Brokering-Betrieb nicht automatisch neu gestartet. Energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen können Daten aus früheren Sitzungen beibehalten, bis die VDAs neu gestartet werden. Ein VDA-Neustart kann erfolgen, wenn sich ein Benutzer während Nicht-LHC-Operationen vom VDA abmeldet oder wenn Administratoren den VDA neu starten.
LHC für energieverwaltete Single-Session-OS-Pool-VDAs mit Studio aktivieren
Mit Studio können Sie diese Maschinen im LHC-Modus pro Bereitstellungsgruppe für neue Verbindungen verfügbar machen:
- Um diese Funktion während der Erstellung einer Bereitstellungsgruppe zu aktivieren, siehe Bereitstellungsgruppen erstellen.
- Um diese Funktion für eine bestehende Bereitstellungsgruppe zu aktivieren, siehe Bereitstellungsgruppen verwalten
Hinweis:
Diese Einstellung ist in Studio nur für gepoolte Desktop-Bereitstellungsgruppen verfügbar, die energieverwaltete VDAs bereitstellen.
LHC für energieverwaltete gepoolte VDAs mit Einzelsitzungs-Betriebssystem mithilfe von PowerShell aktivieren
Um LHC für VDAs in einer bestimmten Bereitstellungsgruppe zu aktivieren, gehen Sie wie folgt vor:
-
Aktivieren Sie diese Funktion auf Site-Ebene, indem Sie diesen Befehl ausführen:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true <!--NeedCopy--> -
Aktivieren Sie LHC für eine Bereitstellungsgruppe, indem Sie diesen Befehl mit dem angegebenen Namen der Bereitstellungsgruppe ausführen:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true <!--NeedCopy-->
Um die standardmäßige LHC-Verfügbarkeit für neu erstellte gepoolte Bereitstellungsgruppen mit energieverwalteten VDAs zu ändern, führen Sie den folgenden Befehl aus:
Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true
<!--NeedCopy-->
Hinweis:
Das Ändern der Standardeinstellung ändert die Einstellung für vorhandene Bereitstellungsgruppen nicht und wirkt sich nur auf Bereitstellungsgruppen aus, die mit PowerShell erstellt wurden.
StoreFront-Konfiguration
-
Wenn Sie eine lokale StoreFront-Bereitstellung verwenden, beachten Sie Folgendes:
- Wenn Sie einen virtuellen Lastausgleichsserver verwenden, konfigurieren Sie den virtuellen Server so, dass er Connectors basierend auf Brokering-Funktionen überwacht (Beispiel: Verwenden Sie den integrierten CITRIX-XD-DDC-Monitor auf einem NetScaler® für den Connector-Lastausgleich).
- Fügen Sie alle Cloud Connectors innerhalb eines einzelnen Cloud-Mandanten als einzelnen Ressourcenfeed in StoreFront hinzu.
- Zeigen Sie NetScaler Gateway-Konfigurationen in StoreFront an und stellen Sie sicher, dass alle Connectors als STA-Server aufgeführt sind. Überprüfen Sie NetScaler-Appliances und stellen Sie sicher, dass alle in StoreFront aufgeführten STAs im virtuellen NetScaler Gateway-Server im selben Format vorliegen. Der STA-Dienststatus kann auch im virtuellen Gateway-Server überwacht werden.
- Fügen Sie alle Connectors dem Ressourcenfeed in StoreFront hinzu und stellen Sie sicher, dass StoreFront mit allen Cloud Connectors über den im Ressourcenfeed angegebenen Port kommunizieren kann.
Hinweis:
Für Kunden mit vielen Connectors kann es vorteilhaft sein, einen virtuellen Lastausgleichsserver für jede Zone zu konfigurieren, um den Verwaltungsaufwand zu reduzieren und die Fehlerbehebung zu vereinfachen. Weitere Informationen finden Sie unter Citrix TIPs: Integrating Citrix Virtual Apps and Desktops service and StoreFront.
Überprüfen der Funktion des Local Host Cache
- Um zu überprüfen, ob LHC korrekt eingerichtet ist und funktioniert:
- Stellen Sie sicher, dass Synchronisierungsimporte erfolgreich abgeschlossen werden. Weitere Informationen zur Überwachung von LHC-Synchronisierungen finden Sie in den [Ereignisprotokollen](#event-logs).
- Stellen Sie sicher, dass die Local Host Cache-Datenbank auf jedem Cloud Connector erstellt wurde. Dies bestätigt, dass der High Availability Service bei Bedarf die Kontrolle übernehmen kann.
- Navigieren Sie auf dem Cloud Connector-Server zu `c:\Windows\ServiceProfiles\NetworkService`.
- Überprüfen Sie, ob `HaDatabaseName.mdf` und `HaDatabaseName_log.ldf` erstellt wurden.
- LHC-Modus erzwingen auf allen Cloud Connectors in der Zone: Nachdem Sie überprüft haben, dass der Local Host Cache funktioniert, denken Sie daran, alle Cloud Connectors wieder in den normalen Modus zu versetzen. Weitere Informationen zur Dauer des Verlassens des LHC-Modus finden Sie unter Local Host Cache-Zustände.
Local Host Cache überwachen
Ereignisprotokolle
Ereignisprotokolle liefern wichtige Informationen zum Zustand und zur Leistung von LHC.
Config Synchronizer Service
Im Normalbetrieb können die folgenden Ereignisse auftreten, wenn der CSS die Konfigurationsdaten mithilfe des LHC-Brokers in die LHC-Datenbank importiert.
| Ereignis-ID | Beschreibung |
|---|---|
| 503 | Zeigt an, dass der CSS eine aktualisierte Konfiguration erhalten hat. Dieses Ereignis tritt jedes Mal auf, wenn eine aktualisierte Konfiguration von Citrix Cloud empfangen wird. Dies kennzeichnet den Beginn des Synchronisierungsprozesses. |
| 504 | Zeigt an, dass der CSS eine aktualisierte Konfiguration importiert hat. Der Konfigurationsimport wurde erfolgreich abgeschlossen. |
| 505 | Zeigt an, dass der CSS einen Import fehlgeschlagen hat. Der Konfigurationsimport wurde nicht erfolgreich abgeschlossen. Wenn eine frühere erfolgreiche Konfiguration verfügbar ist, wird diese verwendet, wenn der LHC-Modus aktiviert wird. Sie ist jedoch gegenüber der aktuellen Konfiguration veraltet. Wenn keine frühere Konfiguration verfügbar ist, kann der Dienst während des LHC-Modus nicht am Session Brokering teilnehmen. In diesem Fall lesen Sie den Abschnitt Fehlerbehebung und wenden Sie sich an den Citrix Support. |
| 507 | Zeigt an, dass der CSS einen Import abgebrochen hat, weil sich das System im LHC-Modus befindet und der LHC-Broker für das Brokering verwendet wird. Der Dienst hat eine neue Konfiguration erhalten, der Import wurde jedoch abgebrochen, da der LHC-Modus aktiviert wurde. Dies ist ein erwartetes Verhalten. |
| 510 | Zeigt an, dass keine CSS-Konfigurationsdaten vom primären Konfigurationsdienst empfangen wurden. |
| 517 | Zeigt an, dass ein Problem bei der Kommunikation mit dem primären Broker-Dienst aufgetreten ist. |
| 518 | Zeigt an, dass das CSS-Skript abgebrochen wurde, weil der LHC-Broker (High Availability Service) nicht ausgeführt wird. |
Hochverfügbarkeitsdienst
Dieser Dienst ist auch als LHC-Broker bekannt.
| Ereignis-ID | Beschreibung |
|---|---|
| 3502 | Gibt an, dass ein Ausfall aufgetreten ist und der LHC-Broker Broker-Operationen ausführt. |
| 3503 | Gibt an, dass ein Ausfall behoben wurde und der normale Betrieb wieder aufgenommen wurde. |
| 3504 | Gibt den gewählten LHC-Broker und andere an der Wahl beteiligte LHC-Broker an. |
| 3507 | Gibt an, dass der LHC-Modus auf dem gewählten LHC-Broker aktiv ist. Enthält eine Zusammenfassung des Ausfalls, einschließlich Ausfalldauer, VDA-Registrierung und Sitzungsinformationen. |
| 3508 | Gibt an, dass LHC auf dem gewählten LHC-Broker nicht mehr aktiv ist und der normale Betrieb wiederhergestellt wurde. Enthält eine Zusammenfassung des Ausfalls, einschließlich Ausfalldauer, Anzahl der während des LHC-Ereignisses registrierten Maschinen und Anzahl der erfolgreichen Starts im LHC-Modus. |
| 3509 | Gibt an, dass LHC auf dem nicht gewählten LHC-Broker aktiv ist. Enthält eine Ausfalldauer alle 2 Minuten und gibt den gewählten LHC-Broker an. |
| 3510 | Gibt an, dass LHC auf dem nicht gewählten LHC-Broker nicht mehr aktiv ist. Enthält die Ausfalldauer und gibt den gewählten LHC-Broker an. |
Remote Broker Provider
Dieser Dienst fungiert als Proxy zwischen Citrix Cloud und Ihren VDAs und Cloud Connectors.
|Ereignis-ID|Beschreibung| |–|–|
- |3001|Die erste Erkennung eines Fehlers, der dazu führt, dass der Cloud Connector in den Status \*\*HA ausstehend\*\* wechselt. Integritätsprüfungen beginnen, um zu beurteilen, ob der Fehler transient oder persistent ist. Nach der zugewiesenen Zeit im Status \*\*HA ausstehend\*\* zeigen die neuesten Integritätsprüfungsergebnisse an, ob ein Eintritt in den LHC-Modus erforderlich ist oder ob der normale Betrieb wieder aufgenommen werden kann.|
- |3002|Gibt an, dass der Cloud Connector nicht in den LHC-Modus wechseln kann. Der Grund ist in den Ereignisinformationen enthalten.|
- |3003|Gibt an, dass der Cloud Connector zwischen LHC-Modus-Zuständen wechselt. Das Ereignis liefert Details zu Folgendem:|
- |^^|^^ - Zustand, aus dem der Cloud Connector wechselt|
- |^^|^^ - Zustand, in den er wechselt|
-
^^ ^^ - Dauer des vorherigen Zustands
Hinweis:
Die 3001-Ereignisse auf Ihren Cloud Connectors, die über den Tag verteilt periodisch auftreten, sind in der Regel kein Grund zur Besorgnis. Wenn sie jedoch mehrmals pro Stunde auftreten, deutet dies auf ein Netzwerkproblem hin und könnte eine weitere Untersuchung rechtfertigen.
Citrix Monitor
Citrix Monitor enthält zentralisierte Informationen zu LHC-Modus-Einträgen und zur Leistung für die verschiedenen Zonen in Ihrer Umgebung.

Weitere Informationen finden Sie unter Historische Trends über eine Site hinweg überwachen.
Lokalen Hostcache-Modus erzwingen
Möglicherweise möchten Sie den Lokalen Hostcache-Modus in den folgenden Szenarien bewusst erzwingen:
- Wenn Ihr Netzwerk wiederholt ausfällt und wiederhergestellt wird: Das Erzwingen von LHC, bis die Netzwerkprobleme behoben sind, verhindert einen kontinuierlichen Übergang zwischen dem normalen und dem LHC-Modus (und die daraus resultierenden häufigen VDA-Registrierungsstürme).
- Um einen Notfallwiederherstellungsplan zu testen.
- Um sicherzustellen, dass der Lokale Hostcache ordnungsgemäß funktioniert.
So erzwingen Sie den LHC-Modus:
-
Bearbeiten Sie die Registrierung jedes Cloud Connector-Servers unter
HKLM\Software\Citrix\DesktopServer\LHC: Erstellen und setzen SieOutageModeForcedals REG_DWORD auf1.- Das Setzen des Werts auf
1weist den LHC-Broker an, in den LHC-Modus zu wechseln, unabhängig vom Status der Verbindung zu Citrix Cloud. - Das Setzen des Werts auf
0weist den LHC-Broker an, den LHC-Modus zu verlassen und den normalen Betrieb wieder aufzunehmen.
- Das Setzen des Werts auf
So überprüfen Sie Ereignisse:
- Überwachen Sie die Protokolldatei
Current_HighAvailabilityServiceunterC:\ProgramData\Citrix\workspaceCloud\Logs\Plugins\HighAvailabilityService.
Beheben von Fehlern beim Synchronisierungsimport
Wenn ein Synchronisierungsimport in die LHC-Datenbank fehlschlägt und ein 505-Ereignis protokolliert wird, können Sie die folgenden Tools zur Fehlerbehebung verwenden:
- CDF-Tracing:
- Aktivieren Sie das Tracing für die Module
ConfigSyncServerundBrokerLHC. - Verwenden Sie es mit anderen Broker-Modulen, um das Problem zu identifizieren.
- Aktivieren Sie das Tracing für die Module
- CSS-Trace-Bericht:
-
Generiert einen detaillierten Bericht, der das Objekt identifiziert, das den Synchronisierungsfehler verursacht.
Hinweis:
Das Aktivieren dieses Berichts kann die Synchronisierungsgeschwindigkeit beeinträchtigen. Deaktivieren Sie ihn, wenn Sie nicht aktiv Fehler beheben.
So aktivieren und generieren Sie einen CSS-Trace-Bericht:
-
Berichterstellung aktivieren: Führen Sie den folgenden Befehl aus:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1 <!--NeedCopy--> -
Bericht suchen: Der HTML-Bericht wird unter
C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.htmlgeneriert. -
Berichterstellung deaktivieren: Nachdem der Bericht generiert wurde, führen Sie den folgenden Befehl aus, um die Berichtsfunktion zu deaktivieren:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0 <!--NeedCopy-->
-
PowerShell-Befehle für den Local Host Cache
Sie können den Local Host Cache auf Ihren Cloud Connectors mithilfe von PowerShell-Befehlen verwalten.
Das PowerShell-Modul befindet sich an folgendem Speicherort auf den Cloud Connectors:
C:\Program Files\Citrix\Broker\Service\ControlScripts
Wichtig:
Führen Sie dieses Modul nur auf den Cloud Connectors aus.
PowerShell-Modul importieren
Um das Modul zu importieren, führen Sie Folgendes auf Ihrem Cloud Connector aus:
Import-Module "C:\Program Files\Citrix\Broker\Service\ControlScripts\HighAvailabilityServiceControl.psm1
<!--NeedCopy-->
PowerShell-Befehle zur Verwaltung von LHC
Die folgenden Cmdlets helfen Ihnen, den LHC-Modus auf den Cloud Connectors zu aktivieren und zu verwalten.
| Cmdlets | Funktion |
|---|---|
Enable-LhcForcedOutageMode |
Versetzt den Broker in den LHC-Modus. Die Local Host Cache-Datenbankdateien müssen vom CSS erfolgreich erstellt worden sein, damit Enable-LhcForcedOutageMode ordnungsgemäß funktioniert. Dieses Cmdlet erzwingt LHC nur auf dem Cloud Connector, auf dem es ausgeführt wurde. Damit LHC aktiv wird, muss dieses Cmdlet auf allen Cloud Connectors innerhalb der Zone ausgeführt werden. |
Disable-LhcForcedOutageMode |
Nimmt den Broker aus dem LHC-Modus. Dieses Cmdlet deaktiviert den LHC-Modus nur auf dem Cloud Connector, auf dem es ausgeführt wurde. Disable-LhcForcedOutageMode muss auf allen Cloud Connectors innerhalb der Zone ausgeführt werden. |
Set-LhcConfigSyncIntervalOverride |
Legt das Intervall fest, in dem CSS nach Konfigurationsänderungen innerhalb der Citrix DaaS™-Site sucht. Das Zeitintervall kann zwischen 60 Sekunden (einer Minute) und 3600 Sekunden (einer Stunde) liegen. Diese Einstellung gilt nur für den Cloud Connector, auf dem sie ausgeführt wurde. Für Konsistenz über die Cloud Connectors hinweg sollten Sie dieses Cmdlet auf jedem Cloud Connector ausführen. Beispiel: Set-LhcConfigSyncIntervalOverride -Seconds 1200
|
Clear-LhcConfigSyncIntervalOverride |
Setzt das Intervall, in dem der CSS nach Konfigurationsänderungen innerhalb der Citrix DaaS-Site sucht, auf den Standardwert von 300 Sekunden (fünf Minuten) zurück. Diese Einstellung gilt nur für den Cloud Connector, auf dem sie ausgeführt wurde. Für Konsistenz über die Cloud Connectors hinweg sollten Sie dieses Cmdlet auf jedem Cloud Connector ausführen. |
Enable-LhcHighAvailabilitySDK |
Ermöglicht den Zugriff auf alle Get-Broker*-Cmdlets innerhalb des Cloud Connectors, auf dem es ausgeführt wurde. |
Disable-LhcHighAvailabilitySDK |
Deaktiviert den Zugriff auf die Broker-PowerShell-Befehle innerhalb des Cloud Connectors, auf dem es ausgeführt wurde. |
Hinweis:
- Verwenden Sie Port 89, wenn Sie die
Get-Broker*-Cmdlets auf dem Cloud Connector ausführen. Beispiel:
Get-BrokerMachine -AdminAddress localhost:89- Wenn nicht im LHC-Modus, enthält der LHC-Broker auf dem Cloud Connector nur Konfigurationsinformationen.
- Im LHC-Modus enthält der LHC-Broker die folgenden Informationen:
- Ressourcenzustände
- Sitzungsdetails
- VDA-Registrierungen
- Konfigurationsinformationen
Weitere Informationen
-
Weitere Informationen finden Sie unter Überlegungen zu Skalierung und Größe für den Local Host Cache zu:
- Testmethoden und -ergebnisse
- Überlegungen zur RAM-Größe
- Überlegungen zur CPU-Kern- und Socket-Konfiguration
- Überlegungen zum Speicher
In diesem Artikel
- Überblick
- Funktionsweise
- Lokaler Hostcache-Dateninhalt
- Lokaler Hostcache-Zustände
- Wichtige Überlegungen im LHC-Modus
- Überprüfen der Funktion des Local Host Cache
- Local Host Cache überwachen
- Citrix Monitor
- Lokalen Hostcache-Modus erzwingen
- Beheben von Fehlern beim Synchronisierungsimport
- Weitere Informationen