- 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
-
az egyik gépet rendszeresen visszük rendezvényekre, fürttaggal ezt nem lehetne tenni;
-
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:
- 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!
- 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.)
- 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á!!)
- 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.
- Éles bevetésen a Core configurator
-
A bevetés azért nem annyira éles, de egy demóra készülve eljött az ideje, hogy kipróbáljam, mennyit segít a kis alkalmazás a Server Core konfigurálásában.
A kísérlet alanya egy leendő tartományvezérlő, ami még némi fájlkiszolgálói feladatot is kapni fog, az érdekesség kedvéért egy iSCSI tárolóhoz csatlakoztatva. Az egész környezet természetesen Hyper-V felett épül ki, és végső állapotában majd egy Data Protection Manager demó alakul ki belőle.
A kiszolgáló telepítésében nincs semmi izgalmas, már biztosan mindenki többször végigjátszotta. A Core configurator (legyen ezentúl csak CC) első indításához felcsatoltam a letöltött ISO képet, majd keresni kezdtem valami használható komponenst rajta. A legjobb jelöltnek a Setup-Core.wsf fájl tűnt és valóban az a CC lelke, de az első futtatáskor bizony két-három hibaüzenettel fogadott. Nincs hálózat! Hát, persze hogy nincs, hiszen kimaradt az integrációs komponens frissítése, és így a szintetikus hálózati adapter nem látszik. A telepítés és az újraindítás után már sirámok nélkül feljött az alkalmazás nem csinos, de praktikus ablaka.
Kezdjük akkor a hálózattal, hogy megoldódjanak a kommunikációs gondok. Válasszunk hálózati csatolót és konfiguráljuk be! A kérdések logikus sorrendben következnek egymás után, tehát nem nehéz a feladat, és ha bekukucskálunk a háttérben futó parancsablakba, akkor láthatjuk is, hogy milyen paranccsá csavarozta össze a felület a megadott paramétereket. A mellékelt képen a gép átnevezésének és a statikus IP cím beállításának lépései látszanak – netdom és netsh, de mennyivel könnyebb volt ez így.
Haladjunk tovább a szerepkörökkel, legyen DNS kiszolgálónk és tartományvezérlőnk! A szerepköröket két körben telepíthetjük, az elsőben mindent, ami nem IIS, a másodikban csupa IIS szerepet.
Amikor ezekkel megvagyunk, nekiláthatunk a tartomány életre keltésének. Ez a legfogósabb feladat, hiszen egy többsoros fájl-t kell összeraknunk a dcpromo vezérlésére. Nos, ez a rész őszintén szólva csalódást okozott. Nem telepíthető ugyanis új tartomány a CC segítségével. Egy lehetséges kerülő, hogy csatlakozunk egy létező tartományhoz, válaszolunk a feltett kérdésekre és az utolsó lépésnél nem nyomunk OK-t arra, hogy akarjuk-e a dcpromo-t futtatni most. Ehelyett kicsi „kipofozzuk” a generált válaszfájlt, hogy azt tegye, amit mi szeretnénk és más néven elmentjük egy könnyen megjegyezhető helyre. Ez a lépés fontos, mert alapértelmezésben az aktuális felhasználó temp mappájába kerül a válaszfájl, és ha leállítjuk a műveletet, akkor automatikusan törlődik is (ami egyébként hasznos, hiszen benne van a DS restore mód jelszava, ami nem jó, ha az idők végéig lapul valahol egy sima szöveges fájlban).
Egy lehetséges "jó" válaszfájl dcpromo-hoz:
[DCInstall]
ReplicaOrNewDomain = Domain
NewDomain=Forest
NewDomainDNSName = demo.local
InstallDNS=Yes
ConfirmGC=Yes
RebootOnCompletion = Yes
SafeModeAdminPassword = <ide jön a jelszó>
Ezzel a kis kerülővel már megy a dolog, van tartományvezérlőnk, csapjunk bele az iSCSI-ba.
Az egyszerűség kedvéért tételezzük fel, hogy az iSCSI target már megfelelően elő van készítve, nézzük egyszerűbb-e a csatlakozás a CC segítségével, mert parancssorból ez bizony nehézkes.
Bizony egyszerűbb a dolog, nagyjából három lépés: telepítsük az iSCSI szolgáltatást (értsd tűzfal kinyit, szolgáltatás elindít), aztán kapcsolódjunk a target-hez, jelentkezzünk be, majd tegyük a kapcsolatot tartóssá. (Vagyis egyes, kettes, hármas és négyes gomb.) Aztán öttől-nyolcig ellenőrizzük a kapcsolatokat. Ha minden rendben, akkor a diskpart már mutatja is az elérhető diszket és nekieshetünk a formázásának. A parancsok innét már egyszerűek:
select disk 1, create partition primary, select partition 1, assign letter e:, format quick, exit.
És íme, használható a diszk a tárolónkon.
- Könnyű szívvel…
-
…avagy: Server Core könnyedén.
A címben van egy kis nyelvészkedés, de a lényeg a kis alkalmazás, amiről szó van. Olyan, mint egy fájdalomcsillapító, mert bizony vannak műveletek, amiket nem egyszerű elvégezni a Server Core-on. De most talán változik a helyzet.
Úgy egy fél éve számoltam be arról a kis alkalmazásról, amit Guy Teverovsky írt a Server Core konfigurálását megkönnyítendő. Nos, most érkezett egy újabb megoldás, ami a Server Core-on túl boldogul a frissen megjelent Microsoft Hyper-V Server konfigurálásával is (noha, az utóbbinak legalább van egy egészen használható “gyári” karakteres konfigurátora).
Az új megoldás a Codeplex-ről tölthető le és folyamatos frissítéseket ígérnek hozzá a fejlesztők. Mivel több, mint az előző felület? Nos, segít például beállítani az iSCSI kapcsoltokat is (erről is írtam korábban, Server Core-on egyáltalán nem könnyű belőni) és a másik megoldással közös részekhez is ad pluszt: pl. nemcsak állítható a frissítés módja, de lekérdezhetők a már telepített frissítések.
Használhatósági szempontból az is hasznos, hogy nemcsak CAB formátumban, hanem ISO-ként is elérhető, ami a virtualizált Server Core-nál nagy könnyebbség, főleg ha elzárt hálózati szegmensen akarjuk telepíteni. Szóval, próbára fel, már nem mondhatjuk, hogy szép-szép a Server Core, de nehéz konfigurálni…
A letöltési link: http://www.codeplex.com/CoreConfig .
- Technológiák és emberek
-
Technorati Tags:
IT,
emberekNemrégiben egy zártkörű szakmai konferencián vettem részt Seattle-ben és meglepő tanulságokkal szolgált, amikor végiggondoltam az ottani eseményeket. Először is technológiai szempontból sokkal szürkébb volt az esemény, mint a tavalyi. Ez részben érthető is, hiszen a következő 12 hónapban nem várható olyan áttörő jelentőségű termék a piacra, mint volt a Windows Server 2008 egy évvel ezelőtt. A másik fontos észrevétel a hangsúlyok eltolódása volt. Az emlékezetes előadások között egyetlen egy technológiai tartalmú volt (ki más, mint Mark Russinovich?) és legalább kettő, ami teljesen másról: emberekről és kommunikációról szólt.
Amiről Mark beszélt, arról én –egyelőre- nem tehetem ugyanezt. Majd talán valamikor késő tavasszal.
A két “humán” tartalmú előadásról viszont talán fontos hogy szó essen. Az egyik előadás Microsoft-os kollégától teljesen szokatlan hangnemben és tartalommal hangzott el és abszolút kellemes meglepetést okozott (bár kétséges érzelmeket keltett). Micha Kralj, beosztását tekintve architekt, tehát a legmélyebb elméleti szinten foglalkozik szoftverek fejlesztésével. Az előadás viszont egészen másról szólt. Pontosan arról, amit a címe ígért: Hol tart majd az IT 10 év múlva, és miért törődj ezzel? Trendekre és tényekre épülő elemzés volt ez (mégpedig nagyon szellemes és élvezetes formában) arról, hogy mire számítsunk a saját életünk vonatkozásában úgy tíz múlva. Az üzenet pedig több, mint elgondolkodtató: kicsivel ötven felett nagyon valószínű, hogy már nem IT-val fogok foglalkozni vagy legalábbis teljesen más tartalommal, mint most. Az új tartalom kitalálását pedig ideje elkezdeni. Az előadásban kisebb részletek is voltak, amiről érdemes lesz majd szót ejteni, ezt majd időről-időre megteszem itt az IT-s blogban.
A másik előadó Simon Sinek, kommunikációs szakértő. Angol létére már nagyon amerikai, sok tekintetben már amerikai sémák szerint kommunikál és azoknak a sémáknak a hatékony használatára oktat. Volt viszont legalább két tanulsága annak, amit elmondott. Az egyik egy indirekt következtetés, amit leteszteltem a rá következő hét folyamán: mi kelet-európaiak, vagy még inkább mi magyarok nem tudunk/akaruk/merünk hinni dolgokban és lelkesedni dolgokért. Valahogy belénk égetődött egy örökös pesszimizmus és kételkedés. És egyre kevésbbé látszik úgy, hogy ez egy egészséges hozzáállás lenne. Az egy hét során beszéltem mindenféle nemzet képviselőivel: chileivel, belgával, mexikóival, angollal, sőt még orosszal is és egyikükben sem éreztem ilyen mértékű negatív kisugárzást. Azt viszont világosan látom: komoly teljesítmények nem születnek kételkedésből és távolságtartásból, gáncsoskodásból és rosszindulatból. (Erre példa az olimpia is!?)
A másik tanulság egyszerű és kézenfekvő, de ördögi körhöz vezet, ha az előző tanulságra alkalmazzuk. Az embereket kétféle képpen lehet befolyásolni: manipulációval és inspirációval. Az előbbi zajlik ma Magyarországon széltében-hosszában (média, politika és szinte minden nyilvános=családon kívül mutató kapcsolatunk). Ha pedig valaki venné a bátorságot és inspirálni próbálná az embereket, akkor egyszerűen nem értenék, elutasítanák, lehülyéznék, mert annyira nem értik/értjük azt a fajta kommunikációt. Nem értjük, mert nem tudunk azonosulni dolgokkal, nem merünk odaállni valami mellé és még kevésbbé érzelmi kötődést mutatni valami iránt. Itt pedig a kör bezárul: marad a manipuláció, mert azt elfogadjuk, mint kommunikációs formát. Az értelmesebbje persze átlát rajta és elvileg elutasítja, de bőszen alkalmazza maga is, egyszerűen azért, hogy célt érjen (mert ez az egyetlen célravezető mód). És elbukik az inspiráció, mert nem engedjük a sztereotípiákon hízlalt énünket más módon elérni. A spirál pedig csak tekereg-tekereg, csak sajnos lefelé…
Az inspirációra épülő kommunikációra égető szükség lenne, mindenhol ahol egymással szóba állunk. Mert ez az, ami hosszútávú, bizalomra és elfogadásra épülő kapcsolatokat képes építeni. Olyat, amit holnap is vállalni tudok.
- Szerverkonszolidáció -apró ötletek az első lépésekhez
-
A TechNet Magazin júniusi számában megjelent cikkem teljes változata. Valamivel több képpel. Különös aktualitása a dolognak, hogy két nappal a Hyper-V RTM megjelenése előtt került nyomdába.
A virtualizációs technológiák megítélése korántsem egységes az informatikusok körében. Vannak, akik számára már teljesen természetes, hogy a felügyelt rendszereik egy része virtuális gép. Az óvatosabbak számára ez a technológia még inkább csak játék. A cikkel továbbgondolós játékra csábítom az utóbbi tábor tagjait is, bízva abban, hogy a technológián túlmutató érvek közül is találnak megfontolandót.
Csaknem két évvel ezelőtt jelent meg a TechNet Magazinban Lepenye Tamás kollégám Tervezz merészen! című cikke. Ajánlom mindenkinek újraolvasásra. Akármekkorát változott ugyanis időközben a virtualizációs technológia, a megközelítés, a konszolidációs feladat megvalósítására alkalmazott módszer a mai napig megállja a helyét. Talán csak annyi változott, hogy megjelentek olyan alkalmazások, amelyekkel kevesebb fáradsággal, rendszerezett és jobban használható adatokat gyűjthetünk a konszolidálásra jelölt rendszerekről. Amikor pedig nekivágunk a feladatnak, akkor használhatjuk például a System Center Virtual Machine Manager-t, hogy fizikai gépeinket virtuális gépekké konvertáljuk. No, de ne szaladjunk ennyire előre! Haladjunk nagyjából abban a sorrendben, ahogy konszolidációs folyamat halad!
_thumb.jpg "Bb897506_image2(en-us,TechNet_10)")
1. ábra - A konszolidáció tervezési folyamata a TechCenteren
Ha szerverkonszolidációra adjuk a fejünket, készüljünk fel arra, hogy hosszú ideig nem fogunk tudni látványos technológiai fejlesztéseket felmutatni. Ez a folyamat ugyanis hosszadalmas és gyakran nehézkes tervező-szervező munkával kezdődik. Legelsőként saját magunkban, illetve az IT-n belüli kollégák körében kell közös nevezőre, egységes álláspontra jutnunk a virtualizációt illetően. Tanulságos olvasmány a témában a Kusnetzky Group tanulmánya a virtualizációhoz kapcsolódó 10 legfontosabb mítoszról. Csak a négy legérdekesebb pontot emelném ki ezzel kapcsolatban:
1. Az én cégem máris készen áll a virtualizáció alkalmazására
2. Nincs szükség különösebb szakértelemre az implementációhoz
3. Nincs szükség részletes tervezésre, minden megoldható néhány kattintással
4. A virtualizáció csökkenti a rendszer komplexitását
A négy felvetett kérdést akár egymással összefüggésben is vizsgálhatjuk: a virtualizációs technológiák alkalmazása rövidtávon egészen biztosan nem csökkenti a rendszer komplexitását, hiszen teljesen új, korábban nem használt technológiai rétegek kerülnek a rendszerbe, amelyeket egyrészt meg kell ismernünk, másrészt a felügyeletükhöz szükséges folyamatokat ki kell fejlesztenünk és dokumentálnunk. Hosszabb távon jelentkezhet a komplexitás csökkenése, ha a virtualizáció egyfajta katalizátorként hat és ösztönöz bennünket a felügyeleti folyamatok pontosítására, jobb összehangolására és a lehető legtöbb feladat automatizálására. Ha többen dolgozunk az IT szervezetben, akkor szükséges lehet az egyes munkatársak feladatainak újragondolása és összehangolása is, hiszen a folyamatokat nekik kell végrehajtaniuk. Tehát igazából akkor állunk készen, ha az alapvető munkafolyamataink már rendben vannak, és van tartalék kapacitásunk a virtualizációs technológia bevezetésének idején jelentkező többletfeladatok elvégzésére. Kiemelten figyeljünk erre, ha egymagunk vagyunk „az IT”: mérjük fel, mennyi idő alatt, milyen kisebb lépéseken keresztül tudjuk elérni a kitűzött célt úgy, hogy közben nem hanyagoljuk el az élő rendszereket sem. Ezen a ponton máris a tervezésnél tartunk. Tervezni pedig kötelező! Mégpedig több irányban egyszerre. Mindenképpen szükség lesz egy pénzügyi tervre. Elég nagy a valószínűsége annak, hogy a konszolidációs folyamatot nem tudjuk véghezvinni pénzügyi befektetés nélkül, tehát feltétlenül meg kell győznünk azokat a döntéshozókat, akik finanszírozzák terveinket. Meggyőzésükhöz több helyről is gyűjthetünk érveket, néhány példát a következő fejezetben bemutatok.
A következő lépés a konszolidációs útiterv: milyen gépeket, szolgáltatásokat mozgatok virtuális platformra, milyen sorrendben, milyen módszerrel és mi tervem, ha valami nem sikerül (ez az a bizonyos gyakran elfelejtett roll-back plan). Ezen lépések tervezéséhez remekül használható a fentebb említett cikk. A tervezés másik vonulata a hosszabb távú tervezés: ha gondot okozott a fizikai szerverek túlzott elszaporodása (egyedi feladatokra, hosszabbtávú koncepció nélküli beszerzések), akkor mit fogunk kezdeni az elszaporodó virtuális gépekkel? A virtuális gépek olcsók, nem lesz meg az a beépített korlát, amit a pénzügyi lehetőségek jelentettek a fizikai gépek beszerzésekor. Sőt, virtuális gépek esetén még a licenszelés is egyszerűbb. Megvannak-e az eszközeink a hibriddé vált számítóközpontunk felügyeletére, van-e eljárásunk a licenszkövetésre? Megfelelően nyilvántartjuk, dokumentáljuk-e virtuális tárolóinkat (storage) és hálózatainkat? Több olyan kérdés, amire megnyugtató megoldást kell találnunk és ez még mind mindig csak a tervezés.
A szakértelem kérdése talán a legegyszerűbb, ezen a területen van ugyanis talán a legnagyobb motiváló erő: a technológiai érdeklődés. Aki virtualizációs megoldás bevezetésére adja a fejét, azt már valamilyen mélységben megragadta a technológia és a benne rejlő lehetőség. Szerencsére az bevezetéshez szükséges eszközök használata nem túl bonyolult. A szakértelem kérdése sokkal inkább a tervezési és az üzemeltetés bevezetési fázisban nyer jelentőséget, ahol rendszer szinten kell gondolkodni a siker érdekében. Hogy csak egyetlen üzemeltetési példát említsek: meg kell változtatnunk a javítócsomagok telepítésére vonatkozó eljárásainkat. A szokásos eljárás nagy valószínűséggel használható marad a virtuális gépek többségére és a virtualizációba nem bevont fizikai gépekre, a virtuális gépeket futtató szülő partíciók frissítése viszont jobban szervezett eljárást igényel, hiszen amikor ezeket frissítjük a rajtuk futó virtuális gépek szolgáltatásai is kiesnek. Ha technológiai szempontból nem is, de szervezési szempontból mindenképpen összetettebb a feladat. (Értjük már miért ajánlott a Windows Server 2008 Core telepítés, mint szülő partíció? Kevesebb frissítési ciklus, kevesebb fejfájás a szervezés körül. J)
Nézzünk bele néhány fontosabb folyamatba, amivel a szerverkonszolidáció során találkozhatunk, és ismerkedjünk meg néhány olyan eszközzel, ami segíthet a kezdeti fázisok nehézségeit legyűrni.
Tanuljunk közgazdászul!
Szó esett róla korábban, hogy nagy valószínűséggel szükség lesz valamennyi beruházásra, ha szerverkonszolidációba fogunk. Az üzleti döntéshozók meggyőzése, támogatásuk elnyerése nem könnyű feladat, hiszen nem a saját szakmánk fegyvertárából kell érveket kerítenünk, hanem olyan gazdasági tényekkel kell előállnunk, amihez a meggyőzendő fél valószínűleg sokkal jobban ért. Hogyan keressünk tehát muníciót? Milyen érvekkel induljunk pénzügyi források megszerzésére?
Az egyik lehetséges út a jelenlegi rendszerekben kimutatható erőforrás-pazarlás kimutatása, noha ezzel óvatosan kell bánni, nehogy a mi hibánkként vagy hozzá nem értésünk jeleként jelenjen meg a tény, hogy erőforrások állnak kihasználatlanul. Mutassuk meg inkább a dolog pozitív oldalát: eddig műszaki megfontolások, pl. biztonsági okok miatt külön gépekre kellett telepítenünk bizonyos alkalmazásokat, ami pazarláshoz vezetett, mert nem tudtunk a feladathoz éppen elégséges hardvert vásárolni, hanem csak jóval nagyobb teljesítményűt. Most az új technológia lehetővé teszi az erőforrások koncentrálását és átcsoportosítását, amivel hosszabb távon beszerzések válhatnak szükségtelenné. Az érveinket alátámasztó mérési adatok összegyűjtése eddig sem volt lehetetlen, hiszen régóta elérhetők a megfelelő teljesítményszámlálók, amikből ezeket kinyerhetjük. Szerencsés esetben készen is kaphatjuk az adatokat a System Center Operations Manager (vagy kisebb cég esetén System center Essentials) jelentéseiből, de mit tegyünk, ha egyik rendszer sincs bevezetve? Mielőtt tömeges performancia mérésbe kezdünk, nézzünk inkább körül például a Microsoft weblapjain. Egy nemrégiben közzétett ingyenes kis eszköz sok egyéb dolog mellett a szerverkonszolidációhoz szükséges adatok összegyűjtésében is segíthet. A Microsoft Assessment and Planning Toolkit nagyon hasznos információkat képes nyújtani például Vista, Windows Server 2008 vagy Office 2007 bevezetés előtt, amikor megmutatja melyik eszközünk áll készen az adott szoftver futtatására. Szerverkonszolidációhoz pedig még a teljesítményadatokat is összegyűjti a számunkra. A telepítőcsomag mindössze 50 megabájt, de a működéshez szükség van egy SQL szerver példányra is, ami lehet egy más célra is használt SQL valahol a hálózaton vagy kérhetjük a telepítőt, hogy töltse le és telepítse az SQL Express egy példányát. A telepítés másik előfeltétele az Office csomagból a Word és Excel jelenléte, mert az alkalmazás ebben a két formátumban készíti el (makrókon keresztül) a jelentéseit, amiket akár közvetlenül nyomtathatunk is, amennyiben az angol nyelv nem akadály. A telepítést követően készítsünk egy adatbázist ahová a szoftver a leltárt és a teljesítményjelentéseket elkészíti, majd állítsuk össze a felmérendő gépek listáját. Míg az bevezetési feladatokhoz szükséges lépésekben sokféle bemeneti adatforrás között választhatunk (Active Directory, alhálózat, SNMP community stb.), addig a konszolidációs felméréshez nekünk kell egy gép listát gyártanunk. Ezt legegyszerűbben a DNS rekordok listájából generálhatjuk, kihagyva az érdektelen gépeket (pl. asztali gépek és notebook-ok). Ezzel a módszerrel viszont akár tartományon kívüli gépeket is felmérhetünk, pl. az IP címük megadásával a listában. A következő lépésben meg kell adnunk a felméréshez használandó jogosultságokat. Célszerű először egy, a legtöbb gépen rendszergazdai joggal rendelkező fiókot megadni és azt mondani, hogy ez mehet minden felmérendő gépre, majd megadni a kivételeket (pl. a nem tartománytag gépek rendszergazda fiókjait). Használható eredményhez az is szükséges, hogy a megfelelő tűzfal szabályok érvényesüljenek (WMI, Remote Performance Logging, Remote Registry). Ezután már csak meg kell adnunk, mennyi időn keresztül szeretnénk az adatokat gyűjteni. Az alapértelmezés egy óra, ami elég is lehet, ha pl. a napközbeni tipikus terhelésre vagyunk kíváncsiak. Ha az átlagos terhelést szeretnénk látni, hagyjuk futni a felmérést legalább 24 órán át! Az eredmény a korábban említett összegző fájlokban jelenik meg. A 1. képen a virtualizáció előtti átlagos kihasználtsági mutatókra láthatunk példát. Ezek azok az értékek, amiket érdemes az üzleti döntéshozó figyelmébe ajánlani, illetve azt a lehetőséget, hogy például a processzorok kihasználtságát 10% alatti értékekről 40-50% feletti értékre tudjuk emelni a virtualizációs technológiákkal.
2. ábra - Kiszolgálók terhelés jelentése
A másik két terület, ahol érveket találhatunk a pénzügyi döntéshozók meggyőzésére az a villamosenergia-felhasználás és a licenszgazdálkodás. Kezdjük az energiával. Csak próbaképpen kikerestem az egyik hardvergyártó néhány belépőszintű és középkategóriás kiszolgálóját. Az alacsonyabb osztályt tekintsük tipikusnak, mint egyedi funkciót ellátó szervereket (ezek amúgy is csaknem asztali PC kategóriájú gépek). A középkategóriát jelöljük meg, mint virtuális gépek futtatására alkalmas kiszolgálót és mindkét kategória esetén számoljunk a maximális kiépítettségre vonatkozó energia felhasználással és hőleadással. A gép által termelt hővel kissé bonyolult számolni, hiszen a gyártók általában BTU/h mértékegységben adják meg az értéket, amit elég nehéz kezelni. Az egyszerűség kedvéért konvertáljuk át az értéket watt-ra és számoljunk vele úgy, mint többletfogyasztással (hiszen tulajdonképpen a felesleges hő elvezetésére ezt az energiamennyiséget valóban be kell vinnünk, csak éppen a klímaberendezés oldalán). A képlet elég egyszerű: 1000 BTU/h = 293 W. A gyártói műszaki dokumentációra épülő átszámított adatokat a következő táblázat mutatja.
| | Tápegység (W) | BTU/h | Energiaigény (W/h) | Megjegyzés |
| Szerver 1 | 600 | 1915 | 1161 | Belépő szint, álló formátum. |
| Szerver 2 | 365 | 1885 | 917 | Belépő szint, álló formátum. |
| Szerver 3 | 630 | 1794 | 1156 | Belépő szint, álló formátum. |
| Szerver 4 | 1170 | 3990 | 2339 | Középkategória, álló formátum. |
| Szerver 5 | 500 | 1194 | 850 | Belépő szint, rack formátum. |
| Szerver 6 | 640 | 2174 | 1277 | Belépő szint, rack formátum. |
| Szerver 7 | 1172 | 3990 | 2341 | Középkategória, rack formátum. |
Az eredmény egészen érdekes. Ha legalább három kisebb teljesítményű gépet össze tudunk vonni egy középkategóriás kiszolgálóra, akkor az energia felhasználás már csökkenthető. Csak egy kis ellenőrzés: a kettes típusú szerverből három darab 2751 W energiát fogyaszt óránként, ha ezeket konszolidáljuk a négyesre, ez az érték 2339 W-ra csökken, a megtakarítás 15% körüli. Egy negyedik kettes típusú gép konszolidálása pedig már 35% feletti megtakarítást jelenthet.
A szoftver költségek számításához emlékezzünk arra a szabályra, hogy a Microsoft szerver operációs rendszerek verziójuktól függően tartalmaznak további licenszeket virtuális gépek operációs rendszerihez. Így a Windows Server 2003 és Windows Server 2008 Standard változatai egy, az Enterprise változatok négy, a Datacenter változatok korlátlan számú további operációs rendszer licenszet tartalmaznak. Ráadásul csak az aktív példányokkal kell számolnunk, amelyek aktuálisan futnak. A további számításokban on-line kalkulátorok segíthetnek bennünket. (Figyelem, az árakat csak viszonyítási alapként használjuk, a pontos adatokért kérdezzük szoftverszállítónkat!)
3. ábra - Webhely a szoftverköltségek számításához
A mellékelt képen csak az operációs rendszerek költségét számoltattam ki (B. mező - világoskékkel) egy, kettő és négyprocesszoros konfigurációkra, ami a gyakorlatban akár négy-nyolc-tizenhat processzormagot is jelenthet, hiszen a költségeket fizikai processzorra kell számítani. Az eredmény itt is érdekes: négy virtuális gép egy egyprocesszoros rendszeren (akár négy processzor maggal) már olcsóbb lehet Windows Server Datacenter Edition verzióval, mintha a szükséges Standard változatokat vásárolnánk meg. Nem beszélve arról, hogy a Datacenter változat korlátlan számú további operációs rendszert enged meg, amíg a processzorok száma nem változik (ez a verzió ugyanis processzoronként licenszelt). Érdemes a kalkulátorokkal néhány „mi lenne ha” játékot eljátszani, hogy aztán a leggazdaságosabb megoldással állhassunk elő.
4. ábra - Egy képzeletbeli virtualizációs projekt megtérülése
Én túl kicsi vagyok ehhez…
Gondolkodjunk-e szerver virtualizációról, ha egészen kis cégnél dolgozunk, ahol kiszolgálóból is esetleg csak egy van? Amikor először tettem fel magamnak a kérdést, akkor szinte azonnal rávágtam: nem. Ne erőltessünk egy megoldást ott, ahová nem való. Aztán feltámadt bennem a kisördög és arra gondoltam tervezzünk itt is merészen. Tegyük fel, van a vállalatunknál egy Small Business Server 2003 kiszolgálónk. Három-négy éve teszi a dolgát a sarokban, néha már bizonytalankodik a hardvere, fontolgatjuk a cseréjét, hiszen már a garanciája is rég lejárt.
Felmerül az igény, hogy szükség lenne egy másik gépre, például egy könyvelési vagy vállalatirányítási szoftver számára. Milyen megoldások közül választhatunk? Vásárolhatunk például két új belépő szintű szervert: a megszokott SBS-ünket átmigráljuk az egyikre, a pénzügyi szoftvert feltesszük a másikra. Nincs is ezzel a megoldással semmi baj, ha csak az nem, hogy a szép új processzoraink alig-alig dolgoznak 5% feletti teljesítményen. Ennél még a legelső gőzmozdonyok is jobb hatásfokkal működtek a XIX század közepén.
Van más lehetőség? Gondoljunk egy merészet és mondjuk azt, hogy igen. Vásároljunk egy kicsit komolyabb szervert, de csak egyet. Ha jól választunk, a hardver költségben még meg is takaríthatunk egy keveset. Célozzunk meg mondjuk egy négymagos processzort, 4 GB memóriát és néhány SATA csatolófelületű lemezt (legyen ebből több, mondjuk 2×80 GB és 4×250 GB) tartalmazó konfigurációt. Vegyünk hozzá egy Windows Server 2008 Standard Edition operációs rendszert a 64 bites szériából, ami tartalmazza a Hyper-V virtualizációs megoldást. Licenszekkel máris rendben vagyunk, hiszen a Small Business Server 2003 licenszünk megvan, a Windows Server 2008 pedig önmagán felül megenged egy további példányt, így a pénzügyi rendszerünk alá is megvan az operációs rendszer.
5. ábra - Egy virtuális kisvállalat sematikus felépítése
Mielőtt nekifognánk a rendszerek átszervezésének, készítsünk legalább egy vázlatot arról, hogy hová szeretnénk eljutni: lesz egy gazdagépünk két virtuális géppel, valahogy úgy, ahogy az ötödik ábrán látható.
Ha már látjuk az alap struktúrát, kezdjük el az erőforrások elosztását. Induljunk természetesen a gazdagép operációs rendszerével, hiszen sok szempontból ez a komponens is csak egy előfizető a rendszer erőforrásaira. Ha nagyon bátrak vagyunk, telepíthetjük a Windows Server 2008-at Server Core telepítési opcióval, de ezt csak akkor vállaljuk fel, ha járatosak vagyunk ezen a területen és még a Hyper-V távoli (nem tartományi) felügyeletével is boldogulunk. (Ennek konfigurálása elég bonyolult, lásd a hivatkozott blog sorozatot.) Bátorságunk jutalma lehet a gazdagép kisebb erőforrásigénye és a kevesebb alkalmazandó frissítés. Akármelyik változatot is választjuk, a gazdagép operációs rendszerét telepítsük a 80 gigabájtos diszkekből kialakított RAID1 kötetre.
A virtuális gépek méretezését kezdjük a Small Business Server 2003 irányából. Az alap egy Windows Server 2003 R2, 32 bites architektúrával. A Hyper-V-ben rendelkezünk megfelelő integrációs komponensekkel, azt kell csak a kis rajzunkra felvezetni, hogy összesen két virtuális processzort adhatunk gépünkhöz. Memóriából valószínűleg most sem rendelkezünk két gigabájtnál többel, ennél több nem kell a virtuális gépünkbe sem. A lemezek konfigurációjánál több választási lehetőségünk van: létrehozhatunk egyetlen RAID5 kötetet vagy két RAID1 kötetet a rendelkezésre álló lemezekből. A két külön kötet előnye, hogy az SBS így nem „közösködik” a pénzügyi alkalmazással, ha bármelyik virtuális gép intenzív lemez műveleteket végez, akkor legfeljebb a közös lemezvezérlő bizonyulhat szűk keresztmetszetnek. Az egyetlen nagyobb kötet viszont lehetőséget ad arra, hogy bármelyik gép tárolókapacitását növeljük szükség esetén a VHD fájlok kiterjesztésével. Hogy a virtualizált SBS kiszolgálónk nagy sebességgel érhesse el a neki szánt tárolókapacitást, most válasszuk azt a megoldást, hogy egy úgynevezett pass-through diszk formájában rendeljük a virtuális géphez a dedikált RAID1 kötetet. A pénzügyi alkalmazásunk virtuális gépéhez rendeljünk egy virtuális processzort és egy gigabájt memóriát. (A Windows Server 2008 operációs rendszerhez rendelhetnénk akár négy virtuális processzort is, de a kisvállalatoknál szokásos alkalmazásoknak általában nincs ekkora igényük, sőt csak ritkán képesek több processzort használni). Adattárolásra használjunk rögzített méretű VHD állományt, mert ennek a teljesítménye alig marad el a fizikai diszkétől (többek között, mert a rögzített méret miatt nem töredezik). Az induló méret legyen 80 gigabájt, ez valószínűleg hosszabb időre elegendő lesz. A fennmaradó kapacitást szükség esetén mentésekre használhatjuk vagy akár újabb VHD állományt hozhatunk létre rajta és felcsatolhatjuk az SBS alá kiegészítő tárhelyként. A végső diszkkonfiguráció valahogy így alakulhat.
6. ábra - Tárkapacitás optimalizálás kicsiben
A Small Business Server migrálása nem könnyű feladat, viszont könyvtárnyi az irodalma, csak keressünk rá néhány kulcsszóra az Interneten és már találunk is néhány alternatívát. Ha konzervatív (és biztonságos) utat szeretünk járni, akkor a migráció történhet egy biztonsági mentés visszatöltésével a virtuális gépbe vagy választhatjuk az úgynevezett „swing migration” technikát, amikor egy ideiglenes (pl. egy PC-n futó) gépet vonunk be ideiglenes tartományvezérlőként, amíg a virtuális gépben újratelepítjük az SBS-t. Vállalkozó szelleműek kísérletezhetnek blokkszintű lemezmásoló szoftverekkel is és átmásolhatják az SBS kiszolgáló diszkjének tartalmát a virtuális géphez rendelendő fizikai kötetre. Ez a megoldás akár működhet is, ha a másolás után a kötetet a virtuális gépünk IDE csatolójához rendeljük. A virtuális gép hardvere alapvetően szabványos, tehát van esélye annak, hogy a Plug&Play pótolja vagy lecseréli a hiányzó hardverkomponenseket és a gép elindul. Gondosan vigyázzunk viszont az SBS eredeti lemezére (lemezeire), hogy legyen visszatérési lehetőségünk, ha mégsem sikerülne a migráció.
Az Hyper-V integrációs komponensek a megfelelő teljesítményhez mindenképpen kellenek, tehát ha a migráció sikeres (járjunk bármelyik úton) ezt a csomagot telepítenünk kell. Ezekkel a komponensekkel pedig már élvezhetjük a szintetikus hálózati csatoló és a többi szintetikus eszköz előnyeit és a VMBus nyújtotta gyors kommunikációs csatornát. A migrációhoz képest a pénzügyi rendszer „zöldmezős” telepítése már valóságos felüdülés lesz, viszonylag kevés hibalehetőséggel.
Hasznos olvasnivalók:
Lepenye Tamás webnaplója
Windows Server Virtualization TechCenter
John Howard webnaplója
- Az árva tartományok esete a globális katalógusokkal
-
Sejtelmesen hangzik talán a cím, de ez nem egy krimi. Inkább egy aprócska esettanulmány.
Az utóbbi évben két alkalommal futottam össze hasonló esettel, gondoltam hát, megosztom a történetet. Persze a rutinos, sokat látott kollégák csak meghúzzák majd a vállukat: hm, igen vannak ilyen helyzetek, de simán megoldjuk. Lehet, hogy ők igen, de a kevésbé rutinosak talán megtakaríthatnak néhány órányi bosszúságot, ha összefutnak egy ilyen szituációval és tudják mi a megoldása.
A történet főszereplői az árva tartományok és a globális katalógusok. Ők így ebben az összeállításban kölcsönösen kizárják egymást, a történet lényege ugyanis éppen az, hogy amíg léteznek árva tartományok, addig nem lesznek új globális katalógusaink.
De mit is nevezünk árva tartománynak? Azokat, amelyeknek már nincs a hálózaton elérhető tartományvezérlőjük, tehát jó eséllyel már megszűntek. A megszűnés módja viszont nem a dcpromo volt (és az utolsó tartományvezérlő bejelölése), hanem egyszerűen eltűntek a bitködben.
Na ebben az esetben jönnek a gondok, ha újabb globális katalógust akarunk életre kelteni. A directory service ugyanis tudja a leckét és keresi-keresi a hiányzó tartományt és próbálkozik szorgalmasan az objektumok szinkronizálásával. De mivel ezzel sosem jut előbbre, hiszen nincs tartományvezérlő ami az adatokat tartalmazza, ezért nem tud mást tenni, mint belesírja ezt a bánatát az eseménynaplóba. Legnagyobb bánatunkra kékkel sír - tehát az esemény csupán információ (x. tartományvezérlő előléptetése globális katalógussá késik, mert y.z tartomány nem elérhető). És.... nem lép elő a tartományvezérlőnk globális katalógussá.
Itt kezdődött a kollégáim kálváriája. Kezdetben csak csodálkoztak, hogy miért áll le a felhasználók beléptetése (meg még jópár dolog), amikor az egyik tartományvezérlőt karbantartják. Aztán amikor megadta magát a gép RAID kontrollere és leállt szerver, akkor égetővé vált a probléma. A másik esetben még izgalmasabb lett a helyzet, mert az egyetlen működő globális katalógus egy kivonásra jelölt tartományvezérlő volt és meg is kezdték a kivonását. Global catalog pipa kivesz, OK gomb megnyom és innentől kezdve leáll a tartomány. Maguk a tartományvezérlők sem léptetik be még a rendszergazdákat sem. Az egyetlen esély az autoritive restore-on túl, ha van még olyan gép, amelyiken van belépett tartományi rendszergazda felhasználó és ő tudja, hogy hová kell ilyenkor kapni.
Ide kell: http://support.microsoft.com/kb/230306/en-us.
Az elárvult tartományokat az ntdsutil nevű létfontosságú szerszámmal tehetjük jól megérdemelt helyükre: a kukába. A procedúra közben teljesen normális, ha kicsit remeg a kezünk, hiszen ilyenkor egy éles szikével kotorászunk az Active Directory belsejében. Nem árt tehát, ha a kezünket és a szemünket fokozott syntax checking és audit módba kapcsoljuk. Viszont ha ügyesen végigcsináltuk a folyamatot, akkor néhány percen belül elhárulnak az akadályok az új globális katalógus létrehozása elől és megérkezik a régvárt üzenet: Server x. is now a global catalog.
Tanulságok? Van több is.
- Tartományokat nem hozunk létre össze-vissza. Ha pedig létrehoztuk őket, akkor szabályosan szüntessük meg őket. Vannak persze extrém esetek, mint a kollégák esetében is, ahol az elárvult tartományokat a világ másik végén hozták létre, majd hagyták magukra.
- Tartsuk a rendszergazdák és főleg az Enterprise Admin-ok számát a minimumon, és ezek az emberek értsék a dolgukat és kommunikáljanak egymással! (Ez sokat segíthet akkor is, ha a világ eltérő sarkaiban dolgoznak.)
- Az új globális katalógus létrehozása nem egyenlő a pipa bekattintásával. A folyamat vége a sikert jelző eseménynapló bejegyzés, amíg nincs ilyenünk, addig gyanakodjunk.
- Tartomány egy globális katalógussal nem igazán tartomány. Éljenek a virtuális tartományvezérlők és globális katalógusok!
- Ha már iSCSi ...
-
Néhány nappal ezelőtt Petrényi Józsi barátom szépen felpakolta az érdeklődőket egy ökrös szekérre és végigrázatta őket az iSCSi göröngyös országútján. Most viszont ne tessék még felugrálni, sőt kérjük a biztonsági öveket is szorosabbra húzni, mert egy kis kerülőút erejéig befordulunk egyenest a szántásba!
Igazán nagyszerű ötlet a Server Core telepítési opció. Nem kell a grafikus felülettel bajlódni, meg toldozni-foldozni. Kevéssel beéri, elég ha erőforrás morzsákat potyogtatunk elébe.
Igen ám, de mi van akkor, ha valami trükkösebb konfigurációba szeretnénk bevonni? Mondjuk az elvetemült példa kedvéért egy iSCSi-ra épülő fürtbe? Hm. Simítsuk ki a ráncokat a homlokunkon, pörgessük fel az ujjainkat a billentyűzeten és lássunk neki!
Meglepő módon egy egyszerű konfiguráció létrehozása nem is annyira bonyolult. De ha valaki mélyebben beleszalad az iSCSicli parancs opcióinak és paramétereinek szövevényébe, akkor hamar a dzsungelben érezheti magát. Mi most legyünk jó turisták és csak tisztes távolból lessünk be a sűrűbe!
(A példában feltételezzük, hogy az iSCSi Storage kiszolgálónk harcra kész, tehát létrehoztuk a megfelelő diszkeket és előkészítettük a használatra.)
Az első feladatunk az iSCSi Initiator felélesztése. A szolgáltatás alapértelmezésben telepítve van, csak engedélyezzük és indítsuk el:
sc config msiSCSI start= auto
net start msiSCSI
Ha ezzel megvagyunk, akkor egyúttal a szükséges tűzfalszabályok is életbeléptek, tehát az iniciátorunk "átlát" a tűzfalunkon. Apropó tűzfal. Hogy később majd visszatérhessünk egérvezérelt üzemmódba, ne felejtsük el engedélyezni a szerverünk távoli felügyeletét!
netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
netsh advfirewall firewall set rule group="Remote Volume Management" new enable=yes
Most már felvehetjük a kapcsolatot az iSCSi Storage kiszolgálóval:
iSCSIcli QAddTargetPortal <ide jön a Storage IP címe>
Ezzel bekopogtattunk a kliensünkkel a kiszolgálóra, a következő lépések előtt rendeljük hozzá az iniciátorunkat a storage kiszolgálón a megfelelő diszkekhez (fürt esetén adjuk meg az összes érintett gépet, mint a fürt tagját)!
(Érdemes felfigyelni a Q betűre az AddTargetPortal parancs elején. Ez egyfajta shortcut parancsot jelöl: a legalapvetőbb műveleteket ilyen Q kezdetű parancsokkal tudjuk elvégezni, anélkül hogy belevesznénk a paraméterezésbe.)
Visszatérve a Server Core-t futtató géphez ismételjük meg az előbbi parancsot! (Azért kell, hogy kikényszerítsük a konfiguráció frissülését.)
iSCSIcli QAddTargetPortal <ide jön a Storage IP címe>
Kérdezzük le az elérhető kiszolgálók listáját!
iSCSIcli ListTargets
Ha mindent helyesen csináltunk idáig, akkor a visszaadott listában szerepel a kiszemelt kiszolgáló IQN neve (is). Ha csak a kiszolgáló IP címét látjuk, akkor kapcsoljunk át hibakereső üzemmódba, mert valamelyik korábbi lépés nem volt sikeres.
Ha megvan az IQN, akkor jelentkezzünk be a kiszolgálóra:
iSCSIcli QloginTarget <kiszolgáló IQN> <CHAP felhasználói név> <CHAP jelszó>
Akkor voltunk sikeresek, ha a kiszolgáló egy session ID-val válaszol. Viszont a kapcsolatunk még nem tartós, a következő újraindításkor elvész. Tegyük tartóssá!
iSCSIcli PersistentLoginTarget <kiszolgáló IQN> T * * * * * * * * * * * * * * * 0
Nem csalás, nem ámítás: a T után 15-ször szerepel a szóköz+* kombináció, majd szóköz+nulla zárja a sort. Aki utánajár, hogy miért pont így, az kap egy nyalókát, mindenesetre a dolog működik - kipróbáltam.
Ellenőrzésképpen nézzük meg a tartós kapcsolataink listáját!
iSCSIcli ListPersistentTargets
Ha itt megtaláljuk a kiszolgálónkat, akkor már nyert ügyünk van, de azért nézzük meg, hogy látszanak-e a kiosztott diszkek:
iSCSIcli ReportTargetMappings
Ne lepődjünk meg, ha valami rettenetes listát kapunk vissza, az sokkal jobb, mintha nem jönne vissza semmi.
Most már nyugodtan elkezdhetünk egerészni, menjünk át egy grafikus felülettel rendelkező gépre, kapcsolódjunk a Server Core-hoz a Computer Management MMC-ből, tegyünk online-ba a diszkeket, formázzuk meg és használjuk! Most már akár egy fürtbe is bevonhatjuk a gépünket, a konfigurációs varázsló szemrebbenés nélkül el fogja fogadni.
Kiértünk a szántásból, ki lehet oldani a biztonsági öveket, az utaskísérő hamarosan felszolgálja a pezsgőt, mert az iSCSI grafikus konfigurálása ehhez képest már pezsgős vacsora.
- Merre kanyarodik az út?
-
Bátorfi Zsolt kollégám Seattle felé röptében remek cikket írt arról, mi minden várható 2008-ban a Microsoft server platformjait illetően. Úgy látszik a repülés monotonitása és azok a remek zenék, amiket Zsolt hallgatni szokott ismét hatottak, mert remek összefoglalás született, ami ugyanakkor tele van kérdésekkel és várakozással. Kicsit hasonlít ez ahhoz, ahogy a kisgyerekek várják a karácsonyt (főleg, ha már nem az elsőt): tudják, hogy eljön, tudják, hogy jó lesz és biztosan kapnak valamilyen ajándékot, még ha nem is tudják pontosan mit. Legfeljebb reménykednek, hogy azt kapják, amire leginkább vágynak.
Szerintem a hazai üzemeltetői közösség jelentős része ugyanígy várta a Windows Server 2008-at. És a következő néhány bekezdésben nem is igazán az új operációs rendszert szeretném méltatni, azt megtesszük kollégáimmal sokszor, sok helyen. Inkább azokat a gondolataimat osztanám meg, amik arról szólnak, hogyan változik/változhat meg a munkánk, a napi életünk az új rendszer hatására.
Szép dolog ez a virtualizációs történet: érdekes a technológia, az alkalmazás sokféle lehetősége. Szeretek ezzel foglalkozni és másokat is erre bíztatni, és itt most nem jön "de", ahogy az általában jönni szokott. Inkább jön egy "és".
ÉS mostanában el-elgondolkozom azon, hogyan hat majd az egyre terjeszkedő virtualizáció az emberre? Arra az emberre, aki kitalálja, felépíti és üzemelteti. Arra, aki csak használja vagy éppen nem is tud róla, hogy használja. És arra aki, egyre nehezebben tudja eldönteni, hogy mi az az életében ami valóságos, és mi az ami virtuális (tehát csak látszat).
A kérdéskör első felére viszonylag könnyebb válaszokat adni, a magam véleményét most meg is írom. A második kör messzebbre vezet, arról egyszer majd talán a nem szakmai blogomban írok hosszabban.
A Windows Server 2008 egyik legfontosabb technológiai kihatása reményeink szerint a virtualizáció erőteljesebb terjedése lesz (a termék ára is ezért van 30 dollár körül). A technológiai részletek itt és most nem számítanak.
A virtualizáció előbb vagy utóbb meg kell hogy változtassa az üzemeltetői szemléletet. A "hány szerveretek van?" kérdést fel kell hogy váltsa a "mennyi erőforrásotok van?" kérdés. És a válasz természetszerűen összetettebb lesz, hiszen egy egyszerű szám helyett processzor ciklusokat, esetleg gigahertzeket, teraflop-okat mondunk majd, és terabájtos tárkapacitásokat mind diszken, mind memóriában.
Amikor pedig figyelembe vesszük, hogy a Windows Server 2008 immár szolgáltatás modellekben "gondolkodik" és ennek megfelelően épül fel egy-egy kiszolgáló saját szolgáltatás portfóliója, akkor még esetleg zavarba is jövünk. Pedig megint csak "erre kanyarodik az út". Ez a szemléletmód egyre több helyen, egyre több termékben fog megjelenni. (Ahogy már látszik is sok helyen: Exchange és ISA Best Practice Analyzer, SC Configuration Manager - elvárt konfiguráció, SC Operations Manager - egészség modell). Nem szerverekre tervezünk ezentúl, hanem erőforrás blokkokra vagy virtuális kiszolgálókra, a szolgáltatások pedig az általunk megadott szabályok szerint "élik az életüket". Ez a DSI víziója, amivel ha eddig nem is, de most már ideje mindenkinek barátkozni.
Amikor pedig a két történet összeér, akkor az üzemeltetői gondolkodásnak is változnia kell. Az erőforrások véglegesen elszakadnak a fizikai hardvertől. A hideg vas nem lesz más, mint a rendelkezésre álló erőforrások (számítási és tárolási kapacitás, hálózati kapcsolatok stb.) egy fizikai szeletkéje, ami éppen otthont ad bizonyos szolgáltatásoknak: pillanatnyilag és gyakran változóan. A kapacitással pedig valakinek tudatosan gazdálkodni kell, még pedig takarékosan és mértéktartóan. Mindenre kell hogy jusson elegendő, ami kitűzött (üzleti vagy egyéb) célokhoz nélkülözhetetlen, de a szükséges tartalékokon felül egyetlen bájtot, egyetlen processzor ciklust sem használhatunk feleslegesen. Erre szorít majd bennünket az üzleti világ, ami az élesedő piaci verseny miatt minden fillért és centet számon fog tartani és erre kényszerít bennünket a környezet védelme, amiről nyilvánvalóan nem lehet a jövőben "csak" beszélni, mert a végén egy pálma alatt sülünk meg a saját zsírunkban az Andrássy úton.
A jövő üzemeltetői tehát erőforrás készletekben és szolgáltatásokban kell hogy gondolkodjanak a jövőben. Fel fog értékelődni a modell- és szabályalkotási képesség, ami nélkülözhetetlen lesz a szolgáltatások elvárt viselkedésének meghatározásához és a rendellenes viselkedések okainak feltárásához. Ráadásul az egyes modelleket össze kell tudni hangolni, helyesen be kell tudni állítani köztük az elsőbbségi viszonyokat és az arányokat. Nem lesz elegendő tehát a szakmai tapasztalat és a diagnosztikai készség: módszeres mérnöki tudásra lesz szükség, széles látókörre és rugalmas gondolkodásmódra. A jövő új szoftverei jelentős tudást fognak magukkal hozni. Leírják önmagukat, a számukra legoptimálisabb működési környezetet, a nem rendeltetésszerű működés jelenségeit és elhárításuk módját. Ezek az információk a szolgáltatás- és egészségmodellekben rendelkezésre fognak állni. A sok-sok egyedi modellt azonban össze kell majd fogni egy-egy vállalati szintű szupermodellbe (nem Claudia Schiffer-re gondolok :-)), ami minden helyen egyedileg alakul ki, hiszen egyedi az alkalmazott technológiák köre és összetétele (jobb esetben általános modellekből a leghasonlóbbat igazíthatjuk majd a magunk arculatára). A szupermodell lesz az informatikai szolgáltatások alfája és omegája. Olyan összetett informatikai ökoszisztéma megjelenítési formája, amit legalább néhány embernek át kell látnia, hogy érthető legyen a rendszerek viselkedése és követhetőek a benne zajló folyamatok. És akkor még nem beszéltünk arról, hogy a rendszer folyamatosan változni fog...
A Windows Server 2008 üzenete tehát szerintem nem pusztán technológiai üzenet, hanem egyben valahol mélyen emberi kérdés is: készen állunk-e a önmagunk folyamatos megváltoztatására? Carpe diem vagy γνῶθι σεαυτόν (gnothi seauton)?
- Tervezni csak pontosan szépen...
-
A jól ismert József Attila verssor jutott eszembe a System Center Capacity Planner 2007 bejelentését olvasva, ezért választottam a cikk mottójául (kis módosítással).
Az utóbbi másfél-két év során sokat írtunk, beszéltünk a Dynamic Systems Initiative-ról (DSI), ami a Microsoft víziója a dinamikus, önfelügyelő és nagyrészt virtualizációra épülő informatikai rendszerekről. Elmondtuk, leírtuk azt is, hogy a megvalósítás útja az egyes rendszerek modelljeinek megalkotása lesz (az XML alapú Service Modeling Language segítségével), ami tartalmazza a rendszer függőségeit, teljesítmény elvárásait, egészség kritériumait.
A System Center termékcsalád egyes tagjaiban (Operations Manager, Configuration Manager), az Exchange Server 2007-ben, az ISA Server 2006-ban (Best Practices Analyzer) és magában a Windows Server 2008-ban (Server Manager) máris láthatjuk a modelleket működés közben.
A Capacity Planner 2007-tel pedig kapunk egy olyan modellező eszközt, amivel a valós üzemeltetési tapasztalatokból felépített kapacitás modellek segítségével aprólékosan megtervezhetjük rendszereinket, különös tekintettel az erőforrások méretezésére.
Az SCCP segíthet abban, hogy költséges és időrabló tesztelés nélkül készíthessünk jól skálázható modellt a tervezett rendszerről, gyorsan készíthessünk alternatív javaslatokat és megismerhessük az egyes komponensek módosításának hatását a rendszer egészére. Nem is beszélve arról, hogy konkrét adatokkal tudjuk alátámasztani az eszközigényeket, illetve adatokkal jelezhetjük mivel jár, ha egyes komponenseket kisebb teljesítményűvel helyettesítünk.
A System Center Capacity Planner 2007 alapkiépítésben az Exchange 2007 kapacitás modelljét tartalmazza, hamarosan (2. negyedév) elérhető lesz az Operations Manager végleges kapacitás modellje és a Sharepoint 2007 modellje is, majd folyamatosan érkeznek a további modellek is. A termék ingyenes, letölthető az alábbi linkről:
http://www.microsoft.com/downloads/details.aspx?FamilyId=E754F35D-59DB-4BC4-8386-E83E66A16FAD&displaylang=en
- A házi datacenter -2.
-
Kicsit lemaradtam a házi datacenter történettel, mentségemre szóljon, hogy meglehetősen sűrű volt az elmúlt néhány hét, és a következők sem tűnnek lazábbnak.
Valahol ott hagytam abba, hogy egy időre leragadtam a router-be dugott USB diszkes NAS-nál. Aztán jött egy lehetőség, és egy már reménytelennek ítélt kifizetetlen munkáért cserébe válogathattam némi hardvert magamnak. Sikerült is öszelapátolnom egy elég csinos kupacot, ami most valahogy így néz ki:
Az egész rendszer lelke egy Intel DQ965GF alaplap, ami elég jó választás volt, ha a szükséges kompromisszumokat is meggondolom. Egyrészt nem akartam nagy házat a gép köré, ki is néztem az A-Cube 1606 nevű dobozt (tágas, mégis kicsi, könnyen vihető). Másrész a ház mérete miatt csak mikroATX-es alaplap jöhetett szóba. Plusz figyelni kellett arra, hogy legyen meg az a két fontos tulajdonság, ami a Hyper-V futattásához kell: a Hardware assisted virtualization és a Data Execution Prevention. Cserébe feladtam a több fizikai processzor lehetőségét, de legagalább a Quad-okat támogatja a lap.
Került még a dobozba egy Intel 6420-as processzor (ennyi fért a keretbe, de majd kinövi magát előbb-utóbb egy Q6700-ra), aztán 8 GB RAM, és 3 SATA2 diszk (+ még kettő külső: egy USB-s és egy FireWire - ezeken laknak az ISO file-ok és részben a Home Server-em). Hogy az 5.25"-ös hely se maradjon kihasználatlanul, oda került egy ASUS DVD-író.
A diszkek története kicsit hosszadalmasabb. Lepenye Tamás kollégámmal beszélgettük egyszer arról, hogy talán a diszkek sebessége most a legszűkebb keresztmetszet a virtuális rendszerekben, főleg olyan kis demóra szánt esetekben, mint amiket mi használunk. Végül abban maradtunk, hogy a legjobb megoldás az, ha külön diszken van az operációs rendszer, a virtuális diszkek és mondjuk a pagefile (arra az esetre, ha kifutnánk a fizikai memóriából és a gépünknek hirtelen szüksége lenne többletre). Ez nagyjából meg is valósul nálam, igaz a pagefile mellé én még csempésztem némi statikus tartalmat (a DVD-be égetésre váró cuccokat).
A motyó szépen összeállt, és most valahogy így néz ki (ez persze nem a saját gépem, mert az egy sötét gardrób mélyén teszi a dolgát, ahol szinte lehetetlen lefotózni).
Szoftverileg természetesen Windows Server 2008 RC1 (build 17119) fut rajta Hyper-V szerepkörrel és változó számú virtuális masinériával. Most éppen 137 óra az uptime-ja (a múlt héten kellett egy demóhoz és fájó szívvel le kellett lőnöm, akkor 396 óra volt benne...).
A reklám után, amikor visszatérek, akkor elmesélem hogyan lett Home Server-em.
- A parancssor ereje legyen velünk
-
Azzal biztosan nem mondok újat, hogy a Hyper-V szerepkör a Server Core-ra is telepíthető. Sőt! Éppen ez a preferált konfiguráció, mert ez foglalja a legkevesebbet az egyébként nagyon értékes erőforrásokból, mint a fizikai memória és a diszk. Amikor pedig végképp kibújik belőlünk a maximalista IT-s, akkor a Server Core-okat failover cluster-be rendezzük, és ezeken tenyésztjük tovább a virtuális gépeket.
De hogy a csodában kell ezt az egészet beizzítani?
Valahogy így:
1. Telepítsd fel a Windows Server 2008-at a Core opcióval.
2. Állíts be egy erős rendszergazda jelszót ezzel a paranccsal, aztán reboot:
net user administrator <valami nagyon erős jelszó>
shutdown /r /t 0
3. Nevezd át gépet (ami azért is jó, mert 3 perc múlva úgysem emlékeznél az alapértelmezett nevére)
netdom renamecomputer %computername% /newname:<egy konvenció szerinti gépnév>
shutdown /r /t 0
4. Tedd a gépet domain-ba, mert úgy sokkal egyszerűbb lesz felügyelni (ha ezt nem akarod, akkor legalább tartósan csatold fel a felügyeletre szánt gépről a c$ megosztást a megfelelő jelszóval)
netdom join %computername% /domain:<a domain neve> /userd:<egy megfelelő jogú account> /passwordd:*
amikor kérdezi, írd be jelszót
shutdown /r /t 0
5. Jelentkezz be helyi rendszergazdai joggal és add hozzá a megfelelő tartományi csoportot vagy felhasználót a helyi Administrators csoporthoz
net localgroup administrators /add <domain account vagy csoport neve>
logoff
6. Jelentkezz be tartományi fiókkal és telepítsd a Hyper-V szerepkört
start /w ocsetup Microsoft-Hyper-V
a rendszer hamarosan újraindítást kér, tegyél a kedvére.
7. Egy másik gépen tedd fel a Hyper-V Management tulajdonságot (a Remote Management csoportban lesz) és csatlakozz a Core géphez.
8. Állítsd be a Hyper-V beállításokat (alapértelmezett folderek stb.) és a hálózatot és már indulhatnak is a virtuális gépek.
Ha valamilyen misztikus okból nem sikerülne a csatlakozás a Hyper-V MMC-vel, akkor
netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
Hamarosan következik: Server Core, mint failover cluster tag
- Ahol a jövő már elkezdődött...
-
Alig két hónapja indítottuk útnak a Microsoftnál az IT Pro Momentum programot, amelynek a legfontosabb célja az új technológiák széles körű megismertetése az informatikus közösséggel és máris megérkeztek az első visszajelzések a legbátrabb kollégáktól.
Az elsők között jelentkezett a programba Varga Árpád és a Cason Zrt. fejlesztői csapata. Munkájukhoz kapcsolódóan két projektet indítottak párhuzamosan: virtualizáció és SQL Server 2008 témában.
Árpád a következőképpen foglalta össze a projektek lényegét és a tapasztalatokat:
"Az egyik projekt fő célja a fejlesztési környezetünk megváltoztatása. Keressük a módot, amely a leghatékonyabb lehetne számunkra. A fő probléma jelenleg az, hogy rendszerfejlesztőkként mindig valamilyen specializált hardver/szoftver térbe kell alkalmazásainkat illeszteni, ezért gyakran okoz fejtörést a szinte végleges formájában lévő alkalmazás „élesítése”. Erre láttuk alternatívaként a virtualizációt. Igyekszünk a célkörnyezetnek a lehető legjobban megfelelő fejlesztői platformokat létrehozni, hogy a felmerülő problémákat a lehető legnagyobb mértékben már itt, „az asztalon” kiszűrhessük. A 2008-as virtualizáció számos jól ismert előnye sokat segít ebben."
"A másik projekt összefügg egy romániai fejlesztéssel, amelynek célja személyi nyomkövetés. Itt egyes embereknél elhelyezett GPS/GPRS alapú nyomkövetők információit kell feldolgozni, és térképen megjeleníteni. Mivel a közkézen forgó térképmotorok romániai lefedettsége az adott térségben nem éri el az utcaszintet, így kénytelenek vagyunk ezt a hézagot egyelőre saját fejlesztéssel kitölteni. Ebben nyújt segítséget az SQL 2008-ban megtalálható SPATIAL támogatás, ami eddigi tapasztalataink szerint igen jól használható geocoding motorok mögött."
"Mint minden korai bevezetést és alkalmazást megcélzó projektben, itt is nap, mint nap szembesülünk technológiai problémákkal, illetve azzal, hogy bizonyos funkciók még nagyon korai (a bétát is megelőző) fázisban vannak. Ilyen esetekben jön jól a TechNet-ben összegyűjtött nagy tudásbázis és az, hogy gondjainkat közvetlenül továbbíthatjuk a fejlesztők felé a béta támogatási csatornákon keresztül. Összességében viszont kedvezőek a tapasztalatok, mind teljesítmény, mind megbízhatóság és biztonság tekintetében."
Néhány mondat a Cason Zrt-ről
A Cason Mérnöki Zrt. 1992 óta van jelen a magyar és nemzetközi piacokon termékeivel és szolgáltatásaival. Portfóliójuk legfontosabb elemei az ipari kommunikációs berendezések, az integrált ipari rendszerek, valamint a személy- és flottakövetésre kifejlesztett GPS/GPRS alapú megoldásuk.
Legfontosabb ügyfeleik az energiaiparból, logisztikai-, szállítmányozó cégekből és a gyógyszergyárak közül kerülnek ki, de legújabb termékük kapcsán biztonsági és távközlési kapcsolatrendszerük is bővül.
A cég fejlesztési központja Magyarországon, Érden található, de jelen vannak Franciaországban, Spanyolországban, Romániában, Japánban, Taiwanon, Szingapúrban és Thaiföldön is. A vállalatnál 114-en dolgoznak. Amellett hogy többször innovációs díjjal is kitüntették, 2006-ban a Cason Zrt. felkerült Európa 500 leggyorsabban fejlődő vállalatának listájára is.
- Út a házi datacenter-ig - 1.
-
Ez a történet valamikor réges-régen kezdődött, mint általában a mesék. És az is lehet, hogy többen átélték ugyanezt a történetet és most deja vue érzésük van. Szóval néhány éve már fel-felébred bennem egy olyan érzés, hogy valami hiányzik a házi informatikai környezetből. Valami, ami folyamatos szolgáltatást nyújt, amit nem kell külön bekapcsolni, csak rákattanni és lehet zenét hallgatni (sőt akár csapkodni ide-oda és percenként másikat hallgatni), filmet nézni, meg ahol biztonságban vannak a digitális fotók, sőt akár a világ végéről is elérhetők. Tehát igazából egy szerver hiányzott.
Felmerült több lehetőség és ötlet a vágy beteljesítésére, de aztán valamilyen apróságon mindegyik megbukott. Csak három a legtovább életben maradt ötletből.
- NAS. Valami kis dobozka, benne diszkekkel, rádugva a hálózatra és hurrá. Sokáig élt az ötlet, több alkalmasnak látszó vasat is megnéztem (sajnos nincs olyan kapcsolatrendszerem, hogy ki is próbálhassam őket). Végül azon bukott meg a dolog, hogy a NAS eszköz önmagában általában buta és pl. az Internet felé nehézkesen publikálható (bár azóta találtam olyat, amiben beépített FTP van), és akkor még nem megbízható és biztonságos. Ráadásul elég drága, főleg ha az ember nem akarja egyetlen diszk megbízhatóságára építeni kincsei megőrzését.
- Okos router. Köztes megoldásként merült fel, és mivel más jó tulajdonságai miatt amúgy is ilyen tudású routert vettem egy ideig üzemelt is ez a megoldás. Az az ASUS WL500g Premium, amit végül kiválasztottam -a szokásos router funkciókon kívül- remek FTP és média szerver is. Bármilyen USB diszket rá lehet dugdosni és az ott tárolt mindenfélét házon belül és kívül lehet szétszórni. Ráadásul olyan funkciókra is alkalmas (pl. t.rr.nt file rádob, ő azt szépen letölt, diszkre letesz, 24 óráig seed és közben nincs gép bekapcsolva), amiknek a részletezésébe most inkább nem mennék bele :-). Min bukott meg? Megint csak az egy szál diszken (nem tud két diszket kezelni) és a diszk fájlrendszerén. Ha valakinek mond valamit az EXT2 :-). Szóval komoly gondjai voltak a hosszú és ékezetes fájlnevekkel, ami valószínűleg a router beágyazott 20-22 MB-os oprendszere miatt lehetett (és csak súlyos hekkeléssel lehetett volna okosítani, amihez viszont nem vagyok kellően képzett és fanatikus).
- Aztán jöttek az első hírek a Windows Home Server-ről. Windows-os tudás adott, az ára nem lehet valami rettenet, gyerünk, próbáljuk ki. Jelentkeztem a béta programba, letöltöttem a telepítőt és ott tartottam, hogy jó, de mire tegyem. Van ugyan egy ezer éves PC a sarokban (P2-Celeron, 550 MHz :-)), de abban csak 256 MB RAM van és nem is bővíthető - a Home Server-nek pedig ez kevés. Uccu, Virtual PC, nézzük mit tud a dolog. Hihihi, ez nagy-nagy százalékban Small Business Server! De azért érdekes. Azután jött a hír, hogy csak OEM csatornán keresztül lehet majd kapni - vagyis géppel, előtelepítve. Brühühü. Nem szeretem, amikor eldöntik, hogy milyen gép lesz jó nekem, persze jó drágán. Ötlet keserű szájízzel bekukázva.
Itt aztán el is aludt a dolog néhány hónapra, maradt az ASUS router a külső diszkkel és az EXT2 szívásaival. Aztán jött egy lehetőség és Szilasligeten (mennyivel kellemesebb leírni így, mint hogy Kerepes!) épülni kezdett a saját házi datacenter-em. Más és több lesz, mint az eredeti elgondolás, de azt is tudni fogja, amit eredetileg szerettem volna. És most jön a reklám :-). Ne menjenek sehová, mert hamarosan visszatérünk és folytatjuk azzal, hogy mi van a fekete dobozban.
- Izoláció és integráció - Hyper-V mélyrepülés
-
A napokban írtam egy kisebb cikket a Hyper-V körül használatos fogalmakról és két nap múlva -újraolvasva a cikket- egy csomó további kérdés merült fel, ami megért egy kis utánjárást. A kis házi nyomozómunka eredményét tartalmazza ez az írás.
Nézzük először a kérdéseket, amik felmerültek. (Na, nem tudományosan és didaktikusan felépített sorrendben, hanem ahogy felmerültek...)
- Mekkora is ez az igen vékonyka hypervisor, és pontosan hogyan is kapcsolódik a többi komponenshez?
- Szépen hangzik ez a partíció meghatározás, de valahogy nem elég leíró. Mit is jelent a partíció?
- Milyen komponensek játszanak még a virtualizációban?
- Mitől lesz a Hyper-V sokkal nagyobb durranás, mint volt (/lesz valaha) a Virtual Server 2005?
Kezdjük a legfontosabbal: a hypervisor nem csodafegyver. Valóban kulcsfontosságú komponense a Hyper-V megoldásnak, de korántsem kizárólagos fontosságú. Legalább további két-három hasonlóan fontos elemből áll össze a teljes rendszer, aminek a működését tényleg nem tudom jobb kifejezéssel jellemezni, mint az izoláció és integráció páros. Kik is a további szereplők?
Az első fontos elem kétségkívül a hypervisor, amelyik az elkülönített erőforrásokat biztosítja a virtuális gépek számára. Amikor magunk elé képzeljük ezt az alkotóelemet, ne valami szokásos, gigantikus méretű Microsoft-os varázslatra gondoljunk. A hypervisor attól remek, hogy kicsi. A pontos méretét homály fedi, annyit sikerült megtudni róla, hogy kevesebb, mint 50 kilobájt!! (Csak összehasonlításként: a notebook-om touchpad drivere 500 kB körül van.) A hypervisor nagyjából az átlagos eszközvezérlő méretű: AMD platformon 519KB, Intelen 536 KB. (Köszönet Lepenye Tamás kollégámnak a pontos adatokért.)
Tehát egy zsilettpenge vékonyságú szoftverről van szó, ami képletesen darabokra szabdalja a hardverünket, annak megfelelően, hogy mekkora partíciókat határoztunk meg. És akkor máris itt vagyunk ismét a partíciónál (és annak létrehozásánál, de erről kicsit később). A partíció egy virtuálisan definiált hardver. Adott méretű memória, adott mennyiségű processzor időszelet és virtuális eszközök összessége. Ugye nem nagyon lepődünk meg azon, hogy maga a definíció egy XML állomány? Ezt olvassa/írja szükség szerint a Virtual Machine Management (VMM) szolgáltatás (aminek a front end-je az az MMC, amiből az egész rendszert felügyeljük). A hypervisor a tényleges fizikai hardvert egyfajta erőforrás készletként látja (resource pool), látja mennyi erőforrás szükséges a gazdakörnyezet futtatásához és a maradékot pedig felkínálja a virtuális gépek számára. A VMM egy-egy virtuális gép indításakor beolvassa a hardver definíciót és létrehozza a partíciót a hypervisor-on keresztül, ami az így lefoglalt erőforrásokat kiveszi a szabad erőforrások közül és a virtuális gépnek adja át. A virtuális gép a neki átadott hardver szeletet közvetlenül látja, semmilyen közvetítő szoftvert nem kell igénybe vennie, hogy azokat elérje. (A virtuális operációs rendszer kernele ténylegesen ring 0-án fut, nem pedig valami emulált és szoftveresen átkódolandó szinten).
Persze ehhez, az kell, hogy a hardverünk támogassa a virtualizációt egy speciális -1. szinttel, a hypervisor móddal (az Intel a Vanderpool processzoroktól kezdve, az AMD a Pacifica processzoroktól kezdve adja ezt a funkciót.) (Erről némi olvasnivaló: Rings, Lord of the Ring0)
Feléled tehát lassan a virtuális hardverünk, de még nem üzemképes: nincs meg a koordináció a hardver elemek között, és a virtuális gépnek nincs kapcsolata a gazdagéppel, tehát még felügyelni sem lehet. Itt jön a képbe az ún. Worker process, ami minden virtuális géphez létrejön a gazda operációs rendszeren. Ez a processz kapcsolja össze a virtuális hardver elemeit, mintha egy virtuális alaplapba rakosgatnánk az alkatrészeket. Ezen felül kapcsolatot épít fel a gazda gép és a virtuális gép között, biztosítva hogy a gazdagépről irányítani tudjuk a virtuális gép működését. Megint csak nem érhet bennünket nagy meglepetésként, hogy az irányítás WMI parancsokon keresztül történik. A megjelenítés maga pedig- csodák-csodája- RDP.
A Worker process tartja a kapcsolatot minden szereplővel: figyeli a hardver konfiguráció (tehát a partíció definíció) változását, így ha menetközben átkonfiguráljuk azt, akkor azokat igyekszik érvényre juttatni a hypervisor-on keresztül (így adhatunk például röptében memóriát, további processzort, diszket, hálózati kártyát a virtuális géphez). A "felvilágosult" (enlightened), -tehát hypervisor-t ismerő- virtuális gépek esetén a VMBus-on keresztül hozzáférést biztosít a szintetikus hardver elemekhez - például egy virtuális switch-hez, amivel VLAN-okkal elkülöníthetjük akár az azonos gépen futó virtuális gépeinket is, miközben a hálózat bizonyos szegmensei felé kommunikálhatnak. A gazda gép és a kliensek közötti kommunikációs alagút a VSP-VSC páros (Virtualization Service Provider - Virtualization Service Client), mintegy klasszikus kliens-szerver megoldás esetén.
Szintén a Worker process nyújtja a virtuális eszközöket a virtuális gép számára (az emulált eszközöket is) és koordinálja a fizikai hardver eszközökhöz való hozzáférést a hypervisor-on keresztül (hiszen lehet, hogy több virtuális gép szeretne kommunikálni egy-egy fizikai hardverrel és ekkor ütemezésre van szükség).
Összefoglalva tehát, a Virtual Machine Management tartja a kapcsolatot az összes Worker process-el, lekérdezve a virtuális gépek állapotát, terhelését, egyeztetve konfigurációjukat az ismert partíció definícióval. A Worker process egy virtuális alaplapba fogja össze a hypervisor által átadott memóriát és processzoridőt (akár több processzorét is), valamint a virtuális eszközöket (devices). Az integrációs komponenseken keresztül tartja a kapcsolatot a szintetikus eszközökkel (VMBus) és a többi virtuális géppel (VSP-VSC), valamint feldolgozza a gazdagépről érkező felügyeleti utasításokat (WMI) és leképezi az RDP kapcsolatokat (ezért láthatjuk már a boot-olási folyamatot is RDP-n keresztül, eltérően a fizikai gépektől). A hypervisor számon tartja a hardver erőforrásokat, a partíció definíciók szerint súlyozza az erőforrásokat, miközben gondoskodik elkülönítésükről, illetve ellenőrzi a hozzáférési jogosultságokat.
És mitől lesz más és jobb? Elsősorban a hypervisor tudásától és a hardveresen támogatott virtualizációtól. A Virtual PC és Server az x86 architektúra korlátai miatt sok kényszerű kompromisszumot tartalmaz. A virtuális operációs rendszerek egy köztes futási szinten (Ring1) kénytelenek futni, amit aztán a VMM emulál a hardver felé (ez a paravirtualizáció). Az ár viszont meglehetősen magas, a virtuális gépek teljesítménye lényegesen rosszabb, mint azt az adott hardver indokolná. A processzorokba épített Ring-1 szintű hypervisor-ok, kiegészítve a szoftveres (és a Microsoft esetében mikrokernel-es) hypervisor-ral képesek túllépni ezeken a korlátokon és a hardver valós képességeihez jobban közelítő teljesítményt biztosítani virtuális környezetben is. (Erről kicsit bővebben: Hardware assisted virtualization)
- Kis fogalom magyarázat a Hyper-V-hez
-
A virtualizáció kapcsán sokan, sokféle szakkifejezést használnak, röpködnek a szakszavak, a bonyolult, nem is mindig pontos magyarázatok, amitől egyszerű földi halandó számára az egész történet valami misztikus varázslattá válhat.
Pedig szó sincs varázslatról. Mert ez csak színtiszta technológia.
Kis tájékozódási segítségként nézzük a legfontosabb szakkifejezések egyszerű magyarázatát:
Hypervisor: A hypervisor egy vékonyka szoftverréteg, ami közvetlenül a hardware és a rajta futó operációs rendszerek között üldögél. A feladata, hogy elkülönített futtatási környezeteket biztosítson az összes operációs rendszer számára. (Ezek a partíciók.) Minden partíció csak a saját hardware erőforrásaival rendelkezik (memória, eszközök és a CPU adott időszeletei). A hypervisor ellenőrzi és koordinálja a partíciók hozzáférését a tényleges hardware-hez.
Partíció (Partition): ez a hypervisor által biztosított elkülönítés alapegysége; egy fizikai címtartományból és egy vagy több virtuális processzorból épül fel. Ráadásul a partícióhoz meghatározott hardware erőforrások rendelhetők és az erőforrások eléréséhez szükséges jogosultságok is.
Szülő partíció (Parent partition): az a partíció, amelyben dolgozva a gyerekpartíciókat létrehozzuk és felügyeljük.
Gyerek partíció (Child partition): a szülőből létrehozott bármely további partíció.
Vendég operációs rendszer (Guest): a partícióban futó operációs rendszer szoftver. A vendég rendszer lehet teljes kiépítettségű (pl. bármely Windows rendszer), vagy akár egy speciális célú kernel. A hypervisor közömbös a vendég rendszer iránt, csak az erőforrásokat adja számára.
Eszköz emuláció (Device emulation): olyan eszköz virtualizációs megoldás, ahol a virtualizált hardware nem különböztethető meg a tényleges fizikai hardware-től (1:1-es megfelelés).
Szintetikus eszközök (Synthetic devices): olyan virtuális eszközök, amelyeknek nincs közvetlen fizikai megfelelőjük. Az ilyen eszközök a VMBus segítségével kommunikálhatnak akár más partícióban lévő fizikai eszközökkel is.
