Lokaler Hostcache
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. Es kommt zu einem Ausfall, wenn ein Fehler bei der Verbindung zwischen einem Delivery Controller und der Sitedatenbank auftritt. Der lokale Hostcache wird aktiviert, wenn die Sitekonfigurationsdatenbank für 90 Sekunden nicht verfügbar ist.
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 Hostcache 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.
Hinweis:
Das Verbindungsleasing wird in Version 7.15 LTSR zwar unterstützt, aus dem nachfolgenden Release wird es jedoch entfernt.
Dateninhalt
Der lokale Hostcache enthält folgende Informationen (die eine Teilmenge der Informationen in der Hauptdatenbank sind):
- Identität der Benutzer und Gruppen, denen Rechte für die in der Site veröffentlichte Ressourcen zugewiesen wurden.
- Identität der Benutzer, die Ressourcen der Site gerade verwenden oder kürzlich verwendet haben.
- Identität von VDA-Maschinen (einschließlich Remote-PC-Zugriffsmaschinen), die in der Site konfiguriert sind.
- Identität (Name und IP-Adresse) von Citrix Receiver-Clientmaschinen, die aktiv für die Verbindung mit veröffentlichten Ressourcen verwendet werden.
Er enthält außerdem Informationen zu aktiven Verbindungen, die eingerichtet wurden, während die Hauptdatenbank nicht verfügbar war:
- Ergebnisse jeglicher von Citrix Receiver durchgeführten Clientmaschinen-Endpunktanalyse.
- Identität von Infrastrukturmaschinen (z. B. NetScaler Gateway- und StoreFront-Server), die mit der Site zu tun haben.
- Datum und Uhrzeit und Art kürzlich erfolgter Aktivitäten von Benutzern.
Funktionsweise
Die folgende Abbildung zeigt die Komponenten des lokalen Hostcaches und die im Normalbetrieb verwendeten Kommunikationspfade:
Normalbetrieb:
- Der Hauptbroker (Citrix Brokerdienst) 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, verwendet der Hauptbroker CSS (Citrix Config Sync-Dienst), um die Informationen mit dem sekundären Broker (Citrix Dienst für hohe Verfügbarkeit) auf dem Controller zu synchronisieren (Kopie). 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):
Wenn ein Ausfall beginnt:
- 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.
Wird bei einem Ausfall ein Controller neu gestartet, passiert Folgendes:
- Handelt es sich bei dem Controller nicht um den gewählten primären Broker, hat der Neustart keine Auswirkungen.
- Handelt es sich um den gewählten primären Broker, wird ein anderer Controller gewählt und somit werden die VDAs neu registriert. Wenn der Neustart des Controllers beendet ist, übernimmt er automatisch das Brokering und somit werden die VDAs erneut neu registriert. In diesem Szenario kann es während der erneuten Registrierung zu Leistungseinbußen kommen.
Wenn Sie einen Controller während des normalen Betriebs ausschalten und dann während eines Ausfalls einschalten, kann der lokale Hostcache auf diesem Controller nicht verwendet werden, wenn dieser als primärer Broker ausgewählt wurde.
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.
- 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.
- 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. Startvorgänge über Zonen hinweg (von einem Broker in einer Zone zu einem VDA in einer anderen Zone) werden während eines Ausfalls nicht unterstützt.
Energieverwaltete Desktop-VDAs in gepoolten Bereitstellungsgruppen, für die die Eigenschaft ShutdownDesktopsAfterUse aktiviert ist, werden standardmäßig bei einem Ausfall in den Wartungsmodus versetzt. Sie können diese Standardeinstellung ändern, damit solche Desktops während eines Ausfalls verwendet werden können. Während des Ausfalls können Sie sich jedoch nicht auf die Energieverwaltung verlassen. (Die Energieverwaltung wird bei Wiederaufnahme des Normalbetriebs wieder aufgenommen.) Solche Desktops können außerdem Daten des vorherigen Benutzers enthalten, weil sie nicht neu gestartet wurden.
Um das Standardverhalten außer Kraft zu setzen, müssen Sie es Site-übergreifend für jede betroffene Bereitstellungsgruppe aktivieren.
Führen Sie für die Site das folgende PowerShell Cmdlet aus:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Führen Sie das folgende PowerShell-Cmdlet für jede betroffene Bereitstellungsgruppe aus:
Set-BrokerDesktopGroup -Name "\<*name*\>" -ReuseMachinesWithoutShutdownInOutage $true
Das Aktivieren dieses Features für die Site und Bereitstellungsgruppen wirkt sich nicht auf die Funktionsweise der Eigenschaft ShutdownDesktopsAfterUse während des normalen Betriebs aus.
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 das Ausführen 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 ein 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.
VDI-Grenzwerte:
- In einer einzonigen VDI-Bereitstellung können während eines Ausfalls bis zu 10.000 VDAS effektiv bewältigt werden.
- In einer VDI-Bereitstellung mit mehreren Zonen können bis zu 10.000 VDAs pro Zone und insgesamt bis zu 40.000 VDAs pro Site gehandhabt werden. Beispielsweise ist ein effektives Handling der folgenden Sites während eines Ausfalls möglich:
- Eine Site mit vier Zonen mit je 10.000 VDAs
- Eine Site mit sieben Zonen, von denen eine 10.000 VDAs enthält und die restlichen sechs je 5.000 VDAs
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 Wiederverbindung 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. Dieser Taktwert ist doppelt so lang wie das Intervall, das der VDA für Pings verwendet. Der Standardwert führt zu einem Ping alle 5 Minuten.
Mit dem folgenden Befehl ändern Sie beispielsweise den Heartbeat auf fünf Minuten (300.000 Millisekunden), was alle 2,5 Minuten zu einem Ping führt:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
Das Intervall kann nicht vollständig eliminiert werden, egal wie schnell die VDAs registrieren.
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 Hostcache
Damit der lokale Hostcache ordnungsgemäß funktioniert, muss die PowerShell-Ausführungsrichtlinie für jeden Controller auf “RemoteSigned”, “Unrestricted” oder “Bypass” festgelegt sein.
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.
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
Bei einer Neuinstallation von XenApp und XenDesktop ist der lokale Hostcache standardmäßig aktiviert. (Das Verbindungsleasing ist standardmäßig deaktiviert.)
Nach einem Upgrade bleibt die Einstellung für den lokalen Hostcache erhalten. War der lokale Hostcache beispielsweise in der Vorgängerversion aktiviert, ist er auch in der aktualisierten Version aktiviert. Wenn der lokale Hostcache in der früheren Version nicht aktiviert war (oder nicht unterstützt wurde), bleibt er in der aktualisierten Version deaktiviert.
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 $false -ConnectionLeasingEnabled $true
Funktionsprüfung des lokalen Hostcache
Überprüfung des lokalen Hostcache auf korrekte Einrichtung und fehlerfreien Betrieb:
- Stellen Sie sicher, dass Synchronisierungsimporte erfolgreich abgeschlossen werden. Überprüfen Sie die Ereignisprotokolle.
- Stellen Sie sicher, dass die LocalDB von SQL Server Express auf jedem Delivery Controller erstellt wurde. Dadurch wird bestätigt, dass der Dienst für hohe Verfügbarkeit 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 wurde.
- Erzwingen Sie einen Ausfall bei den Delivery Controllern. Vergessen Sie nicht, nach der Funktionsprüfung des lokalen Hostcache alle Controller wieder in den normalen Modus zu versetzen. Dies kann ca. 15 Minuten dauern, um eine VDA-Registrierungsflut zu vermeiden.
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 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 Config Service und beim Importieren in die LocalDB unter Einsatz des Diensts für hohe Verfügbarkeit (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).
- 510: Es wurden keine Konfigurationsdienst-Konfigurationsdaten vom primären Konfigurationsdienst empfangen.
- 517: Ein Problem ist bei der Kommunikation mit dem primären Broker aufgetreten.
- 518: Das Config Sync-Skript wurde abgebrochen, weil der sekundäre Broker (Hohe Verfügbarkeit) nicht ausgeführt wird.
Dienst für hohe Verfügbarkeit:
- 3502: Ein Ausfall ist aufgetreten und der sekundäre Broker (Dienst für hohe Verfügbarkeit) 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: Wenn ein Synchronisierungsimport fehlschlägt, können Sie einen Bericht erstellen. Der Bericht endet mit dem Objekt, das den Fehler verursacht hat. Das Berichtsfeature wirkt sich auf die Synchronisierungsgeschwindigkeit aus. Deshalb empfiehlt Citrix, es zu deaktivieren, wenn es nicht verwendet wird.
Zum Aktivieren von CSS und Erstellen eines Ablaufverfolgungsberichts geben Sie 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.
Wenn der Bericht generiert wurde, deaktivieren Sie das Berichtsfeature durch Eingabe des folgenden Befehls:
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 file-pathname
Beispiel: Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.
In diesem Artikel
- Dateninhalt
- Funktionsweise
- Sites mit mehreren Controllern
- Designüberlegungen und -anforderungen
- Verwalten des lokalen Hostcache
- SQL Server Express-LocalDB
- Standardeinstellungen nach Installation bzw. Upgrade von XenApp- oder XenDesktop
- Aktivieren und Deaktivieren des lokalen Hostcaches
- Funktionsprüfung des lokalen Hostcache
- Erzwingen eines Ausfalls
- Überwachung
- Problembehandlung