Windows Server 2012 béta - virtualizáció

2011 szeptemberében a Microsoft kiadta a következő hálózati operációs rendszerének, jelenlegi kódnevén Windows Server 8-nak a nagyon korai, ún. "Developer Preview" (DP) változatát. A fanatikusok (jómagam is) ezt már ütögették rendesen, de ez még tényleg egy elég korai változat volt, egy halom dolog nem, vagy nem helyesen működött. Aztán jó ideig látszólag semmi nem történt, míg végül 2012 februárjának utolsó napján letölthetővé vált a következő mérföldkő a "Beta".

A két dátum közötti időszakban a Microsoft legújabb kori elvei értelmében nem igazán voltunk elkényeztetve információval vagy köztes verziókkal, most viszont a telepítő image-ek mellett több száz oldalnyi deployment guide, step-by-step doksi, és egyéb adalék áll rendelkezésre. Ebben a sorozatban megpróbálom követhető terjedelemben összefoglalni a legfontosabb újdonságokat, mind a DP óta, mind úgy általában a Windows Server 2008 R2-höz képest.

Kicsit magyarázkodok

Nem keveset csúsztam a cikksorozat (1, 2) harmadik részével, ennek részben az az oka, hogy közben azért a napi rutin és a tűzoltások mellett történtek az új szerverrel kapcsolatos és egyben jómagamat is érintő dolgok. Többek között egy remekül sikerült, többségében az új System Center és SQL-verziókat taglaló, de azért egy kicsit az új Windows Servert is beharangozó konferencián vagyunk túl, illetve egy 2 napos Windows Server 2012 (innentől WS12) Beta tanfolyamot is lebonyolítottunk az aláírásomban szereplő oktatóközpontban - szintén jelentős sikerrel.

De van más is: módosítanom kellett a sorozat címét, ugyanis időközben eldőlt, hogy a 8-as szám helyett, a jól bevált évszám kerül a termék neve mellé, olyan sorrendben, ahogy az elmúlt 9 évben megszokhattuk. No és persze az is kiderült, hogy június első hetében megkapjuk az új változatokat, azaz mind a kliensből, mind a szerverből megérkezik majd a klasszikus RC, azaz Release Candidate (a kliensnél RP, azaz Release Preview), ami valószínűleg a végleges változat (RTM) előtti utolsó publikus példány lesz. Úgyhogy ha újra ilyen csigalassúsággal folytatom az írást, akkor lehet, hogy a befejező részre már ezt verziót fogom ütögetni.

Viszont ebben a harmadik részben kicsit megint tömény leszek, pedig csak egyetlen nagy dobásról lesz szó, mégpedig a virtualizációról. De mint mindig, most is jelzem, hogy úgy tekintsünk a tartalomra, hogy nem biztos, hogy minden változatlan marad, amiről itt és most szó lesz.

Virtualizáció Hyper-V-vel

Hadd kezdjem el egy szubjektív fordulattal: akármit tesztelek hónapok óta a Hyper-V 3.0-val, mindig minden működött és minden úgy működött, ahogy le van írva, és ahogy magam is elképzeltem - a leírásokból kiindulva. Kezdő versenyzők most biztosan felnevetnek ezen, de a rutinos szakemberek biztosan értik, amire célzok – ez nem mindig tipikus, egy béta terméknél pedig különösen nem. No és persze a lényeg, ami tesztelhető, azaz amit tud a termék, az nem kevés, sőt nagyon is jelentős számú újdonságról van szó, nézzük sorban.

Véleményem szerint az egyik legfontosabb újdonság (főleg a KKV szektor számára) a virtuális gépek replikálási lehetősége két fizikai gép között, közös storage, failover cluster vagy bármilyen más nagyvállalati infrastruktúra nélkül. Ez azt jelenti, hogy két Hyper-V gép esetén a virtuális gépeink egyszerűen duplikálhatóak, a tartalmuk rendszeresen szinkronizálódik, illetve probléma esetén az átváltás gyors és teljes mértékben automatikus - így egyszerű körülmények között is viszonylag magas rendelkezésre állási szintet érhetünk el. Természetesen akár fizikai hálózaton belül, akár WAN-linken keresztül működik a dolog, jelen pillanatban kb. 15 perces replikációs intervallummal (de ez változhat).

^{Telephelyek között, WAN kapcsolaton keresztül is működhet a replika}

