Gyakorlat (t)eszi a mestert

A napokban nekiveselkedtem a demózáshoz használt rendszerünk (alapos) újjáépítésének és az eközben szerzett tapasztalatokat szeretném megosztani ebben a kis cikkben. Persze az is kiderül a végére, hogy miért is eszi a gyakorlat a “mestert” (és főleg annak idejét).

Elöljáróban

Mit is építgetek újjá? Aki járt októberben a virtualizációs TechNet rendezvényen az láthatta azokat a SUN szervereket, amikkel a demókat készítettük. Nos, azóta is használjuk ezeket a vasakat kisebb-nagyobb demókhoz, csak hát a gyakori, sokféle (és általában sietős) telepítés, virtuális gép létrehozás/másolás/faragás erőteljesen megkoptatta a rendszer egészségét. Ideje volt hát kijavítani és egyúttal kipróbálni, hogy hogyan is működik a valóságban az, amiről az ember olyan sokat beszél :-). A vas tehát 4db SUN Fire 4150-es és egy 4250-es szerver, az utóbbi teletömve diszkkel, mert ez adja storage funkciót (iSCSI, természetesen). A hálózatot két 3Com 2169-es L3 switch biztosítja. Kis tervezgetés után az alábbi koncepciót találtam ki, így a hálózat és a storage elérése is megfelelő lett (illetve kis kompromisszum árán még az Internet is elérhető).

Virtualizációs környezetről lévén szó a storage és az Active Directory életre lehelése után a következő dolog a Hyper-V szülő partíciók telepítése volt. Mivel mindent virtuális gépként fogunk futtatni, ezért mind a négy 4150-es gép Windows Server 2008 Enterprise Edition-nel települt (teljes telepítés, mert az iSCSI telepítése/konfigurálása/javítása a Server Core-on ugrásszerűen növelte volna az ősz hajszálaim számát, amiből így is van elég). Amíg települtek az alapkonfigurációk, tovább finomítottam a terveket a virtuális gépekre vonatkozóan. Hamar kizártam például azt a csábító lehetőséget, hogy minden gép legyen tagja a tervezett cluster-nak. Egyszerűen azért, mert

1. az egyik gépet rendszeresen visszük rendezvényekre, fürttaggal ezt nem lehetne tenni;
2. hová tegyem akkor a virtuális gépben futó SCVMM-et és főleg hogyan vezéreljen pl. egy Quick migration-t, ha éppen ő maga mozog?

Így tehát egy két tagú fürt mellett döntöttem, az SCVMM VM pedig az egyik további magában álló gépen lakik a DPM virtuális gép társaságában. A negyedik gépen egy tartalék tartományvezérlőt építettem utóbb, arra a ritka esetre, ha az elsődleges DC-t (ami több gép hiányában egyben a storage is) újra kell indítani. A haditerv szerint a fürtre egy 2003-as (x64 Enterprise) és egy 2008-as VM került, előbbin egy SQL, utóbbin egy SCOM 2007 és mivel külön-külön LUN-okat készítettem nekik, mozoghatnak egymástól függetlenül is a node-ok között, sőt még a preferált node-ot is beállítottam, hogy általában ne legyenek egy fizikai gépen.

Minden szépen is alakult, amíg egyszer csak felfigyeltem az SCVMM-ben arra, hogy nem látja a cluster-en futó virtuális gépeket és makacsul meg is tagadott minden további akciót és információt, hogy mi is fáj neki.

Na jó, de mit is jelent az “unsupported cluster configuration”?

Legyünk biztosak benne, hogy elsősorban rendszergazdai következetlenséget. Igen ám, de hol? A hiba okát ugyanis az SCVMM sajnos nem árulja el, tehát rutinosan blogokból kell kitúrnunk. Menjünk végig a listán: látja-e mindkét node a storage-ot? Igen. Ugyanazokat a LUN-okat látja-e? Igen. Működik-e a quick migration a hibajelenség ellenére. (Csodálkozó szemek, majd kuncogás), igen. Szóval igazán nagy baj nem lehet. Nézzük csak a Hyper-V konfigurációját! Látszólag egyezik. Kicsit jobban megnézve mégsem, az egyik virtuális switch neve egy szóközzel több. Na, ne! De. A virtuális switchek nevének betűre, sőt, nagybetűre egyezniük kell. Javítás, frissítés az SCVMM-ben -vagyis Repair a virtuális gépen és Ignore (mármint az előző frissítési próbálkozást). Láss csodát, a konfig rendben. 

Aztán egy fél óra múlva ott virít megint.

