Virtualisering Archive

Tid synkronisering i en virtuell DC

Har skapat en ny guide där jag tar upp och förklarar hur man bör konfigurera sin tid synkronisering i en virtuell domänkontrollant. Detta ämne diskuteras ganska så frekvent i olika forum och det finns lite olika varianter och lösningar på hur man bäst implementerar detta.

I denna guide har jag sammanställt den information som jag funnit kring ämnet och metoden som beskrivs är ett rekommenderat tillvägagångssätt från VMware. Tid synkroniseringen av domänkontrollanten sker genom att använda Grupp policy objekt och WMI-filtrering.

Fördelen med denna metod är att korrekta registerinställningar sker per automatik på den primära domänkontrollanten även vid en eventuell migrering av denna roll. Hoppas att denna guide kan komma till nytta när det är dags för virtualisering av ert Active Directory.

Guiden hittar du här: TidSynkVirtuellDC.pdf

Virtuella förhållanden

Har sammanställt lite enkla riktlinjer gällande frågor som ofta dyker upp i virtualiserings sammanhang. Det kan vara frågor som:

  • Hur många virtuella maskiner kan jag köra på en host?
  • Hur stora LUNs skall jag skapa på mitt SAN?
  • Hur många VMs kan jag köra per LUN?
  • Hur mycket RAM och CPU skall jag ha i mina hostar?

Hostsize

Det finns naturligtvis inget enkelt svar på dessa frågor och egentligen inte något rätt och fel. Det är ju många faktorer och förhållanden som spelar in och avgör hur man i slutändan fattar ett beslut. När det gäller storleken och hur man skall dimensionera sina hostar när vi talar CPU och RAM så handlar det om att hitta ett lagom förhållande mellan den fysiska hårdvaran och den arbetslast som skall hostas på denna. Större och kraftfullare servrar innebär färre fysiska hostar att drifta och underhålla, men samtidigt medför detta att konsekvenserna av en eventuell serverkrasch blir allt mer allvarlig. Fördelen med fler mindre fysiska hostar är att lasten kan spridas ut på ett mer effektivt sätt och på så vis minimeras de negativa följderna vid ett hårdvarufel. Dessutom fungerar enligt min uppfattning lastbalanseringen (DRS) bättre i en mer balanserad miljö. I de flesta fall är det alltså bättre att skal ut än att skala upp. Oftast vill man ju ha inte belasta sina hostar mer än 70% för att tillgodose kraven för HA vilket på en kraftfullare maskin innebär större resurser som inte nyttjas. Ett exempel på lämplig server i denna klass skulle kunna vara en HP DL380 eller liknande.

pCPU vs vCPU

När vi sedan talar om förhållandet mellan den fysiska servern och de virtuella maskinerna, alltså hur många VMs / ESX host man kan köra så är svaret återigen ”det beror på”. I några fall när du har en mycket kraftfull host och de VMs som hostas har en mycket låg arbetsbelastning så kan man nå förhållanden på ca 60:1 medan du på en mindre kraftfull host och VMs med hög arbetslast kanske enbart når ett förhållande på 10:1 eller mindre. Man brukar generellt räkna med att en mellanklass server med 2 sockets kan nå ett förhållande på ca 16:1 och ca 32:1 för en med 4 sockets med en normal arbetslast på de VMs som hostas. Det gäller att ha koll på antalet virtuella CPUer i dessa sammanhang. Som en tumregel kan man räkna med att kunna köra 4 x vCPU x antalet pCPU. Det skulle på en server med två fysiska fyrakärninga CPUer ge oss 8pCPU x 4 = 32 vCPU.

Lagringdirektiv

För många VMs per LUN kan skapa flaskhalsar på ditt SAN och du kan få problem med metadata låsningar etc. Det är även viktigt att förhålla sig till det underliggande disksystemet och antalet spindlar i det RAID set som levererar lagringen. Här följer några riktlinjer att förhålla sig till:

  • Antalet VMs per LUN i genomsnitt: 14 to 16
  • För hög I/O belastning, applications: 8 to 10 VMs per LUN
  • För medel I/O belastning: 20 to 22 VMs per LUN
  • För mycket låg I/O belastning, terminalservrar, VDI-klienter: mer än 100 VMs per LUN

