Lokaler Hostcache

Last published : Nov 13, 2026
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 Local Host Cache-Funktion ermöglicht die Fortsetzung von Verbindungsmakler-Vorgängen an einem Standort, 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 Local Host Cache wird aktiviert, wenn die Sitedatenbank 90 Sekunden lang nicht erreichbar ist.
Ab XenApp und XenDesktop 7.16 wurde die Connection Leasing-Funktion (eine frühere Hochverfügbarkeitsfunktion in früheren Releases) aus dem Produkt entfernt und ist nicht mehr verfügbar.
Related information
Verwalten

Dateninhalt

Der Local Host Cache 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 von 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 Client-Maschinen-Endpunktanalyse, die von Citrix Receiver durchgeführt wurde.
  • Identitäten von Infrastrukturmaschinen (wie NetScaler Gateway- und StoreFront™-Servern), die am Standort beteiligt sind.
  • Datum, Uhrzeit und Art der jüngsten Aktivitäten von Benutzern.

Funktionsweise

Die folgende Grafik veranschaulicht die Local Host Cache-Komponenten und Kommunikationspfade während des normalen Betriebs.
Diagramm der Kommunikationspfade des Local Host Cache 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 vorherigen Überprü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.)
    Es werden alle Konfigurationsdaten kopiert, nicht nur die Elemente, die sich seit der vorherigen Überprü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 (von der Local Host Cache-Datenbank verwendet) wird automatisch installiert, wenn Sie einen Controller installieren. (Sie können diese Installation bei der Installation eines Controllers über die Befehlszeile unterbinden.) Die Local Host Cache-Datenbank kann nicht von mehreren Controllern gemeinsam genutzt werden. Sie müssen keine Sicherung der Local Host Cache-Datenbank erstellen. Sie wird jedes Mal neu erstellt, wenn eine Konfigurationsänderung erkannt wird.
  • Wenn seit der letzten Überprüfung keine Änderungen vorgenommen wurden, werden keine Daten kopiert.
Die folgende Grafik veranschaulicht die Änderungen der Kommunikationspfade, wenn der primäre Broker den Kontakt zur Sitedatenbank verliert (ein Ausfall beginnt).
Diagramm der Kommunikationspfade des Local Host Cache während eines Ausfalls

Während eines Ausfalls

Wenn ein Ausfall beginnt:
  • Der sekundäre Broker beginnt, auf Verbindungsanfragen zu warten und diese 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 Warten auf Verbindungsinformationen einzustellen, und der Brokering Principal nimmt die Broker-Operationen 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.
Im 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.
Für den Betrieb im Ausfallmodus gibt es keine zeitliche Begrenzung.
Der Übergang zwischen Normal- und Ausfallmodus wirkt sich nicht auf bestehende Sitzungen aus. 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 dies zu tun ist.

Sites mit mehreren Controllern

Neben anderen Aufgaben übermittelt der CSS dem sekundären Broker routinemäßig 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 Peer-Sekundärbroker 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-Operationen in der Zone übernimmt, wenn 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.
Wird ein Controller während eines Ausfalls neu gestartet:
  • 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 sich die VDAs registrieren. 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:
      • Fügen Sie einen Registrierungsschlüssel EnableCssTestMode mit dem Wert 1 hinzu: New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
      • Verwenden Sie Port 89: Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
    • Nachdem Sie diese Befehle ausgeführt haben, 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. Zonenübergreifende Starts (von einem sekundären Broker in einer Zone zu einem VDA in einer anderen Zone) werden während eines Ausfalls nicht unterstützt.
  • Tritt ein Datenbankausfall der Site auf, bevor ein geplanter Neustart für VDAs in einer Bereitstellungsgruppe beginnt, beginnen die Neustarts, wenn der Ausfall beendet ist. Dies kann zu unbeabsichtigten Ergebnissen führen. Weitere Informationen finden Sie unter Geplante Neustarts aufgrund von Datenbankausfall verzögert.
  • Zonenpräferenz kann nicht konfiguriert werden. Wenn konfiguriert, werden Präferenzen beim 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.

Unterstützung für Anwendungen und Desktops

