Har du tid?

Som VMware instruktör vet man att det blir diskussioner vid vissa område när man håller en vSphere kurs. Ett av dessa område som det tveklöst blir diskussioner kring är hantering av tid i en virtualiserad miljö. Har synkar man bäst tiden för sina virtuella maskiner, hur synkar man tiden på sina hostar, vad är best practice och så vidare.

Anledningen att ha att synka tiden är helt enkelt att vi ska kunna lita på att vi ser rätt tid inuti en virtuell maskin eller rättare sagt att operativsystemet och applikationerna ser rätt tid, vissa applikationer kan vara väldigt känsliga om tiden skiljer sig för mycket med omvärlden. Ett exempel är Microsoft Domain Controllers som slutar replikera information om tiden skiljer sig för mycket mellan de olika domänkontrollanterna vilket kan vara ett stort problem men det finns naturligtvis massor av andra exempel.

Vi har två olika sätt att synkronisera tiden för virtuella maskiner:

  1. Använda inbyggda verktyg i operativsystemet för att synkronisera tiden med en extern källa
  2. Använda VMware tools för att synkronisera tiden inuti den virtuella maskinen med hosten den körs på

Synkning med hjälp av VMware Tools kan sättas via edit settings på den enskilda virtuella maskinen (men det är inte aktiverat per default):

(Bild saknas)

Oavsett vilken av metoderna ovan man använder sig av ska man se till att man endast använder sig av ett sätt, om man använder VMware tools för tidssynkningen avaktiverar man operativsystemets egna metod eller vice versa. De flesta miljöer omfattar ett Microsoft Active Directory vilket även kan användas för tidssynkning, så låt oss säga vi beslutar oss för att använda den virtuella maskinens operativsystem för att sätta tiden korrekt (via Active Directory) – då ska vi naturligtvis se till att vi inte använder VMware tools samtidigt för det också.

Bing, bang, boom då var det klart… Eller? Har vi verkligen sett till att vi inte synkar tiden mellan den virtuella maskinen och hosten nu? Behöver vi då ens bry oss om att synka tiden på våra hostar? Av många olika anledningar ska vi se till att synka tiden på hostarna bland annat för att se till att performance charts visar nyttjandet av resurserna på korrekta tider men även för felsökning. Felsökning i en virtualiserad miljö innebär ofta att vi behöver verifiera olika delar i infrastrukturen: Lagrings-, nätverks- eller servermiljön. Och för att göra felsökningen någorlunda överskådlig och korrelera informationen mellan de olika miljöerna ska vi se till att samtliga komponenter i infrastrukturen har en gemensam källa för tid, annars blir det väldiga problem då vi går igenom de olika loggarna vid felsökning – klockan 09.58, då problemet uppstod, måste vara samma i alla loggarna.

Så det är väldigt viktigt att se till att vi synkar tiden både för hostar och virtuell maskiner, och att vi har en gemensam tidskälla för samtliga komponenter i infrastrukturen. Men låt oss spekulera, om jag inte är intresserad av mina performance charts, jag är inte intresserad av loggfiler – jag har ändå aldrig problem med miljön ju. Så jag väljer att inte synka tiden på mina hostar och på mina virtuella maskiner synkar jag tiden med hjälp av operativsystemets funktion och VMware tools tidssynk är disabled. Ett halvår senare upptäcker jag att tiden skiljer sig väldigt mycket på mina hostar, kanske till och med har olika datum, men detta är väl inget problem för mina virtuella maskiner? Jag använder ju Active Directory för att få rätt tid, så det spelar väl ingen roll att mina hostar inte har korrekt tid?

Den stora frågan är hur fungerar VMware tools tidssynkningsfunktion egentligen? Den ser till att periodvis hämta tiden från hosten och sätter därefter tiden inuti den virtuella maskinen, detta sker som standard en gång i minuten. Så om man avaktiverar VMware tools funktionen så stänger man av funktionen för att periodvis hämta/sätta tiden men det finns andra aktiviteter som initierar en synkning av tiden till hosten. Om man har ”pausat” (suspend) en virtuell maskin så kommer den att synka tiden med hosten då den startas upp igen (resume) – kanske inte ett jättestort problem om man inte använder denna funktion. Men vi har samma beteende på en virtuell maskin då vi flyttar den via vMotion, tar ett snapshot, går tillbaka till ett tidigare snapshot, gör shrink på en virtuell disk eller startar om VMware tools tjänsterna. Detta händer alltså även då VMware tools tidssynkningsfunktionen är avaktiverad!
Därför ska man alltid se till att ha en extern tidskälla uppsatt för både virtuella maskiner och hostar!

