Vijf manieren om x86 s te virtualiseren

Virtualisatie DOOR Bram Dons Containervirtualisatie verplettert concurrerende technieken Vijf manieren om x86 s te virtualiseren 28 STORAGE MAGAZINE s p e c i a l i s s u e Toen virtualisatie de oversteek maakte van het RISC-systeem naar het x86-platform, is men de techniek gaan aanpassen zodat deze beter zou functioneren in de nieuwe omgeving. Verschillende ontwikkelaars kozen hierbij verschillende paden, voortbouwend op het werk van anderen. Inmiddels zitten we aan de vijfde generatie van virtualisatietechnieken. De afgelopen drie, vier jaar werden gekenmerkt door de razendsnelle groei van virtualisatie op de x86-architectuur. Deze architectuur heeft zich inmiddels bewezen als een geschikt platform voor de enterpriseomgeving. De huidige generatie x86 CPU s bevat onder meer features als multithreading, ondersteuning van grote geheugensystemen, high-speed CPU-verbindingen en virtualisatie. Dergelijke features waren voorheen alleen voorbehouden aan mainframes en RISC-Unixsystemen. Maar voordat virtualisatie op de x86-architectuur realiteit werd, moest nog wat onderzoek en ontwikkeling worden uitgevoerd. Ontwikkelaars zijn verschillende richtingen op gegaan bij het zoeken naar een virtualisatieoplossing: binary translation, paravirtualisatie, K, hardware-assisted virtualization en containers. We zullen ze in dit artikel een voor een belichten en zien wat de voor- en nadelen van elke technologie zijn. Privilegeniveaus Van oorsprong heeft de door Intel ontworpen x86-cpu-architectuur vier hiërarchisch georganiseerde privilegeniveaus oftewel privilegeringen: ring 0 tot en met 3 (zie figuur 1). Ring 0 kent de meeste privileges, heeft volledige toegang tot de hardware en is bevoegd om geprivilegieerde instructies uit te voeren. Het OS draait in ring 0, waarbij de kernel het OS toegang verleent tot de onderliggende hardware. Ringen 1, 2 en 3 draaien op een lager niveau en mogen geen instructies uitvoeren die zijn gereserveerd voor het OS. In het algemeen worden operating systems, zoals Linux en Windows, in ring 0 gedraaid. De gebruikers zitten in ring 3. Ring 1 en 2 hebben de moderne commerciële OS en nooit gebruikt. Hoewel dit model voordelen biedt voor de ontdekt dat hij een is traditionele baremetaltoepassingen, is het voor een virtuele omgeving echter ongeschikt. In een virtuele omgeving moet de hypervisor, het programma dat de virtuele omgeving bestuurt, namelijk op het hoogste privilegeniveau draaien, zodat hij toegang heeft tot alle hardware en systeemfuncties. In dit model draaien de virtual machines ( s) in een lagere privilegering, meestal in ring 3, met daarbinnen een operating system op basis van virtuele geëmuleerde hardware. Omdat het OS van oorsprong ontworpen is om direct toegang te hebben tot alle hardware, verwacht het in ring 0 te kunnen draaien. Het OS zal daarom privileged calls maken, maar die zijn niet toegestaan in ring 3. Wanneer het OS toch zo n call uitvoert, dan zal de hardware de instructies afvangen en een fout genereren, wat doorgaans de vernietiging van de betekent. De eerste x86 hypervisors, zoals Bochs (een open-source x86-emulator), creëerden een volledig geëmuleerd systeem waarbij de x86 CPU volledig door de software werd nagebootst. Deze techniek presteerde echter slecht, daarom werd een meer geavanceerde techniek ontwikkeld voor toepassing in de latere x86 hypervisors. 1. Binary translation ware was de voortrekker van het model van binary translation, waarbij een direct op de CPU draait in plaats van dat de processor geëmuleerd wordt. Wanneer de CPU een geprivilegieerde instructie tegen- 28 15-02-2011 11:14:04

