Überlegungen zu Skalierung und Größe für Cloud Connectors

Wenn Sie den Citrix Virtual Apps and Desktops-Service auf Größe und Skalierbarkeit prüfen, sollten Sie alle Komponenten berücksichtigen. Testen Sie, ob die gewählte Konfiguration aus Cloud Connectors und vom Kunden verwalteten StoreFront Ihren spezifischen Anforderungen entspricht. Zu knapp dimensionierte Maschinen können sich negativ auf die Systemleistung auswirken. Dieser Artikel erläutert die getesteten maximalen Kapazitäten und enthält Empfehlungen zu bewährten Methoden für die Konfiguration der Cloud Connector-Maschinen.

Zusammenfassung

Alle Ergebnisse in dieser Zusammenfassung basieren auf den Erkenntnissen aus der im Folgenden beschriebenen Testumgebung. Andere Systemkonfigurationen führen möglicherweise zu anderen Ergebnissen.

Wichtigste Testergebnisse:

  • Dimensionierung und Skalierbarkeit für den Citrix Cloud Virtual Apps and Desktops-Service
    • Für Sites mit maximal 5000 Arbeitsstation-VDAs wird die Verwendung von drei Cloud Connectors mit je 4 vCPUs empfohlen.
      • Dies ist eine Hochverfügbarkeitskonfiguration vom Typ N+1.
    • 20.000 Sitzungen auf 100 Server-VDAs können um 57 % schneller gestartet werden, wenn statt des von Citrix verwalteten StoreFront das vom Kunden verwaltete StoreFront verwendet wird.
    • Das Bereitstellen von 1000 VMs dauert durchschnittlich 140 Minuten.
  • Citrix Virtual Desktops Essentials
    • Für 1000 Windows 10-VMs wird die Verwendung von zwei Cloud Connectors auf Standard_A2_v2-VMs unter Azure empfohlen.
    • Der Start von 1000 Sitzungen auf Windows 10-VMs in Azure dauert weniger als 20 Minuten.
    • In Tests dauerte es ungefähr 44 Sekunden, bis ein Benutzer nach Anmeldung bei StoreFront einen funktionsfähigen VDI-Desktop mit Standardeinstellungen erhielt.
    • Die Bereitstellung von 1000 Windows 10-VMs in Azure dauert durchschnittlich 8 Stunden.

Übersichtsbild

  • Die Verwaltung von Cloud Connector-Diensten erfolgt durch Citrix Cloud, während der Kunde die Maschinen verwaltet.
  • Bei den Sitzungsstarttests für Citrix Virtual Desktops Essentials wurde eine NetScaler-Appliance verwendet. In allen anderen Sitzungsstarttests wurde eine direkte Verbindung mit StoreFront genutzt.

Testmethode

In den Tests wurde die Leistung der Umgebungskomponenten nach Hinzufügen von Last gemessen. Zur Überwachung der Komponenten wurden Leistungsdaten und die erforderliche Zeit für bestimmte Prozesse (z. B. Anmeldezeit, Maschinenerstellungszeit) erfasst. In einigen Fällen wurden firmeneigene Simulationstools von Citrix verwendet, um VDAs und Sitzungen zu simulieren. Diese Tools 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. Folgende Tests wurden durchgeführt:

  • Sitzungsanmeldungsansturm: Dieser Test simuliert ein hohes Aufkommen an gleichzeitigen Anmeldungen.
  • VDA-Registrierungsansturm: Dieser Test simuliert ein hohes Aufkommen an gleichzeitigen VDA-Registrierungen. Dies kann beispielsweise nach einem Upgradezyklus oder behobenen Ausfall erfolgen.
  • Bereitstellung von Maschinenerstellungsdiensten: Dieser Test misst den Zeitaufwand für MCS-Aufgaben wie das Kopieren von Masterimages, das Erstellen von Active Directory-Konten und das Erstellen von Maschinen.

