Lokaler Hostcache

Hinweis:

Lokaler Hostcache ist derzeit nicht verfügbar.

Das Feature lokaler Hostcache ermöglicht die Fortsetzung der Verbindungsvermittlung, in einer XenApp und XenDesktop Service-Bereitstellung, wenn ein Cloud Connector nicht mit Citrix Cloud kommunizieren kann. Der lokale Hostcache wird aktiv, wenn die Netzwerkverbindung für 20 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.

Der lokale Hostcache ist in XenApp und XenDesktop Service immer aktiviert.

Funktionsweise

Normalbetrieb:

Abbildung des Normalbetriebs

  • Der Brokerprinzipal (Citrix Remote Broker Provider Service) auf einem Cloud Connector akzeptiert Verbindungsanfragen von StoreFront und 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 alle zwei Minuten 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 (HA-Broker des Citrix Diensts für hohe Verfügbarkeit in der Abbildung oben) auf dem Cloud Connector. Dabei werden nicht nur die seit der letzten Prüfung geänderten Elemente, sondern alle Konfigurationsdaten kopiert. Der sekundäre Broker importiert die Daten in eine Microsoft SQL Server Express-LocalDB-Datenbank auf dem Cloud Connector. Der CSS stellt sicher, dass die Informationen in der LocalDB-Datenbank des sekundären Brokers mit den Informationen in der Sitedatenbank in Citrix Cloud übereinstimmen. Die LocalDB-Datenbank wird bei jeder Synchronisierung neu erstellt.

Die LocalDB-Datenbank wird automatisch installiert, wenn Sie einen Cloud Connector installieren. Diese Datenbank kann nicht führe mehrere Cloud Connectors genutzt werden. Sie müssen die Datenbank nicht sichern, denn 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. Das CSS nimmt die Synchronisierung von Informationen wieder auf, wenn es 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.

Dsa 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 dazu, wozu dies dient und wie Sie dabei vorgehen finden Sie im Abschnitt “Erzwingen eines Ausfalls” weiter unten.

Ressourcenstandorte (Satellitenzonen) 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 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) sie, 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 primären Broker, hat der Neustart keine Auswirkungen.
  • Handelt es sich um den gewählten primären 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 erneut registriert. In diesem Szenario kann es während der Registrierungen zu Leistungseinbußen kommen.

Das Ereignisprotokoll enthält Informationen zu diesen Wahlen.

Einschränkungen, Faktoren und Anforderungen

Der lokale Hostcache wird für servergehostete Anwendungen und Desktops und statische (zugewiesene) Desktops unterstützt, nicht aber für gepoolte VDI-Desktops, die mit MCS oder PVS erstellt wurden.

Während eines Ausfalls nicht verfügbare Elemente und weitere Unterschiede

  • Sie können die Studio-Verwaltungsfunktionen in Citrix Cloud nicht für Elemente an einem ausgefallenen Ressourcenstandort verwenden und keine PowerShell-Cmdlets 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.
  • Energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen, für die die Eigenschaft “ShutdownDesktopsAfterUse” aktiviert ist, werden bei einem Ausfall in den Wartungsmodus versetzt.
  • Zugewiesene Maschinen können nur verwendet werden, wenn die Zuweisung vor dem Ausfall erfolgte. Neue Zuweisungen sind bei einem Ausfall nicht möglich.
  • Die automatische Registrierung und Konfiguration von Remote-PC-Zugriff-Maschinen ist nicht möglich. Maschinen, die vor dem Ausfall registriert und konfiguriert wurden, können jedoch Verbindungen akzeptieren.
  • Benutzer servergehosteter Anwendungen und Desktops können mehr Sitzungen verwenden als das für sie konfigurierte Sitzungslimit zulässt, wenn die Ressourcen an verschiedenen Ressourcenstandorten sind.

RAM-Größe

Der LocalDB-Dienst kann ca. 1,2 GB RAM belegen (bis zu 1 GB für den Datenbankcache plus 200 MB für die Ausführung von SQL Server Express LocalDB). Der Dienst für hohe Verfügbarkeit kann bis zu 1 GB RAM belegen, wenn ein Ausfall länger andauert und viele Anmeldungen erfolgen (z. B. 12 Stunden mit 10.000 Benutzern). Diese Speicheranforderungen verstehen sich zusätzlich zu den normalen RAM-Anforderungen des Cloud Connectors, d. h. Sie müssen möglicherweise die RAM-Kapazität erhöhen.

