Virtualisatie: op weg naar echte operationele continuïteit
Nog meer dan bij een traditionele, fysieke omgeving, is de continuïteit van een gevirtualiseerde oplossing kritiek voor een onderneming. Alleen ligt het pad daar naartoe bezaaid met allerlei mogelijke struikelblokken.
Servers virtualiseren levert plaatswinst op, zorgt dat er niet onnodig servers worden bijgekocht en beperkt de administratie tot een kleiner aantal systemen, maar houdt ook een groter risico in: namelijk dat de server waarop x VM staat of een van zijn (hardware- of software)componenten, het begeeft. Dat zou immers betekenen dat een hele infrastructuur verlamd geraakt en dat een heleboel applicatieprocessen mogelijk stil komen te liggen.Continuïteit is dus zeer belangrijk.
"De eerste stap in een VM-herstelstrategie moet zijn: de bedrijfskritische waarde van de verschillende VM's inschatten", klinkt het bij Double-Take Software. Die kritische waarde kan worden bepaald op basis van het aantal of het soort gegevens dat men mag verliezen zonder dat daar zware gevolgen aan vastzitten (het fameuze Recovery Point Objective (RPO)-principe) en op basis van de snelheid waarmee de applicatie hersteld moet kunnen worden (oftewel de Recovery Time Objective (RTO).
In alle omstandigheden
De continuïteit van de virtuele servers kan worden verzekerd via back-up/restoreprocedures of, met kortere tussenpozen, via replicatie (omdat back-ups het prestatievermogen of de systeembeschikbaarheid te veel beïnvloeden).
We moeten hier een onderscheid maken tussen twee scenario's (die elkaar helemaal niet uitsluiten). Enerzijds zijn er de 'preventieve' verrichtingen (snapshots, replicatie, etc.), het maken van kopieën (waarbij de 'dubbels' van de VM geïnstalleerd worden op dezelfde of een andere fysieke server), die in geval van nood de operationele continuïteit moeten garanderen. Anderzijds zijn er de migratieverrichtingen (transfers) van de VM naar een andere server als de eerste server verzadigd geraakt of minder krachtig begint te presteren. In dat laatste geval mag men een aantal zaken niet uit het oog verliezen. Voor een hotswap in real time zonder onderbreking van het systeem, moeten de fysieke bron- en doelserver een identiek OS plus identieke processors aan boord hebben. Ieder detail is daarbij van belang: het cachegeheugen, de controller en voor bepaalde hypervisors zelfs de klokfrequentie. Bij Citrix bijvoorbeeld leidt een eenvoudig verschil in kloksnelheid automatisch tot downtime (al is die heel kort). Dat geldt dan weer niet voor VMware. Hyper-V van Microsoft blijft voorlopig het enige systeem dat in alle omstandigheden een reboot vergt (in 2010 zou evenwel een Live Migration worden aangeboden in plaats van de bestaande Quick Migration en het verschil is niet klein!). Als de processors aan de twee kanten tot een andere generatie behoren, leidt dat ook weer tot downtime. Er moet dan namelijk een shutdown gebeuren, gevolgd door een reboot.
"Live migraties (zoals bijvoorbeeld met VMotion van VMware) hangen sterk af van de architectuur van de onderliggende processor", zegt Eric De Witte, technisch directeur Erudict. "Het is absoluut noodzakelijk om de fysieke servers die de virtualisatiecluster vormen te standaardiseren om de overdracht tussen de systemen mogelijk te maken zonder de service te hoeven onderbreken. Vroeger was dat een groot probleem, bijvoorbeeld als men een cluster wilde uitbreiden om meer bronnen toe te kennen. Processorfabrikanten (Intel, AMD) hebben echter een hardwarematig trucje gevonden waarmee een processor van de nieuwe generatie - op voorwaarde dat de virtualisatieomgeving dit ondersteunt, wel te verstaan - zich tegenover de VM kan voordoen als een processor van de vorige generatie (nvdr: degradatieprincipe). De VM 'ziet' dus geen architecturaal verschil tussen de oude en de nieuwe, zodat de live migratie zonder serviceonderbreking normaal kan doorgaan. (nvdr: de VM beschikt dan wel niet over de specifieke processorfuncties van de laatste generatie). Toch moeten we opmerken dat in deze procedure de cluster geherconfigureerd moet worden om de functionaliteit te activeren".
Live migratie tussen verschillende generaties wint ondanks alles terrein. De fabrikanten zijn ermee bezig. Intel heeft bijvoorbeeld zijn Flex Migration-techniek en is die voortdurend aan het verbeteren. Met die techniek kan VMotion op verschillende CPU's worden uitgevoerd.
"In sommige gevallen is VMotion tussen verschillende architecturen niet mogelijk omdat de besturingssystemen geen hotswap van de CPU ondersteunen. Toch worden besturingssystemen meer en meer uitgerust met hot-add- of hot-remove-functies, bijvoorbeeld voor het geheugen, de harde schijven... Van zodra een hot change van de CPU tot de mogelijkheden gaat behoren, worden alle VMotion-functies mogelijk", zegt Jeremy van Doorn, manager system engineers bij VMware. Alleen is het niet duidelijk of dat op korte of lange termijn zal gaan gebeuren.
Als het overstappen van de ene processorgeneratie naar de andere al narigheid oplevert (vooral met bepaalde hypervisors), hoe problematisch moet het dan niet zijn om een VM van een Intel-server naar een AMD-systeem te migreren... Door de verschillen tussen deze twee soorten processors moet de VM op het bronsysteem worden stilgelegd en heropgestart op het doelsysteem. In bepaalde gevallen moet de configuratie zelfs gewijzigd worden. Bijvoorbeeld voor Linux-kernels, die specifiek gecompileerd zijn voor gebruik met deze of gene processor. Voorlopig ziet het er niet naar uit dat de fabrikanten het probleem samen willen aanpakken. Eigenbelang primeert...
Naar een heterogene, virtuele omgeving?
Wat compatibiliteit betreft, hoeft het wellicht geen betoog dat de verschillende hypervisors (nog) niet onderling compatibel zijn. Een VM van een VMware-omgeving overbrengen naar Hyper-V of Xen is dus uitgesloten. Er bestaan natuurlijk wel invoer- en omzettingstools, maar dat zijn in de verste verte geen technieken voor het uitwisselen of swappen in reële tijd. Bare metal restore is hier de boodschap. OVF (Open Virtualisation Framework) kan - op termijn - de overdraagbaarheid verbeteren door de formaten te harmoniseren. Op voorwaarde dat alle betrokken partijen daar in alle openheid en zonder voorbehoud aan meewerken en ze allemaal dezelfde, toekomstige OVF specs gebruiken... API's zijn nog een andere piste.
"Het is heel belangrijk om binnen ons eigen ecosysteem zo open mogelijk te zijn", vindt Anne-Mie Foucart, directrice VMware Benelux. "Maar de voorwaarde voor succes is een goede samenwerking. Wie (zijn eigen API's) ook deelt met de concurrentie, maakt kans om een belangrijke rol te spelen in datacenters".
Is er dan hoop op samenwerking? Thomas De Fonseca, consultant bij Avanade, heeft zo zijn twijfels. "VMware zegt dat het klaar is om het beheer van heterogene (virtuele) omgevingen te bevorderen, maar heeft nog geen concrete stappen gezet. Er is nog geen ondersteuning voor concurrerende oplossingen, zoals bijvoorbeeld Hyper-V van Microsoft. Ook niet in de allernieuwste generatie oplossingen (nvdr: het zopas geïntroduceerde vSphere 4). Het bedrijf zegt 'klaar te zijn', maar dan wel op voorwaarde dat de andere spelers een kritieke massa bereiken. In afwachting zegt het liever in zijn eigen technologie te investeren dan in compatibiliteit".
Hoe zit het bij Microsoft? "De nieuwe SCVMM (System Center Virtual Machine Manager) ondersteunt VM-beheer, op voorwaarde dat de klant over een Virtual Center-licentie van VMware beschikt. Overigens kan de console van Microsoft wel VMware VM's aanmaken en opstarten via templates en VM's stopzetten, maar blijft ze niettemin beperkt qua functionaliteit. Ze kan bijvoorbeeld niet overweg met VMotion en biedt geen ondersteuning voor ESXi, de open source-versie van ESX".
De harde cijfers
We berekenen per projector gewogen performantie- en prijsperformatiescores op honderd punten. De technisch hoogst scorende projector is onze top performer, terwijl de projector met de beste prijsperformatiescore van ons het label best buy krijgt.
