Lokaler Hostcache

Um sicherzustellen, dass die Citrix Virtual Apps and Desktops-Sitedatenbank immer verfügbar ist, empfiehlt Citrix, mit einer fehlertoleranten SQL Server-Bereitstellung zu beginnen, indem die Best Practices für Hochverfügbarkeit von Microsoft befolgt werden. (Informationen zu unterstützten SQL Server-Hochverfügbarkeitsfunktionen finden Sie unter Datenbanken.) Netzwerkprobleme und -unterbrechungen können jedoch dazu führen, dass Benutzer keine Verbindung zu ihren Anwendungen oder Desktops herstellen können.

Die Funktion Lokaler Hostcache ermöglicht die Fortsetzung von Broker-Vorgängen in einer Site, wenn ein Ausfall auftritt. Ein Ausfall tritt auf, wenn die Verbindung zwischen einem Delivery Controller™ und der Sitedatenbank in einer lokalen Citrix®-Umgebung fehlschlägt. Der Lokale Hostcache wird aktiviert, wenn die Sitedatenbank 90 Sekunden lang nicht erreichbar ist.

Ab XenApp and XenDesktop 7.16 wurde die Verbindungsleasing-Funktion (eine frühere Hochverfügbarkeitsfunktion in früheren Releases) aus dem Produkt entfernt und ist nicht mehr verfügbar.

Dateninhalt

Der lokale Hostcache enthält die folgenden Informationen, die eine Untermenge der Informationen in der Hauptdatenbank darstellen:

• Identitäten von Benutzern und Gruppen, denen Rechte für von der Site veröffentlichte Ressourcen zugewiesen sind.
• Identitäten von Benutzern, die derzeit veröffentlichte Ressourcen der Site verwenden oder kürzlich verwendet haben.
• Identitäten von VDA-Maschinen (einschließlich Remote PC Access-Maschinen), die in der Site konfiguriert sind.
• Identitäten (Namen und IP-Adressen) von Client-Citrix Receiver™-Maschinen, die aktiv zum Herstellen einer Verbindung zu veröffentlichten Ressourcen verwendet werden.

Er enthält auch Informationen für aktuell aktive Verbindungen, die hergestellt wurden, während die Hauptdatenbank nicht verfügbar war:

• Ergebnisse jeder Clientmaschinen-Endpunktanalyse, die von Citrix Receiver durchgeführt wurde.
• Identities of infrastructure machines (such as NetScaler Gateway and StoreFront™ servers) involved with the site.
• Datum, Uhrzeit und Art der letzten Aktivitäten von Benutzern.

Funktionsweise

Die folgende Grafik veranschaulicht die Komponenten des lokalen Hostcaches und die Kommunikationspfade während des normalen Betriebs.

Während des normalen Betriebs

• Der Hauptbroker (Citrix Broker Service) auf einem Controller akzeptiert Verbindungsanfragen von StoreFront. Der Broker kommuniziert mit der Sitedatenbank, um Benutzer mit VDAs zu verbinden, die beim Controller registriert sind.
• Der Citrix Config Synchronizer Service (CSS) prüft etwa alle 5 Minuten beim Broker, ob Änderungen vorgenommen wurden. Diese Änderungen können vom Administrator initiiert (z. B. Ändern einer Bereitstellungsgruppeneigenschaft) oder Systemaktionen (z. B. Maschinenzuweisungen) sein.

• Wenn seit der letzten Prüfung eine Konfigurationsänderung aufgetreten ist, synchronisiert (kopiert) der CSS Informationen auf einen sekundären Broker auf dem Controller. (Der sekundäre Broker wird auch als High Availability Service bezeichnet.)

  Alle Konfigurationsdaten werden kopiert, nicht nur Elemente, die sich seit der letzten Prüfung geändert haben. Der CSS importiert die Konfigurationsdaten in eine Microsoft SQL Server Express LocalDB-Datenbank auf dem Controller. Diese Datenbank wird als Local Host Cache-Datenbank bezeichnet. Der CSS stellt sicher, dass die Informationen in der Local Host Cache-Datenbank mit den Informationen in der Sitedatenbank übereinstimmen. Die Local Host Cache-Datenbank wird bei jeder Synchronisierung neu erstellt.

  Microsoft SQL Server Express LocalDB (das von der Local Host Cache-Datenbank verwendet wird) wird automatisch installiert, wenn Sie einen Controller installieren. (Sie können diese Installation untersagen, wenn Sie einen Controller über die Befehlszeile installieren.) Die Local Host Cache-Datenbank kann nicht von mehreren Controllern gemeinsam genutzt werden. Sie müssen die Local Host Cache-Datenbank nicht sichern. Sie wird jedes Mal neu erstellt, wenn eine Konfigurationsänderung erkannt wird.