CPU-Kern- und Socketkonfiguration

Die CPU-Konfiguration eines Cloud Connectors, insbesondere die Zahl der für die SQL Server Express-LocalDB verfügbaren Kerne, wirkt sich direkt und in einem noch höheren Maß als die Speicherbelegung auf die Leistung des lokalen Hostcache aus. Der CPU-Mehraufwand tritt nur während eines Ausfalls auf, wenn die Datenbank nicht erreichbar und der Dienst für hohe Verfügbarkeit aktiv ist.

Die LocalDB kann zwar bis zu 4 Kerne verwenden, ist aber auf ein einziges Socket beschränkt. Durch Hinzufügen weiterer Sockets (z. B. mit 4 Sockets mit je 1 Kern) lässt sich die Leistung nicht verbessern. Stattdessen empfiehlt Citrix die Verwendung von mehreren Sockets mit mehreren Kernen. Bei von Citrix durchgeführten Tests lieferte eine 2x3-Konfiguration (2 Sockets, 3 Kerne) eine bessere Leistung als eine 4x1- oder 6x1-Konfiguration.

Speicher

Wenn Benutzer bei einem Ausfall auf Ressourcen zugreifen, wächst die LocalDB. Bei einem An-/Abmeldetest mit 10 Anmeldungen pro Sekunde vergrößerte sich die Datenbank beispielsweise alle 2 bis 3 Minuten um 1 MB. Wenn der normale Betrieb wieder aufgenommen wird, wird die lokale Datenbank neu erstellt, wenn eine Konfigurationsänderung erkannt wird. Der Broker benötigt auf dem Laufwerk, auf dem die LocalDB installiert ist, ausreichend Speicherplatz für das Wachstum der Datenbank. Beim lokalen Hostcache erfolgen während eines Ausfalls außerdem zusätzliche E/A-Vorgänge: ca. 3 MB Schreibvorgänge pro Sekunde bei mehreren Hunderttausend Lesevorgängen.

Leistung

Während eines Ausfalls verarbeitet ein Broker alle Verbindungen. An Ressourcenstandorten mit Lastausgleich zwischen mehreren Cloud Connectors muss der gewählte Broker daher möglicherweise viel mehr Anfragen verarbeiten als im Normalbetrieb. Die CPU-Anforderungen sind somit höher. Jeder einzelne Broker am Ressourcenstandort muss in der Lage sein, die zusätzliche, von der LocalDB und allen betroffenen VDAs verursachte Last zu verarbeiten, da der gewählte Broker bei einem Ausfall wechseln kann.

VDI-Grenzwerte:

  • In einer Bereitstellung mit einem Ressourcenstandort können während eines Ausfalls bis zu 10.000 VDAs effektiv bewältigt werden.
  • In VDI-Bereitstellungen mit mehreren Ressourcenstandorten können bis zu 10.000 VDAs pro Ressourcenstandort und insgesamt bis zu 40.000 VDAs pro Bereitstellung gehandhabt werden. Beispielsweise ist eine effektive Handhabung der folgenden Bereitstellungen während eines Ausfalls möglich:
    • Eine Bereitstellung mit vier sekundären Ressourcenstandorten mit jeweils 10.000 VDAs
    • Eine Bereitstellung mit sieben sekundären Zonen, von denen eine 10.000 VDAs enthält und die restlichen sechs je 5.000 VDAs

Bei einem Ausfall kann die Lastverwaltung beeinträchtigt werden. Lastauswertungsprogramme (und insbesondere Sitzungszahlregeln) werden möglicherweise überschritten.

Während der Zeit, die für die Registrierung aller VDAs bei einem Broker benötigt wird, hat der Broker evtl. nicht alle Informationen über die aktuellen Sitzungen. Die Verbindungsanfrage eines Benutzers kann während dieses Zeitraums daher zum Start einer neuen Sitzung führen, obwohl eine erneute Verbindung mit einer vorhandenen Sitzung möglich wäre. Dieses Intervall (des Abrufs von Sitzungsinformationen bei allen VDAs durch den neuen Broker) ist unvermeidlich. Auf Sitzungen, die bei Ausfallbeginn verbunden waren, hat das Übergangsintervall keine Auswirkungen, doch bei neuen Sitzungen und erneuten Sitzungsverbindungen ist eine Beeinträchtigung möglich.

