A Windows Server Virtualization

Az alábbi cikk a Microsoft TechNet Magazin legújabb számában olvasható, és a szerző szíves engedélyével közöljük.

Egy közel száz kilobájtos kis réteg van készülőben a Microsoftnál: egy mikrokernel, ami képes az erőforrások (memória, processzor, stb.) megosztására több operációs rendszer között. Mindezt a Windows Server 2008 egy szerepköreként kapjuk meg, gyakorlatilag teljesen ingyen. A szervervirtualizáció új generációja ez: a Windows Server Virtualization!

Egy kis történelem

A virtualizáció már közel 30 éve jelen van a mainframe rendszerek esetében, azonban csak néhány éve jelentek meg az első virtualizációs technológiák az x86 platformra. A mainframek esetében az elsődleges cél a szoftverek visszafelé kompatibilitásának megőrzése volt, hogy a virtuális környezetekben akár évtizedekkel korábban elavult megoldások is futhassanak. Később egyre inkább teret nyertek a virtualizáció más irányú felhasználási módjai is, például az erőforrások egy fizikai gépen belül történő elosztása a virtualizált operációs rendszerek között.

Az x86-os platformon is hasonló volt a helyzet -- elsőként a desktop-virtualizációs megoldások jelentek meg, majd rohamosan fejlődni kezdett a szervervirtualizáció is. Majd ahogy egyre többet tudtunk meg a virtualizáció lényegéről, a Terminal Services-alapú megoldások is részben ide kerültek (megjelenítés virtualizáció). Mára már minden virtualizálható: a hálózat, a tárolórendszerek (pl. iSCSI), de akár az alkalmazások is (pl. SoftGrid).

A Microsoft virtualizációs megoldásainak körképe

Nem meglepő ez a tendencia, ahogy egyre nagyobb az igény a rugalmasan változtatható informatikai rendszerek iránt. A virtualizáció talán legfontosabb célja ugyanis az, hogy a rendszerünk összetevőit minél inkább elszigeteljük egymástól, és lehetővé váljon ezeknek az építőkockáknak a tetszés szerinti mozgatása, cseréje, frissítése.

A szervervirtualizáció lehetőségei

Koncentráljunk most egy kicsit a szervervirtualizációra! Pontosan mire is jó ez nekünk? Milyen problémákra ad választ? Ha valaki még nem foglalkozott szervervirtualizációval, érdemes végiggondolnia az alábbi felhasználási lehetőségeket:

• Szerverkonszolidáció: a szerverhardverek a legritkább esetben vannak folyamatosan kiterhelve a lehetőségeik határáig. Minden szolgáltatás máskor és eltérő mennyiségű számítási teljesítményt illetve erőforrásokat igényel. Érdemes ezeket a különféle szolgáltatásokat minél kevesebb fizikai vasra központosítani, és azok skálázhatóságát és rendelkezésre állásást biztosítani.
• A szolgáltatások folyamatos működésének biztosítása: a cél itt igencsak egyszerű: szeretnénk minimalizálni mind a tervezett, mind a be nem tervezett rendszerleállások idejét. Minél kevesebbszer álljon le a rendszer, de ha le is áll, gyorsan helyre tudjuk azt állítani. Virtualizációval mindez könnyen megvalósítható, hiszen mind a fürtözésre, mind a virtuális lemezek és gépek replikációjára és mozgatására is számtalan megoldás áll rendelkezésünkre, amihez egészen kényelmes rendszerfelügyeleti megoldások is elérhetőek már.
• Dinamikus adatközpont: lehetőségünk van arra is, hogy az egy vasra konszolidált operációs rendszerek, illetve szolgáltatások között rugalmasan mozgathassuk az erőforrásokat, például a rendelkezésre álló memóriát, illetve a számítási kapacitást. Ha több szerverünk van, igény szerint másolhatjuk, mozgathatjuk köztük a virtualizált gépekeinket is.
• Fejlesztési és tesztkörnyezet: könnyen építhetünk olyan virtuális tesztkörnyezeteket, amin új szoftverváltozatokat próbálhatunk ki, hogy azok mennyire fognak helyt állni valós rendszerünkben. Ezek a virtuális környezetek nem kell, hogy külön fizikai szerverekre kerüljenek – elférhetnek a már használatban lévő szervereken is, és mivel csak a teszt idejére van rájuk szükség, így erőforrásigényük is csak ideiglenes. A virtualizációnak köszönhetően tökéletesen izolálhatjuk ezeket a tesztrendszereket a valódiaktól (egy hardveren belül is!), de ha pont ennek az ellenkezőjére van szükségünk (például egy migráció tesztelésekor szeretnénk elérni az aktuális rendszert is), az is könnyen megvalósítható.