Men om vi går tillbaka till ursprungsfrågan, om jag inte vill synka tiden på mina hostar kan jag inte styra hur tiden hanteras då jag gör vMotion, tar snapshot och så vidare? Jo, det går att styra via de avancerade parametrarna på en virtuell maskin.

Markera den virtuella maskinen i ditt inventory och stäng av den virtuella maskinen (inställningarna läses inte in om man bara gör en reboot). Högerklicka den virtuella maskinen och välj Edit Settings, klicka på Options fliken och välj General (under Advanced).

(Bild saknas)

Klicka på Configuration Parameters och klicka på Add Row och lägg till följande information:

tools.syncTime = 0
time.synchronize.continue = 0
time.synchronize.restore = 0
time.synchronize.resume.disk = 0
time.synchronize.shrink = 0
time.synchronize.tools.startup = 0
time.synchronize.tools.enable = 0
time.synchronize.resume.host = 0

Detta behöver alltså göras på varje enskild virtuell maskin, antingen manuellt eller via script, och dessutom måste de virtuella maskinerna stängas ner och startas upp för att inställningarna ska läsas in och användas.

Referens:
Disabling Time Synchonization
Configure Time Synchronization Between Guest and Host Operating Systems

VMware vSphere 5.1 uppdatering släppt

Äntligen har VMware släppt en uppdatering till vSphere 5.1 som löser en del problem som irriterat oss.
En av de första sakerna jag lägger märke till är att nu är äntligen Windows Server 2012 supporterat att köra vCenter på, dessutom stöds även MS SQL 2012 som DB.

Ett annat problem som gäckat oss är omdöpning av virtuella maskiner, i sig inget problem eftersom man under lång tid kunnat döpa om en virtuell maskin (Display name) utan att det påverkar miljön. Problemet ligger i att ”Display name” inte propageras ner till katalog- och filnamn för den virtuella maskinen vilket i en förlängning kan försvåra en eventuell felsökning. Om man förlitar sig på ”Display name” när man felsöker en virtuell maskin som blivit omdöpt och försöker hitta relaterade filer på VMFS datastore så hittar man inte en katalog som stämmer överens namnmässigt. En lösning finns nu åter igen i update 1 för vSphere 5.1 där man helt enkelt kan göra en storage vmotion för att synkronisera namnen på katalog och display name – MEN det kräver att man i advanced settings på vCenter sätter provisioning.relocate.enlabeRename till True.

När vi ändå är inne på VMFS så innehåller update 1 även en förändring på VMFS Heap Size där man nu kan växa Heap Size till 640 MB jämfört med 256 MB tidigare. Detta minimerar eventuella problem att starta upp virtuella maskiner då många, stora virtuella hårddiskfiler är öppna.

I samband med vSphere 5.1 uppdateringen har VMware även släppt uppdatering för SRM och vSphere Replication, både är nu uppe i version 5.1.1

VMware vSphere 5.1 licenser

När nu VMware har lanserat sin senaste version av vSphere, som är 5.1, är det några förändringar som gjorts på licens-sidan.

I nästan alla bundlingar, det vill säga Essentials Plus och alla Acceleration kit, ingår numera VMwares appliance för virtuellt SAN (vSphere Storage Appliance) och dessutom ingår även funktionen för att replikera virtuella maskiner mellan hostar (vSphere Replication) också. En annan förändring är att backup funktionen som tidigare gick under namnet Data Recovery har ersatts av en nyutvecklad backupappliance vid namn Data Protection. Data Protection är en lösning utvecklad av VMware tillsammans med EMC som bygger i grunden på Avamar teknologi.

Vad gäller fristående licenser har det tillkommit en variant vilket innebär att det finns totalt 4 stycken att välja mellan:

  • Standard
  • Standard with Operations Management
  • Enterprise
  • Enterpris Plus

Skillnaden mellan Standard och Standard with Operations Managment är att i den senare ingår vCenter Operations Management Suite Advanced samt vCenter Protect.

I samtliga fristående licenser (från Standard upp till Enterprise Plus) ingår:

  • vSphere Replication
  • Fault Tolerance
  • Storage vMotion

