Citrix Sizing, Hardware- und Systemanforderungen Citrix Virtual Apps and Desktops: Delivery Controller, VDA, XenDesktop, StoreFront, PVS

In diesem Blogartikel werden von Citrix empfohlene Hardware- und Systemanforderungen für die unterschiedlichen Komponenten der Citrix-Infrastruktur beschreiben bwz. tabellarisch erfasst. Die Hardware-Systemanforderungen für Citrix Virtual Apps and Desktops 7 1912 hat sich grundsätzlich nicht geändert. Die Systemanforderungen des aktuellen Current Release (zzz. 2003) finden hier.

Nachfolgend finden Sie die unterschiedlichen Tabellen basierend auf die Citrix Best Practices aus dem letzten „Citrix VDI Best Practices for XenApp and XenDesktop 7.15 LTSR” Buch. oder Design Methodology Hardware Layer

Wichtig: Die optimale Berechnung hängt  sehr stark von den genutzten Anwendungen und der Arbeitsweise der Benutzer ab. Die tatsachlich erforderlichen Hardware-Ressourcen sollen aufgrund Ihrer individuellen Anforderungen ermittelt werden, ein Proof of Concept ist die bewährteste Methode dafür.

Windows Server 2016 / 2019

Eine reale Systemanforderung ist von den installierten Rollen, Features und Anwendungen abhängig.

VDA - Empfehlungen für Hosted Shared Virtual Desktops (Session Hosts) und Hosted VDI

Die fünf folgenden Tabellen beinhalten je nach Workload empfohlene Hardware-Konfiguration für Citrix VDAs. Vor allem eine korrekte Verteilung der virtuellen CPUs, des virtuellen Arbeitsspeichers, RAM Cache, Storage und Cache Disks ist der Erfolgsschlüssel einer effizienten Citrix Infrastruktur.

Aus Sicht der Citrix-Terminologie befinden sich die VDAs auf dem Resource Layer.

1.1 vCPU

Vor einiger Zeit lautete die einfachen Faustregeln: vier vCPU für 2012 R2 / 2016.  Mittlerweile werden die CPU-Ressourcen des Hostsystems effektiver genutzt.

Aktuell wird es empfohlen, dass die Anzahl der vCPUs in einer VM gleich (oder ½) der Anzahl physischer CPUs in einem NUMA-Knoten sein sollte.

Non-Uniform Memory Access (NUMA)

Beim NUMA handelt es sich um die Architektur für Multiprozessor-Computersysteme. Die CPUs werden direkt an eigenen lokalen Speicherbereich (RAM) angeschlossen. Dadurch wird einen schnellen Prozessorzugriff auf den lokalen Arbeitsspeicher ermöglicht. Alle CPUs in einem physischen System und die dazugehörigen lokalen RAM werden in NUMA-Nodes aufgeteilt. In diesem Fall greifen die CPUs auf das lokale RAM innerhalb dieses NUMA-Knotens.

Die virtuellen Maschinen sollen so konfiguriert werden, dass die Anzahl der zugewiesen vCPU die Grenze den NUMA-Knoten nie überschreitet. Wenn z.B. die NUMA-Knoten über die jeweils 4 Kernen verfügen und die VM (wie unten abgebildet) mit 6 vCPU konfiguriert wurde, dann wird diese VM auf die entfernten Ressourcen den anderen NUMA-Knoten zugreifen. Durch den Remote-Speicherzugriff müssen wir nicht nur mit erhöhter Latenz rechnen, sondern auch mit spürbaren Performanceeinbußen.

Wie viele NUMA Nodes hat mein Host?

Wie Sie sicherlich wiesen, sind nicht alle CPUs gleich und nicht alle Sockets verfügen über nur einen zugrunde liegenden NUMA-Knoten . Folgende Information können Ihnen helfen, die Anzahl der NUMA-Knoten festzustellen. Die Hersteller-Spezifikationen können ebenfalls notwendigen Informationen liefern.

• Hyper-V – starten Sie den Task Manager > Leistung > CPU > rechte Maustaste  > Graph ändern in > NUMA-Knoten.  Noch mehr Informationen zeigt Ihnen Coreinfo von Microsoft Sysinternals.
• WMware ESX - führen Sie folgende Befehlskette aus: esxcli hardware memory get | grep NUMA
• Citrix XenServer - xl info Weitere hilfreiche Information: Xen on NUMA Machines