Sokan persze már csak mosolyogva legyintenek ezen sorokat olvasva, hiszen már ismerik a ma elérhető megoldásokat, és használják is azokat, köztük a Microsoft Virtual Server 2005 R2-őt, vagy például a VmWare megoldásait. Nekik már sokkal gyakorlatiasabb problémáik vannak: a virtualizált rendszerek teljesítménye, az emulált és virtualizált hardverek használhatósága, a biztonság kérdése, a minél alaposabb izoláció és az egyszerű kezelhetőség és menedzselhetőség kerül előtérbe.

Tervezési szempontok

A Windows Server Virtualization tervezésekor a korábbi céllal szemben (a visszafelé kompatibilitás megvalósítása) további, új szempontok is előtérbe kerültek. Az első szempont az volt, hogy a rendszer a lehető legbiztonságosabb legyen. Legyenek a különféle virtualizált rendszerek és a virtualizációt végző infrastruktúra egymástól teljesen elszigetelve, izolálva: ne érhessék el a virtualizált rendszerek egymás adatait, memóriáját; ne tudják egymás elől elvenni a rendelkezésre álló számítási kapacitást, hanem azt az infrastruktúra ossza meg köztük. A biztonság elérése érdekében az is fontos, hogy minél kisebb legyen a virtualizációs réteg kódja. Ez a réteg ugyanis mindenhez hozzáfér, és mindenhez van joga. A lehető legkisebbre kell csökkenteni a méretét, ezzel egyúttal csökkentve a támadási felületet is.

A biztonság után legfontosabb szempontként a megbízhatóság állt, ugyanis a virtualizációs réteg hibája vagy leállása valamennyi azon futó virtuális gép leállásával jár együtt! Elég akár egy egyszerű rendszerújraindításra gondolnunk. Virtualizáció nélkül egyetlen gép leállása csak egy adott szolgáltatás leállását eredményezi. Egy 20 virtuális gépet futtató vas leállása azonban mind a 20 szolgáltatás azonnali leállását eredményezi. Emiatt nagyon fontos, hogy a rendszer minél megbízhatóbb legyen, másrészt legyen képes magas rendelkezésre állásra abban az esetben is, ha valamiért mégis leállás következik be. Többek között ezért is jár annyira kéz a kézben a virtualizáció és a fürtözés.

A monolitikus és a mikrokernel-alapú hypervisor közti különbségek

A fokozottabb megbízhatóság érdekében a Windows Server Virtualization az egyszerűségre törekszik. Ennek legfontosabb eszköze, hogy egyértelműen meghatározott, egymásra épülő rétegekre osztott a felépítése, és az ezek közti kommunikációs kapcsolatok száma alacsony, működésük a lehető legegyszerűbb. A hardverhez legközelebb eső rétegek (amik a legtöbb jogosultsággal rendelkeznek) a lehető legkevesebb feladat elvégzésére képesek. Ezért maga a hypervisor egy nagyon apró mikrokernel képében került megvalósításra (ezzel később részletesen foglalkozunk), ami kizárólag azokat a funkciókat tartalmazza, amikhez tényleg szükség van a legmagasabb jogosultságokra, illetve néhány olyan apró funkciót, ami az optimális teljestmény eléréséhez teljességgel elengedhetetlen. Minden más a hypervisor fölött, a partíciókban fut, amit virtualizációs réteg (virtualization stack) néven fogunk a jövőben emlegetni.

Ez lényeges eltérés például a VmWare ESX szerverhez képest, ami a minél nagyobb teljesítmény érdekében további drivereket és hardveremulációt is a hypervisor szintjére helyezett el -- ez a monolitikus hypervisor megközelítés. Ez azonban növeli a támadási felületet, növeli a leállások kockázatát (gondoljunk csak a hibás driverekre!), és gyakorlatilag teljes ellentétben áll a Microsoft által is képviselt minimalista, mikrokernel alapú hozzáállással szemben -- mindezt néhány százaléknyi teljesítményért cserébe. A nyílt forrású hypervisor, a Xen is a Microsoft álláspontját osztja ebben a kérdésben, emiatt a két megoldás igen sok ponton képes lesz együttműködni -- de erről még szintén lesz szó a későbbiekben.

A harmadik szempont a skálázhatóság volt: elérni, hogy a Windows Server Virtualization gyakorlatilag akármekkora gépen, tetszőleges méretű és számú virtuális gépet is képes legyen optimális teljesítménnyel kezelni.

[oldal:A Windows Server Virtualization működése]

A Windows Server Virtualization a következők meglétét igényli:

• x64-es Windows Server 2008 Standard, Enterprise vagy Datacenter Edition, akár teljes, akár Core változatban a szülő partícióra
• x64-es processzor, Intel Virtualzation vagy AMD Pacifica hardveres virtualizáció támogatással
• Hardveres DEP, azaz Data Execution Prevention (Intel XD/AMD NX)

És amire képes:

