Local Host Cache
Um sicherzustellen, dass die XenApp- und XenDesktop-Sitedatenbank immer verfügbar ist, empfiehlt Citrix, mit einer fehlertoleranten SQL Server-Bereitstellung zu beginnen, indem die Best Practices von Microsoft für Hochverfügbarkeit befolgt werden. (Der Abschnitt „Datenbanken“ im Artikel Systemanforderungen listet die in XenApp und XenDesktop unterstützten SQL Server-Hochverfügbarkeitsfunktionen auf.) Netzwerkprobleme und -unterbrechungen können jedoch dazu führen, dass Benutzer keine Verbindung zu ihren Anwendungen oder Desktops herstellen können.
Die Funktion „Local Host Cache“ (LHC) ermöglicht es, Verbindungsbroker-Vorgänge in einer XenApp- oder XenDesktop-Site fortzusetzen, wenn ein Ausfall auftritt. Ein Ausfall tritt auf, wenn die Verbindung zwischen einem Delivery Controller™ und der Sitedatenbank fehlschlägt. Der Local Host Cache wird aktiviert, wenn die Sitedatenbank 90 Sekunden lang nicht zugänglich ist.
Local Host Cache ist die umfassendste Hochverfügbarkeitsfunktion in XenApp und XenDesktop. Sie ist eine leistungsfähigere Alternative zur Verbindungsleasing-Funktion, die in XenApp 7.6 eingeführt wurde.
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; lesen Sie weiter, um zu erfahren, wie er funktioniert.
Hinweis:
Obwohl Verbindungsleasing in Version 7.15 LTSR unterstützt wird, wird es in der nächsten Version entfernt.
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 explizit Rechte für von der Site veröffentlichte Ressourcen zugewiesen sind.
- Identitäten von Benutzern, die derzeit oder kürzlich veröffentlichte Ressourcen von der Site verwendet haben.
- Identitäten von VDA-Maschinen (einschließlich Remote-PC-Zugriffsmaschinen), 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 zu aktuell aktiven Verbindungen, die hergestellt wurden, während die Hauptdatenbank nicht verfügbar war:
- Ergebnisse jeder Endpunktanalyse von Clientmaschinen, die von Citrix Receiver durchgeführt wurde.
- Identitäten von Infrastrukturmaschinen (wie NetScaler Gateway- und StoreFront™-Server), die mit der Site verbunden sind.
- Datums- und Uhrzeitangaben sowie Arten der letzten Aktivitäten von Benutzern.
Funktionsweise
Die folgende Abbildung 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 und kommuniziert mit der Sitedatenbank, um Benutzer mit VDAs zu verbinden, die beim Controller registriert sind.
- Alle zwei Minuten wird geprüft, ob Änderungen an der Konfiguration des Hauptbrokers vorgenommen wurden. Diese Änderungen können durch PowerShell/Studio-Aktionen (z. B. das Ändern einer Eigenschaft einer Bereitstellungsgruppe) oder Systemaktionen (z. B. Maschinenzuweisungen) initiiert worden sein.
- Wenn seit der letzten Prüfung eine Änderung vorgenommen wurde, verwendet der Hauptbroker den Citrix Config Synchronizer Service (CSS), um Informationen auf einen sekundären Broker (Citrix High Availability Service) auf dem Controller zu synchronisieren (zu kopieren). Alle Broker-Konfigurationsdaten werden kopiert, nicht nur die Elemente, die sich seit der vorherigen Prüfung geändert haben. 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 vorgenommen wurden, werden keine Daten kopiert.
Die folgende Abbildung veranschaulicht die Änderungen der Kommunikationspfade, wenn der Hauptbroker den Kontakt zur Sitedatenbank verliert (ein Ausfall beginnt):
Wenn ein Ausfall beginnt:
- Der Hauptbroker kann nicht mehr mit der Sitedatenbank kommunizieren und hört auf, auf StoreFront- und VDA-Informationen zu warten (in der Abbildung mit X gekennzeichnet). Der Hauptbroker weist dann den sekundären Broker (High Availability Service) an, mit dem Warten auf und der Verarbeitung von Verbindungsanfragen zu beginnen (in der Abbildung mit einer rot gestrichelten Linie gekennzeichnet).
- Wenn der Ausfall beginnt, hat der sekundäre Broker keine aktuellen VDA-Registrierungsdaten, aber sobald ein VDA mit ihm kommuniziert, wird ein Neuregistrierungsprozess 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 primäre Broker weiterhin die Verbindung zur Site-Datenbank. Wenn die Verbindung wiederhergestellt ist, weist der primäre Broker den sekundären Broker an, das Abhören von Verbindungsinformationen einzustellen, und der primäre Broker nimmt die Broker-Operationen wieder auf. Wenn ein VDA das nächste Mal mit dem primären Broker kommuniziert, wird ein erneuter Registrierungsprozess ausgelöst. Der sekundäre Broker entfernt alle verbleibenden VDA-Registrierungen vom vorherigen Ausfall und setzt die Aktualisierung der LocalDB-Datenbank mit Konfigurationsänderungen fort, die vom CSS empfangen 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. Weitere Informationen finden Sie im Abschnitt „Monitor“ unten.
Sie können auch absichtlich einen Ausfall auslösen; weitere Informationen dazu, warum und wie dies zu tun ist, finden Sie im Abschnitt „Ausfall erzwingen“ unten.
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 kennt jeder sekundäre Broker alle anderen sekundären Broker.
Die sekundären Broker kommunizieren über einen separaten Kanal miteinander. Sie 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 im Falle eines Ausfalls für die Broker-Operationen in der Zone zuständig sein wird. Während des Ausfalls registrieren sich alle VDAs erneut 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, um die Aufgabe zu übernehmen, und die VDAs registrieren sich erneut beim neu gewählten sekundären Broker.
Wenn während eines Ausfalls ein Controller neu gestartet wird:
- Wenn dieser Controller nicht der gewählte primäre Broker ist, hat der Neustart keine Auswirkungen.
- Wenn dieser Controller der gewählte primäre Broker ist, wird ein anderer Controller gewählt, was dazu führt, dass sich die VDAs erneut registrieren. Nachdem der neu gestartete Controller hochgefahren ist, übernimmt er automatisch das Brokering, was dazu führt, dass sich die VDAs erneut registrieren. In diesem Szenario kann die Leistung während der erneuten Registrierungen beeinträchtigt werden.
Wenn Sie einen Controller während des normalen Betriebs ausschalten und ihn dann während eines Ausfalls einschalten, kann Local Host Cache auf diesem Controller nicht verwendet werden, wenn er als primärer Broker gewählt wird.
Das Ereignisprotokoll enthält Informationen zu Wahlen. Siehe den Abschnitt „Monitor“ unten.
Überlegungen und Anforderungen zum Design
Local Host Cache wird für servergehostete Anwendungen und Desktops sowie statische (zugewiesene) Desktops unterstützt; er wird nicht für gepoolte VDI-Desktops (erstellt von MCS oder PVS) unterstützt.
Es gibt keine zeitliche Begrenzung für den Betrieb im Ausfallmodus. Stellen Sie den Standort jedoch so schnell wie möglich wieder auf den Normalbetrieb um.
Was während eines Ausfalls nicht verfügbar ist oder sich ändert:
- Sie können Studio nicht verwenden oder PowerShell-Cmdlets ausführen.
- 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 können mehr Sitzungen nutzen, als ihre konfigurierten Sitzungslimits zulassen, 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 Broker in einer Zone zu einem VDA in einer anderen Zone) werden während eines Ausfalls nicht unterstützt.
Standardmäßig werden energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen, bei denen die Eigenschaft ShutdownDesktopsAfterUse aktiviert ist, bei einem Ausfall in den Wartungsmodus versetzt. Sie können diese Standardeinstellung ändern, um die Nutzung dieser Desktops während eines Ausfalls zu ermöglichen. Sie können sich jedoch während des Ausfalls nicht auf die Energieverwaltung verlassen. (Die Energieverwaltung wird nach Wiederaufnahme des normalen Betriebs fortgesetzt.) Außerdem können diese Desktops Daten des vorherigen Benutzers enthalten, da sie nicht neu gestartet wurden.
Um das Standardverhalten zu überschreiben, müssen Sie es standortweit und für jede betroffene Bereitstellungsgruppe aktivieren.
Führen Sie für den Standort das folgende PowerShell-Cmdlet aus:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Führen Sie für jede betroffene Bereitstellungsgruppe das folgende PowerShell-Cmdlet aus:
Set-BrokerDesktopGroup -Name "\<*name*\>" -ReuseMachinesWithoutShutdownInOutage $true
Das Aktivieren dieser Funktion im Standort und in den Bereitstellungsgruppen hat keinen Einfluss darauf, wie die konfigurierte Eigenschaft ShutdownDesktopsAfterUse während des normalen Betriebs funktioniert.
RAM-Größe:
Der LocalDB-Dienst kann ca. 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 High Availability Service kann bis zu 1 GB RAM verwenden, wenn ein Ausfall über einen längeren Zeitraum mit vielen Anmeldungen andauert (z. B. 12 Stunden mit 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.
Beachten Sie, dass bei Verwendung einer SQL Server Express-Installation für die Site-Datenbank der Server zwei sqlserver.exe-Prozesse aufweist.
CPU-Kern- und Socket-Konfiguration:
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 Hostcaches aus, sogar noch stärker als die Speicherzuweisung. Dieser CPU-Overhead wird nur während des Ausfallzeitraums beobachtet, wenn die Datenbank nicht erreichbar ist und der High Availability Service aktiv ist.
Obwohl LocalDB mehrere Kerne (bis zu 4) verwenden kann, ist es auf einen einzigen 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.
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 ein MB. Wenn der normale Betrieb wieder aufgenommen wird, wird die lokale Datenbank neu erstellt und der Speicherplatz freigegeben. Der Broker muss jedoch über ausreichend Speicherplatz auf dem Laufwerk verfügen, auf dem die LocalDB installiert ist, um das Datenbankwachstum während eines Ausfalls zu ermöglichen. Der lokale Hostcache verursacht während eines Ausfalls auch zusätzliche E/A-Vorgänge: ca. 3 MB Schreibvorgänge pro Sekunde mit mehreren Hunderttausend Lesevorgängen.
Leistung:
Während eines Ausfalls wickelt ein Broker alle Verbindungen ab. In Sites (oder Zonen), die während des normalen Betriebs die Last auf mehrere Controller verteilen, muss der ausgewählte Broker während eines Ausfalls möglicherweise viel mehr Anfragen bearbeiten als normal. Daher ist der CPU-Bedarf höher. Jeder Broker in der Site (Zone) muss in der Lage sein, die zusätzliche Last zu bewältigen, die durch LocalDB und alle betroffenen VDAs entsteht, da der während eines Ausfalls ausgewählte Broker wechseln könnte.
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 während eines Ausfalls bis zu 10.000 VDAs in jeder Zone effektiv verwaltet werden, bis zu einem Maximum von 40.000 VDAs in der Site. Zum Beispiel 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 mit 10.000 VDAs und sechs mit jeweils 5.000 VDAs.
Während eines Ausfalls kann die Lastverwaltung innerhalb der Site beeinträchtigt sein. Lastauswerter (und insbesondere Regeln für die Sitzungsanzahl) können überschritten werden.
Während der Zeit, die alle VDAs für die erneute Registrierung bei einem Broker benötigen, verfügt dieser Broker möglicherweise nicht über vollständige Informationen zu aktuellen Sitzungen. Eine Benutzerverbindungsanforderung während dieses Intervalls könnte daher zum Start einer neuen Sitzung führen, obwohl eine Wiederverbindung zu einer bestehenden Sitzung möglich gewesen wäre. Dieses Intervall (während dessen der „neue“ Broker bei der erneuten Registrierung Sitzungsinformationen von allen VDAs abruft) ist unvermeidlich. Beachten Sie, dass Sitzungen, die bei Beginn eines Ausfalls verbunden sind, während des Übergangsintervalls nicht betroffen sind, neue Sitzungen und Sitzungswiederverbindungen jedoch schon.
Dieses Intervall tritt immer dann auf, wenn sich VDAs bei einem anderen Broker neu registrieren müssen:
- Ein Ausfall beginnt: Beim Migrieren von einem primären Broker zu einem sekundären Broker.
- Brokerfehler 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-Protokolls 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.
Der folgende Befehl ändert den Heartbeat beispielsweise 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
Das Intervall kann nicht vollständig eliminiert werden, unabhängig davon, wie schnell sich die VDAs registrieren.
Die Synchronisierungszeit zwischen Brokern nimmt mit der Anzahl der Objekte (z. B. VDAs, Anwendungen, Gruppen) zu. Das Synchronisieren von 5000 VDAs kann beispielsweise zehn Minuten oder länger dauern. Weitere Informationen zu Synchronisierungseinträgen im Ereignisprotokoll finden Sie im Abschnitt „Überwachen“ weiter unten.
Lokalen Hostcache verwalten
Damit der lokale Hostcache ordnungsgemäß funktioniert, muss die PowerShell-Ausführungsrichtlinie auf jedem Controller auf RemoteSigned, Unrestricted oder Bypass festgelegt sein.
SQL Server Express LocalDB
Die von Local Host Cache verwendete Microsoft SQL Server Express LocalDB wird automatisch installiert, wenn Sie einen Controller installieren oder einen Controller von einer Version vor 7.9 aktualisieren. Für die LocalDB ist keine Administratorwartung erforderlich. 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 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.
Standardeinstellungen nach der Installation und dem Upgrade von XenApp oder XenDesktop®
Bei einer Neuinstallation von XenApp® und XenDesktop ist Local Host Cache standardmäßig aktiviert. (Verbindungsleasing ist standardmäßig deaktiviert.)
Nach einem Upgrade bleibt die Local Host Cache-Einstellung unverändert. Wenn Local Host Cache beispielsweise in der früheren Version aktiviert war, bleibt er in der aktualisierten Version aktiviert. Wenn Local Host Cache in der früheren Version deaktiviert (oder nicht unterstützt) war, bleibt er in der aktualisierten Version deaktiviert.
Local Host Cache aktivieren und deaktivieren
Um Local Host Cache zu aktivieren, geben Sie Folgendes ein:
Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false
Dieses Cmdlet deaktiviert auch die Verbindungsleasing-Funktion. Aktivieren Sie nicht gleichzeitig Local Host Cache und Verbindungsleasing.
Um festzustellen, ob Local Host Cache aktiviert ist, geben Sie Folgendes ein:
Get-BrokerSite
Überprüfen Sie, ob die Eigenschaft LocalHostCacheEnabled auf True und die Eigenschaft ConnectionLeasingEnabled auf False gesetzt ist.
Um Local Host Cache zu deaktivieren (und Verbindungsleasing zu aktivieren), geben Sie Folgendes ein:
Set-BrokerSite -LocalHostCacheEnabled $false -ConnectionLeasingEnabled $true
Ü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 High Availability Service 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, versetzen Sie alle Controller wieder in den normalen Modus. Dies kann etwa 15 Minuten dauern, um VDA-Registrierungsstürme zu vermeiden.
Ausfall erzwingen
Möglicherweise möchten Sie absichtlich einen Datenbankausfall erzwingen.
- Wenn Ihr Netzwerk wiederholt ausfällt. Das Erzwingen eines Ausfalls, bis die Netzwerkprobleme behoben sind, verhindert einen kontinuierlichen Übergang zwischen Normal- und Ausfallmodus.
- Um einen Notfallwiederherstellungsplan zu testen.
- Beim Ersetzen oder Warten des Site-Datenbankservers.
Um einen Ausfall zu erzwingen, bearbeiten Sie die Registrierung jedes Servers, der einen Delivery Controller enthält.
- Setzen Sie in HKLM\Software\Citrix\DesktopServer\LHC den Wert OutageModeForced auf 1. Dies weist den Broker an, in den Ausfallmodus zu wechseln, unabhängig vom Status der Datenbank. (Das Setzen des Werts auf 0 beendet den Ausfallmodus des Servers.)
- In einem Citrix Cloud™-Szenario wechselt der Connector in den Ausfallmodus, unabhängig vom Status der Verbindung zur Steuerungsebene oder primären Zone.
Überwachung
Ereignisprotokolle zeigen an, wann Synchronisierungen und Ausfälle auftreten.
Config Synchronizer Service:
Während des normalen Betriebs können die folgenden Ereignisse auftreten, wenn der CSS die Brokerkonfiguration kopiert und exportiert und sie mithilfe des High Availability Service (sekundärer Broker) in die LocalDB importiert.
- 503: Eine Änderung wurde in der primären Brokerkonfiguration gefunden, und ein Import wird gestartet.
- 504: Die Brokerkonfiguration wurde erfolgreich kopiert, exportiert und dann in die LocalDB importiert.
- 505: Ein Import in die LocalDB ist fehlgeschlagen; siehe unten für weitere Informationen.
- 510: Keine Konfigurationsdaten des Konfigurationsdienstes 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, weil der sekundäre Broker (High Availability Service) nicht ausgeführt wird.
High Availability Service:
- 3502: Ein Ausfall ist aufgetreten, und der sekundäre Broker (High Availability Service) führt Broker-Operationen aus.
- 3503: Ein Ausfall wurde behoben, und der normale Betrieb wurde wieder aufgenommen.
- 3504: Zeigt an, welcher sekundäre Broker gewählt wurde, sowie andere Broker, die an der Wahl beteiligt sind.
Problembehandlung
Mehrere Tools zur Fehlerbehebung stehen zur Verfügung, wenn ein Synchronisierungsimport in die LocalDB fehlschlägt und ein 505-Ereignis protokolliert 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: Stellt die genaue Konfiguration zu Debugging-Zwecken bereit.
Export-BrokerConfiguration | Out-File file-pathname
Zum Beispiel Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.
In diesem Artikel
- Dateninhalt
- Funktionsweise
- Sites mit mehreren Controllern
- Überlegungen und Anforderungen zum Design
- Lokalen Hostcache verwalten
- SQL Server Express LocalDB
- Standardeinstellungen nach der Installation und dem Upgrade von XenApp oder XenDesktop®
- Local Host Cache aktivieren und deaktivieren
- Überprüfen, ob der Local Host Cache funktioniert
- Ausfall erzwingen
- Überwachung
- Problembehandlung