Lokaler Hostcache

Der lokale Hostcache ermöglicht die Fortsetzung der Verbindungsvermittlung in einer Citrix Virtual Apps and Desktops-Bereitstellung, 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:

Jeder Ressourcenstandort muss über eine vom Kunden bereitgestellte On-Premises-StoreFront-Instanz verfügen. Der lokale Hostcache funktioniert nur bei Ressourcenstandorten mit lokalem StoreFront. Stellen Sie sicher, dass der Ressourcenstandort eine lokale StoreFront-Bereitstellung enthält, die auf alle Cloud Connectors an diesem Ressourcenstandort verweist.

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

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
  • Citrix Config Sync-Dienst (CSS) überprüft ungefähr jede Minute bei dem 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 im Cloud Connector. Dieser wird auch als Dienst für hohe Verfügbarkeit bzw. Hochverfügbarkeitsbroker 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. 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 sobald 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.

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:

  • Sie können Studio nicht verwenden und keine PowerShell-Befehle ausführen.
  • Überwachungsdaten werden während eines Ausfalls nicht an Citrix Cloud gesendet. Daher enthalten die Überwachungsfunktionen (Director) 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.
  • Benutzer können Anwendungen und Desktops nur von registrierten VDAs in der Zone starten, die den aktuell aktiven/gewählten Broker enthält. 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.
  • 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.

StoreFront

Jeder Ressourcenstandort muss über eine vom Kunden bereitgestellte On-Premises-StoreFront-Instanz verfügen. Der lokale Hostcache funktioniert nur bei Ressourcenstandorten mit lokalem StoreFront. Workspace wird nicht unterstützt.

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.
  • Veröffentlichen Sie die Ressourcen an mindestens einem Ressourcenstandort. Verwenden Sie dann das folgende Verfahren, um in jedem StoreFront-Store die erweiterte Integritätsprüfung zu aktivieren.

    1. Aktualisieren Sie die StoreFront-Installation an jedem Ressourcenstandort auf die Mindestversion 1912 CU1. Weitere Informationen finden Sie in der StoreFront-Dokumentation.
    2. Aktivieren Sie für jeden StoreFront-Store die erweiterte Integritätsprüfung. Fügen Sie in der Datei web.config des Stores unter farmsets die Zeichenfolge advancedHealthCheck="on" hinzu.

      Beispiel:

      Erweiterte Integritätsprüfung in StoreFront

    3. Nach dem Update der Datei starten Sie IIS manuell neu. Wiederholen Sie das Update der Datei web.config und den IIS-Neustart für andere Stores.

Unterstützung für Anwendungen und Desktops

Der lokale Hostcache funktioniert nur mit StoreFront, das vom Kunden bereitgestellt wird. Workspace wird nicht unterstützt.

Der lokale Hostcache unterstützt servergehostete Anwendungen und Desktops und statische (zugewiesene) Desktops.

Der lokale Hostcache unterstützt Desktop-VDAs in gepoolten Bereitstellungsgruppen wie folgt.

  • Standardmäßig werden energieverwaltete Desktop-VDAs in gepoolten (und mit MCS oder Citrix Provisioning erstellten) Bereitstellungsgruppen, für die die Eigenschaft ShutdownDesktopsAfterUse aktiviert ist, bei einem Ausfall in den Wartungsmodus versetzt. Sie können diese Standardeinstellung ändern, damit solche Desktops während eines Ausfalls verwendet werden können.

    Während des Ausfalls können Sie sich jedoch nicht auf die Energieverwaltung verlassen. (Die Energieverwaltung wird bei Wiederaufnahme des Normalbetriebs wieder aufgenommen.) Solche Desktops können außerdem Daten des vorherigen Benutzers enthalten, weil sie nicht neu gestartet wurden.

  • Um das Standardverhalten außer Kraft zu setzen, muss es Site-übergreifend für jede betroffene Bereitstellungsgruppe aktiviert werden. Wenden Sie sich an den Support, um es Site-übergreifend zu aktivieren (dieser Befehl kann nicht mit dem Remote PowerShell SDK ausgeführt werden).

    Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

    Führen Sie den folgenden PowerShell-Befehl für jede betroffene Bereitstellungsgruppe aus.

    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.

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, der lokale Hostcachebroker ist jedoch technisch eine völlig andere Implementierung. Die Implementierung bietet signifikante Verbesserungen, sie ist robuster und immun gegen Beschädigung und sie erfordert weniger Wartung.

Verwalten des lokalen Hostcache

Bei der Citrix Virtual Apps and Desktops-Bereitstellung ist der lokale Hostcache immer aktiviert. Sie müssen nichts tun, um ihn zu konfigurieren oder zu verwalten.

Wie bereits erwähnt, wird die Microsoft SQL Express LocalDB-Datenbank automatisch installiert, wenn Sie einen Cloud Connector an einem Ressourcenstandort installieren. Versuchen Sie nicht, sie zu deaktivieren oder zu entfernen. Citrix aktualisiert den Cloud Connector regelmäßig. Wenn Sie die Microsoft SQL Express LocalDB-Software manuell deaktivieren oder entfernen, wird sie durch die nächste Cloud Connector-Aktualisierung ersetzt.

Funktionsprüfung des lokalen Hostcache

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

  • Stellen Sie sicher, dass der Ressourcenstandort eine lokale StoreFront-Bereitstellung enthält, die auf alle Cloud Connectors an diesem Ressourcenstandort verweist.
  • Stellen Sie sicher, 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.
  • Führen Sie das Erzwingen eines Ausfalls für alle Cloud Connectors am Ressourcenstandort durch. 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 mithilfe des 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 Problembehandlung 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.

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.

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

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 Synchronisationsimport 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

Weitere Informationen

Unter Überlegungen zur Skalierung und Größe für den lokalen Hostcache finden Sie weitere Informationen zu folgenden Themen:

  • Testmethoden und -ergebnisse
  • RAM-Größe
  • CPU-Kern- und Socketkonfiguration
  • Speicher