Tänk på att allt som föreslagits här endast är riktlinjer och rekommendationer. Det finns otaliga faktorer som spelar in i dessa sammanhang och det kan skilja mycket från olika miljöer. Det viktigaste är att man tänker till innan man designar sin virtuella infrastruktur för att på så vis slippa de vanligaste prestandaproblemen.

Automatisk inloggning i vCenter 2.5

I vCenter 4.0 och senare versioner kan man förenkla inloggningen med den tillhörande vSphere klienten genom att bocka i den lilla rutan längst ner och på så vis använda sig utav det windows konto man är inloggad med för att per automatik logga in på sin vCenter server. Denna möjlighet finns inte på den då kallade ”VMware Infrastructure Client” och vCenter version 2.5 eller tidigare . Det finns dock ett sätt att lösa detta på för att kunna vidarebefodra sina windows uppgifter och på så vis skapa en automatisk inloggning. Detta sker genom att man lägger till följande parametrar för genvägen till klienten.

-passthroughAuth -s vc.yourdomain.com

Byt ut ”vc.yourdomain.com” mot namnet eller ip adressen på din vCenter server. Nu har du möjligheten att automatiskt logga in på vCenter servern utan att ange autentiseringsuppgifter.

passthru

Partition alignment

Översätter man det engelska ordet ”Alignment” så får man följande förklaring: ”The act of adjusting or aligning the parts of a device in relation to each other”. De svenska alternativen är inriktning, justering eller linjering. Och det är precis vad detta inlägg kommer att handla om.

Bakgrund
Disk alignment är ett fenomen som många gånger förbises och som i virtualiseringssammanhang är extra viktigt att ha koll på då detta tillför ytterligare ett filsystemslager. För att klargöra det hela så börjar vi på SAN nivån. Den minsta beståndsdelen som används av lagrings-arrayen för att skapa ett LUN utav ett antal fysiska diskar kalls för ”chunk” eller ”stripe”.  På detta LUN skapas sedan en VMFS volym (i VMware miljöer) som delas upp i olika block. Det sista lagret är själva VMDK filen som på en Windows server formateras i NTFS som även detta delar upp disken i block som sedan grupperas i ”cluster” (allokerings enheter).  NTFS lagret använder sig utav MBR (Master Boot Record) som innehåller partitionstabellen.

Utrymmet mellan MBR som alltid ligger först på volymen och startpartitionen som utgör själva lagringsytan kallas för ”Offset” eller ”StartOffset”. Och det är storleken på detta utrymme  som är nyckeln till det hela och som skall justeras för att alla lager ska ligga i fas med varandra. Om samtliga lager inte ligger i fas med varandra kan diskprestandan bli lidande då onödigt många I/O operationer måste utföras för att läsa eller skriva data. Det här låter kanske krångligt men om vi tittar på animationen nedan så kanske det förklarar en del.

Problemet
Som vi ser i animationen så krävs det i värsta fall läsning av totalt 3 stycken ”chunks” från LUN:et när det egentligen hade varit tillräckligt med endast 1. Anledningen till detta är att både VMFS partitionen och NTFS partitionen är ur fas och ej i linje med underliggande chunksize (stripesize) på LUN:et. Detta innebär naturligtvis en prestandaförlust då antalet ”chunks” som måste bearbetas vid läsningar och skrivningar till och från disk blir onödigt många. I väldigt I/O intensiva miljöer som exempelvis databasservrar kan detta få betydande negativ inverkan på diskprestanda vad avser latency och throughput.

I ovanstående exempel är även VMFS partitionen ur fas med underliggande LUN. Detta är med aktuella versioner av ESX inte något problem då VMFS volymer som skapas med vSphere klienten (vilket för övrigt är en rekommendation från VMware) automatiskt får korrekt offset.  Problemet ligger oftast i det översta lagret som i detta exempel är en Windows formaterad NFTS partition med felaktigt offset.

