De integratie van opslag met een virtuele desktop infrastructuur

1. Case study
VDI & Storage: De integratie van opslag met
een virtuele desktop infrastructuur
Client computing in al zijn vormen is klaar voor deel. In een traditioneel storage systeem neemt een virtuele desktop,
de invoering van virtualisatietechnologie. Net zoals met in begrip van configuratiebestanden, guest OS en applicaties, tussen
virtualisatie de utilisation rate, beheerbaarheid en de 8 en 10GB in beslag. Voor de creatie van meerdere VDI’s zijn er dan
kosteneffectiviteit van servers en de storage infra- excessief grote hoeveelheden storage capaciteit nodig die vaak in het
Terabyte bereik lopen. Storage provisioning en updates bij desktop images
structuur hebben verhoogd, zo zullen ook desk-
kunnen ook een probleem vormen omdat het een lastig en tijdrovend
tops en laptops van deze technologie profiteren.
beheerproces is. Hiervoor is het in ieder geval van belang dat OS-image
Immers, een VDI-gebaseerde infrastructuur maakt en gebruikersdata worden gescheiden ten behoeve van updates en
virtuele desktops hardware-onafhankelijk en is in beschikbaarheid.
principe geschikt voor ieder operating system.
Door het gebruik van slechts één OS speelt de compatibility bij applicaties
minder een rol in vergelijking tot een omgeving op basis van terminal
servers. De implementatie van een virtuele desktop is ook eenvoudiger
en biedt gebruikers meer vrijheid van handelen.
Ondanks de vele voordelen, ondervonden de early adopters van het VDI
concept een aantal tekortkomingen, waarmee tevens de voornaamste
aandachtsgebieden werden blootgelegd:
• Capaciteitsefficiency
• Prestatie optimalisatie Golden Images
• Beschikbaarheid
Als antwoord op de genoemde problemen is een aantal storagefabrikanten
Capaciteit efficiency met specifieke oplossingen voor VDI gekomen. Een aantal daarvan brengen
op hun storage-array’s extra voorzieningen voor de virtuele omgeving aan.
De aanmaak van een nieuwe virtuele desktop geschiedt met behulp van Daarbij maken storage array’s in combinatie met VDI gebruik van snapshot-
een volledige kopie of via de traditionele snapshotmethode vanaf een technologie voor het klonen van VDI’s, waarbij de kloon verwijst naar een
golden boot image. Bij een volledige kopie wordt meerdere malen dezelfde ‘golden’ master boot disk. Deze klonen zijn beschrijfbare snapshots die via
data opgeslagen want desktop boot-images overlappen voor een groot pointers gekoppeld zijn aan het master image. Met behulp van ‘thin copy’

