Mire való a virtualizáció

Következzék itt most egy tudománytalan, de hosszabb fejtegetés, hogy mire is jó a virtualizáció, és milyen jelentősége van az IT rendszerekben.

A virtualizáció – felfogásom szerint – egyfajta speciális izoláció, amelynek lényege, hogy az információs architektúrák elemeinek kapcsolata laza legyen, így az elemek cseréje, mozgatása, helyettesítése, elválasztása könnyedén megvalósulhasson, ezáltal az egész rendszer rugalmassága növekedjék. Mivel ez a mondat látszólag a semmitmondási bajnokságban is indulhatna, vegyünk – egyelőre még nem a témánkhoz szorosan tartozó – virtualizációs példát, ez pedig a RAID.

A RAID tömbökkel mindenki találkozott már, a mi szempontunkból bármely típusa megfelelő, lássunk hát egy 4 lemezes RAID 5 tömböt. Hol van itt a virtualizáció? A RAID tömbökön, miután megalkottuk őket, úgynevezett logikai lemezeket lehet létrehozni. Ezek nem igazi, fizikailag is megfogható merevlemezek, hanem virtuálisak, ám a megfelelő meghajtóknak köszönhetően az operációs rendszer úgy hiszi, hogy egyszerű, szimpla merevlemezzel van dolga. Az előnyök egyértelműek. A valóságos lemez meghibásodása az operációs rendszer valóságos kötetének kiesését jelentené. A virtuális lemez meghibásodása azonban gyakorlatilag a végtelenbe tolódott (persze nem pontosan oda), tehát elvált két réteg egymástól. A lemezek egy bizonyos rétegben önálló életet élhetnek, amiről a felette működő operációs rendszer mit sem tud. A RAID elemeit úgy kicserélhetjük egyesével, hogy közben a logikai lemez sértetlen. Ha egymás után mind a négy lemezet nagyobbra cseréljük, akkor tökéletesen modelleztük milyen erő rejlik virtualizációban. Hiszen az új tömb egyetlen eleme sem a régi (elméletileg!), mégis minden működik, mintha mi sem történt volna. A RAID tömb – mint virtualizációs technológia – függetleníti a tárolórendszert az operációs rendszertől. A konkrét példa persze ennél kicsit összetettebb, de a lényeg, és a virtualizáció, mint technológia – előnye kidomborodik.

Olyannyira, hogy rögtön bárki által felidézhető, hány helyen alkalmaznak ma már „közönséges” rendszerek „közönséges” virtualizációt. A Windowsnak van virtuális memóriája, és virtuális DOS gépe. A fürtözés is virtuális szerverekkel, erőforráscsoportokkal operál. A DFS egy virtuális mappahierarchiát hoz létre, de már a DNS nevek mögött is meghúzódik valamiféle virtualizáció, hiszen a nevek virtualizálják az IP címeket. A neveket meg virtualizálják a CNAME rekordok stb. stb. Vegyük észre, hogy itt mindig egy valamilyen értelemben vett réteg elválasztása történik egy másik rétegtől.

Az utóbbi két-három évben a teljes rendszerek virtualizációja „jött divatba”, vagyis inkább terjedt el. Érdemes elgondolkodni, hogy milyen elméleti (vagy gyakorlati) előnyöket nyújt az ilyen virtualizáció vagyis MIÉRT virtualizálnak azok, akik ezt teszik, továbbá HOGYAN teszik, melyek a technológia sikerei és jelenlegi korlátai. (Előre felhívom mindenki figyelmét, hogy a cikk nem kíván kimerítő alaposságú lenni.)

Mindenki tapasztalta már, hogy egy kiszolgáló – általában – messze kihasználatlanul hagyja a rábízott erőforrásokat. Lehet, hogy a memóriájára teljes mértékben szüksége van, de a processzor jobbára malmozik, a hálókártya üresen ketyeg, a rendszerbusz békésen szuszog és a merevlemezének kisebb vagy nagyobb része is kihasználatlan. Biztonsági, kompatibilitási vagy egyéb megfontolások miatt azonban nem kerülnek újabb funkciók az operációs rendszerre.