Och som säkert ingen missat vid det här laget så har VMware valt att slopa vRam licensering dessutom har man tagit bort begränsning på antal kärnor per CPU, detta innebär att det enda man behöver ta hänsyn till är hur många CPU sockets hostarna har!

För att kunna skapa de allra största virtuella maksinerna (tilldela 64 vCPU) krävs Enterprise Plus, med Enterprise kan man tilldela 32 vCPU och alla övriga licenser tillåter 8 vCPU per virtuell maskin.

För mer information:

http://www.vmware.com/files/pdf/vsphere_pricing.pdf

VMware ökar vRam tilldelning efter kritik

Med VMware vSphere 5 har licensprogrammet gjorts om där man lagt till hur mycket minne som får tilldelas virtuella maskiner per licens, Upplägget har fått ganska mycket kritik från kunder och partners, VMware har lyssnat på och meddelade igår kväll att man gör 3 ändringar på licensprogrammet:

  • De ursprungliga maximala tilldelningen av vRam baserad på licenstyp har ökats upp:
    vSphere edition Previous vRAM entitlement New vRAM entitlement
    vSphere Enterprise+ 48 GB 96 GB
    vSphere Enterprise 32 GB 64 GB
    vSphere Standard 24 GB 32 GB
    vSphere Essentials+ 24 GB 32 GB
    vSphere Essentials 24 GB 32 GB
  • En enskild virtuell maskin räknar numera inte mer vRam än max en vSphere Enterprise+ licens, d.v.s om man tilldelar 1 TB minne till en “monster-VM” så krävs det nu bara en licens för den (även om vSphere Enterprise+ “bara” tillåter användandet av 96GB vRam).
  • Beräkningsmodellen har även anpassats för miljöer som varierar i storlek/antal VMs under kortare perioder, exempelvis test- och utvecklingsmiljöer. VMware gör nu beräkningen baserat på ett 12 månaders genomsnitt istället för hålla koll på högvattenmärke av vRam nyttjande.

VMware funktioner “in action”

En del av de nya funktioner som lanserades med vSphere 5 i tisdags finns ny tillgängliga som filmer. För den som är intresserad är det nu bara att luta sig tillbaka i solstolen och spendera lite kvalitetstid tillsammans med VMware.

Demo Auto Deploy:
http://download3.vmware.com/media/flv/vSphereAutoDeploy.html

Demo vSphere Storage Appliance:
http://download3.vmware.com/media/flv/VSAResilience.html

Demo Storage Profile:
http://download3.vmware.com/media/flv/vSphereProfileDriven.html

Demo Storage DRS:
http://download3.vmware.com/media/flv/vSphereStorageDRS.html

Demo Web client:
http://download3.vmware.com/media/flv/vSphereWebClient.html

 

Den nya licensmodellen där RAM tilldelat till virtuella maskiner är en del av betalningsmodellen har skapat en del diskussion kring om vad som krävs för att vara rätt licensierad. Det är inte endast betal-varianterna som är påverkade av den nya modellen, även VMware Hypervisor (gratisversionen av ESXi) har fått ett “tak” – 8GB vRAM. Om taket är en hård begränsning (d.v.s. man kan inte starta fler VMs om de överskrider begränsningen) precis som Essentials och Essentials Plus ska jag låta vara osagt men jag hade blivit förvånad om det inte är så.

How much vRAM does a VMware vSphere Hypervisor license provide?
A vSphere Hypervisor license includes a vRAM entitlement of 8GB.

Massiv lansering från VMware

Idag har VMware haft en av sina största lanseringar någonsin. Man har verkligen inte sparat på krutet, vSphere 5.0 var endast en liten del av det som presenterades idag. VMware har på senare år gjort en hel del förvärv, man har valt att fasa ut somliga produkter (för att integrera valda funktioner i andra produkter) och man har “korsbefruktat” funktioner mellan olilka produkter – och nu börjar produkterna samverka på ett plan som gör att summan blir större än de enskilda delarna.

Paul Maritz, CEO på VMware, började dagens webinar med en liten historielektion över hur virtualisering har utvecklats över åren till att idag stå för ungefär 50% av all serverlast, det som nu byggs upp är fundamentet för en infrastruktur som är dynamisk och anpassningsbar på ett sätt som var omöjligt bara för några år sedan. Att molntjänster är framtiden är inget att tveka på längre, oavsett om det är privata eller ett publika moln, det som är det riktigt intressanta är hur man hanterar flytt av applikationer mellan de olika typerna av moln. Efter Pauls inledning fortsatte Steve Herrod, CTO på VMware, med en mer konkret presentation kring vad som de facto lanseras och listan är lång:

  • vSphere 5.0
  • vCloud Director 1.5
  • vShield 5.0
  • vCenter SRM 5.0
  • vCenter Heartbeat 6.4
  • vSphere Storage Appliance 1.0

