Houdt het nooit op? Oracle en VMware…

Bart Sjerps heeft zich opnieuw gewaagd aan een uiteenzetting met betrekking tot de FUD die Oracle schijnt rond te strooien over het licenseren van Oracle databases onder een VMware omgeving. De positie die daarbij naar verluidt door Oracle personeel wordt ingenomen is dat je alle servers zou moeten licenseren waar Oracle via vMotion IN THEORIE naar toe gebracht kan worden.

Nu is dat al vaker als onzin bestempeld. Bart heeft echter nog een ander idee: als je ervoor zorgt dat Oracle nooit met vMotion naar een server kan migreren, dan zou je voor die server toch hopelijk echt geen licenties hoeven te betalen? Hij stelt daartoe drie roadblocks voor. Ook nu zal echter hierover het laatste woord nog lang niet zijn gezegd…

Zie Caging the license dragon voor meer.

—

Read Full Post »

Verdoving voor virtuele machines

Een van de nieuwe vSphere 5 features lost een min of meer theoretisch probleem op. Stel dat je met vMotion een machine wilt verhuizen en dat de memory pages razendsnel veranderen in die machines. Het lukt je dan niet om de pagina’s naar de andere fysieke machine te verhuizen, omdat het resterende deel pagina’s dat nog te kopiëren overblijft maar niet kleiner wordt.

Daar heeft VMware iets op gevonden: Stun During Page Sends, oftewel verdoof de machine tijdens het verhuizen van de memory pages. Misschien moet je eigenlijk zeggen “versuffen”, omdat de machine wel degelijk blijft draaien, zoals het hoort tijdens vMotion.

Dit is een van de vele verbeteringen rond vMotion in vSphere 5. Gelukkig zijn de meeste andere verbeteringen iets praktischer van aard. Zie voor een volledig overzicht de net gepubliceerde white paper daarover: “VMware vSphere vMotion – Archiecture, Performance and Best Practices in VMware vShpere 5”.

Bromn: Eric Sloof

Read Full Post »

CPU compatibiliteit en Hyper-V

Microsoft had – net als VMware – het probleem op te lossen van de verschillen tussen CPU’s bij live migration. Deze CPU compatibility eis bewaakt dat zowel het operating systeem als de applicaties feilloos doordraaien op een andere fysieke machine na een live migration. Zijn de CPU’s niet compatibel dan loop je het risico dat het operating systeem of één van de applicaties een processorinstructie uitvoert die niet op die nieuwe processor aanwezig is, met alle gevolgen van dien (denk aan BSOD).

VMware heeft bij de oplossing hiervoor gekozen voor de meest veilige en robuuste manier. Dit is namelijk een combinatie van hypervisor-software en hardware-ondersteuning: “Flex Migration” in geval van Intel en “Extended Migration” bij AMD. Door deze hardware-ondersteunde aanpak kan de hypervisor-laag de onderliggende CPU forceren om geen instructies uit te voeren die de CPU op de machine waar je via live migration naar toe gaat niet aan zou kunnen. Daardoor weet je zeker dat alle software die op de eerste machine draait ook op de migration-target zal draaien (tenminste, voor zover het potentiële CPU-compatibiliteit problemen betreft natuurlijk).

Microsoft heeft daarentegen bij de Live Migration van Server 2008 R2 gekozen voor een 100% software-aanpak. Het voordeel is duidelijk: dit ook werkt op oudere processoren die geen Flex of Extended Migration ondersteunen. Het nadeel is echter dat je nooit 100% zeker weet of er toch niet een applicatie draait op je eerste machine die niet – zoals het hoort – de capabilities van de processor vooraf heeft opgevraagd, maar gewoon instructies gebruikt die niet op alle processoren aanwezig zijn (zo’n applicatie kan bijvoorbeeld eenmalig een error-trap gebruiken om dit bij de start te detecteren). Alles gaat dan goed zolang de software op de eerste machine draait waar die instructies wel aanwezig zijn. Bij een live migration kan dit echter fatale gevolgen hebben. En helaas kan dat op elk moment in de tijd optreden, dus niet per se direct na de migratie want dan zou je wellicht nog handmatig kunnen ingrijpen.

Het argument van Microsoft hiervoor is “we zijn nog nooit software tegen gekomen die zich zo gedraagt”. Pragmatisme is natuurlijk altijd goed, maar gaat dit niet net een stap te ver?

