VMware’s VMotion biedt één van de meest aansprekende functies die je met virtualisatie kunt bereiken: het migreren van draaiende serverapplicaties van de ene fysieke server naar de andere, zonder dat de bijbehorende clients er iets van merken. Dit fenomeen wordt “live migration” genoemd en helpt je om – met name geplande – downtime te voorkomen. Voorbeelden van zulke geplande downtime-momenten zijn (a) het willen uitvoeren van preventief onderhoud op een server of (b) het herverdelen van applicaties over servers om daarmee de server-belasting te optimaliseren.
De architectuur van de huidige generatie CPU’s maakt live migration echter niet onder alle omstandigheden op een efficiënte wijze mogelijk. Zo hebben zowel Intel als AMD in de loop der tijd extra instructies geïmplementeerd in sommige processoren. Maakt nu het operating systeem of een applicatie binnen een virtuele machine (VM) gebruik van zo’n instructie, dan dient die instructie ook aanwezig te zijn op de fysieke server waar de VM middels live migration naar toe verhuist. Immers, zowel het operating systeem als de applicatie gaan na de verhuizing door op hun volgende instructie, zonder dat ze “weet” hebben van de migratie.
De consequentie hiervan is dat VMotion noodzakelijkerwijs eisen stelt aan de CPU compatibiliteit: de CPU’s op de fysieke servers moeten exact gelijke functionaliteit bieden om problemen tijdens de live migration te voorkomen. Dit kan de toepassing van VMotion behoorlijk frustreren. Ten eerste moet je wellicht oude hardware voortijdig afschrijven. Daarnaast zit je met het probleem dat je niet weet wat je over een paar jaar zou willen kopen en of dat nog wel compatibel is.
Hier zijn echter wel een paar kanttekeningen bij te maken:
- Ten eerste zou het onverstandig zijn om deze beperking van live migrations door te vertalen naar een beperking van virtualisatie zelf. Er zijn genoeg andere redenen om te virtualiseren (te veel om in dit bestek te noemen, maar denk aan consolidatie, “cold migration” en legacy ondersteuning). Het feit dat VMotion zo tot ieders verbeelding spreekt moet dus niet als een boemerang tegen virtualisatie zelf gaan werken.
- CPU-leveranciers begrijpen deze beperking maar al te goed en hebben dan ook – samen met de virtualisatie-leveranciers – een goede oplossing gevonden. Zowel de Intel Flex Migration als de AMD-V Extended Migration bieden oplossingen om de beperkingen van live migration te voorkomen. VMotion ondersteunt dit sinds VMware ESX 3.5 Update 2 onder de naam “Enhanced VMotion Compatibility”. Met deze uitbreidingen kun je er dus gevoeglijk vanuit gaan dat toekomstige processoren – ondanks eventuele nieuwe instructies – inderdaad opgenomen kunnen worden in de live migration omgeving van de huidige generatie processoren.
Samengevat:
- Laat je niet onnodig verleiden tot het motiveren van een virtualisatie-traject alleen op basis van VMotion, puur omdat het zo tot ieders verbeelding spreekt. Dit kan als een boemerang werken als de beperkingen van live migration duidelijk worden.
- Virtualisatie is nog zo pril dat het samenspel tussen de hypervisor en de CPU nog niet volledig is uitgekristalliseerd. Zowel Intel Flex Migration als AMD-V Extended Migration zijn voorbeelden van de manier waarop CPU-fabrikanten hier goede vorderingen maken.
VMware heeft een en ander overigens uitstekend uitgelegd in een Information Guide die als PDF te downloaden is.
Bert,
Goed artikel.
Wijze les.
Meer van deze lessen leiden tot een goed, afgewogen oordeel voordat men begint aan het traject. We moeten ze bundelen….
Groet,
Jan-Paul
Waarvoor dank. En ook voor het lenen van je titel op http://www.computable.nl/artikel/ict_topics/virtualisatie/2727569/2333390/zin-en-onzin-van-virtualisatie.html
[...] een AMD processor (’live migration’ dus). Als je weet hoe complex dit is (zie ‘Zin en onzin van VMotion CPU compatibiliteit‘) dan krijgt het geheel toch wel de WOW-factor van een [...]
[...] 14, 2009 by Bert Bouwhuis Microsoft had – net als VMware – het probleem op te lossen van de verschillen tussen CPU’s bij live migration. Deze CPU [...]