White paper Sizing of Virtual Desktop Infrastructures
Page 3 of 32 ts.fujitsu.com
Einleitung Die folgenden Inhalte sollen zum besseren Verständnis zu den Anforderungen an eine virtuelle Desktop-Infrastruktur (VDI) dienen. Ein besonderer Fokus liegt hierbei neben CPU und Arbeitsspeicher (RAM) Anforderungen insbesondere auf den Anforderungen an das Storage Subsystem. Anforderungen an Netzwerk und Bandbreiten sind nicht Bestandteil dieses Whitepapers. Die Ergebnisse können als Grundlage für das Sizing einer entsprechenden VDI Umgebung auf Basis von Citrix XenDesktop 4 / 5 bzw. VMware View 4.5 / 4.6 / 51 herangezogen werden. Um eine möglichst effiziente VDI Lösung anzubieten, ist es wichtig die drei Ressourcen CPU, RAM und Disk-IO bestmöglich aufeinander abzustimmen. Ist eine der Komponenten unterdimensioniert, so ist eine optimale Nutzung der Ressourcen nicht mehr möglich. In heutigen VDI Umgebungen ist meist die Disk-IO der begrenzende Faktor. An zweiter Stelle folgt der RAM als möglicher Engpass. Die CPU Ressource ist in heutigen VDI Architekturen in der Regel nicht der begrenzende Faktor – wird jedoch häufig fälschlicherweise als solcher identifiziert. Der Grund dafür liegt auch in der Art und Weise wie die Ressource CPU in Verwaltungskonsolen angezeigt wird. Meist wird hier die Auslastung der CPU angezeigt. Es fehlt jedoch die Unterscheidung von tatsächlich durchgeführten Rechenzyklen und Wartezyklen (sogenannte Wait States). In heutigen VDI Szenarien liegt der Prozentsatz der tatsächlichen Rechenarbeit der CPU typischerweise bei deutlich unter 10%. Die restlichen 90% der verfügbaren CPU Leistung werden mit „Warten― z.B. auf Lesevorgänge einer Festplatte, verbracht. Die Auslastungsanzeige der CPU der Verwaltungstools (z.B. VMware vCenter Performance, Citrix XenCenter Performance) zeigt in diesen Fällen 100% CPU Auslastung an, da die CPU ja keine weiteren Aufträge mehr annehmen kann. Wartezyklen treten in virtuellen Infrastrukturen besonders massiv zu Tage, da mehrere virtuelle Maschinen mit multiplen Betriebssystemen deutlich mehr Wartezyklen erzeugen als ein einziges physisches System mit nur einem Betriebssystem. Sowohl physische, als auch virtuelle Systeme kämpfen allerdings grundsätzlich mit der großen Leistungsdiskrepanz von CPU (schnellste Ressource), Arbeitsspeicher (zweitschnellste Ressource) und Storage (langsamste Ressource). Da ist es nicht verwunderlich, dass ungünstig dimensionierte Arbeitsspeicher und/oder zu geringe Performance eines Storage Subsystems (Disk-IO) die häufigsten Gründe für eine erhöhte Anzahl an Wartezyklen auf CPU Seite sind. Dies verhindert eine optimale Ausnutzung der vorhandenen Ressourcen der virtuellen Infrastruktur.
■ Die Anfragen, hier als Regentropfen dargestellt, füllen die
Warteschlangen der jeweiligen Ressourcen – visualisiert als Behälter.
■ Ist eine Ressource wie. z.B. Disk-IO gesättigt, füllen sich automatisch die verbleibenden noch freien Ressourcen zusätzlich, es entstehen Warte-Zyklen.
■ Letztendlich wird die CPU bis zur Sättigungsgrenze immer weiter gefüllt. Sobald die CPU die Aufträge nicht mehr entgegen nehmen kann, entsteht ein Stau, bei dem meist auf „langsamere― Ressourcen gewartet wird. Ist dieser Zustand einmal erreicht, kann man meist nur noch indirekt feststellen, wer ursächlich dafür verantwortlich ist.
Abbildung 1: Abhängigkeiten von CPU, RAM und Storage
1 ab VMware View 5 wird es voraussichtlich die Möglichkeit geben, die Replica-Disk bei Linked Clones im RAM des vSphere 5.0 Hypervisor Server zu hinterlegen. Dies führt zu deutlich geringeren Read IOPS auf SAN-Seite. Nutzt man diese Option nicht, werden die Anforderungen an das SAN auch bei View 5 voraussichtlich vergleichbar bleiben.
RAM
CPU
DISK-IO
White paper Sizing of Virtual Desktop Infrastructures
Page 4 of 32 ts.fujitsu.com
Verwendung von Begriffen und Namen Für Hinweise und weitere Informationen zu bestimmten Produkten oder Herstellern im Fließtext wurden Hyperlinks in Form von Fußnoten eingefügt. Erklärungen zu immer wieder vorkommenden Abkürzungen oder Begriffen wurden im Anhang hinterlegt, zusammen mit einem Hyperlink auf den Quelltext. Die Abkürzungen und Begriffe wurden beim ersten Erscheinen im Fließtext mit einem Hyperlink auf das Glossar versehen. Zur besseren Lesbarkeit werden die Marken- und Handelsnamen im weiteren Textverlauf meist abgekürzt:
Die von Microsoft eingetragenen Markennamen können auf folgender Website nachgelesen werden: http://www.microsoft.com/library/toolbar/3.0/trademarks/de-de.mspx.
Die von Citrix registrierten Marken sowie die Regeln zur korrekten Bezeichnung sind auf folgender Website zu finden: http://www.citrix.com/English/aboutCitrix/legal/secondLevel.asp?level2ID=2210.
Von Cisco registrierte Marken sind auf folgender Website zu finden: http://www.cisco.com/web/siteassets/legal/trademark.html.
Alle weiteren im Dokument erwähnten Produkte sind Markennamen der jeweiligen Hersteller. Aufgabenstellung ■ Entwicklung und Aufbau eines POC (Proof-of-Concept), um auf virtuellen Clients (vClients) die Betriebslast,
die durch Standard-Anwender entsteht, simulieren zu können. ■ Vergleich der Technologien VMware „Linked Clone― und Citrix "XenDesktop / Provisioning". ■ Erstellung einer Entscheidungsmatrix und Verfassen einer fundierten Empfehlung zur Weiterführung der geeigneten Technologie. ■ Erstellung einer Testdokumentation Bei der Durchführung der Lastmessungen wurde berücksichtigt: ■ Die Lastsimulation soll zum einen über übliche Lastsimulationsprogramme durchgeführt werden, zum anderen die Vergleichbarkeit mit
ermittelten Werten von Herstellern zulassen. ■ Für Vergleichbarkeit soll die Basisumgebung gleich gehalten sein, sowie spezielle Optimierungen vermieden werden.
White paper Sizing of Virtual Desktop Infrastructures
Page 5 of 32 ts.fujitsu.com
Marktbetrachtung und Produktauswahl Als Grundlage für das Ergebnisdokument wurden folgende Hypervisor und Management-Lösungen: ■ Citrix XenServer 5.6 und XenCenter 5.6 ■ VMware ESX vSphere 4.1 und vCenter 4.1 2 Als Grundlage für die Auswahl der Produkte / Hersteller dienten Informationen, die von dem Marktforschungsinstitut Gartner (Stand Mai 2010; ersetzt durch aktualisierte Abbildung mit Stand Juni 2011) zur Verfügung gestellt wurden.
Abbildung 2: Marktpositionierung Hypervisor (nach Gartner) Demnach gehören oben genannte Produkte der Hersteller VMware, Microsoft und Citrix zu den drei ausgereiftesten und am meisten etablierten Bare-Metal-Hypervisor-Produkten für x86-Servervirtualisierung. Ferner basieren die zu virtualisierenden Betriebssysteme innerhalb der Messungen auf Windows, mit Fokus auf Windows 7 (x64) und Windows Server 2008 R2 (x64). Die drei oben genannten Hypervisor-Produkte der Hersteller Citrix, Microsoft und VMware wurden innerhalb des Paketes um Desktopvirtualisierungprodukte erweitert. Da Microsoft bei größeren Umgebungen (> 500 Clients) ebenfalls die Citrix-Komponenten für Brokering und Provisionierung empfiehlt, wurde aus Zeitgründen auf parallele Tests mit Hyper-V 2.0 verzichtet. Einzelne Messungen auf einer anderen Hardware-Basis zeigten vergleichbare Ergebnisse des XenServer 5.6 mit Hyper-V 2.0. Folgende Kombinationen wurden dabei – gemäß Hersteller-Empfehlungen – eingesetzt:
Citrix XenDesktop 4 (VDI-Komponente) und Citrix XenServer 5.6 (Hypervisor) VMware View v4.5 (VDI-Komponente) und VMware ESX vSphere 4.1 (Hypervisor)
Details zum konkreten Testaufbau siehe auch Kapitel „Schematischer Aufbau der Lasttestumgebung―
White paper Sizing of Virtual Desktop Infrastructures
Page 6 of 32 ts.fujitsu.com
Technologie-Beschreibung Hypervisorkomponenten und - funktionen Citrix XenServer 5.6 Nach Angaben von Citrix ist "Citrix® XenServer® die einzige Cloud-fähige Server-Virtualisierungsplattform für Unternehmen jeder Größe, die alle wichtigen Funktionen zur Virtualisierung aller Server und Rechenzentren bietet — Skalierbarkeit für unterschiedliche Unternehmensgrößen, Unterstützung von Windows® und Linux-Betriebssystemen und komplexen Storage-Anforderungen, zentralisiertes Management mehrerer Server, Live-Migration virtueller Maschinen und vieles mehr. Ganz gleich, für welche XenServer-Edition Sie sich als Ausgangsbasis entscheiden, die verschiedenen Editionen sind alle miteinander kompatibel. Upgrades können einfach über Eingabe eines neuen Lizenzschlüssels erfolgen, ohne dass zusätzliche Software installiert oder Systeme außer Betrieb genommen werden müssen. Die Preisgestaltung für XenServer erfolgt pro Server."
Funktion Free Advanced Enterprise Platinum
Free virtual infrastructure
XenServer hypervisor
XenMotion® live migration
VM Disk Snapshot and Revert
XenCenter multi-server management
Resilient distributed management architecture
Conversion tools
Advanced management and automation
High availability
Memory optimization
Performance alerting and reporting
Automated workload balancing
Heterogeneous pools
Host power management
Provisioning services (virtual)
Role-based administration
Live memory snapshots and reverts
Citrix® StorageLink
Lifecycle mananement
Provisioning services (physical)
Site recovery
Tabelle 1: XenServer Editionen
White paper Sizing of Virtual Desktop Infrastructures
Page 7 of 32 ts.fujitsu.com
VMware vSphere 4.1 Laut Herstellerangaben umfasst „VMware vSphere eine Reihe von Komponenten, mit denen Industriestandard-Hardware quasi wie eine flexible Mainframe- Umgebung mit integrierter Service-Level-Kontrolle für alle Anwendungen genutzt werden kann. Die Komponenten von VMware vSphere sind in folgende Kategorien unterteilt: Infrastruktur-Services - Diese Komponentengruppe virtualisiert Server-, Storage- und Netzwerk-Ressourcen umfassend, bündelt diese und ordnet sie Anwendungen nach Bedarf und geschäftlicher Priorität zu. Anwendungs-Services - Diese Komponentengruppe bietet integrierte Service-Level-Kontrollen für alle Anwendungen auf der Plattform des Cloud-Betriebssystems, unabhängig vom Anwendungstyp oder verwendeten Betriebssystem. VMware vCenter Server stellt einen zentralen Kontrollpunkt für das Virtualisierungs-Management bereit. Dies ist eine wichtige Komponente zur Verwaltung von Infrastruktur und Anwendungs-Services, die einen detaillierten Einblick in alle Aspekte der virtuellen Infrastruktur, Automatisierung täglicher Betriebsabläufe und die nötige Skalierbarkeit für das Management großer Rechenzentrumsumgebungen bieten.―
Abbildung 3: Schematischer Überblick zum Hypervisor VMware vSphere 4.1
White paper Sizing of Virtual Desktop Infrastructures
Page 8 of 32 ts.fujitsu.com
Funktionen der Desktopvirtualisierungslösung Citrix XenDesktop 43 Citrix ist mit XenDesktop in der Lage, unterschiedliche Typen zentraler, virtualisierter Arbeitsplätze vorzuhalten. Damit bietet das Bereitstellungskonzept von Citrix eine sehr große Bandbreite an möglichen Einsatzszenarien, um virtuelle Desktops bereitstellen. Die Einsatzszenarien von XenDesktop im Überblick: Hosted Shared Desktop: Dieser Desktop ist vor allem auf die Bedürfnisse der so genannten „Task Worker― ausgerichtet. Diese Anwender installieren keine Programme eigenständig und kommen mit relativ wenig Rechenleistung aus. Hosted Shared Desktops werden auf Terminalserverfarmen bereitgestellt. Hosted Virtual Desktop: Diese Lösung ist für Anwendergruppen, die Spezialsoftware nutzen oder neue Programme installieren, gemacht (z.B. Entwickler). Der Desktop befindet sich als vClient dauerhaft auf einem Hypervisor und wird nicht dynamisch erzeugt und verworfen. Hosted Central Desktop: Kommt der Hosted Central Desktop Hochleistungs-Desktop zum Einsatz, greift der Nutzer auf eine eigene physikalische Hardware (z.B. Workstation) im Rechenzentrum zurück. Diese Variante adressiert in der Regel „Power User―, deren Aufgaben nach besonders großer CPU-Leistung verlangen. Local Streamed Desktop: Ein oder mehrere Citrix Provisioning Server (PvS) streamen einzelne, mehrfach nutzbare Standard-Desktop-Images (vDisks) auf die physischen oder virtuellen Rechner der Anwender. Der Bootvorgang geschieht über das Netzwerk. Über Provisioning Server kann nach der einmaligen Erstellung eines Master-Images eine theoretisch unbegrenzte Zahl an Desktops mit virtualisierten Festplatten beliefert werden. Die Rechenleistung selbst wird bei dieser Variante nach wie vor vom Client-Gerät geliefert. Ideal für Unternehmen, deren Anwender absolut identisch konfigurierte PC-Arbeitsplätze benötigen. Zusätzliche Flexibilität liefert die Trennung von Betriebssystem und Anwendungsebene: Hier beliefert XenApp als eigenständige Einheit die über XenDesktop zentralisierten Desktops mit Anwendungen. Grundsätzlich hat der Administrator die Wahl, ob die Anwendungen fest im Betriebssystem enthalten oder über XenApp virtualisiert oder gestreamt bereitgestellt werden sollen. VMware View 4.5 VMware folgenden Lösungsvarianten an: Automated Pool: Ein automatisierter Pool enthält einen oder mehrere virtuelle Desktops, welche automatisch durch den View Manager erstellt und angepasst werden. Diese Maschinen basieren auf einem Template, welches im Virtual Center Server verwaltet wird. Die Zugriffssteuerung erfolgt ebenfalls über den View Client. Bei automatisierten Desktops kann zwischen persistenten (dedicated) und nicht persistenten (floating) Desktops unterschieden werden. Bei persistenten Desktops wird der Anwender automatisch einem bestimmten vClient zugeordnet. Bei nicht persistenten Desktops erhält der Anwender irgendeinen der verfügbaren Desktops. Dies kann bei jeder Anmeldung ein anderer vClient sein. Bei automatisierten Desktop-Pools können sogenannte ―Linked Clones‖ verwendet werden. Ein "Linked Clone" ist eine spezielle Variante des normalen Clones. Der normale "Full Clone" ist die komplette Kopie einer virtuellen Maschine und ist vollkommen eigenständig. Ein "Linked Clone" ist ein Verweis auf einen existierenden vClient - das sogenannte Master-Image - und nimmt dadurch deutlich weniger Plattenplatz in Anspruch als ein "Full Clone". Dies bedeutet allerdings auch, dass der "Linked Clone" immer vom Master-Image abhängig ist und dieses zur Verfügung stehen muss. Der komplette vClient wird durch den Betrieb eines "Linked Clone" nicht verändert, es genügen also im Betrieb Leserechte auf das Master-Image. Die notwendigen Schreibvorgänge erfolgen im Verzeichnis des "Linked-Clone". Nach der Erzeugung wird jeder "Linked Clone" eigenständig gestartet und verhält sich dann im Betrieb wie ein eigenständiger vClient.
White paper Sizing of Virtual Desktop Infrastructures
Page 9 of 32 ts.fujitsu.com
Manual Pool: Ein manueller Desktop-Pool besteht aus einer Mischung von virtuellen und physikalischen Desktops. Diese Desktops können sich grundsätzlich unterscheiden und basieren nicht auf einem einheitlichen Ursprungsimage. Dafür erfolgt die Verwaltung bzw. die Zugriffssteuerung über den View Client. Auch bei den manuellen Desktop-Pools kann zwischen persistenten (dedicated) und nicht persistenten (floating) Desktops unterschieden werden. Somit erhält man hier eine Mischung aus individuellen und automatisierten Pools auf unterschiedlicher Ursprungsbasis. Terminal Services Pool: Hierbei handelt es sich um auf Microsoft Terminal Diensten basierende Systeme, welche ebenfalls vom View Manager verwaltet werden können. Diese Art von Desktop-Pools wurde im Test nicht betrachtet. Seitens VMware können Applikationen entweder direkt im Basisimage der virtuellen Maschine oder des Templates enthalten sein. Alternativ können Anwendungen auch über Terminal-Services oder via ThinApp (Applikationsvirtualisierung) bereit gestellt werden. ThinApp bietet hierbei eine durchaus attraktive Lösungsmöglichkeit. Diese ist aber im derzeitigen Status im Hinblick auf das Management der Applikationen und die Verteilung eher unpraktisch. Es gibt keine Management-Konsole oder etwas vergleichbares, durch welche es dem Administrator ermöglicht wird, die Applikationen zentral oder automatisiert an bestimmte Anwender zu verteilen. Lösungen für dieses Problem müssen derzeit noch manuell über andere Wege, bspw. via Scripting, bereitgestellt werden. Beschreibung der Lasttest-Infrastruktur Schematischer Aufbau der Lasttestumgebung
Abbildung 4: Schematischer Aufbau Auf Cluster #1 wurden alle Infrastruktur-Server gehostet, um eine mögliche Beeinflussung auf die Lasttests zu minimieren. Hierbei wurde der im Rahmen von vorangehenden Tests aufgesetzte vSphere 4.0 ESX-Host mit separatem vCenter (vCenter 4.0) weitergenutzt. Für die Lasttest-Messungen der VMs wurde lediglich ein Server mit VMware vSphere 4.1 als Hypervisor für die VMware View Tests bzw. ein Server mit XenServer 5.6 FP1 als Hypervisor für die XenDesktop Tests eingesetzt. Um die Leistungsfähigkeit der Citrix-Lösung voll auszunutzen, wurde zusätzlich ein physischer Provisioning Server in Betrieb genommen. Details siehe auch Tabelle 2 – Infrastruktur-Server.
White paper Sizing of Virtual Desktop Infrastructures
Page 10 of 32 ts.fujitsu.com
Beschreibung des Lasttest-Tools Um vergleichbare Ergebnisse der unterschiedlichen Technologien zu erzielen, ist es notwendig, ein möglichst unabhängiges Tool zur Erzeugung/Simulation anwenderähnlicher Belastungssituationen einzusetzen. In diesem Zusammenhang entschied man sich daher für das Tool VSI Pro der Firma Login Consultants. VSI Pro unterstützte zum Testzeitpunkt als einzig bekanntes Tool alle drei zu testenden Hypervisor-Technologien Citrix XenServer, VMware ESX und Microsoft Hyper-V 2.0. Außerdem bietet VSI Pro zahlreiche Zugriffsmöglichkeiten, so dass neben dem RDP-Protokoll auch z.B. das ICA-Protokoll eingesetzt werden kann. Die Last kann wahlweise direkt auf einem oder mehreren Zielen erzeugt werden. Hierbei bleibt anzumerken, dass VSI Pro lediglich den Verbindungsaufbau über unterschiedliche Protokolle aufbaut und den Lasttest initiiert. Die eigentliche Betriebslast wird dann lokal auf dem Test-Zielsystem erzeugt. Zusätzliche Optimierungen seitens der Protokolle (PCoIP, ICA, RDP) werden innerhalb der VSI Pro-Tests folglich nicht betrachtet. So kann man im praktischen Betrieb mit einem Endgerät weitere Vorteile erzielen, indem beispielsweise CPU-Berechnungen vom Hypervisor auf das Endgerät (z.B. ThinClient) verlagert werden. Zum Tool VSI-Pro existieren vielfache, frei erhältliche Publikationen. Insbesondere das http://projectvrc.nl empfiehlt sich als ergänzende Informationsquelle. VSI Pro unterstützt vielfältige Lastprofile, welche in der Lage sind, unterschiedlich hohe Betriebslasten zu erzeugen. Für die Erstellung dieses Whitepapers wurden die beiden VSI-Pro-Lastprofile „Medium― und „Heavy― herangezogen. Messungen mit bis zu 1.000 physikalischen Windows XP basierten Rich Clients zeigten einen allgemeinen Belastungsgrad, der - unter Berücksichtigung der Mehrbelastung durch den geplanten Betriebssystemwechsel von Windows XP (32-Bit) auf Windows 7 (64-Bit) - dem Lastprofil „Medium― entspricht. Der folgende Abschnitt zeigt die Beschreibung der unterschiedlichen Lastprofile von VSI Pro4 in seiner Originalversion. Workload Medium The medium workload is the default workload in VSI.
■ This workload emulated a medium knowledge worker using Office, IE and PDF. ■ Once a session has been started, the medium workload will repeat every 12 minutes. ■ During each loop, the response time is measured every 2 minutes. ■ The medium workload opens up to 5 applications simultaneously. ■ The type rate is 160 ms per character. ■ The medium workload in VSI 2.0 is approximately 35% more resource-intensive than in VSI 1.0. ■ Approximately 2 minutes of idle time is included to simulate real-world users. Each loop will open and use:
■ Outlook 2007, browse 10 messages. ■ Internet Explorer, one instance is left open (BBC.co.uk), one instance is browsed to Wired.com, Lonelyplanet.com and heavy flash app
gettheglass.com (not used with MediumNoFlash workload). ■ Word 2007, one instance to measure response time, one instance to review and edit document. ■ Bullzip PDF Printer & Acrobat Reader, the word document is printed and reviewed to PDF. ■ Excel 2007, a very large randomized sheet is opened. ■ PowerPoint 2007, a presentation is reviewed and edited. ■ 7-zip: using the command line version the output of the session is zipped. Workload Heavy This workload simulates a power user.
■ It is based on the medium workload. Difference in comparison to the medium workload:
■ Type rate is 130 ms per character. ■ Idle time total is only 40 seconds. ■ The heavy workload opens up to 8 applications simultaneously.
White paper Sizing of Virtual Desktop Infrastructures
Page 11 of 32 ts.fujitsu.com
Durchgeführte Messungen Citrix XenServer 5.6 FP1 und Citrix XenDesktop 4.0 Messungen Citrix XenServer 5.6 FP1 und Citrix XenDesktop 4.0 ■ Anzahl vClients mit Lastprofil „Medium― 5 ■ Anzahl vClients mit Lastprofil „Heavy― ■ Anzahl virtuelle Terminalserver (vTS) mit Lastprofil „Medium― ■ Anzahl vTS Lastprofil „Heavy― Messungen VMware vSphere 4.1 und VMware View 4.5 ■ Anzahl vClients mit Lastprofil „Medium― ■ Anzahl vClients mit Lastprofil „Heavy― ■ Anzahl vTS mit Lastprofil „Medium― ■ Anzahl vTS Lastprofil „Heavy― Hardware der Testumgebung Neben integrierten Netzwerk- und SAN-Infrastrukturkomponenten wurde für den Lasttest insbesondere folgende Hardware genutzt: ■ 2 Blade Server mit folgender Ausstattung
2x Intel Xeon X5670 2.93GHz 12x8GB RAM
■ 2 Blade Server mit folgender Ausstattung 2x Intel Xeon X5650 2.66GHz 24x8GB RAM
■ SAN Storage Subsystem Typ: EMC CX4-480 FastCache 185 GB Powerpath (4 Pfade, 2 davon aktiv im Round Robin) 3x RAID 5 (9x 300GB FC HDDs, 3 LUNs mit jeweils 2.4 TB Kapazität) 1x RAID 5 (5x 300GB FC HDDs, 1 LUNs mit jeweils 1.2 TB Kapazität) 1x RAID 5 (5x 100GB SATAII EFD HDDs, 1 LUN mit 400 GB Kapazität)
Name und Funktion IP Adresse Betriebssystem
DC1: Domain Controller 130.250.224.1 Windows Server 2008 EE R2 x64
VC2: VMware vCenter 4.0 130.250.224.2 Windows Server 2008 EE R2 x64
SQL: Datenbank Server MS SQL 2008 EE 130.250.224.3 Windows Server 2008 EE R2 x64
DDC1: Desktop Delivery Controller (DDC) 130.250.224.7 Windows Server 2003 EE 32bit
DDC2:Desktop Delivery Controller (DDC) 130.250.224.8 Windows Server 2003 EE 32bit
PVS1: Provisioning Server PvS 5.6 130.250.224.9 Windows Server 2008 EE R2 x64
PVS2: Provisioning Server PvS 5.6 130.250.224.10 Windows Server 2008 EE R2 x64
PVS3: physikalischer Provisioning Server PvS 5.6 130.250.224.33 Windows Server 2008 EE R2 x64
LIC1 : Citrix License Server Lic 11.9 130.250.224.11 Windows Server 2003 EE 32bit
VC3: VMware vCenter 4.1, View 4.5 130.250.224.20 Windows Server 2008 EE R2 x64
CS3: VMware Connection Server CS 4.5 130.250.224.21 Windows Server 2008 EE R2 x64
VSI-XA6-000: XenApp6-Server Master and Web Interface 130.250.224.30 Windows Server 2008 EE R2 x64
Tabelle 2: Infrastruktur-Server
5 Der „Medium― Workload der Citrix vClients konnte aus zeitlichen Gründen nur in einer anderen Lasttestumgebung mit älterer Hardware, nicht jedoch in der hier beschriebenen Lasttestumgebung ermittelt werden.
White paper Sizing of Virtual Desktop Infrastructures
Page 12 of 32 ts.fujitsu.com
Testergebnisse aus der Lasttestumgebung Alle dargestellten Messresultate liegen konsolidiert in Form einer Excel-Tabelle vor. Siehe auch Error! Reference source not found.. Citrix XenServer 5.6 FP1 und Citrix XenDesktop 4 / 5 Da die Belastungstests von VSI Pro nur die virtuellen Hüllen auf dem XenServer nutzen und der Provisioning Server auch bei XenDesktop 5 unverändert ist, können die Resultate auch auf XenDesktop 5 in Kombination mit PvS 5.6 angewendet werden. Die Messungen der vClients im Lastprofil „Medium‖ konnten aufgrund der zeitlich begrenzten Teststellung nicht mehr durchgeführt werden. Vorangegangene Messungen in einer anderen Lasttestumgebung, ließen jedoch relativ genaue Um- bzw. Hochrechnungen zu. Konfiguration vClient ■ OS: Windows 7 (x64) ■ CPU: 1 vCPU ■ RAM: 1536 MB6 ■ HDD: 30 GB vDisk (Thick7) + 3 GB vDisk mit 2 GB Pagefile Konfiguration vTS ■ OS: Windows 2008 R2 (x64) mit Erweiterung Citrix XenApp6 ■ CPU: 4 vCPUs ■ RAM: 24576 MB, davon 8196 MB als ―Write Cache in RAM‖8 ■ HDD: 8 GB vDisk mit 4 GB Pagefile, 30 GB vDisk (Thick) als OS-Partition auf Provisioning Server ■ Anzahl: 6
6 Citrix stellt für alle Templates die von Microsoft empfohlene Mindestgröße für RAM ein. Für Windows 7 (x64) sind das 2GB. Um weniger RAM und das Dynamic Memory Control Feature nutzen zu können, muss daher diese Untergrenze angepasst werden. Das geschieht mit folgende Kommandos über die XenServer-Konsole:
7 Es gibt grundsätzlich zwei Modi beim Zuweisen von Storage-Kapazität: Thick = der gesamte zugewiesene Speicherplatz wird auf dem Storage bereits initial für die VM reserviert, unabhängig davon, wie viel tatsächliche Daten in der Partition der VM liegen; optimale Performance Fast bzw. Thin = der VM steht grundsätzlich der zugewiesene Speicherplatz zur Verfügung, auf dem Storage wird allerdings nur die Kapazität belegt, die mit Daten befüllt ist; optimale Kapazitätsnutzung, aber reduzierte Performance
8 Der Provisioning Server 5.6 nutzt intern 32-bit Adressierung bei der Option Write Cache in RAM. Daher sind in der Praxis max. 4 GB RAM pro OS sinnvoll.
White paper Sizing of Virtual Desktop Infrastructures
Page 13 of 32 ts.fujitsu.com
Anzahl vClients bei Betriebslast „Heavy”
Abbildung 5: VSI-max vClients bei Betriebslast „Heavy“ Der VSI-max wurde gemäß Berechnung9 bei einer Dichte von 91 vClients erreicht. Hier muss erwähnt werden, dass die Konfiguration des Storage Subsystems nach Übernahme des Anbieters VCE nicht optimal konfiguriert wurde. Insbesondere die Cache- und Pfadeinstellungen mussten im Laufe der Messungen nachträglich angepasst werden. Als Folge wurden alle bereits durchgeführten Tests wiederholt und zeigten auch alle einen leichten Anstieg der Performance um ~ 5%.Zeitlich konnten jedoch zwei Lasttests nicht mehr nach dieser Optimierung erneut nachgetestet werden. Die hier aufgeführten Resultate spiegeln also die Resultate ohne Optimierung des Storage wieder. Dabei handelte es sich konkret um die folgenden beiden Lasttests ohne Optimierung des Storage: ■ Citrix XenDesktop 4 mit vClients im Belastungsprofil „Medium― ■ Citrix XenDesktop 4 mit vClients im Belastungsprofil „Heavy― Es ist zu erwarten, dass sich das Ergebnis „Citrix XenDesktop 4 mit vClients im Belastungsprofil „Heavy― auf 95 - 100 erhöht. Protokollabhängige Optimierung bei Einsatz spezieller physischer Endgeräte (z.B. FUTRO Thin Clients) wurden hierbei nicht berücksichtigt, würden jedoch zu einer Erhöhung der Dichte führen. Weiterführende Informationen zu den unterschiedlichen Optimierungen durch Einsatz spezieller Protokolle (z.B. PCoIP, ICA) sind nicht Bestandteil dieses Whitepapers.
9 VSImax wird ausgelöst, wenn Baseline (hier 2000ms) + 2500ms (= 4500ms) vom ―VSI Index Average― durchbrochen wird. Definition Baseline siehe Tabelle 16: Abkürzungsverzeichnis.
White paper Sizing of Virtual Desktop Infrastructures
Page 14 of 32 ts.fujitsu.com
Sizing vClients bei Betriebslast „Heavy“
XenServer 5.6 FP1 und XenDesktop 4.0 Lastprofil "Heavy" vClients
CPU-Typ CPU- Anzahl
Normalisierte Leistung
Empfohlene Anzahl Sessions
"Heavy"
Empfohlene RAM-Kapazität
Hypervisor-Server
Empfohlene Leistungsfähigkeit SAN
(Backend Disk-IOPS)
Intel Xeon E5504 2 39% 36 57 GB 615
Intel Xeon E/L5520 2 57% 52 82 GB 903
Intel Xeon X5550 2 70% 64 100 GB 1103
Intel Xeon W5590 2 79% 72 112 GB 1244
Intel Xeon E5507 2 45% 41 65 GB 703
Intel Xeon E/L5640 2 70% 64 99 GB 1098
Intel Xeon X5650 2 100% 91 141 GB 1571
Intel Xeon X5670 2 105% 96 147 GB 1649
Intel Xeon X5680 2 110% 100 154 GB 1722
Intel Xeon E7540 4 158% 144 219 GB 2478
Intel Xeon X7560 4 222% 202 307 GB 3483
Tabelle 3: Sizing vClients bei Betriebslast „Heavy“ Legende
Lediglich die rot markierte Zeile wurde auf physischer Hardware real vermessen. Alle anderen Werte wurden anhand der CPU-Leistungswerte theoretisch berechnet. Als Grundlage für die „Normalisierte Leistung― dienten real ermittelte CPU-Benchmarkwerte des SPECint_rate_base2006. Die „empfohlene Kapazität Arbeitsspeicher (RAM)― beinhaltet neben dem konfigurierbaren Arbeitsspeicher pro vClient bzw. pro vTS auch den zum Betrieb benötigten Arbeitsspeicher für den Hypervisor (4096 MB).
White paper Sizing of Virtual Desktop Infrastructures
Page 15 of 32 ts.fujitsu.com
Anzahl vTS bei Betriebslast „Medium”
Abbildung 6: VSI-max vTS bei Betriebslast „Medium“ Der VSI-max wurde gemäß Berechnung10 bei einer Dichte von 136 Sessions erreicht. Um auf XenServer 5.6 FP1 die maximale CPU-Auslastung und Benutzerdichte zu erreichen, müssen alle logischen Prozessoren (in unserem Fall 24 logische CPUs) verwendet werden! Bei oberer Messung wurden 6 virtuelle XenApp 6-Server mit je 4 vCPUs konfiguriert. Alternativ können auch 3 virtuelle XenApp6-Server mit je 8 vCPUs genutzt werden, um z.B. Lizenzkosten für das Betriebssystem einzusparen. Aus Gründen der Vergleichbarkeit mit den Tests aus der Lasttestumgebung, sowie der Vergleichbarkeit mit Hyper-V, wurde jedoch auf Messungen mit 8 vCPUs verzichtet. Protokollabhängige Optimierung bei Einsatz physischer Endgeräte (z.B. FUTRO Thin Clients) wurden hierbei nicht berücksichtigt, würden jedoch zu einer Erhöhung der Dichte führen.
10 VSImax wird ausgelöst, wenn Baseline (hier 3700ms) + 2500ms (=6200ms) vom ―VSI Index Average― (blaue Linie) durchbrochen wird. Definition Baseline siehe Tabelle 16: Abkürzungsverzeichnis.
White paper Sizing of Virtual Desktop Infrastructures
Tabelle 4: vTS - Sizing bei Betriebslast „Medium“ Legende
Lediglich die rot markierte Zeile wurde auf physikalischer Hardware real vermessen. Alle anderen Werte wurden anhand der CPU-Leistungswerte theoretisch berechnet. Als Grundlage für die „Normalisierte Leistung― dienten real ermittelte CPU-Benchmarkwerte des SPECint_rate_base2006. Die virtuellen Terminalserver wurden über einen physikalischen Provisioning Server zur Verfügung gestellt. Dadurch kommt es zu sehr geringen Lesevorgängen auf dem Storage-Subsystem, da lesende Anfragen meist aus dem RAM des Provisioning Servers bedient werden können. Durch die Einstelllung „Cache in device RAM― konnten auch die Schreibvorgänge nahezu auf 0 reduziert werden. Eine höhere Arbeitsspeicherausstattung der virtuellen Terminalserver war im Testumfeld nicht nötig. In diesem Betriebsmodus fällt nahezu keine messbare IO-Auslastung auf dem genutzten Storage-Subsystem mehr an. Ein Betrieb mit lokalen Festplatten ist möglich. Die „empfohlene Kapazität Arbeitsspeicher (RAM)― beinhaltet neben dem konfigurierbaren Arbeitsspeicher pro vClient bzw. pro vTS auch den zum Betrieb benötigten Arbeitsspeicher für den Hypervisor (4096 MB).
White paper Sizing of Virtual Desktop Infrastructures
Page 17 of 32 ts.fujitsu.com
Anzahl vTS bei Betriebslast „Heavy”
Abbildung 7: VSI-max vTS bei Betriebslast „Heavy“ Der VSI-max wurde gemäß Berechnung11 bei einer Dichte von 105 Sessions erreicht. Um auf XenServer 5.6 FP1 die maximale CPU-Auslastung und Benutzerdichte zu erreichen, müssen alle logischen Prozessoren (in unserem Fall 24 logische CPUs) verwendet werden! Bei oberer Messung wurden 6 virtuelle XenApp6-Server mit je 4 vCPUs konfiguriert. Alternativ können auch 3 virtuelle XenApp6-Server mit je 8 vCPUs genutzt werden, um z.B. Lizenzkosten für das Betriebssystem einzusparen. Aus Gründen der Vergleichbarkeit mit den Tests aus der Lasttestumgebung, sowie der Vergleichbarkeit mit Hyper-V, wurde jedoch auf Messungen mit 8 vCPUs verzichtet. Protokollabhängige Optimierung bei Einsatz spezieller physikalischer Endgeräte (z.B. FUTRO Thin Clients) wurden hierbei nicht berücksichtigt, würden jedoch zu einer Erhöhung der Dichte führen.
11 VSImax wird ausgelöst, wenn Baseline (hier 3700 ms) + 2500 ms (=6200 ms) vom ―VSI Index Average― (blaue Linie) durchbrochen wird. Definition Baseline siehe Tabelle 16: Abkürzungsverzeichnis.
White paper Sizing of Virtual Desktop Infrastructures
Tabelle 5: vTS - Sizing bei Betriebslast „Heavy“ Legende
Lediglich die rot markierte Zeile wurde auf physikalischer Hardware real vermessen. Alle anderen Werte wurden anhand der CPU-Leistungswerte theoretisch berechnet. Als Grundlage für die „Normalisierte Leistung― dienten real ermittelte CPU-Benchmarkwerte des SPECint_rate_base2006. Die virtuellen Terminalserver wurden über einen physikalischen Provisioning Server zur Verfügung gestellt. Dadurch kommt es zu sehr geringen Lesevorgängen auf dem Storage-Subsystem, da lesende Anfragen meist aus dem RAM des Provisioning Servers bedient werden können. Durch die Einstelllung „Cache in device RAM― konnten auch die Schreibvorgänge nahezu auf 0 reduziert werden. Eine höhere Arbeitsspeicherausstattung der virtuellen Terminalserver war im Testumfeld nicht nötig. In diesem Betriebsmodus fällt nahezu keine messbare IO-Auslastung auf dem genutzten Storage-Subsystem mehr an. Ein Betrieb mit lokalen Festplatten ist möglich. Die „empfohlene Kapazität Arbeitsspeicher (RAM)― beinhaltet neben dem konfigurierbaren Arbeitsspeicher pro vClient bzw. pro vTS auch den zum Betrieb benötigten Arbeitsspeicher für den Hypervisor (4096 MB).
White paper Sizing of Virtual Desktop Infrastructures
Page 19 of 32 ts.fujitsu.com
VMware vSphere 4.1 and VMware View 4.5 Neben genereller Optimierung des Windows 7-Images für den vClient wurde der vSphere 4.1 ESX Host über die erweiterten Einstellungen – auf Empfehlung von VMware12 - wie folgt optimiert:
12 Details siehe auch http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1020233
13 Es gibt grundsätzlich zwei Modi beim Zuweisen von Storage-Kapazität: Thick = der gesamte zugewiesene Speicherplatz wird auf dem Storage bereits initial für die VM reserviert, unabhängig davon, wie viel tatsächliche Daten in der Partition der VM liegen; optimale Performance Fast bzw. Thin = der VM steht grundsätzlich der zugewiesene Speicherplatz zur Verfügung, auf dem Storage wird allerdings nur die Kapazität belegt, die mit Daten befüllt ist; optimale Kapazitätsnutzung, aber reduzierte Performance
White paper Sizing of Virtual Desktop Infrastructures
Page 20 of 32 ts.fujitsu.com
Anzahl vClients bei Betriebslast „Medium”
Abbildung 8: VSI-max vClients bei Betriebslast „Medium“ Der VSI-max wurde gemäß Berechnung14 bei einer Dichte von 103 vClients erreicht. Protokollabhängige Optimierung bei Einsatz physikalischer Endgeräte (z.B. FUTRO Thin Clients) wurden hierbei nicht berücksichtigt, würden jedoch zu einer Erhöhung der Dichte führen.
14 VSImax wird ausgelöst, wenn Baseline (hier 1300ms) + 2500ms (=3800ms) vom ―VSI Index Average― durchbrochen wird. Definition Baseline siehe Tabelle 16: Abkürzungsverzeichnis.
White paper Sizing of Virtual Desktop Infrastructures
Tabelle 6: Sizing vClients bei Betriebslast „Medium“ Legende
Lediglich die rot markierte Zeile wurde auf physischer Hardware real vermessen. Alle anderen Werte wurden anhand der CPU-Leistungswerte theoretisch berechnet. Als Grundlage für die „Normalisierte Leistung― dienten real ermittelte CPU-Benchmarkwerte des SPECint_rate_base2006. Die „empfohlene Kapazität Arbeitsspeicher (RAM)― beinhaltet neben dem konfigurierbaren Arbeitsspeicher pro vClient bzw. pro vTS auch den zum Betrieb benötigten Arbeitsspeicher für den Hypervisor (4096 MB).
White paper Sizing of Virtual Desktop Infrastructures
Page 22 of 32 ts.fujitsu.com
Anzahl vClients bei Betriebslast „Heavy”
Abbildung 9: VSI-max vClients bei Betriebslast „Heavy“ Der VSI-max wurde gemäß Berechnung15 bei einer Dichte von 95 vClients erreicht. Protokollabhängige Optimierung bei Einsatz physischer Endgeräte (z.B. FUTRO Thin Clients) wurden hierbei nicht berücksichtigt, würden jedoch zu einer Erhöhung der Dichte führen.
15 VSImax wird ausgelöst, wenn Baseline (hier 1600ms) + 2500ms (=4100ms) vom ―VSI Index Average― durchbrochen wird. Definition Baseline siehe Tabelle 16: Abkürzungsverzeichnis.
White paper Sizing of Virtual Desktop Infrastructures
Tabelle 7: Sizing vClients bei Betriebslast „Heavy“ Legende
Lediglich die rot markierte Zeile wurde auf physikalischer Hardware real vermessen. Alle anderen Werte wurden anhand der CPU-Leistungswerte theoretisch berechnet. Als Grundlage für die „Normalisierte Leistung― dienten real ermittelte CPU-Benchmarkwerte des SPECint_rate_base2006. Die „empfohlene Kapazität Arbeitsspeicher (RAM)― beinhaltet neben dem konfigurierbaren Arbeitsspeicher pro vClient bzw. pro vTS auch den zum Betrieb benötigten Arbeitsspeicher für den Hypervisor (4096 MB).
White paper Sizing of Virtual Desktop Infrastructures
Page 24 of 32 ts.fujitsu.com
Anzahl vTS bei Betriebslast „Medium”
Abbildung 10: VSI-max vTS bei Betriebslast „Medium“ Der VSI-max wurde gemäß Berechnung16 bei einer Dichte von 132 Sessions erreicht. Um auf vSphere v4.1 die maximale CPU-Auslastung und Benutzerdichte zu erreichen, müssen nicht alle logischen Prozessoren (in unserem Fall 24 logische CPUs) verwendet werden! Bei oberer Messung wurden 4 virtuelle XenApp6-Server mit je 4 vCPUs konfiguriert. Eine größere Anzahl an vTS brachte keine höhere Anzahl an möglichen Sessions. Alternativ können auch zwei oder drei virtuelle XenApp6-Server mit je 8 vCPUs genutzt werden. Aus Gründen der Vergleichbarkeit mit den Tests aus der Lasttestumgebung, sowie der Vergleichbarkeit mit Hyper-V, wurde jedoch auf Messungen mit 8 vCPUs verzichtet. Protokollabhängige Optimierung bei Einsatz physikalischer Endgeräte (z.B. FUTRO Thin Clients) wurden hierbei nicht berücksichtigt, würden jedoch zu einer Erhöhung der Dichte führen.
16 VSImax wird ausgelöst, wenn Baseline (hier 2100ms) + 2500ms (=4600ms) vom ―VSI Index Average― (blaue Linie) durchbrochen wird. Definition Baseline siehe Tabelle 16: Abkürzungsverzeichnis.
White paper Sizing of Virtual Desktop Infrastructures
Tabelle 8: vTS - Sizing bei Betriebslast „Medium“ Legende
Lediglich die rot markierte Zeile wurde auf physikalischer Hardware real vermessen. Alle anderen Werte wurden anhand der CPU-Leistungswerte theoretisch berechnet. Als Grundlage für die „Normalisierte Leistung― real ermittelte CPU-Benchmarkwerte des SPECint_rate_base2006. Die virtuellen Terminalserver wurden über ein zuvor angelegtes Template manuell auf dem Hypervisor Server erzeugt, da VMware View die automatisierte Provisionierung von Server-Betriebssystemen derzeit nicht unterstützt. Durch die Nutzung der Terminalserver Technologie können signifikant geringere IO-Auslastungen auf dem Storage-Subsystem erreicht werden. Die „empfohlene Kapazität Arbeitsspeicher (RAM)― beinhaltet neben dem konfigurierbaren Arbeitsspeicher pro vClient bzw. pro vTS auch den zum Betrieb benötigten Arbeitsspeicher für den Hypervisor (4096 MB).
White paper Sizing of Virtual Desktop Infrastructures
Page 26 of 32 ts.fujitsu.com
Anzahl vTS bei Betriebslast „Heavy”
Abbildung 11: VSI-max vTS bei Betriebslast „Heavy“ Der VSI-max wurde gemäß Berechnung17 bei einer Dichte von 95 Sessions erreicht. Um auf vSphere v4.1 die maximale CPU-Auslastung und Benutzerdichte zu erreichen, müssen nicht alle logischen Prozessoren (in unserem Fall 24 logische CPUs) verwendet werden! Bei oberer Messung wurden 4 virtuelle XenApp6-Server mit je 4 vCPUs konfiguriert. Eine größere Anzahl an vTS brachte keine höhere Anzahl an möglichen Sessions. Alternativ können auch zwei oder drei virtuelle XenApp6-Server mit je 8 vCPUs genutzt werden. Aus Gründen der Vergleichbarkeit mit den Tests aus der Lasttestumgebung, sowie der Vergleichbarkeit mit Hyper-V, wurde jedoch auf Messungen mit 8 vCPUs verzichtet. Protokollabhängige Optimierung bei Einsatz physischer Endgeräte (z.B. FUTRO Thin Clients) wurden hierbei nicht berücksichtigt, würden jedoch zu einer Erhöhung der Dichte führen.
17 VSImax wird ausgelöst, wenn Baseline (hier 2100 ms) + 2500 ms (=4600 ms) vom ―VSI Index Average― (blaue Linie) durchbrochen wird. Definition Baseline siehe Tabelle 16: Abkürzungsverzeichnis.
White paper Sizing of Virtual Desktop Infrastructures
Tabelle 9: vTS - Sizing bei Betriebslast „Heavy“ Legende
Lediglich die rot markierte Zeile wurde auf physikalischer Hardware real vermessen. Alle anderen Werte wurden anhand der CPU-Leistungswerte theoretisch berechnet. Als Grundlage für die „Normalisierte Leistung― dienten real ermittelte CPU-Benchmarkwerte des SPECint_rate_base2006. Die virtuellen Terminalserver wurden über ein zuvor angelegtes Template manuell auf dem Hypervisor Server erzeugt, da VMware View die automatisierte Provisionierung von Server-Betriebssystemen derzeit nicht unterstützt. Durch die Nutzung der Terminalserver Technologie können signifikant geringere IO-Auslastungen auf dem Storage-Subsystem erreicht werden. Die „empfohlene Kapazität Arbeitsspeicher (RAM)― beinhaltet neben dem konfigurierbaren Arbeitsspeicher pro vClient bzw. pro vTS auch den zum Betrieb benötigten Arbeitsspeicher für den Hypervisor (4096 MB).
White paper Sizing of Virtual Desktop Infrastructures
*= Spalte "vClients XD4.0 Medium" enthält geschätzte Werte und wurden nicht vermessen! PvS wurde mit Option "WC in SAN" betrieben.
Weitere Details siehe auch VDI-SizinError! Reference source not found..
1.414
1.199
165 165
1.140997
1.212 1.212
3.200 3.200
1.640 1.640
30,48 32,00 17,26 17,260
500
1.000
1.500
2.000
2.500
3.000
3.500
vClients View4.5Medium
vClients View4.5Heavy
vClients XD 4.0Medium*
vClients XD 4.0Heavy
Read PeakSPA + SPB (IO/s)
Write PeakSPA + SPB (IO/s)
Cum. Total ThroughputSPA + SPB (IO/s)
White paper Sizing of Virtual Desktop Infrastructures
Page 29 of 32 ts.fujitsu.com
vTS - Übersicht IO-Auslastung Storage Subsystem
Abbildung 13: vTS - Übersicht IO-Auslastung
Weitere Details siehe auch Error! Reference source not found..
Schlussfolgerung Die getesteten Lösungen bewegen sich hinsichtlich der Benutzerdichte der vClients auf einem vergleichbaren Niveau. Ein erwähnenswerter Unterschied lässt sich allenfalls bei der Benutzerdichte von vTS erkennen: Bei aktiviertem Hyperthreading der Hypervisor-CPUs und Einsatz eines 64-Bit Server-Betriebssystems (z.B. Windows Server 2008 R2) verhält sich der Hypervisor von Citrix leistungsfähiger, als der von VMware. Bei den Messungen der Benutzerdichte konnte Citrix XenServer 5.6 FP1 10-15% mehr Sessions performant bereitstellen als VMware ESXi vSphere 4.1. Für die Provisionierung und den Betrieb von einer reinen vClient-Umgebung eignen sich beide Lösungen - VMware View 4.5 und XenDesktop 4 - gleichermaßen gut. Beide Lösungen bieten Vor- und Nachteile wie aus Tabelle 12 – Vor- und Nachteile ersichtlich.
In einer VDI-Umgebung empfiehlt sich ein verstärkter Einsatz von virtuellen Terminalservern (vTS) insbesondere, wenn im Durchschnitt ein „Medium― oder „Light― Lastprofil der Benutzer vorliegt. Zum einen, weil dann bis zu 30% mehr Desktops bereitgestellt werden können, zum anderen, weil die Performance-Anforderungen an das zentrale SAN-Storage-Subsystem generell deutlich geringer ausfallen.
348
477
27 40
484
403
5 12
700
600
32 405,00 6,00 0,23 0,36
0
100
200
300
400
500
600
700
800
vTS View4.5Medium
vTS View4.5Heavy
vTS XD 4.0Medium
vTS XD 4.0Heavy
Read PeakSPA + SPB (IO/s)
Write PeakSPA + SPB (IO/s)
Cum. Total ThroughputSPA + SPB (IO/s)Backend-IOPSSPA + SPB (IOPS/vTS)
White paper Sizing of Virtual Desktop Infrastructures
Page 30 of 32 ts.fujitsu.com
Da VMware View die Provisionierung von Serverbetriebssystemen nicht unterstützt, bieten sich bei Mischumgebungen von vClients und vTS folgende Optionen an: ■ VMware ESXi vSphere / VMware View / Dinamiqs VirtualStorm18 ■ Citrix XenServer / Citrix XenDesktop ■ VMware ESXi vSphere / Citrix XenDesktop19 Bei der Analyse der IO-Auslastung zeigte sich ferner, dass mit der Option des Citrix Provisioning Server, den Write-Cache in den Arbeitsspeicher des Zielgerätes zu legen, eine weitere Option zur Verfügung steht. So fallen bei Nutzung dieser Option nahezu keine Read- und Write IO-Operationen auf den zentralen SAN-Storage-Subsystemen an. Allerdings muss dann der RAM des Hypervisor-Server entsprechend groß dimensioniert werden. Diese Option eignet sich auch für eine lokale Lösung ohne SAN zur Realisierung einer zentralisierten VDI-Umgebung. Siehe auch die zusammenfassende Auswertung oberer Lösungskombinationen auf der folgenden Seite.
Lastprofil "Medium"
Test Beschreibung
Client- Typ
CPU- Typ
CPU- Anzahl
Empfohlener RAM-Bedarf /
Session
Empfohlene RAM-Kapazität
Hypervisor-Server
Empfohlene Anzahl Sessions
Empfohlene Leistungsfähigkeit SAN
(Backend Disk-IOPS)
Citrix XenServer 5.6 XenDesktop 4
vClients Intel Xeon X5650
2 1.536 MB 159 GB 103 31* / 1.571
Citrix XenServer 5.6 XenDesktop 4
vTS Intel Xeon X5650
2 768 MB 106 GB 136 31* / 700
VMware vSphere 4.1 VMware View 4.5
vClients Intel Xeon X5650
2 1.536 MB 159 GB 103 3139
VMware vSphere 4.1 VMware View 4.5
vTS Intel Xeon X5650
2 768 MB 103 GB 132 660
VMware vSphere 4.1 XenDesktop 4
vClients Intel Xeon X5650
2 1.536 MB 159 GB 103 31* / 1.571
VMware vSphere 4.1 XenDesktop 4
vTS Intel Xeon X5650
2 768 MB 106 GB 136 31* / 700
= Resultate der markierten Zeile wurden nicht ermittelt, sondern spiegeln zu erwartende Ergebnisse der Lösung wieder!
* = Konfiguration: Provisioning Server WriteCache in RAM (zweiter Wert = WriteCache in SAN)
Tabelle 10: Zusammenfassung Sizing „Medium“ Workload Die Hersteller Citrix und VMware haben bei der Installation, Konfiguration und Durchführung der jeweiligen Lasttests mitgewirkt und die Richtigkeit der Resultate aus dem Lasttest bestätigt.
18 Mehr Informationen zu VirtualStorm siehe http://www.dinamiqs.com/
19 Zum Testzeitpunkt stellte sich diese Kombination als technisch optimal heraus; die Wirtschaftlichkeit muss separat geprüft werden
White paper Sizing of Virtual Desktop Infrastructures
Page 31 of 32 ts.fujitsu.com
Lastprofil "Heavy"
Test Beschreibung
Client Typ
CPU- Typ
CPU- Anzahl
Empfohlener RAM-Bedarf /
Session
Empfohlene RAM-Kapazität
Hypervisor-Server
Empfohlene Anzahl Sessions
Empfohlene Leistungsfähigkeit SAN
(Backend Disk-IOPS)
Citrix XenServer 5.6 XenDesktop 4
vClients Intel Xeon X5650
2 1.536 MB 141 GB 91 38* / 1.571
Citrix XenServer 5.6 XenDesktop 4
vTS Intel Xeon X5650
2 768 MB 83 GB 105 38* / 600
VMware vSphere 4.1 VMware View 4.5
vClients Intel Xeon X5650
2 1.536 MB 147 GB 95 3139
VMware vSphere 4.1 VMware View 4.5
vTS Intel Xeon X5650
2 768 MB 75 GB 95 570
VMware vSphere 4.1 XenDesktop 4
vClients Intel Xeon X5650
2 1.536 MB 147 GB 95 38* / 1.571
VMware vSphere 4.1 XenDesktop 4
vTS Intel Xeon X5650
2 768 MB 83 GB 105 38* / 600
= Resultate der markierten Zeile wurden nicht ermittelt, sondern spiegeln zu erwartende Ergebnisse der Lösung wieder!
* = Konfiguration: Provisioning Server WriteCache in RAM (zweiter Wert = WriteCache in SAN)
Tabelle 11: Zusammenfassung Sizing „Heavy“ Workload Die Hersteller Citrix und VMware haben bei der Installation, Konfiguration und Durchführung der jeweiligen Lasttests mitgewirkt und die Richtigkeit der Resultate aus dem Lasttest bestätigt.
Kriterium Citrix XenDesktop 4 VMware View 4.5
Anzahl benötigter Infrastruktur-Server - +
Komplexität bei Installation und Inbetriebnahme o +
Administrationsaufwand für das Management von bis zu 160.000 vClients o o
51Maximale Pool-Größe 65.000 512
Geschwindigkeit (Neu-) Provisionierung + -
Anforderungen SAN + -
Anforderungen LAN - +
Provisionierung von Serverbetriebssystemen + -
Tabelle 12: Vor- und Nachteile Legende: + = Vorteil o = Neutral - = Nachteil
White paper Sizing of Virtual Desktop Infrastructures
Page 32 of 32 ts.fujitsu.com
Anhang Abkürzungen / Glossar Bezeichnung Bedeutung
Baseline Durchschnittliche Antwortzeit der ersten 15 vClients bzw. vTS in ms. Die Basis-Antwortzeit von Published Desktops (vTS) über Terminal Server ist grundsätzlich höher als die von Desktops einer VDI Lösung (vClients).
CS Kurzform für den VMware Connection Server. Erfüllt die Funktion eines Connection Brokers.
DDC Kurzform für den Citrix Desktop Delivery Controller. Erfüllt die Funktion eines Connection Brokers.
EFD Kurzform für Enterprise Flash Disks; Hochwertige Solid State Disks (SSD)
OS Operating System; engl. Bezeichnung für Betriebssystem
PvS Kurzform für den Citrix Provisioning Server.
SAN Kurzform für Storage Area Network.
vClient Kurzform für: virtueller Client bzw. virtuelle Maschine (VM).
VDI Kurzform für Virtual Desktop Infrastructure. Beschreibt die zum Betrieb von virtuellen Clients nötige Infrastruktur.
VM Kurzform für Virtuelle Maschine, dies kann sowohl ein virtueller Client (vClient) als auch ein virtueller Server sein
vTS Kurzform für virtueller Terminalserver bzw. virtuelle Terminalserver Session. Tabelle 133: Abkürzungsverzeichnis
ƒ Copyright 2011 Fujitsu, the Fujitsu logo are trademarks or registered trademarks of Fujitsu Limited in Japan and other countries. Other company, product and service names may be trademarks or registered trademarks of their respective owners. Technical data subject to modification and delivery subject to availability. Any liability that the data and illustrations are complete, actual or correct is excluded. Designations may be trademarks and/or copyrights of the respective manufacturer, the use of which by third parties for their own purposes may infringe the rights of such owner.
![High Availability, Loadbalancing und Scale-Out in Mailclustern · High-Availability, Loadbalancing und Scale-Out in Mailclustern [Admin-Stammtisch 05.07.2018] Carsten Rosenberg](https://static.unterlagen.site/doc/80x56/5eca5ccdc471db0fee405824/high-availability-loadbalancing-und-scale-out-in-mailclustern-high-availability.jpg)
