Überlegungen zu Skalierung und Größe für den lokalen Hostcache

Der lokale Hostcache im Citrix Virtual Apps and Desktops-Service ermöglicht bei einem Ausfall das fortgesetzte Verbindungsbrokering in einer Site. Ein Ausfall tritt auf, wenn die WAN-Verbindung zwischen Site und Verwaltungskonsole in einer Citrix Cloudumgebung fehlschlägt. Weitere Informationen finden Sie unter Lokaler Hostcache. Im Dezember 2017 testeten wir die Citrix Cloud Connector-Maschinenkonfiguration mit lokalem Hostcache und mindestens drei Cloud Connectors. Die Testergebnisse in diesem Artikel beziehen sich auf die im Dezember 2017 getesteten Höchstwerte. Die empfohlenen bewährten Methoden basieren auf diesen getesteten Höchstwerten.

Der lokale Hostcache unterstützt nur on-premises StoreFront an jedem Ressourcenstandort oder in jeder Zone. Das Feature verwendet nur einen Socket für Mehrkern-CPUs zur Connector-VM-Konfiguration. In diesem Szenario empfehlen wir eine Konfiguration mit 4 Kernen und 1 Socket.

Zusammenfassung

Alle Ergebnisse in dieser Zusammenfassung basieren auf den Erkenntnissen aus den im Folgenden beschriebenen Testumgebungen. Andere Systemkonfigurationen führen zu anderen Ergebnissen.

Wichtige Empfehlungen basierend auf den Testergebnissen:

  • Für Sites mit hoher Verfügbarkeit und maximal 5000 gehosteten Arbeitsstationen oder 500 Server-VDAs wird eine Konfiguration mit 3 dedizierten VMs für den Cloud Connector empfohlen. Jede Cloud Connector-VM benötigt 4 vCPUs mit 4 GB RAM. Dies ist eine Hochverfügbarkeitskonfiguration vom Typ N+1. Cloud Connectors werden in Hochverfügbarkeitsgruppen bereitgestellt. Cloud Connectors bieten keinen Lastausgleich. Da jede CPU eine begrenzte Anzahl von Verbindungen verarbeiten kann, ist die CPU der größte limitierende Faktor in Bezug auf die Anzahl der unterstützten Arbeitsstationen oder Server-VDAs.
  • Obwohl dieses Dokument primär Tests mit zwei Cloud Connectors behandelt, wird eine N+1-Gruppe mit drei Cloud Connectors empfohlen.
  • Es wurden Sitzungsstarttests durchgeführt, um den aktiven und inaktiven Ausfallmodus mit lokalem Hostcache zu vergleichen, nachdem eine neue Konfiguration synchronisiert und importiert wurde. Die Starttests umfassten Szenarien mit 5000, 20.000 und 1000 Sitzungsstarts und der entsprechenden Anzahl verfügbarer Arbeitsstationen.
    • 5000 Sitzungsstarts bei 5000 Arbeitsstation-VDAs
      • Bei den Tests wurden 2 Cloud Connector-VMs verwendet, jeweils mit 4 vCPUs und 4 GB RAM. Basierend auf den Empfehlungen für eine N+1-Konfiguration sollten Produktionsumgebungen 3 Cloud Connector-VMs umfassen, die diese Spezifikationen erfüllen.
      • Der lokale Hostcache verbrauchte zu Spitzenzeiten 91 % der CPU-Ressourcen, mit einem verfügbaren Arbeitsspeicher von durchschnittlich 563 MB.
      • Es dauerte rund 10 Minuten, bis alle VDAs nach dem Feststellen eines Ausfalls durch den Dienst für hohe Verfügbarkeit erneut bei diesem Dienst (der jetzt als Broker fungierte) registriert waren. Gemessen wurde die Zeit vom Auslösen des Ausfallmodus durch den Dienst für hohe Verfügbarkeit bis zum erneuten Brokering von Sitzungen durch den HA-Service.
    • 20.000 Sitzungsstarts bei 500 Server-VDAs
      • Bei den Tests wurden 2 Cloud Connector-VMs verwendet, jeweils mit 4 vCPUs und 4 GB RAM. Basierend auf den Empfehlungen für eine N+1-Konfiguration sollten Produktionsumgebungen 3 Cloud Connector-VMs umfassen, die diese Spezifikationen erfüllen.
      • Der lokale Hostcache verbrauchte zu Spitzenzeiten 90 % der CPU-Ressourcen, mit einem verfügbaren Arbeitsspeicher von durchschnittlich 471 MB.
      • Es dauerte rund 8 Minuten, bis alle VDAs nach dem Feststellen eines Ausfalls durch den Dienst für hohe Verfügbarkeit erneut bei diesem Dienst registriert waren. Gemessen wurde die Zeit vom Auslösen des Ausfallmodus durch den Dienst für hohe Verfügbarkeit bis zum erneuten Brokering von Sitzungen durch den HA-Service.
    • 1000 Sitzungsstarts bei 1000 Arbeitsstation-VDAs
      • Bei den Tests wurden 2 Cloud Connector-VMs verwendet, jeweils mit 2 vCPUs und 4 GB RAM. Basierend auf den Empfehlungen für eine N+1-Konfiguration sollten Produktionsumgebungen 3 Cloud Connector-VMs umfassen, die diese Spezifikationen erfüllen.
      • Der lokale Hostcache verbrauchte zu Spitzenzeiten 95 % der CPU-Ressourcen, mit einem verfügbaren Arbeitsspeicher von durchschnittlich 589 MB.
      • Es dauerte rund 7 Minuten, bis alle VDAs nach dem Feststellen eines Ausfalls durch den Dienst für hohe Verfügbarkeit erneut bei diesem Dienst (der jetzt als Broker fungierte) registriert waren. Gemessen wurde die Zeit vom Auslösen des Ausfallmodus durch den Dienst für hohe Verfügbarkeit bis zum erneuten Brokering von Sitzungen durch den HA-Service.

