Citrix Sizing, Hardware- und Systemanforderungen 7.15: 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.

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.

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.

 

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. 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.

 

 Types of workloads Betriebssystem

      vCPU  /  

Skalierung

 vCPU  /  

User Experience

Light Windows 10 2 vCPU 2 vCPU
Windows 2012 R2 2 vCPU 3 vCPU
Windows 2016  NUMA or 1/2 of NUMA  NUMA or 1/2 of NUMA 
Medium Windows 10  2 vCPU 3 vCPU
Windows 2012 R2  NUMA oder 1/2 von NUMA NUMA oder 1/2 von NUMA
Windows 2016 NUMA oder 1/2 von NUMA NUMA oder 1/2 von NUMA
Heavy Windows 10  2 vCPU 3 vCPU
Windows 2012 R2 NUMA oder 1/2 von NUMA NUMA oder 1/2 von NUMA
Windows 2016 NUMA oder 1/2 von NUMA NUMA oder 1/2 von NUMA

 

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.

 

 

NUMA Nodes Architektur

 

 

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.

NUMA Nodes Remote Memory Access

 

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.

vCPU Corevs. Core pro vCPU Core

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:

 

 

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.

 Types of workloads Betriebssystem

      vRAM  / 

 Skalierung

 vRAM  /  

User Experience

Light Windows 10 2 GB 3 GB
Windows 2012 R2 256 MB pro Benutzer
Windows 2016 320 MB pro Benutzer
Medium Windows 10 3 GB 4 GB
Windows 2012 R2 512 MB pro Benutzer
Windows 2016 640 MB pro Benutzer
Heavy Windows 10 6 GB 8 GB
Windows 2012 R2 1024 MB pro Benutzer
Windows 2016 1280 MB pro Benutzer
 

 

 

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:

Memory MCS

Provisioning Services:

Memory PVS

 

 Types of workloads Betriebssystem

      RAM Cache /  

Skalierung

 RAM Cache /  

User Experience

Light Windows 10 128 MB 256 MB
Windows 2012 R2 2 GB
Windows 2016 4 GB
Medium Windows 10 256 MB 512 MB
Windows 2012 R2 4 GB
Windows 2016 8 GB
Heavy Windows 10 512 MB 1024 MB
Windows 2012 R2 6 GB
Windows 2016 10 GB

 

 

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.

 

 Types of workloads Betriebssystem

Storage-Speicherverbrauch

MCS-Deffirencing Disk / PVS - Write Cache Disk

Light Windows 10 10 GB
Windows 2012 R2 40 GB
Windows 2016 60 GB
Medium Windows 10 15 GB
Windows 2012 R2 40 GB
Windows 2016 60 GB
Heavy Windows 10 20 GB
Windows 2012 R2 40 GB
Windows 2016 60 GB

 

5. Storage IOPS

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

 Types of workloads

profile

Betriebssystem

Storage IOPS 

(ohne RAM-Based Cache)

Storage IOPS 

(mit RAM-Based Cache)

Light Windows 10 12 IOPS 12 IOPS
Windows 2012 R2 3 IOPS 0,5 IOPS
Windows 2016 4 IOPS 1 IOPS
Medium Windows 10 20 IOPS 1,5 IOPS
Windows 2012 R2 4 IOPS 0,5 IOPS
Windows 2016 6 IOPS 1 IOPS
Heavy Windows 10 35 IOPS 3 IOPS
Windows 2012 R2 5 IOPS 0,5 IOPS
Windows 2016 8 IOPS 1 IOPS

 

 

Systemanforderungen der Infrastruktur Server

Deliver 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).

Betriebsysteme vCPU vRAM Disk
Windows Server 2008 R2 Standard, Enterprise, Datacenter
Windows Server 2012 / 2012 R2 Standard und Datacenter
Windows Server 2016 Standard und Datacenter
4

5² GB

8³ GB

40 GB

 Ab Version 7.16 werden nur die Versionen 2012 R2 oder 2016 in Standard / Datacenter Edition unterstützt.

 ² in diesem Fall werden zwei weiteren Kernkomponenten (Studio, Director) auf einem separaten Server installiert.

 ³  in diesem Fall sind Studio und Director mitinstalliert.

 

 