Mindkét oldalon szükség lesz némi és nem túl bonyolult indító konfigurálásra, de ha egyszer ezt megtettük, akkor arra is van lehetőségünk, hogy üzem közben, kiesés nélkül teszteljük a replikációt. A Hyper-V replikával kapcsolatban még rengeteg részlet van tarsolyban (olyan extra érdekesek is, mint pl. a Guest IP Injection), de egyelőre legyen elég ennyi, lépjünk tovább.

^{A „Planned Failover” (tervezett átállás) művelethez egy varázsló is dukál}

Live Migration

A klasszikus, azaz a Windows Server 2008 R2-ben megismert Live Migration esetén is vannak kellemes változások. A legfontosabb: fürtözött és nem fürtözött gépek esetén is van lehetőségünk a live migration használatára, akár két önálló, a virtuális gépeket helyben tároló fizikai gép esetén is! Ilyenkor először a .vhd fájl kerül tükrözésre a hálózaton keresztül, majd maga a virtuális gép is, ugyanúgy a szolgáltatások kiesése nélkül. Gyorsabb és akár szimultán migrációt is elérhetünk, azaz például egy 10 gigabites hálózat esetén ki is tudjuk aknázni ezt a lehetőséget

A virtuális gépek mozgatása népszerű terület. Ezt már korábban is megoldhattuk úgy ahogy, de ha arra volt szükség, hogy futás közben mozgassunk, akkor a Windows Server 2008 R2-nél csak a Live Migration-nel tehettük meg – ahhoz pedig sok egyéb körülmény is kellett. Az új Hyper-V alatt ez már natívan, külső segítség nélkül megy, leállás nélkül, akár egy grafikus varázsló, akár PowerShell segítségével, és persze nemcsak egy önálló gép, hanem egy Hyper-V fürt esetén is.

^{A sorrend: másolás, tükrözés, átkapcsolás, törlés}

Az export/import és a mobilitás

Szerintem még a rutinosabb szakemberek közül is sokan úgy gondolkodnak a virtuális gépről (sokáig én is ide tartoztam), hogy az csak két fájl, és ennyi, tehát mozgatni, exportálni nem nagy kunszt. Pedig hát van azért itt még sok egyéb összetevő is, például:

• A virtuális gép háttértárolója azaz a lemez (.vhd, vagy .vhdx) amit fizikailag eltárolunk a host gép lemezén vagy pl. egy CSV köteten
• A pillanatfelvételek (snapshot)
• A "Saved State" állapot, ami tipikusan hosztspecifikus, tehát különböző is lehet virtuális gépenként<
• A memóriafájl, ami a virtuális géphez vagy a pillanatfelvételhez is tartozhat
• A virtuális gép konfigurációs fájlja

Minden virtuális gép és pillanatfelvétel egyedi és globális azonosítókkal rendelkezik, azonban rengeteg hosztfüggő jellemző is tartozik hozzájuk, például az elérési útvonalak. Amikor egy virtuális gép indul, a Hyper-V mindezeket ellenőrzi, és ha gubanc van, akkor kapjuk a piros keresztes hibaüzeneteket. Azért, hogy pl. egy export-import után ne legyen ebben az élményben részünk, a WS12-ben mintegy 40 különféle kompatibilitási vizsgálatot végez az import varázsló, és ha lehet, akkor ki is javítja a problémákat - de ha ez nem sikerül, akkor legalább azonnal látjuk is a hibát,  nem kell az Eseménynapló mélyében elrejtett hibaüzeneteket keresgetnünk.

Még egy dolog elmondható az export/import műveletről: az exportot kivehetjük a folyamatból, ugyanis elég a megfelelő fájlok másolása, majd a túloldalon az import -  és készen vagyunk. No és persze amit még nem mondtam, de ma már triviális, az az, hogy minden ezzel kapcsolatos művelet immár PowerShellből is elvégezhető, mivel az új PowerShell Hyper-V modulja tartalmazza az összes cmdlet-et ehhez (is).

VHDX – az új lemezformátum

A korábbi 2 terabájttal szemben 64 terabájtg növelhető a lemez mérete (a részletes táblázatot lásd a következő ábrán), az új formátum védettebb az adatsérülés ellen (pl. egy nem tervezett kikapcsolás akció után), és nagyobb a blokkméret a dinamikus és a differenciális lemezek esetén.
Fontos még a 4KB-os logikai szektorméret, ami teljesítménynövekedést hoz, illetve több az online művelet: menet közben végezhető el a pillanatfelvételek összefűzése például, amihez eddig ehhez le kellett állítanunk a virtuális gépet.