Umgebungsübersicht Die Verwaltung von Cloud Connector-Diensten erfolgt durch Citrix Cloud, während der Kunde die Maschinen verwaltet.

Testmethode

Gemessen wurde die Leistung der Umgebungskomponenten nach Hinzufügen von Last:

  • CPU
  • Speicher
  • Datenbanklast
  • Citrix Remote Broker Provider-Service
  • Citrix Dienst für hohe Verfügbarkeit

Erfasst wurden Leistungsdaten, Anmeldezeit oder beides. In bestimmten Fällen wurden firmeneigene Simulationstools von Citrix verwendet, um VDAs und Sitzungen zu simulieren. Diese Simulationstools beanspruchen Citrix Komponenten auf dieselbe Weise wie herkömmliche VDAs und Sitzungen, jedoch ohne Einsatz der für das Hosten echter Sitzungen und VDAs erforderlichen Ressourcen.

Der lokale Hostcache unterstützt einen gewählten Dienst für hohe Verfügbarkeit pro Zone (nicht pro Site). Wenn Sie beispielsweise fünf Zonen haben, wird in jeder Zone ein Connector als Broker ausgewählt. Der Citrix Config Sync-Dienst (CCS) ist für den Import der von Citrix verwalteten Sitekonfigurationsdatenbank verantwortlich. Da bei jeder Konfigurationssynchronisierung eine Datenbank erstellt wird, sind zunächst Erstkonfigurationen erforderlich, z. B. das Kompilieren gespeicherter Prozeduren beim ersten Verwenden der Datenbank. Alle Tests wurden nach einer Konfigurationssynchronisierung ausgeführt.

Sitzungsstarttests

Auf vom Kunden verwalteten StoreFront-Servern wurden 5000 und 20.000 Testsitzungen gestartet. Die Überwachungstools erfassten die StoreFront-Anmeldezeit, die Ressourcenenumeration und das Abrufen der ICA-Datei.