komt, vangt hij deze af, dit noemt men trapping. Deze trap wordt daarna door de hypervisor afgehandeld en geëmuleerd. Er zijn echter een paar x86-instructies, bijvoorbeeld pushf of popf, die geen trap genereren. Er zijn ook gevallen waarin de erachter kan komen dat hij in ring 3 draait. Om met dit soort gevallen om te kunnen gaan, is de techniek binary translation ontwikkeld (zie figuur 2). In dit model scant de hypervisor het geheugen van de en onderschept ongeoorloofde calls voordat ze uitgevoerd kunnen worden. Vervolgens wordt de code dynamisch in het geheugen aangepast. Het is een vorm van dynamische aanpassing van programmacode die programmeurs verafschuwen, maar dat neemt men op de koop toe. De operating system kernel is zich niet bewust van deze aanpassing en zal normaal zijn werk doen. De combinatie van trapand-execute en binary translation staat elk x86 operating system toe om ongemodificeerd boven de hypervisor te draaien. Hoewel deze benadering complex is om te implementeren, biedt zij het voordeel van een belangrijke prestatiewinst in vergelijking met volledige emulatie van de CPU. Full virtualization biedt de beste isolatie en beveiliging voor s en maakt migratie en overdraagbaarheid eenvoudig, omdat dezelfde guest OS instance gevirtualiseerd of op native hardware kan draaien. Behalve ware gebruikt ook Microsofts Virtual Server deze virtualisatietechniek. Applications Operating System Emulated Hardware Physical Hardware Ring 3 Ring 2 Ring 1 Applications Operating System Emulated Hardware Hypervisor Figuur 1: x86-architectuur met privilegeniveaus Ring 0 User Apps Guest OS Host Computer System Hardware Ring 3 Ring 1 & 2 Ring 0 Direct Execution of User Requests Binary Translation of OS Requests STORAGE MAGAZINE special issue 29 2. Paravirtualisatie De methoden van emulatie en binary translation richten zich op de geprivilegieerde instructie die de moet afhandelen. Het opensourceproject Xen heeft echter voor een andere methode gekozen. In plaats van de geprivilegieerde instructie af te handelen, wordt het guest OS tijdens het draaien in de aangepast middels paravirtualisatie. Alle geprivilegieerde instructies worden daarbij vervangen door directe calls aan de hypervisor. In dit model is het gemodificeerde guest OS zich er wel degelijk van bewust dat het op een hypervisor draait en werkt het met de hypervisor samen om de scheduling en I/O te verbeteren. Dit neemt de noodzaak weg om hardwaredevices te emuleren, zoals netwerkkaarten en diskcontrollers. Voor paravirtualisatie, ook wel OS-assisted virtualization genoemd, moet het OS worden aangepast, daarom kan dit alleen gedaan worden door de leverancier van het OS (zie Figuur 2: Binary translation, hierbij zit het Os niet in ring 0 (bron: ware) figuur 3). Zo werden bij Linux de veranderingen aan het OS oorspronkelijk aangebracht in de vorm van custom patches van de Linux kernel, pas veel later werden ze vast in de Linux kernel opgenomen. In een dergelijk virtualisatiemodel is de Xen hypervisor verantwoordelijk voor de kernactiviteiten van het gevirtualiseerde systeem, zoals CPU-interactie, geheugenvirtualisatie, powermanagement en de scheduling van s. De hypervisor laadt een speciale privileged, domein nul oftewel domain0 (dom0) geheten, die direct toegang heeft tot de hardware. Deze verzorgt de devicedrivers en het I/O-management voor de s. Elke, een unprivileged domain (domu), bevat een gemodificeerde Linux kernel die rechtstreeks met de hypervisor communiceert in plaats van met de hardware-interfaces. CPU en geheugen worden hypervisor ONDERSChEPT ONGEOORlOOfDE CAllS direct door de Xen hypervisor afgehandeld, alleen I/O verloopt via domain0. De requests voor I/O lopen via het backendproces in domain0, dat alle I/O bestuurt. Domain0 kan als Linux, BSD of Solaris worden geïmplementeerd, maar meestal wordt gekozen voor een gemodificeerde Linuxdistributie. Red Hat, Citrix en Oracle gebruiken allemaal een domain0 dat is gebaseerd op Red Hat Enterprise Linux 5-broncode met de 2.6.18 kernel. Hoewel Xen vaak wordt gecategoriseerd als een thin hypervisor van type 1, is voor het complete platform een domain0 OS nodig dat toegang geeft tot de hardware. 3. kernel-based virtual machines Het project dat werkt aan een systeem voor kernel-based virtual machines (K) vertegenwoordigt de jongste generatie van de open-source virtualization. Doel van het project was om een moderne hypervisor te ontwikkelen op basis van ervaringen die waren opgedaan met technologieën van 29 15-02-2011 11:14:05