vSphere 5.0

Onekligen är vSphere 5.0 det jag längtat mest efter (jag har iofs haft insyn i vad som skulle komma då jag varit med i betaprogrammet) med många nya funktioner och en låååååång rad förbättringar av befingliga funktioner. Några nya funktioner värda att nämna är Auto Deploy som gör det möjligt att rulla ut ett stort antal hostar på några minuter via nätverket direkt till RAM på hostarna och Storage DRS som kan lastbalansera din storage (flytta VMDK-filer mellan datastores vid behov). Storage DRS gör det möjligt att gruppera flera olika datastores i ett kluster och sätta regelverk som håller koll på om en datastore börjar få ont om diskutrymme eller se till att en virtuell maskin får den IO som behövs alternativt så kan Storage DRS migrera virtuella maskiner till ett datastore med mer diskplats eller med mer IO.

(Bild saknas)

På nätverkssidan har man lagt till möjlighet till “Quality of Service” på olika typer av trafik för att garantera bandbredd där det behövs.

In the VMware vSphere 5.0 platform, NIOC supports traffic management capabilities for the following traffic types

• Virtual machine traffic
• Management traffic
• iSCSI traffic
• NFS traffic
• Fault-tolerant traffic
• VMware vMotion™ traffic
• User-defined traffic
• vSphere replication traffic

NetFlow och LLDP är även nyheter som är integrerade i distribuerade switchar dessutom finns det även stöd för port mirroring för spegling av nätverkspaket till/från en virtuell maskin till en nätverksenhet för monitorering.

För mindre företag som inte har resurser att köpa in delad lagring så är en välkommen funktion vSphere Storage Appliance som gör vMotion och HA möjligt utan delad lagring (!!!):

(Bild saknas)

VSA:n kan köpas som en bundlign tillsammans med Essentials Plus eller som a-la-carte. På tal om vMotion så kan man nu gruppera upp till 16st 1Gbps NIC för vMotion och dessutom lastdela trafiken!

VMwares klustrade filsystem har även fått en omarbetning, borta är nu 2 TB gränsen på en datastore – taket är dock fortfarande 64TB maximalt för en datastore/extent. Enskilda VMDK-filer kan fortfarande bara vara 2TB stora men om man behöver en riktigt stor volym till en virtuell maskin så kan man lösa detta genom en pass-through RDM som kan göras större. Virtuella maskiner har också fått sig en uppgradering, vad sägs om 32 vCPU och 1 TB vRAM i en VM? vSphere 5 supporterar även Apple Xserve servers som kör OS X Server 10.6 (Snow Leopard) i ett gäst operativsystem. En ny virtuell hårdvaruversion öppnar också upp stöd för 3D grafik och USB 3.0. Man behöver dock inte skynda med att uppgradera den virtuella hårdvaran eller VMware tools om man inte nödvändigt måste ha tillgång till de nya funktionerna:

(Bild saknas)

Om man vill förenkla utrullning av vCenter så finns det nu en virtuell appliance baserad på SUSE Linux Enterprise Server 11, på 10 minuter har du en vCenter installation färdig att börja använda!

Vad gäller licenser så tar man bort Advanced edition vilket resulterar i 5 stycken kvarvarande varianter: Essentials, Essentials Plus, Standard, Enterprise och Enterprise Plus. Har man Advanced edition idag med giltigt supportavtal kommer dessa uppgraderas till Enterprise edition. En annan ganska stor förändring på licenssidan är att tidigare fanns restriktioner för bland annat för hur många kärnor en CPU var licenserad för och RAM var begränsat per host för alla editioner utom Enterprise Plus (även om det var en ganska hög begränsning så fanns den dock där). Borta är nu begränsning i hur många kärnor en CPU får ha, licenseringen är per socket och man har infört en koppling till hur mycket RAM som är tilldelat virtuella maskiner istället (vRAM). Beroende på vilken edition man kör så får man nyttja mellan 24GB upp till 48GB vRAM per CPU-licens, minnet kan fördelas fritt över klustret som en poolad resurs.