Citrix verwendet Simulationstools für Tests mit hohen Benutzerzahlen. Die firmeneigenen Simulationstools von Citrix ermöglichen es, Tests mit weniger Hardware auszuführen, als beim Einsatz echter Sitzungen dieser Größenordnung (5000 und 20.000 Sitzungen) erforderlich wäre. Bei diesen simulierten Sitzungen werden StoreFront-Anmeldung, Ressourcenenumeration und Abrufen der ICA-Datei normal ausgeführt, es werden jedoch keine aktiven Desktops gestartet. Stattdessen meldet das Simulationstool dem ICA-Stack, dass die Sitzung gestartet wurde, und die gesamte Kommunikation zwischen Brokeragent und Brokerdienst stimmt mit der einer tatsächlichen Sitzung überein. Die Leistungsmetriken der Citrix Cloud Connectors werden erfasst. Um zu bestimmen, wie die Umgebung auf Sitzungsstarts reagiert, wurden während der gesamten Testdauer kontinuierlich 25 Sitzungen gleichzeitig gestartet. Die Messungen zeigen daher die Ergebnisse eines Systems, das während des gesamten Tests unter Last stand.

Testergebnisse

Sitzungsstart

Die folgenden Tabellen vergleichen den Sitzungsstart im aktiven bzw. inaktiven Ausfallmodus mit lokalem Hostcache nach Synchronisierungsimport einer neuen Konfiguration. Jede Tabelle zeigt die Ergebnisse für die im Test gestartete Sitzungsanzahl.

5000 Arbeitsstation-VDA-Sitzungen

  Inaktiver Ausfallmodus mit lokalem Hostcache (Normalbetrieb) / Durchschnittszeit Aktiver Ausfallmodus mit lokalem Hostcache / Durchschnittszeit
Authentifizierung 193 ms 95 ms
Enumeration 697 ms 75 ms
Gesamtanmeldezeit 890 ms 170 ms
ICA-Dateiabruf 4191 ms 156 ms

20.000 Server-VDA-Sitzungen

  Inaktiver Ausfallmodus mit lokalem Hostcache (Normalbetrieb) / Durchschnittszeit Aktiver Ausfallmodus mit lokalem Hostcache / Durchschnittszeit
Authentifizierung 135 ms 112 ms
Enumeration 317 ms 91 ms
Gesamtanmeldezeit 452 ms 203 ms
ICA-Dateiabruf 762 ms 174 ms
  • Starttest für 5000 Arbeitsstation-VDA-Sitzungen
    • Zwischen Citrix Cloud Connectors und Citrix Delivery Controller trat eine Latenz von rund 30 ms auf, während der Ausfallmodus mit lokalem Hostcache inaktiv war.
    • Die Anmeldezeit zwischen aktivem bzw. inaktivem Ausfallmodus mit lokalem Hostcache unterschied sich um 720 ms, während StoreFront unter Last war.
    • Der größte Zeitunterschied mit 4 Sekunden zeigte sich beim Abrufen der ICA-Datei. Dies liegt vor allem daran, dass der Connector das Brokering durchführt, während der StoreFront-Datenverkehr normal über die Connectors zum Citrix Delivery Controller in Azure und zurück geleitet wird.
  • Starttest für 20.000 Server-VDA-Sitzungen
    • Die Anmeldezeit zwischen aktivem bzw. inaktivem Ausfallmodus mit lokalem Hostcache unterschied sich um 249 ms, während StoreFront unter Last war.
    • Der Unterschied beim Abrufen der ICA-Datei betrug rund 1 Sekunde.
  • Im Vergleich zum Start von 5000 Arbeitsstation-VDA-Sitzungen enthält der Test für 20.000 Sitzungsstarts nur 500 Server-VDAs. Dies führt zu weniger Abfragen vom Citrix Delivery Controller an die VDAs und damit zu kürzeren Antwortzeiten.

Mittlere CPU-Auslastung im Vergleich

Sitzungsstarttest   Mittlere CPU-Last (%) Max. CPU-Last (%)
5000 Arbeitsstation-VDA-Sitzungen Connector 1 8,3 38,2
  Connector 2 8,4 33,3
5000 Arbeitsstation-VDA-Sitzungen - aktiver Ausfallmodus mit lokalem Hostcache Connector 1 (gewählter Dienst für hohe Verfügbarkeit) 42 91
  Connector 2 0,8 5