Die Ergebnisse dieser Tests bildeten die Grundlage für unsere Empfehlungen zur Cloud Connector-Dimensionierung. Die Durchführung der Tests wird im Folgenden beschrieben.

Tests mit Sitzungsanmeldungsansturm

Sitzungen werden auf vom Kunden und von Citrix verwalteten StoreFront-Servern gestartet. In jeder Umgebung wurden Tests mit 1000 Sitzungen, 5000 Sitzungen und 20.000 Sitzungen ausgeführt. Erfasst wurden die Zeiten für StoreFront-Anmeldung, Ressourcenenumeration und ICA-Dateiabruf und die Zeit bis zum aktiven Desktop. Die Zeit bis zum aktiven Desktop misst die Zeit vom Start der ICA-Datei bis zur Einsatzbereitschaft der vollständig geladenen Ressource.

Für einige Testszenarien wurden zum Testen größerer Benutzerzahlen Simulationstools verwendet. Simulationstools ermöglichen Tests mit weniger Hardware, als für 5000 oder 20.000 reale Sitzungen erforderlich wären. 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. Die gesamte Kommunikation vom Brokeragent zum Brokerdienst stimmt mit der Kommunikation einer tatsächlichen Sitzung überein. Die Leistungsmetriken der 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.

Tests mit VDA-Registrierungsansturm

Bei einem VDA-Registrierungsansturm werden hunderte oder tausende VDAs gleichzeitig registriert, um die Wiederherstellung einer Site zu simulieren. Zu einer VDA-Registrierung hoher Benutzerzahlen kommt es in der Regel alle zwei Wochen nach dem Upgradezyklus, nach unerwarteten Problemen am Wochenbeginn (“Montagmorgenszenario”) oder nach einem behobenen Ausfall zwischen den vom Kunden verwalteten Maschinen und den von Citrix verwalteten Services. Die Tests wurden mit 5000 VDAs durchgeführt, und während jedes Tests wurden die Leistungsdaten der Cloud Connectors gesammelt. Erfasst wurden Perfmon-Leistungsindikatoren (CPU, Arbeitsspeicher, Datenträgerauslastung) und die VDA-Registrierungszeiten.

Tests zur Bereitstellung des Maschinenerstellungsdienstes

Die Bereitstellungstests wurden durchgeführt, indem Kataloge unterschiedlicher Größe erstellt wurden. Durch Messung der benötigten Zeit für verschiedene Aufgaben (Kopieren des Masterimages, Erstellen von AD-Konten und Maschinen) wurde dann die Leistung bestimmt. Getestet wurde auch ein Anstieg der Kataloggröße in Azure. Bereitstellungstests mit 1000 Maschinen wurden für Azure und für vom Kunden verwaltete Hypervisoren durchgeführt. Tests in Azure wurden auf Windows 10-VMs beschränkt, da Windows 10 das einzige unterstützte Betriebssystem für Citrix Virtual Desktops Essentials ist. Der vom Kunden verwaltete Hypervisor wurde unter Windows 10 und Windows 2012 R2 getestet.

Testumgebung

Die Testumgebungskonfiguration umfasste Citrix Cloud Connector, den Citrix Virtual Apps and Desktops-Service und Citrix Virtual Apps and Desktops-Komponenten. Die verwendeten Maschinen- und Betriebssystemspezifikationen sind hier angegeben, damit Sie unsere Konfiguration und Testergebnisse mit Ihren eigenen Konfigurationen und Anforderungen vergleichen können.

Verwendete Tools

Wir verwendeten ein internes Testtool, um Leistungsdaten und Metriken der getesteten Maschinen zu erfassen und um die Sitzungen zu starten. Mit diesem proprietären Tool können Benutzersitzungen in der Citrix Virtual Apps and Desktops-Umgebung gleichzeitig gestartet und Reaktionszeiten und Leistungsmetriken zentral aufgezeichnet werden. Im Wesentlichen dient das Testtool zum Koordinieren der Tests und zum Erfassen der Ergebnisse.

