Chargeback för VMware

En sen länge efterlängtad funktion i VMware har nu släppts: Chargeback
Detta innebär att man kan mäta resursutnyttjande på varje virtuell maskin och fördela kostanden för VMwaremiljön. Chargeback funktioner för VMwares infrastruktur har tidigare bara funnits via tredje parts leverantörer men nu har alltså VMware själv släppt en funktion för detta.

Det är en webbaserad applikation (front-end) som kräver Internet Explorer 6.x eller 7.x. alternativt Mozilla Firefox 2 eller 3. Men den går även att integrera med vSphere client som en plug-in. I bakgrunden krävs även en SQL databas och vCenter server (både version 2.5 update 3 och version 4 stöds).

Installationen finns i 2 olika skepnader, dels en lokal installation på vCenter servern där chargeback tjänsterna startas automatiskt samt en del som består av en virtuell appliance som ska importeras och startas i VMwaremiljön – den virtuella appliancen är bara tänkt för evaluering av funktionen och fungerar därmed enbart med evalueringslicenser. Både kräver dock att det skapats en databas som kan användas av Chargeback.

När funktionen är i drift kan man ta fram kostnadsrapporter för ett tjugotal olika policies, några exempel:
• Fixed cost – avser de fasta kostanderna man har med infrastrukturen, de faktiska resurserna som används spelar ingen roll i detta fall.
• Actual Usage – denna policy baserar sina rapporter på de faktiska resurserna som har använts under perioden. Den totala kostnaden räknas ut med hjälp av den grundtaxa som angetts i kostandsmodellen.
• Reservation – detta är en kostnadsmodell som tar höjd för virtuella maskiner där man reserverat resurser. vCenter server tillåter bara CPU och minnesreservationer, dessa reserverade resurser tillsammans med övriga parametrar används för att räkna ut den totala kostnaden.

Man kan även ta fram jämförande rapporter baserade på olika policies. Rapporter tas fram manuellt eller schemalagda. Schemalagda rapporter kan även automatiskt mailas till fördefinierade epostkonto.

Licensmässigt kopplas en licens till en CPU i ESX servern.

VMware uppdaterar ThinApp

Under sommaren har VMware smugit ut en uppdatering av VMware ThinApp, företagets applikationsvirtualiseringsprodukt. Man är nu uppe i version 4.0.3 och en välkommen uppdatering är att man löst problemen med att virtualisera VMware vSphere client – eller som man också kan uttrycka: eat your own dogfood.
“ThinApp 4.0.3 addresses issues that affect the following applications:

  • Telecordia
  • Arthemis
  • Adobe Reader 9
  • Adobe Reader 8 Update component on Windows Vista
  • Smartplant License Manager
  • Microsoft Office Groove
  • Windows Live Messenger
  • AutoCAD 2000
  • eVIT by LUURENS
  • VMware vSphere Client
  • Internet Explorer 7
  • Lotus Notes
  • SigmaPlot 11.0
  • QuickTime Control Panel”

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.