Tech Brief: Lokaler Hostcache/Hochverfügbarkeitsmodus für Citrix Virtual Apps and Desktops Service

Übersicht

Local Host Cache (LHC) kann im Rahmen des Dienstes Citrix Virtual Apps and Desktops (CVAD) als Versicherungspolice angesehen werden. Diese Versicherungspolice kommt ins Spiel, wenn die Citrix Cloud Connectors aus irgendeinem Grund (Ausfälle, Verbindungsprobleme, Internet-Blackouts usw.) nicht mit dem Citrix Brokering-Dienst kommunizieren können (Teil des CVAD-Dienstes und fortan als Cloud-Broker bezeichnet). Ein Kommunikations-Zusammenbruch zwischen einem Ressourcenstandort und dem Cloud-Broker kann zu Auswirkungen auf die Endbenutzer führen - Local Host Cache wurde entwickelt, um die Auswirkungen solcher Endbenutzer zu minimieren.

Local Host Cache ist eine Kombination aus mehreren Diensten und Komponenten, die zusammenkommen, um die Brokering-Verantwortlichkeiten zu übernehmen, bis die Verbindung zum Cloud-Broker wiederhergestellt werden kann.

Abbildung 1: Konzeptionelle Darstellung des CVAD-Dienstes, der für den HA-Modus relevante Komponenten zeigt

Cloud Connector-Komponenten

Innerhalb des Citrix Cloud Connector gibt es mehrere Komponenten, die für die lokalen Host-Cache-Vorgänge erforderlich sind.

• Configuration Synchronizer-Dienst: Der Configuration Synchronizer-Dienst (CSS) überprüft regelmäßig den Cloud-Broker (alle 60 Sekunden), um festzustellen, ob Konfigurationsänderungen vorgenommen wurden. Die Änderungen können vom Administrator initiiert sein (z. B. das Ändern einer Bereitstellungsgruppeneigenschaft) oder Systemaktionen (wie Maschinenzuweisungen). Wenn Änderungen erkannt werden, synchronisiert CSS die Änderungen vom Cloud-Broker mit den Connector-Computern.
• LocalDB: Das CSS importiert die Konfigurationsdaten in eine Microsoft SQL Server Express LocalDB-Datenbank. Für jeden Synchronisierungsvorgang wird eine neue Instanz der Datenbank erstellt. Sobald die Synchronisierung erfolgreich abgeschlossen ist, ersetzt die neueste DB-Instanz die vorherige DB-Instanz.
• High Availability Service : Der High Availability Service (HA Service) ist ein spezialisierter Brokerdienst, der die Runtime Brokering-Funktionalität während eines Ausfalls bereitstellt. Der HA-Dienst wird auch als sekundärer Broker bezeichnet.
• Remote Broker-Anbieter: Der Remote Broker-Anbieter führt mehrere wichtige Funktionen aus:
  • Er fungiert als Proxy, vermittelt Kommunikation zwischen dem Citrix Virtual Delivery Agent (VDA) und dem Cloud Broker
  • Er fungiert als Proxy, vermittelt Kommunikation zwischen einem on-premises StoreFront oder einem on-premises ADC und den verschiedenen Citrix Cloud-Diensten
  • Es bestimmt, wann ein Ressourcenstandort zwischen dem HA-Modus und dem normalen Betrieb umgeschaltet werden soll

Abbildung 2: Connector-Komponenten und -Dienste, die eine Rolle im HA-Modus spielen

Die ordnungsgemäße Dimensionierung der Cloud Connector-Maschinen ist ein wichtiger Schritt, um sicherzustellen, dass die entsprechenden Ressourcen für die Dienste im Hochverfügbarkeitsmodus verfügbar sind. Weitere Informationen finden Sie im Artikel zu Maßstäben und Größen .

Hochverfügbarkeitsmodus

Citrix Cloud Connectors sind in der Lage, den HA-Modus automatisch ohne Eingreifen des Administrators zu verlassen. Der HA-Modus kann durch Folgendes ausgelöst werden:

• Ausfall von StoreFront-Aufzählungen oder Startanfragen
• Versäumnis, die Kommunikation zwischen dem VDA und dem Cloud Broker weiterzuleiten
• Versäumnis, Secure Ticket Authority (STA) -Anfragen an den CVAD-Dienst im Namen eines on-premises ADC während eines Starts zu präsentieren