2. technologie zijn besparingen tot 90% mogelijk op de voor VDI totaal benodigde storage capaciteit.
Dit thin storage concept stroomlijnt ook het provisioning proces van VDI’s doordat binnen seconden
met behulp van scripts of automatisch een VDI is te creëren.
Ook de server-gecentreerde oplossing is gebaseerd op een master image en pointers naar de VDI
klonen. Zo maakt VMware via de View Composer gebruik van de Linked Clone technologie om
een nieuwe VM te creëren op basis van een golden image. Bij het aanbrengen van een patch of
upgrade hoeft de beheerder dan alleen maar de golden image aan de top van de snapshot tree
aan te passen en worden vervolgens de referenties naar de onderste ‘takken’ aan deze nieuwe
image versie gekoppeld. Via dit update proces kan een beheerder snel en effectief honderden of
duizenden VDI images vanuit een enkele console updaten.
Prestatie optimalisatie
Een ander kritisch punt betreft de prestatieproblemen bij grootschalige toepassing van VD’s
met shared storage. Die treden op wanneer, bijvoorbeeld als gevolg van bootstorms en antivirus
operaties, veel schrijf/lees (I/O (input/output) activiteiten plaatsvinden. Bij een traditionele desktop
vormde dit meestal geen probleem omdat elk zijn eigen disk volume(s) lokaal bezat en de I/O
activiteit tot het systeem zelf beperkt bleef. Bij toepassing van virtual machines moeten de
beschikbare I/Os van de centrale storage echter gedeeld worden met andere VM’s. Dat kan,
zeker bij grootschalige toepassing van VM’s, prestatieproblemen opleveren.
De eerste VDI gebruikers werden geconfronteerd met een slecht presterende virtuele desktop.
Met name bij het gelijktijdig inloggen van een grote groep gebruikers en het booten van de
virtuele desktop werd dit duidelijk. De belangrijkste oorzaak van deze slechte prestaties bij
grootschalige toepassing van VD’s en shared storage zijn het aantal IOPS (IOs per seconde)
die een VD tot zijn beschikking heeft.
Virtuele Desktops en IOPS
In een bootproces wordt het basis-OS en een aantal bijbehorende services opgestart, bijvoor-
beeld voor file indexering, geïnstalleerde hardware en andere services. Samen genereren ze veel
IOPS, waarbij het OS tracht zo goed mogelijk de random I/Os te optimaliseren door de disk reads
en writes ‘contiguous’ uit te voeren. Opmerkelijk hierbij is het feit dat op een virtuele desktop
veel van de genoemde services overbodig zijn en zelfs contraproductief werken. Het probleem
De voornaamste
hierbij is dat het geïnstalleerde guest OS niet weet dat het binnen een virtuele omgeving draait
aandachtsgebieden en de hardware moet delen met de andere guest OS’s die op de fysieke server draaien. Een
van VDI zijn: standalone desktop met een SATA lokale disk kan maximaal tussen de 40 en 50 IOPS leveren.
• Capaciteitsefficiëntie Een licht belaste desktop vraagt slechts enkele I/Os, wat kan oplopen tot 20 I/Os voor een zwaar
• Prestatie optimalisatie belaste desktop. In de praktijk is gebleken dat de read/write verhouding 50/50 is, maar soms
• Beschikbaarheid veel slechter, tot 1 op 10. Het zijn daarbij de write IOPS die het meeste ‘kosten’. Gelukkig bestaat
een bootproces voor meer dan 90% uit read IOPS waarbij de hoeveelheid write IOPS tijdens het
loginproces kan toenemen, maar de meeste IOPS blijven toch reads. Wanneer virtuele desktops
massaal een boot- en login proces starten is er een significant aantal IOPS nodig; een piekbelas-
ting die de meeste traditionele storagesystemen niet kunnen adresseren.

3. Tot voor kort werden traditionele methodes toegepast om deze hoge piekbelasting op te vangen,
bijvoorbeeld vergroting van het cache op de server of het storage systeem, dan wel het toevoe-
gen van ‘spindles’ (disken) of zelfs complete storage devices. Een meer geavanceerde oplossing “Een standalone
voor het boot- en login probleem is om de disk I/O leesoperaties rechtsreeks vanuit de storage desktop met een
cache of een SSD te laten uitvoeren. Dit bespaart disk I/O cycles die vervolgens vrijkomen voor
lokale SATA disk kan
write I/Os die rechtstreeks naar disk gaan.
maximaal tussen
Storagesystemen bieden ook een oplossing voor de boot- en login stormen door een gecombi- de 40 en 50 IOPS
neerd gebruik van intelligente snapshots en adaptive caching. De caching technologie herkent leveren.”
automatisch dat overwegend het grootste deel van de data tussen de bootklonen identiek is,
zodat slechts één kopie van de gemeenschappelijke data in cache hoeft te worden opgeslagen.
De adaptive caching is op zijn beurt weer afhankelijk van intelligente snapshots wat het mogelijk
maakt om de data die gemeenschappelijk is tussen de verschillende storage volumes in het
cache te sharen. Door het boot image vanuit cache te laden, in plaats vanaf een hard disk,
wordt een hoge bootsnelheid behaald.
Beschikbaarheid
Voor een hoog beschikbare VDI omgeving is een centrale opslagoplossing vereist. Helaas vormt
deze tegelijkertijd een single point of failure. Om die reden is het van belang dat het opslag-
systeem is opgebouwd uit redundante componenten en voldoende databeschikbaarheid biedt.
Maar ongeacht de op lokaal niveau aanwezige redundantie, het blijft één opslagsysteem waardoor
bijvoorbeeld bij stroomuitval de totale VDI omgeving niet langer beschikbaar is. Daarnaast speelt
ook het service window bij VDI een steeds belangrijkere rol. Zo moeten in een VDI omgeving eerst
alle virtuele systemen volledig worden afgesloten voordat het centrale storage systeem kan worden “Voor een hoog
uitgeschakeld voor onderhoud, ook al is het maar voor een reboot van slechts enkele minuten. beschikbare VDI
omgeving is een
Wanneer bij volledige uitval van het centrale storage array er een restore vereist is, kan het meer- redundante centrale
dere dagen duren voordat een nieuw storage array en alle bedrijf kritische data weer beschikbaar
opslagoplossing
is. Dit is voor de meeste organisaties niet toelaatbaar. Ditzelfde geldt voor niet-beschikbaarheid
als gevolg van een centrale storage onderhoudsactie. Een veel gebruikte oplossing hiervoor is
vereist.”
de toepassing van (geografische) gescheiden opslagsystemen waarbij een kopie beschikbaar is
van de primaire omgeving op een tweede storage array en -locatie. Bij geografische scheiding
van de dataopslag ten behoeve van beschikbaarheid zijn er grofweg twee verschillende storage
oplossingen:
• Data replicatie tussen twee onafhankelijke storage arrays
• Geografische storage-clustering

4. Storage replicatie vs. -clustering
“Bij de implementatie van Datareplicatie kan op meerdere manieren en volgens verschillende technologieën gereali-
een VDI concept wordt seerd worden. Bij het kiezen van de meest geschikte replicatiemethode zijn de belangrijkste
uitgangspunten; welke soort gegevens moeten worden beveiligd en hoeveel van die gegevens
de afhankelijkheid van
mogen eventueel verloren gaan. Het is daarbij belangrijk te bedenken dat datareplicatie op zich
de beschikbaarheid en nog geen uitwijk is. Storage-gebaseerde replicatie zorgt immers alleen voor een kopie van de
performance van het dataset op een tweede locatie. Bij uitval van het centrale storage array zullen alle dataservices
onderliggende centrale niet-beschikbaar worden, omdat een host een vaste relatie heeft met één storage array welke
opslagsysteem sterk niet automatisch en/of online gewijzigd kan worden zodat transparant gebruik wordt gemaakt
vergroot. ” van de gerepliceerde dataset. Dit geldt voor elk besturingssysteem, ongeacht of deze in een
clusteropstelling draaien. Ook
clusters maken immers gebruik van één centraal storage array voor hun gedeelde storage. Alle
gerepliceerde datasets dienen handmatig actief gemaakt te worden en vervolgens eveneens
handmatig gekoppeld te worden aan (eventueel) beschikbare of
te installeren hosts op de tweede locatie. Met standaard replicatie is uitwijk dus altijd
een handmatig proces, wat met bepaalde tools (deels) te automatiseren is.
Automatische uitwijk zonder oneschikbaarheid is wel mogelijk met storage clustering.
Bij een calamiteit op één van de twee geclusterde storage controllers zal de identiteit van deze
controller over gaan naar de andere controller of bieden de geclusterde controllers één identiteit
naar de servers en/of gebruikers toe. Hierdoor blijft een host wel de connectie behouden met
de centrale storage omgeving, ook al is de functie van de originele controller reactief (calamiteit)
of proactief (preventief onderhoud) overgenomen door diens tegenhanger op de andere locatie.
Replicatie blijft een onderdeel van storage clustering om data op beide locaties beschikbaar te
hebben, maar wordt bij storage clustering aangevuld met de intelligentie om ook de gerepliceer-
de dataset transparant beschikbaar te stellen aan de host, zonder tijdelijke onbeschikbaarheid.
De replicatie bij storage clustering is gebaseerd op synchrone replicatie om de datasets op beide
locaties identiek te hebben en bij een failover dataconsistentie te kunnen waarborgen.
Conclusie
Om die reden is het van groot belang bij het ontwerp van de laatste sterk de nadruk te leggen op
capaciteitsefficiency, prestatie optimalisatie en (hoge) beschikbaarheid.
PROACT is gespecialiseerd in het managen, beveiligen en opslaan van grote hoeveelheden bedrijfskritische informatie.
Als onafhankelijke integrator leveren wij consultancy, services, support en systemen voor storage, back-up en archivering.
De PROACT groep heeft ongeveer 320 gespecialiseerde medewerkers en is vertegenwoordigd in Nederland, Zweden,
Denemarken, Finland, Noorwegen en de Baltische Staten. PROACT is opgericht in 1994 en de moederorganisatie PROACT
IT Group is sinds 1999 beursgenoteerd.
Proact Netherlands B.V.
+31 35 70 70 525 info@proact.nl www.proact.nl