Virtualisatie op basis van volledige virtuele machines is inefficiënt. Het domweg copiëren van complete besturingssystemen kost heel veel geheugen. Is het wel nodig dat alle systemen op alle systemen kunnen draaien? Voor de consolidatie van tweehonderd Windows-servers heb je immers alleen een systeem nodig dat meerdere Windows-servers kan draaien.
De virtualisatie van servers kan tientallen procenten aan besparingen opleveren op hardware, onderhoud en stroomkosten. Desondanks is virtualisatie als technologie zelf nog steeds bijzonder inefficiënt. Voor elke applicatie wordt immers weer een complete copie van het besturingssysteem aangemaakt, inclusief alle libraries. Een gevirtualiseerde infrastructuur stelt daarom veel meer eisen aan het geheugen van de systemen, zowel in hoeveelheid als in bandbreedte. Daarmee vormt het geheugen een beperking op het aantal virtuele machines dat op een server kan worden gedraaid.
Brute force
Leveranciers van hypervisors proberen op verschillende manieren deze belasting van het geheugen terug te dringen. VMware gebruikt daarvoor (Content-Based) Transparent Page Sharing (TPS) en Ballooning. Die eerste technologie mapt logische pagina's met dezelfde inhoud uit verschillende virtuele machines op dezelfde fysieke pagina's. Pas als een pagina verandert, wordt een nieuwe copie daarvan gemaakt (copy-on-write). Hoewel dit een weinig intelligente, brute force oplossing is — tijdens lage belasting worden hash codes van de pagina's gemaakt en met elkaar vergeleken — is het volledig transparant voor de virtuele machines.
Om de processoren van de virtualisatie-servers flink aan het werk te kunnen zetten, moeten bovendien voldoende virtuele machines naast elkaar in het geheugen kunnen worden gezet (Memory Overcommit). Hoewel er ook transparante technologieën zijn waarbij de hypervisor verantwoordelijk is voor het swappen van geheugenpagina's, is dat geen beste oplossing. Daarbij wordt immers een tweede laag swapping-technologie onder die van de verschillende besturingssystemen gelegd. Bovendien heeft die laag weinig zicht op de pagina's die het beste naar disk geswapped kunnen worden.
Swapping
Bij Ballooning worden eerder toegekende pagina's door de hypervisor van de virtuele machines teruggepakt via een speciale driver in het guest operating system. Deze dwingt het besturingssysteem geheugenpagina's uit te swappen. Worden grote stukken van een virtuele machine niet gebruikt, dan krimpt onder druk van de hypervisor het aantal pagina's in het fysieke geheugen. Deze worden weer binnengehaald als de virtuele machine weer tot leven komt.
Voordeel van deze aanpak is dat hierbij gebruik gemaakt wordt van de paging-functionaliteit van het operating system. Nadeel is dat er in het besturingssysteem met die balloon driver gerommeld kan worden, met mogelijke performance-consequenties voor de andere virtuele machines. Levert Ballooning geen vrije pagina's meer op, dan valt ESX Server terug op een eigen paging-functie.
Goedkoop
In navolging van VMware zijn ook XenSource (tegenwoordig onderdeel van Citrix) en Microsoft inmiddels met ballooning aan de slag. Versie 3.2 van de hypervisor (de basis onder XenServer 4.2) ondersteunt deze technologie voor Linux en geparavirtualiseerde systemen. XenServer 4.1 bevat ballooning wel als optie maar deze wordt vanwege stabiliteitsproblemen niet ondersteund door Citrix. XenServer is echter georiënteerd op een markt waar de meeste virtuele machines op Windows zijn gebaseerd. Daar helpt memory ballooning van Linux en geparavirtualizeerde systemen niet veel,
aldus een woordvoerder.
Belangrijk is dat XenSource tot voor kort een andere benadering nastreefde. Hun hypervisor deed zelf helemaal geen I/O, en dus ook geen memory management. Hun idee: geheugen is goedkoop; koop gewoon bij, dan is je probleem opgelost. Inmiddels geven ze toe dat allerlei workloads voordeel kunnen hebben bij Memory Overcommit, en dat 64 Gbyte aan DIMM's toch een behoorlijke uitgave is. De technologie die nu in Xen 3.3 wordt geïmplementeerd, zal dan ook worden opgenomen in nieuwe versies van XenServer.
Oneigenlijk gebruik
Uit de introductie van de ballooning-technologie blijkt al dat de veelgeroemde stricte scheiding tussen hypervisor en virtuele machines niet goed vol te houden is. Virtualisatie is dan ook nooit bedoeld geweest voor het optimaliseren van computing resources. Het is ooit voor het mainframe bedacht om nieuwe versies van het besturingssysteem te kunnen testen. En velen zijn alweer vergeten dat VMware uit dezelfde hoek komt: hun eerste product was gericht op software-ontwikkelaars die daarmee veel gemakkelijker hun test-omgeving konden opzetten.
Je zou zelfs kunnen spreken van oneigenlijk gebruik. Volgens Martin Hingley, Chief Research Officer IDC Europe, heeft VMware zijn succes in de server-markt te danken aan de beperkingen van Windows. Daardoor zitten we nu met enorm veel losse systemen in het rekencentrum, die elk maar één applicatie draaien.
De vraag is dan ook of server-virtualisatie niet slechts een tussenstap is op weg naar een betere afscheiding tussen de verschillende applicaties op één enkel operating system. De belangrijkste functies van het besturingssysteem zijn immers het creëren van een veilige omgeving voor de applicaties, tools voor het beheer daarvan, en het delen van resources. Die verworvenheden zijn nog steeds waardevol, ondanks dat VMware ons anders wil doen geloven.
Containers
Marcel den Hartog, CA's mainframe marketing manager voor EMEA, hield onlangs in Automatisering Gids met soortgelijk argumenten een pleidooi voor het mainframe. Maar ook in de Unix- en X86-wereld zijn al veel efficiëntere manieren van virtualisatie te vinden. Zo delen de Containers in Sun Solaris allemaal dezelfde kern van het besturingssysteem. Hetzelfde geldt voor de Virtuozzo Containers van Parallels.
Bij virtualisatie op OS-niveau worden alleen van die onderdelen die per container verschillen meerdere instanties onderhouden (qua principe vergelijkbaar met processor multi-threading). Terwijl zo naar boven toe steeds een volledig operating system wordt aangeboden, worden aan de onderkant stiekem steeds dezelfde onderdelen gebruikt.
Hoewel dit een intelligentere oplossing is dan het domweg zoeken naar dubbele pagina's zoals dat bij TPS gebeurt, beperkt virtualisatie op OS-niveau zich wel tot de besturingssystemen die door het onderliggende systeem vantevoren worden ondersteund. Er worden immers geen compleet onafhankelijke virtuele machines gebruikt. Sun lost dat op met de branding van containers: Branded Zones (BrandZ). Behalve Solaris zelf wordt op die manier ook Linux ondersteund. Misschien moeten we ons eerst afvragen of het voor de verbetering van de efficiëntie inderdaad wel nodig is dat elk besturingssysteem op elk ander kan draaien.
Nederlands (nl-NL)
English (United Kingdom) 
Plaats reactie