En nämare titt på VMware Fault Tolerance

En av de mest omtalade funktionerna i vSphere 4 är onekligen Fault Tolerance, en funktion vars uppgift är att se till att valda virtuella maskiner fortsätter fungera även om hårdvaran den körs på går sönder. Jag genomförde nyligen en installation hos en av våra kunder och passade på att testa Fault Tolerance lite mer på djupet. Funktionsmässigt “spelas” allt som händer i den virtuella maskinen in och lagras i loggfiler som därefter replikeras över till en annan fysisk server där de spelas upp på en sekundär kopia av den virtuella maskinen. Allt som händer i den virtuella maskinen utförs alltså på 2 olika servrar och detta är priset man får betala för Fault Tolerance: Dubbelt så mycket systemresurser går åt. VMware har en rekommendation att inte ha mer än 4-8 feltoleranta virtuella maskiner på en fysisk server, i den siffra räknas både primära och sekundära virtuella maskiner.

Tekniken bakom Fault Tolerance kallas av VMware för vLockstep som har sitt ursprung i funktionen Record/Replay som har funnits i VMware Workstation ett tag. Trafiken för replikering av loggfiler ska ske över dedicerade (minimum) gigabit nätverkskort, en central disklösning för lagring av vmdk-filerna krävs också.

Fault Tolerance fungerar utmärkt tillsammans med den kompletterande tillgänglighetslösningen High Availability. Man kan testa failover enkelt via GUI för att simulera hårdvarukrasch via “Test failover”-optionen – Jag är däremot mer intresserad av att se hur systemet reagerar i skarpt läge vilket ledde mig till att i den nämda installationen helt sonika rycka strömmen för den fysiska servern där den feltoleranta primära virtuella maskinen (ibland är det inte så dumt med förkortningar ändå, FTPVM kanske låg, för att kontrollera hur lång tid fiktiva användare skulle vara utan sin virtuella maskin gjorde jag det gamla hederliga ping-testet samtidigt. En ny siffra som presenteras i den uppdaterade Virtual Infrastructure client, numer vSphere client, är Log Intervall om man har Fault Tolerance aktiverat och visar hur mycket “lag” (fördröjning) det är mellan den primära och sekundära noden. Replikeringen av loggfilerna sker nämligen asynkront. 0,01 sekunders fördröjning hade jag i mitt test.

Nu är det inte vilka virtuella maskiner som helst som man kan använda Fault Tolerance på, dessutom kan man inte använda snapshot samtidigt som Fault Tolerance på en VM. De restriktioner som finns idag är följande:
Max 1 vCPU
Måste vara “tjock” disk (d.v.s inte thinprovisioned)
Inget stöd för RDM
Snapshot får inte finnas
Intel 31xx, 33xx, 52xx, 54xx, 55xx, 74xx eller AMD 13xx,23xx, 83xx processorer eller senare.

Men sett från den ljusa sidan så kan man skydda alla operativsystem oavsett om det är 32- eller 64-bitars. Inga speciella drivrutiner behövs även om VMware tools rekommenderas (av flera olika skäl).
Vem får då köra Fault Tolerance, vilka licenser är det som krävs? Här har faktiskt VMware varit väldigt generösa, Fault Tolerance ingår i alla editioner överstigande Standard edition, det vill säga Advanced, Enterprise och Enterprise Plus.

Och vad var egentligen resultatet? Hur länge var de fiktiva användarna utan sin virtuella maskin? Ping-testet visade att man tappade 1 ping innan den sekundära virtuella maskinen tog över. Alltså lika mycket/lite som när man kör VMotion!!! Hörde jag någon säga “Fantastiskt”?

vSphere Client och Windows 7 fungerar inte…eller?

Ibland är det för svårt att motstå frestelsen att testa nya saker, priset man ofta får betala är att vissa saker slutar fungera. Så var det för mig när jag uppgraderade till Windows 7 och samtidigt vill köra vSphere Client. En omständig workaround med att installera WindowsXP mode osv finns ju men detta är ett betydligt enklare sätt som ni kan testa:

1. Skaffa en kopia av filen %SystemRoot%Microsoft.NETFrameworkv2.0.50727System.dll från en icke-Windows 7 maskin som har .NET 3.5 SP1 installerat.
2. Skapa en katalog på Windows 7 maskinen där vSphere Clienten är installerad och kopiera in filen från steg 1 i denna katalog.
Till exempel, skapa katalogen Lib under katalogen där vSphere Client launcher är installerad
(%ProgramFiles%VMwareInfrastructureVirtual Infrastructure ClientLauncherLib).
3. I vSphere Client launcher katalogen, öppna filen VpxClient.exe.config i en text editor och lägg till 
< runtime>
 element och ett < developmentMode> element enligt nedan och spara filen.

< ?xml version="1.0" encoding="utf-8"?>
< configuration>
...
< runtime>
< developmentMode developerInstallation="true"/>
< /runtime>

< /configuration>

4. Skapa en batch fil (exempelvis VpxClient.cmd) på något lämpligt ställe. Lägg till kommandot DEVPATH miljö variabeln till den katalog dit du kopierade System.dll i steg 2 och ett andra kommando för att starta vSphere Client. Spara filen.
Exempel för Windows 7 32-bitar:

SET DEVPATH=%ProgramFiles%VMwareInfrastructureVirtual Infrastructure ClientLauncherLib
"%ProgramFiles%VMwareInfrastructureVirtual Infrastructure ClientLauncherVpxClient.exe"

Exempel för Windows 7 64-bitar:

SET DEVPATH=C:Program Files (x86)VMwareInfrastructureVirtual Infrastructure ClientLauncherLib

"C:Program Files (x86)VMwareInfrastructureVirtual Infrastructure ClientLauncherVpxClient.exe"

Nu är det bara att starta VpxClient.cmd och köra så det ryker!

VMware vSphere är här!

Äntligen är den här, den nya versionen av VMwares Virtual Infrastructure som numera döpts om till VMware vSphere. vSphere innehåller en mängd nya funktioner, både i stort och smått. Allt ifrån stöd för högsta möjliga tillgänglighet av virtuella maskiner via den nya funktionen Fault Tolerance till stöd för IDE-diskar och USB stöd. En del nya paket har introducerats, bland annat två nya Essentials paket som är mycket bra prissatta. En annan nyhet vad gäller licenser är att den tidigare Foundation licensen kommer att försvinna omgående och på lite längre sikt kommer även Enterprise licensen att tas bort, Enterprise licensen kommer att finnas kvar att beställa fram till den 15 december.

En viktig framgångsfaktor för VMwares plattform har i åtminstone mina ögon alltid varit att man har kunnat designa lösningar som höjer tillgängligheten på de funktioner och tjänster som vi inom IT ska leverera till våra organisationer. VMotion har funnits länge, funktionen introducerades för cirka 6 år sedan, och VMware har byggt vidare på tillgänglighetsspåret genom sin High Availability funktion. Nu är vi redo att ta nästa logiska steg som är Fault Tolerance. Fault Tolerance kan skydda utvalda funktioner och tjänster i din miljö genom att tillåta helt tranparent tillgänglighet om serverhårdvaran skulle krascha. Din Exchangeserver, affärssystem, filserver eller vilken funktion du nu anser vara affärskritisk går alltså inte ner bara för att servern den ligger på råkar krascha, upptiden är alltså bättre än ett kluster från exempelvis Microsoft och dessutom behöver du inte använda dyra Enterprise licenser för Windows, du behöver inte kunna klusterhantering, du behöver inte ens kunna något om operativsystemet i den virtuella maskinen du vill skydda. Det enda du behöver göra är att klicka på den virtuella maskinen du vill skydda och välja att aktivera Fault Tolerance.