Testkonfiguration – Citrix Virtual Apps and Desktops

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

  • Cloud Connectors:
    • Szenario 1: zwei Windows 2012 R2, 2 vCPUs, 4 GB RAM
    • Szenario 2: zwei Windows 2012 R2, 4 vCPUs, 4 GB RAM
  • StoreFront (vom Kunden verwaltet): ein Windows 2012 R2, 8 vCPUs, 8 GB RAM
  • Hypervisors: acht VMware vSphere ESXi 6.0 Update 1, HP ProLiant BL 460c Gen9, 2 Intel E5-2620-CPUs, 256 GB RAM
  • Hypervisorspeicher: NFS-Freigabe mit 2 TB auf NetApp 3250
  • VDA: Windows 2012 R2 und Windows 10 Build 1607 (32 Bit)

Testkonfiguration – Citrix Virtual Desktops Essentials

Sitzungen wurden von 100 Windows 2012 R2-Clientmaschinen gestartet. Sitzungen wurden mit einem Windows Active Directory in Azure authentifiziert. Roamingprofile wurden auf einem Windows-Dateiserver in Azure gespeichert.

  • VDA: 1000 Windows 10 Build 1607 (64 Bit), 2 vCPUs, 7 GB RAM (Standard_D2_v2-Instanz)
  • Client: 100 Windows 2012 R2-Server, 8 vCPUs, 8 GB RAM
  • Domänencontroller: zwei Windows 2012 R2, 4 vCPUs, 14 GB RAM (Standard_D3_v2-Instanz)
  • Dateiserver: ein Windows 2012 R2, DS11-Instanz
  • NetScaler VPX:ein NetScaler 11.0, Standard_D3_v2-Instanz mit 1000-Platinum-Lizenz
  • Cloud Connectors:
    • Szenario 1: zwei Windows 2012 R2, 2 vCPUs, 4 GB RAM (Standard_A2_v2-Instanz)
    • Szenario 2: zwei Windows 2012 R2, 4 vCPUs, 7 GB RAM (Standard_A3-Instanz)
  • StoreFront (vom Kunden verwaltet): ein Windows 2012 R2, DSv2-Instanz

Überlegungen zu von Kunden verwalteten Maschinen

Von Kunden verwaltete Maschinen können sich im Büro des Kunden, im Datencenter oder in einem Cloud-Konto (wie Azure oder AWS) befinden. Nach unserer Definition werden vom Kunden verwaltete Maschinen vollständig vom Kunden kontrolliert. Vom Kunden verwaltete Maschinen umfassen: Cloud Connector, StoreFront-Server, RDS-Server, VDI-Maschinen und Maschinen mit Remote-PC-Zugriff (nicht getestet). RDS-Server, VDI-Maschinen und Maschinen mit Remote PC-Zugriff wurden in diesem Bericht unter dem Begriff “VDAs” zusammengefasst.

StoreFront-Server

Beim Test des Citrix Virtual Apps and Desktops-Dienstes verwendeten wir eine Maschine mit 8 vCPUs und 8 GB RAM als vom Kunden verwalteten StoreFront-Server. Für Citrix Virtual Desktops Essentials-Tests verwendeten wir eine Azure-Maschine vom Typ Standard_DS2_v2 (2 vCPUs, 7 GB RAM) als vom Kunden verwalteten StoreFront-Server. Weitere Informationen zur korrekten StoreFront-Servergröße für Ihre Umgebung finden Sie unter StoreFront Planning Guide.

Cloud Connectors

Getestet wurden vom Kunden verwaltete Cloud Connectors auf VMs mit 2 vCPUs und 4 GB RAM (Szenario 1) bzw. auf VMs mit 4 vCPUs und 4 GB RAM (Szenario 2). In Azure wurden Cloud Connectors auf Instanzen der Größe Standard_A2_v2 (2 vCPUs, 4 GB RAM) bzw. Standard_A3 (4 vCPUs, 7 GB RAM) getestet.