• Wenn seit der letzten Prüfung keine Änderungen aufgetreten sind, werden keine Daten kopiert.

Die folgende Grafik veranschaulicht die Änderungen der Kommunikationspfade, wenn der Hauptbroker den Kontakt zur Sitedatenbank verliert (ein Ausfall beginnt).

Während eines Ausfalls

Wenn ein Ausfall beginnt:

• Der sekundäre Broker beginnt, Verbindungsanfragen abzuhören und zu verarbeiten.
• Wenn der Ausfall beginnt, verfügt der sekundäre Broker nicht über aktuelle VDA-Registrierungsdaten, aber wenn ein VDA mit ihm kommuniziert, wird ein Registrierungsprozess ausgelöst. Während dieses Prozesses erhält der sekundäre Broker auch aktuelle Sitzungsinformationen zu diesem VDA.
• Während der sekundäre Broker Verbindungen verarbeitet, überwacht der Brokering Principal die Verbindung weiterhin. Wenn die Verbindung wiederhergestellt ist, weist der Brokering Principal den sekundären Broker an, das Abhören von Verbindungsinformationen einzustellen, und der Brokering Principal nimmt die Brokering-Vorgänge wieder auf. Wenn ein VDA das nächste Mal mit dem Brokering Principal kommuniziert, wird ein Registrierungsprozess ausgelöst. Der sekundäre Broker entfernt alle verbleibenden VDA-Registrierungen vom vorherigen Ausfall. Der CSS nimmt die Synchronisierung von Informationen wieder auf, wenn er feststellt, dass Konfigurationsänderungen in der Bereitstellung vorgenommen wurden.

In dem unwahrscheinlichen Fall, dass ein Ausfall während einer Synchronisierung beginnt, wird der aktuelle Import verworfen und die zuletzt bekannte Konfiguration verwendet.

Das Ereignisprotokoll enthält Informationen zu Synchronisierungen und Ausfällen.

Für den Betrieb im Ausfallmodus gibt es keine zeitliche Begrenzung.

Der Übergang zwischen Normal- und Ausfallmodus hat keine Auswirkungen auf bestehende Sitzungen. Er betrifft nur den Start neuer Sitzungen.

Sie können auch absichtlich einen Ausfall auslösen. Unter Ausfall erzwingen finden Sie Details dazu, warum und wie Sie dies tun können.

Sites mit mehreren Controllern

Neben anderen Aufgaben versorgt der CSS den sekundären Broker routinemäßig mit Informationen über alle Controller in der Zone. (Wenn Ihre Bereitstellung keine mehreren Zonen enthält, betrifft diese Aktion alle Controller in der Site.) Mit diesen Informationen weiß jeder sekundäre Broker über alle gleichrangigen sekundären Broker Bescheid, die auf anderen Controllern in der Zone ausgeführt werden.

Die sekundären Broker kommunizieren über einen separaten Kanal miteinander. Diese Broker verwenden eine alphabetische Liste der FQDN-Namen der Maschinen, auf denen sie ausgeführt werden, um zu bestimmen (zu wählen), welcher sekundäre Broker die Broker-Vorgänge in der Zone übernimmt, falls ein Ausfall auftritt. Während des Ausfalls registrieren sich alle VDAs beim gewählten sekundären Broker. Die nicht gewählten sekundären Broker in der Zone lehnen eingehende Verbindungs- und VDA-Registrierungsanfragen aktiv ab.

Wenn ein gewählter sekundärer Broker während eines Ausfalls ausfällt, wird ein anderer sekundärer Broker gewählt, der die Aufgabe übernimmt, und die VDAs registrieren sich beim neu gewählten sekundären Broker.