StoreFront (Access Layer)

Die in der nachfolgenden Tabelle angegeben Werte haben sich bereits als optimal 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.

Betriebsysteme vCPU vRAM Disk
Windows Server 2008 R2* Standard, Enterprise, Datacenter
Windows Server 2012* / 2012 R2 Standard und Datacenter
Windows Server 2016 Standard und Datacenter
4 4 GB 60 GB
 * ab Version 7.16 werden nur die Versionen 2012 R2 oder 2016 in Standard / Datacenter Edition unterstützt

 

Lizenz Server (Control Layer)

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

Betriebsysteme vCPU vRAM Disk
Windows Server 2008 R2* Standard, Enterprise, Datacenter
Windows Server 2012* / 2012 R2 Standard und Datacenter
Windows Server 2016 Standard und Datacenter
2 2 GB 60 GB
 * ab Version 11.15 werden nur die Versionen 2012 R2 oder 2016 in Standard / Datacenter Edition unterstützt

 

 

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.

Komponente Betriebsystem vCPU vRAM Disk
Server Windows Server 2008 R2* Standard, Enterprise, Datacenter
Windows Server 2012* / 2012 R2 Standard und Datacenter
Windows Server 2016 Standard und Datacenter 
 2 4 GB   
Policy Console Windows Server 2008 R2* Standard, Enterprise, Datacenter
Windows Server 2012* / 2012 R2 Standard und Datacenter
Windows Server 2016 Standard und Datacenter 
 2  4 GB  
Player Windows 7 SP1, 8.1, 10²   2 ab 2 GB   
Database Microsoft SQL Server 2017 Express, Standard, Enterprise
Microsoft SQL Server 2016 SP1 Express, Standard, Enterprise
Microsoft SQL Server 2014 SP2 Express, Standard, Enterprise
Microsoft SQL Server 2012 SP3 Express, Standard, Enterprise
Microsoft SQL Server 2008 R2 SP3 Express, Standard, Enterprise
     
Agent

alle supportete Betriebssysteme

- - -

 * ab 7.16 nur 2012 R2 oder 2016 Standard oder Datacenter Editions

 ² Windows 10 Version 1809, 1803, 1709, 1703. Der Player kann auch auf einem Serverbetriebssystem installiert werden.

 

 

Workspace Environment Management

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

Komponente Betriebsystem vCPU vRAM Disk

Server (Infrastructure

service)

Windows Server 2008 R2* Standard, Enterprise, Datacenter
Windows Server 2012* / 2012 R2 Standard und Datacenter
Windows Server 2016 Standard und Datacenter 
 4 8 GB  80 MB 
Verwaltungskonsole Windows Server 2008 R2* Standard, Enterprise, Datacenter
Windows Server 2012* / 2012 R2 Standard und Datacenter
Windows Server 2016 Standard und Datacenter 
 2  2 GB 40 MB 
Agent

Kann auf jedem beliebigen Windows-Betriebssystem
(ab Vista SP2, Server ab 2008 SP2) installiert werden

- 10 MB

100 MB

* ab 7.16 nur 2012 R2 oder 2016 Standard oder Datacenter Editions

 

 

 

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. 
Betriebsystem RAM  vCPU  Disk C vDisk Storage
Windows Server 2008 R2 Standard, Enterprise, Datacenter
Windows Server 2012 / 2012 R2 Standard und Datacenter
Windows Server 2016 Standard und Datacenter
 8² GB 4-8³ 40 GB 40 - 100 GB
pro VDisk
 ² abhängig von der Anzahl der unterschiedlichen vDisks
 ³ abhängig von der Anzahl der gleichzeitig gesteamten VMs

 

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

Betriebsystem RAM  vCPU Disk C
Windows Server 2008 R2 / 2008 R SP1 Standard, Enterprise, Datacenter
Windows Server 2012 / 2012 R2  /2016 Standard und Datacenter
Windows 7, 8, 8.1 oder 10 (32- oder 64 -bit)
2 GB 2 500 MB

  

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

Advanced Server Properties Threads

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: 

 

 

 

Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden.
Ok