• 64 és 32 bites virtuális operációs rendszerek kiszolgálása (vegyesen is akár)
• Akár 8 processzormag hozzárendelése bármely virtuális géphez
• 2 TB memória memóriát oszthatunk szét a virtuális gépek között
• Tetszőleges számú virtuális gép futtatása (csak a hardverünk szab határt, nincsenek kódolt limitek)

Szerver-változat	LHS Standard x64 Edition	LHS Enterprise x64 Edition	LHS Datacenter x64 Edition
A támogatott fizikai processzorok	1-4	1-8	1-64
Támogatott memória	Max. 32 Gbyte	Max. 2 Tbyte	Max. 2 Tbyte
Virtual Machine Live Migration	Nem	Igen	Igen
Cluster-támogatás	Nincs	Van	Van

A Windows Server Virtualization egy teljesen 64 bites, mikrokerneles hypervisor-alapú virtualizációs megoldás. A 64 bit talán egyből érthető is, bár rögtön két dolgot is jelent: egyrészt a virtualizációs réteg a 32 bites rendszerekkel szemben sokkal nagyobb memóriához fér hozzá, másrészt lehetőségünk van futtatni 32 és 64 bites virtuális operációs rendszereket is, akár vegyesen is. No de mi az a hypervisor? Ennek megértéséhez először érdemes visszatekinteni egy kicsit a Virtual Server 2005-re.

Kétféle virtualizációt különböztetünk meg egymástól. A hagyományos virtualizáció (type 2, vagy host-alapú virtualizáció) egy vékony réteget helyez el egy futó operációs rendszer (host) és a virtuális gépek (guest) között. Minden hardverrel kapcsolatos művelet keresztülhalad egyrészt a virtualizációs rétegen, majd magán a host operációs rendszeren is, ami jelentős teljesítménycsökkenést eredményez.

A modernebb, de még szintén erre a megoldásra épülő, úgynevezett hibrid virtualizációs technológiák esetében a virtualizációs réteg az operációs rendszerrel majdnem egy szinten található meg, és a hardverhívások többségét igyekszik minél közvetlenebb úton továbbítani a tényleges hardverekhez az operációs rendszer kihagyásával.

Erre jó példa a Virtual Server 2005 esetében a Virtual Machine Additions csomag, ami amellett, hogy átjárhatóvá teszi a virtuális guest és a host gépeket (egérkurzor integráció, időszinkronizáció, stb), a rendszer teljesítményén is javít azáltal, hogy még bootolás során egy driver segítségével átírja a rendszerhívások tábláját néhány (közel 6) ponton, hogy a leginkább hardverintenzív hívások teljesítménye virtualizált környezetben se lassuljon le számottevően.

A Virtual Server 2005 R2 architektúrája

A Virtual Server 2005 képes több mint ezer különféle operációs rendszer futtatására, méghozzá azok bármiféle módosítása nélkül. Ahhoz, hogy ez működjön, el kell hitetnie a virtualizációt végző rétegnek a virtuális operációs rendszerrel, hogy ő valóban teljes egészében Kernel módban fut (ring 0), holott valójában a host operációs rendszeren Guest Kernel módban (ring 1) fut. Ezt az emulációt nevezzük Ring Compressionnek, amit a Kernel módban futó Virtual Machine Monitor (VMM) végez: ez figyeli a virtuális operációs rendszereket, és biztosítja, hogy azok ne csinálhassanak semmi butaságot (ne férhessenek a virtuális rendszerek hozzá más virtuális gépek, vagy akár a host gép memóriájához, adataihoz). Ez természetesen szintén csökkenti a rendszer teljesítményét, de hardveres virtualizáció-támogatás nélkül más megoldás erre a problémára jelenleg nem létezik.

A hypervisor

Ezzel szemben a hypervisor-alapú megvalósítás (type 1 virtualizáció) esetében a virtualizált gépek és a hardver között semmi más nem áll, mint maga a hypervisor: egy vékony réteg, gyakorlatilag egy mikrokernel, ami közvetlenül a hardveren fut, nincs szüksége host operációs rendszerre a működéshez. A Windows Server Virtualization felépítésére is ez jellemző. A hypervisor felel a virtualizált gépek futtatásáért, illetve azért, hogy számukra teljesen elszigetelt partíciókat alakítson ki az általunk beállított hardvereszközök, memóriaméret, számítási kapacitás, hálózati kártyák és egyéb beállítások alapján.

A Windows Server Virtualization felépítése

A Windows Server Virtualization kihasználja a hardveres virtualizációs megoldásokat, emiatt nincs többé szükség a Ring Compressionre. Miért is kellett a Ring Compression? Azért, mert a virtuálizációs réteg és a virtualizált gépek nem futhatnak egy ringben (biztonsági és izolációs okok miatt -- hogy ne érhessék el egymás adatait közvetlenül), viszont az emulált operációs rendszereknek azt kellett hinniük, hogy ők valójában a 0-s ringben futnak. Mi lenne az ideális megoldás? Ha a virtualizációt végző réteg a -1-es ringben futna. A hardveres virtualizáció pedig pontosan ezt teszi lehetővé, ezáltal nincs szükség többé emulációra, és a teljesítmény sem romlik miatta.