Wenn während eines Ausfalls ein Controller neu gestartet wird:

• Wenn dieser Controller nicht der gewählte Broker ist, hat der Neustart keine Auswirkungen.
• Wenn dieser Controller der gewählte Broker ist, wird ein anderer Controller gewählt, wodurch VDAs registriert werden. Nachdem der neu gestartete Controller hochgefahren ist, übernimmt er automatisch das Brokering, wodurch sich die VDAs erneut registrieren. In diesem Szenario kann die Leistung während der Registrierungen beeinträchtigt werden.

Wenn Sie einen Controller während des normalen Betriebs ausschalten und ihn dann während eines Ausfalls einschalten, kann der lokale Hostcache auf diesem Controller nicht verwendet werden, wenn er als Broker gewählt wird.

Die Ereignisprotokolle enthalten Informationen zu Wahlen.

Was während eines Ausfalls nicht verfügbar ist und andere Unterschiede

Für den Betrieb im Ausfallmodus gibt es keine zeitliche Begrenzung. Citrix empfiehlt jedoch, die Konnektivität so schnell wie möglich wiederherzustellen.

Während eines Ausfalls:

• Sie können Studio nicht verwenden.

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

  • Sie müssen zuerst:
    • Einen Registrierungsschlüssel EnableCssTestMode mit dem Wert 1 hinzufügen: New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
    • Port 89 verwenden: Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
  • Nach dem Ausführen dieser Befehle können Sie zugreifen auf:
    • Alle Get-Broker* Cmdlets.
• Hypervisor-Anmeldeinformationen können nicht vom Hostdienst abgerufen werden. Alle Maschinen befinden sich im unbekannten Energiezustand, und es können keine Energieoperationen ausgeführt werden. VMs auf dem Host, die eingeschaltet sind, können jedoch für Verbindungsanfragen verwendet werden.
• Eine zugewiesene Maschine kann nur verwendet werden, wenn die Zuweisung während des normalen Betriebs erfolgte. Neue Zuweisungen können während eines Ausfalls nicht vorgenommen werden.
• Die automatische Registrierung und Konfiguration von Remote-PC-Zugriffsmaschinen ist nicht möglich. Maschinen, die während des normalen Betriebs registriert und konfiguriert wurden, sind jedoch nutzbar.
• Benutzer von servergehosteten Anwendungen und Desktops verwenden möglicherweise mehr Sitzungen als ihre konfigurierten Sitzungslimits, wenn sich die Ressourcen in verschiedenen Zonen befinden.
• Benutzer können Anwendungen und Desktops nur von registrierten VDAs in der Zone starten, die den aktuell aktiven/gewählten sekundären Broker enthält. Starts über Zonen hinweg (von einem sekundären Broker in einer Zone zu einem VDA in einer anderen Zone) werden während eines Ausfalls nicht unterstützt.
• Wenn ein Datenbankausfall der Site auftritt, bevor ein geplanter Neustart für VDAs in einer Bereitstellungsgruppe beginnt, beginnen die Neustarts, wenn der Ausfall endet. Dies kann unbeabsichtigte Folgen haben. Weitere Informationen finden Sie unter Geplante Neustarts aufgrund von Datenbankausfall verzögert.
• Zonenpräferenz kann nicht konfiguriert werden. Wenn konfiguriert, werden Präferenzen für den Sitzungsstart nicht berücksichtigt.
• Tag-Einschränkungen, bei denen Tags zur Kennzeichnung von Zonen verwendet werden, werden für Sitzungsstarts nicht unterstützt. Wenn solche Tag-Einschränkungen konfiguriert sind und die Option Erweiterte Integritätsprüfung eines StoreFront-Stores aktiviert ist, können Sitzungen gelegentlich nicht gestartet werden.

Anwendungs- und Desktop-Unterstützung

LHC unterstützt die folgenden VDA-Typen und Bereitstellungsmodelle:

Hinweis:

Das Aktivieren des Zugriffs auf energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen hat keinen Einfluss darauf, wie die konfigurierte ShutdownDesktopsAfterUse-Eigenschaft während des normalen Betriebs funktioniert. Wenn der Zugriff auf diese Desktops während LHC aktiviert ist, starten die VDAs nach Abschluss des LHC-Ereignisses nicht automatisch neu. Energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen können Daten aus früheren Sitzungen beibehalten, bis die VDAs neu gestartet werden. Ein VDA-Neustart kann erfolgen, wenn sich ein Benutzer während Nicht-LHC-Operationen vom VDA abmeldet oder wenn Administratoren den VDA neu starten.

LHC für energieverwaltete Single-Session-OS-Pool-VDAs mit Web Studio aktivieren

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

• Um diese Funktion während der Erstellung einer Bereitstellungsgruppe zu aktivieren, siehe Bereitstellungsgruppen erstellen.
• Um diese Funktion für eine bestehende Bereitstellungsgruppe zu aktivieren, siehe Bereitstellungsgruppen verwalten.

Hinweis:

Diese Einstellung ist in Web Studio nur für gepoolte Desktop-Bereitstellungsgruppen verfügbar, die energieverwaltete VDAs bereitstellen.

LHC für energieverwaltete Single-Session-OS-Pool-VDAs mit PowerShell aktivieren

Um LHC für VDAs in einer bestimmten Bereitstellungsgruppe zu aktivieren, führen Sie die folgenden Schritte aus:

1. Aktivieren Sie diese Funktion auf Site-Ebene, indem Sie diesen Befehl ausführen:

   Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

2. Aktivieren Sie LHC für eine Bereitstellungsgruppe, indem Sie diesen Befehl mit dem angegebenen Namen der Bereitstellungsgruppe ausführen:

   Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true

Um die standardmäßige LHC-Verfügbarkeit für neu erstellte gepoolte Bereitstellungsgruppen mit energieverwalteten VDAs zu ändern, führen Sie den folgenden Befehl aus:

Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true

Überlegungen zur RAM-Größe

Der LocalDB-Dienst kann etwa 1,2 GB RAM verwenden (bis zu 1 GB für den Datenbank-Cache plus 200 MB für den Betrieb von SQL Server Express LocalDB). Der sekundäre Broker kann bis zu 1 GB RAM verwenden, wenn ein Ausfall über einen längeren Zeitraum mit vielen Anmeldungen auftritt (z. B. 12 Stunden mit 10.000 Benutzern). Diese Speicheranforderungen gelten zusätzlich zu den normalen RAM-Anforderungen für den Controller, sodass Sie die gesamte RAM-Kapazität möglicherweise erhöhen müssen.

Wenn Sie eine SQL Server Express-Installation für die Sitedatenbank verwenden, verfügt der Server über zwei sqlserver.exe-Prozesse.

Überlegungen zur CPU-Kern- und Sockelkonfiguration

Die CPU-Konfiguration eines Controllers, insbesondere die Anzahl der für SQL Server Express LocalDB verfügbaren Kerne, wirkt sich direkt auf die Leistung des lokalen Host-Caches aus, sogar stärker als die Speicherzuweisung. Dieser CPU-Mehraufwand wird nur während des Ausfallzeitraums beobachtet, wenn die Datenbank nicht erreichbar ist und der sekundäre Broker aktiv ist.

Obwohl LocalDB mehrere Kerne (bis zu 4) verwenden kann, ist es auf einen einzigen Sockel beschränkt. Das Hinzufügen weiterer Sockel verbessert die Leistung nicht (z. B. 4 Sockel mit jeweils 1 Kern). Stattdessen empfiehlt Citrix die Verwendung mehrerer Sockel mit mehreren Kernen. Bei Citrix-Tests lieferte eine 2x3-Konfiguration (2 Sockel, 3 Kerne) eine bessere Leistung als 4x1- und 6x1-Konfigurationen.

Speicherüberlegungen

Wenn Benutzer während eines Ausfalls auf Ressourcen zugreifen, wächst die LocalDB. Bei einem Anmelde-/Abmeldetest mit 10 Anmeldungen pro Sekunde wuchs die Datenbank beispielsweise alle 2-3 Minuten um 1 MB. Wenn der normale Betrieb wieder aufgenommen wird, wird die lokale Datenbank neu erstellt und der Speicherplatz freigegeben. Es muss jedoch ausreichend Speicherplatz auf dem Laufwerk verfügbar sein, auf dem die LocalDB installiert ist, um das Datenbankwachstum während eines Ausfalls zu ermöglichen. Der lokale Host-Cache verursacht während eines Ausfalls auch mehr E/A: etwa 3 MB Schreibvorgänge pro Sekunde, mit mehreren hunderttausend Lesevorgängen.