20.000 Server-VDA-Sitzungen Connector 1 23 62
  Connector 2 23 55
20.000 Server-VDA-Sitzungen - aktiver Ausfallmodus mit lokalem Hostcache Connector 1 (gewählter Dienst für hohe Verfügbarkeit) 57 90
  Connector 2 0,8 6,6
  • Die Tabelle zeigt die CPU-Auslastung der Citrix Cloud Connectors bei Tests mit 5000 Arbeitsstation-VDA- und 20.000 Server-VDA-Sitzungsstarts, wenn der Ausfallmodus mit lokalem Hostcache aktiv bzw. inaktiv ist.
  • Alle Cloud Connectors sind mit 4 vCPUs und 4 GB RAM konfiguriert.
  • Die maximale CPU-Last der als Dienst für hohe Verfügbarkeit gewählten Maschinen lag bei 91 % bzw. 90 % der CPU-Gesamtlast. Der nicht gewählte Dienst für hohe Verfügbarkeit zeigt hingegen eine nur geringe Nutzung, kann jedoch aktiviert werden, wenn der gewählte Dienst für hohe Verfügbarkeit fehlschlägt. Es ist daher wichtig, dass für die Connectors identische Spezifikationen gelten.

Auslastung des verfügbaren Speichers

Sitzungsstarttest   Mittlerer verfügbarer Speicher (Arbeitsbereich in MB) Maximal verfügbarer Speicher (Arbeitsbereich in MB)
5000 Arbeitsstation-VDA-Sitzungen Connector 1 636 657
  Connector 2 786 801
5000 Arbeitsstation-VDA-Sitzungen - aktiver Ausfallmodus mit lokalem Hostcache Connector 1 (gewählter Dienst für hohe Verfügbarkeit) 563 618
  Connector 2 912 918
20.000 Server-VDA-Sitzungen Connector 1 1030 1195
  Connector 2 1178 1329
20.000 Server-VDA-Sitzungen - aktiver Ausfallmodus mit lokalem Hostcache Connector 1 (gewählter Dienst für hohe Verfügbarkeit) 471 687
  Connector 2 1210 1227
  • Die Tabelle zeigt die Auslastung des verfügbaren Speichers bei Tests mit 5000 Arbeitsstation-VDA- und 20.000 Server-VDA-Sitzungsstarts, wenn der Ausfallmodus mit lokalem Hostcache aktiv bzw. inaktiv ist.
  • Die Anzahl der Sitzungen verringert den verfügbaren Speicherplatz.
  • Bei 20.000 Server-VDA-Sitzungen steigt der Speicherverbrauch im aktivem Ausfallmodus mit lokalem Hostcache um 54,35 % (559 MB), hauptsächlich aufgrund des Speicherverbrauchs des SQL-Servers.

CPU-Auslastung der Cloud Connectors nach Komponente

Sitzungsstarttest Komponente Mittlere CPU-Last (%) Max. CPU-Last (%)
5000 Arbeitsstation-VDA-Sitzungen Connector 1 LSASS 2,4 10,7
  Connector 1 XaXdCloudProxy 3,5 18,5
  Connector 2 LSASS 2,5 12,9
  Connector 2 XaXdCloudProxy 3,5 21,2
5000 Arbeitsstation-VDA-Sitzungen - aktiver Ausfallmodus mit lokalem Hostcache Connector 1 (gewählter Dienst für hohe Verfügbarkeit) LSASS 12,9 29,5
  Connector 1 (gewählter Dienst für hohe Verfügbarkeit) HighAvailabilityService 14,7 49,7
20.000 Server-VDA-Sitzungen Connector 1 LSASS 7 12,2
  Connector 1 XaXdCloudProxy 8,7 15,5
  Connector 2 LSASS 7 12,5
  Connector 2 XaXdCloudProxy 9 15,7