Das Intervall tritt immer dann auf, wenn die VDAs sich bei einem anderen Broker registrieren müssen:

  • Ausfallbeginn: bei der Migration von einem Brokerprinzipal zu einem sekundären Broker
  • Brokerfehler während eines Ausfalls: bei der Migration von dem fehlerhaften sekundären Broker zu dem neu gewählten sekundären Broker
  • Wiederherstellung nach Ausfall: bei Wiederaufnahme des Normalbetriebs und der erneuten Übernahme der Steuerung durch den Brokerprinzipal

Die Dauer der Synchronisierung zwischen den Brokern erhöht sich mit steigender Anzahl der Objekte (VDAs, Anwendungen, Gruppen usw.). Die Synchronisierung von 5000 VDAs kann beispielsweise 10 Minuten oder länger dauern.

StoreFront

Wichtig:

Für jede Satellitenzone (Ressourcenstandort) muss StoreFront lokal installiert und konfiguriert sein. Der lokale Hostcache funktioniert nur bei Ressourcenstandorten mit lokalem StoreFront.

Unterschiede zu XenApp 6.x-Versionen

Die neue Implementierung des lokalen Hostcache hat zwar denselben Namen wie ein Feature in XenApp-Releases bis 6.x, weist jedoch einige wichtige Verbesserungen auf. Diese Implementierung ist robuster und beschädigungsresistent. Die Wartungsanforderungen wurden auf ein Minimum begrenzt (z. B. sind keine regelmäßigen dsmaint-Befehle mehr erforderlich). Der neue lokale Hostcache ist technisch völlig anders implementiert.

Verwalten des lokalen Hostcache

Bei der XenApp und XenDesktop Service-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 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 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 die Cloud Connectors an diesem Ressourcenstandort verweist.
  • Stellen Sie sicher, dass Synchronisierungsimporte erfolgreich abgeschlossen werden. Überprüfen Sie die Ereignisprotokolle.
  • Stellen Sie sicher, dass die LocalDB von SQL Server 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_logldf 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 ca. 15 Minuten dauern, um eine VDA-Registrierungsflut zu vermeiden.

Siehe auch Scalability considerations for using Local Host Cache with Cloud Connectors.

Ereignisprotokolle

Ereignisprotokolle enthalten Informationen zu Synchronisierungen und Ausfällen.

Config Synchronizer Service:

Im Normalbetrieb können beim Kopieren und Exportieren der Brokerkonfiguration durch den Config Service und beim Importieren in die LocalDB unter Einsatz des Diensts für hohe Verfügbarkeit (sekundärer Broker) die folgenden Ereignisse auftreten.

  • 503: Der Citrix Config Sync-Dienst erhielt eine aktualisierte Konfiguration. Dieses Ereignis tritt jedes Mal auf, wenn der Dienst für hohe Verfügbarkeit eine aktualisierte Konfiguration von Citrix Cloud erhält. Es zeigt den Beginn des Synchronisationsprozesses an. Nach dem Ergebnis folgt stets ein Ereignis vom Typ 504 oder 505.
  • 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 Hostcache 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:

  • 3502: Ein Ausfall ist aufgetreten und der sekundäre Broker (Dienst für hohe Verfügbarkeit) hat das Brokering übernommen.
  • 3503: Ein Ausfall wurde behandelt und der Normalbetrieb wieder aufgenommen.
  • 3504: Gibt an, welcher sekundäre Broker gewählt wurde und welche anderen Broker 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. Legen Sie unter “HKLM\Software\Citrix\DesktopServer\LHC” den Parameter “OutageModeForced” auf 1 fest. Dadurch wird der Broker 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 Broker beendet.

Problembehandlung

Mehrere Problembehandlungstools sind verfügbar, wenn ein Synchronisierungsimport in die LocalDB fehlschlägt und ein 505-Ereignis verzeichnet wird.

Ablaufverfolgung mit CDF: enthält Optionen für die Module ConfigSyncServer und BrokerLHC. In Kombination mit anderen Brokermodulen kann mit diesen Optionen das Problem 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 und sollte deaktiviert werden, wenn es nicht in Verwendung ist.

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 in folgendem Ordner gespeichert: The HTML report is posted at: C:\Windows\ServiceProfiles\NetworkService\ AppData\Local\Temp\CitrixBrokerConfigSyncReport.html

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