Keresés újra – és a megoldás a leghétköznapibb: a magas rendelkezésre állás az utolsó csavarig értendő. Tehát ha az integrációs komponenseket tartalmazó ISO képet csatolom a virtuális gép DVD meghajtójához, annak is magas rendelkezésre állású elérési útról (értsd fürtözött megosztás) kell jönnie, különben a fürt egészen addig hisztizik, amíg az ISO-t le nem veszem.

A kisördög persze tényleg felvihog: tényleg leellenőrzi az SCVMM, hogy az elérési út fürtözött-e? Nézzük meg! Gyors iSCSI hegesztés, 100 GB diszket hozzácsapok a fürthöz, létrehozom fürtözött megosztást. Rámásolom az ISO image-t és lám, tényleg zöld marad az SCVMM. Tanulság? SCVMM-et hibatűrő Library megosztással telepítünk, oda rakosgathatjuk a mindenféle szükséges dolgainkat (ISO image-ek, sysprep-elt vagy tárolt vhd-k, Powershell scriptek, template-ek stb.) és nem felejtjük el odatenni a a vmguest.iso-t sem !

Körök a cluster körül

Van még egy dolog, ami előidézheti ezt a bizonyos “unsupported cluster config”-ot, de ez nem annyira a virtualizációhoz, mint inkább a cluster sajátsságaihoz kapcsolódik. Az egész dolog akkor kerül elő, ha pass-through  (PT) diszket dugdosunk valamelyik virtuális gépünk alá. A PT diszk hozzáadása a fürtözött virtuális géphez ugyanis eléggé kötött procedúra. Nézzük a fő lépéseket:

1. Tegyük láthatóvá a LUN-t a fürt tagjai számára, a diszket tegyük online-ba, hogy megkapja a signature-t, majd tegyük ismét offline-ba!
2. Ha futna a virtuális gépünk, akkor állítsuk le! (Ezt a lépést úszhatjuk majd meg az R2-től, ha már van SCSI adapter a VM-ben – csak simán hozzáadhatjuk a diszket a géphez.)
3. Adjuk hozzá az offline diszket a virtuális géphez! (Nagy piros betűkkel írjuk fel a noteszbe, hogy a cluster-hez még csak véletlenül sem adtam hozzá!!)
4. Most ugorjunk át cluster MMC-be és kattintsunk a Refresh virtual machine configuration linkre a jobboldali menüben. Ez az egyetlen módja annak, hogy a fürtünk úgy vegye felügyelet alá a diszke(ke)t, hogy közben nem zárolja a saját kizárólagos használatára (amivel persze ellehetetleníti a VM hozzáférését). Minden egyéb –kézi- beállítás esetén felvirít az SCVMM-ben a már jól ismert hibajelzés – teszem hozzá: joggal.

A lépések bővebben itt olvashatók (illusztrációkkal): http://blogs.technet.com/askcore/archive/2009/02/20/adding-a-pass-through-disk-to-a-highly-available-virtual-machine.aspx

A fürt konfigurálgatása közben eleinte nem értettem, miért olyan nehézkes az élet, ha le akarom állítani valamelyik VM-et (amit persze a Hyper-V MMC-ből nem lehet, mert a fürt rögtön újraéleszti, hiszen nem tud arról, hogy én szándékosan állítottam le). Az erőforrások offline-ba rakosgatása közben aztán egyszer csak bevillant, hogy volt egy hotfix, ami éppen a fürtöt okosította fel a Hyper-V kezelésére. Kis keresgélés ezen az oldalon http://technet.microsoft.com/en-us/library/dd430893.aspx és megtaláltam a KB951308-as cikket, ami tényleg kezessé tette a fürtkezelést. A virtuális gépet kiválasztva a jobb oldalon előjön több, a Hyper-V MMC-ből már ismert kezelési opció, köztük a leállítás is. Azt mondom, VM cluster üzemeltetésnek ne vágjunk neki enélkül.

Még egy fontos megjegyzés, ami részben kapcsolódik az előbbi lépések közül az elsőhöz (mehet szintén a noteszbe, pirossal): ha Windows Server 2003-nak szánjuk a PT diszket, akkor még csak véletlenül se formázzuk meg a 2008-as hoszton! A 2003-as gép látni fogja ugyan, hogy létezik ott egy partíció, de sem azonosítani nem tudja (nem látja NTFS-nek, nem lesz betűje stb.), sem lecserélni. Le tudjuk ugyan szedni a partíciót és létrehozhatunk újat, de a formázás a folyamat végén elhasal, mondván: nem tudja felírni a második MFT táblát (persze ezt is csak akkor árulja el, ha parancssorból formázunk, /q nélkül). A válasz abban rejlik, hogy a 2008-as szerver bizony 6.0-ás tranzakciós és öngyógyítós NTFS-re formáz, amit a 2003-as nem tud használni, ő szegény leragadt az 5.2-nél.