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.
Friss tartalom! Nem hiszem, hogy talál ennél átfogóbb leírást a weben a Hibrid felhőről:
Hibrid felhő: teljes útmutató döntéshozóknak
(Vigyázat, hosszú! Mert tényleg teljes útmutató.)
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!
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:
- Az én cégem máris készen áll a virtualizáció alkalmazására
- Nincs szükség különösebb szakértelemre az implementációhoz
- Nincs szükség részletes tervezésre, minden megoldható néhány kattintással
- 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 licencelé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 licenckö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.)
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.
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 hardverkö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 2x80 GB és 4x250 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. Licencekkel máris rendben vagyunk, hiszen a Small Business Server 2003 licencü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.
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.
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ó.
A 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.
Forrás: Somogyi Csaba, Microsoft Magyarország