Während des HA-Modus übernimmt der HA-Dienst mehrere wichtige Vermittlungsfunktionen, zählt Ressourcen auf, veröffentlicht die Sitzung und akzeptiert VDA-Registrierungen. Darüber hinaus agiert der HA-Service als STA-Anbieter. An einem Ressourcenstandort mit mehreren Cloud Connectors kommunizieren die HA Services im Rahmen eines Wahlprozessesmiteinander. Dieser Wahlprozess legt fest, welche Instanz des HA-Dienstes übernimmt, wenn der HA-Modus ausgelöst wird.

Abbildung 3: Ressourcenstandort im HA-Modus

Hochverfügbarkeits-Modus eingehen/beenden

Die Entscheidung, in den HA-Modus zu wechseln, hängt von der Aufzählung und dem Startverkehr ab, der durch eine bestimmte Cloud Connector-Instanz fließt. Nur Connector-Computer, die in StoreFront als Delivery Controller konfiguriert wurden, unterstützt die Erkennung und den Übergang im HA-Modus. Diese Optimierung ist notwendig, um unnötige VDA-Registrierungen zu vermeiden.

Während des gesamten Zyklus des Ein- und Ausstiegs des HA-Modus gibt es mehrere Zustände. Während des Status “ Working Normal “ sind alle Komponenten fehlerfrei und alle Broker-Transaktionen werden vom Cloud-Broker abgewickelt. Das CSS repliziert aktiv die Konfigurationen vom Cloud-Broker auf die Connector-Computer.

Falls einige der Komponenten nicht fehlerfrei gemeldet werden, wechselt der Konnektor in den Status Ausstehend HA. In diesem Zustand wird ein umfassender Gesundheitscheck eingeleitet, um die nächste Vorgehensweise zu bestimmen. Die Konnektoren interagieren mit anderen Konnektoren am Ressourcenstandort, um ihren Systemzustand zu bestimmen. Die Entscheidung, von ausstehender HA zu Initial HA zu wechseln, basiert auf dem Integritätsstatus aller Konnektoren an einem bestimmten Ressourcenstandort. Wenn die Zustandsprüfungen erfolgreich sind, werden die Konnektoren wieder in den Status Working Normal übergehen. Wenn die Zustandsprüfungen weiterhin fehlschlagen, wechseln die Konnektoren alternativ in den Status Anfänglich HA.

Abbildung 4: Connectorstatus für den eingehenen/bestehenden HA-Modus

Während des Status Anfänglich HA übernimmt der Hochverfügbarkeitsdienst auf dem Konnektor die Verantwortlichkeiten für die Vermittlung. Alle VDAs am aktuellen Ressourcenstandort, die beim Cloud Broker registriert wurden, werden beim HA Service/Secondary Broker auf dem Connector registriert. Am Ende von Initial HA werden Gesundheitschecks eingeleitet. Wenn alle Zustandsprüfungen erfolgreich sind, wechselt der Status auf Ausstehende Wiederherstellung, andernfalls wird der Status auf Extended HA überführt.

Die Zustandsprüfungen werden während des erweiterten HA-Zeitraums fortgesetzt, und wenn alle Zustandsprüfungen erfolgreich sind, wechselt der Status auf Ausstehende Wiederherstellung. Es gibt keine maximale Zeitdauer, bis ein Connector im Status Extended HA verbleibt.

Die ausstehende Wiederherstellung dient als Wartezeit, in der alle Komponenten fehlerfrei sind, bevor die Vermittlung an den Cloud-Broker zurückgegeben wird. Wenn eine der Zustandsprüfungen während der Ausstehende Wiederherstellung fehlschlägt, wechselt der Status zurück zu Extended HA. Wenn alle Zustandsprüfungen während der gesamten Ausstehenden Wiederherstellungsfrist erfolgreich sind, wechselt der Status auf Working Normal. Mit dieser Umstellung ist der HA-Modus beendet, und alle VDAs am Ressourcenstandort, die beim sekundären Broker registriert waren, registrieren sich jetzt erneut beim Cloud-Broker.

CVAD-Dienstinstanz mit mehreren Ressourcenstandorten