^{Tárolási paraméterek összevetése}

A storage-gyártókkal együttműködve, azok innovatív újdonságait beépítve az új Hyper-V a nagyméretű adatmásolás/mozgatás/összefűzés műveletek felgyorsítása apropóján egy olyan újdonságot használ, amit Offloaded Data Transfer-nek (vagy ODX-nek) hívunk. Ez azt jelenti, hogy ezek a műveletek rendkívül gyorsan, a hypervisort és a virtuális gépet nem terhelve, a storage hardver hathatós segítségével valósulnak meg. Ezt a lehetőséget a virtuális SCSI vagy pass-through lemezekkel, illetve a natív .vhdx-ekkel használhatjuk ki, a virtuális IDE vezérlőkre kötött lemezekkel nem (és ebben az esetben a .vhdx-ekkel sem).

Az új Hyper-V-ben lehetőségünk van (legfeljebb 4 db) virtuális Fiber Channel adapter használatára, amelyekkel közvetlenül a virtuális gépből érhetjük el az FC rendszerben kiajánlott LUN-okat. Minden egyes a fizikai adaptereknél megszokott tudást felvonultat a virtuális kártya is, azaz teljesen úgy működik, mintha valóban egy fizikai gépről és egy kézzelfogható adapterről lenne szó. A támogatás természetesen érvényes az NPIV-re, a virtuális SAN-okra, a live migration-ra, vagy éppen az MPIO-ra egyaránt.

^{Egy virtuális FC adapter felvétele a guest géphez}

Hálózatvirtualizáció

Ez egy nagyon izgalmas rész, viszont - ellentétben az összes eddigi és ezután felsorolt jósággal -, kipróbálni még nem tudtam, mivel nincs kész teljesen. Ennek ellenére passzol ebbe a cikkbe, így semmiképpen nem akartam kihagyni. Szóval képzeljük el, hogy egy olyan Hyper-V rendszert kell üzemeltetnünk, amelyben több gép alkot egy virtuális hálózatot, amelyek ki is látnak a nagyvilágba, és aztán kapunk még egy adag virtuális gépet, amelyekben néhány gép egy másik hálózatot alkot. Csak éppen az a gond, hogy a két rendszerben az összes IP-cím azonos alhálózatból van, sőt, vannak konkrétan IP-cím átfedések is. Mivel nem változtathatunk, ez a helyzet bizony ütközésekhez vezet majd, tehát nagy a gond. Bevethetjük persze a VLAN taggelést, de akkor skálázhatósági és egyéb formai problémákba ütközünk, szóval inkább valami másra lenne szükség.

Ezt a "mást" képes nyújtani a Hyper-V a hálózat virtualizációval, amely egy szoftveres, házirendalapú megoldás. A működés lényege egyébként olyan nagyon nem bonyolult: minden virtuális gépnek 2 IP-címe van, egy, amivel érkezik, azaz az eredeti, és egy másik, amelyet a fizikai hálózati infrastruktúrából adunk meg. Ez utóbbi látható a fizikai hálózatból, de láthatatlan a virtuális gépek szempontjából. A virtualizációra két technikánk van/lesz, az ún. "IP rewrite", illetve az IP enkapszuláció, és egy nagyon fontos komponens az ún. Policy Manager passzítja a címeket a fizikai hálózatot és a virtuális gépeket.

^{Hálózatvirtualizáció példa}

A Windows Server  2012 Hyper-V-ben egy virtuális gép tulajdonságai között az eddigi szimpla Network Adapter menü kissé kibővült, megszületett egy Hardware Acceleration, illetve egy Advanced Features elágazás is. Az utóbbi alatt az ismerős MAC spoofing mellett három újdonságot is felfedezhetünk, amelyek alapvetően mind biztonsággal kapcsolatosak:

• DHCP Guard: biztosan másnak is volt már olyan élménye, hogy a virtuális gépben futó DHCP szerver egy helytelen konfigurációnak köszönhetően olyan gépeket is megtalált, amelyeket nem kellett volna. Ez nemcsak kellemetlen, hanem biztonsági szempontból is problémás. A DHCP Guard ezeket képes blokkolni – virtuális gépenként.
• Router Guard: A routerként működő virtuális gépek átirányítási és kihirdetési üzeneteit dobálja el, ha azok nem érvényesek (azaz jogosulatlanok) a mi virtuális gépünk számára.
• Monitor Port: a gép teljes kimenő/bejövő hálózati forgalmának duplikálása egy másik switch portra, egy másik virtuális géphez, ami a monitorozást végzi (a képen nem látszik, de a Mirroring Mode alatt egy Destination / Source választási lehetőségünk van).