20.000 Sitzungen - aktiver Ausfallmodus mit lokalem Hostcache Connector 1 (gewählter Dienst für hohe Verfügbarkeit) LSASS 4,3 17,2
  Connector 1 (gewählter Dienst für hohe Verfügbarkeit) Dienst für hohe Verfügbarkeit 4,5 18,2
  • Die obige Tabelle zeigt für die durchgeführten Starttests mit 5000 Arbeitsstation-VDA- und 20.000 Server-VDA-Sitzungen, welche Prozesse die meisten CPU-Ressourcen beanspruchen, wenn der Ausfallmodus mit lokalem Hostcache aktiv bzw. inaktiv ist.
  • Der Citrix Remote Broker Provider-Service (XaXdCloudProxy) hat den höchsten CPU-Verbrauch, wenn der Ausfallmodus mit lokalem Hostcache inaktiv ist.
  • Der LSASS-Service (Subsystemdienst für die lokale Sicherheitsautorität) verbraucht Rechenleistung bei der Sitzungsanmeldung. Alle von Citrix verwalteten Services müssen zur Authentifizierung über die Citrix Cloud Connectors auf das vom Kunden verwaltete Active Directory zugreifen.

  • Das Brokering der Sitzungen erfolgt über den Citrix Dienst für hohe Verfügbarkeit, was im aktiven Ausfallmodus mit lokalem Hostcache die CPU-Auslastung erhöht. Beim Start von 5000 Arbeitsstation-VDA-Sitzungen erreichte die CPU-Auslastung einen Spitzenwert von 49,7 %, während der Wert beim Start von 20.000 Server-VDA-Sitzungen (500 VDAs) nur bei 18,25 % lag. Der Unterschied ist auf die Anzahl der VDAs zurückzuführen.
  • Connector 2 lieferte keine aussagekräftigen Metriken, da es sich nicht um den gewählten Dienst für hohe Verfügbarkeit handelte.

VDA-Neuregistrierungszeit beim Wechsel zum lokalen Hostcache

Beim Ausfall eines Delivery Controllers müssen sich die 5000 Arbeitsstation-VDAs beim gewählten Broker mit lokalem Hostcache neu registrieren. Diese Neuregistrierung dauerte rund 10 Minuten. Die Neuregistrierung der 500 Server-VDAs dauerte rund 8 Minuten.

VDA-Anzahl Neuregistrierungszeit
5000 Arbeitsstation-VDAs ca. 10 Minuten
500 Server-VDAs ca. 8 Minuten

Ausfallzeiten

Ausfallereignis VDA-Anzahl Zeit
Beginn des Ausfallmodus   10 Minuten
Neuregistrierung beim gewählten Dienst für hohe Verfügbarkeit 500 ca. 8 Minuten
  5000 ca. 10 Minuten
Ende des Ausfallmodus   10 Minuten
Neuregistrierung beim Citrix Delivery Controller 500 ca. 5,5 Minuten
  5000 ca. 1,5 Minuten
  • Aufgrund der erforderlichen Citrix Delivery Controller-Diagnosetests dauert der Ausfallmodus insgesamt 20 Minuten – jeweils 10 Minuten für Beginn und Ende. Die für die Neuregistrierung der VDAs erforderliche Zeit erhöht die Gesamtausfallzeit.
  • Bei wiederholten Netzwerkausfällen werden durch das Erzwingen eines Ausfalls bis zum Beheben des Netzwerkproblems fortlaufende Wechsel zwischen Normalbetrieb und Ausfallmodus vermieden.

Metriken für Datenbank und Dienst für hohe Verfügbarkeit mit lokalem Hostcache

Sitzungsstarttest Mittelwert für Datenbanktransaktionen/Sekunde (Dienst für hohe Verfügbarkeit) Spitzenwert für Datenbanktransaktionen/Sekunde (Dienst für hohe Verfügbarkeit)
5000 Arbeitsstation-VDA-Sitzungen 436 1344
20.000 Server-VDA-Sitzungen 590 2061

Die obige Tabelle zeigt die Anzahl der Datenbanktransaktionen pro Sekunde auf dem gewählten Dienst für hohe Verfügbarkeit.

CPU-Auslastung von StoreFront im Vergleich