In unseren Tests wurden Cloud Connectors in Hochverfügbarkeitsgruppen bereitgestellt (ohne Lastausgleich). Obwohl dieses Dokument primär Testumgebungen mit zwei Cloud Connectors behandelt, wird eine N+1-Gruppe mit drei Cloud Connectors empfohlen. Der übrige Bericht konzentriert sich auf Cloud Connectors und ihre Dimensionierung für eine optimale Leistung.

Testergebnisse

VDA-Registrierungsansturm

Dieser Test umfasst eine hohe Anzahl gleichzeitiger VDA-Registrierungen und verdeutlicht die Beziehung zwischen Cloud Connector-Größe und Umgebungsstabilität. Die Umgebungsstabilität wird während einer Reihe von Netzwerkausfällen zwischen dem vom Kunden verwalteten Standort und den von Citrix verwalteten Diensten getestet. Ein VDA-Registrierungsansturm kann ausgelöst werden, wenn der Delivery Controller und die Sitekonfigurationsdatenbank aktualisiert werden (in der Regel erfolgt dies alle zwei Wochen).

Vergleich der CPU-Größe von Cloud Connectors: 2 vCPUs bzw. 4 vCPUs

Vergleich der CPU-Größe von Cloud Connectors

  • Die mittlere CPU-Last ist ähnlich, bei Belastungsspitzen gelangen Maschinen mit 2 vCPUs jedoch an ihre Grenzen und es kommt zu gelegentlichen Aufhebungen der VDA-Registrierung.
  • Aus Stabilitätsgründen wird daher für Sites mit ca. 5000 VDAs die Verwendung von Cloud Connectors mit 4 vCPUs empfohlen.
  • Die Verwendung von Cloud Connectors mit 2 vCPUs wird für Sites mit 2500 VDAs empfohlen.
  • Cloud Connectors sind eine Hochverfügbarkeitsgruppe und bieten keinen Lastausgleich.
  • Ein Argument gegen die Verwendung von Cloud Connectors mit 2 vCPUs für Sites mit 5000 VDAs ist die zufällige Zuweisung von Maschinen. Da Cloud Connectors keinen Lastausgleich verwenden, kann nicht vorhergesagt werden, welche Last auf einen der Cloud Connectors geleitet wird. Bei unseren Tests wurden gelegentlich mehr als 60 % der Last auf eine Maschine geleitet.
VDA-Anzahl Erforderliche Cloud Connectors
<2500 2 VMs + 1 mit jeweils 2 vCPUs
<5000 2 VMs + 1 mit jeweils 4 vCPUs

Registrierungszeit bei einem VDA-Registrierungsansturm im Vergleich (Cloud Connector-Paar mit hoher Verfügbarkeit)

Cloud Connector-Größe VDA-Anzahl Registrierungszeit
2 vCPUs 5000 11:03
4 vCPUs 5000 5:46
  • Cloud Connectors mit 4 vCPUs erwiesen sich in unseren Tests als stabiler.
  • VDAs wurden schneller registriert, wenn Cloud Connectors mit 4 vCPUs ausgestattet waren.
  • Bei Tests mit Cloud Connectors mit 2 vCPUs wurden VDA-Neuregistrierungen beobachtet.
    • Eine Neuregistrierung kann auftreten, wenn bei der Registrierung ein Timeout auftritt oder es in der VDA-Kommunikation zur Taktverzögerung kommt.

Speichernutzung nach Komponente in einem Cloud Connector während eines Registrierungsansturms mit 5000 VDAs

