Produktdokumentation
Citrix DaaS
PDF anzeigen

Lokaler Hostcache

September 28, 2024
Beitrag von: 
C

Tipp:

In Studio Start--Knoten werden Sie durch “Benachrichtigungen zum Dienststatus” proaktiv informiert, ob Ihr lokaler Hostcache und die Zonen korrekt konfiguriert sind. Dies gewährleistet, dass der lokale Hostcache bei einem Ausfall funktioniert und Ihre Benutzer nicht davon betroffen sind. Es gibt zwei Arten von Benachrichtigungen: Siteübergreifende Benachrichtigungen werden auf der Homepage angezeigt (Flaggensymbol). Zonenbezogene Benachrichtigungen werden auf der Registerkarte “Problembehandlung” jeder Zone angezeigt. Weitere Informationen finden Sie unter Zonen.

Der lokale Hostcache (LHC) ermöglicht das fortgesetzte Verbindungsbrokering in einer Bereitstellung von Citrix DaaS (ehemals Citrix Virtual Apps and Desktops Service), wenn ein Cloud Connector nicht mit Citrix Cloud kommunizieren kann. Der lokale Hostcache wird aktiv, wenn die Netzwerkverbindung für 60 Sekunden unterbrochen wird.

Über den lokalen Hostcache können verbundene Benutzer bei einem Ausfall ohne Unterbrechung weiterarbeiten. Bei Wiederverbindungen und neuen Verbindungen treten minimale Verbindungsverzögerungen auf.

Wichtig:

Wenn Sie eine On-Premises-StoreFront-Bereitstellung verwenden, müssen Sie alle Cloud Connectors, bei denen VDAs registriert sind (oder sein können), zu StoreFront als Delivery Controller hinzufügen. Ein Cloud Connector, der nicht zu StoreFront hinzugefügt wird, kann nicht in den Ausfallmodus wechseln, was zu Startfehlern für Benutzer führen kann.

Verwenden Sie für Bereitstellungen ohne on-premises StoreFront das Servicekontinuität-Feature der Citrix Workspace-Plattform, um Benutzern auch bei Ausfällen den Zugriff auf Ressourcen zu ermöglichen. Weitere Informationen finden Sie unter Servicekontinuität.

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 Workspace-App-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 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.

Funktionsweise

Erfahren Sie, wie der lokale Hostcache mit Citrix Cloud interagiert.

Normalbetrieb

Abbildung des Normalbetriebs

  • Der Brokerprinzipal (auch “Citrix Remote Broker Provider Service”) auf einem Cloud Connector akzeptiert Verbindungsanfragen von StoreFront. Der Brokering Principal kommuniziert mit Citrix Cloud, um Benutzer mit VDAs zu verbinden, die bei Cloud Connector registriert sind
  • Der Citrix Config Synchronizer Service (CSS) überprüft ca. alle 5 Minuten beim Broker 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 (kopiert) der CSS die Informationen auf einen sekundären Broker auf dem Cloud Connector. Der sekundäre Broker wird auch als “Dienst für hohe Verfügbarkeit” oder HA-Broker bezeichnet (siehe Abbildung oben).

    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. 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 Cloud Connector installieren. Die lokale Hostcachedatenbank kann nicht für mehrere Cloud Connectors genutzt 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 Konfigurationsdaten kopiert.

Bei einem Ausfall

Abbildung eines Ausfalls

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 mit Citrix Cloud. 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 Citrix Cloud 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 zu Synchronisierungen und Ausfällen.

Es gibt keine zeitliche Begrenzung für den Betrieb in Ausfallmodus.

Sie können einen Ausfall auch absichtlich auslösen. Informationen zu Zweck und Vorgehensweise finden Sie unter Erzwingen eines Ausfalls.

Ressourcenstandorte mit mehreren Cloud Connectors

Unter anderem hat der CSS die Aufgabe, den sekundären Broker regelmäßig mit Informationen zu allen Cloud Connectors am Ressourcenstandort zu versorgen. Anhand dieser Informationen sind die Sekundärbroker über alle anderen Sekundärbroker, die auf Cloud Connectors am Ressourcenstandort ausgeführt werden, unterrichtet.

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 neu. Die nicht gewählten sekundären Broker in der Zone weisen eingehende Verbindungs- und VDA-Registrierungsanfragen aktiv ab.

Wichtig:

Connectors innerhalb eines Ressourcenstandorts müssen in der Lage sein, einander über http://<FQDN_OF_PEER_CONNECTOR>:80/Citrix/CdsController/ISecondaryBrokerElection zu erreichen. Wenn Connectors unter dieser Adresse nicht kommunizieren können, werden möglicherweise mehrere Broker ausgewählt und während eines lokalen Hostcacheereignisses können zeitweise Startfehler auftreten.

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 Cloud Connector neu gestartet, passiert Folgendes:

  • Handelt es sich bei dem Cloud Connector nicht um den gewählten Broker, hat der Neustart keine Auswirkungen.
  • Handelt es sich um den gewählten Broker, wird ein anderer Cloud Connector gewählt und somit werden die VDAs registriert. Wenn der Neustart des Cloud Connectors beendet ist, übernimmt er automatisch das Brokering und somit werden die VDAs neu registriert. In diesem Szenario kann es während der Registrierungen zu Leistungseinbußen kommen.