Zie Microsoft’s Virtualization Team Blog voor een uitleg van Microsoft’s aanpak van Live Migration in Server 2008 R2

Read Full Post »

Onderzoek naar VMotion versneller

VMware’s VMotion is de meest bekende techniek om live migrations uit te voeren. Dit houdt in dat je draaiende virtuele machines van de ene fysieke server naar de andere verhuist, zonder dat de clients die van die draaiende machine gebruik maken er iets van merken.

De belangrijkste bottleneck hierbij is de migratie van main memory via het LAN (de virtuele disk moet namelijk sowieso op een shared storage systeem staan om VMotion te kunnen uitvoeren). Dat LAN moet dan ook minimaal een bandbreedte van 1Gbps hebben, en liever nog 10Gbps.

Om de interruptie van de virtuele machine zo kort mogelijk te houden, wordt het geheugenis een paar kopie-slagen verhuist, terwijl de virtuele machine nog op de “oude” server draait. Na elke kopie wordt gekeken hoeveel verschil er intussen weer is ontstaan door de draaiende machine en wordt dat verschil opnieuw verstuurt. Normaal gesproken moeten die verschillen dus steeds kleiner worden. Uiteindelijk beslist VMotion om het laatste restant te versturen, de “oude” virtuele machine te stoppen en de “nieuwe” in de lucht te brengen.

Kevin Lawton heeft dit mechanisme nu verder verfijnd, door over meerdere servers te onderzoeken hoeveel duplicaten van brokken memory al aanwezig zijn in de “nieuwe” server of in zijn directe omgeving. Hij toont aan dat hiermee enorme versnellingen mogelijk zijn, met factoren 4 tot 10 of zelfs meer. Wellicht dat hierdoor live migration ook ooit op lange afstand via relatief trage verbindingen mogelijk gemaakt kan worden.

Bron: virtualization.info

Read Full Post »

VMware’s Distributed Resource Scheduler

VMware’s Distributed Resource Scheduler (DRS) automatiseert de distributie van virtuele machines over meerdere fysieke servers. Het doel van de distributie is ervoor te zorgen dat de belasting – ook onder dynamische omstandigheden – redelijk evenwichtig verdeeld blijft over de beschikbare fysieke machines. DRS maakt daarbij primair gebruik van VMware’s VMotion oplossing. Met VMotion kun je op VMware ESX draaiende virtuele machines zonder merkbare downtime verhuizen van de ene fysieke server naar de andere (‘live migration‘ dus).

Om het effect van DRS inzichtelijk te maken publiceerde VMware vandaag een interessant White paper: “DRS Performance and Best Practices“. Daarin wordt uitgelegd hoe je DRS kunt instellen en wat het effect daarvan is onder verschillende belastingen. Een voorbeeld daarvan is de herverdeling van Database servers, Web servers, File servers, Java servers en Idle machines:

Het gebruik van VMotion dwingt overigens wel af dat de CPU’s van de verschillende fysieke machines onderling compatibel moeten zijn. Deze eis is recent met het uitbrengen van VMware’s ESX 3.5 Update 2 gelukkig behoorlijk afgezwakt door de zogenoemde “Enhanced VMotion compatibility”.

De White Paper geeft een redelijk inzicht in DRS’s architectuur – met verwijzing naar meer achtergrondinfo daarover – en het effect in de praktijk. Tevens worden Best Practices tips gegeven, een duidelijk aan inflatie onderhevige kreet voor een oplossing die nog maar net op de markt gebracht is overigens. De conclusie luidt:

The effectiveness and scalability tests we performed with DRS demonstrate that resources are distributed across hosts in a DRS cluster according to the resource allocations and that better throughputs are achieved especially in the presence of varying loads and random virtual machine placement on hosts. The DRS framework also provides the ability to adjust the aggressiveness of the DRS algorithm and interval between invocations of the algorithm. In addition, DRS avoids wasteful migrations with cost‐benefit analysis and minimizes migration of idle virtual machines.

Based on our experience and customer experience in the field, we provided a list of best practices that you can follow to avoid pitfalls.

Finally, DRS also provides a few mechanisms you can use to monitor the DRS cluster performance and potentially provide feedback on how the resources are being delivered and whether the DRS settings need to be adjusted.

Download de White Paper hier in PDF-formaat.

Read Full Post »