Sitzungsstarttest Mittlere CPU-Last (%) Max. CPU-Last (%)
5000 Arbeitsstation-VDA-Sitzungen 4,5 32,4
5000 Server-VDA-Sitzungen - aktiver Ausfallmodus mit lokalem Hostcache 13,8 32,6
20.000 Server-VDA-Sitzungen 11,4 22,1
20.000 Server-VDA-Sitzungen - Ausfallmodus mit lokalem Hostcache 18,6 33,2
  • Die obige Tabelle zeigt die CPU-Auslastung von StoreFront bei Tests mit 5000 Arbeitsstation-VDA- und 20.000 Server-VDA-Sitzungsstarts, wenn der Ausfallmodus mit lokalem Hostcache aktiv bzw. inaktiv ist.
  • Die StoreFront-Maschine besitzt die folgenden Spezifikationen: Windows 2012 R2, 8 vCPUs (2 Sockets mit jeweils 4 Kernen), 8 GB RAM
  • Im aktiven Ausfallmodus mit lokalem Hostcache steigt die mittlere CPU-Last bei Tests mit 5000-Arbeitsstation-VDA-Sitzungsstarts um etwa 9 % und bei Tests mit 20.000 Server-VDA-Sitzungsstarts um etwa 7 %. Dieser Anstieg ist hauptsächlich darauf zurückzuführen, dass der IIS-Worker mehr Anfragen verarbeitet, wenn der Ausfallmodus mit lokalem Hostcache aktiv ist. Die CPU-Auslastung ist höher, da StoreFront Sitzungsstarts schneller verarbeitet, als wenn der Ausfallmodus inaktiv ist.

Nutzung des verfügbaren StoreFront-Speichers im Vergleich

Sitzungsstarttest Mittlerer verfügbarer Speicher (Arbeitsbereich in MB) Maximal verfügbarer Speicher (Arbeitsbereich in MB)
5000 Arbeitsstation-VDA-Sitzungen 5731 6821
5000 Arbeitsstation-VDA-Sitzungen - Ausfallmodus mit lokalem Hostcache 5345 5420
20.000 Server-VDA-Sitzungen 4671 4924
20.000 Server-VDA-Sitzungen - aktiver Ausfallmodus mit lokalem Hostcache 4730 5027
  • Die obige Tabelle zeigt die Nutzung des verfügbaren StoreFront-Speichers bei Tests mit 5000 Arbeitsstation-VDA- und 20.000 Server-VDA-Sitzungsstarts, wenn der Ausfallmodus mit lokalem Hostcache aktiv bzw. inaktiv ist.
  • Im aktiven Modus mit lokalem Hostcache steigt die Speicherauslastung beim Test mit 5000 Arbeitsstation-VDA-Sitzungsstarts um 6,73 %.

In der folgenden Tabelle werden aktiver und inaktiver Ausfallmodus nach Synchronisierungsimport einer neuen Konfiguration verglichen. Es werden 1000 Sitzungen für 1000 Arbeitsstation-VDAs mit lokalem Hostcache gestartet und Citrix Cloud Connectors mit 2 vCPU-VMs verwendet.

Sitzungsstart im Vergleich

  Inaktiver Ausfallmodus mit lokalem Hostcache (Normalbetrieb) Aktiver Ausfallmodus mit lokalem Hostcache
Authentifizierung 359 ms 89 ms
Enumeration 436 ms 180 ms
Anmeldezeit insgesamt 795 ms 269 ms
ICA-Dateiabruf 804 ms 549 ms
  • Wenn StoreFront unter Last ist, unterscheiden sich die Anmeldezeiten bei aktivem und bei inaktivem Ausfallmodus mit lokalem Hostcache um 526 ms.
  • Die für das Abrufen der ICA-Datei erforderliche Zeit liegt bei aktivem und inaktivem Ausfallmodus mit lokalem Hostcache um 255 ms auseinander. Die Differenz steigt mit der Anzahl an Sitzungen.

Mittlere CPU-Auslastung im Vergleich

Mittlere CPU-Auslastung im Vergleich