A szülő partíció

A Windows Server Virtualization esetében továbbra is van egy kiemelt jelentőségű virtuális gép, vagy más néven partíció, de ennek a neve ezentúl szülő (parent) partíció, és nem host. Ennek az az oka, hogy megváltozott a szerepe is. A szülő partíció felelős valamennyi hardver és erőforrás kezeléséért, valamint ő végzi el a további partíciók létrehozásával, törlésével és felügyeletével kapcsolatos teendőket. Gyakorlatilag a szülő partíció amellett, hogy egy teljes értékű operációs rendszer, egyben a vékonyka hypervisor réteg kiterjesztése is -- itt található az a virtualizációs réteg, amit korábban már említettünk.

Miért előnyös ez? Egy hatalmas oka van ennek: a driverek! Ugyanis ezzel a megoldással nincs szükség speciális, virtualizációs driverek írására, hanem bármilyen driver, ami felmegy a szülő partícióra, az egyben elérhetővé válik a többi partíció (virtuális gép) számára is!

A szülő és gyerekpartíciók viszonya

A szülő partícióra kizárólag Longhorn Serverre telepíthető (Standard, Enterprise vagy Datacenter), de az akár Core változat is lehet. Ha a teljes Longhorn Servert telepítjük, akkor akár erről a partícióról közvetlenül menedzselhetjük valamennyi virtális gépünket egy MMC-s grafikus felületről, azonban ezzel csökkentjük a teljes rendszer teljesítményét és biztonságát. Ha viszont Longhorn Server Core-t telepítünk, akkor igaz ugyan, hogy a rendszer felügyelete csak távolról valósítható meg, de egy nagyon kicsi, erőforrásokat önmagában nem nagyon igénylő operációs rendszert kapunk, ami sokkal biztonságosabb, és valamennyi Windowsra írt drivert képes futtatni egyben. A Microsoft ajánlása az, hogy a szülő partíció lehetőség szerint Core legyen.

Könnyen észrevehető, hogy csakúgy, mint a host gép esetén, a szülő partíció is SPoF-ként (Single Point of Failure) viselkedik, vagyis ha az leáll, valamennyi virtuális gépünk is leáll egyben. Ennek kivédése érdekében érdemes fürtözni azt egy másik fizikai géppel, amin szintén egy Longhorn Server Core szülő partíció található meg, valamint minden futtatott virtuális gép replikált változata is megtalálható rajta. Ez a megoldás gyakorlatilag analóg a Virtual Server 2005 R2 host clustering megoldásával. Viszont a fürtözés a Standard „Longhorn” Serverben nem található meg, ezért ezt a technikát csak Enterprise vagy Datacenter változatokkal használhatjuk.

A szülő partíció egyébként teljesen ugyanúgy viselkedik, mint bármely más operációs rendszer. Ugyanúgy lehet patchelni is, akár Microsoft Update, WSUS, vagy SMS segítségével.

[oldal:Hardverek megosztása]

A hardvereszközök megosztása, emuláció

A hagyományos eszköz-emulációs megoldás nem éppen gyors, és nem is igazán skálázható nagyobb rendszerek esetén, különösen, ha például 20 virtuális gépünk fut párhuzamosan egy vason. A Windows Server Virtualization új hardvermegosztási architektúrája azonban választ ad erre is.

Mivel eleve esélytelen elvárni bárkitől is, hogy emulációs drivereket fog készíteni régebbi hardverekhez a Windows Server Virtualization-höz, ezért -- mint korábban kifejtettük -- a szülő partícióra telepíthető drivereket használja az összes többi virtuális gép is. Az ehhez szükséges infrastruktúrához tartozik hozzá az alábbi három technológia:

Virtualization Service Provider (VSP): A szülő partícióban fut -- ez kommunikál a tényleges driverekkel, és osztja meg azt a virtuális gépekkel, multiplexerként működve. Például ha van egy fizikai hálókártyánk, amit 10 virtuális gép között szeretnénk megosztani, akkor a szülő partíción található hálózati VSP elérhetővé fogja tenni azt a kártyát azon virtuális gépek számára, amiket beállítottuk, és mindannyian képesek lesznek egyidőben használni azt. A Microsoft virtualizációs csapata már fejleszti azokat az általános hálózati, tárolóeszköz, bemeneti és videó VSP-ket, amikkel tetszőleges eszközt tudunk megosztani egyszerűen driverük telepítésével a szülő partícióra a többi virtuális gép között. A VSP-k telepítése automatikus a szülő partícióra, amint engedélyezzük rajta a virtualizáció szerepkört.

A hardvermegosztási alrendszer architektúrája