Ez, így, lényegében pazarlás. De a pazarlás nem csak ennyiből áll. Tegyük fel, hogy van hat, kritikus alkalmazásunk, hat szerverrel, abban hat processzorral. Mindegyik túltervezett hardverrel fut, de a megfelelő rendelkezésre állás érdekében mindegyik redundáns táppal, távoli felügyeletet biztosító menedzsment adapterrel, teaming hálózati kártyákkal stb. felszerelt masina. A hat gép energiaellátása sem elhanyagolható.

Mit tehet ebben az esetben a virtualizációs technológia? Az alkalmazások igénylik az önálló operációs rendszert. De az operációs rendszer egyben el is választja őket a konkrét hardvertől. Nosza, csapjuk be az operációs rendszereket is, tegyük őket csupán két fizikai vasra. A kevesebb hardver kevesebb processzort, tápot, hálózati kártyát, menedzsment adaptert és áramfelvételt jelent, így kevesebb hely, olcsóbb szünetmentes megoldás, kevesebb hűtés kell neki. Kis méreteknél ez nem biztos, hogy jelentős, de ahol hatszáz szerver helyett elég kétszáz, ott már akár sokszázmilliós géptermeket lehet felszámolni, vagy a kialakításukat elkerülni. Mit veszítenek az alkalmazások? Semmit. A változást (elméletileg) észre sem veszik. Megfelelő kapacitás és performancia tervezés esetén a válaszidők nem romlanak.

Mit nyerünk mi, üzemeltetők? Pontokba szedve a következőket:

·        Takarékosabb fizikai környezetet (áramellátás, hűtés, hálózati kártya végpontszám csökkenés, SAN FC végpontszám csökkenés, kevesebb menedzsment kártya stb, kevesebb rack szekrény.)

·        Jobban hasznosuló szervereket

·         A tényleges hardvertől elválasztott operációs rendszerek.

 

A legutolsó bajusz új dimenziókat adhat a rendszergazdák számára. Csak néhány példa. Egy „hardver” frissítés nem áll másból ezután (lényegében és elméletileg), mint egy fájl másolása. A virtuális gép merevlemeze ugyanis valójában egyetlen fájl. Ha ezt egy izmosabb gépen indítom el, akkor frissítettem a hardvert anélkül, hogy a tényleges operációs rendszert újra kellene telepítenem.

Telepítés? El lehet felejteni. Érdemes előre image-eket készíteni, szükség esetén pedig a talonból – fájlmásolással – elő lehet húzni. Teljes rendszerpartíciómentés? Nem kell tovább trükközni. A rendszerpartíció valójában egy fájl, az meg „simán” menthető.

A virtualizációs termékek további ötleteket adhatnak a kreatív rendszerüzemeltetéshez. Azt látjuk, hogy egy hotfix nem eltávolítható? A virtuális gép merevlemeze olyan üzemmódba kapcsolható, ahol a változások külön fájlban gyűlnek. Hiba esetén a változások eldobhatók és az operációs rendszert olyan állapotba repítjük vissza, mintha az a hotfix sohasem került volna fel a gépre.