LHC unterstützt die folgenden VDA-Typen und Bereitstellungsmodelle:
VDA-Typ Bereitstellungsmodell VDA-Verfügbarkeit während LHC-Ereignissen
Multi-Session-Betriebssystem Anwendungen und Desktops Immer verfügbar.
Single-Session-Betriebssystem statisch (zugewiesen) Desktops Immer verfügbar.
Energieverwaltetes Einzel-Session-Betriebssystem zufällig (gepoolt) Desktops Standardmäßig nicht verfügbar. Alle Versuche, Sitzungen auf energieverwalteten VDAs in gepoolten Bereitstellungsgruppen zu starten, schlagen standardmäßig fehl.
Sie können sie während LHC-Ereignissen für neue Verbindungen verfügbar machen. Weitere Informationen finden Sie unter Aktivieren mit Web Studio und Aktivieren mit PowerShell.
Wichtig: Das Aktivieren des Zugriffs auf energieverwaltete Single-Session-Pool-Maschinen kann dazu führen, dass Daten und Änderungen aus früheren Benutzersitzungen in nachfolgenden Sitzungen vorhanden sind.
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, werden VDAs nach Abschluss des LHC-Ereignisses nicht automatisch neu gestartet. 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 des Nicht-LHC-Betriebs vom VDA abmeldet oder wenn Administratoren den VDA neu starten.

LHC für energieverwaltete gepoolte VDAs mit Einzelsitzungs-Betriebssystem über Web Studio aktivieren

Mit Web Studio können Sie diese Maschinen während LHC-Ereignissen pro Bereitstellungsgruppe für neue Verbindungen verfügbar machen:
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

Führen Sie die folgenden Schritte aus, um LHC für VDAs in einer bestimmten Bereitstellungsgruppe zu aktivieren:
  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 ca. 1,2 GB RAM verwenden (bis zu 1 GB für den Datenbankcache 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 bei 10.000 Benutzern). Diese Speicheranforderungen kommen zu den normalen RAM-Anforderungen für den Controller hinzu, sodass Sie möglicherweise die gesamte RAM-Kapazität 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 Local Host Cache-Leistung aus, sogar stärker als die Speicherzuweisung. Dieser CPU-Overhead 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 nur einen Socket beschränkt. Das Hinzufügen weiterer Sockets verbessert die Leistung nicht (z. B. 4 Sockets mit jeweils 1 Kern). Stattdessen empfiehlt Citrix die Verwendung mehrerer Sockets mit mehreren Kernen. Bei Citrix-Tests lieferte eine 2x3-Konfiguration (2 Sockets, 3 Kerne) eine bessere Leistung als 4x1- und 6x1-Konfigurationen.

Überlegungen zum Speicher

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 Local Host Cache verursacht während eines Ausfalls auch mehr E/A: ca. 3 MB Schreibvorgänge pro Sekunde, mit mehreren hunderttausend Lesevorgängen.

Leistungsüberlegungen

Während eines Ausfalls verarbeitet ein sekundärer Broker alle Verbindungen. In Sites (oder Zonen), die während des normalen Betriebs die Last auf mehrere Controller verteilen, muss der gewählte sekundäre Broker während eines Ausfalls möglicherweise viel mehr Anfragen bearbeiten als normal. Daher ist der CPU-Bedarf höher. Jeder sekundäre Broker in der Site (Zone) muss in der Lage sein, die zusätzliche Last zu bewältigen, die durch die Local Host Cache-Datenbank und alle betroffenen VDAs entsteht, da sich der während eines Ausfalls gewählte sekundäre Broker ändern kann.
VDI-Grenzwerte:
  • In einer VDI-Bereitstellung mit einer einzigen Zone können während eines Ausfalls bis zu 10.000 VDAs effektiv verwaltet werden.
  • In einer VDI-Bereitstellung mit mehreren Zonen können bis zu 10.000 VDAs in jeder Zone während eines Ausfalls effektiv verwaltet werden, bis zu einem Maximum von 40.000 VDAs im gesamten Site. Beispielsweise können die folgenden Sites während eines Ausfalls effektiv verwaltet werden:
    • Ein Site mit vier Zonen, die jeweils 10.000 VDAs enthalten.
    • Ein Site mit sieben Zonen, wobei eine 10.000 VDAs enthält und sechs jeweils 5.000 VDAs enthalten.