Leistungsüberlegungen

Während eines Ausfalls übernimmt ein sekundärer Broker alle Verbindungen. In Sites (oder Zonen), die im Normalbetrieb die Last auf mehrere Controller verteilen, muss der gewählte sekundäre Broker während eines Ausfalls möglicherweise wesentlich mehr Anfragen als üblich bearbeiten. Daher ist der CPU-Bedarf höher. Jeder sekundäre Broker in der Site (Zone) muss die zusätzliche Last bewältigen können, die durch die Local Host Cache-Datenbank und alle betroffenen VDAs entsteht, da der während eines Ausfalls gewählte sekundäre Broker wechseln kann.

VDI-Grenzwerte:

• In einer VDI-Bereitstellung mit einer Zone können während eines Ausfalls bis zu 10.000 VDAs effektiv verwaltet werden.
• In einer VDI-Bereitstellung mit mehreren Zonen können während eines Ausfalls bis zu 10.000 VDAs pro Zone effektiv verwaltet werden, bis zu einem Maximum von 40.000 VDAs in der Site. Beispielsweise können die folgenden Sites während eines Ausfalls effektiv verwaltet werden:
  • Eine Site mit vier Zonen, die jeweils 10.000 VDAs enthalten.
  • Eine Site mit sieben Zonen, eine davon mit 10.000 VDAs und sechs weitere mit jeweils 5.000 VDAs.

Während eines Ausfalls kann die Lastverwaltung innerhalb der Site beeinträchtigt sein. Lastausgleichsregeln (insbesondere Sitzungsanzahlregeln) können überschritten werden.

Während der Zeit, die alle VDAs benötigen, um sich bei einem sekundären Broker zu registrieren, verfügt dieser Dienst möglicherweise nicht über vollständige Informationen zu aktuellen Sitzungen. Eine Benutzerverbindungsanfrage in diesem Intervall kann daher zum Starten einer neuen Sitzung führen, obwohl eine Wiederverbindung zu einer bestehenden Sitzung möglich gewesen wäre. Dieses Intervall (während der „neue“ sekundäre Broker bei der erneuten Registrierung Sitzungsinformationen von allen VDAs abruft) ist unvermeidlich. Sitzungen, die bei Beginn eines Ausfalls verbunden sind, sind während des Übergangsintervalls nicht betroffen, neue Sitzungen und Sitzungswiederverbindungen jedoch möglicherweise schon.

Dieses Intervall tritt immer dann auf, wenn sich VDAs registrieren müssen:

• Ein Ausfall beginnt: Beim Migrieren von einem primären Broker zu einem sekundären Broker.
• Ausfall des sekundären Brokers während eines Ausfalls: Beim Migrieren von einem ausgefallenen sekundären Broker zu einem neu gewählten sekundären Broker.
• Wiederherstellung nach einem Ausfall: Wenn der Normalbetrieb wieder aufgenommen wird und der primäre Broker die Kontrolle wieder übernimmt.

Sie können das Intervall verkürzen, indem Sie den Registrierungswert HeartbeatPeriodMs des Citrix Broker Protocols (Standard = 600000 ms, d. h. 10 Minuten) senken. Dieser Heartbeat-Wert ist doppelt so lang wie das Intervall, das der VDA für Pings verwendet, sodass der Standardwert alle 5 Minuten einen Ping ergibt.

Der folgende Befehl ändert den Heartbeat beispielsweise auf fünf Minuten (300000 Millisekunden), was zu einem Ping alle 2,5 Minuten führt:

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

Seien Sie vorsichtig, wenn Sie den Heartbeat-Wert ändern. Eine Erhöhung der Frequenz führt zu einer größeren Last auf den Controllern, sowohl im Normalbetrieb als auch im Ausfallmodus.

Das Intervall kann nicht vollständig eliminiert werden, egal wie schnell sich die VDAs registrieren.

