Lokaler Hostcache: Dimensionierung und Skalierung

HINWEIS:

Dieser Artikel enthält Empfehlungen zur Dimensionierung und Skalierung für XenApp- und XenDesktop-Bereitstellungen, die den lokalen Hostcache (LHC) verwenden. Empfehlungen zur Dimensionierung und Skalierung für Citrix DaaS finden Sie unter Überlegungen zur Dimensionierung und Skalierung für Cloud Connectors.

LHC bietet Hochverfügbarkeit, indem es das Verbindungs-Brokering während eines Ausfalls fortsetzen lässt. Benutzer von LHC sollten die folgenden Designüberlegungen beachten:

• Während eines Ausfalls übernimmt ein einzelner Broker pro Zone die Registrierung von Virtual Delivery Agents (VDAs) und das Brokering von Sitzungen.
• Ein Wahlprozess, der entscheidet, welcher Broker aktiv sein wird, berücksichtigt keine Broker-Ressourcen.
• Wenn ein einzelner Broker in einer Zone während des normalen Betriebs nicht alle Anmeldungen verarbeiten kann, wird er im Ausfallmodus nicht gut funktionieren.
• Während eines Ausfalls ist keine Site-Verwaltung verfügbar.
• Ein hochverfügbarer SQL Server ist weiterhin das empfohlene Design.
• Bei Szenarien mit intermittierender Datenbankkonnektivität ist es immer noch besser, den SQL Server zu isolieren und die Site im Ausfallmodus zu belassen, bis alle zugrunde liegenden Probleme behoben sind.
• Es gibt eine Begrenzung von 10.000 VDAs pro Zone.
• Gepoolte Desktops werden im Ausfallmodus in der Standardkonfiguration nicht unterstützt.

Architektur

LHC verwendet eine lokale SQL Server-Datenbank, die hinsichtlich der Festplattenspeichernutzung effizienter ist als Connection Leasing, aber erheblich mehr CPU und Arbeitsspeicher benötigt. LHC durchläuft Synchronisierungsphasen, in denen Details aus der Haupt-Site-Datenbank mit den Brokern (Controllern) synchronisiert werden. LHC verwendet eine SQL-Datenbank, die weiterhin IOPS benötigt und den Vorteil hat, dass SQL diese Schreibvorgänge optimiert.

LHC setzt einen einzelnen Broker ein, der ausgewählt wird, um alle Verbindungen zu vermitteln und VDA-Registrierungen zu verwalten. Alle VDAs in der Site registrieren sich bei diesem einzelnen Broker neu, der dann einen höheren Ressourcenbedarf aufweisen wird (im Vergleich zu einer Multi-Broker-Site im Normalbetrieb), insbesondere in Sites mit einer großen Anzahl von VDAs.

LHC verwendet Microsoft LocalDB, das im Task-Manager als Prozess sqlserver.exe angezeigt wird. Es wurde so konfiguriert, dass es bis zu 1 GB Arbeitsspeicher für das Caching des Datenbankpufferpools verwendet. Der Prozess wird jedoch darüber hinaus wachsen, da die SQL-Engine selbst und andere kleinere Caches Arbeitsspeicher benötigen. Im Allgemeinen gilt: Je länger der Ausfall und je mehr Ressourcen während des Ausfallmodus aufgerufen werden, desto stärker steigt die Speichernutzung von LocalDB. Wenn jedoch die Konnektivität der Site-Datenbank wiederhergestellt ist, behält sqlserver.exe diesen Speicher und gibt ihn nicht sofort an den Hauptpool zurück.

Auswirkungen von CPU-Sockets und -Kernen im Ausfallmodus

LHC verwendet eine Laufzeitversion von SQL Server namens LocalDB, die eine spezielle Lizenzierung hat, die sie auf maximal vier Kerne oder einen einzelnen Socket beschränkt. Dies kann erhebliche Leistungseffekte haben, wenn die physische oder virtuelle Maschine mit mehreren Sockets, aber nur einem oder zwei Kernen konfiguriert wurde. Eine Broker-Maschine mit vier Sockets und einem Kern pro Socket beschränkt LocalDB auf die Verwendung eines einzelnen Kerns, während dieselbe VM, die als 1-Socket-, 4-Kern-Maschine konfiguriert ist, bedeutet, dass LocalDB auf alle vier Kerne zugreifen kann (wenn auch diese mit anderen Prozessen geteilt werden). Im Ausfallmodus führt LocalDB denselben Broker- und SQL-Code aus wie im Normalbetrieb. Viele der SQL-Abfragen können CPU-intensiv sein und sich direkt auf die Leistung des Brokering im Ausfallmodus auswirken. Einzelheiten finden Sie unter Überlegungen zu Größe und Skalierung für Cloud-Connectors und auch unter Compute-Kapazitätsgrenzen nach SQL Server-Edition.