Der Spitzenwert für den gewählten Dienst für hohe Verfügbarkeit lag bei 95 % der CPU-Gesamtlast, was darauf verweist, dass ein VDA mit 1000 Arbeitsstationen eine optimale Konfiguration für eine Connector-VM mit 2 vCPUs ist.

Mittlere Speichernutzung im Vergleich

Mittlere Speichernutzung im Vergleich

Das obige Diagramm vergleicht den Speicherverbrauch pro Citrix Cloud Connector beim Start von 1000 Arbeitsstation-VDA-Sitzungen, wenn der Ausfallmodus mit lokalem Hostcache aktiv bzw. inaktiv ist. Der Ausfallmodus mit lokalem Hostcache verursacht keinen signifikanten Unterschied bei der Speichernutzung.

CPU-Auslastung der Cloud Connectors nach Komponente im Vergleich

CPU-Auslastung der Cloud Connector nach Komponente im Vergleich

Das obige Diagramm zeigt an, welche Prozesse bei inaktivem Ausfallmodus mit lokalem Hostcache die meisten CPU-Ressourcen verbrauchen.

CPU-Ressourcen

  • Das obige Diagramm zeigt an, welche Prozesse bei aktivem Ausfallmodus mit lokalem Hostcache die meisten CPU-Ressourcen verbrauchen.
  • Connector 2 ergab keine aussagekräftigen Metriken.

VDA-Neuregistrierungszeit beim Wechsel zum lokalen Hostcache

Beim Ausfall eines Delivery Controllers müssen sich die 1000 Arbeitsstation-VDAs beim gewählten Broker mit lokalem Hostcache neu registrieren. Die Neuregistrierung dauerte rund 7 Minuten.

Metriken für Datenbank und Dienst für hohe Verfügbarkeit mit lokalem Hostcache

Metriken für Datenbank und Dienst für hohe Verfügbarkeit

Das obige Diagramm zeigt die Anzahl der Datenbanktransaktionen pro Sekunde auf dem gewählten Dienst für hohe Verfügbarkeit.

Auswirkung ansteigender Zonenzahlen auf die Datenbankimportzeit

Die Testumgebung wurde um eine zusätzliche Zone (mit zwei Connectors) erweitert, um die Auswirkungen dieser Änderung zu untersuchen. Die erste Zone umfasst 5500 eindeutige Objekte (2 Kataloge). Die sekundäre Zone ist ein Spiegel der ersten Zone und umfasst insgesamt 11.000 eindeutige Objekte. Beachten Sie, dass das lokale Hostcache-Feature nur für Zonen mit maximal 10.000 Objekten empfohlen wird. Vor dem Hinzufügen der sekundären Zone betrug die Datenbankimportzeit auf den Connectors ca. 4 Minuten und 20 Sekunden. Nach dem Hinzufügen der sekundären Zone und Speichern von 11.000 Objekten erhöhte sich die Importzeit um rund 30 Sekunden auf ca. 4 Minuten und 50 Sekunden. Das Hinzufügen weiterer Kataloge beeinflusste die Importzeit nur geringfügig. Die größten Einflussfaktoren, die zu einer Leistungsminderung und zu längeren Importzeiten führten, basieren auf der Anzahl der zugewiesenen Maschinen, Benutzer und Remote-PCs. Zusätzlich wurden 5500 Objekte auf zwei Zonen aufgeteilt. Dabei blieb die Importzeit gleich.

Zonenanzahl Gesamtanzahl der Objekte Importzeit
1 5500 4 Minuten 20 Sekunden
2 11.000 4 Minuten 50 Sekunden
2 5500 4 Minuten 20 Sekunden

Hinweise zur Connector-Dimensionierung

Für eine optimale Leistung empfehlen wir die folgenden Citrix Cloud Connector-Konfigurationen bei aktiviertem Modus mit lokalem Hostcache.