Der Cloud-Broker ist darauf ausgelegt, einen Überblick über die gesamte Bereitstellung zu erhalten — über mehrere Ressourcenstandorte hinweg. Wenn sich jedoch im HA-Modus befindet, wird jeder Ressourcenstandort zu seinem eigenen unabhängigen Pod, und der gewählte sekundäre Broker an jedem Ressourcenstandort verwaltet die Broker-Transaktionen nur für die VDAs innerhalb dieses Ressourcenstandorts. Dieses Design ist ein wichtiger Grund, um sicherzustellen, dass die StoreFront so konfiguriert ist, dass sie alle Cloud Connectors von allen Ressourcenstandorten enthält, die VDA-Workloads enthalten. Die StoreFront kann dann Startanforderungen verteilen und Benutzer effektiv über mehrere Ressourcenstandorte ausgleichen.

VDA-Registrierungen

Wenn der Ausfall beginnt, verfügt der gewählte sekundäre Broker (lesen Sie den Abschnitt über mehrere Konnektoren an einem Ressourcenstandort, um mehr über den Wahlprozess zu erfahren) keine aktuellen VDA-Registrierungsdaten, aber wenn ein VDA mit ihm kommuniziert, wird ein Registrierungsprozess ausgelöst. Während dieses Prozesses erhält der gewählte sekundäre Broker auch aktuelle Sitzungsinformationen für diesen VDA. Der VDA kommuniziert mindestens alle 5 Minuten mit dem Broker. Je nachdem, wann der letzte Heartbeat abgeschlossen wurde, kann es bis zu 5 Minuten dauern, bis ein VDA vom Cloud-Broker zum gewählten sekundären Broker realisiert und die Registrierung beim gewählten sekundären Broker ausgelöst wird.

Während der gewählte sekundäre Broker Verbindungen verarbeitet, überwacht der Remote-Broker-Anbieter die Verbindung zu Citrix Cloud. Wenn die Verbindung wiederhergestellt ist, weist der Remote-Broker-Anbieter den gewählten sekundären Broker an, die Suche nach Verbindungsinformationen einzustellen, und übermittelt den Brokerbetrieb erneut an den Cloud-Broker. Wenn ein VDA das nächste Mal mit dem Remote-Broker-Anbieter kommuniziert, wird ein weiterer Registrierungsprozess ausgelöst. Der gewählte Sekundärbroker 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.

Mehrere Konnektoren an einem Ressourcenstandort

Citrix empfiehlt mindestens 2 Konnektoren an jedem Ressourcenstandort/-bereich. In jeder Zone läuft ständig ein Wahlprozess, um sicherzustellen, dass die HA-Services wissen, welcher Connector-Computer bei einer Unterbrechung die Verantwortung für die Vermittlung übernehmen würde. Diese Wahl findet immer statt — sowohl im normalen Betrieb als auch beim Betrieb im HA-Modus.

Das CSS stellt dem sekundären Broker routinemäßig Informationen über alle Cloud Connectors am Ressourcenstandort zur Verfügung. Mit diesen Informationen weiß jeder Konnektor über alle Peer-Connectors Bescheid, die am Ressourcenstandort ausgeführt werden. Die sekundären Broker kommunizieren miteinander über einen anderen Kanal. Diese Dienste verwenden eine alphabetische Liste von FQDN-Namen der Maschinen, auf denen sie laufen, um den gewählten sekundären Broker in der Zone zu ermitteln, wenn ein Ausfall auftritt. Im HA-Modus übernimmt der gewählte sekundäre Broker die Verantwortung für die Vermittlung, während die anderen sekundären Broker in der Zone eingehende Verbindungs- und VDA-Registrierungsanfragen aktiv ablehnen.

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. Wenn im HA-Modus ein Connector neu gestartet wird:

• Wenn dieser Konnektor nicht der gewählte sekundäre Broker ist, hat der Neustart keine Auswirkungen.
• Wenn dieser Konnektor der gewählte sekundäre Broker ist, wird ein anderer Cloud Connector gewählt, wodurch sich VDAs beim neu gewählten sekundären Broker registrieren. 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. Weitere Informationen zu den zugehörigen Ereignissen finden Sie im Artikel Ereignisprotokolle in der Produktdokumentation.

Lokaler Hostcache mit mehreren Ressourcenstandorten

