Performance-Gedanken beim Einsatz einer Virtual Desktop Infrastruktur

“Wenn ich Word starte, geht das bei mir am Laptop zuhause aber schneller.“

So oder so ähnliche Aussagen dürfte jeder, der sich beruflich mit der Bereitstellung von virtuellen Desktops auseinandersetzt schon einmal gehört haben. Besonders ärgerlich ist, dass der „gemeine User“ die filigrane Planungs- und Umsetzungsleistung die um seinen virtuellen Desktop und das darauf installiere „Word“ gar nicht wert-zuschätzen weiß.

Muss er auch nicht. Als User hat man eine subjektive Sicht und das ist auch gut so. Das ist ehrlicher als jeder Benchmark. Die Komplexität von „echter“ Arbeitslast innerhalb eines so komplexen Szenario wie VDI lässt sich nicht einfach messen wie der Stromverbrauch eines Bügeleisen´s.

Wochenlang wurde „gesized“ und mit vCPU, vRAM und vDisk gerechnet. Es wurde ein Konzept erarbeitet, dieses in einem Proof of Concept erfolgreich nachgewiesen, die Testphase mit einer Hand voll auserwählter User wurde mit Bravour abgeschlossen. Man hat an alles gedacht. Drucken, Speichern, Anmeldungen von intern und extern mittels SSL Verschlüsselung und Mehrfaktor Authentifizierung. Alle kritischen Hard- und Software-Komponenten sind ausfallsicher angeschafft und installiert worden. Doppelte Netzteile, gespiegeltes Storage, Backup zum zweiten Standort, ja sogar ein web-basierender Bestell-Prozess für temporäre VDI Test-Systeme wurde implementiert.

„The Future is now!“ 😉

Und dann das: Word startet langsamer als am heimischen Laptop. Oder mehr noch. Das arbeiten mit dem System “fühlt sich irgendwie nicht so schnell an”. Sachliche Ernüchterung steht dem Haus-Admin ins Gesicht geschrieben.

Wie kann das sein?

Selbst die Besten (und Teuersten) Last-Simulationen können nur einen ungefähren Wert der Leistungsfähigkeit einer VDI Umgebung abbilden. Als Ergebnis weis man dann, wie viele User parallel ihren virtuellen Desktop starten können (Boot-Storm), wie viele User sich parallel an ihrem virtuellen Desktop anmelden können (Logon-Storm) und wie viele User gleichzeitig Drucken können (Print-Storm??). Diese Werte können als Schätzung für ein Sizing herbeigezogen werden, mehr aber auch nicht. Die gemessenen Aufruf-Zeiten für das Ausführen von Word, sind mit großer Sicherheit in einem durchaus akzeptablen Rahmen der das Arbeiten innerhalb der Umgebung auch nicht zu einer ewigen Kaffeepause verkommen lassen würde und wäre im Vergleich zu einem 15 Jahre alten Windows XP System auch um längen schneller.

 Aber wieso ist der 1 Jahr alte, 400€ Heimcomputer schneller??

Zum Teil können wir uns dazu bei den Herstellern der aktuellen Computerhardware für den Consumer-Markt “bedanken”. Diese haben die Frechheit besessen, den aktuelle Standard auf vor Jahren noch undenkbare Werte zu heben.

4 Kern CPU mit 4 x 2,5GHz, 8 GB Arbeitsspeicher, SSD

Man darf sicherlich sagen, dass für einen normalen Office-Worker (Mails, Textverarbeitung und Surfen) ein solcher Hardware-Unterbau absolut oversized ist. Word öffnet damit noch schneller als auf einer VDI Umgebung mit Enterprise-Hardware. Aber wieso ist das eigentlich so?

Die Geschwindigkeit beim initialen Öffnen von Programmen ist grundsätzlich abhängig von 2 Komponenten: CPU und Festplatte.

User Klickt Word an > CPU sagt Festplatte was sie holen soll > Festplatte liefert Daten und schmeißt sie in den RAM. Von jetzt an kann die CPU die Daten aus dem RAM laden, ohne auf die Festplatte zu warten.

Ist die CPU das Problem?