Virtuelle Sockets oder virtuelle Kerne pro Socket

Aus Sicht einer virtuellen Maschine wäre eine vCPU mit vier virtuellen Kernen identisch den vier vCPUs mit einem virtuellen Kern.

vs. 

Empfohlene Konfiguration: VMware bevorzugt 4 vCPU mit einem virtuellen Kern, anstatt einer mit vier. Hier ist die Erklärung dazu: Does corespersocket Affect Performance?

CPU Over-Subscription

Das Thema wurde bereits hier beschrieben 

Lesenswertes:

• XenApp Scalability v2015, Part 1    
• XenApp Scalability v2017

1.2 User pro Physical Processor (pCPU)

Es handelt sich dabei um einer anderen Methode die notwendigen CPU-Ressourcen zu berechnen. Die folgende Tabelle beinhalten von Citrix empfohlene Werte:

Bei der Berechnung der Profile wird das MS Office 2010 zugrunde gelegt. Die aktuelle Versionen (2016/2019) sind wesentlich rechenintensiver als Office 2010, dies kann zur Verringerung der Benutzerdichte zwischen 10 – 25 % führen.

Types of workloads – ist eine abstrakte, auf Erfahrungswerten basierte Aufteilung der Benutzer.

2. Virtual Memory (vRAM)

Wenn Sie Ihre VMs auf einem ESX-Hypervisor hosten, es ist zu empfehlen, dass der zugewiesene vRAM kleiner als der NUMA-Knoten zugewiesener RAM ist.

2.1. Berechnung des Arbeitsspeichers

Hier ist ein mögliches Beispiel der Berechnung des Arbeitsspeichers eines Session Hostes (2012R2 / 2016 VDAs)

1.  48 GB RAM (49152 MB) wird einer neuen VM zugewiesen.

2.  Im zweiten Schritt wird für das Betriebssystem benötigter Arbeitsspeicher 3 GB abgezogen.

    49152 MB – 3072 MB = 46080 MB

3.  Weiter wird von den restlichen 46080 MB die RAM Cache MCS/PVS (8 GB für Server 2016) abgezogen.

   46080 MB – 8192 MB = 37888 MB

4. Um die bessere User-Experience zu gewährleisten, ist es wünschenswert einen Server Full Load festzulegen. (z.B. 80 % oder 90 %). Jetzt können wir die weiteren 20 % als Puffer abziehen.

   37888 MB – 7578 MB = 30310 MB

5. 30310 MB steht effektiv den Server-Benutzer zur Verfügung. Im letzten Schritt werden 30310 durch 512 MB (durchschnittlicher Arbeitsspeicherverbrauch eines „Medium Users“) geteilt.

   30310 / 512 = 59 User pro Server.

Aus technischer Sicht, spricht nichts dagegen einen Sesson Host anders zu dimensionieren und wesentlich mehr RAM zuzuweisen. Im Falle eines Server-Ausfalls werden aber wesentlich mehr Benutzer betroffen.

2.2 Memory Overcommitment

Die Verwendung der Arbeitsspeicherüberbelegung hängt sehr stark von dem Workload ab. Wenn bei der Bereitstellung des Server-Betriebssystems von der Nutzung die Überbelegung abzuraten ist, sieht es bei der Bereitstellung der VDIs anders aus. In diesem Fall wäre die Verwendung der Funktion durchaus möglich. Wäre es nicht sicherer, die zusätzlichen RAM-Module zu kaufen, um eine höhere VM-Dichte zu erreichen?

3. RAM Cache

Beide Citrix-Bereitstellungsdienste (MCS und PVS) können einen Teil der VM zugewiesenen Arbeitsspeichers als Cache verwenden. Dadurch wird die Zahl der IOPS wesentlich reduziert und die Performance verbessert.

Machine Creation Services:

Provisioning Services:

4. Disk Cache

Die folgende Tabelle gibt  die Information über den möglichen Platzverbrauch auf einem Storage und soll als Hilfe bei der Planung von Storage-Kapazitäten dienen.

Es sollen folgende Punkte beachtet werden:

• der reale Platzbedarf ist sehr stark von verschiedenen Faktoren abhängig, wie z.B.:  der Rebootzyklus, die Auslassung des Systems (User-Anzahl), das Verhalten der App, das Userverhalten
• die Deffirencing Disk (MCS) wird nach jedem Reboot geleert, dies soll auch bei der Planung beachtet werden. Je öfter das System neu gestartet wird, desto weniger Platz wird benötigt.
• die Write Cache Disk kann so konfiguriert werden, dass drauf gespeicherten Daten dauerhaft auf der Disk bleiben.

5. Storage IOPS

Angesicht der Verbreitung der All-Flash-Arrays bzw. Hybrid-Arrays verliert das Thema IOPS massiv an Bedeutung.

Systemanforderungen der Infrastruktur Server

Delivery Controller  (Control Layer)

Die Berechnung der optimalen Systemanforderungen ist von mehreren Faktoren abhängig, die für die Auslastung sorgen.

1. Sie werden weniger Ressourcen benötigen, wenn die Verwaltungskonsole (Studio) und der Director separat vom Delivery Controller installiert werden.
2. Man konnte einen Delivery Controller als eine CPU-intensive Anwendung bezeichnen. Je intensiver die Infrastruktur benutzt wird, desto höher ist die CPU-Auslastung. Besonders ist die Bereitstellung der VDI (Desktop-Startup-, Registrierungs-, Enumerations- und Startanforderung) belastet die Infrastruktur am meisten.

Nach einer ständigen CPU-Auslastung von zirka 80% sollte über einer Erweiterung nachdenken. Das Hinzufügen der weiteren vCPU ist keine effiziente Problemlösung, da die Systemleistung nicht linear mit der Anzahl der eingesetzten CPUs steigt. Fügen Sie einen weiteren Controller der Site hinzu, somit wird die Gesamtlast gleichmäßig auf die bestehenden Controller verteilt.

3. Einen weiteren Punkt, der die vorhandenen Systemressourcen beeinträchtigen kann, ist der Ausfall der zentralen SQL-Datenbank. An diesem Punkt kommt Local Host Cache ins Spiel und sorgt dafür, dass die Citrix Infrastruktur zwar sehr eingeschränkt, aber grundsätzlich funktionsfähig bleibt. Je länger die Datenbank nicht erreichbar wird, desto mehr RAM (über 2 GB) wird belegt und desto mehr Speicherplatz wird benötigt. Der Speicherplatzzuwachs: Plus 1 MB alle 2-3 Minuten bei der durchschnittlichen 10 Anmeldungen pro Sekunde.

Wenn Sie den ersten Delivery Controller entsprechend der folgenden Tabelle konfigurieren, kann Ihre Infrastruktur mehr als 5000 aktive Sessions unterstützen.

Die unten angegebene Berechnung, um die Anzahl der Delivery Controllers zu berechnen:
Anzahl der Delivery Controllers (N) = Anzahl der aktiven Session / 5000 +1

Zwecks Hochverfügbarkeit sollen mindestens zwei Delivery Controller bereitgestellt werden (N + 1-Redundanz).

StoreFront (Access Layer)

Die in der nachfolgenden Tabelle angegeben Werte haben sich bereits als optimal (bis zu 30 000 Verbindungen/Stunde) erwiesen. 

Mehrere StoreFront Server können Sie zu einer Servergruppe hinzufügen. Die Mitgliedschaft in einer Servergruppe ermöglicht eine Synchronisierung bzw. Verteilung der Konfiguration innerhalb der Gruppe. Der StoreFront Server hat keine eingebauten Mechanismen der Lausverteilung zwischen den Gruppenmitgliedern und benötigt einen externen Load Balancer, wie z.B. NetScaler.

Lizenz Server (Control Layer)

Der Lizenz Server (Version: 11.14.0.1) setzt keine besonderen Anforderungen voraus. 

Session Recorder

Citrix Session Recording besteht aus fünf Komponenten: Session Recording Server, Session Recording Policy Console, Session Recording Player, Session Recording Database und Agent. Wobei mehreren Komponenten können sowohl separat installiert, als auch auf demselben Server gehostet werden können.
Es könnte ganz praktisch sein, wenn folgenden Komponenten auf einem Server installiert werden: Server, Policy Console und Player. Der Platzbedarf lässt sich schwer vorhersehen und ist von der tatsächlichen Nutzung abhängig.

Workspace Environment Management

Analog zu Session Recording, kann die Management Konsole gemeinsam mit den Infrastructure Diensten gehostet werden.

