Leta i den här bloggen

2011-10-31

Citrix Summit Europe 2011 - Dag 1 - Learning lab: XenServer technical deep dive and troubleshooting (del2)

Detta är andra delen av denna post. Första delen hittar man här.

I måndas förra veckan gick jag en Learning Lab på Citrix Summit 2011. Labben hette "SUM409W: XenServer Technical deep dive and troubleshoting" och varade i 5,5 timmar... Jupp helt rätt fem och en halv timme för en labb. :)

Detta är mina anteckningar från den sessionen.

Vi fortsätter där jag avslutade förra posten och vi är alltså framme vid labb 4.
Denna labb handlade om en fil som heter "state.db".
En rätt viktig fil faktiskt. Det den filen som innehåller all information om hur XenServer hosten är konfigurerad. Vilken hårdvara som finns (CPU (antal, modell, kärnor, hastighet osv), minne, disk, nätverkskort), Om den är med i en pool eller en stand-alone maskin, Vilka Virtuella maskiner som finns på servern, hur de är konfade, om de är igång eller inte osv. osv.
I princip allting som XenServer behöver veta om sin miljö.

Om det dessutom är så att hosten är medlem i en pool, tja då är det ännu mer info i denna fil. Då är det nämligen med info om vilka virtuella maskiner som finns i poolen, om dessa är startade, på vilken host osv.

Det är datat i denna fil som replikeras mellan hostarna så att alla maskiner vet hur miljön ser ut.

Man hittar filen på "/var/xapi/state.db" på en XenServer host.
En kul grej man kan göra är att kopiera denna fil med exempelvis WinSCP till sin windowsmaskin med XenCenter. Därefter man man i XenCenter välja att lägga till en server (Öppna XenCenter => klicka på "Add New Server"), men istället för att peka ut IP-address på servern man vill lägga till så anger man "state.db"-filen och skriver in användarnamn+lösenord till servern som filen kommer från.

Därefter kan man i XenCenter kika runt på rätt mycket saker filen. Det som visas är statisk information så det kommer inte att uppdateras minnesutnyttjande eller CPU-utnyttjande på hostarna, men man kan få reda på hur det såg ut när filen kopierades.

Ett annat sätt att kika i state.db-filen är att öppna den i XML Marker. Då kan man titta på precis all information i filen, men är man inte van att kika i XML-filer så kan det kännas som lite mycket information...  :)


Vi gick sedan över till att kika på backupper. Med andra ord Labb nr 5. :)
Denna labb tycker jag personligen var rätt kass. Man fick testa att högerklicka på en Host och välja "Back Up...".
Man fick testa att stänga ned en Virtuell Maskin, högerklicka på den och välja "Export..."
Därefter att göra samma export igen, fast denna gång från en SSH-session.

När detta var klart så fick man testköra "xe pool-dump-database"-kommandot. Detta kommando tar en kopia på pool/host konfigurationen (den där "state.db"-filen som vi talade om nyss). Med andra ord; det gör ungefär samma sak som vi gjorde med WinSCP i Labb 4 när vi kopierade state.db filen.

Nästa steg var att ta en backup på "Virtual Machine Metadata". Detta gjordes också från en SSH-session men denna gång genom att använda xsconsolen och välja "Backup, Restore and Update" => "Backup Virtual Machine Metadata".

Det jag saknade i denna labb var att få nått som i sin tur går att använda rent praktiskt. Att sitta och göra manuella backupper på servarna funkar ju inte.
Att vara tvungen att stänga ned servrar för att kunna ta en backup på dem fungerar inte heller i en produktionsmiljö.
Som jag ser det finns det två sätt att göra backupper på en XenServer-miljö:
- Backupagenter installerade på Hostar och VMar och sedan schemalagda backupper till backupsystemet.
- Schemalagda script på  Hostarna som dumpar ut host/Pool-config till en gemensam plats och sedan backup på traditionellt sätt av VMar.

Självklart finns det fler sätt att göra backupper (exempelvis kan Storage-miljön ha sätt för snapshots och liknande), men de två jag tog upp ovan är de vanligaste jag ser ute hos kunder.
Jag hade verkligen gillat att få en del bra tips kring backupper, men det var ont om dem här tycker jag...
(jag kan i och för sig ha missat nått som passerat snabbt, men jag tror inte det. :))

Labb 6.
Nu blev tempot rätt högt i labbarna för att det var inte så mycket tid kvar...
Detta var lite synd, för här var det bra grejjer.
Denna labb gick ut på hur man skapar en nätverks trace. Alltså hur man avlyssnar en virtuell nätverksport i XenServer.
För att göra detta användes kommandot "tcpdump -i [device] -vvv -w [filename.pcap]" på den XenServer host där VMen var igång. ("-i"= interface, "-vvv"=very verbose logging, "-w"=Write to file).
För att analysera pcap-filen används förslagsvis Wireshark eller liknande produkt.

Labb 7 handlade om Monitorering i XenServer.
Att man kan använda XenCenter och "performance"-tabben för att se last på hostar och VMar hoppas jag att alla som var där redan visste, men vi kikade på det i ett par sekunder.
Därefter kikade vi på kommanona: "top" , "xentop"och  "uptime"
Nästa kommando var "mpstat 1" ("1"=ny rad varje sekund). Ett riktigt bra verktyg för att se hur CPUn mår på hosten.
I bilden visas alla CPU-kärnor som ett genomsnitt på varje rad (en ny rad per sekund). Vill man ha det uppdelat så att man ser alla CPU-kärnor som egna rader så kör man istället "mpstat -P ALL 1"
Höga siffror under "%iowait" tyder på att disksystemet eventuellt är  överlastat.
Höga siffror under "%steal" kan tyda på att CPUn är överlastad.

Nästa kommando var "vmstat 1".
Intressanta kolumner här är:
- si = Memory swapped in from disk /s
- so = Memory swapped to disk /s
- us = time running non-kernel code (user time/space)
- sy = time running kernel code
- wa = Time waiting for CPU IO

"iostat 1" kikades på. Ett bra verktyg för att kolla last på olika I/O-enheter.

"sar" har jag inte sprungit på tidigare (vad jag minns).
Ruskigt kraftfullt mer nästan hur många olika växlar som helst. :)
exempelvis. Om man kör "sar -q" och det kostant är mer än 2 eller 3 i run queue ("runq-sz") och "idle CPU%" från "sar -u" samtidigt är under 5% så har man nästan säkert ett problem med CPU-last.


Labb 8 hann vi inte med på grund av tidsbrist, men den skulle ha handlat om Snapshots.  :)

En rätt lång labb som åtminstone tömde min hjärna rätt ordentligt... :)
Men här var labben slut och vi skyndade oss till keynoten (som jag skrivit om i en annan post)

Inga kommentarer:

Skicka en kommentar

Related Posts Plugin for WordPress, Blogger...