Lokaler Hostcache
Dieser Artikel bietet einen vollständigen Überblick über das Feature “Lokaler Hostcvache” (Local Host Cache, LHC), wobei der Schwerpunkt auf ihrer Fähigkeit liegt, die Geschäftskontinuität aufrechtzuerhalten. Die Funktionsweise des LHC sowohl während des normalen Arbeitsbetriebs als auch bei Aktivierung des LHC-Modus wird hier erklärt. Darüber hinaus bietet der Artikel Anleitungen zu Konfigurationsprüfungen, zur Problembehandlung, zu PowerShell-Befehlen für die LHC-Verwaltung und zur Überwachung des LHC-Zustands im Ereignisprotokoll.
Übersicht
LHC behält den Endbenutzerzugriff auf Apps und Desktops bei, wenn Cloud Connectors aufgrund einer Netzwerkunterbrechung oder eines Problems mit Citrix Cloud die Verbindung zu Citrix Cloud verlieren. Aktive Sitzungen werden nicht beeinträchtigt, wenn der LHC-Modus aktiviert wird und neue Sitzungen über den LHC-Broker vermittelt werden, der auf den Cloud Connectors läuft.
LHC ist standardmäßig aktiviert, aber es ist wichtig sicherzustellen, dass Ihre Umgebung ordnungsgemäß für LHC konfiguriert ist. Obwohl Fehlkonfigurationen das normale Brokering nicht stören, können sie die LHC-Leistung beeinträchtigen und zu Unterbrechungen für Endbenutzer führen, wenn der LHC-Modus aktiv ist. Um eine optimale LHC-Funktionalität sicherzustellen, überprüfen Sie Ihren Zonen-Knoten in Studio auf zonenbezogene Fehler und Warnungen, die Citrix erkannt hat. Lesen Sie außerdem den Leitfaden Resilienzkonfigurationen prüfen und den Artikel Avoid Common Misconfigurations that Can Negative Impact DaaS Resiliency für eine umfassende LHC-Konfigurationscheckliste.
Wichtig:
LHC wird nur aktiviert, wenn Cloud Connectors Datenverkehr von StoreFront empfangen oder Servicekontinuität aktiviert ist. Weitere Informationen darüber, wie Servicekontinuität den lokalen Hostcache verwenden kann, um den Benutzerzugriff auf Apps und Desktops bei Dienstunterbrechungen aufrechtzuerhalten, finden Sie unter Servicekontinuität.
Funktionsweise
Während des normalen Betriebs kommuniziert der Remote Broker Provider Service auf einem Cloud Connector mit Citrix Cloud für alle Brokeringoperationen. Der Citrix Config Synchronizer Service (CSS) sucht regelmäßig nach 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 bei Citrix Cloud ein Problem auftritt, wird der LHC-Modus aktiviert und gewährleistet den kontinuierlichen Zugriff auf Anwendungen und Desktops.
Während des normalen Brokerbetriebs
- Der Citrix Remote Broker Provider Service auf einem Cloud Connector akzeptiert Verbindungsanforderungen von StoreFront. Der Remote Broker Provider Service kommuniziert mit Citrix Cloud, um Benutzer mit VDAs zu verbinden, die bei Citrix Cloud registriert sind.
- Das CSS überprüft ungefähr alle 5 Minuten beim Cloudbroker in Citrix Cloud, ob Konfigurationsä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 das CSS Informationen mit dem LHC-Broker auf dem Cloud Connector. (Der LHC-Broker wird auch als High Availability Service oder HA-Broker 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 Cloud Connector. 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 in Citrix Cloud übereinstimmen.
Microsoft SQL Server Express LocalDB (wird 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. Das Backup der LHC-Datenbank ist nicht nötig. Sie wird jedes Mal neu erstellt, wenn eine Konfigurationsänderung erkannt wird.
- Wenn seit der letzten Prüfung keine Änderungen erfolgt sind, werden keine Konfigurationsdaten kopiert.
Wenn der LHC-Modus aktiv wird
- Der LHC-Broker beginnt, auf Verbindungsinformationen zu warten und Verbindungsanfragen zu verarbeiten.
- Wenn die Cloud Connectors zum ersten Mal die Konnektivität zu Citrix Cloud verlieren, hat der LHC-Broker keine aktuellen VDA-Registrierungsdaten, aber wenn ein VDA mit ihm kommuniziert, wird ein Registrierungsprozess ausgelöst. Während dieses Vorgangs ruft der LHC-Broker auch aktuelle Sitzungsinformationen für diesen VDA ab.
- 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, nicht mehr auf Verbindungsinformationen zu warten, und Citrix Cloud nimmt den Brokerbetrieb wieder auf. Wenn ein VDA das nächste Mal über den Remote Broker Provider Service mit Citrix Cloud kommuniziert, wird ein Registrierungsvorgang 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, wenn er Konfigurationsänderungen in Citrix Cloud erkennt.
In dem unwahrscheinlichen Fall, dass der LHC während einer Synchronisation beginnt, wird der aktuelle Import verworfen und die letzte bekannte Konfiguration wird verwendet.
Das Ereignisprotokoll gibt an, wann Synchronisationen stattfinden und der LHC-Modus aktiviert wird.
Für den Betrieb im LHC-Modus gibt es kein Zeitlimit.
Sie können den LHC-Modus auch manuell auslösen. Weitere Informationen dazu, warum und wie das zu tun ist, finden Sie unter LHC-Modus erzwingen.
Zonen mit mehreren Cloud Connectors
Neben anderen Aufgaben stellt das CSS dem LHC-Broker routinemäßig Informationen über alle Cloud Connectors in der Zone zur Verfügung. Mit diesen Informationen weiß jeder LHC-Broker über alle Peer-LHC-Broker Bescheid, die auf anderen Cloud Connectors in der Zone laufen.
Die LHC-Broker kommunizieren auf einem separaten Kanal miteinander. Diese Broker verwenden eine alphabetische Liste von FQDN-Namen der Maschinen, auf denen sie laufen, um zu bestimmen (auszuwählen), welcher LHC-Broker Operationen in der Zone vermittelt, wenn die Zone in den LHC-Modus wechselt. Im LHC-Modus registrieren sich alle VDAs erneut beim ausgewählten LHC-Broker. Die nicht ausgewählten LHC-Broker in der Zone lehnen eingehende Verbindungs- und VDA-Registrierungsanfragen aktiv ab.
Wichtig:
Connectors innerhalb einer Zone müssen einander unter
http://<FQDN_OF_PEER_CONNECTOR>:80/Citrix/CdsController/ISecondaryBrokerElection
. erreichen können. Wenn Connectors unter dieser Adresse nicht kommunizieren können, werden möglicherweise mehrere Broker ausgewählt und im LHC-Modus treten Startfehler auf.
Wenn im LHC-Modus 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 Cloudconnector ausgewählt, wodurch sich VDAs registrieren. Die Wahlreihenfolge basiert auf der alphabetischen Reihenfolge des FQDN von 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 es während der Registrierungen zu Leistungseinbußen kommen.
Weitere Informationen zu Ereignissen im Zusammenhang mit LHC-Brokerwahlen finden Sie in den Ereignisprotokollen.
Dateninhalt des lokalen Hostcaches
Die LHC-Datenbank enthält die folgenden Daten, die eine Teilmenge der Daten 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 Workspace-App-Clientmaschinen, die aktiv für die Verbindung mit veröffentlichten Ressourcen verwendet werden.
Sie enthält auch die folgenden Informationen für derzeit aktive Verbindungen, die im LHC-Modus hergestellt wurden:
- Ergebnisse jeder von der Citrix Workspace-App durchgeführten Clientmaschinen-Endpunktanalyse.
- Identität von Infrastrukturmaschinen (z. B. Citrix Gateway- und StoreFront-Server), die mit der Site zu tun haben.
- Datum, Uhrzeit und Art kürzlich erfolgter Aktivitäten von Benutzern
Status des lokalen Hostcaches
Während des gesamten Zyklus des Ein- und Ausstiegs des LHC-Modus gibt es mehrere Zustände. Das folgende Diagramm beschreibt die Zustände für das Aufrufen und Verlassen des LHC-Modus.
- Während des Status Working Normally sind alle Komponenten fehlerfrei und alle Brokeringtransaktionen werden vom Cloudbroker abgewickelt. - Das CSS repliziert aktiv die Konfigurationen vom Cloudbroker auf die Cloud Connectors. Wenn eine Systemintegritätsprüfung fehlschlägt, wechseln Cloud Connectors in den Status Pending HA. In diesem Zustand wird eine umfassende Systemintegritätsprüfung eingeleitet, um die nächste Vorgehensweise festzulegen. Die Connectors interagieren mit anderen Connenctors in der Zone, um ihren Integritätsstatus zu ermitteln.
- Die Entscheidung, von Pending HA zu Initial HA zu wechseln, basiert auf dem Zustand aller Connectors in einer bestimmten Zone. Wenn die Systemintegritätsprüfungen erfolgreich sind, wechseln die Connectors/Controller zurück in den Status Working Normally. Wenn die Systemintegritätsprüfungen weiterhin fehlschlagen, wechseln die Connectors/Controller alternativ in den Zustand Initial HA.
- Während des Status Initial HA übernimmt der LHC-Broker auf dem ausgewählten Connector die Brokeringaufgaben. Alle VDAs in der aktuellen Zone, die zuvor registriert wurden, registrieren sich jetzt beim LHC-Broker auf dem Cloud Connector. Es kann bis zu 5 Minuten dauern, bis sich alle VDAs erneut beim HA-Dienst registrieren. Am Ende von Initial HA werden Systemintegritätsprüfungen eingeleitet. Wenn alle Systemintegritätsprüfung erfolgreich sind, wechselt der Status zu Wiederherstellung ausstehend, andernfalls wechselt der Status zu Extended HA.
- Während der Extended HA-Periode finden weiterhin Systemintegritätsprüfungen statt. Wenn die Systemintegritätsprüfungen während Extended HA erfolgreich sind, geht der Status in Wiederherstellung ausstehend über. Es gibt keine maximale Zeitdauer, für die ein Connector im Status Extended HA verbleibt.
- Wiederherstellung ausstehend dient als Pufferzeit, um sicherzustellen, dass die Dienste vollständig intakt sind, bevor der LHC-Modus verlassen wird. Wenn eine der Systemintegritätsprüfungen während Wiederherstellung ausstehend fehlschlägt, wechselt der Status zurück zu Extended HA.
- Wenn während des gesamten Zeitraums von 10 Minuten für Pending Recovery alle Zustandsprüfungen erfolgreich waren, wechselt der Status zu Working Normally. Mit diesem Übergang endet der LHC-Modus und alle VDAs in der Zone, die beim LHC-Broker registriert waren, registrieren sich jetzt erneut beim Cloudbroker. Diese erneute Registrierung kann erneut 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 | Je nach Art der Störung möglicherweise nicht zugänglich. 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 Access
|
Eingeschränkter Zugang. Erfordert die Aktivierung des CSS-Testmodus und die Einstellung der SDK-Authentifizierung. CSS-Testmodus aktivieren: Fügen Sie den Registrierungsschlüssel hinzu. “EnableCssTestMode” mit einem DWORD-Wert von “1” unter HKLM:\SOFTWARE\Citrix\DesktopServer\LHC .
SDK-Authentifizierung festlegen: Setzen Sie die Variable $XDSDKAuth auf “OnPrem”, um zu verhindern, dass der SDK-Proxy Cmdlet-Aufrufe umleitet. Nachdem Sie diese Änderungen vorgenommen haben, können Sie alle Get-Broker -Cmdlets verwenden.
Hinweis: Schließen Sie den Parameter -AdminAddress localhost:89 in den ersten Cmdlet-Aufruf ein.
Beispiel: Get-BrokerMachine -AdminAddress localhost:89
|
Überwachungsdaten | Überwachungsfunktionen zeigen keine Aktivität an, wenn der LHC-Modus aktiv ist. Eine Teilmenge der Überwachungsdaten ist im Dashboard des lokalen Hostcaches der Seite trends in Monitor verfügbar. |
Hypervisor-Anmeldeinformationen | Kann nicht vom Hostdienst abgerufen werden. Maschinen in unbekanntem Betriebszustand, kein Strombetrieb möglich. Eingeschaltete VMs, die für Verbindungen verwendet werden können. |
Zugewiesene Maschinen | Nur nutzbar, wenn sie während des normalen Betriebs zugewiesen werden. Neue Zuweisungen sind im LHC-Modus nicht möglich. |
Maschinen mit Remote-PC-Zugriff | Automatische Registrierung und Konfiguration werden nicht unterstützt. Maschinen, die während des normalen Betriebs registriert und konfiguriert wurden, können verwendet werden. |
Sitzungslimits für servergehostete Anwendungen und Desktops | Benutzer verwenden möglicherweise mehr Sitzungen als ihre konfigurierten Sitzungslimits, wenn sich die Ressourcen in verschiedenen Zonen befinden. |
Zonenverhalten | Jede Zone agiert unabhängig. Wenn das StoreFront-Feature Erweiterte Integritätsprüfung aktiviert ist, kann StoreFront Startanfragen im LHC-Modus an die entsprechende Zone weiterleiten und Fehler beim Sitzungsstart 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 Brokeringbetrieb wieder aufgenommen wird. Dies kann zu unerwarteten Neustarts führen, wenn die Zone den LHC-Modus verlässt. Weitere Informationen und Konfigurationen, die dieses Verhalten ändern können, finden Sie unter Geplante Neustarts verzögert aufgrund eines Datenbankausfalls. |
Zonenpräferenz | Zonenpräferenz-Konfigurationen werden beim Sitzungsstart nicht berücksichtigt. |
Tageinschränkungen | Bei Bereitstellungsgruppen mit VDAs in mehreren Zonen können Tageinschränkungen zu Startfehlern führen, wenn markierte VDAs nicht in allen Zonen vorhanden sind. |
Unterstützung für Anwendungen und Desktops
Der LHC unterstützt die folgenden Arten von VDAs und Bereitstellungsmodellen:
VDA-Typ | Bereitstellungsmodell | VDA-Verfügbarkeit im LHC-Modus |
---|---|---|
Multisitzungs-OS | Anwendungen und Desktops | Immer verfügbar. |
Einzelsitzungs-OS statisch (zugewiesen) | Desktops | Immer verfügbar. |
Energieverwaltetes Einzelsitzungs-OS nach dem Zufallsprinzip (gepoolt)
|
Desktops
|
Standardmäßig nicht verfügbar. Alle Sitzungsstartversuche zur Energieverwaltung von VDAs in gepoolten Bereitstellungsgruppen schlagen standardmäßig fehl.
Sie können sie für neue Verbindungen während des LHC verfügbar machen. Weitere Informationen finden Sie unter Mit Studio aktivieren und Mit PowerShell aktivieren. Wichtig: Die Aktivierung des Zugriffs auf gepoolte Einzelsitzungsmaschinen mit Energieverwaltung kann dazu führen, dass Daten und Änderungen aus früheren Benutzersitzungen in nachfolgenden Sitzungen wiedergegeben werden. |
Hinweis
Die Aktivierung 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 nicht automatisch neu gestartet, nachdem sie zum normalen Brokeringbetrieb zurückgekehrt sind. Energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen können Daten aus früheren Sitzungen beibehalten, bis VDAs neu gestartet werden. Ein VDA-Neustart kann erfolgen, wenn sich ein Benutzer bei Nicht-LHC-Vorgängen vom VDA abmeldet oder Administratoren den VDA neu starten.
LHC mit Studio für gepoolte VDAs mit energieverwaltetem Einzelsitzungsbetriebssystem aktivieren
Mit Studio können Sie diese Maschinen für neue Verbindungen im LHC-Modus pro Bereitstellungsgruppe verfügbar machen:
- Informationen zum Aktivieren dieses Features bei der Erstellung von Bereitstellungsgruppen finden Sie unter Bereitstellungsgruppen erstellen.
- Informationen zum Aktivieren dieses Features für eine vorhandene Bereitstellungsgruppe finden Sie unter Bereitstellungsgruppen verwalten
Hinweis
Diese Einstellung ist in Studio nur für gepoolte Desktopbereitstellungsgruppen verfügbar, die energieverwaltete VDAs bereitstellen.
LHC für gepoolte VDAs für Einzelsitzungs-OS mit PowerShell aktivieren
Gehen Sie folgendermaßen vor, um LHC für VDAs in einer bestimmten Bereitstellungsgruppe zu aktivieren:
-
Aktivieren Sie dieses Feature auf Siteebene, indem Sie den folgenden Befehl ausführen:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
-
Aktivieren Sie LHC für eine Bereitstellungsgruppe, indem Sie diesen Befehl mit dem angegebenen Bereitstellungsgruppennamen ausführen:
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
Führen Sie den folgenden Befehl aus, um die LHC-Standardverfügbarkeit für neu erstellte gepoolte Bereitstellungsgruppen mit energieverwalteten VDAs zu ändern:
Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true
Hinweis
Eine Änderung der Standardeinstellung hat keine Auswirkungen auf die Einstellung für vorhandene Bereitstellungsgruppen und wirkt sich nur auf Bereitstellungsgruppen aus, die mit PowerShell erstellt wurden.
Konfigurieren in StoreFront
Wenn Sie eine lokale StoreFront-Bereitstellung verwenden, überprüfen Sie Folgendes:
- Wenn Sie einen virtuellen Lastausgleichsserver verwenden, konfigurieren Sie den virtuellen Server so, dass er Connectors auf der Grundlage von Brokeringfunktionen überwacht (verwenden Sie beispielsweise den integrierten CITRIX-XD-DDC-Monitor auf einem NetScaler für den Connector-Lastausgleich).
- Schließen Sie alle Cloud Connectors innerhalb eines einzelnen Cloudmandanten als einen einzigen -Ressourcenfeed in StoreFront ein.
- Sehen Sie sich 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 vergewissern Sie sich, dass alle in StoreFront aufgeführten STAs auf dem virtuellen NetScaler Gateway-Server dasselbe Format haben. Der Status des STA-Dienstes kann auch auf dem virtuellen Gateway-Server überwacht werden.
- Fügen Sie alle Connectors zum Ressourcen-Feed in StoreFront hinzu und achten Sie darauf, dass StoreFront über den im Ressourcenfeed angegebenen Port mit allen Cloud Connectors kommunizieren kann.
Hinweis
Für Kunden mit vielen Connectors kann es von Vorteil sein, für jede Zone einen virtuellen Lastausgleichsserver zu konfigurieren, um den Verwaltungsaufwand zu reduzieren und die Problembehandlung zu vereinfachen. Weitere Informationen finden Sie unter Citrix-Tipps: Integration von Citrix Virtual Apps and Desktops Service und StoreFront.
Funktion des lokalen Hostcaches validieren
Gehen Sie wie folgt vor, um zu überprüfen, ob der LHC eingerichtet ist und ordnungsgemäß funktioniert:
- Vergewissern Sie sich, dass Synchronisierungsimporte erfolgreich abgeschlossen werden. Weitere Informationen zur Überwachung von LHC-Synchronisierungen finden Sie in den Ereignisprotokollen.
- Stellen Sie sicher, dass die lokale Hostcachedatenbank auf jedem Cloud Connector erstellt wurde. Dadurch wird bestätigt, dass der Dienst für hohe Verfügbarkeit bei Bedarf übernehmen kann.
- Navigieren Sie auf dem Cloud Connector-Server zu
c:\Windows\ServiceProfiles\NetworkService
. - Überprüfen Sie, ob
HaDatabaseName.mdf
undHaDatabaseName_log.ldf
erstellt werden.
- Navigieren Sie auf dem Cloud Connector-Server zu
- LHC-Modus erzwingen auf allen Cloud Connectors in der Zone: Nachdem Sie überprüft haben, dass der lokale Hostcache funktioniert, denken Sie daran, alle Cloud Connectors wieder in den normalen Modus zu versetzen. Weitere Informationen zur Zeit, die benötigt wird, um den LHC-Modus zu verlassen, finden Sie unter Status des lokalen Hostcaches.
Lokalen Hostcache überwachen
Ereignisprotokolle
Ereignisprotokolle liefern wichtige Informationen über den Zustand und die Leistung des LHC.
Config Sync-Dienst
Während des normalen Betriebs können die folgenden Ereignisse auftreten, wenn das CSS die Konfigurationsdaten mit dem LHC-Broker in die LHC-Datenbank importiert.
Ereignis-ID | Beschreibung |
---|---|
503 | Zeigt an, dass das CSS eine aktualisierte Konfiguration erhalten hat. Dieses Ereignis tritt jedes Mal auf, wenn eine aktualisierte Konfiguration von Citrix Cloud eintrifft. Dies zeigt den Beginn des Synchronisierungsvorgangs an. |
504 | Zeigt an, dass das CSS eine aktualisierte Konfiguration importiert hat. Der Konfigurationsimport wurde erfolgreich abgeschlossen. |
505 | Zeigt an, dass das CSS einen Import nicht bestanden hat. Der Konfigurationsimport wurde nicht erfolgreich abgeschlossen. Wenn eine frühere erfolgreiche Konfiguration verfügbar ist, wird sie verwendet, wenn der LHC-Modus aktiviert wird. Sie ist jedoch im Vergleich zur aktuellen Konfiguration veraltet. Wenn keine vorherige Konfiguration verfügbar ist, kann der Dienst im LHC-Modus nicht am Sitzungsbroker teilnehmen. Lesen Sie in diesem Fall den Abschnitt Fehlerbehebung und wenden Sie sich an den Citrix Support. |
507 | Zeigt an, dass das 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 erhielt eine neue Konfiguration, aber der Import wurde abgebrochen, weil der LHC-Modus aktiviert wurde. Dieses Verhalten wird erwartet. |
510 | Zeigt an, dass keine CSS-Konfigurationsdaten vom primären Konfigurationsdienst empfangen wurden. |
517 | Zeigt an, dass bei der Kommunikation mit dem Remote Broker Provider Service ein Problem aufgetreten ist. |
518 | Zeigt an, dass das CSS-Skript abgebrochen wurde, weil der LHC-Broker (High Availability Service) nicht läuft. |
Dienst für hohe Verfügbarkeit
Dieser Dienst ist auch als LHC-Broker bekannt.
Ereignis-ID | Beschreibung |
---|---|
3502 | Zeigt an, dass ein Ausfall aufgetreten ist und der LHC-Broker Brokeroperationen durchführt. |
3503 | Zeigt an, dass ein Ausfall behoben und der normale Betrieb wieder aufgenommen wurde. |
3504 | Zeigt den gewählten LHC-Broker und andere an der Wahl beteiligte LHC-Broker an. |
3507 | Zeigt an, dass der LHC-Modus auf dem ausgewählten LHC-Broker aktiv ist. Enthält eine Zusammenfassung des Ausfalls, einschließlich Ausfalldauer, VDA-Registrierung und Sitzungsinformationen. |
3508 | Zeigt an, dass LHC auf dem ausgewählten LHC-Broker nicht mehr aktiv ist und der normale Betrieb wiederhergestellt wurde. Enthält eine Zusammenfassung des Ausfalls, einschließlich der Ausfalldauer, der Anzahl der Maschinen, die sich während des LHC-Ereignisses registriert haben, und der Anzahl der erfolgreichen Starts im LHC-Modus. |
3509 | Zeigt an, dass LHC auf dem nicht ausgewählten LHC-Broker aktiv ist. Enthält alle 2 Minuten eine Ausfalldauer und gibt den ausgewählten LHC-Broker an. |
3510 | Zeigt an, dass der LHC auf dem nicht ausgewählten LHC-Broker nicht mehr aktiv ist. Enthält die Ausfalldauer und gibt den ausgewä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 | Prüft, ob Cloud Connectors in den LHC-Modus wechseln müssen. Tritt nach einer einzelnen fehlgeschlagenen Integritätsprüfung des Cloud Connectors auf. Schlägt eine weitere Überprüfung nach 60 Sekunden fehl, wechselt der Cloud Connector in den LHC-Modus. |
3002 | Zeigt an, dass der Cloud Connector nicht in den LHC-Modus wechseln kann. Der Grund ist in den Veranstaltungsinformationen enthalten. |
3003
|
Zeigt an, dass der Cloud Connector den LHC-Modus durchläuft. Das Ereignis enthält Einzelheiten zu folgenden Themen
|
Hinweis
Die 3001-Ereignisse auf Ihren Cloud Connectors, die im Laufe des Tages regelmäßig auftreten, geben in der Regel keinen Anlass zur Sorge. Wenn sie jedoch mehrmals pro Stunde auftreten, deutet dies auf ein Netzwerkproblem hin und erfordert möglicherweise weitere Untersuchungen.
Citrix Monitor
Citrix Monitor enthält zentrale Informationen zu LHC-Moduseinträgen und zur Leistung der verschiedenen Zonen in Ihrer Umgebung.
Weitere Informationen finden Sie unter Historische Trends auf einer Website überwachen.
Lokalen Hostcachemodus erzwingen
In den folgenden Szenarien sollten Sie möglicherweise bewusst den lokalen Hostcachemodus erzwingen:
- Wenn Ihr Netzwerk wiederholt hoch- und heruntergefahren wird: Wenn Sie LHC so lange erzwingen, bis die Netzwerkprobleme behoben sind, wird ein kontinuierlicher Übergang zwischen Normal- und LHC-Modus verhindert (und die daraus resultierenden häufigen VDA-Registrierungsstürme).
- Zum Testen eines Notfallwiederherstellungsplans
- Zur Prüfung des ordnungsgemäßen Betriebs des lokalen Hostcache
Um den LHC-Modus zu erzwingen:
-
Bearbeiten Sie die Registrierung jedes Cloud Connector-Servers in
HKLM\Software\Citrix\DesktopServer\LHC
: Erstellen SieOutageModeForced
und legen Sie es als REG_DWORD auf1
fest.- Wenn Sie den Wert auf
1
setzen, wird der LHC-Broker angewiesen, unabhängig vom Status der Verbindung zu Citrix Cloud in den LHC-Modus zu wechseln. - Wenn Sie den Wert auf
0
setzen, wird der LHC-Broker angewiesen, den LHC-Modus zu verlassen und den normalen Betrieb fortzusetzen.
- Wenn Sie den Wert auf
So verifizieren Sie Ereignisse:
- Überwachen Sie die
Current_HighAvailabilityService
-Protokolldatei inC:\ProgramData\Citrix\workspaceCloud\Logs\Plugins\HighAvailabilityService
.
Fehler beim Synchronisierungsimport beheben
Wenn ein Synchronisierungsimport in die LHC-Datenbank fehlschlägt und ein 505-Ereignis protokolliert wird, können Sie die folgenden Tools zur Problembehandlung verwenden:
- CDF-Ablaufverfolgung:
- Aktivieren Sie das Tracing für die Module
ConfigSyncServer
undBrokerLHC
. - Verwenden Sie es zusammen mit anderen Brokermodulen, um das Problem zu identifizieren.
- Aktivieren Sie das Tracing für die Module
- CSS Tracingbericht:
-
Generiert einen detaillierten Bericht, der das Objekt identifiziert, das den Synchronisierungsfehler verursacht hat.
Hinweis
Die Aktivierung dieses Berichts kann sich auf die Synchronisierungsgeschwindigkeit auswirken. Deaktivieren Sie ihn, wenn Sie keine aktive Problembehandlung durchführen.
So aktivieren und generieren Sie einen einen CSS Tracingbericht:
-
Berichterstattung aktivieren: Führen Sie den folgenden Befehl aus:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1
-
Suchen Sie den Bericht: Der HTML-Bericht wird unter
C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html
generiert. -
Berichterstattung deaktivieren: Führen Sie nach der Generierung des Berichts den folgenden Befehl aus, um das Berichtsfeature zu deaktivieren:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
-
PowerShell-Befehle für den lokalen Hostcache
Sie können den lokalen Hostcache auf Ihren Cloud Connectors mithilfe von PowerShell-Befehlen verwalten.
Das PowerShell-Modul ist auf den Cloud Connectors hier gespeichert:
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 folgenden Befehl auf Ihrem Cloud Connector aus:
Import-Module "C:\Program Files\Citrix\Broker\Service\ControlScripts\HighAvailabilityServiceControl.psm1
PowerShell-Befehle zur Verwaltung des lokalen Hostcache
Mit den folgenden Cmdlets können Sie den Modus “Lokaler Hostcache” (LHC) auf den Cloud Connectors aktivieren und verwalten.
Cmdlets | Funktion |
---|---|
Enable-LhcForcedOutageMode |
Versetzen Sie den Broker in den Modus “Lokaler Hostcache”. Lokale Hostcachedatenbankdateien müssen erfolgreich vom CSS erstellt worden sein, damit Enable-LHCForcedOutageMode ordnungsgemäß funktioniert. Dieses Cmdlet erzwingt den lokalen Hostcache 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 |
Beendet den Modus “Lokaler Hostcache” auf dem Broker. Dieses Cmdlet deaktiviert nur den LHC-Modus 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 innerhalb der Citrix DaaS-Site nach Konfigurationsänderungen sucht. Das Zeitintervall kann zwischen 60 Sekunden (eine Minute) und 3600 Sekunden (eine Stunde) liegen. Diese Einstellung gilt nur für den Cloud Connector, auf dem sie ausgeführt wurde. Damit alle Cloud Connector übereinstimmen, sollten Sie das Cmdlet auf jedem Cloud Connector ausführen. Zum Beispiel: Set-LhcConfigSyncIntervalOverride -Seconds 1200
|
Clear-LhcConfigSyncIntervalOverride |
Legt das Intervall, in dem das CSS innerhalb der Citrix DaaS-Site nach Konfigurationsänderungen sucht, auf den Standardwert von 300 Sekunden (fünf Minuten) fest. Diese Einstellung gilt nur für den Cloud Connector, auf dem sie ausgeführt wurde. Damit alle Cloud Connector übereinstimmen, sollten Sie das Cmdlet auf jedem Cloud Connector ausführen. |
Enable-LhcHighAvailabilitySDK |
Ermöglicht den Zugriff auf das gesamte Cmdlet Get-Broker* im Cloud Connector, auf dem es ausgeführt wurde. |
Disable-LhcHighAvailabilitySDK |
Deaktiviert den Zugriff auf die Broker PowerShell-Befehle im Cloud Connector, auf dem er ausgeführt wurde. |
Hinweis
- Verwenden Sie Port 89, wenn Sie die Cmdlets
Get-Broker*
auf dem Cloud Connector ausführen. Beispiel:
Get-BrokerMachine -AdminAddress localhost:89
- Wenn sich der Broker des lokalen Hostcache auf dem Cloud Connector nicht im Modus “Lokaler Hostcache” befindet, enthält er nur Konfigurationsinformationen.
- Im LHC-Modus speichert der LHC Broker die folgenden Informationen:
- Ressourcenzustände
- Sitzungsdetails
- VDA-Registrierungen
- Konfigurationsangaben
Weitere Informationen
-
Unter Überlegungen zur Skalierung und Größe für den lokalen Hostcache finden Sie Informationen zu:
- Testmethoden und -ergebnisse
- RAM-Größe
- CPU-Kern- und Socketkonfiguration
- Speicher
In diesem Artikel
- Übersicht
- Funktionsweise
- Dateninhalt des lokalen Hostcaches
- Status des lokalen Hostcaches
- Wichtige Überlegungen im LHC-Modus
- Funktion des lokalen Hostcaches validieren
- Lokalen Hostcache überwachen
- Citrix Monitor
- Lokalen Hostcachemodus erzwingen
- Fehler beim Synchronisierungsimport beheben
- Weitere Informationen