Die Synchronisierungszeit zwischen sekundären Brokern nimmt mit der Anzahl der Objekte (wie VDAs, Anwendungen, Gruppen) zu. Das Synchronisieren von 5000 VDAs kann beispielsweise 10 Minuten oder länger dauern.

Unterschiede zu XenApp 6.x-Versionen

Obwohl diese Local Host Cache-Implementierung den Namen der Local Host Cache-Funktion in XenApp 6.x und früheren XenApp-Versionen teilt, gibt es erhebliche Verbesserungen. Diese Implementierung ist robuster und unempfindlicher gegenüber Beschädigungen. Der Wartungsaufwand ist minimiert, z. B. entfällt die Notwendigkeit periodischer dsmaint-Befehle. Dieser Local Host Cache ist technisch eine völlig andere Implementierung.

Local Host Cache verwalten

Damit der Local Host Cache ordnungsgemäß funktioniert, muss die PowerShell-Ausführungsrichtlinie auf jedem Controller auf RemoteSigned, Unrestricted oder Bypass eingestellt sein.

SQL Server Express LocalDB

Die Microsoft SQL Server Express LocalDB-Software, die der Local Host Cache verwendet, wird automatisch installiert, wenn Sie einen Controller installieren oder einen Controller von einer Version vor 7.9 aktualisieren. Nur der sekundäre Broker kommuniziert mit dieser Datenbank. Sie können keine PowerShell-Cmdlets verwenden, um Änderungen an dieser Datenbank vorzunehmen. Die LocalDB kann nicht von mehreren Controllern gemeinsam genutzt werden.

Die SQL Server Express LocalDB-Datenbanksoftware wird installiert, unabhängig davon, ob der Local Host Cache aktiviert ist.

Um die Installation zu verhindern, installieren oder aktualisieren Sie den Controller mit dem Befehl XenDesktopServerSetup.exe und fügen Sie die Option /exclude "Local Host Cache Storage (LocalDB)" hinzu. Beachten Sie jedoch, dass die Local Host Cache-Funktion ohne die Datenbank nicht funktioniert und Sie keine andere Datenbank mit dem sekundären Broker verwenden können.

Die Installation dieser LocalDB-Datenbank hat keinen Einfluss darauf, ob Sie SQL Server Express zur Verwendung als Sitedatenbank installieren.

Informationen zum Ersetzen einer älteren SQL Server Express LocalDB-Version durch eine neuere Version finden Sie unter SQL Server Express LocalDB ersetzen.

Standardeinstellungen nach Produktinstallation und Upgrade

Bei einer Neuinstallation von Citrix Virtual Apps and Desktops (Mindestversion 7.16) ist der Local Host Cache aktiviert.

Nach einem Upgrade (auf Version 7.16 oder höher) ist der Local Host Cache aktiviert, wenn weniger als 10.000 VDAs in der gesamten Bereitstellung vorhanden sind.

Local Host Cache aktivieren und deaktivieren

• Geben Sie Folgendes ein, um den Local Host Cache zu aktivieren:

  Set-BrokerSite -LocalHostCacheEnabled $true

  Um festzustellen, ob der Local Host Cache aktiviert ist, geben Sie Get-BrokerSite ein. Überprüfen Sie, ob die Eigenschaft LocalHostCacheEnabled auf True gesetzt ist.

• Geben Sie Folgendes ein, um den Local Host Cache zu deaktivieren:

  Set-BrokerSite -LocalHostCacheEnabled $false

Hinweis: Ab XenApp und XenDesktop 7.16 wurde Connection Leasing (die Funktion, die dem Local Host Cache ab Version 7.6 vorausging) aus dem Produkt entfernt und ist nicht mehr verfügbar.

Überprüfen, ob der Local Host Cache funktioniert

So überprüfen Sie, ob der Local Host Cache eingerichtet ist und ordnungsgemäß funktioniert:

• Stellen Sie sicher, dass die Synchronisierungsimporte erfolgreich abgeschlossen werden. Überprüfen Sie die Ereignisprotokolle.
• Stellen Sie sicher, dass die SQL Server Express LocalDB-Datenbank auf jedem Delivery Controller erstellt wurde. Dies bestätigt, dass der sekundäre Broker bei Bedarf übernehmen kann.
  • Navigieren Sie auf dem Delivery Controller-Server zu C:\Windows\ServiceProfiles\NetworkService.
  • Überprüfen Sie, ob HaDatabaseName.mdf und HaDatabaseName_log.ldf erstellt wurden.