Windows
Med Windows Server 2003 och tidigare versioner så skapas alla diskar som standard med en offset på 31,5KB för startpartitionen vilket gör att de inte är i fas med de underliggande ”chunk” storlekar som är vanligats på dagen lagrings arrayer (64K, 128K, 256K). Anledningen till detta är att tidiga versioner av BIOS använde sig utav cylindrar, huvuden och sektorer för adressering istället för LBA (Logical Block Adressing).  Senare versioner av Windows (Vista, W7 och server 2008) skapar automatiskt en korrekt offset och därmed är detta inget problem med aktuella versioner av Windows.

Kontollera dina partitioner
Hur gör man då om man vill kontrollera sina partitioner för att veta om de är ”alignade” (ursäkta svengelskan)? Det finns tredjepartsverktyg  och även powershell script som kan köras som kan identifiera detta. Men det enklaset sättet att kontrollera detta på en specifik windows VM är att använda sig utav kommandorads verktyget diskpart.exe

Följande bild visar hur du i Windows kontrollerar om en partition är korrekt riktad (i fas, i linje).

diskpart1

Som ni ser så visar diskpart här att startpartitionen har en offset på 32KB. Detta innebär att den inte är korrekt alignad dvs inte är i fas med underliggande disksystem. Jag nämnde ju tidigare att alla partitioner i Windows 2003 och tidigare versioner alltid alignar sina partitioner med en offset på 31,5KB. Men här ser vi istället värdet 32KB?! Borde inte detta innebära att denna partition är korrekt alignad då 32KB är jämnt delbart med 8 (vi kommer till detta senare) ?. Nja, så här ligger det till. Diskpart avrundar värdet 31,5KB (32,256 bytes) till 32KB (32768 bytes) vilket kan vara lite lurigt om man inte är medveten om detta. Om disken hade varit alignad ska diskpart visa en offset på 64KB. Detta är vad som rekommenderas.

För att vara på den säkra sidan kan man köra följande kommando för att kontrollera ”StartingOffset”

”wmic partition get BlockSize, StartingOffset, Name, Index”

diskpart2

Och som ni ser så är alltså denna partition unaligned då vi ser att StartingOffset är 32256 bytes.

Rekommendationer
För att säkerhetsställa att dina VMFS partitioner är i fas med chunk storleken på ditt SAN se då till att alltid använda dig utav vSphere klienten när du skapar dina VMFS partitioner då de automatiskt får rätt alignment (128KB).

För att säkerhetsställa att dina NFTS partitioner i Windows är i fas med det underliggande disksystemet (VMFS partitioner) så ska man inte använda ”Windows Disk Manager” för att skapa sina partitioner utan istället använda sig utav kommandorads verktyget diskpart.exe

Vmware rekommenderar att man sätter en offset för sin start partition som är en multipel av 8.

Microsoft rekommenderar att man sätter en offset på 64KB för startpartitionen.

Dessa rekommendationer förutsätter att inget annat uttryckligen har rekommenderats av tillverkaren för disksystemet.

Prestanda
Kommer inte att gå in i detalj på I/O, latency, throughput, RAID, etc i olika konfigurationer utan bara konstatera att det finns i många fall finns stora prestandavinster att göra genom att se till att sina partitioner är korrekt alignade. Hittade följande bild från Microsoft som talat ett tydligt språk.

disk-align-perf

Här kan vi tydliga prestandaskillnader mellan alignade och icke alignade diskar. Om vi tittar lite närmare så ser vi att vi har lika bra om inte bättre prestanda med 6st korrekt alignade diskar än med 8st icke alignade. Även fast vi har exakt likadana diskar med samma RAID konfiguration!

Lösning
Hur skapar man då en korrekt alignad partition i Windows? Jo, man använder sig som sagt var utav programmet diskpart. Följande bild visar steg för steg hur man skapar och alignar en partition på disk 1 med en offset på 64KB.

diskpart4

VMware rekommenderar dessutom att du formaterar din partition med en klusterstorlek på 32KB enligt bilden nedan. Observera att detta värde inte har någonting med alignment att göra. Vill man göra detta direkt med diskpart skriver man följande:

”format fs=ntfs unit=32K”

diskpart3

Systempartitionen
Hur fungerar det med alignment av systempartitionen då? Man har tyvärr ingen möjlighet att via Windows installationsprogram eller i efterhand konfigurera en korrekt offset på 64Kb med diskpart. Det som beskrivits ovan kan alltså enbart tillämpas på en datadisk som inte innehåller windows systemet. Detta innebär att om du tilldelar din VM en disk på ex 20GB och kör Windows installationsprogram så kommer denna systemdisk inte att vara korrekt alignad. Man bör alltså se till att ha en alignad systempartition klar innan man startar sin Windows installation då detta i efterhand är betydligt mer komplicerat.

Aligna systempartitionen INNAN Windows installationen
Hur gör man då för att för att aligna sin systempartition innan man installerar Windows? Det enklaste sättet är att använda sig utav en en annan VM och till denna skapa en ny disk som sedan kommer att användas som systemdisk till den ursprungliga maskinen. Låt mig klargöra detta lite närmare. Säg att vi vill skapa en ny VM som vi kallar VM-SRV2. På denna VM ska vi installera Windows Server 2003 på. För att kunna aligna denna systemdisk innan vi startar Windows installationen kan man använda sig utav en befintlig VM som vi här kallar för VM-SRV1. Följande steg ger dig en korrekt alignad systemdisk som du kan använda för VM-SRV2.

  1. Addera en ny disk till VM-SRV1 och ange den storlek som du vill att VM-SRV2 skall ha som systemdisk.
  2. Aligna sedan denna disk med diskpart och sätt en offset på 64KB enligt tidigare instruktioner.
  3. Formatera sedan disken och välj en kluster storlek på 32KB.
  4. Koppla sedan bort denna disk från VM-SRV1. Observera att du inte skall välja ”Remove from virtual machine” och inte ”Remove from virtual machine and delete files from disk”
  5. Ta sedan bort redan befintlig systemdisk från VM-SRV2 genom att välja ”Remove from virtual machine and delete files from disk”
  6. Välj sedan att lägga till en ny disk för VM-SRV2 och istället för att skapa en ny disk så väljer du ”Use an existing virtual disk” och pekar sedan på den disk som du skapade i steg 1
  7. Nu har du en korrekt alignad systempartition på din disk och du kan nu starta windows installationen.

Tänk på att inte radera den befintliga partitionen som windows installationen kommer att hitta. Utan istället välja att enbart installera windows på denna partition utan att formatera om den. Detta för att säkerhetställa att din alignment och kluster storlek inte raderas.

Om man vill kan man mellan steg 5 0ch 6 välja att manuellt flytta den VMDK fil som utgör systemdisken till samma mapp som VM-SRV2 ligger för att få det hela mer organiserat.

Aligna systempartitionen EFTER Windows installationen
För att aligna en redan befintlig windows partition i efterhand kan man inte använda sig utav diskpart och den metod som jag beskrivit tidigare. En sådan operation är ett komplicerat ingrepp och kräver tredjeparts program som exempelvis:

vOptimizer Pro
Paragon Alignment Tool
GParted

Detta är som sagt ett stort ingrepp som kan innebära vissa risker och eventuella dataförluster. Jag rekommenderar därför att man absolut ser till att ha en aktuell backup innan en sådan operation utförs. Dessutom kanske man kan fråga sig om en alignment av just systemdisken kommer att tillföra så mycket vad avser prestandavinster. Är det verkligen värt mödan? Många gånger så är ju systemdisken där windows huserar inte så hårt belastad vad avser I/O som exempelvis en datadisk som innehåller databasfiler och transaktionsloggar är. I sådana fall finns det betydligt mer prestanda att vinna genom alignment. Allt detta bör alltså övervägas innan man fattar ett sådant beslut.

Referenser
VMware – Recommendations for Aligning VMFS Partitions
Yellow-Bricks – Aligning your VMs virtual hard disks
Microsoft – Disk Partition Alignment Best Practices