Bild der Speichernutzung

  • Dieses Diagramm bietet eine detaillierte Ansicht der Speichernutzung durch Citrix Komponenten und Microsoft LSASS (Subsystemdienst für die lokale Sicherheitsautorität) während des Registrierungsansturmtests.
  • Der LSASS-Prozess auf den Cloud Connectors spielt sowohl bei der Registrierung als auch beim Sitzungsstart eine bedeutende Rolle. Sämtliche Active Directory-Authentifizierungen der Citrix Cloud-Dienste werden über die Cloud Connectors an das vom Kunden verwaltete Active Directory weitergeleitet.
  • Die Speicherauslastung erreicht einen Spitzenwert während der VDA-Registrierung und sinkt, nachdem alle VDAs erfolgreich registriert wurden.
  • Bei Cloud Connectors mit 4 GB Arbeitsspeicher wurde eine hohe Speicherauslastung beobachtet.

Sitzungsstart (Citrix Virtual Desktops Essentials)

Es wurden 1000 Sitzungsstarttests mit der Citrix Virtual Desktops Essentials-Plattform durchgeführt. Dabei wurden Cloud Connector-Instanzen unterschiedlicher Größe miteinander verglichen. Getestet wurden Instanzen der Größe Standard_A2_v2 (2 vCPUs, 4 GB RAM) und Standard_A3 (4 vCPUs, 7 GB RAM).

Connector-CPU-Auslastung beim Sitzungsstarttest (StoreFront unter Verwaltung von Citrix)

Bild der Connector-CPU-Auslastung

  • Während des Tests gab es nur geringe CPU-Konflikte. Die Standard_A2_v2-Instanz konnte eine VDI-Bereitstellung mit 1000 Maschinen während eines Sitzungsstarttests mit hoher Last problemlos bewältigen.
  • Die Standard_A3-Instanz erwies sich als übermäßig groß für diese Sitegröße und wird daher bei der weiteren Auswertung nicht berücksichtigt.
  • Maschinen der Größe Standard_A3 könnten für größere VDI-Sites erforderlich sein.

CPU-Auslastung durch Hauptkomponenten eines A2v2-Cloud Connectors beim Start von 1000 Sitzungen

Bild der CPU-Auslastung

Hinweise:

Weitere auf dem Cloud Connector ausgeführte Prozesse ergaben keine aussagekräftigen Metriken und werden darum nicht angezeigt.

  • Der Citrix Remote Broker Provider (XaXdCloudProxy) vermittelt die Kommunikation zwischen den vom Kunden verwalteten VDA-Maschinen und den von Citrix verwalteten Services (Delivery Controller).
  • LSASS auf den Cloud Connectors verarbeitet sämtliche Active Directory-Authentifizierungen. Die Authentifizierungen der Citrix Cloud-Dienste werden über die Cloud Connectors an das vom Kunden verwaltete Active Directory weitergeleitet.
  • Das Diagramm zeigt die Auslastung eines einzelnen Cloud Connectors, auf den während des Tests ein höherer Lastanteil geleitet wurde. Ein zweiter Cloud Connector hatte eine geringere CPU-Last im Test und ist nicht im Diagramm dargestellt.

Vergleich der Cloud Connector-Speichernutzung pro Instanz

Bild des Cloud Connector-Arbeitsspeichers

  • Die geringere Menge an verfügbarem Speicher auf der Standard_A2_v2-VM (4 GB RAM) verweist auf eine hohe Speicherauslastung auf dieser Maschine.
  • Die hohe Speicherauslastung wird durch den Citrix Remote-HCL-Server-Prozess (RemoteHCLServer) verursacht, der den Energiezustand der 1000 Maschinen in Azure aufrechterhält.
    • Aufgrund von Einschränkungen der Azure-API-Rate können diese Zustände nicht regelmäßig abgefragt werden.
  • Nach dem Test vorgenommene Änderungen am Citrix Remote-HCL-Server (RemoteHCLServer) ermöglichen dem Delivery Controller die Direktübertragung von Maschinenzuständen an Azure.
    • Dadurch wird die Speicherauslastung erheblich reduziert, und die Standard_A2_v2-Instanzen können die 1000 VDA-Site ohne Probleme verwalten.