• Erzwingen Sie einen Ausfall auf den Delivery Controllern. Nachdem Sie überprüft haben, dass der Local Host Cache funktioniert, denken Sie daran, alle Controller wieder in den normalen Modus zu versetzen. Dies kann etwa 15 Minuten dauern.

Ereignisprotokolle

Ereignisprotokolle zeigen an, wann Synchronisierungen und Ausfälle auftreten. In den Ereignisanzeige-Protokollen wird der Ausfallmodus als HA-Modus bezeichnet.

Config Synchronizer Service:

Während des normalen Betriebs können die folgenden Ereignisse auftreten, wenn der CSS die Konfigurationsdaten mithilfe des Local Host Cache Brokers in die Local Host Cache-Datenbank importiert.

• 503: Der Citrix Config Sync Service hat eine aktualisierte Konfiguration erhalten. Dieses Ereignis zeigt den Beginn des Synchronisierungsprozesses an.
• 504: Der Citrix Config Sync Service hat eine aktualisierte Konfiguration importiert. Der Konfigurationsimport wurde erfolgreich abgeschlossen.
• 505: Der Citrix Config Sync Service konnte einen Import nicht durchführen. Der Konfigurationsimport wurde nicht erfolgreich abgeschlossen. Wenn eine zuvor erfolgreiche Konfiguration verfügbar ist, wird diese bei einem Ausfall verwendet. Diese ist jedoch gegenüber der aktuellen Konfiguration veraltet. Wenn keine frühere Konfiguration verfügbar ist, kann der Dienst während eines Ausfalls nicht am Session Brokering teilnehmen. In diesem Fall lesen Sie den Abschnitt Problembehandlung und wenden Sie sich an den Citrix Support.
• 507: Der Citrix Config Sync Service hat einen Import abgebrochen, da sich das System im Ausfallmodus befindet und der Local Host Cache Broker für das Brokering verwendet wird. Der Dienst hat eine neue Konfiguration erhalten, der Import wurde jedoch aufgrund eines Ausfalls abgebrochen. Dies ist ein erwartetes Verhalten.
• 510: Keine Konfigurationsdienst-Konfigurationsdaten vom primären Konfigurationsdienst empfangen.
• 517: Es gab ein Problem bei der Kommunikation mit dem primären Broker.
• 518: Das Config Sync-Skript wurde abgebrochen, da der sekundäre Broker (High Availability Service) nicht ausgeführt wird.

High Availability Service:

Dieser Dienst ist auch als Local Host Cache Broker bekannt.

• 3502: Ein Ausfall ist aufgetreten, und der Local Host Cache Broker führt Brokering-Vorgänge aus.
• 3503: Ein Ausfall wurde behoben und der normale Betrieb wurde wieder aufgenommen.
• 3504: Zeigt an, welcher Local Host Cache-Broker gewählt wurde, sowie andere am Wahlprozess beteiligte Local Host Cache-Broker.
• 3507: Bietet alle 2 Minuten eine Statusaktualisierung des Local Host Cache, die anzeigt, dass der Local Host Cache-Modus auf dem gewählten Broker aktiv ist. Enthält eine Zusammenfassung des Ausfalls, einschließlich Ausfalldauer, VDA-Registrierung und Sitzungsinformationen.
• 3508: Meldet, dass der Local Host Cache auf dem gewählten Broker nicht mehr aktiv ist und der normale Betrieb wiederhergestellt wurde. Enthält eine Zusammenfassung des Ausfalls, einschließlich Ausfalldauer, Anzahl der während des Local Host Cache-Ereignisses registrierten Maschinen und Anzahl der erfolgreichen Starts während des LHC-Ereignisses.
• 3509: Benachrichtigt, dass der Local Host Cache auf dem/den nicht gewählten Broker(n) aktiv ist. Enthält alle 2 Minuten eine Ausfalldauer und gibt den gewählten Broker an.
• 3510: Meldet, dass der Local Host Cache auf dem/den nicht gewählten Broker(n) nicht mehr aktiv ist. Enthält die Ausfalldauer und gibt den gewählten Broker an.