^{Guardok minden mennyiségben}

Domain controller virtualizációja biztonságosan

A tartományvezérlőinket (Domain Controller, DC) már jó pár éve virtualizáljuk már jó pár éve, de csak fenntartásokkal. A problémás körülmények közé tartozik a Hyper-V időszinkronizálás, vagy a VHD/VM exportja, másolása vagy éppen a pillanatfelvételek (snapshot) használata, azaz konkrétan egy ezekből adódó helytelen visszaállítás. Ez utóbbiak a DC-k között komoly replikációs problémákat, USN és RID Pool kavarást, károsodott, apátlan-anyátlan objektumokat, inkonzisztens jelszavakat és attribútumokat, duplikált SID-eket és esetleg egy Schema FSMO rollback esetén akár igencsak fájdalmas sémahibákat is előhozhatnak.

A Windows Server 2012 a virtualizált DC-k esetén egy újdonság bevezetésével próbálja megoldani ezeket a gondokat, ez pedig az ún. "VM GenerationID", ami egy speciális azonosító. Ebből az látszik, hogy a Microsoft a hypervisor és a DC működését összehangolta, hogy valamennyi virtualizáció adta képességet (save state, pillanatfelvétel stb.) bátran ki lehessen használni a tartományvezérlőkön is. Így tehát ha menet közben egy snapshot vagy egy VM-másolás történik, akkor ezt detektálja a DC, az azonosító változik (a helyit a virtuális gép BIOS-ában találjuk, az OS egy driveren keresztül látja), és a bootolás közben, még mielőtt a helyi címtáradatbázis-változások véglegesülnének és a replikáció megkezdődne, a DC összehasonlítja ezt az azonosítót a címtárban korábban, azaz a snapshot előtt eltárolttal (ez egy nem replikálódó attribútum a DC számítógép fiókjának részeként).

Égbe révedő informatikusok: az Időkép-sztori Mi fán terem az előrejelzés, hogy milyen infrastruktúra dolgozik az Időkép alatt, mi várható a deep learning modellek térnyerésével?

Égbe révedő informatikusok: az Időkép-sztori Mi fán terem az előrejelzés, hogy milyen infrastruktúra dolgozik az Időkép alatt, mi várható a deep learning modellek térnyerésével?

Ha zűr van, azaz ha az ID-k különböznek, akkor ezt a DC egy rollback-ként értékeli, reseteli a helyit, minden helyből elindított címtárváltozási igényt megszakít, és inkább csendesen a többi DC-hez igazodik. Viszonylag egyszerűen hangzik, de nem az, ellenben nagyon hasznos lesz. Viszont - értelemszerűen - ez a fajta extra védelem csak akkor élhet, ha ez a virtuális DC egy WS12 Hyper-V alatt fut, mivel a GID kezelés a Hyper-V tudástárába tartozik.

A Windows Server 2012-ben kérhetjük azt is, hogy egy már működő virtuális DC-t klónozással hadd kettőzzünk meg a tartományon belül. A folyamat során szükség lesz egy komplett .vhd export/import vagy szimpla másolás műveletre, egy konfigurációs fájl legyártása az előléptetéshez akár kézzel, akár automatán feltöltött adatokkal (név, IP cím, alhálózat, DNS szerverek adatai, egyebek), illetve egy olyan .xml fájl legyártása, amelyben az eredeti tartományvezérlőn futó, de nem klónozható szolgáltatások (pl. DHCP, Print Management Console) megjelölése történik meg és kész, a többi megy majd magától. Nem kell sysprepelt image telepítés, előléptetés, replika hálózaton vagy külső tárolóról, semmi utólagos konfig, csak ennyi. Nekem nagyon tetszik, még akkor is, ha ennek már azért lesz néhány követelménye, például. egy Windows Server 2012 Primary Domain Controller Flexible Single Master Operations (PDC FSMO) megléte.

Folytatás következik

Tisztában vagyok vele, hogy a Hyper-V témakör kapcsán is sikerült kihagyni pár újdonságot, de biztos vagyok benne, hogy lesz még alkalom és idő pótolni mindezt, és persze jön az utolsó, kicsit vegyes rész is, amelyben szintén lesz bőven újdonság – hamarosan.

Gál Tamás
informatikai vezető, vezető oktató, IQSOFT-John Bryce Oktatóközpont