Das Ereignisprotokoll enthält 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. Wenn der Ausfall jedoch auf einen Konnektivitätsverlust vom Ressourcenstandort zu Citrix Cloud zurückzuführen ist, empfiehlt Citrix die schnellstmögliche Wiederherstellung der Verbindung vom Ressourcenstandort.

Bei einem Ausfall:

  • Während eines lokalen Hostcache-Ereignisses kann möglicherweise vorübergehend nicht auf Studio zugegriffen werden. Wenn auf Studio zugegriffen werden kann, werden VDAs an Ressourcenstandorten, die im HA-Modus arbeiten, in Studio als nicht registriert angezeigt. Auf diese VDAs kann weiterhin über den lokalen Hostcache zugegriffen werden.

  • Sie haben eingeschränkten Zugriff auf das Remote PowerShell SDK.

    • Sie müssen zuerst Folgendes tun:
      • Fügen Sie einen Registrierungsschlüssel EnableCssTestMode mit dem Wert 1 hinzu: New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
      • Legen Sie die SDK-Authentifizierung auf OnPrem fest, damit der SDK-Proxy nicht versucht, die Cmdlet-Aufrufe umzuleiten: $XDSDKAuth="OnPrem"
      • Verwenden Sie Port 89: Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ContollerDNSName, DesktopGroupName, RegistrationState
    • Nachdem Sie diese Befehle ausgeführt haben, können Sie auf Folgendes zugreifen:
      • Alle Get-Broker*-Cmdlets.
  • Überwachungsdaten werden während eines Ausfalls nicht an Citrix Cloud gesendet. Daher enthalten die Überwachungsfunktionen keine Aktivität aus Ausfallintervallen.
  • 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.
  • Jede Zone agiert während eines LHC-Ereignisses unabhängig. Startvorgänge über Zonen hinweg (von einem Broker in einer Zone zu einem VDA in einer anderen Zone) werden während eines Ausfalls nicht unterstützt. Verwenden Sie die erweiterte Systemintegritätsprüfung von StoreFront, um Startanforderungen während eines LHC-Ereignisses an die entsprechende Zone weiterzuleiten.
  • Fällt vor einem geplanten Neustart von VDAs in einer Bereitstellungsgruppe die Sitedatenbank aus, beginnt der Neustart erst nach Ende des Ausfalls. Dieses Szenario 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 Ressourcenstandorten 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.

StoreFront

Wenn Sie eine On-Premises-StoreFront-Bereitstellung verwenden, müssen Sie alle Cloud Connectors, bei denen VDAs registriert sind (oder sein können), zu StoreFront als Delivery Controller hinzufügen. Ein Cloud Connector, der nicht zu StoreFront hinzugefügt wird, kann nicht in den Ausfallmodus wechseln, was zu Startfehlern für Benutzer führen kann.

Ressourcenverfügbarkeit

Es gibt zwei Möglichkeiten, die Verfügbarkeit von Ressourcen (Apps und Desktops) während eines Ausfalls sicherzustellen:

  • Veröffentlichen Sie die Ressourcen an jedem Ressourcenstandort in Ihrer Bereitstellung.
  • Bei Verwendung von StoreFront 1912 CU4 oder höher veröffentlichen Sie die Ressourcen an mindestens einem Ressourcenstandort und aktivieren die erweiterte Integritätsprüfung auf allen StoreFront-Servern. Für Versionen vor StoreFront 2308 ist die erweiterte Integritätsprüfung standardmäßig deaktiviert und muss von einem Administrator aktiviert werden. Für StoreFront ab Version 2308 ist dieses Feature standardmäßig aktiviert. Weitere Informationen und Anweisungen zum Aktivieren der erweiterten Integritätsprüfung finden Sie unter Erweiterte Integritätsprüfung.

Unterstützung für Anwendungen und Desktops

Der LHC unterstützt die folgenden Arten von VDAs und Bereitstellungsmodellen:

VDA-Typ Bereitstellungsmodell VDA-Verfügbarkeit bei LHC-Ereignissen
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 für energieverwaltete VDAs in gepoolten Bereitstellungsgruppen schlagen standardmäßig fehl.
Sie können sie für neue Verbindungen während LHC-Ereignissen 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 Eigenschaft ShutdownDesktopsAfterUse im normalen Betrieb funktioniert. Wenn der Zugriff auf diese Desktops während LHC 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 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 für gepoolte VDAs für Einzelsitzungs-OS mit Studio aktivieren

Mit Studio können Sie diese Maschinen für neue Verbindungen während LHC-Ereignissen pro Bereitstellungsgruppe verfügbar machen:

Hinweis:

Diese Einstellung ist in Studio nur für gepoolte Desktop-Bereitstellungsgruppen 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:

  1. Aktivieren Sie dieses Feature auf Siteebene, indem Sie den folgenden Befehl ausführen:

    Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

  2. 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