Einen Ausfall erzwingen

Möglicherweise möchten Sie absichtlich einen Ausfall erzwingen.

• Wenn Ihr Netzwerk wiederholt ausfällt. Das Erzwingen eines Ausfalls, bis die Netzwerkprobleme behoben sind, verhindert einen kontinuierlichen Übergang zwischen Normal- und Ausfallmodus (und die daraus resultierenden häufigen VDA-Registrierungsstürme).
• Um einen Notfallwiederherstellungsplan zu testen.
• Um sicherzustellen, dass der Local Host Cache ordnungsgemäß funktioniert.
• Beim Austausch oder der Wartung des Site-Datenbankservers.

Um einen Ausfall zu erzwingen, bearbeiten Sie die Registrierung jedes Servers, der einen Delivery Controller enthält. Erstellen und setzen Sie in HKLM\Software\Citrix\DesktopServer\LHC den Wert OutageModeForced als REG_DWORD auf 1. Diese Einstellung weist den Local Host Cache-Broker an, in den Ausfallmodus zu wechseln, unabhängig vom Status der Datenbank. Das Setzen des Werts auf 0 beendet den Ausfallmodus des Local Host Cache-Brokers.

Um Ereignisse zu überprüfen, überwachen Sie die Protokolldatei Current_HighAvailabilityService in C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.

Fehlerbehebung

Mehrere Tools zur Fehlerbehebung stehen zur Verfügung, wenn ein Synchronisierungsimport in die Local Host Cache-Datenbank fehlschlägt und ein 505-Ereignis protokolliert wird.

CDF-Tracing: Enthält Optionen für die Module ConfigSyncServer und BrokerLHC. Diese Optionen identifizieren zusammen mit anderen Broker-Modulen wahrscheinlich das Problem.

Bericht: Wenn ein Synchronisierungsimport fehlschlägt, können Sie einen Bericht generieren. Dieser Bericht stoppt bei dem Objekt, das den Fehler verursacht. Diese Berichtsfunktion beeinträchtigt die Synchronisierungsgeschwindigkeit, daher empfiehlt Citrix, sie bei Nichtgebrauch zu deaktivieren.

Um einen CSS-Trace-Bericht zu aktivieren und zu erstellen, geben Sie den 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.

Nachdem der Bericht generiert wurde, geben Sie den folgenden Befehl ein, um die Berichtsfunktion zu deaktivieren:

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

Broker-Konfiguration exportieren: Bietet die exakte Konfiguration für Debugging-Zwecke.

Export-BrokerConfiguration | Out-File <file-pathname>

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

Local Host Cache PowerShell-Befehle

Sie können den Local Host Cache (LHC) auf Ihren Delivery Controllern mithilfe von PowerShell-Befehlen verwalten.

Das PowerShell-Modul befindet sich an folgendem Speicherort auf den Delivery Controllern:

C:\Program Files\Citrix\Broker\Service\ControlScripts

Wichtig:

Führen Sie dieses Modul nur auf den Delivery Controllern aus.

PowerShell-Modul importieren

Um das Modul zu importieren, führen Sie Folgendes auf Ihrem Delivery Controller aus.

cd C:\Program Files\Citrix\Broker\Service\ControlScripts Import-Module .\HighAvailabilityServiceControl.psm1

PowerShell-Befehle zur Verwaltung von LHC

Die folgenden Befehle helfen Ihnen, den LHC-Modus auf den Delivery Controllern zu aktivieren und zu verwalten.

Hinweis:

• Verwenden Sie Port 89, wenn Sie die Get-Broker* Cmdlets auf dem Delivery Controller ausführen. Zum Beispiel:
  • Get-BrokerMachine -AdminAddress localhost:89
• Wenn nicht im LHC-Modus, hält der LHC-Broker auf dem Delivery Controller nur Konfigurationsinformationen.
• Im LHC-Modus hält der LHC-Broker auf dem gewählten Delivery Controller die folgenden Informationen:
  • Ressourcenzustände
  • Sitzungsdetails
  • VDA-Registrierungen
  • Konfigurationsinformationen