Entitlement by vSphere edition
– 24GB vRAM for Essentials Kit
– 24GB vRAM for Essentials Plus Kit
– 24GB vRAM for Standard
– 32GB vRAM for Enterprise
– 48GB vRAM for Enterprise Plus

Ovanstående är kopplat per CPU-licens man köper, d.v.s köper man 4 st Enterprise licenser får man nyttja/tilldela VMs med max 4x32GB=128GB minne. Om dina VMs överskrider 128GB minne totalt så finns 2 alternativ: Köp ytterligare en CPU Licens för Enterprise edition eller uppgradera befintliga licenser till Enterprise Plus istället. Bra eller dåligt? Tja, det beror på. De flesta kommer nog inte beröras så mycket med några större miljöer kommer att drabbas hårt av det. Det är en mjuk gräns för alla editioner, där vCenter kommer att varna då man överskrider minnesgränsen, utom för Essentials och Essentials Plus som är en hård gräns.

(Bild saknas)

Q: How is consumed vRAM capacity determined?
A: Consumed vRAM is equal to the sum total of vRAM configured
to all powered on virtual machines managed by a single
instance of VMware vCenter Server or by multiple instances
of VMware vCenter Server in Linked Mode.

Uppgraderingsvägen för att gå från vSphere 4.x till 5.0 är ganska enkel, den enda förändringen är att Advanced edition försvinner och blir uppgraderad till Enterprise edtion om man har giltigt SnS:

(Bild saknas)

vSphere Site Recovery Manager

Site Recovery Manager har inte heller undgått den stora uppgraderingsvågen, en del funktioner står ut som väldigt intressanta bland annat har man integrerat en replikeringsfunktion som kan replikera VMs över nätverket i produkten – d.v.s. välj själv om storagen eller hosten ska sköta replikeringen. Det innebär bland annat att man kan ha storage enheter från olika tillverkare på produktions- och katastrofsiten. Automated Failback är nu också möjligt med SRM5.0. En annan väldigt uppskattad funktion är “Planned Migration” d.v.s. möjligheten att migrera datacentret vid exempelvis ett stort servicearbete i serverhallen.

(Bild saknas)

 

En nya era börjar, en annan går i graven – Länge leve ESX

VMware har under lång tid varit tydliga i sitt budskap att VMware ESX (den “tjocka” hypervisorn) kommer att försvinna och ersättas av ESXi (den “tunna” hypervisorn). De båda varianterna har levt parallellt under ett antal år nu och när vSphere 4.1 lanserades för lite mer än ett år sedan var ett av budskapen att detta kommer att bli den sista versionen där man själv kan välja tjock eller tunn hypervisor. Nästa version som spekuleras komma under året bygger alltså endast på den tunna, ESXi, hypervisorn. Som ett led i strategin att få kunder att gå över till ESXi har man nu tagit bort möjligheten att ladda ner ESX från VMwares nedladdningssidor (nåja, den finns faktiskt med som en länk på sidan men den är lätt att missa).

http://downloads.vmware.com/d/info/datacenter_downloads/vmware_vsphere_4/4_0

Vill man hämta ESX så kan man använda direktlänken till nedladdningssidan istället:

download ESX here

Fault Tolerance och DRS?

En förbisedd förbättring med DRS funktionaliteten i VMware vSphere 4.1 är hantering av fel-toleranta virtuella maskiner. Tidigare kunde man inte lastbalansera virtuella maskiner med VMware Fault Tolerance (FT) funktionen påslagen, detta har nu ändrats. För att detta ska fungera måste man konfigurera VMware Enhanced vMotion Cluster, då aktiveras möjligheten att låta DRS flytta de fel-toleranta virtuella maskinerna.

VMware EVC aktiveras via clusterinställningarna.

VMware vSphere 4.1 USB stöd

Visste du att VMware vSphere har stöd för USB enheter nu? Det är en efterlängtad nyhet som kommer att underlätta en hel del för många. Borta är nu behovet att köpa nätverksbaserade USB dockningsstationer typ AnywhereUSB. VMware har publicerat en KB artikel över vilka enheter som stöds i dagsläget, den kommer förmodligen att utökas vad det lider.

(Bild saknas)

Men det riktigt intressanta i det hela är inte själva stödet för USB utan att vMotion stöds för dessa anslutna enheter, man kan alltså flytta virtuella maskiner mellan hostar och fortfarande ha access till sin USB enhet! Man kan ansluta upp till max 20 stycken USB enheter till en virtuell maskin.

vSphere funktioner som stöds:

(Bild saknas)