Hosszan lehetne még sorolni az előnyöket, engem lényegében a fenti gondolatok győztek meg arról, hogy úgy gondoljam: virtualizáljak annyi szervert, amennyit csak lehet. Mert, jelenlegi ismereteink szerint, nem mindent lehet. Nézzük a virtualizációs technológiák korlátait:

  • A virtuális gépekben a virtuális processzorok száma korlátozott. Ez a Microsoft szoftvereknél egy, a VmWare esetén 2, illetve ESX-nél hamarosan 4 virtuális processzort jelent maximum. Ha olyan rendszert üzemeltetünk, amely ennél többet igényel, akkor azt „nyers vason” kell megtennünk.
  • A virtuális gépek maximális memóriája 3,6 GB lehet mindkét gyártónál (A hamarosan megjelenő ESX 3 esetén ez 16 GB-ra nő). Ha tehát ennél többet igényel egy alkalmazásunk, akkor a virtualizáció nem járható út.
  • A virtuális hardver kötött elemekből áll. Amennyiben a megadott specifikácitól eltérő hardverelemre is szükségünk van (pl. Faxkártya, 3D grafikus kártya stb.), a vitualizáció nem keresztülvihető.
  • Nincs „virtuális” Fibre channel kártya, így a SAN kapcsolat mindenképpen korlátozott. A korábbi cikkekből olvashattátok, hogy például nem működik a LAN-Free mentés, a virtuális szerver nem kezeli megfelelően a szalagos könyvtárakat.
  • A működő gépek virtuális lemezeinek mentése „kívülről” – jelenleg – legalábbis problémás. Minden gyártó gőzerővel dolgozik a témán, de a jelenlegi helyzet még nem kielégítő.
  • A virtuális környezetben futtatott rendszerek támogatás – különösen a Microsoft szoftverek esetén – korlátozott.

A virtualizáció tehát egyáltalán nem csodaszer, nagyon is konkrét korlátai vannak. Nem lehet mindent virtualizálni. Nálunk péládul működik egy fax szerver – a faxkártyák miatt nem dugható virtuális térbe. Működik egy Tivoli Storage mentési rendszerünk is, a fentiek miatt szintén nem virtualizálható. Van néhány terminál szerverünk is, ott viszont a memória (és persze a megfelelő processzorszám is) akadályozza a virtualizációt. Minden más egyéb iránt „mátrix-ba tehető”. Így például máris azon van a külső és a belső tűzfalunk, a DMZ-nk kiszolgálói, az Exchange fürtünk, tartományvezérlőink egy része, belső intranet szerverünk, spamszűrőnk stb.. És lehetne még sűríteni a dolgokon, pénz kérdése, jórészt.

Még egy fontos dolog, mielőtt valaki virtualizációba fogna. Ez a technológia sok szempontból szemléletváltást igényel. Korábban úgy tartottam, hogy magyar viszonyok között, párszáz felhasználóig a funkciók többségénél nincs értelme teljesítmény-menedzsmentről beszélni. Amikor AD-hangolás előadásokat néztem, a skála kiindulópontja 10 000 felhasználó volt. 500 User? Nevetséges. A közös vasra költözött virtuális gépek esetén viszont a téma igencsak forró lett hirtelen. Ha ugyanis egy gépben egy processz kiakad, akkor könnyen más gépekre is kihat a hiba, így mind a monitorozásnak, mind a proaktív beavatkozásnak fontos szerep jut. De nem csak annak. A szerver vas tervezése is nagyobb odafigyelést igényel. Ha ugyanis az leáll, akkor nem egy, hanem esetleg tíz-tizenöt logikai szerverünk is „elpusztulhat”. A hostok operációs rendszereinek frissítéséről sem szabad megfeledkezni. Ha mégoly ritkán is kerül sor az ilyen eseményre, azt előre tervezni kell, sőt gondoskodni kell szükség esetén az eredeti állapot visszaállításának lehetőségéről is. Vagyis – hogy nem fecséreljem a szót – a virtualizáció nagyobb pontosságot, előrelátást, tervezést, precíz üzemeltetést igényel. Hogy tényleg megérje.

2 Responses to Mire való a virtualizáció

  1. Tako says:

    :( úgy látszik itt nem sikerült egy commentből megoldani azt amit szeretnék :)))
     
    becopyzom ide is mert ide szántam:
     

    "Köszönöm! :)tiszta és világos! eddig eszembe se jutott hogy egy virtuális gép "valódi"  funkciót is elláthat!"
     
    üdv
     
    Tako

  2. Tamas says:

    Mivel többen is tévednek, egyértelmű, hogy a spaces-design okozza a félrekommentezést.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: