Product Documentation

Local Host Cache

Jun 20, 2017

Um sicherzustellen, dass die XenApp- und XenDesktop-Sitedatenbank immer verfügbar ist, empfiehlt Citrix, unter Befolgung der bewährten Methoden zur hohen Verfügbarkeit von Microsoft mit einer fehlertoleranten SQL Server-Bereitstellung zu beginnen. (Der Abschnitt "Datenbanken" des Artikels Systemanforderungen enthält eine Liste der in XenApp und XenDesktop unterstützten SQL Server-Features für hohe Verfügbarkeit.) Aufgrund von Netzwerkproblemen und Unterbrechungen können Benutzer jedoch evtl. keine Verbindung mit ihren Anwendungen oder Desktops herstellen.

Der lokale Hostcache (LHC) ermöglicht bei einem Systemausfall das fortgesetzte Verbindungsbrokering in einer XenApp- oder XenDesktop-Site. Ein Ausfall tritt auf, wenn:

  • ein Fehler bei der Verbindung zwischen einem Delivery Controller und der Sitedatenbank in einer lokalen Citrix Umgebung auftritt
  • ein Fehler bei der WAN-Verbindung zwischen Site und Citrix Steuerungsebene in einer Citrix Cloudumgebung auftritt

Der lokale Hostcache ist das umfassendste Feature für hohe Verfügbarkeit in XenApp und XenDesktop. Er ist eine leistungsfähigere Alternative zum Verbindungsleasing, das in XenApp 7.6 eingeführt wurde.

Die neue Implementierung des lokalen Hostcaches 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. Nachfolgend erfahren Sie, wie er funktioniert.

Funktionsweise

Die folgende Abbildung zeigt die Komponenten des lokalen Hostcaches und die im Normalbetrieb verwendeten Kommunikationspfade:

localized image

Normalbetrieb

  • Der Hauptbroker (Citrix Broker Service) auf einem Controller akzeptiert Verbindungsanfragen von StoreFront und kommuniziert zur Verbindung zwischen beim Controller registrierten Benutzern und VDAs mit der Sitedatenbank. 
  • Alle zwei Minuten wird die Konfiguration des Hauptbrokers auf Änderungen geprüft. Änderungen können von PowerShell-/Studio-Aktionen (z. B. Ändern der Eigenschaft einer Bereitstellungsgruppe) oder Systemaktionen (z. B. Maschinenzuweisungen) hervorgerufen werden.
  • Wenn seit der letzten Prüfung eine Änderung gemacht wurde, synchronisiert der Hauptbroker mithilfe von Citrix Config Synchronizer Service (CSS) die Informationen mit einem sekundären Broker (Citrix High Availability Service) auf dem Controller. Dabei werden nicht nur die seit der letzten Prüfung geänderten Elemente, sondern alle Brokerkonfigurationsdaten kopiert. Der sekundäre Broker importiert die Daten in eine Microsoft SQL Server Express-LocalDB-Datenbank auf dem Controller. Der CSS stellt sicher, dass die Informationen in der LocalDB-Datenbank des sekundären Brokers mit den Informationen in der Sitedatenbank übereinstimmen. Die LocalDB-Datenbank wird bei jeder Synchronisierung neu erstellt.
  • Wenn seit der letzten Prüfung keine Änderungen erfolgt sind, werden keine Daten kopiert. 

Die folgende Abbildung zeigt die Änderungen an den Kommunikationspfaden, wenn der Hauptbroker die Verbindung mit der Sitedatenbank verliert (d. h. zu Beginn eines Ausfalls):

localized image

Beginn eines Ausfalls

  • Der Hauptbroker kann nicht mehr mit der Sitedatenbank kommunizieren und beendet das Lauschen auf StoreFront- und VDA-Informationen (X in der Abbildung). Der Hauptbroker weist dann den sekundären Broker (High Availability Service) an, auf Verbindungsanforderungen zu lauschen und diese zu verarbeiten (rote gestrichelte Linie in der Abbildung).
  • Bei Ausfallbeginn hat der sekundäre Broker keine aktuellen VDA-Registrierungsdaten, aber sobald der VDA mit ihm kommuniziert, wird eine Neuregistrierung 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 Hauptbroker weiterhin die Verbindung mit der Sitedatenbank. Wenn die Verbindung wiederhergestellt ist, weist der Hauptbroker den sekundären Broker an, das Lauschen auf Verbindungsinformationen einzustellen, und nimmt das Verbindungsbrokering wieder auf. Wenn ein VDA das nächste Mal mit dem Hauptbroker kommuniziert, wird eine Neuregistrierung ausgelöst. Der sekundäre Broker entfernt alle verbleibenden VDA-Registrierungen aus dem vorherigen Ausfall und aktualisiert wieder die LocalDB-Datenbank mit den vom CSS empfangenen Konfigurationsänderungen.

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 über Synchronisierungen und Ausfälle. Weitere Informationen finden Sie unter "Überwachen" weiter unten.

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.