Funktionsprüfung des lokalen Hostcache

Erfahren Sie, wie Sie die Konfiguration des lokalen Hostcache überprüfen.

Überprüfung des lokalen Hostcache auf korrekte Einrichtung und fehlerfreien Betrieb:

  • Wenn Sie StoreFront verwenden, stellen Sie sicher, dass die lokale StoreFront-Bereitstellung auf alle Cloud Connectors an dem Ressourcenstandort verweist.
  • Vergewissern Sie sich, dass Synchronisierungsimporte erfolgreich abgeschlossen werden. Überprüfen Sie die Ereignisprotokolle.
  • 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 und HaDatabaseName_log.ldf erstellt wurden.
  • Erzwingen Sie einen Ausfall für alle Cloud Connectors am Ressourcenstandort. Vergessen Sie nicht, nach der Funktionsprüfung des lokalen Hostcache alle Cloud Connectors 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 Sync-Dienst

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. Dieses Ereignis tritt jedes Mal auf, wenn eine aktualisierte Konfiguration von Citrix Cloud eintrifft. Es 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.

Remote Broker Provider

Dieser Dienst fungiert als Proxy zwischen Citrix Cloud und Ihren VDAs und Cloud Connectors.

  • 3001: Prüft, ob Cloud Connectors in den HA-Modus wechseln müssen. Dieses Ereignis tritt nach einer einzigen fehlgeschlagenen Systemintegritätsprüfung des Cloud Connector auf. Schlägt eine zusätzliche Systemintegritätsprüfung nach 60 Sekunden fehl, wechselt der Cloud Connector in den HA-Modus.
  • 3002: Benachrichtigt darüber, dass der Cloud Connector nicht in den HA-Modus wechseln kann. Der Grund dafür, dass der HA-Modus nicht aufgerufen wurde, ist in den Ereignisinformationen enthalten.

  • 3003: Benachrichtigt darüber, dass der Cloud Connector verschiedene HA-Modusstatus durchläuft. Dieses Diagramm beschreibt die Status für das Aufrufen und Beenden des HA-Modus. Das Ereignis enthält Informationen zu:

    • dem Status, aus dem der Cloud Connector wechselt.
    • der Status, in den der Cloud Connector übergeht.
    • die Dauer des vorherigen Status.

Hinweis:

3001-Ereignisse kommen für Cloud Connectors häufig vor. Diese Ereignisse können auf Netzwerkfehler zurückzuführen sein und geben keinen Anlass zur Sorge.

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

Ein Cloud Connector kann zwar während eines erzwungenen Ausfalls aktualisiert werden, dabei können jedoch unvorhergesehene Probleme auftreten. Wir empfehlen das Festlegen eines Zeitplans für Cloud Connector-Updates, durch den Zeiten erzwungener Ausfälle vermieden werden.

Zum Erzwingen eines Ausfalls bearbeiten Sie die Registrierung jedes Cloud Connector-Servers. Erstellen Sie für HKLM\Software\Citrix\DesktopServer\LHC OutageModeForced und legen Sie REG_DWORD auf 1 fest. Dadurch wird der lokale Hostcachebroker angewiesen, unabhängig vom Zustand der Verbindung mit Citrix Cloud 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 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

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:

cd C:\Program Files\Citrix\Broker\Service\ControlScripts Import-Module .\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”. Datenbankdateien für den lokalen Hostcache müssen erfolgreich vom ConfigSync-Dienst 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. Um den lokalen Hostcache zu aktivieren, muss dieses Cmdlet auf allen Cloud Connectors innerhalb des Ressourcenstandorts ausgeführt werden.
Disable-LhcForcedOutageMode Beendet den Modus “Lokaler Hostcache” auf dem Broker. Dieses Cmdlet deaktiviert den Modus “Lokaler Hostcache” nur auf dem Cloud Connector, auf dem es ausgeführt wurde. Disable-LhcForcedOutageMode muss auf allen Cloud Connectors innerhalb des Ressourcenstandorts ausgeführt werden.
Set-LhcConfigSyncIntervalOverride Legt das Intervall fest, in dem Citrix Config Synchronizer Service (CSS) nach Konfigurationsänderungen innerhalb der Citrix DaaS-Site 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. Beispiel: Set-LhcConfigSyncIntervalOverride -Seconds 1200
Clear-LhcConfigSyncIntervalOverride Legt das Intervall fest, in dem Citrix Config Synchronizer Service (CSS) nach Konfigurationsänderungen innerhalb der Citrix DaaS-Site sucht. Standardwert 300 Sekunden (5 Minuten). 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 jedes Cmdlet Get-Broker* 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 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 Modus “Lokaler Hostcache” enthält der Broker des lokalen Hostcache auf dem ausgewählten Cloud Connector 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
Lokaler Hostcache
September 28, 2024
Beitrag von: 
C
September 28, 2024
Beitrag von: 
C

In diesem Artikel

Feedback zur Site | Your privacy choices footer linkIhre Datenschutzauswahl | Datenschutz und rechtliche Bestimmungen | Cookie-Einstellungen | Einstellungen für die Zustimmung | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.