Größe und Skalierung des lokalen Hostcache

HINWEIS:

Dieser Artikel enthält Empfehlungen zu Größe und Skalierung für XenApp- und XenDesktop-Bereitstellungen mit Local Host Cache (LHC). Empfehlungen zu Größe und Skalierung für Citrix DaaS finden Sie unter Überlegungen zu Größe und Skalierung für Cloud Connectors.

LHC bietet hohe Verfügbarkeit, da die Verbindungsvermittlung während eines Ausfalls fortgesetzt werden kann. Benutzer von LHC sollten die folgenden Konstruktionsüberlegungen beachten:

• Während eines Ausfalls verarbeitet ein einzelner Broker pro Zone Virtual Delivery Agent (VDA) -Registrierungen und Brokersitzungen.
• Ein Wahlprozess, der entscheidet, welcher Broker aktiv sein wird, berücksichtigt keine Maklerressourcen.
• Wenn ein einzelner Broker in einer Zone während des normalen Betriebs nicht alle Anmeldungen verarbeiten kann, funktioniert er im Ausfallmodus nicht gut.
• Während eines Ausfalls ist keine Site-Verwaltung verfügbar.
• Ein hochverfügbarer SQL Server ist immer noch das empfohlene Design.
• Bei zeitweiligen Datenbankkonnektivitätsszenarien 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 ein Limit von 10.000 VDAs pro Zone.
• In der Standardkonfiguration werden gepoolte Desktops im Ausfallmodus nicht unterstützt.

Architektur

LHC verwendet eine lokale SQL Server-Datenbank, die hinsichtlich der Speicherplatznutzung effizienter ist als Verbindungsleasing, aber erheblich mehr CPU und Arbeitsspeicher benötigt. LHC verfügt über Synchronisationsphasen, in denen Details aus der Hauptstandortdatenbank mit den Brokern (Controllern) synchronisiert werden. LHC verwendet eine SQL-Datenbank, die immer noch IOPS benötigt, und hat den Vorteil, dass SQL diese Schreibvorgänge optimiert.

LHC setzt einen einzigen Broker ein, der für die Vermittlung aller Verbindungen und die Abwicklung von VDA-Registrierungen ausgewählt wird. Alle VDAs in der Site registrieren sich erneut bei diesem einzelnen Broker, der dann einen höheren Ressourcenbedarf (im Vergleich zu einer Multi-Broker-Site im Normalbetrieb) aufweist, insbesondere an Standorten 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 bis zu 1 GB Arbeitsspeicher für das Zwischenspeichern von Datenbank-Pufferpools verwendet werden. Der Prozess wird jedoch darüber hinaus wachsen, da die SQL-Engine Speicher für sich selbst und andere kleinere Caches benötigt. Im Allgemeinen gilt: Je länger der Ausfall dauert und je mehr Ressourcen im Ausfallmodus abgerufen werden, desto mehr LocalDB-Speicher wird verwendet. Wenn jedoch die Konnektivität der Standortdatenbank wiederhergestellt wird, behält sqlserver.exe diesen Speicher bei und gibt ihn nicht sofort an den Hauptpool zurück.

Auswirkung von CPU-Sockeln und Kernen im Ausfallmodus

LHC verwendet eine Laufzeitversion von SQL Server namens LocalDB, die über eine spezielle Lizenzierung verfügt, die sie auf weniger als vier Kerne oder einen einzelnen Socket beschränkt. Dies kann erhebliche Auswirkungen auf die Leistung haben, wenn die physische oder virtuelle Maschine mit mehreren Sockets mit nur einem oder zwei Kernen konfiguriert wurde. Ein Broker-Computer mit vier Sockets und einem Core pro Socket beschränkt LocalDB auf die Verwendung eines einzelnen Kerns, wohingegen dieselbe VM, die als 1-Sockel-4-Core-Maschine konfiguriert ist, bedeutet, dass LocalDB auf alle vier Kerne zugreifen kann (obwohl sie mit anderen Prozessen gemeinsam genutzt werden). Im Ausfallmodus führt LocalDB denselben Broker und denselben SQL-Code wie im normalen Betrieb aus. Viele der SQL-Abfragen können CPU-intensiv sein und sich direkt auf die Leistung des Brokerings im Ausfallmodus auswirken. Einzelheiten finden Sie unter Überlegungen zu Größe und Skalierung für Cloud-Connectors und auch Rechenkapazitätsbeschränkungen nach Edition von SQL Server.