Lastenausgleich zwischen Konnektoren an einem Ressourcenstandort

Die on-premises StoreFront sendet standardmäßig alle 60 Sekunden eine Heartbeat-Meldung an alle Cloud Connectors, die in ihrem Store konfiguriert sind. Nur gesunde Cloud Connectors (die erfolgreich auf den Heartbeat reagieren) werden für die Aufzählung und die Startanfrage der Load Balancing-App berücksichtigt. Die gleiche Heartbeat-Anfrage an die Cloud Connectors aktiviert den Connector auch, um am in den vorherigen Abschnitten beschriebenen HA-Modus-Algorithmus teilzunehmen. Um sicherzustellen, dass alle Ressourcenstandorte im HA-Modus ausgeführt werden können, muss sichergestellt werden, dass bei der on-premises StoreFront alle Cloud Connectors in der StoreFront-Konfiguration als Delivery Controller identifiziert werden. Wenn keine geeigneten StoreFront-Konfigurationen vorhanden sind, kann dies zu einem Kapazitätsverlust führen, wenn die Site in den HA-Modus wechselt.

Abbildung 5: Bereitstellung mit mehreren Ressourcenstandorten, bei denen eine RL aufgrund fehlender Konfigurationen nicht HA-fähig ist

HA-Modus für Ressourcenstandorte, die dieselben Apps/Desktops veröffentlichen

Eines der CVAD-Service-Bereitstellungsmodelle umfasst mehrere Ressourcenstandorte — alle veröffentlichen identische Anwendungen und Desktops an den Ressourcenstandorten. Beispielsweise kann eine Bereitstellung, die Anwendungen von einem einzelnen Multi-Session-Image oder gepoolten VDI-Desktops enthält, einheitlich an allen Ressourcenstandorten bereitgestellt werden.

Wenn eine solche Bereitstellung im HA-Modus ausgeführt wird, können Benutzer an den verschiedenen konfigurierten Ressourcenstandorten zu einer der VDAs weitergeleitet werden. In diesem Szenario gleicht die StoreFront-Last Anforderungen an alle konfigurierten Cloud Connectors an verschiedenen Ressourcenstandorten aus.

HA-Modus für Ressourcenstandorte, die verschiedene Apps/Desktops veröffentlichen

Bei einer CVAD-Dienstbereitstellung sind möglicherweise auch bestimmte Anwendungen nur an einer bestimmten Teilmenge von Ressourcenstandorten verfügbar. Beispielsweise ist ein japanischer OS-Desktop möglicherweise nur auf den in Japan ausgeführten VDAs verfügbar. Ein anderes Beispiel sind statische/zugewiesene Desktops, die benutzerspezifisch sind und nach der Zuweisung an einen bestimmten Ressourcenstandort gebunden sind.

Wenn eine solche Bereitstellung im HA-Modus ausgeführt wird, müssen die Anwendungs- oder Desktopstartanfragen an den entsprechenden Cloud Connector an den spezifischen Ressourcenstandort weitergeleitet werden, an denen sich die Apps und Desktops befinden, da das zonenübergreifende Brokering im HA-Modus nicht verfügbar ist. Die von StoreFront 1912 LTSR Cumulative Update 1 oder höher angebotene AdvancedHealthCheck-Funktion stellt solche Bereitstellungen wie im folgenden Absatz beschrieben zur Verfügung.

Die StoreFront zählt Anwendungen und Desktops von Cloud Connectors in jeder Region auf. Die Aufzählungsinformationen enthalten jetzt eine Zuordnung zwischen der Ressource (einer Anwendung oder einem Desktop) und den Ressourcenstandorten, an denen sich die Anwendung/der Desktop befindet. Diese Zuordnung wird verwendet, um die Startanfragen des Benutzers an bestimmte Ressourcenstandorte zu leiten. Lesen Sie die in der Produktdokumentation aufgeführten Konfigurationsschritte durch, damit StoreFront diese Funktion nutzen kann.

Architekturen mit Citrix ADC

Überwachen