Sitzungsstartzeiten

Vergleich der vom Kunden bzw. von Citrix verwalteten StoreFront-Server (Standard_A2_v2 und Standard_A3)

  StoreFront unter Verwaltung des Kunden* StoreFront unter Verwaltung des Kunden* StoreFront unter Verwaltung von Citrix StoreFront unter Verwaltung von Citrix
  A3 A2v2 A3 A2v2
Authentifizierung 561 ms 575 ms 1996 ms 2051 ms
Enumeration 1132 ms 1054 ms 1410 ms 1577 ms
Gesamtanmeldezeit 1693 ms 1629 ms 3406 ms 3621 ms
         
Abruf der ICA-Datei 3464 ms 3659 ms 4730 ms 6222 ms
OS-Anmeldung abgeschlossen 38,83 Sekunden 41,91 Sekunden 37,67 Sekunden 40,08 Sekunden
Gesamtstartzeit 42,3 Sekunden 45,6 Sekunden 42,4 Sekunden 42,4 Sekunden

Hinweise:

Die aufgeführten Zeiten sind Durchschnittswerte aller Testläufe. Vom Kunden verwalteter StoreFront-Server in Azure: Standard_DS2_v2 (2 vCPUs, 7 GB RAM)

  • Von Citrix verwaltete StoreFront-Sitzungen sind unter Last langsamer, da sich StoreFront bei dem vom Kunden verwalteten Active Directory über das WAN authentifizieren muss.
  • Während des Tests trat eine Latenz von ca. 30 ms zwischen Client-Maschinen und NetScaler auf.
  • Bei Verwendung von Standard_A3-Instanzen für Cloud Connectors verlangsamten sich Sitzungsstarts im Schnitt um 3-4 Sekunden, wenn die Umgebung stark ausgelastet war.
    • Die Standard_A3-VM hat doppelt so viele CPU-Kerne wie Standard_A2_v2.
    • Während des Tests zeigte die Standard_A2_v2-Instanz eine hohe Speicherauslastung.
      • Die hohe Speicherauslastung wurde behoben, nachdem die RemoteHCLServer-Kommunikation von Cloud Connectors in Azure ARM-Bereitstellungen entfernt wurde.

Anmeldezeiten für 1000 Windows 10-Sitzungen

Bild der Sitzungsanmeldung

  • Alle Maschinen wurden vor dem Test eingeschaltet.
  • Das Testverfahren startete 1000 Sitzungen im Zeitraum von etwa 8 Minuten.
  • Die Zeit bis zum aktiven Desktop betrug im Durchschnitt rund 37,67 Sekunden auf einem VDA mit Standard_D2_v2-Instanz und Windows 10 (64 Bit).
  • Das Diagramm zeigt die einzelnen Anmeldezeiten im Testverlauf, gemessen vom Abrufen der ICA-Datei bis zur Anzeige eines aktiven, einsatzbereiten Desktops.
    • Die grünen und gelben Bereiche kennzeichnen eine bzw. zwei Standardabweichungen.
  • Obwohl die Sitzungsstartzeiten konsistent sind, gibt es einige Ausreißer. Diese können durch kurzzeitige Änderungen der Netzwerkbedingungen ausgelöst werden, mit Auswirkungen auf Folgendes:
    • STA-Ticketaustausch auf dem NetScaler, weitergeleitet über Cloud Connectors.
    • Aufbau einer HDX-Verbindung über das WAN.
    • Azure-Speicher. Tests verwendeten den Standardspeicher.

Simulierter Sitzungsstart

