RAID Archive

Virtuella förhållanden

Av:
Andreas Berg
Publicerad: 22 maj 2010Postad i: Teknik, Virtualisering

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.

P2V och Software RAID

Av:
Andreas Berg
Publicerad: 18 december 2009Postad i: Tips & Guider

Genomförde nyligen en P2V konvertering av en Windows server (2003 32bit). Servern hade 2st fysiska IDE-diskar som var speglade med Windows egna mjukvaruraid. Genomförde själva konverteringen med hjälp av VMware Converter.  Körde an så kallad ”Cold Clone” vilket innebär att man bootar den fysiska servern från en skiva där en anpassad version av Win-PE finns som startar VMware vCenter Converter. Föredrar att alltid använda denna metod vid P2V migreringar då risken för att dataförändringar under själva konverteringen försvinner helt.

Själva konverteringen gick bra trots att det tog ca 5-6 timmar. Det var ca 150GB data som skulle migreras. Det tog lite tid då det bara var 100Mbit nät plus att det var riktigt slöa IDE-diskar. Efter att konverteringen var klar så skulle jag boota upp den nya virtuella maskinen. Detta lyckades INTE och jag fick bara meddelandet ”No operation system found”. Funderade lite kring detta och testade att mounta den VMDK fil som min nya virtuella maskin bestod av till en annan virtuell maskin för att kontrollera innehållet på denna. All data fanns där och jag redigerade ”boot.ini” för att va säker på att den gick mot rätt partition. Testade även att boota maskinen med en win srv 2003 skiva och körde FIXBOOT & FIXMBR utan resultat. Kollade även i diskmanagern att partitionen var aktiv.

Hyffsat frustrerad så började jag googla på detta då jag var ganska säker på att felet hade att göra med att det var en mjukvaruspegling på diskarna när konverteringen kördes. Det jag fann som besvarade min fundering och förklarade problemet var att VMware Convertern bara fungerar med basic eller dynamiska diskar. Men den dynamiska disken måste bestå av endast en fysisk disk.  Det man alltså måste göra innan konverteringen kan ske är att bryta speglingen på dessa diskar i diskmanagern (”break mirror”).

Convertern fungerar så att den försöker att skapa samma antal virtuella diskar som den hittar fysiska diskar under konverteringsprocessen. Detta innebär att diskarna måste ha unika enhetsnamn tilldelade. Om samma enhetsnamn (ex c:) delas mellan två fysiska diskar som är fallet med Windows mjukvaruraid så kommer konverteringen inte att fungera! Eller jo, den kommer att slutförs men det resulterar i att man inte har en bootbar volym.  Hårdvaruraid fungerar av dessa skäl naturligtvis bra. Något att tänka på om ni stöter på en maskin med mjukvaruraid som skall migreras till den virtuella världen.