Während eines Ausfalls kann die Lastverwaltung innerhalb des Sites beeinträchtigt werden. Lastauswerter (und 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. Daher kann eine Benutzerverbindungsanforderung während dieses Intervalls zum Starten einer neuen Sitzung führen, obwohl eine Wiederverbindung mit einer vorhandenen 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, aber neue Sitzungen und Sitzungswiederverbindungen könnten es sein.
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 normale Betrieb wieder aufgenommen wird und der primäre Broker die Kontrolle wieder übernimmt.
Sie können das Intervall verringern, indem Sie den Registrierungswert HeartbeatPeriodMs des Citrix Broker Protocols senken (Standard = 600000 ms, d. h. 10 Minuten). 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 zur Folge hat.
Beispielsweise ändert der folgende Befehl den Heartbeat auf fünf Minuten (300000 Millisekunden), was alle 2,5 Minuten einen Ping zur Folge hat:
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 höheren 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 Zeit, die für die Synchronisierung zwischen sekundären Brokern benötigt wird, steigt mit der Anzahl der Objekte (z. B. VDAs, Anwendungen, Gruppen). Beispielsweise kann die Synchronisierung von 5000 VDAs 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 wird 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 Local Host Cache ordnungsgemäß funktioniert, muss die PowerShell-Ausführungsrichtlinie auf jedem Controller auf RemoteSigned, Unrestricted oder Bypass festgelegt sein.

SQL Server Express LocalDB

Die Microsoft SQL Server Express LocalDB-Software, die 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 unabhängig davon installiert, ob 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 als Sitedatenbank installieren.
Informationen zum Ersetzen einer früheren 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 Local Host Cache aktiviert.
Nach einem Upgrade (auf Version 7.16 oder höher) ist Local Host Cache aktiviert, wenn in der gesamten Bereitstellung weniger als 10.000 VDAs vorhanden sind.

Local Host Cache aktivieren und deaktivieren

  • Um Local Host Cache zu aktivieren, geben Sie Folgendes ein:
    Set-BrokerSite -LocalHostCacheEnabled $true
    Um festzustellen, ob Local Host Cache aktiviert ist, geben Sie Get-BrokerSite ein. Überprüfen Sie, ob die Eigenschaft LocalHostCacheEnabled True ist.
  • Geben Sie Folgendes ein, um den lokalen Hostcache zu deaktivieren:
    Set-BrokerSite -LocalHostCacheEnabled $false
Hinweis: Ab XenApp und XenDesktop 7.16 wurde Connection Leasing (die Funktion, die ab Version 7.6 dem lokalen Hostcache vorausging) aus dem Produkt entfernt und ist nicht mehr verfügbar.

Überprüfen, ob der lokale Hostcache funktioniert

So überprüfen Sie, ob der lokale Hostcache eingerichtet ist und ordnungsgemäß funktioniert:
  • Stellen Sie sicher, dass 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. Dadurch wird bestätigt, dass der sekundäre Broker bei Bedarf übernehmen kann.
    • Navigieren Sie auf dem Delivery Controller-Server zu C:\Windows\ServiceProfiles\NetworkService.
    • Stellen Sie sicher, dass HaDatabaseName.mdf und HaDatabaseName_log.ldf erstellt wurden.
  • Erzwingen Sie einen Ausfall auf den Delivery Controllern. Nachdem Sie überprüft haben, dass der lokale Hostcache funktioniert, versetzen Sie alle Controller wieder in den Normalmodus. 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.*
Config Synchronizer Service:
Während des normalen Betriebs können die folgenden Ereignisse auftreten, wenn der CSS die Konfigurationsdaten mithilfe des lokalen Hostcache-Brokers in die lokale Hostcache-Datenbank importiert.
  • 503: Der Citrix Config Sync Service hat eine aktualisierte Konfiguration empfangen. 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 frühere erfolgreiche Konfiguration verfügbar ist, wird diese bei einem Ausfall verwendet. Sie 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 lokale Hostcache-Broker für das Brokering verwendet wird. Der Dienst hat eine neue Konfiguration empfangen, 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 Konfigurationssynchronisierungsskript wurde abgebrochen, da der sekundäre Broker (High Availability Service) nicht ausgeführt wird.
High Availability Service:
Dieser Dienst wird auch als Local Host Cache-Broker bezeichnet.
  • 3502: Ein Ausfall ist aufgetreten, und der Local Host Cache-Broker führt Broker-Operationen 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 Local Host Cache-Broker, die an der Wahl beteiligt sind.
  • 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 Maschinen, die sich während des Local Host Cache-Ereignisses registriert haben, 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 und wiederhergestellt wird. 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 lokale Hostcache ordnungsgemäß funktioniert.
  • Beim Ersetzen oder Warten 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 OutageModeForced als REG_DWORD auf 1. Diese Einstellung weist den Local Host Cache-Broker an, in den Ausfallmodus zu wechseln, unabhängig vom Zustand 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.

Problembehandlung

Es stehen mehrere Tools zur Fehlerbehebung zur Verfügung, wenn ein Synchronisierungsimport in die Local Host Cache-Datenbank fehlschlägt und ein 505-Ereignis gemeldet wird.
CDF-Tracing: Enthält Optionen für die Module ConfigSyncServer und BrokerLHC. Diese Optionen werden zusammen mit anderen Broker-Modulen das Problem wahrscheinlich identifizieren.
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 zu deaktivieren, wenn sie nicht verwendet wird.
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 genaue Konfiguration für Debugging-Zwecke.
Export-BrokerConfiguration | Out-File <file-pathname>
Zum Beispiel Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.

PowerShell-Befehle für den lokalen Hostcache

Sie können den Local Host Cache (LHC) auf Ihren Delivery Controllern mithilfe von PowerShell-Befehlen verwalten.
Das PowerShell-Modul befindet sich am folgenden 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.
Cmdlets Funktion
Enable-LhcForcedOutageMode Versetzt den Broker in den LHC-Modus. Die LHC-Datenbankdateien müssen vom ConfigSync-Dienst erfolgreich erstellt worden sein, damit Enable-LhcForcedOutageMode ordnungsgemäß funktioniert. Dieses Cmdlet erzwingt den LHC-Modus nur auf dem Delivery Controller, auf dem es ausgeführt wurde. Damit LHC aktiv wird, muss dieser Befehl auf allen Delivery Controllern innerhalb der Zone ausgeführt werden.
Disable-LhcForcedOutageMode Nimmt den Broker aus dem LHC-Modus. Dieses Cmdlet deaktiviert den LHC-Modus nur auf dem Delivery Controller, auf dem es ausgeführt wurde. Disable-LhcForcedOutageMode muss auf allen Delivery Controllern innerhalb der Zone ausgeführt werden.
Set-LhcConfigSyncIntervalOverride Legt das Intervall fest, in dem der Citrix Config Synchronizer Service (CSS) nach Konfigurationsänderungen innerhalb der Site sucht. Das Zeitintervall kann zwischen 60 Sekunden (einer Minute) und 3600 Sekunden (einer Stunde) liegen. Diese Einstellung gilt nur für den Delivery Controller, auf dem sie ausgeführt wurde. Um Konsistenz über alle Delivery Controller hinweg zu gewährleisten, sollten Sie dieses Cmdlet auf jedem Delivery Controller ausführen. Beispiel: Set-LhcConfigSyncIntervalOverride -Seconds 1200
Clear-LhcConfigSyncIntervalOverride Setzt das Intervall, in dem der Citrix Config Synchronizer Service (CSS) nach Konfigurationsänderungen innerhalb der Site sucht, auf den Standardwert von 300 Sekunden (fünf Minuten) zurück. Diese Einstellung gilt nur für den Delivery Controller, auf dem sie ausgeführt wurde. Um Konsistenz über alle Delivery Controller hinweg zu gewährleisten, sollten Sie dieses Cmdlet auf jedem Delivery Controller ausführen.
Enable-LhcHighAvailabilitySDK Ermöglicht den Zugriff auf alle Get-Broker*-Cmdlets innerhalb des Delivery Controllers, auf dem es ausgeführt wurde.
Disable-LhcHighAvailabilitySDK Deaktiviert den Zugriff auf die Broker-Cmdlets innerhalb des Delivery Controllers, auf dem es ausgeführt wurde.
Hinweis:
  • Verwenden Sie Port 89, wenn Sie die Get-Broker*-Cmdlets auf dem Delivery Controller ausführen. Beispiel:
    • Get-BrokerMachine -AdminAddress localhost:89
  • Wenn sich der LHC-Broker auf dem Delivery Controller nicht im LHC-Modus befindet, enthält er nur Konfigurationsinformationen.
  • Im LHC-Modus enthält der LHC-Broker auf dem ausgewählten Delivery Controller die folgenden Informationen:
    • Ressourcenzustände
    • Sitzungsdetails
    • VDA-Registrierungen
    • Konfigurationsinformationen