Sites mit mehreren Controllern

Unter anderem hat der CSS die Aufgabe, den sekundären Broker regelmäßig mit Informationen zu allen Controllern in der Zone zu versorgen. (Enthält Ihre Bereitstellung nicht mehrere Zonen, wirkt sich diese Aktion auf alle Controller in der Site aus.) Anhand dieser Informationen ist jeder sekundäre Broker über sekundäre Peerbroker informiert. 

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.

Das Ereignisprotokoll enthält Informationen zu diesen Wahlen. Weitere Informationen finden Sie unter "Überwachen" weiter unten.

Designüberlegungen 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).

Es gibt keine zeitliche Begrenzung für den Betrieb in Ausfallmodus. Allerdings sollten Sie den Normalbetrieb so schnell wie möglich wiederherstellen.

Auswirkungen eines Ausfalls

  • Sie können Studio nicht verwenden und keine PowerShell-Cmdlets ausführen.
  • 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.
  • Maschinen mit VDAs in gepoolten Bereitstellungsgruppen mit der Einstellung "Nach Verwendung herunterfahren" werden in den Wartungsmodus versetzt.
  • 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.

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 Controllers, d. h. Sie müssen möglicherweise die RAM-Kapazität erhöhen.

Wenn Sie SQL Server Express für die Sitedatenbank verwenden, gibt es zwei sqlserver.exe-Prozesse.

CPU-Kern- und Socketkonfiguration

Die CPU-Konfiguration eines Controllers, 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 Hostcaches 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. Bei Wiederaufnahme des Normalbetriebs wird die lokale Datenbank neu erstellt und der Speicherplatz wieder zurückgegeben. Der Broker benötigt jedoch 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

Bei einem Ausfall verarbeitet ein einziger Broker alle Verbindungen. In Sites (oder Zonen) mit Lastausgleich zwischen mehreren Controllern 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 in der Site (Zone) 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.

Hinweis: In diesem Release können bis 5000 VDAs während eines Ausfalls einwandfrei verarbeitet werden.

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

Während der Zeit, die für die Neuregistrierung 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 neu registrieren müssen: 

  • Ausfallbeginn: bei der Migration von einem Hauptbroker 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 Hauptbroker 

Sie können das Intervall verringern, indem Sie den Registrierungswert "HeartbeatPeriodMs" für Citrix Broker Protocol (Standardwert = 600000 ms, d. h. 10 Minuten) verringern, es lässt sich jedoch nicht vollständig eliminieren, egal wie schnell die VDAs sich registrieren. Mit dem folgenden Befehl ändern Sie beispielsweise den Heartbeat auf fünf Minuten (300.000 Millisekunden): 

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs
-PropertyType DWORD –Value 300000

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. Informationen zu Synchronisierungseinträgen im Ereignisprotokoll finden Sie unter "Überwachen" weiter unten.

Verwalten des lokalen Hostcaches

SQL Server Express-LocalDB

Die vom lokalen Hostcache verwendete Microsoft SQL Server Express-LocalDB wird automatisch installiert, wenn Sie einen Controller installieren oder von einer Version vor 7.9 aktualisieren. Die LocalDB erfordert keine Wartung durch den Administrator. Nur der sekundäre Broker kommuniziert mit dieser Datenbank, sie kann nicht mit PowerShell-Cmdlets geändert werden. Die LocalDB kann nicht für mehrere Controller freigegeben werden.

Die Datenbanksoftware der SQL Server Express-LocalDB wird unabhängig davon installiert, ob der lokale Hostcache aktiviert wird. 

Um die Installation zu verhindern, installieren bzw. aktualisieren Sie den Controller mit dem Befehl "XenDesktopServerSetup.exe" und verwenden Sie die Option /exclude "Local Host Cache Storage (LocalDB)". Der lokale Hostcache funktioniert allerdings nicht ohne die Datenbank und Sie können keine andere Datenbank für den sekundären Broker verwenden.

Hinweis: Die Installation der LocalDB-Datenbank ist irrelevant für die Entscheidung, ob Sie SQL Server Express zur Verwendung als Sitedatenbank installieren.

Standardeinstellungen nach Installation bzw. Upgrade von XenApp- oder XenDesktop

Die folgende Tabelle zeigt die Einstellungen für den lokalen Hostcache und das Verbindungsleasing nach einer neuen Installation von XenApp oder XenDesktop bzw. nach einem Upgrade von XenApp oder XenDesktop auf eine unterstützte Version ab 7.12.

Vorgang

Zahl der VDAs

Verbindungsleasing vor Vorgang

Lokaler Hostcache nach Vorgang

Verbindungsleasing nach Vorgang

Installation

Beliebig

-

Deaktiviert