Virtualization Service Client (VSC): Ezek a komponensek a gyerekpartíciókon futnak, és szintetikus eszközökként teszik elérhetővé azokat a hardvereket, amiket a szülő partícióra telepítettünk, és megosztottunk az adott gyerekpartícióval. Minden gyerekpartíción megtalálhatóak ezek a VSC komponensek, annak megfelelően, hogy milyen VSP-ket szeretnénk használni rajtuk (párban vannak). A VSC-k telepítése nem automatikus, az Integration Components telepítésével együtt kerülnek fel a virtuális gépünkre.

Szintetikus eszköz alatt azt értjük, hogy egy hálókártya nem úgy jelenik meg, hogy "DEC/Intel Ethernet Card", hanem úgy, hogy "Microsoft Virtual Network Adapter". Ez azon kívül, hogy egy általánosabb név, azt is jelenti, hogy nem valóban létező hardvereszköz képességeit emulálja a VSC-VSP páros, hanem lehetőség van arra, hogy egy fizikai eszköz lehetőségeit messze túlszárnyaljuk ezzel a megoldással, akár új képességeket fejlesszünk ki hozzá. (erre láthatunk egy példát a tárolóeszközöknél).

VMBus: egy olyan memórián keresztül működö nagyteljesítményű sínrendszer, ami a partíciók közötti adatkommunikációért felelős. Ezen keresztül kommunikálnak egymással a VSC-k és a VSP-k, de a hypervisor maga nem érhető el ezen keresztül. A VMBus nem emulált hardverként viselkedik, és nem is jelenik meg a szintetikus eszközök sínrendszereként a hardverek között az eszközkezelőben.

Ezek a megoldások nagyban növelik a virtualizált rendszerek teljesítményét, különösen az IO alrendszerrel kapcsolatos műveletek esetén, és lehetővé teszik olyan eszközök megosztását és virtualizálását is, amikre korábban nem volt mód. Mégis, joggal merülhet fel a kérdés: ezek szerint minden eszközemuláció megszűnt? Nincs rá többé szükség?

A válasz: nem. Továbbra is van szükség hardveremulációra. Mivel egyetlen operációs rendszer sem tartalmazza alapból a VSC komponenseket (még a Longhorn Server sem!), ezért legalább a virtuális gépek telepítésének idejére szükség van hardverek emulálására. Emiatt továbbra is ezernél több marad a támogatott és telepíthető operációs rendszerek száma Windows Server Virtualization alapokon is. Hasonló módon a bootolás korai szakaszában is szükség van az emulált eszközökre, hiszen a VSC-k csak egy kicsivel később kerülnek betöltésre és aktiválásra. Amint a VSC-k betöltődnek, teljesen átveszik az irányítást az emulált eszközöktől.

Mi a helyzet a Linuxokkal?

Mivel rengetegen kérik, hogy a Microsoft virtualizációs megoldásai ugyanolyan jól támogassák a Linux operációs rendszereket, mint a Windowsokat, ezért nem lenne megfelelő megoldás, ha Linux alatt csak emulált eszközök lennének elérhetőek. A XenSource ezért a Microsofttal kötött partneri megállapodása értelmében elkészíti a VSC-k Linuxos változatait a legelterjedtebb Linux disztibúciókra is (egyelőre Novell SuSE és Red Hat), ezáltal Linuxokon is elérhetőek lesznek a nagysebességű szintetikus eszközök a VSP-ken és a VMBuson keresztül.

Xen-alapú Linuxok és a Windows Server Virtualizáció együttműködése

Ráadásul, mivel a XenSource által készített, szintén mikrokernel- és hypervisor-alapú virtualizációs megoldása nagyon hasonló felépítésében és koncepciójában a Microsoft-féle Windows Server Virtualizationhoz, és mindkét cég megoldásai használják a VHD fájlformátumot a virtuális gépek lemezeihez, ezért a a Xen és a Windows Server Virtualization között a virtuális gépek cseréje meglehetősen egyszerűnek ígérkezik.

USB, hang, videó és a BIOS

Érdekes kérdés, hogy vajon mi a helyzet az olyan egzotikumokkal, mint például az USB eszközök, a hangkártyák, vagy a 3D grafikus kártyák. Nézzük őket szépen sorjában!

Egyelőre a virtualizációs csapat nem fejezte be a teljeskörű USB-támogatást, így az a Windows Server Virtualization első változatában nem lesz elérhető. Azonban mivel a virtuális gépeket mostantól RDP-n keresztül lehet elérni (a VMRC a továbbiakban már nem opció), lehetőségünk van akár Smart Card, akár USB-s tárolóeszközök használatára is a hagyományos RDP kapcsolat beállításokon keresztül.

Hasonló a helyzet a hangkártya esetén: bár a szervereken ritkán van szükség hangkártyára, és a Windows Server Virtualization nem is emulál jelenleg hangkártyát a virtuális gépeken, az RDP képes emulálni a hangkártyát a kapcsolat idejére.

