Überlegungen zur Skalierung und Größe für den lokalen Hostcache
Der lokale Hostcache in Citrix DaaS (ehemals 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 wieder 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 wieder 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 wieder 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.
- 5000 Sitzungsstarts bei 5000 Arbeitsstation-VDAs
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 - 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 |
| Gesamtanmeldezeit | 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
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
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 Connector nach Komponente im Vergleich
Das obige Diagramm zeigt an, welche Prozesse bei inaktivem Ausfallmodus mit lokalem Hostcache die meisten CPU-Ressourcen verbrauchen.
- 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
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
- 5000 Arbeitsstation-VDA-Sitzungen, gestartet im aktivem Modus mit lokalem Hostcache
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 DaaS
Folgende Maschinen- und Betriebssystemspezifikationen wurden beim Test von Citrix DaaS 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 für:
- Authentifizierung
- Enumeration
- Abrufen der ICA-Datei
- Auswirkung zusätzlicher Zonen auf die Datenbanksynchronisierungszeiten
- Erforderliche Synchronisierungszeit nach einer Konfigurationsänderung