Aktiviert

Upgrades

< 5000

Aktiviert

Deaktiviert

Aktiviert

Upgrades

< 5000

Deaktiviert

Aktiviert

Deaktiviert

Upgrades

> 5K

Aktiviert

Deaktiviert

Aktiviert

Upgrades

> 5K

Deaktiviert

Deaktiviert

Deaktiviert

 

Installation: Nach einer neuen Installation von XenApp oder XenDesktop ist der lokale Hostcache deaktiviert und das Verbindungsleasing standardmäßig aktiviert. 

Upgrade: Die Zahl der VDAs in einer Site wirkt sich auf die Einstellung für den lokalen Hostcache nach einem Upgrade aus. Die Einstellung für das Verbindungsleasing ändert sich bei einem Upgrade nicht.

Sites mit weniger als 5000 VDAs:

  • Der lokale Hostcache wird aktiviert, wenn das Verbindungsleasing vor dem Upgrade deaktiviert war. Das Verbindungsleasing bleibt deaktiviert.
  • Der lokale Hostcache wird deaktiviert, wenn das Verbindungsleasing vor dem Upgrade aktiviert war. Das Verbindungsleasing bleibt aktiviert.

Sites mit 5000 oder mehr VDAs:

  • Der lokale Hostcache ist deaktiviert (unabhängig von der Einstellung des Verbindungsleasings) und das Verbindungsleasing behält die Einstellung von vor dem Upgrade bei.

Aktivieren und Deaktivieren des lokalen Hostcaches

Zum Aktivieren des lokalen Hostcache geben Sie Folgendes ein:

Set-BrokerSite - LocalHostCacheEnabled $true - ConnectionLeasingEnabled $false

Dieses Cmdlet deaktiviert außerdem das Verbindungsleasing. Aktivieren Sie den lokalen Hostcache und das Verbindungsleasing nicht gleichzeitig.

Um zu ermitteln, ob der lokale Hostcache aktiviert ist, geben Sie Folgendes ein:

Get-BrokerSite

Vergewissern Sie sich, dass die Eigenschaft "LocalHostCacheEnabled" auf "True" und die Eigenschaft "ConnectionLeasingEnabled" auf "False" eingestellt ist.

Zum Deaktivieren des lokalen Hostcache und Aktivieren des Verbindungsleasings geben Sie Folgendes ein:

Set-BrokerSite - LocalHostCacheEnabled $true - ConnectionLeasingEnabled $false

Erzwingen eines Ausfalls

In folgenden Situationen kann das Erzwingen eines Datenbankausfalls 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 vermieden.
  • Zum Testen eines Notfallwiederherstellungsplans
  • Beim Ersetzen oder Warten des Sitedatenbankservers

Zum Erzwingen eines Ausfalls bearbeiten Sie die Registrierung aller Server, die einen Delivery Controller enthalten.

  • Legen Sie unter "HKLM\Software\Citrix\DesktopServer\LHC" den Parameter "OutageModeForced" auf 1 fest. Dadurch wird der Broker angewiesen, unabhängig vom Zustand der Datenbank in den Ausfallmodus zu wechseln. (Wenn Sie den Wert auf 0 festlegen wird der Ausfallmodus auf dem Server beendet.)
  • In einer Citrix Cloud wechselt der Connector unabhängig vom Zustand der Verbindung mit der Steuerungsebene oder der primären Zone in den Ausfallmodus.

Überwachung

Ereignisprotokolle enthalten Informationen zu Synchronisierungen und Ausfällen.

Config Synchronizer Service

Im Normalbetrieb können beim Kopieren und Exportieren der Brokerkonfiguration durch den CSS und beim Importieren in die LocalDB unter Einsatz des High Availability Service (sekundärer Broker) die folgenden Ereignisse auftreten.

  • 503: Es wurde eine Änderung an der Konfiguration des Hauptbrokers erkannt und ein Import wird gestartet.
  • 504: Die Brokerkonfiguration wurde erfolgreich kopiert, exportiert und in die LocalDB importiert.
  • 505: Der Import in die LocalDB ist fehlgeschlagen (siehe weiter unten).

Dienst für hohe Verfügbarkeit

  • 3502: Ein Ausfall ist aufgetreten und der sekundäre Broker (High Availability Service) 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. 

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 in der Regel identifiziert werden.

Bericht: Sie können einen Bericht mit Informationen zu dem Fehlerpunkt erstellen. 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 Folgendes 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 gespeichert.

Wenn der Bericht generiert wurde, deaktivieren Sie das Berichtsfeature mit folgendem Befehl:

Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0

Exportieren der Brokerkonfiguration: stellt die exakte Konfiguration zum Debuggen zur Verfügung.

Export-BrokerConfiguration | Out-File

Beispiel: Export-BrokerConfiguration | Out-File C:\BrokerConfig.xml.