Beim Test mit simulierten Sitzungsstarts werden Cloud Connectors, Delivery Controller und Sitekonfigurationsdatenbank beansprucht. Simulierte Sitzungstarts testen die Fähigkeit der Komponenten, eine große Anzahl gleichzeitiger Anmeldungen zu verarbeiten und die Sitzungen unter andauernder Last aufrechtzuhalten. Es wurden Verfahren mit 5000 und 20.000 Sitzungen getestet. Dieses Dokument konzentriert sich auf die Tests mit 20.000 Sitzungen. Startrate und Komponentenverhalten waren bei beiden Tests nahezu identisch. Der Test mit 20.000 Sitzungen lief jedoch länger und gab einen besseren Überblick über die Dienstnutzung im Zeitverlauf. Dabei wurden so schnell wie möglich 25 Sitzungen gleichzeitig gestartet. Durch die Einstellung zum schnellstmöglichen Sitzungsstart konnte das getestete System festlegen, wie schnell die Umgebung auf Verbindungen reagieren musste.

CPU-Auslastung der Cloud Connectors beim Sitzungsstarttest (Hochverfügbarkeitsgruppe)

Bild der Cloud Connectors bei Hochverfügbarkeit

  • Das Diagramm vergleicht die CPU-Auslastung der Cloud Connectors beim Start von 20.000 Sitzungen.
  • Zwei Cloud Connectors wurden für Belastungs- und Auslastungstests bereitgestellt. Für hohe Verfügbarkeit wird eine Bereitstellung vom Typ N+1 mit drei Cloud Connectors empfohlen.
  • Während des Tests wurden keine CPU-Konflikte beobachtet.

CPU-Auslastung der Cloud Connectors nach Komponente beim Test mit 20.000 Sitzungsstarts

Bild der CPU-Auslastung der Cloud Connectors

  • Der LSASS-Service (Subsystemdienst für die lokale Sicherheitsautorität) verbraucht Rechenleistung bei der Sitzungsanmeldung, wobei das von Citrix und das vom Kunden verwaltete Storefront verwendet wird.
  • Alle von Citrix verwalteten Services müssen zur Authentifizierung über die Cloud Connectors auf das vom Kunden verwaltete Active Directory zugreifen.

Speichernutzung nach Komponente beim Start von 20.000 Sitzungen

Bild der Speichernutzung

  • Der Speicherauslastung ist während des Sitzungsstarts gering.
  • Der Speicherbedarf der meisten Komponenten ändert sich während des Tests nicht, was sich auch an den nahezu identischen Spitzen- und Durchschnittswerten zeigt.

Vergleich der vom Kunden bzw. von Citrix verwalteten StoreFront-Server beim Sitzungsstart

  StoreFront unter Verwaltung des Kunden* StoreFront unter Verwaltung von Citrix
Authentifizierung 261 ms 1629 ms
Enumeration 1075 ms 1275 mss
Gesamtanmeldezeit 1336 ms 2904 ms
     
ICA-Dateiabruf 2132 ms 2715 ms

Hinweise:

Als vom Kunden verwalteter StoreFront-Server wurde eine VM mit 8 vCPUs, 8 GB RAM und Windows 2012 R2 für die Tests verwendet. Das von Citrix verwaltete StoreFront befand sich auf dem Delivery Controller und nutzte Ressourcen gemeinsam mit anderen Citrix Services.

  • Die Verwendung eines vom Kunden verwalteten StoreFront-Servers ist schneller, da die AD-Authentifizierung über das WAN zeitaufwändig ist.
  • Während des Tests trat eine Latenz von ca. 30 ms zwischen den Cloud Connectors und dem Delivery Controller auf.
  • Die Anmeldezeit mit von Citrix verwaltetem StoreFront bzw. vom Kunden verwalteten StoreFront-Server unterschied sich um 2 Sekunden, wenn der StoreFront-Server unter Last war.
  • Beim Abrufen der ICA-Datei wurde ein Unterschied von durchschnittlich 1,2 Sekunden festgestellt. Dies ist eine Steigerung von 83 %.
  • Die Verwendung eines vom Kunden verwalteten StoreFront-Servers wird für Kunden empfohlen, die eine hohe Anzahl von Sitzungen gleichzeitig starten müssen.