Provisioning Server

Die richtige Dimensionierung eines PVS- Servers ist im Wesentlichen von drei Faktoren abhängig:

1. Die Anzahl der unterschiedlichen bereitgestellten Betriebssysteme (vDisks) ist für die Berechnung der benötigten RAM Speicherplatz von Bedeutung.  
2. Die Menge der gleichzeitig gestreamten vDisk wirkt auf die Anzahl der vCPU aus.
3. Die Netzwerkbandbreite soll ebenso berücksichtig werden. 

Falls die Management Konsole separat von dem Server installiert werden soll, soll das System folgende Voraussetzungen erfüllen: 

RAM

Der PVS-Server speichert die vDisks teilweise im Arbeitsspeicher und verringert dadurch die Anzahl der Lesevorgänge auf dem vDisk-Store, da das Lesen von der Festplatte (sogar SSD) bekanntermaßen langsamer als das Lesen aus dem RAM ist.

Beispielhafte Berechnung des Arbeitsspeichers in einer kleinen PVS-Farm. In der Farm werde nur zwei unterschiedlichen vDisk existieren: Windows 10 und Server 2016

• 4 GB RAM für den Server selbst
• 2 GB RAM pro aktive vDisk (Desktop Betriebssystem - XD Windows 10)
• 4 GB RAM pro aktive vDisk (Published Application / Desktop XA - Windows 2019)

Von Citrix wird folgende Formel zur Berechnung des Arbeitsspeichers (RAM) angeboten:

Gesamtspeicher = 4GB + (Anzahl der vDisks XD * 2GB) + (Anzahl der vDisks XA * 4GB) + 15% (Puffer)

vCPU

Der PVS-Server ist nicht besonders CPU-intensiv. Die Provisioning Services PVS beanspruchen die CPU-Ressourcen um die Streams (vDisk zu den Zielsystemen) zu steuern. Die Anzahl der gleichzeitig ausgeführten Streams, wird nach folgender Formel berechnet:

Maximale Anzahl der Streams = Anzahl der Ports * Anzahl der Threads pro Port

Nach der Installation wird der Streaming-Dienst im Standard mit 20 aufeinander folgenden Ports-Freigaben (6910 – 6930) und 8 Threads pro Port konfiguriert. Es ist einfacher und effizienter, die Anzahl der Ports zu erhöhen, anstatt die weiteren vCPU hinzuzufügen. 

Die Standardwerte lassen sich jederzeit anpassen: Server Properties > Advanced Server Properties > Server

Von Citrix wird es empfohlen, die Anzahl der Threads und die Anzahl der vCPU gleichzuhalten. Für eine kleine PVS-Farm (bis zu ca. 500 VMs) empfiehlt Citrix die Zuweisung von vier vCPU für eine größere 8 vCPU.

Netzwerk

Die effiziente Implementierung der Provisioning Services setzt eine perfomante und stabile Netzwerkanbindung voraus. Die Skalierbarkeit der PVS ist von dem verfügbaren Netzwerkdurchsatz abhängig.  (Die Verwendung der XenServer mit der Option PVS-Accelerator stellt eine Ausnahme dar.  - Introducing PVS-Accelerator, only available with XenServer! - How to Configure XenServer PVS-Accelerator?)

Obwohl die übertragbare Datenmenge die zum Starten des Betriebssystem benötigt werden, vergleichsweise gering sind (z.B. für Windows 10, Server 2012 R2 oder Server 2016 werden circa 250 MB übertragen).

Um die das Starten der Zielgeräte benötigte Zeit zu ermitteln, können Sie die folgende Formel verwenden:

Zeit zum Starten = (Anzahl der Zielgeräten * verbrauchte Datenmenge) / Netzwerkdurchsatz

Auf Basis der oberen Informationen ist der Einsatz der 10-GB Netzwerkarten zu empfehlen. Als Alternative können Sie auch das Netzwerk-Teaming verwenden.

Empfohlene Artikel zum Thema: 

• Updated Guidance on PVS Ports and ThreadsUpdated Guidance on PVS Ports and Threads
• Turbo Charging Performance with PVS 7.7
• Best Practices for Configuring Provisioning Services Server on a Network
• ControllUp - Best Practices for Deploying and Configuring Citrix Provisioning Services
• Best Practices for deploying PVS in multi-geo environments

• Zurück
• Weiter