Vergleicht man die CPUs wird man feststellen, dass der VDI für Officeworker meistens mit 2 vCPUs ausgestattet ist. Da das Sizing für die vCPUs vom VDI Consultant auch mit Overcommitment im CPU Bereich geplant wurde, könnte man vermuten, dass es durch das Zugreifen mehrere User auf die gleiche CPU zu Performance Einbrüchen kommen kann. Dies kommt jedoch in den seltensten Fällen vor und würde sich nicht auf den initialen Startvorgang von “Word” alleine auswirken. Das CPU-Sharing zwischen mehreren virtuellen Maschinen wird vom Hypervisor geregelt und funktioniert im Normalfall hervorragend.

Das sämtliche VMs zeitgleich CPU-Rechenzyklen beanspruchen, wodurch das Overcommitment zum Problem wird, kommt in den meisten Fällen nur von einer nicht beachteten Software-Konfiguration wie bspw. einem Virenscanner der auf allen Systemen Zeitgleich um 12.30 Uhr anspringt, oder als zweites Beispiel bei Software-Telefonie oder anderen Echtzeit-Audio oder Video Formaten, da der Codec über die vCPU in Echtzeit die Konvertierung durchführen muss, damit es keine Verzögerungen bei Sprache und Bild mit dem Gegenüber gibt. (kann man auch an der CPU des Hypervisors vorbei berechnen lassen, Stichtwort vGPU, aber das würde hier den Rahmen sprengen)

Also doch die Festplatte?

Es bleibt noch die Festplatte als schuldiges Medium. Moderne Storage-Systeme bringen eine Menge Power. Diese Power wird dann natürlich unter allen darauf zugreifende User aufgeteilt. Im Gegensatz dazu hat der User in seinem Laptop eine SSD und die Schnittstelle der SSD für sich allein. Diese ist ohne Probleme in der Lage zwischen 500 MB bis 2 GB pro Sekunde zu Lesen und auch zu Schreiben (Linear oder Random – wird weiter unten erläutert). Da immer mehr SSDs mit M2 Schnittstelle verbaut werden, setzt hier lediglich die Schnittstelle (SATA / PCI-Express) die Grenze des Möglichen. Auch da kommen immer neue und schnellere Standards und damit auch Geschwindigkeiten in Consumer-Endgeräten zum Einsatz.

SchnittstelleBrutto-Datenrate in Gigabit pro SekundeBrutto-Datenrate in Gigabyte pro Sekunde
SATA Revision 2.060,750*1
M2 mit Anbindung an PCIe 2.0 x4162,000*2
M2 mit Anbindung an PCIe 3.0 x431,53,938*2
M2 mit Anbindung an PCIe 4.0 x4 (2017 erwartet)63(!!)7,877*2

Im Enterprise Segment hält man da mit 40 Gigabit (auch 100 GBit*3 ist theoretisch möglich: Stichwort FCoE) Anbindungen dagegen, welche man dann auch auf 2, 4 oder mehr Pfade (parallele Anschlüsse) verteilt und damit auch Datendurchsatz-Raten jenseits der 160 Gigabit (20 Gigabyte) erhält.

Nicht zu vergessen ist: Diese teilen sich dann alle User. Bedeutet, ein einzelner Nutzer würde die volle Power der Enterprise Infrastruktur spüren. Sollten jedoch 500 oder mehr User gleichzeitig damit arbeiten wird ähnlich wie bei den CPUs eine gewisse Einschränkung durch die Aufteilung der Datenraten zu spüren sein.

*1) https://de.wikipedia.org/wiki/PCI_Express
*2) https://de.wikipedia.org/wiki/Serial_ATA#Serial_ATA_6.2C0_Gbit.2Fs
*3) https://en.wikipedia.org/wiki/100_Gigabit_Ethernet

Also müssen wir an der Storage-Performance der VDI optimieren?

Ja.

Also müssen wir immense Kosten für die Storage Infrastruktur in Kauf nehmen, um eine vergleichbare Performance bereitzustellen?

Nein.

Es gibt ein Medium welches noch schneller ist: RAM.