Weitere Faktoren sind die Standortkonfiguration selbst, z. B. die folgenden:

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

Wenn die gesamte CPU-Auslastung des Brokers fast 100% erreicht, erhöht sich die Reaktionszeit bei der Vermittlung, die Verarbeitung von Anmeldungen dauert länger und einige Anmeldeversuche können fehlschlagen.

Websites mit mehreren Brokern

Während des Standortausfallmodus verarbeitet nur ein einziger Broker Registrierungs- und Anmeldeanfragen. In einer Multi-Broker-Site findet ein Wahlprozess statt, um den Broker zu nominieren, der während des Ausfalls aktiv sein wird. Bei diesem Wahlprozess werden jedoch nicht die physischen Ressourcen berücksichtigt, die den Maklern zur Verfügung stehen. Dies bedeutet, dass an einem Standort, an dem Broker über unterschiedliche Ressourcen verfügen, der gewählte Broker nicht unbedingt der leistungsstärkste in Bezug auf CPU oder RAM ist, was möglicherweise zu einer schlechten Leistung im Ausfallmodus führen kann. Es ist wichtig, dass jeder Broker die zusätzlichen Anforderungen von LHC erfüllt, falls er gewählt wird.

Synchronisation mit der Standortdatenbank

Der CitrixConfigSync-Dienst übernimmt den Import von Daten aus der Site-Datenbank in eine lokale Kopie auf den Brokern. Es überwacht die Standortdatenbank auf Änderungen an der Sitekonfiguration 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. Bei einer Site mit 10,000 VDAs sollte er jedoch weniger als zehn Minuten betragen.

Speicherort der Datenbank

Die lokale Datenbank ist gespeichert in:

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

Um die Zuverlässigkeit zu gewährleisten, erstellt der CitrixConfigSync-Dienst eine Backup des zuvor erfolgreich synchronisierten Datenbank-Imports, bevor eine neue Standortdatenbanksynchronisierung gestartet wird. Wenn die Synchronisierung aus irgendeinem Grund nicht erfolgreich abgeschlossen wird, wird die Backup verwendet, bis eine erfolgreiche Synchronisierung abgeschlossen ist. Sie sollten die Datenbank nicht manuell kopieren.

Technische Daten des lokalen Host-Caches

Lokalen Hostcache aktivieren oder deaktivieren

LHC kann je nach 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 nicht für die Vermittlung zur Verfügung. Dies kann dazu führen, dass Desktops nicht verfügbar sind und “im Wartungsmodus” gemeldet werden, wenn ein Ausfall auftritt, bevor alle Zuweisungen synchronisiert wurden, obwohl einem Benutzer tatsächlich ein Desktop zugewiesen wurde.

In der Standardkonfiguration werden gepoolte Desktops im Ausfallmodus nicht unterstützt. Es gibt eine Problemumgehung, die jedoch potenzielle Auswirkungen auf Sicherheit und Leistung hat. Wenn Sie eine Bereitstellungsgruppe mit gepoolten Desktops so konfigurieren, dass sie bei der Abmeldung nicht neu gestartet wird, stehen alle eingeschalteten Pool-Desktops in dieser Gruppe im Ausfallmodus zur Verfügung. Nachdem sich ein Benutzer abgemeldet hat, befindet sich der Desktop jedoch nicht in einem sauberen Zustand, da der Desktop nicht neu gestartet wird. Dies kann in jedem Szenario ein Sicherheitsproblem sein. Wenn der nächste Benutzer dieses Desktops ein lokaler Administrator dieses Desktops ist, kann möglicherweise auf Daten eines früheren Benutzers zugegriffen werden. Und obwohl dieses Risiko für Standardbenutzer (Nicht-Administratorbenutzer) weniger besorgniserregend ist, sollten Sie bedenken, dass sich Anwendungen nicht ordnungsgemäß verhalten und im Laufe der Zeit Leistungsprobleme verursachen können. Wichtig: Administratoren sollten die möglichen Auswirkungen dieser Problemumgehung für die Verwendung nicht neu gestarteter Pool-Desktops im Ausfallmodus sorgfältig abwägen.