Empfehlung 1: Unterstützung von 1000 Arbeitsstation-VDAs bei Verwendung des lokalen Hostcache mit Citrix Cloud Connector

  • 2 Windows 2012 R2-VMs, jeweils mit 2 vCPUs (1 Socket, 2 Kerne) und 4 GB RAM
  • Diese Konfiguration basiert auf den Testergebnissen für Citrix Cloud Connectors, mit einer CPU-Auslastung von maximal 95 % der CPU-Gesamtlast und einem mittleren verfügbaren Speicher von 589 MB bei aktivem Modus mit lokalem Hostcache.

Empfehlung 2: Unterstützung von 5000 Arbeitsstation-VDAs oder 500-Server-VDAs bei Verwendung des lokalen Hostcache mit Citrix Cloud Connector

  • 2 Windows 2012 R2-VMs, jeweils mit 4 vCPUs (1 Socket, 4 Kerne) und 4 GB RAM
  • Diese Konfiguration basiert auf
    • 5000 Arbeitsstation-VDA-Sitzungen, gestartet im aktivem Modus mit lokalem Hostcache
      • Maximal 91 % der CPU-Gesamtlast
      • 563 MB mittlerer verfügbarer Speicher
    • 20.000 Server-VDA-Sitzungen, gestartet im aktivem Modus mit lokalem Hostcache
      • Maximal 90 % der CPU-Gesamtlast
      • 471 MB mittlerer verfügbarer Speicher

Weitere Informationen zur allgemeinen Skalierbarkeit und Dimensionierung finden Sie unter Überlegungen zu Skalierung und Größe für Cloud Connectors.

Testumgebung

Die Testumgebung umfasste intern entwickelte, proprietäre Testtools sowie VMs, die nach den Spezifikationen in den folgenden Abschnitten konfiguriert wurden.

Verwendete Tools

Wir verwendeten ein internes Testtool, um Leistungsdaten und Metriken der getesteten Maschinen zu erfassen und um die Sitzungen zu starten. Damit können Benutzersitzungen in der Citrix Virtual Apps and Desktops-Umgebung gemeinsam gestartet werden. Außerdem bietet das Testtool die Möglichkeit einer zentralen Aufzeichnung von Reaktionszeiten und Leistungsmetriken. Im Wesentlichen dient das Testtool zum Koordinieren der Tests und zum Erfassen der Ergebnisse.

Testkonfiguration – Citrix Virtual Apps and Desktops-Service

Folgende Maschinen- und Betriebssystemspezifikationen wurden beim Test des Citrix Virtual Apps and Desktops-Dienstes verwendet.

  • Cloud Connectors:
    • 2 Windows 2012 R2-VMs, jeweils mit 4 vCPUs (1 Socket, 4 Kerne) und 4 GB RAM
    • 2 Windows 2012 R2-VMs, jeweils mit 2 vCPUs (1 Socket, 2 Kerne) und 4 GB RAM
  • StoreFront (vom Kunden verwaltet): Windows 2012 R2, 8 vCPUs (2 Sockets mit je 4 Kernen) und 8 GB RAM
  • Hypervisor: Citrix XenServer 7.0 + Updates, 5x HP Blade BL 460C Gen 9, 2x Intel E5-2620 CPU, 256 GB RAM
  • Hypervisorspeicher: NFS-Freigabe mit 2 TB auf NetApp 3250
  • VDA: Windows 2012 R2

Datensammlung

Es wurden für jeden Test folgende Metriken erfasst:

  • mittlere CPU-Gesamtlast, Arbeitsspeicher, Lastanstieg pro Komponente (Cloud-Prozesse)
  • VDA-Neuregistrierungszeit beim Wechsel zum gewählten Dienst für hohe Verfügbarkeit mit lokalem Hostcache
  • Metriken für Datenbank und Dienst für hohe Verfügbarkeit bei aktivem Ausfallmodus mit lokalem Hostcache
  • Sitzungsstartvergleich und mittlere Zeitangaben
    • Authentifizierung
    • Enumeration
    • Abrufen der ICA-Datei
  • Auswirkung zusätzlicher Zonen auf die Datenbanksynchronisierungszeiten
    • Erforderliche Synchronisierungszeit nach einer Konfigurationsänderung

Überlegungen zu Skalierung und Größe für den lokalen Hostcache