Zur selben Zeit in der ich den Artikel schreibe, ist der RAM Preis für das “laufende Gigabyte” sicherlich wieder gefallen. Der Server-Standard liegt bei 256 GB Tendenz steigend!

Brauchen wir nur das passende Stück Software, welches diese Vorteile für ein Windows System nutzbar macht: Citrix Provisioning Services

Mittels Citrix Provisioning Services stellt man VDI-Worker bereit, die aus dem RAM der Provisioning Server booten, Programme öffnen, und in den RAM der Hypervisor ablegen, ohne das ein Byte auf einen Datenträger geschrieben werden muss. Auf dem Weg zwischen Provisioning Server und Worker befindet sich nichts, außer Netzwerk. Die Provisioning Server (mindestens 2) laufen dabei auch als virtuelle Maschine auf den gleichen Hosts wie die Worker, die sie bereitstellen. Das „Streaming“ der Worker erfolgt damit über den internen Switch des Hypervisors. (Ja, das ist schnell.  Sehr schnell!)

Wieso ist das so schnell?

Performance von Storage wird am ehesten in IOPS (Schreib-Lese-Vorgänge pro Sekunde) bemessen. Dazu eine einfache Rechnung.

IOPS = [1/(Latenz + HDD-Schreib/Lesekopf Platzierungs-Verzögerung)] * 1000

Eine (neue) 7.200 UPM SATA Festplatte: IOPS = [1/(8,9ms)] * 1000 = 112 IOPS *1
Eine (neue) 10.000 UPM SAS Festplatte: IOPS = [1/(4,2ms)] * 1000 = 238 IOPS *1

(Es werden Mittelwerte handelsüblicher Festplattentypen dieser Kategorie verwendet.)

Dann muss noch Zwischen Brutto und Netto unterschieden werden (wie immer), da es Unterschiede zwischen Lese-IOPS und Schreib-IOPS gibt. Summa Sumarum sind die berechneten Werte oben im „Feld“ nicht ansetzbar. Realistische Werte liegen bei den 7200er SATA Festplatten um die 90 IOPS, die SAS Festplatten haben um die 140 IOPS. Das Alter der Festplatten spielt dabei ebenso eine Rolle. Die Mechanik der Lese/Schreib-Arme nutzt ab. Das sind zwar nur ein paar Millisekunden Verlust, jedoch gehören Millisekunden zur wichtigsten Einheit bei der Berechnung von Durchsatzwerten jeglicher Art.

Wie man jetzt die RAID-Level und deren Einbußen durch mehrfache Schreibvorgänge berechnet, möchte ich hier nicht weiter aufzeigen, es gilt nur zu wissen dass durch eine Erhöhung der Redundanzen auch eine Erhöhung der Schreibvorgänge stattfindet, was auch eine “Bestrafung” der maximalen IOPS zur folge hat. (Stichwort: RAID-Penalty)

Wichtig sind zwei Erkenntnisse im VDI Umfeld:

  1. Random IOPS (Dynamische Schreib-Lese-Vorgänge pro Sekunde) = Böse!
  2. VDI = Hochgradige Random Write IOPS (85% Schreib- zu 15% Lese-Vorgängen sind bei VDI realistisch)

Bedeutet das, VDI = Böse?

Natürlich nicht!

Random IOPS kennen wir alle. Um sie zu vermeiden mussten wir früher noch unsere Festplatten defragmentieren. Die Fragmentierung der Festplatten war schuld, das der Schreib/Lesekopf sich immer wieder neu positionieren musste um eine Datei zu lesen oder zu schreiben. Und Je fragmentierter eine Datei war, desto langsamer wurde der Schreib- und Lese-Prozess und damit das gesamte System. Diesen Effekt haben SSDs eliminiert. Es gibt keinen mechanischen Lese- Schreib-Kopf mehr. Random IOPS von Consumer SSDs sind mit 50.000 IOPS bis 100.000 IOPS realistisch angegeben.

Da drängt sich zwangsläufig die Frage auf: Wie konnten wir es nur so lange mit mechanischen Festplatten aushalten?!

Wieso jetzt aber RAM?