30 STORAGE MAGAZINE s p e c i a l i s s u e Ring 3 Ring 2 Ring 1 Ring 0 User Apps Paravirtualized Guest OS Virtualization Layer Host Computer System Hardware Host (Domain 0) Back End Device drivers Virtual Machine (domu) Front end Xen Hypervisor Direct Execution of User Requests Figuur 3: paravirtualisatie, hierbij zit het Os in ring 0 (bron: ware) Figuur 4: architectuur van de Xen hypervisor Hypercalls` to the Virtualization Layer replace Non-virtualizable OS Instructions Front end Virtual CPU & Memory voorgaande generaties en gebruikmakend van de huidige moderne hardware. K wordt geïmplementeerd als een loadable kernelmodule, die de Linux kernel converteert in een zogenoemde bare-metal hypervisor. Het K-projectteam nam twee fundamentele ontwerpbeslissingen op basis waarvan een stabiele en hoogpresterende hypervisor werd ontwikkeld die al snel de andere open-source hypervisors heeft overschaduwd. Ten eerste: omdat K werd ontworpen na de komst van hardware-assisted virtualization, verviel de noodzaak om deze features in de software in te bouwen. De K hypervisor vereist daarvoor Intel VT-x- of AMD-V-enabled CPU s. Ten tweede: het K-team paste een beproefde en bewezen methode toe in plaats van dat ze het wiel opnieuw gingen uitvinden. Omdat de Linux kernel al de kernfeatures bevat die nodig zijn voor een hypervisor en al vijftien jaar een stabiel enterpriseplatform vormt, is het efficiënter om op basis daarvan iets te bouwen dan om alle benodigde componenten, waaronder een memorymanager en BESTAAT uit TEMPlATE PluS AfwIjkINGEN scheduler, opnieuw te ontwikkelen. In dit opzicht heeft het K-project geprofiteerd van de ervaring die is opgedaan met Xen. Een van de problemen van de Xenarchitectuur is de splitsing tussen domain0 en de Xen hypervisor. De Xen hypervisor gebruikt de kernfeatures van het platform om, zoals gezegd, zelf CPU en geheugen af te handelen. De K-ontwikkelaars wilden dit echter ook door domain0 laten doen, maar daarvoor moesten deze functies opnieuw worden ontwikkeld from scratch. Een andere beslissing die het K-team nam, was om de K in de upstream Linux kernel op te nemen. De K-code werd eind december aan de Linux kernel community overhandigd en na acceptatie voor het eerst geïmplementeerd in de 2.6.20 kernel. Vanaf dat moment maakte K een kernonderdeel uit van Linux, dit in tegenstelling tot de Linux kernel patches die nodig zijn voor Xen. De Linuxcommunity-K wordt breed gesteund door leveranciers uit de softwarebranche, zoals AMD, HP, IBM, Intel, Novell, Red Hat, Siemens en SGI. k-architectuur In de K-architectuur wordt de als een regulier Linuxproces geïmplementeerd en door de standaard Linux scheduler aangestuurd. In feite doet elke virtuele CPU zich voor als een regulier Linuxproces, zodat een K kan profiteren van alle features die de Linux kernel biedt. De deviceemulatie wordt afgehandeld door een gemodificeerde versie van Qemu. Deze emuleert BIOS, PCI-bus en USB s en een standaardset aan devices, zoals IDE- en SCSI-diskcontrollers en NIC s. Qemu is een open-source emulatieprogramma dat draait op een beperkt aantal hostarchitecturen, te weten x86-64 en PowerPC. Omdat elke als een Linuxproces is geïmplementeerd, kan hij gebruikmaken van het standaard securitymodel van Linux. De Linux kernel bevat daarvoor Security-Enhanced Linux (SE Linux), een project van het National Security Agency van de VS. K maakt ook gebruik van de krachtige memorymanagementfuncties van Linux. Het ondersteunt de laatste door CPU-leveranciers ondersteunde features voor geheugenvirtualisatie, zoals Intels Extended Page Tables (EPT) en AMD s Rapid Virtualization Indexing (RVI). Memory-page sharing wordt ondersteund via de kernelfeature kernel same-page merging (KSM). Daarbij scant de KSM-functie het geheugen van elke. Waar meerdere s identieke memorypages blijken te hebben, verenigt KSM deze tot een enkele page die onder 30 15-02-2011 11:14:05

CPu krijgt ONDERDANIGE MODuS Applications Virtual Machine Virtual Machine K Linux Kernel x86 Hardware Figuur 5: Kernel-based virtual machine meerdere s kan worden gedeeld. Ook omdat K een onderdeel vormt van Linux, kan het gebruikmaken van het complete hardware-ecosysteem van de technologieleveranciers. Alle nieuwe hardwarefeatures kunnen direct aan de Linux kernel worden toegevoegd en K kan daarvan gelijk profiteren. K kan ook elk storagesysteem dat Linux ondersteunt gebruiken voor de opslag van -images, waaronder lokale IDE-, SCSIen SATA-disks, NAS en (waaronder NFS-, Samba- en CIFS-systemen) en Fibre Channel of iscsi SAN s. K ondersteunt ook -images op shared filesystems, zoals het global file system (GFS2). Het native diskformat voor K is QCOW2, een copy-onwriteformaat dat ondersteuning biedt voor meerdere niveaus aan snapshots, compressie en encryptie. Ten slotte voorziet K in live migration, waarbij actieve s tussen fysieke hosts kunnen worden verhuisd. k guests K ondersteunt een groot aantal guest operating systems, mainstream-os en als Linux en Windows en andere platforms, waaronder OpenBSD, OpenSolaris voor de x86 en ook nog MS-DOS. K is gecertificeerd volgens Microsofts Server Virtualization Validation Program (SVVP), waardoor Windows Server op Red Hat Enterprise Linux (RHEL) en Red Hat Enterprise Virtualization Hypervisor (RHEV-H) de volledige commerciële ondersteuning van Microsoft krijgt. K ondersteunt ook paravirtualized drivers op het guest OS. Deze werken niet met geëmuleerde devices, maar bieden ondertussen een geoptimaliseerde I/O-interface en leveren hoge prestaties voor network I/O en block devices. De K hypervisor maakt gebruik van de standaard virtio, die door IBM en Red Hat is ontwikkeld in samenwerking met de Linuxcommunity. Red Hat heeft virtiodrivers ontwikkeld voor de Windows guests, die zijn gecertificeerd door de Windows Hardware Quality Labs (WHQL) van Microsoft. 4. hardware-assisted virtualization Zowel Intel als AMD hebben de x86-architectuur voorzien van uitbreidingen die een hypervisor kan gebruiken voor het vereenvoudigen van de CPU-virtualisatie. De technieken van Intel (VT-x) en AMD (AMD-V) verschillen weliswaar, maar ze gaan uit van dezelfde benadering. De nieuw toegevoegde CPU operating mode kan werken in hostof guestmodus. Een hypervisor kan de CPU vragen om in guestmodus te opereren, waarbij de CPU nog steeds de vier ringen of privilegeniveaus ziet. De CPU wordt dan geïnstrueerd om de geprivilegieerde instructie af te vangen middels een trapping en de controle aan de hypervisor over te geven. Door deze nieuwe feature hoeft een hypervisor geen binary translation toe te passen, zoals voorheen nodig was. Hoewel de Intel VT-x en AMD-V CPU s de overhead bij CPU-virtualisatie verminderen, moet de hypervisor toch nog een aanmerkelijke hoeveelheid tijd besteden aan geheugenvirtualisatie. Omdat het guest OS geen directe toegang heeft tot het geheugen, moet de hypervisor zorgen voor de mapping (Advertentie) tussen het geheugen op de fysieke host en het door de gebruikte virtuele geheugen. Dit gebeurt vaak via shadow page tables in de hypervisor. Hiervoor ontwikkelde AMD de feature Rapid Virtualization Indexing (RVI), voorheen bekend als nested page tables, en Intel de feature Extended Page Tables (EPT). Beide technieken voorzien in een door de hardware uitgevoerde gevirtualiseerde memory management unit (MMU). Vandaag de dag maakt zo goed als ieder soort virtualisatiesoftware daarvan gebruik, variërend van Microsoft Virtual PC tot ware en Xen 3.0. 5. Containervirtualisatie Bij het woord hypervisor denken veel ITprofessionals direct aan de consolidatie van OS en op virtuele hosts. Voor veel IT ers is virtualisatie de technologie die de OS en scheidt van de onderliggende hardware. Fysieke bronnen worden daarbij op een bepaalde manier geëmuleerd of de s worden van hun hosts geïsoleerd. Deze vorm van virtualisatie is echter slechts een van vele mogelijke. De voornoemde variant is specifiek ontworpen om de heterogeniteit van OS en te ondersteunen en om tegelijkertijd te dienen als middel voor serverconsolidatie. Dit type virtualisatie noemt men ook wel hardwarevirtualisatie. De abstracte laag tussen virtueel en fysiek bevindt zich daarbij onder het niveau van het gevirtualiseerde OS (zie figuur 6). Laten we nu eens uitgaan van een omgeving waarbij de abstracte laag verhuist van een positie onder het OS naar een nieuwe locatie tussen het OS en de s. In een dergelijke configuratie wordt het OS, dat is geïnstalleerd op de fysieke hardware, samen met STORAGE MAGAZINE special issue 31 31 15-02-2011 11:14:05

32 STORAGE MAGAZINE s p e c i a l i s s u e Virtual Machine Hosting Platform Hardware Virtualization Hypervisor Physical Hardware Virtual Machine Figuur 6: Hardware- versus containervirtualisatie host Admin. Remote Admin. Core Services /proc /home /usr /dev Apache MySQL PHP /proc /home /usr /dev Containers Virtualization (Deltas) Container (Template)... Shares OS Image Figuur 7: architectuur voor containervirtualisatie de OS-templates in het core OS een kernonderdeel van de virtuele workloads die zich daarboven bevinden. De laag boven en binnen een volledige instantiatie van het OS, namelijk de files en configuraties die een specifieke instantiatie uitmaken, vormt de basis voor de s. De aldus beschreven architectuur toont dus een geheel andere virtualisatiemethode: containervirtualisatie (zie figuur 7). Daarbij bestaat elke individuele virtuele workload of container uit twee delen. Het eerste deel wordt gevormd door de OS-template die zich in het core OS bevindt. Het andere deel wordt samengesteld uit de verschillen tussen de template en de individuele configuratie van de container zelf. Het uiteindelijke resultaat is dat met OS-virtualisatie voor Linux meerdere omgevingen gelijktijdig hetzelfde core OS kunnen draaien. Als voorbeeld nemen we twee identieke Linuxservers, beide vers geïnstalleerd met dezelfde softwarepackage en configuratie. Het enige verschil tussen de twee servers zit NSA MAAkTE linux VEIlIG Host OS (Deltas) Container (Template) Physical Hardware Quake Svr Postgres n /proc /home /usr /dev Virtual Platform in hun namen. In dit geval zullen de configuraties slechts van elkaar afwijken op enkele karakters in een file. Bij hardwarevirtualisatie zijn hiervoor echter twee complete afzonderlijke s nodig. Elke vereist zijn eigen aparte installatie en configuratie. Er bestaat bovendien nog geen enkele verbinding tussen beide systemen. Er moeten cache, diskruimte, buffervolume en andere hardwarebronnen op de hostserver worden gereserveerd voor de verwerking van elke. Dit in tegenstelling tot containervirtualisatie. Daarbij hoeven buffers, cache en hardwarebronnen niet te worden geëmuleerd, omdat elke bijbehorende in feite is samengesteld uit een template en zijn individuele afwijkingen daarvan. Er wordt diskruimte bespaard, omdat alleen de verschillen tussen de s hoeven worden opgeslagen. Voordelen van containers De containermethode biedt op het gebied van prestaties, schaalbaarheid en dichtheid een aantal voordelen die hardwarevirtualisatie niet kent. Wat betreft de prestaties: met hardwarevirtualisatie zijn voor devices op s speciale drivers nodig. Het gebruik van geëmuleerde of synthetische drivers heeft een negatieve invloed op de prestaties van s. Bij containervirtualisatie speelt dit geen rol, omdat de echte drivers worden gebruikt. Wat betreft de schaalbaarheid: dezelfde emulatieactiviteit die van invloed is op de driverbelasting kan ook de schaalbaarheid van s verkleinen. Zo wordt bij hardwarevirtualisatie de hoeveelheid systeembronnen, waaronder processorkracht en geheugencapaciteit, tijdens het booten vastgelegd. Bij containervirtualisatie gebeurt dit juist niet. Bij een veranderde belasting kan de beheerder de bronnen dan nog aanpassen. Wat betreft de dichtheid: door de lage virtualisatieoverhead kunnen gelijktijdig meer s op een enkele server worden toegewezen. Er zijn namelijk minder fysieke bronnen nodig voor een individuele container. Bepaalde hoge werkbelastingen komen nu in aanmerking voor virtualisatie, wat anders niet het geval zou zijn. Containers toepassen Er zijn een aantal IT-omgevingen waar containervirtualisatie beter geschikt is dan hardwarevirtualisatie. Het prestatievoordeel van containervirtualisatie kan het algehele consolidatieniveau verhogen, dat voor virtuele werkbelastingen mogelijk is. Containervirtualisatie kan ook zorgen voor verbeterde prestaties van niet-gevirtualiseerde applicaties met een hoog bronverbruik. De besparing aan diskruimte en de snelle toepassing van s door templates maakt containervirtualisatie een efficiënte toepassing voor test- en ontwikkeldoeleinden. In een hosted desktopomgeving, waarbij elke individuele container in hoge mate vergelijkbaar is met iedere andere, kan op de totale hoeveelheid benodigde diskruimte, geheugen en cache worden bespaard. Containervirtualisatie kan dienen als alternatief voor massive horizontal scaling bij de ondersteuning van grote aantallen desktops. Het kan ook dienen als alternatief voor hosted services, waarbij het meermaals inzetten van dezelfde templates en managementtoolsets tot grote besparingen kan leiden. Bekende producten voor containervirtualisatie zijn Oracle Solaris en Parallels Virtuozzo Containers. Afweging Ruwweg valt onder de virtualisatieoplossingen te kiezen uit hypervisor- of containergebaseerde virtualisatie. Welke van de twee methoden de beste oplossing biedt, hangt af 32 15-02-2011 11:14:05

Techniek Modificatie en compatibiliteit van de guests Full virtualization met binary translation Binary translation en directe executie Ongemodificeerd guest OS, uitstekende compatibiliteit Paravirtualisatie Hypercalls Guest OS is zo gecodeerd dat het hypercalls afgeeft en niet kan draaien op native hardware of andere hypervisors, slechte compatibiliteit, niet beschikbaar op Windows OS en Hardwarevirtualisatie Schakelt over naar rootmodus voor geprivilegieerde instructies Ongemodificeerd guest OS, uitstekende compatibiliteit Performance Goed In sommige gevallen beter Redelijk, momenteel vertraagt het de binary translation onder verschillende werkbelastingen, maar dit wordt in de toekomst beter Gebruikt door Is het guest OS onafhankelijk van de hypervisor? ware, Microsoft, Parallels Ja ware, Xen XenLinux draait alleen op Xen hypervisor, I-Linux is hypervisorneutraal Figuur 8: Overzicht full virtualization, paravirtualisatie en hardwarevirtualisatie. ware, Microsoft, Parallels, Xen van veel factoren, waaronder werkbelasting, hardware en omgeving. Soms valt er een uitgesproken keuze te maken voor een van de twee technieken, in andere gevallen kan voor alle twee worden gekozen. Het belangrijkste voordeel van de hypervisorgebaseerde benaderingen is dat deze een groot aantal operating systems ondersteunen. Met virtualisatieoplossingen als K, ware Server of ESX, Parallels Server 4 Bare Metal en Xen is bijna elk x86 operating system als guest op een groot aantal host-os en te draaien. Het is een zeer effectieve serverconsolidatieoplossing. Heb je tien Windows- en Linuxservers, dan is een hypervisoroplossing een prima keus. Met een hypervisor zijn de prestaties echter wel wat minder. Ook is voor elke guest een complete OS stack nodig, van de kernel tot en met de library s, applicaties enzovoort. Bovendien is er nog sprake van extra storageoverhead en geheugenbeslag, omdat elk OS apart moet worden gedraaid. Desondanks speelt de daling van de prestaties als gevolg van overhead nauwelijks nog een rol, vooral niet in vergelijking met enkele jaren Ja geleden. De verschillende hypervisoroplossingen zijn nu tamelijk goed geoptimaliseerd voor zware belastingen. Het netto-effect van containervirtualisatie verschilt nauwelijks met dat van een hypervisor. Er is een gerede kans dat de gebruikers van guestsystemen nauwelijks enig verschil merken tussen een OS dat draait op bare metal of een dat draait onder een hypervisor of in een container. De installatie van een guest OS is met containervirtualisatie niet zo rechttoe rechtaan als met een hypervisoroplossing. Allereerst moet de beheerder een containertemplate ontwikkelen. Verder is men meestal beperkt tot een enkel OS. Bovendien zijn Linux en Windows niet tegelijkertijd te draaien. Er zijn echter ook voordelen wat betreft prestaties en schaalbaarheid. Hypervisorvirtualisatie kent meestal beperkingen met betrekking tot het aantal CPU s en de hoeveelheid geheugen die een guest OS kan adresseren. Dit in tegenstelling tot containervirtualisatie, waarbij je zo veel CPU s en RAM kan adresseren als de hostkernel toelaat. Meestal hangt het ervan af hoeveel werkbelasting je hebt. Als er tien of honderden Linux guests moeten worden gevirtualiseerd, dan is de containerbenadering waarschijnlijk de beste. p Bram Dons is onafhankelijk IT-analist bij IT-Trendwatch (info@it-trendwatch.nl) STORAGE MAGAZINE special issue 33 (Advertentie) 33 15-02-2011 11:14:06