Weitere Faktoren sind die Site-Konfiguration selbst, wie zum Beispiel die folgenden:

• Die Anzahl der veröffentlichten Anwendungen
• Die Anzahl der vermittelten Benutzer
• Die Rate, mit der Benutzer versuchen, Sitzungen zu starten
• Active Directory-Leistung

Wenn die gesamte CPU-Auslastung des Brokers 100 % erreicht, erhöht sich die Antwortzeit des Brokering, Anmeldungen dauern länger und einige Anmeldeversuche können fehlschlagen.

Sites mit mehreren Brokern

Im Site-Ausfallmodus verarbeitet nur ein einzelner Broker Registrierungs- und Anmeldeanfragen. In einer Multi-Broker-Site findet ein Wahlprozess statt, um den Broker zu bestimmen, der während des Ausfalls aktiv sein wird. Dieser Wahlprozess berücksichtigt jedoch nicht die den Brokern zur Verfügung stehenden physischen Ressourcen. Das bedeutet, dass in einer Site, in der Broker unterschiedliche Ressourcenmengen haben, der gewählte Broker nicht unbedingt der leistungsstärkste in Bezug auf CPU oder RAM ist, was potenziell zu einer schlechten Leistung im Ausfallmodus führen könnte. Es ist wichtig, dass jeder Broker die zusätzlichen Anforderungen von LHC erfüllt, falls er gewählt wird.

Synchronisierung mit der Site-Datenbank

Der CitrixConfigSync-Dienst übernimmt den Import von Daten aus der Site-Datenbank in eine lokale Kopie auf den Brokern. Er überwacht die Site-Datenbank auf Änderungen an der Site-Konfiguration und löst bei Änderungen einen neuen Import aus. Eine Kopie der aktuellen lokalen Datenbank wird erstellt, bevor der Import beginnt. Je größer die Anzahl der Ressourcen (z. B. VDAs) in einer Site ist, desto länger dauert der Import, aber er sollte für eine Site mit 10.000 VDAs weniger als zehn Minuten betragen.

Datenbankstandort

Die lokale Datenbank wird gespeichert unter:

C:\Windows\ServiceProfiles\NetworkService\HaDatabaseName.mdf

Um die Zuverlässigkeit zu gewährleisten, erstellt der CitrixConfigSync Service eine Sicherung des zuvor erfolgreich synchronisierten Datenbankimports, bevor eine neue Standortdatenbanksynchronisierung gestartet wird. Sollte die Synchronisierung aus irgendeinem Grund nicht erfolgreich abgeschlossen werden, wird die Sicherung verwendet, bis eine erfolgreiche Synchronisierung abgeschlossen ist. Sie sollten die Datenbank nicht manuell kopieren.

Technische Spezifikationen des lokalen Hostcaches

Lokalen Hostcache aktivieren oder deaktivieren

LHC kann bei Bedarf aktiviert oder deaktiviert werden.

Einschränkungen

Desktops müssen zugewiesen worden sein, bevor sie im Ausfallmodus verwendet werden können. Nicht zugewiesene Desktops stehen für das Brokering nicht zur Verfügung. Dies kann dazu führen, dass Desktops nicht verfügbar sind und „im Wartungsmodus“ melden, wenn ein Ausfall auftritt, bevor alle Zuweisungen synchronisiert wurden, obwohl einem Benutzer tatsächlich ein Desktop zugewiesen wurde.