Aktueller RAM liegt jenseits der 5.000.000 IOPS, je nach CPU-Ausstattung und RAM Typ des Servers, denn die Adressierung der Speicherplätze im RAM wird durch die CPU durchgeführt. Dementsprechend verschiebt sich damit dann doch wieder unser Augenmerk auf die Leistungsfähigkeit der CPU des Hosts.

Abbildung 1 zeigt einen IOPS Benchmark auf einer DDR4-RAM Disk
Abbildung 2 zeigt einen IOPS Benchmark auf einer SATA2 SSD
Abbildung 3 zeigt einen IOPS Benchmark auf einer m2 SSD an PCI-e 2.0 x4

 

 

Aber wie ist das mit Citrix Provisioning Services?

Da die Leseprozesse über Netzwerk (Provisioning = UDP) laufen, muss auch da eine Berechnung der IOPS erfolgen. Netzwerk (Host Only) mit extrem geringen Latenzen (um die 0,01 ms) erreichen dabei also Werte um die 100.000 IOPS (pro Provisioning Server und pro virtuellen-Adapter, wohlgemerkt). Beim Schreiben der Daten des Workers (die Gewichtung liegt bei ungefähr 85% Schreiben zu 15% Lesen) spielt der WriteCache des Workers im RAM seine Stärken aus. Jeder virtuelle Worker kann dabei direkt auf den RAM des Hypervisors zugreifen. Die Latenzen bei DDR4-RAM Zugriffen befinden sich im 50 Nanosekunden Bereich. (um die 0,000050 Millisekunden) Im Idealfall reserviert man den kompletten Arbeitsspeicher des Worker am Hypervisor, womit zwar ein Overcommitment nicht möglich ist, was sich jedoch problemlos messen und zu Sizing-Zwecke berechnen lässt.

Abbildung 4

 

Abbildung 4 zeigt das Laufwerk C eines VDI Workers mit aktivem RAM WriteCache. Der WriteCache-Überlauf liegt auf Laufwerk D. Die IOPS werden zum RAM geleitet.

Abbildung 5

Abbildung 5 zeigt das Laufwerk D eines VDI Workers. Laufwerk D ist der Überlauf und ein angebundenes Storage. Die IOPS werden direkt an das Storage geleitet und spiegel wieder, wieviele IOPS das System normalerweise für alle Worker zusammen zu Verfügung stellen könnte, gäbe es den RAM Cache nicht. In diesem Fall vergrößert sich die Random-Write-Performance um das 47-fache(!!), durch Verwendung des RAM-Caches.

Aber… Es gibt auch schnelles Storage!

Ja, es gibt auch Storage-Systeme die mit nahezu unbegrenzten IOPS auffahren. Werte von 11 Millionen IOPS und mehr sind damit möglich. Auch da wird RAM als vorgelagertes Caching (Auto-Tiering Level 0) verwendet, bevor die Daten dann auf die angebundenen SSDs (Auto-Tiering-Level-1) weggeschrieben werden. Das erfordert jedoch zusätzlich eine Investition in die Backend-Infrastrukturen (Anbindung des Storage an die Hypervisor) und die Anschaffungskosten des Storage selber sind auch nicht zu verachten.

Zwei Argumente gegen eine VDI Lösung mit eigenständigen Storage sind:

Die Skalierbarkeit:

Erweitere ich meine Umgebung um einen weiteren Host, erhöhe ich meine Anzahl an CPUs und RAM. Ich erhöhe nicht die Performance meiner Server- Blade- oder SAN-Switche. Auch die IOPS meines Storage bleiben identisch.
Einzig ein Nachrüsten der Connection zwischen SAN und Host, sowie nachrüsten des Storages selber würden mehr Performance bieten. (Scale-Up)

Wie mache ich es dann?

Sorge doch dafür, dass alle Komponenten des Hosts für die darauf befindlichen Worker verwendet werden. Skaliere dadurch mit jedem zusätzlichen Host sowohl CPU und RAM als auch Storage-(Größe und Performance) für die VDI horizontal. (Scale-Out)

Dieses Argument ist auch ein Grund für die stark wachsende Nachfrage an „Converged Infrastrukture“.