Die Citrix ADC Appliance bietet einen integrierten Monitor, CITRIX-XD-DDC-Monitor, der die Server von Citrix Virtual Apps and Desktops Delivery Controller überwacht. Im Zusammenhang mit dem Citrix Virtual Apps and Desktops Service entsprechen die Cloud Connectors den Delivery Controller-Servern. Der Monitor sendet eine Sonde an die konfigurierten Controller-/Konnektorserver in Form einer XML-Nachricht. Wenn der Server auf die Sonde mit der Identität der Farm antwortet, gilt die Sonde als erfolgreich und der Status des Servers wird als UP markiert. Wenn die Antwort keinen Erfolgscode hat oder die Identität der Serverfarm in der Antwort nicht vorhanden ist, wird der Test als Fehler angesehen und der Status des Servers wird als DOWN markiert.

Weitere Informationen zum CITRIX-XD-DDC-Monitor finden Sie in der Citrix ADC-Dokumentation.

Citrix ADC für Ressourcenstandorte, die verschiedene Apps/Desktops veröffentlichen

Für Architekturen mit Citrix ADC mit Ressourcenstandorten, die verschiedene Apps und Desktops veröffentlichen, müssen die folgenden Konfigurationen durchgeführt werden.

• Aggregieren Sie die Cloud Connectors an jedem Ressourcenstandort zu einem eindeutigen VIP im ADC-Load Balancer.
• Aktivieren Sie die StoreFront AdvancedHealthCheck-Funktion wie hierbeschrieben.
• Ordnen Sie jede Zone/Ressourcenstandort einer virtuellen ADC-IP (VIP) zu
• Fügen Sie alle ADC-VIPs als Delivery Controller zur StoreFront hinzu.
• Richten Sie den ADC-Load Balancer ein, um die Cloud Connectors an jedem Ressourcenstandort über den CITRIX-XD-DDC-Monitor zu überwachen.

Abbildung 6: Bereitstellung mit mehreren Ressourcenstandorten und Citrix ADC

Überlegungen zu gepoolten Desktop-VDA-Arbeitslast

Wenn sich ein Benutzer von einem gepoolten Desktop-VDA abmeldet, wird das Image des VDA zurückgesetzt, um alle benutzerspezifischen Daten auf dem VDA zu entfernen. Wenn eine Site im HA-Modus läuft, ist der Reset-Vorgang nicht verfügbar. Wenn sich ein Benutzer von einem gepoolten Desktop-VDA abmeldet, wird die Maschine in den Wartungsmodus versetzt. Dieser Reset verhindert, dass ein beschädigtes Images einem anderen Benutzer zur Verfügung gestellt wird.

Abhängig von den Sicherheitsanforderungen für eine Implementierung kann dieses Verhalten durch ein standortweites und ein Update pro Liefergruppe geändert werden. Weitere Informationen zum Überschreiben des Standardverhaltens finden Sie in der Produktdokumentation.

Für gepoolte Desktop-VDA-Workloads, die auf VMware vSphere und Citrix Hypervisor ausgeführt werden, ist eine neue Funktion verfügbar, die die Unterstützung für den Energiebetrieb im HA-Modus einführt, als frühe Vorschau. Diese Funktion bietet die Möglichkeit, Images zurückzusetzen, selbst wenn eine Site im HA-Modus funktioniert. Lesen Sie hiermehr über das Vorschau-Angebot.

Testen des lokalen Hostcache

Der lokale Host-Cache ist so konzipiert, dass er ohne Benutzereingriff funktioniert - - er ist vollständig autonom. Sie können jedoch überprüfen, ob alle Cloud Connectors korrekt synchronisiert sind und zur Übernahme bereit sind. Die folgenden Schritte werden empfohlen:

• Wie in den früheren Abschnitten beschrieben, führt jeder Konnektor die Synchronisierung der Standortkonfiguration unabhängig durch. Die Ergebnisse der Synchronisierung sind in der Ereignisanzeige verfügbar. Einzelheiten zu den Ereignissen finden Sie im Abschnitt Ereignisprotokolle der Produktdokumentation.
• Ein Ausfall kann simuliert werden, um die Local Host Cache-Lösung in einer Umgebung zu testen. Eine Anleitung zum Erzwingen eines Ausfalls finden Sie in der Produktdokumentation. Achten Sie beim Erzwingen eines Ausfalls besonders darauf, alle Konnektoren an einem Ressourcenstandort auf den erzwungenen Ausfallmodus zu setzen.