Szerző: TechNet

2008. június 23. 09:32

Szerver- konszolidáció: ötletek az első lépésekhez

A TechNet Magazin cikkéből kiderül, hogy mik lehetnek egy szerverkonszolidációs projekt legfontosabb buktatói, és hogyan készülhetünk fel az elkerülésükre. A legfontosabb az idejében megkezdett tervezés, és az sem árt, ha tudunk a gazdasági vezetők fejével gondolkodni.

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!

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 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.

[oldal: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 teljesítménymé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.


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 licencgazdá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 wattra é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áp (W) BTU/h Energiaigény (Wh) Megjegyzés
Szerver 1 600 1915 1161 Belépő szint, álló kivitel
Szerver 2 365 1885 917 Belépő szint, álló kivitel
Szerver 3 630 1794 1156 Belépő szint, álló kivitel
Szerver 4 1170 3990 2339 Középkategória, álló kivitel
Szerver 5 500 1194 850 Belépő szint, rack kivitel
Szerver 6 640 2174 1277 Belépő szint, rack kivitel
Szerver 7 1172 3990 2341 Középkategória, rack kivitel

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 energiafelhaszná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 százalék körüli. Egy negyedik kettes típusú gép konszolidálása pedig már 35 százalék feletti megtakarítást jelenthet.


Webhely a szoftverköltségek számításához

A szoftverkö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 licenceket 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 licencet 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!)

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ő.


Egy képzeletbeli virtualizációs projekt megtérülése

[oldal:É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 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.

Somogyi Csaba
Microsoft Magyarország

Véleménye van?

Kubernetes képzéseinket már közel 300 szakember végezte el. A nagy sikerre való tekintettel a tanfolyamot aktualizált tananyaggal június 18-án újra elindítjuk! A 8 alkalmas, élő képzés képzés órái utólag is visszanézhetők, és munkaidő végén kezdődnek.

a címlapról