Während eines Ausfalls können keine Standortänderungen vorgenommen werden. Die Datenbank ist quasi ein Snapshot der Hauptstandortdatenbank und wird bei jeder neuen Synchronisation verworfen.

Größe der Datenbank

Bei der 10.000 VDI-Konfiguration (d. h. 10.000 VDI-Desktops für Einzelsitzungen) betrug die LocalDB etwa 75 MB. Für die 100.000 RDS-Konfiguration (d. h. 100.000 Benutzer) variierte die LocalDB je nach Anzahl der Anwendungen und Anmeldungen zwischen 100 und 300 MB. Da eine Kopie der Datenbank erstellt wird, bevor ein neuer Import gestartet wird, sollten Sie 1 GB Speicherplatz für LocalDB einplanen.

Überlegungen zur Benutzergröße

Obwohl 10.000 VDAs das Maximum pro Zone sind, da Sitzungen während eines Ausfalls zur Auslastung des ausgewählten Brokers beitragen, empfiehlt Citrix, dass Sie auch die Spitzensitzungen pro Zone berücksichtigen. Die Sitzungsdichte kommt bei der Verwendung von Multisession-VDAs ins Spiel, da mehrere Sitzungen an einem einzelnen VDA initiiert werden können.

Während eines Ausfalls liegt die empfohlene Spitzenleistung bei 25.000 Benutzern pro Zone, die bei richtiger Größe möglicherweise 1-2 000 Ressourcenstarts pro Minute erreichen können.

Anwendungsstarts werden ähnlich behandelt wie Desktop-Starts. Für beide gelten dieselben Empfehlungen. Citrix empfiehlt jedoch, dass Sie auch die Startrate berücksichtigen. Ein einzelner Benutzer kann mehrere Anwendungen starten, wodurch die Belastung des Brokers pro Benutzer während eines Ausfalls erhöht wird.

Beachten Sie bei der Berechnung der Anwendungskapazität die durchschnittliche Anzahl der pro Benutzer gestarteten Anwendungen und halten Sie diese innerhalb derselben Empfehlung von 25.000 pro Zone ein.

Zusammenfassung

Während eines Ausfalls der Standortdatenbank unterstützt LHC eine Vielzahl von Ressourcen und Bedingungen, erfordert jedoch Planung und Berücksichtigung von CPU und Arbeitsspeicher beim Betrieb.

In mehreren Broker-Sites kann jeder Broker als Ausfallbroker ausgewählt werden, und daher müssen alle über genügend Ressourcen verfügen, um im Ausfallmodus fertig zu werden. Es wird keine Bewertung der Brokerressourcen durchgeführt. Daher ist es an einer Website mit Brokern mit unterschiedlichen Ressourcen möglich, dass der am wenigsten leistungsfähige Broker während eines Ausfalls ausgewählt wird.

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

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

Broker mit unzureichender CPU-Ressource können fehlgeschlagene Starts erleben.

Citrix empfiehlt, dass Sie Ihre Antivirenausschlüsse definieren. Weitere Informationen finden Sie im Tech Paper: Best Practices für Endpunktsicherheit, Virenschutz und Antimalware.

Zwei zusätzliche Kerne und 2 GB RAM sind ein guter Ausgangspunkt, um die Leistung im LHC-Ausfallmodus zu testen.

1 GB Speicherplatz reicht für die LocalDB-Datenbank aus.

Ein überlasteter Broker führt zu fehlgeschlagenen Verbindungen.