Dat VDI-omgevingen organisaties talloze voordelen kunnen brengen is inmiddels algemeen bekend. Waar echter de belangrijkste valkuilen voor o.a. het beheer en de performance liggen is niet voor iedereen helder.
Waarom?
- Gebrek aan inzicht over de invloed van het VDI image op de I/O load
- Omgaan met boot- en login-stormen
Bekijk in deze presentatie hoe door performance en storage-optimalisatie binnen een VDI omgeving zelfs de meest veeleisende desktopvirtualisatie omgevingen mogelijk worden gemaakt.
Performance- en storageopitimalisatie voor VDI omgevingen
1. SYNC 2014 - EXPAND YOUR HORIZONS
Rob Turk
Pre-sales consultant
2.
3. Infrastructuur
Servers:
CPU (MHz) en Memory (GB)
Netwerk:
Bandbreedte en Connecties
Storage:
Capaciteit (TB) en Snelheid (IOPS)
4. IOPS, wat is (zijn?) dat eigenlijk?
Applicatie schrijft data naar een file
(100 kleine write I/O’s)
Framework verzamelt stukjes data in een buffer
(1 write I/O van bijvoorbeeld 4KB)
Buffer wordt naar het file system gestuurd
(1 write I/O data + één of meer I/O’s Metadata)
Filesystem schrijft naar het cache
(1 of meer grotere I/O’s coalesced)
Hypervisor met eigen filesystem, drivers, cache en buffers
(wie het weet mag het zeggen)
Cache wordt ge-flushed naar disk
(meerdere I/O’s gerangschikt)
5. Hoeveel tijd kost het om een byte op te halen..
*Source: http://commons.wikimedia.org/wiki/File:Solar_system_distances.JPG
6. I/O - Faciliteren of voorkomen?
• Supersnelle storage systemen
• Lage latencies
• Razendsnel netwerk
• Flash / SSD / Memory cache
• Optimaal VDI image
• Voorkomen van piekbelastingen
• Gefaseerd bootproces
• Goed afgestemde Virtual Machines
7.
8. Boot en Login storms
EEN VOORBEELD
• Een typisch Windows 7 VM genereert 10.000 - 15.000 I/O’s tot het login scherm
• 1000 VM’s tegelijk booten betekent 15 miljoen I/O’s afhandelen
• Een storage systeem gesized voor 20 IOPS/user gaat er minimaal (15 miljoen / (20
x 1000)) = 750 sec. over doen. (12.5 minuten)
• Latency gooit roet in het eten. Werkelijkheid duurt 3x zo lang!
• Voorkomen
• ‘s Ochtends gefaseerd pre-booten?
• Always-on VM’s (extra CPU/RAM nodig)?
• Faciliteren
• Boot images van SSD/Flash array
• Applicatie Pre-Cache
• Automatische storage tiering
9. Pilot en Praktijk
…De “happy first” hebben alle ruimte
Performance is vaak beter dan verwacht
Na volledige uitrol voelt het wat krap…
Toegang tot informatie wordt steeds vanzelfsprekender. Anytime, anywhere. Meestal in een kantoor omgeving waar desktops, laptops en tablets te vinden zijn. Soms op exotische plaatsen waar een traditionele desktop of een IT team voor het beheer niet voorhanden zijn.
Het liefst werken we in de vertrouwde werkomgeving zodat applicaties en data direct toegankelijk zijn. Daarnaast willen we het beheer, het up-to-date houden van applicaties en het veiligstellen van informatie zo efficiënt mogelijk maken.
Virtual Desktop heeft een grote vlucht gemaakt om dit allemaal mogelijk te maken. In deze presentatie kijken we naar de invloed van storage op de werking van VDI.
Een traditionele IT omgeving bestaat uit servers waarop back-end applicaties draaien (databases, email, collaboration). Applicaties zoals tekstverwerkers, ontwikkel omgevingen en spreadsheets draaien op de desktop machines bij de gebruiker. Die gebruiker heeft een grote diversiteit aan systemen ter beschikking, die elk specifieke beheer inspanning vereisen.
Bij introductie van VDI worden de applicaties niet langer op verschillende desktop systemen gedraaid, maar op virtuele machines. De desktop, laptop of tablet bieden toegang tot deze applicaties, maar draaien zelf geen applicatie. Daarmee zijn ze uitwisselbaar geworden.
Om Virtual Desktops goed tot hun recht te laten komen, is een gedegen infrastructuur nodig
De Virtual Desktop Infrastructuur, of VDI, bestaat uit servers, netwerken en storage.
Voor het slagen van een VDI project is met name storage een belangrijk aandachtspunt.
In deze presentatie zien we waarom.
Input/Output Operations Per Second
‘de’ I/O bestaat niet.
Voorraadbeheer applicatie scanned barcodes. Elke barcode scan genereert een write naar een file.
Framework (.NET, Qt, Carbon/Cocoa) verzamelt en structureert de writes. Er komt een grotere I/O uit voort
Filesystem (NTFS, HFS, EXT3) schrijft daadwerkelijk naar disk. Voegt ook meta-data toe (access time, filenaam)
Disk? NFS, iSCSI, FC, SAS/SATA.
‘de’ disk bestaat niet
Disk is onderdeel van complex storage systeem. RAID sets, virtual volumes, thin provisioning, remote mirroring, tiering.
De kosten van een daadwerkelijke I/O zijn hoog.
Hoe hoog? Stel dat we een CPU zijn en we zijn druk bezig een applicatie uit te voeren
We hebben de volgende instructie of het volgende byte nodig om te verwerken.
Als dat byte zich in het cache op de CPU bevindt dan is dat snel beschikbaar. Denk aan tienden van nanosecondes.
Moet het van disk komen dan duurt dat aanzienlijk langer.
Ter illustratie doen we een kleine vergelijking.
Stel dat het ophalen van een byte uit een CPU register hetzelfde is als het ophalen van een doosje uit het midden van de zaal..
Mocht het byte dan niet in het register maar in het cache op de CPU zitten, dan is dat vergelijkbaar met het ophalen uit de parkeergarage.
Als het cache ook ‘niet thuis’ geeft, dan moet het wellicht uit het werkgeheugen komen. Ophalen uit het werkgeheugen is een wandelingetje van hier naar Amsterdam en terug.
Is de gevraagde informatie niet in het werkgeheugen te vinden, dan moet het van disk gehaald worden. De route loopt via device drivers, pci bus, san/nas connecties, switches, storage controllers, backplane, disk firmware en fysieke hardware. De afstand van dit wandelingetje is van hier….. Naar Pluto.
Een groot deel van deze reis is het wachten op fysieke beweging. Het positioneren van de disk arm, en het draaien van de schijf.
Gelukkig is daar tegenwoordig een oplossing voor, in de vorm van Solid State Disk. Daarmee wordt de reistijd met een factor 10 ingekort. We hoeven nog maar naar Jupiter..
Duidelijk mag zijn dat een disk I/O zeer kostbaar is ten opzichte van CPU en geheugen toegang. Er moet dus zeer goed nagedacht worden over hoe de reis naar Pluto of Jupiter ingericht wordt, en of we kunnen voorkomen dat die reis ondernomen wordt.
Harddisks vormen nog altijd het leeuwendeel van storage systemen. Het zijn mechanische devices die door hun opbouw erg veel invloed hebben op de responsetijd van elke I/O. Die tijd wordt bepaald door de gemiddelde zoektijd (de tijd dat het armpje met de lees/schrijfkop onderweg is) en de rotatiesnelheid. Het feit dat een 7.2K SATA schijf langzamer is dan een 15K SAS schijf is puur een functie van de rotatiesnelheid.
Latency is een killer voor end-user performance. Naarmate disks meer I/O opdrachten verwerken, wordt de latency hoger. Zeker richting volle belasting gaat dat exponentieel omhoog. Dat heeft ook zijn weerslag op storage systemen die uit vele tientallen disks opgebouwd zijn. Zie bijvoorbeeld het rechter grafiekje. Een relatief kleine verhoging van de belasting heeft een forse stijging van de latency tot gevolg.
Van 16 IOPS naar 18 IOPS = van 80% naar 90% utilization -> Latency 1.5 keer zo groot
Met brute kracht kan alles
Heel veel disks combineren
Maar ook latency (transport telt zeker mee)
All-SSD is de snelste methode, maar kost een paar stuivers.
Niet alle SSD is hetzelfde (Cache? Tier?)
===
Optimaal VDI image
Geen ‘last access time’ op files
Geen achtergrondprocessen (defrag, index, search)
Onnodige apps/startups uitschakelen
Het Golden Image is een momentopname. Het is een moving target wat aandacht vereist, wat up-to-date gehouden moet worden. Dat kan gevolgen hebben voor de I/O load. Zeker als een update meer geheugen vereist kan dit extra swap activiteit veroorzaken.
Ook kunnen updates de zorgvuldig gekozen instellingen veranderen. Bijvoorbeeld een instelling om geen automatische updates te ontvangen en te installeren kan door een nieuwe versie overschreven worden. Let daarbij op virusscanners. Een ‘scheduled scan’ tijdens kantooruren kan de performance flink beïnvloeden.
Als klap op de vuurpijl kunnen updates een gedwongen reboot veroorzaken. Een reboot die kortstondig een zeer hoge I/O load op het storage systeem kan veroorzaken. De reboot van één systeem is wellicht geen drama, maar als de helft of alle Virtual Desktops tegelijk rebooten dan hebben we te maken met een Boot Storm
Zet tijdens de pilot fase realistische limieten op de beschikbare resources
Gebruik schaalbare hardware die representatief is voor de pilot groep
- of –
Gebruik een load generator om de rest van de gebruikers te emuleren
Maak gebruik van Quality of Service functies in servers, netwerk en storage
Monitor vooral het gedrag van de storage systemen en stuur bij waar nodig
Begrijp de afwijkingen van het applicatiegedrag
Proact wil u graag helpen bij het kiezen van de juiste storage architectuur.
Met de services, kennis en keuzevrijheid van Proact ligt er een succesvol VDI project in het verschiet!
Ik wens u een goede reis.