Bereitstellung des Maschinenerstellungsdienstes

MCS-Tests mit Citrix Virtual Desktops Essentials und Azure Resource Manager

Mit dem Maschinenerstellungsdienst erstellen und löschen Sie virtuelle Desktops (VDA) in Azure. Im ersten Schritt erstellen Sie eine Windows 10-VHD und laden die VHD in Azure hoch. Das Masterimage wird von der virtuellen Festplatte erstellt. Mit Citrix Virtual Desktops Essentials können Sie virtuelle Maschinen vom Masterimage erstellen.

Maschinenanzahl Kopieren des Masterimages Active Directory-Kontoerstellung Maschinenerstellung
10 30 Minuten 1 Minute 7 Minuten
100 30 Minuten 7 Minuten 50 Minuten
250 40 Minuten 8 Minuten 2 Stunden
500 55 Minuten 15 Minuten 4 Stunden
1000 65 Minuten 30 Minuten 8 Stunden

Hinweise:

Die Zeiten basieren auf mehreren Testläufen und können variieren.

  • Der Maschinenerstellungsprozess wurde mit verschiedenen Maschinenzahlen getestet. Gemessen wurde die für folgende Aktionen erforderliche Zeit:
    • Kopieren des Masterimages
    • Erstellen von Maschinenkonten
    • Bereitstellen der Maschinen
  • Der Zeitanstieg ist nicht linear, da Kopien des Masterimages für jedes Speicherkonto repliziert werden müssen. Die Replikation erfolgt parallel und wird langsamer, je mehr Aufgaben hinzukommen.
    • Pro Speicherkonto gilt ein Limit von maximal 40 Maschinen. Das Limit erfordert 25 Speicherkonten für eine 1000 VM-Umgebung.
    • Es gilt ein Limit von 760 Maschinen pro Ressourcenstandort.
  • Die Erstellung eines Active Directory-Kontos muss über die Cloud Connectors erfolgen, wodurch die zum Abschluss der Aufgabe erforderliche Zeit steigt. Es werden rund 33 Active Directory-Konten pro Minute erstellt.
  • Für die Tests wurden Cloud Connectors vom Typ Standard_A2_v2 verwendet. Es wurden keine Ressourcenengpässe beobachtet.

MCS-Tests mit Citrix Virtual Apps and Desktops

MCS-Bereitstellungstests wurden auf einem VMware ESXi 6.0-Hypervisor durchgeführt. Der Cluster enthält acht vSphere-Hosts, mit einem NFS-Speicher auf einer NetApp-Freigabe.

Betriebssystem Maschinenanzahl Kopieren des Masterimages Active Directory-Kontoerstellung Maschinenerstellung
Win2012 100 4 Minuten 3 Minuten 4 Minuten
WIN 2012 R2 1000 5 Minuten 30 Minuten 100 Minuten
WIN 10 (32 BIT) 100 4 Minuten 3 Minuten 4 Minuten
WIN 10 (32 BIT) 100 4 Minuten 3 Minuten 4 Minuten

Hinweise:

Die Zeiten basieren auf mehreren Testläufen und können variieren. Die Tabelle enthält die Mittelwerte der Testergebnisse aus diesen Läufen.

  • Die für den Maschinenerstellungsprozess erforderliche Zeit entspricht in etwa der Zeit, die in XenApp und XenDesktop 7.x-Versionen benötigt wird. Der Hauptunterschied in diesen Tests liegt bei der Erstellung der Active Directory-Konten. In Cloud-Umgebungen muss die Kontoerstellung über die Cloud Connectors geleitet werden. In der Cloud-Umgebung werden rund 33 Active Directory-Konten pro Minute erstellt.
  • Für die Tests wurden zwei VMs mit 4 vCPUs und 4 GB RAM als Cloud Connectors verwendet. Während des Tests wurden keine Ressourcenkonflikte beobachtet.