Gepoolte Desktops werden im Ausfallmodus in der Standardkonfiguration nicht unterstützt. Es gibt eine Problemumgehung, die jedoch potenzielle Sicherheits- und Leistungsbeeinträchtigungen mit sich bringt. Wenn Sie eine Delivery Group mit gepoolten Desktops so konfigurieren, dass sie beim Abmelden nicht neu gestartet werden, sind alle eingeschalteten gepoolten Desktops in dieser Gruppe im Ausfallmodus verfügbar. Nach der Abmeldung eines Benutzers befindet sich der Desktop jedoch nicht in einem sauberen Zustand, da der Desktop nicht neu gestartet wird. Dies könnte in jedem Szenario ein Sicherheitsrisiko darstellen. Wenn der nächste Benutzer dieses Desktops ein lokaler Administrator dieses Desktops ist, könnten Daten eines früheren Benutzers zugänglich sein. Und obwohl dieses Risiko für Standardbenutzer (Nicht-Administratoren) weniger bedenklich ist, sollten Sie bedenken, dass Anwendungen sich möglicherweise nicht ordnungsgemäß verhalten und im Laufe der Zeit Leistungsprobleme verursachen könnten. Wichtig: Administratoren sollten die potenziellen Auswirkungen der Verwendung dieser Problemumgehung für die Verwendung nicht neu gestarteter gepoolter Desktops im Ausfallmodus sorgfältig abwägen.

Während eines Ausfalls können keine Site-Änderungen vorgenommen werden; die Datenbank ist effektiv ein Snapshot der Haupt-Sitedatenbank und wird bei jeder neuen Synchronisierung verworfen.

Datenbankgröße

Für die 10.000 VDI-Konfiguration (d. h. 10.000 Single-Session-VDI-Desktops) betrug die LocalDB etwa 75 MB. Für die 100.000 RDS-Konfiguration (d. h. 100.000 Benutzer) variierte die LocalDB zwischen 100 und 300 MB, abhängig von der Anzahl der Anwendungen und Anmeldungen. Da eine Kopie der Datenbank vor einem neuen Import erstellt wird, sollten Sie 1 GB Speicherplatz für LocalDB einplanen.

Überlegungen zur Benutzerdimensionierung

Obwohl 10.000 VDAs das Maximum pro Zone sind, empfiehlt Citrix, auch die Spitzensitzungen pro Zone zu berücksichtigen, da Sitzungen zur Last des gewählten Brokers während eines Ausfalls beitragen. Die Sitzungsdichte spielt eine Rolle bei der Verwendung von Multisession-VDAs, da mehrere Sitzungen auf einem einzelnen VDA initiiert werden können.

Während eines Ausfalls liegt der empfohlene Spitzenwert bei 25.000 Benutzern pro Zone, die bei richtiger Dimensionierung 1-2.000 Ressourcenstarts pro Minute erreichen können.

Anwendungsstarts werden ähnlich wie Desktop-Starts behandelt. Für beide gelten die gleichen Empfehlungen; Citrix empfiehlt jedoch, auch die Startrate zu berücksichtigen. Ein einzelner Benutzer kann mehrere Anwendungen starten, wodurch die pro Benutzer auf den Broker während eines Ausfalls wirkende Last erhöht wird.

Berücksichtigen Sie bei der Berechnung der Anwendungskapazität die durchschnittliche Anzahl der pro Benutzer gestarteten Anwendungen und halten Sie diese innerhalb der gleichen Empfehlung von 25.000 pro Zone.

Zusammenfassung

Während eines Datenbankausfalls der Site unterstützt LHC eine Vielzahl von Ressourcen und Bedingungen, erfordert jedoch bei der Nutzung eine Planung und Berücksichtigung von CPU und Arbeitsspeicher.

In Sites mit mehreren Brokern kann jeder Broker zum Ausfall-Broker gewählt werden, und daher müssen alle über genügend Ressourcen verfügen, um im Ausfallmodus zurechtzukommen. Es wird keine Bewertung der Broker-Ressourcen vorgenommen, sodass in einer Site mit Brokern, die unterschiedliche Mengen an Ressourcen aufweisen, der am wenigsten leistungsstarke Broker während eines Ausfalls gewählt werden kann.

Das Layout von Kernen und Sockets muss als Teil des Designs der Broker berücksichtigt werden.

Die Anzahl der veröffentlichten Anwendungen und Desktops wirkt sich auf die Anmeldeantwortzeiten und den maximalen Anmeldedurchsatz aus.

Broker mit unzureichenden CPU-Ressourcen können fehlgeschlagene Starts erleben.

Citrix empfiehlt, Ihre Antivirus-Ausschlüsse zu definieren. Weitere Informationen finden Sie unter Tech Paper: Endpoint Security, Antivirus and Antimalware Best Practices.

Zwei zusätzliche Kerne und 2 GB RAM sind ein guter Ausgangspunkt für Leistungstests im LHC-Ausfallmodus.

1 GB Festplattenspeicher ist für die LocalDB-Datenbank ausreichend.

Ein überlasteter Broker führt zu fehlgeschlagenen Verbindungen.