Teknik Archive

Identifiera installerat RAM i ESXi hosten?

Ibland kan det vara bra att kunna avgöra hur mycket RAM minne som finns installerat i respektive minnesbank på ESXi hosten. Administrerar man sina hostar med vCenter så presenteras detta grafiskt under hårdvarufliken för respektive host. Kör du däremot en standalone host som inte är knuten till en vCenter så kan detta vara lite knepigare då du inte har tillgång till hårdvarufilken.

För att du skall kunna identifiera hur mycket RAM som finns installerat i respektive slot så följer du dessa instruktioner:

  1. Logga in på ESXi hosten via SSH eller DCUI.
  2. Kör följande kommando: smbiosDump
  3. Detta kommer ge dig detaljerad information om Minnet i respektive slot.

smbiosDump

Tycker man detta verkar krångligt så kan man naturligt vis även lyfta på locket och göra en okulär besiktning :)

/Andreas

vMotion varning

Skulle idag flytta en VM mellan Host X och Host Y med vMotion och fick då en varning som jag ville dela med mig av. Felet som visades löd enligt följande (se bild 1):

”Virtual ethernet card ‘Virtual Ethernet Adapter’ is of type which is not supported.  This is not a limitation of the host in general, but of the virtual machine’s configured OS on this host.”

Vad betyder då detta i klarspråk? Jo, anledningen till denna varning var i detta fall att den virtuella nätverksadapter som var konfigurerad för denna VM ej supporterades av det operativsystem som den virtuella maskinen var konfigurerad för. I detta fall var den virtuella adaptern av typen ”Flexible” (se bild 2) och operativsystemet var konfigurerat som ”Windows Server 2008 32bit” (se bild 3). Denna kombination är alltså inte supporterad.

Om vi tittar på vilka typer av NIC adaptrar som finns att välja på för detta OS (se bild 4) så ser vi klart och tydligt att ”Flexible” inte är med i listan. Lösningen på detta var alltså att lägga till en adapter som stöds och att sedan ta bort den ej supporterade. OBS! Notera alla IP-inställningar innan den gamla tas bort för att kunna konfigurera den nya med de korrekta inställningarna.

vmotion-error-8754

Borttagen nätverksadapter

Hade idag ett fall där nätverkskortet på en VM som körs på en ESXi 4.0 host helt plötsligt hade försvunnit. Då funktionen att  lägga till och ta bort hårdvara ”Hot Add/Remove” under drift tillkom i vSphere så misstänkte jag att detta kunde ha med saken att göra. Och när jag tittade i loggen för den drabbade servern så hittade jag mycket riktigt följande rader:

Apr 13 11:48:32.330: vmx| Powering off Ethernet0
Apr 13 11:48:32.331: vmx| Hot removal done.

Detta bevisar alltså att någon nyttjat funktionen att ta bort nätverksadaptern under skarp drift. Nätverksadaptern visas under ”Safely Remove Hardware” i ”system tray”. För att undvika att detta sker igen så bör man avaktivera denna funktion för den virtuella maskinen genom att sätta parametern devices.hotplug till false enligt följande bild. Det kan vara bra att veta att detta  inte påverkar möjligheten att lägga till/ta bort CPU eller minne under drift utan endast NIC och SCSI adapters.

disable-hotplug

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.