Die Kosten:

Auch bei den Kosten tritt eine VDI Strategie in Konkurrenz zur klassischen Fat-Client Strategie. Ein (wie oben beschriebener Office) Worker PC ist oftmals nicht wesentlich teurer wie ein guter ThinClient(+ Lizenzkosten etc.pp).

Der Verwaltungsaufwand muss dabei natürlich besonders hervorgehoben werden und darf bei einer Kostenrechnung nicht fehlen. Bei der VDI Strategie kann man mit Argumenten wie der Hochverfügbarkeit oder schnellen Austauschbarkeit der Client´s sowie eine durchweg zentralen Datenhaltung punkten. Ein sauberer Vergleich muss alle anfallenden Kosten und Optionen mit einbeziehen. Ein Fat-Client mit RAID aus Enterprise-SSDs, zwei Netzteilen und zwei Netzwerkkarten wird preislich sicherlich weit über dem ThinClient liegen.

Bleibt die Frage: Benötige ich das? Muss mein Office-Worker diese hohen Verfügbarkeiten vorweisen? Benötige ich für die Laufzeitumgebung meiner VDI Worker ein Enterprise Storage? Die Auslagerungsdatei meines Windows 10 VDI auf einem Enterprise SSD Storage? Perlen vor die Säue? 😉 Wieso sollte man die IOPS nicht irgendwo „einschlagen“ lassen, wo es billig ist und schnell?

Der RAM wird doch bei einem Neustart geleert?

Ja. Deswegen müssen alle vom User erzeugten Daten und Dokumente beim Abmelden (oder auch schon während der Arbeitszeit) weggeschrieben werden. Dementsprechend muss ein intelligentes User Profil Management in die Konzeption einfließen. Dabei ist zu beachten, dass man sich kein neues Nadelöhr baut.

Das User Profile Management ist die Achillesferse einer jeden VDI-Lösung.

Geht es auch so, wie beschrieben, nur mit SSD anstatt des RAM?

Ja. Der WriteCache der Worker kann dank Provisioning Services irgendwo liegen. Irgendwo bedeutet auch, ein RAID aus 2, 3 oder mehr SSDs im Host. Damit kann die benötigte RAM-Größe etwas kleiner Dimensioniert werden. Pro Worker 100MB bspw. Diese 100MB werden als „Tier-Level-0“ verwendet. Das bedeutet, dass jeder Schreibvorgang (wir sind wieder bei den IOPS) erstmal in den RAM greift. Im RAM werden die Vorgänge gesammelt und linearisiert. Ist der linearisierte Datenblock größer als 100MB, wird der Überlauf auf die im Host verbauten SSDs (Tier-Level-1) geschrieben. (So machen das gute Storage-Systeme auch, um der Random-IOPS Herr zu werden.)

Geht das noch günstiger?

 Ja! Dimensioniere ich den WriteCache so, dass mein Tier-Level-0 (RAM) nie überläuft, kann ich auch mit “langsamen” herkömmlichen SAS Festplatten den WriteCache realisieren. Dabei muss die Mehrinvestition in den Arbeitsspeicher des Hosts gegen die Mehrinvestition in die SSDs im Host gegengerechnet werden.

Auch da müssen jedoch nach dem Abmelden die User-Daten auf einen externen Fileserver abgelegt werden und es bedarf einer Proaktiven Monitoring-Lösung, die den WriteCache im Auge behält. Wenn dieser nämlich doch auf die Festplatten ausgelagert wird, verschlechtert sich die Performance deutlich.

Fazit: Man kann mit einer VDI auch weiterhin gegen den heimischen Laptop antreten und gewinnen. Das Augenmerk sollte dabei auf der einzusetzenden Infrastruktur liegen. Je optimierter diese für den Einsatzzweck VDI ist, desto performanter und zeitgleich kostenschonender kann man virtuelle Arbeitsplätze bereitstellen.

Veröffentlicht von

Christian

Mit den Fachgebieten Virtualisierung und Citrix arbeite ich als Pricipal Consultant bei Axians IT Solutions GmbH in Deutschland.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.