Überlegungen zu Größe und Skalierung für Cloud Connectors
Bei der Bewertung von Citrix DaaS hinsichtlich Größe und Skalierbarkeit müssen alle Komponenten berücksichtigt werden. Recherchieren und testen Sie die Konfiguration von Citrix Cloud™ Connectors und StoreFront für Ihre spezifischen Anforderungen. Die Bereitstellung unzureichender Ressourcen für Größe und Skalierbarkeit wirkt sich negativ auf die Leistung Ihrer Bereitstellung aus.
Hinweis:
- Diese Empfehlungen gelten zusätzlich zu Citrix DaaS auch für Citrix DaaS Standard für Azure.
- Die in diesem Artikel enthaltenen Tests und Empfehlungen sind Richtlinien, die Ihnen den Einstieg in Ihre Tests erleichtern sollen. Wir empfehlen Ihnen, die Tests in Ihrer Umgebung durchzuführen, um die korrekte Dimensionierung des Connectors zu validieren.
- Informationen zu Größen- und Skalierungsüberlegungen für den HDX-Proxy finden Sie unter Überlegungen zu Größe und Skalierung des Cloud Connectors für den HDX-Proxy.
-
Dieser Artikel enthält Details zu den getesteten maximalen Kapazitäten und Best-Practice-Empfehlungen für die Konfiguration von Cloud Connector-Maschinen. Die Tests wurden an Bereitstellungen durchgeführt, die mit StoreFront™ und Local Host Cache (LHC) konfiguriert waren.
-
Die bereitgestellten Informationen gelten für Bereitstellungen, bei denen jeder Ressourcenstandort sowohl VDI-Workloads als auch RDS-Workloads enthält.
Der Cloud Connector verbindet Ihre Workloads auf folgende Weisen mit Citrix DaaS™:
- Stellt einen Proxy für die Kommunikation zwischen Ihren VDAs und Citrix DaaS bereit.
- Stellt einen Proxy für die Kommunikation zwischen Citrix DaaS und Ihrem Active Directory (AD) sowie Hypervisoren bereit.
-
In Bereitstellungen, die StoreFront-Server umfassen, dient der Cloud Connector bei Cloud-Ausfällen als temporärer Session Broker, der Benutzern weiterhin Zugriff auf Ressourcen bietet.
- Es ist wichtig, dass Ihre Cloud Connectors entsprechend Ihren spezifischen Anforderungen dimensioniert und konfiguriert sind. Obwohl Tests mit zwei Cloud Connectors durchgeführt wurden, ist während Cloud Connector-Upgrades nur ein Cloud Connector verfügbar. Um eine hohe Verfügbarkeit während Cloud Connector-Upgrades zu gewährleisten, haben sich einige Kunden für die Bereitstellung von drei Cloud Connectors entschieden.
Jeder Satz von Cloud Connectors wird einem Ressourcenstandort (in Studio auch als Zone bezeichnet) zugewiesen. Ein Ressourcenstandort ist eine logische Trennung, die festlegt, welche Ressourcen mit diesem Satz von Cloud Connectors kommunizieren. Mindestens ein Ressourcenstandort pro Domäne ist erforderlich, um mit dem Active Directory (AD) zu kommunizieren.
Jeder Maschinenkatalog und jede Hosting-Verbindung wird einem Ressourcenstandort zugewiesen.
Bei Bereitstellungen mit mehr als einem Ressourcenstandort weisen Sie Maschinenkataloge und VDAs den Ressourcenstandorten zu, um die Fähigkeit von LHC zu optimieren, Verbindungen während Ausfällen zu vermitteln. Weitere Informationen zum Erstellen und Verwalten von Ressourcenstandorten finden Sie unter Verbindung zu Citrix Cloud herstellen. Für optimale Leistung konfigurieren Sie Ihre Cloud Connectors auf Verbindungen mit geringer Latenz zu VDAs, AD-Servern und Hypervisoren.
Empfohlene Prozessoren und Speicher
Für eine Leistung, die der in diesen Tests beobachteten ähnelt, verwenden Sie moderne Prozessoren, die SHA-Erweiterungen unterstützen. SHA-Erweiterungen reduzieren die kryptografische Last auf der CPU. Empfohlene Prozessoren umfassen:
- Advanced Micro Devices (AMD) Zen und neuere Prozessoren
- Intel Ice Lake und neuere Prozessoren
Die empfohlenen Prozessoren arbeiten effizient. Sie können ältere Prozessoren verwenden, dies kann jedoch zu einer höheren CPU-Auslastung führen. Wir empfehlen, die Anzahl Ihrer vCPUs zu erhöhen, um dieses Verhalten auszugleichen.
Die in diesem Artikel beschriebenen Tests wurden mit AMD EPYC- und Intel Cascade Lake-Prozessoren durchgeführt.
Cloud Connectors haben eine hohe kryptografische Last, während sie mit der Cloud kommunizieren. Cloud Connectors, die Prozessoren mit SHA-Erweiterungen verwenden, erfahren eine geringere Last auf ihrer CPU, was sich in einer geringeren CPU-Auslastung durch den Windows Local Security Authority Subsystem Service (LSASS) äußert.
Citrix empfiehlt die Verwendung von modernem Speicher mit ausreichenden I/O-Vorgängen pro Sekunde (IOPS), insbesondere für Bereitstellungen, die LHC verwenden. Solid-State-Laufwerke (SSDs) werden empfohlen, aber Premium-Cloud-Speicher-Tiers sind nicht erforderlich. Höhere IOPS sind für LHC-Szenarien erforderlich, bei denen der Cloud Connector eine kleine Kopie der Datenbank ausführt. Diese Datenbank wird regelmäßig mit Änderungen der Site-Konfiguration aktualisiert und bietet Vermittlungsfunktionen für den Ressourcenstandort in Zeiten von Citrix Cloud-Ausfällen.
Empfohlene Compute-Konfiguration für Local Host Cache
Local Host Cache (LHC) bietet Hochverfügbarkeit, indem er ermöglicht, dass Verbindungsvermittlungsvorgänge in einer Bereitstellung fortgesetzt werden, wenn ein Cloud Connector nicht mit Citrix Cloud kommunizieren kann.
Cloud Connectors führen Microsoft SQL Express Server LocalDB aus, das automatisch installiert wird, wenn Sie den Cloud Connector installieren. Die CPU-Konfiguration des Cloud Connectors, insbesondere die Anzahl der für SQL Express Server LocalDB verfügbaren Kerne, wirkt sich direkt auf die LHC-Leistung aus. Die Anzahl der für SQL Server Express Server LocalDB verfügbaren CPU-Kerne beeinflusst die LHC-Leistung sogar noch stärker als die Speicherzuweisung. Dieser CPU-Overhead wird nur im LHC-Modus beobachtet, wenn Citrix DaaS nicht erreichbar ist und der LHC-Broker aktiv ist. Für jede Bereitstellung, die LHC verwendet, empfiehlt Citrix vier Kerne pro Sockel, mit einem Minimum von vier CPU-Kernen pro Cloud Connector. Informationen zur Konfiguration von Compute-Ressourcen für SQL Express Server LocalDB finden Sie unter Compute-Kapazitätsgrenzen nach SQL Server-Edition.
- Wenn die für den SQL Express Server LocalDB verfügbaren Computeressourcen falsch konfiguriert sind, können die Konfigurationssynchronisierungszeiten verlängert und die Leistung während Ausfällen reduziert werden. In einigen virtualisierten Umgebungen kann die Rechenkapazität von der Anzahl der logischen Prozessoren und nicht von den CPU-Kernen abhängen.
Zusammenfassung der Testergebnisse
Alle Ergebnisse in dieser Zusammenfassung basieren auf den Erkenntnissen aus einer Testumgebung, wie sie in den detaillierten Abschnitten dieses Artikels konfiguriert ist. Die hier gezeigten Ergebnisse beziehen sich auf einen einzelnen Ressourcenstandort. Unterschiedliche Systemkonfigurationen können zu unterschiedlichen Ergebnissen führen.
- Diese Abbildung bietet einen grafischen Überblick über die getestete Konfiguration.
-
Die folgende Tabelle zeigt die empfohlenen Mindestkonfigurationen für CPU und Arbeitsspeicher des Cloud Connectors für Sites unterschiedlicher Größe. Die Testergebnisse mit diesen Konfigurationen sind unten aufgeführt. Weitere Informationen zu den Grenzwerten für Ressourcenstandorte finden Sie unter Grenzwerte.
-
Mittel Groß Maximal - | — | — | — | — |
-
Connectors für HA 2 2 3 -
VDAs Bis zu 1000 1001 - 5000 5001 - 10.000 -
Sitzungen Bis zu 2500 Bis zu 10.000 Bis zu 25.000 -
Hosting-Verbindungen Bis zu 20 Bis zu 40 Bis zu 40 -
CPUs für Cloud Connectors 4vCPU 4vCPU 8vCPU -
Arbeitsspeicher für Cloud Connectors 6 GB 8 GB 10 GB
Hinweis:
Wenn Ihre Bereitstellung 5000 VDAs überschreitet, müssen Sie drei Cloud Connectors für Hochverfügbarkeit und Skalierbarkeit verwenden.
Testmethodik
Es wurden Tests durchgeführt, um Last hinzuzufügen und die Leistung der Umgebungskomponenten zu messen. Die Komponenten wurden durch das Sammeln von Leistungsdaten und Verfahrenszeiten, wie Anmeldezeit und Registrierungszeit, überwacht. Manchmal werden proprietäre Citrix-Simulationstools verwendet, um VDAs und Sitzungen zu simulieren. Diese Tools sind darauf ausgelegt, Citrix-Komponenten auf die gleiche Weise zu beanspruchen wie herkömmliche VDAs und Sitzungen, jedoch ohne die gleichen Ressourcenanforderungen für das Hosten realer Sitzungen und VDAs. Tests wurden sowohl im Cloud-Brokering- als auch im LHC-Modus für Szenarien mit Citrix StoreFront durchgeführt.
Empfehlungen zur Dimensionierung des Cloud Connectors in diesem Artikel basieren auf Daten, die aus diesen Tests gesammelt wurden.
Die folgenden Tests wurden durchgeführt:
- Anmelde-/Start-Storm für Sitzungen: ein Test, der Anmeldeperioden mit hohem Volumen simuliert.
- VDA-Registrierungs-Storm: ein Test, der VDA-Registrierungsperioden mit hohem Volumen simuliert. Zum Beispiel nach einem Upgrade-Zyklus oder beim Übergang zwischen Cloud-Brokering und Local Host Cache-Modus.
- VDA-Power-Action-Storm: ein Test, der VDA-Power-Actions mit hohem Volumen simuliert.
Testszenarien und -bedingungen
Diese Tests wurden mit konfiguriertem LHC durchgeführt. Weitere Informationen zur Verwendung von LHC finden Sie im Artikel Local Host Cache. LHC erfordert einen lokalen StoreFront-Server. Detaillierte Informationen zu StoreFront finden Sie in der StoreFront-Produktdokumentation.
Empfehlungen für StoreFront-Konfigurationen:
- Wenn Sie mehrere Ressourcenstandorte mit einem einzelnen StoreFront-Server oder einer Servergruppe haben, aktivieren Sie die erweiterte Integritätsprüfungsoption für den StoreFront-Store. Siehe StoreFront-Anforderung im Artikel Local Host Cache.
- Für höhere Sitzungsstartraten verwenden Sie eine StoreFront-Servergruppe. Siehe Servergruppen konfigurieren in der StoreFront-Produktdokumentation.
Testbedingungen:
- CPU- und Arbeitsspeicheranforderungen gelten nur für das Basis-Betriebssystem und Citrix-Dienste. Drittanbieter-Apps und -Dienste können zusätzliche Ressourcen erfordern.
- VDAs sind alle virtuellen oder physischen Maschinen, auf denen der Citrix Virtual Delivery Agent ausgeführt wird.
- Tests werden nur mit Windows-VDAs durchgeführt.
- Alle getesteten VDAs wurden mit Citrix DaaS energieverwaltet.
- Sitzungen wurden mit einer konstanten Rate von 1.000 pro Minute gestartet.
- Es wurden Workloads von 1.000 bis 10.000 VDI- und 500–10.000 RDS-Servern mit 1.000–25.000 Sitzungen getestet.
- RDS-Sitzungen wurden bis zu 25.000 pro Ressourcenstandort getestet.
- Tests wurden mit zwei Cloud Connectors sowohl im Normalbetrieb als auch während eines Ausfalls durchgeführt. Citrix empfiehlt die Verwendung von mindestens zwei Cloud Connectors für Hochverfügbarkeit und drei Cloud Connectors für maximale und große Ressourcenstandorte. Im Ausfallmodus wird nur einer der Cloud Connectors für VDA-Registrierungen und das Brokering verwendet. Obwohl Tests mit zwei Cloud Connectors durchgeführt wurden, ist während Upgrades nur ein Cloud Connector verfügbar. Um Hochverfügbarkeit während Upgrades zu gewährleisten, haben sich einige Kunden dafür entschieden, drei Cloud Connectors zu betreiben.
- Tests wurden mit dem Cloud Connector durchgeführt, der mit Intel Cascade Lake Prozessoren konfiguriert war.
- Sitzungen wurden über einen einzelnen Citrix StoreFront-Server gestartet.
-
LHC-Ausfallsitzungsstarttests wurden durchgeführt, nachdem sich die Maschinen neu registriert hatten.
-
Die Anzahl der RDS-Sitzungen ist eine Empfehlung und keine Begrenzung. Testen Sie Ihr eigenes RDS-Sitzungslimit in Ihrer Umgebung.
-
Hinweis:
-
-
-
Die Sitzungsanzahl und die Startrate sind für RDS wichtiger als die VDA-Anzahl.
-
Mittlere Workloads
- Diese Workloads wurden mit 4 vCPUs und 6 GB Arbeitsspeicher getestet.
-
Test-Workloads Site-Bedingung VDA-Registrierungszeit CPU- und Arbeitsspeichernutzung bei Registrierung Starttestdauer CPU- und Arbeitsspeichernutzung beim Sitzungsstart Startrate - | — | — | — | — | — | — | — |
-
1000 VDI Online 5 Minuten CPU maximal = 36 %, CPU durchschnittlich = 33 %, Arbeitsspeicher maximal = 5,3 GB 2 Minuten CPU maximal = 29 %, CPU durchschnittlich = 27 %, Arbeitsspeicher maximal = 3,7 GB 500 pro Minute 1000 VDI Ausfall 4 Minuten CPU maximal = 11 %, CPU durchschnittlich = 10 %, Arbeitsspeicher maximal = 4,5 GB 2 Minuten CPU maximal = 42 %, CPU durchschnittlich = 28 %, Arbeitsspeicher maximal = 4,0 GB 500 pro Minute
-
250 RDS, 5000 Sitzungen Online 3 Minuten CPU maximal = 14 %, CPU durchschnittlich = 4 %, Arbeitsspeicher maximal = 3,5 GB 9 Minuten CPU maximal = 46 %, CPU durchschnittlich = 21 %, Arbeitsspeicher maximal = 3,7 GB 555 pro Minute -
250 RDS, 5000 Sitzungen Ausfall 3 Minuten CPU maximal = 15 %, CPU durchschnittlich = 5 %, Arbeitsspeicher maximal = 3,7 GB 9 Minuten CPU maximal = 51 %, CPU durchschnittlich = 32 %, Arbeitsspeicher maximal = 4,2 GB 555 pro Minute
Große Workloads
Diese Workloads wurden mit 4 vCPUs und 8 GB Arbeitsspeicher getestet.
| Test-Workloads | Site-Bedingung | VDA-Registrierungszeit | CPU- und Arbeitsspeichernutzung bei Registrierung | Starttestdauer | CPU- und Arbeitsspeichernutzung beim Sitzungsstart | Startrate |
|---|---|---|---|---|---|---|
| 5000 VDI | Online | 3–4 Minuten | CPU maximal = 45 %, CPU durchschnittlich = 25 %, Arbeitsspeicher maximal = 7,0 GB | 5 Minuten | CPU maximal = 75 %, CPU durchschnittlich = 55 %, Arbeitsspeicher maximal = 7,0 GB | 1000 pro Minute |
| 5000 VDI | Ausfall | 4–6 Minuten | CPU maximal = 15 %, CPU durchschnittlich = 5 %, Arbeitsspeicher maximal = 7,5 GB | 5 Minuten | CPU maximal = 45 %, CPU durchschnittlich = 40 %, Arbeitsspeicher maximal = 7,5 GB | 1000 pro Minute |
| 500 RDS, 10.000 Sitzungen | Online | 3 Minuten | CPU maximal = 45 %, CPU durchschnittlich = 25 %, Arbeitsspeicher maximal = 7,0 GB | 10 Minuten | CPU maximal = 75 %, CPU durchschnittlich = 55 %, Arbeitsspeicher maximal = 7,0 GB | 1000 pro Minute |
| 500 RDS, 10.000 Sitzungen | Ausfall | 3 Minuten | CPU maximal = 15 %, CPU durchschnittlich = 5 %, Arbeitsspeicher maximal = 7,5 GB | 10 Minuten | CPU maximal = 45 %, CPU durchschnittlich = 40 %, Arbeitsspeicher maximal = 7,5 GB | 1000 pro Minute |
Maximale Workloads
Diese Workloads wurden mit 8 vCPUs und 10 GB Arbeitsspeicher getestet.
| Test-Workloads | Site-Bedingung | VDA-Registrierungszeit | CPU- und Arbeitsspeichernutzung bei Registrierung | Starttestdauer | CPU- und Arbeitsspeichernutzung beim Sitzungsstart | Startrate |
|---|---|---|---|---|---|---|
| 10.000 VDI | Online | 3–4 Minuten | CPU maximal = 85 %, CPU durchschnittlich = 10 %, Arbeitsspeicher maximal = 8,5 GB | 7 Minuten | CPU maximal = 66 %, CPU durchschnittlich = 28 %, Arbeitsspeicher maximal = 7,0 GB | 1400 pro Minute |
| 10.000 VDI | Ausfall | 4–5 Minuten | CPU maximal = 90 %, CPU durchschnittlich = 17 %, Arbeitsspeicher maximal = 8,2 GB | 5 Minuten | CPU maximal = 90 %, CPU durchschnittlich = 45 %, Arbeitsspeicher maximal = 8,5 GB | 2000 pro Minute |
| 1000 RDS, 20.000 Sitzungen | Online | 1–2 Minuten | CPU maximal = 60 %, CPU durchschnittlich = 20 %, Arbeitsspeicher maximal = 8,6 GB | 17 Minuten | CPU maximal = 66 %, CPU durchschnittlich = 25 %, Arbeitsspeicher maximal = 6,8 GB | 1200 pro Minute |
| 1000 RDS, 20.000 Sitzungen | Ausfall | 3–4 Minuten | CPU maximal = 22 %, CPU durchschnittlich = 10 %, Arbeitsspeicher maximal = 8,5 GB | 21 Minuten | CPU maximal = 90 %, CPU durchschnittlich = 50 %, Arbeitsspeicher maximal = 7,5 GB | 1000 pro Minute |
Hinweis:
Die hier gezeigten Workloads sind die maximal empfohlenen Workloads für einen Ressourcenstandort. Um größere Workloads zu unterstützen, fügen Sie weitere Ressourcenstandorte hinzu.
Ressourcennutzung bei der Konfigurationssynchronisierung
Der Konfigurationssynchronisierungsprozess hält die Cloud Connectors mit Citrix DaaS auf dem neuesten Stand. Updates werden automatisch an die Cloud Connectors gesendet, um sicherzustellen, dass die Cloud Connectors bereit sind, das Brokering im Falle eines Ausfalls zu übernehmen. Die Konfigurationssynchronisierung aktualisiert die LHC-Datenbank, SQL Express Server LocalDB. Der Prozess importiert die Daten in eine temporäre Datenbank und wechselt dann nach dem Import zu dieser Datenbank. Dadurch wird sichergestellt, dass immer eine LHC-Datenbank zur Übernahme bereitsteht.
Die CPU-, Arbeitsspeicher- und Festplattennutzung wird vorübergehend erhöht, während Daten in die temporäre Datenbank importiert werden.
Testbedingungen:
- Getestet auf einem AMD EPYC mit 8 vCPUs
- Die importierte Site-Konfigurationsdatenbank war für eine Umgebung mit insgesamt 80.000 VDAs und 300.000 Benutzern (drei Schichten von 100.000 Benutzern) site-weit.
- Die Datenimportzeit wurde an einem Ressourcenstandort mit 10.000 VDI getestet.
Testergebnisse:
- Datenimportzeit: 7–10 Minuten
-
CPU-Nutzung:
- maximal = 25 %
- durchschnittlich = 15 %
-
Arbeitsspeichernutzung:
- Zunahme von ca. 2 GB bis 3 GB
-
Festplattennutzung:
- 4 MB/s Spitzenwert beim Festplattenlesen
- 18 MB/s Spitzenwert beim Festplattenschreiben
- 70 MB/s Spitzenwert beim Festplattenschreiben während des Herunterladens und Schreibens von XML-Konfigurationsdateien
- 4 MB/s Spitzenwert beim Festplattenlesen nach Abschluss des Imports
-
Größe der LHC-Datenbank:
- 400–500 MB Datenbankdatei
- 200–300 MB Protokolldatenbank
Zusätzliche Überlegungen zur Ressourcennutzung:
- Während des Imports werden die vollständigen Site-Konfigurationsdaten heruntergeladen. Dieser Download kann je nach Site-Größe einen Arbeitsspeicher-Spitzenwert verursachen. Wenn während der Konfigurationssynchronisierung Arbeitsspeicher-Spitzenwerte auftreten, sollten Sie die Größe der Cloud Connectors erhöhen.
- Die getestete Site verwendete ca. 800 MB für die Datenbank- und Datenbankprotokolldateien zusammen. Während einer Konfigurationssynchronisierung werden diese Dateien dupliziert, mit einer maximalen kombinierten Größe von ca. 1600 MB. Stellen Sie sicher, dass Ihr Cloud Connector über ausreichend Speicherplatz für die duplizierten Dateien verfügt. Der Konfigurationssynchronisierungsprozess schlägt fehl, wenn die Festplatte voll ist.