Hangkártya és más eszközök emulálása RDP-n keresztül.

A grafikus kártya kérdése sem teljesen egyértelmű. Ugyan nem szokás szervereken 3D grafikát használni, és általában egyszerű, 2D kártyákat találunk a szerverekben, mégis szükségünk lehet például egy Aero felülettel rendelkező Windows Vista virtualizálására és megfelelő megjelenítésére is. Maga a Windows Server Virtualization ugyanazt az S3 Trio kártyát emulálja, mint a Virtual Server, azonban ha egy Aero-képes Windows Vistáról RDP-zünk rá egy virtuális Vistára, akkor fogjuk tudni használni a virtuális gépen is az Aerot, kihasználva a lokális grafikus kártya erejét.

A BIOS összes beállítása elérhető az MMC-ről

Azáltal, hogy a VMRC protokollt nem használjuk a továbbiakban, felmerül még pár apróság: például hogyan érjük el a virtuális gépek BIOS-át? A válasz: sehogy. Nincs többé mód a BIOS hagyományos elérésére, viszont helyette minden beállítás elérhető a Windows Server Virtualization MMC-jén keresztül. Ugyanígy tudjuk beállítani a bootolandó eszközök listáját, sorrendjét is, és bootolhatunk akár lokális lemezről, USB, firewire, SAN és NAS eszközökről is.

Tárolóeszközök és Smart Cardok megosztása RDP-n keresztül

[oldal:Processzor- és memóriakezelés]

A Windows Server Virtualization 1, 2, 4, illetve 8 processzormag hozzárendelését támogatja egy adott virtuális géphez. A virtuális gép nem csak azt látja, hogy hány magot adtunk neki, azzal is pontosan tisztában van, hogy az hány fizikai processzorhoz tartozik. Erre feltétlenül szükség volt, hiszen a licencelési kérdések esetében sokkal kedvezőbben járunk így egyes gyártókkal, például a Microsofttal is, aki továbbra is processzorszám és nem processzormagszám alapján licenceli termékeit.

Egy négymagos virtuális gép Windows Server Virtualization alatt

Érdemes itt megemlíteni, hogy jelenleg egyetlen, halandó ember számára elérhető virtualizációs megoldás sem képes a processzorok fizikai gépek közötti megosztására (spanning), így a Windows Server Virtualization sem. Ennek több oka is van, de a legfontosabb a teljesítmény, hiszen sem hálózat, sem más összeköttetés segítségével nincs jelenleg még megfelelő sebességű megoldás arra, hogy két rendszersín ilyen szinten képes legyen közösen dolgozni.

Memóriakezelés

Azon túl, hogy a Windows Server Virtualization szinte korlátlan mennyiségű memóriát képes használni, megjelent néhány újabb képesség is a rendszer részeként.

Az egyik ilyen újdonság a Page Sharing technológia, amivel a virtuális gépek között lehetővé válik az azonos memórialapok megosztása. Ez azonos operációs rendszerek esetén rendkívül sokat segíthet, hiszen ugyanazt a Kernelt, és nagyjából ugyanazokat a rendszerszolgáltatásokat használják mind. Természetesen a Page Sharing csak a teljesen megegyező memórialapokat osztja meg a gépek között, ha valamelyik gép picit is eltér a többitől, akkor az az eltérés csak a saját memóriatartományában lesz elérhető. A megoldás előnye, hogy kevesebb memóriára lesz szükségünk, ha sok hasonló virtuális gépünk van. Hátránya: minimális teljesítménycsökkenéssel számolhatunk.

A másik újdonság a Memory Reserves funkció. Ennek segítségével lehetőségünk van arra, hogy a virtuális géphez rendelt memória egy adott százalékát ne adjuk oda azonnal a virtuális gépnek, csak akkor, ha tényleg szüksége van rá, és van még szabad fizikai memóriánk. Ha már nincs, akkor a Windows Server Virtualization virtuális memóriát fog létrehozni az adott virtuális gép számára. Természetesen ez a megoldás is teljesítménycsökkenéssel jár, azonban így még több virtuális gépet tudunk egymással párhuzamosan futtatni, különösen, ha limitált a rendelkezésünkre álló memória mérete.

A Memory Reserve beállítási lehetőségei

Ennek a két funkciónak akkor van igazán értelme, ha tesztrendszereket szeretnénk virtuálisan kiépíteni, és nem rendelkezünk korlátlan mennyiségű memóriával. Éles környezetben azonban mindkettő jelentősen ronthat a teljesítményen, ezért ezeket a funkciókat ne használjuk akkor, ha a lehető legjobb teljesítményt szeretnénk elérni. Éppen ezért a két beállítás kéz a kézben jár:

• Ha a legjobb teljesítményt szeretnénk, állítsuk 100%-ra a Memory Reserves opciót. Ekkor a virtuális gép azonnal és fixen megkapja az összes számára szükséges memóriát. Ilyen esetben a Page Sharing is ki van kapcsolva, hiszen a teljesítményre optimalizálunk.
• Ha szeretnénk használni a Page Sharinget is, és inkább több memóriára van szükségünk, akár a teljesítmény kárára is, állítsuk a Memory Reserves opciót 100%-nál kevesebbre. A minimum, amit beállíthatunk 75%. Ilyen esetben a virtuális gép azonnal megkapja a számára beállított memória 75%-át, majd ha azt felhasználta, kaphat még a fennmaradó fizikai memóriából. Rosszabb esetben virtuális memóriát fog kapni, ha már nincs több szabad memória, amihez a virtuális gép hozzáférhetne.

A Windows Server Virtualization virtuális memória kezelése teljesen független az operációs rendszerétől, így akár olyan operációs rendszer is használhatja, ami alapból nem támogat virtuális memóriakezelést. Természetesen olyan esetekben, ahol az operációs rendszer már maga is támogatja a virtuális memória kezelését, ott ez a megoldás jelentősebb teljesítménycsökkenést eredményezhet.

Integration Components és társai

A VM Additions csomagok helyett érkeznek az IC-k (Integration Components), amik a következőket tartalmazzák:

• Virtualization Service Client-ek (VSC) a nagyobb IO sebesség érdekében (szintetikus eszközök)
• Időszinkronizáció
• Szívverés (Heartbeat) funkció
• Integráció a virtualizált géppel a megfelelő rendszerleállítás támogatásához

Ezek mindegyike virtuális gépenként be-, illetve kikapcsolható. Az IC-k már nem tartalmazzák azokat a VM Additionsból ismert rendszerhívás-módosításokat, amik a hardveres virtualizáció-támogatás miatt már amúgy sem szükségesek többé.

Viszont külön érdekesség, hogy a Longhorn Servertől kezdve az operációs rendszerek taralmaznak olyan beépített optimalizációkat, amik miatt virtualizált környezetben képesek a körülményekhez jobban alkalmazkodni. Ezeket gyűjtőnéven Windows Enlightements-nek nevezzük. Erre jó példa, hogy a Longhorn Server memóriakezelője lényegesen másképpen működik virtuális környezetben, mint egyébként. Ezen kívül most már elérhető olyan rendszerhívás is, ami képes megmondani, hogy virtuális vagy valódi gépen futunk-e.

Menet közbeni bővítés

A Windows Server Virtualization alatt futó virtuális gépekhez futás közben allokálhatunk további memóriát, processzormagokat, tárolóeszközöket, illetve hálózati kártyákat is [az első verzióban ez a funkcionalitás még nem lesz elérhető -- a szerk.]. Ehhez azonban ezt a gyerek partíción futó operációs rendszernek is támogatnia kell. A szülő partíció, mivel csak Longhorn Server lehet, nem okozhat problémát, az mindegyik bővítési módszert támogatja. A XenSource megállapodásnak köszönhetően a virtualizált Linuxok is képesek lesznek a menet közbeni bővítés használatára, de ez Kernel verziónként és disztribúciónként változó.

Az eszközök menet közbeni eltávolítására is van lehetőség hálózati csatolók és tárolóeszközök esetében, azonban a processzormagok és memória eltávolítását a Windows Serverek jelenleg nem támogatják -- de ennek megoldására is léteznek kerülőutak.

[oldal:Tárolóeszközök, hálózatkezelés, felügyelet]

A VSP/VSC architektúrának köszönhetően a tárolóeszközökkel kapcsolatban számtalan újdonság érkezik, amik kihasználják a szintetikus eszközök lehetőségeit, és új képességekkel jelentkeznek a korábbi, technológiailag limitált driverekhez képest.

Korábban Virtual PC és Virtual Server alatt az emulált IDE vezérlő legfeljebb 127 gigabájtos merevlemezeket volt képes kezelni. Ez a határ az új szintetikus eszközzel 2 TB, csakúgy mint a SCSI eszközök esetében. Ezen kívül most már ugyanolyan gyors a szintetikus IDE vezérlő is, mint az SCSI vezérlő (az emulált viszont még mindig lassabb -- érdemes telepíteni a VSC-ket mielőbb!)

Akár 256 eszközt is köthetünk a virtuális SCSI vezérlőre

A SCSI-vezérlő is fejlődött, most már vezérlőnként 256 virtuális merevlemezt használhatunk egyszerre, és ezek egyenként 2 TB méretűek is lehetnek. Linux, Windows Server 2003 és Longhorn Server alatt legalább 2 SCSI vezérlőt lehet majd használni (a guest clustering támogatása miatt). Azokon a rendszereken, ahol nem érhető el szintetikus a SCSI vezérlő, ott jelenleg 4 IDE eszközt lehet legfeljebb használni, de az új korlátokkal az is akár 8 TB tárhelyet is jelenthet.

Hálózatkezelés

Ezentúl virtuális gépenként 8 hálózati csatolót lehet majd használni, de ehhez szükség van a megfelelő VSC-k telepítésére, ugyanis ez a határ csak a szintetikus eszközök esetén érhető el. Emulált eszközökkel továbbra is legfeljebb 4 hálózati kártyát használhatunk.

A Virtual Serverben már volt lehetőség arra, hogy virtuális hálózatokat definiáljunk és kössünk hozzá virtuális gépeink hálózati csatolóihoz. Ez a Virtual Server esetében nem volt más, mint egy uplinkkel rendelkező egyszerű hálózati hub. Ez azonban azt is jelenti, hogy az azonos (virtuális) hubra kapcsolódó gépek képesek az egymásnak küldött adatokba belehallgatni, ami nem éppen biztonságos megoldás. A Windows Server Virtualization esetén már nem hub, hanem egy virtuális switch áll rendelkezésünkre, ami már csak azokra a portokra küldi el a csomagokat, ahova tényleg szükséges, és nem mindre, mint egy hub. Ez a switch akár WMI-vel scriptelhető is, mint a rendszer bármely más komponense is.

Szintén újdonság, hogy már lehetőség van VLAN-ok használatára is, mivel mind az emulált, mind a szintetikus hálózati csatolók támogatják a 802.1q (VLAN tagging) technológiát. Hasonló módon a virtualizációs csapat keményen dolgozik azon, hogy további 802.1x technológiák támogatását fejlessze le a hálózati csatolókhoz, de ezek jelentős része csak a következő változatra fog elkészülni.

Érdekesség, hogy virtuális gépek is képesek részt venni egy NAP (Network Access Protection) infrastruktúrában, ám mivel még a 802.1x támogatás nem teljes, ezért csak IPSec alapokon képes kezelni azt. Ez akkor lehet hasznos, amikor egy-két hónap kikapcsolt állapot után csatlakoztatjuk egy virtuális gépekkel teli szerverünket a vállalati hálózathoz, és szeretnénk, ha automatikusan frissülnének ezeken a gépeken a szoftverek, mielőtt ténylegesen be tudnának lépni, és esetlegesen kárt okozhatnának.

Felügyeleti újdonságok, távoli elérés

Történt jónéhány változás a virtuális gépek felügyeletével kapcsolatban is. Első változás, hogy a webes adminisztrációs felület helyett egy MMC fogad minket, ami természetesen távoli gépről is tökéletesen elérhető.

Hasonlóképpen újdonság, hogy a VMRC prorokollt is lecserélték, és helyette minden a RDP-vel, Remote Desktoppal érhető el. Ennek számtalan előnye van a VMRC-vel szemben. Lehetőségünk lesz olyan virtualizált operációs rendszerre is csatlakozni Remote Desktoppal, ami amúgy nem támogatja a Terminal Servicest, és ugyanúgy elérhető lesz egy ActiveX Control az RDP-hez, mint ahogy a VMRC esetében is megszokhattuk.

Akcióban a Windows Server Virtualization

A Windows Server Virtualization valamennyi összetevője WMI segítségével lesz scriptelhető, ha pedig mélyebbre szeretnénk ásni a rendszer lelki világába, böngésszük át a HyperCall API-kat.

Ami még a felügyelet kapcsán érdekes lehet: csakúgy, mint a Virtual Server 2005 R2 SP1, a Windows Server Virtualization is támogatja már a Volume Shadow Copy szolgáltatását, így lehetőség van a VHD-k futás közben történő mentésére is (Volume Snapshot), valamint vannak eszközeink a VHD állományok megnyitására is (de csak ha éppen nem használjuk őket), hogy abban kézzel végezzünk el módosításokat.

A System Center Virtual Machine Manager kényelmesebbé teszi a virtuális gépparkok kezelését

Ha pedig egy teljes virtuális gépparkot szeretnénk megfelelően felügyelni, szükségünk lesz a System Center Virtual Machine Managerre is, ami mind Virtual Server-, mind Windows Server Virtualization-alapú gépek felügyeletére is alkalmas. Ha ehhez hozzávesszük a System Center Operations Manager 2007-et is, akkor egy központi helyről felügyelhetjük mind fizikai, mind virtuális gépeink egészségi állapotát, és gyorsan tudunk reagálni az esetleges teljesítményproblémákra is.

Zárszó

Érdekes technológia lesz a Windows Server Virtualization, az már biztosan látszik -- az első publikus béta verzió 2007 második felében érkezik, a végleges változat pedig a „Longhorn” Server után legfejlebb 180 nappal lesz elérhető. Aki szeretné élőben is látni a rendszert, látogasson el a Soapbox on MSN Video oldalra.

Véleménye van?

• szóljon hozzá a fórumban
• írjon szerkesztőségünknek!

kipróbáltuk