Eredetileg egy cikkben akartam bemutatni mindent, amit az ESX VI3 környezet kapcsán célszerű megismerni, de aztán túl hosszú lett, így inkább 2 részre vágtam szét. Az előző részben beállítottuk a hálózatot, létrehoztunk egy fürtöt és átnéztük annak beállításait. Ez alkalommal a közös storage beállításával ismerkedünk meg, illetve létrehozzuk az első ESX VI3 alatti virtuális gépünket is, egy Windows XP lesz. Végezetül egy VMotion-t is végrehajtunk, azaz az egyik fizikai vasról a másik fizikai vasra helyezzük át a futó XP virtuális gépet, leállás nélkül. Az iSCSI közös storage és a notebook teljesítménye miatt 2 „ping” maradt ki, de a múlt heti szerver környezeti tesztjeim alatt (FC+BLADE) mindössze egyetlen „ping” marad ki a VMotion alatt (ARP flush miatt). A migráció alatt egy rajzot készítettem „mspaint”-ben (RDP kapcsolat közben). A kapcsolat nem bont le, sőt, a Paint-ben a ceruzám csak egy pillanatra „nem fog”. Kb. ennyit vettem észre abból, hogy a gépem fizikai gépek határát átlépte. A felhasználó ezt észre sem veszi (egy pillanatra nem működik az egér a távoli asztal kapcsolatban).

Minden alapja, egy közös hálózati tároló (iSCSI SAN konfigurációja)

Ahogy már korábban is említettem, a VMware a SAN-okon elhelyezett virtuális gépeket támogatja. Nem véletlen, hiszen csak megosztott lemezeken lehet szó HA vagy VMotion szolgáltatásokról.

Példámban most nem FC vagy NFS, hanem az iSCSI alapú SAN beállítását fogom végigjárni.

Nagyvállalati környezetben e helyett az FC SAN + HBA konfiguráció a jellemző. Azért az iSCSI-t választottam, mert nem kell hozzá FC HBA, így bárki számára akár otthon is elérhető, így amit itt bemutatok, akár otthon is össze lehet faragni. Igaz a legutóbb azt ígértem nincs több barkácsolás, így természetesen az Openfiler kicserélhető egy iSCSI célhardverre, nem beszélve arról, hogy a legtöbb FC storage iSCSI hálózati csatlakozóval is fel van szerelve.

Először is engedélyezzük az iSCSI szolgáltatást az ESX hoszt(ok) esetén.

Ilyenkor a gép sorsol neki egy egyedi iSCSI nevet. Ezzel fog majd bejelentkezni az Openfiler-be a példámban.

Adjuk hozzá az Openfiler IP címét. Példámban külön IP tartományt hoztam létre a storage hálózat számára.

Az új iSCSI szervert felvéve indulhat a dinamikus felderítés, azaz hálózaton keresztül az ESX hoszt lekéri, hogy milyen elérhető LUN-ok vannak a gépen.

Később (változások esetén) ez a „Rescan” link segítségével kikényszeríthető.

Útvonal beállítási lehetőségek. FC esetén is megadható!!!

Az iSCSI HBA az ESX esetén egy szoftveres emuláció általi megoldás. Akárcsak a Windows-ban is megtalálható jól ismert MS iSCSI target programocska. A következő képek a lemez hozzáadását mutatják. (Ha az ESX-et bootolni is szeretnénk, akkor fizikai iSCSI HBA-ra lesz szükségünk. Ebből kb. 1 fajta van most a piacon.)

A „Datastore” neve esetén használjunk beszédes neveket. A „sandisk” nem jó példa, ezt később át is neveztem.

A VMware a 8MB-os blokk méretet ajánlja (FC esetén). Ennek ellenére, az iSCSI tesztkörnyezetemben a legkisebbet, az 1MB-os méretet választom, mert ott ez a beállítás hoz gyorsabb válaszidőt (látszólag nagyobb teljesítményt).

A nagy varázslat az, hogy az egyes szervernél (ESX01) vettem fel és formáztam meg a közös lemezt, de ugyanaz egyből elérhető az azonos fürtbeli 2-es szerveren is (ESX02). Automatikusan hozzáadja az ott elérhető DataStore-ok közé, nem kell minden egyes szervernél külön-külön rögzíteni.

Most már egyre jobban állunk, készen van az ESX01 és ESX02 gépek közötti közös tároló is. Mindkét gép látja. Az egyik gépben válasszunk a Browse DataStore-t, és töltsük fel az XP telepítőjét. Ezt most nem részletezem, mert a korábbi ESXi-s cikkemben kb. ugyanezt már végigjátszottuk.

Itt látható a korábbi cikkemből kimaradt fontos kép, a „Cluster mint gépek halmaza erőforráskeret”. Itt nagyon nagy számok lehetnek, több tízezer Mhz, illetve több száz GB memória. Ez ne csapjon be senkit, a foglalható legnagyobb memória és CPU virtuális gépenként a fürt legkisebb gépéhez lesz igazítva. Ezért célszerű azonos gépeket választani!

Kúszik fel az XP telepítő a közös storage-ra. Esetemben az Openfiler virtuális gép virtuális lemezére. Nem célom ezt most jobban megértetni, de bízom benne követhető vagyok J

Itt már normálisabb neveket adtam a DataStore-oknak.

Új virtuális gép létrehozása VI3 környezetben

Mint már mondtam, nincs új a nap alatt, ez a rész itt pont ugyanaz, mint a szigetszerű felhasználás esetén. Pár apróbb különbséggel.

Például, itt egy eltérés. A Datastore VI3 környezet estén lehet „Multiple hosts” típusú is!

Csak a teszt környezet miatt választottam ilyen kis lemezt, valójában legalább 10GB javasolt XP esetén (rendszer „C” lemeznek).

A BusLogic SCSI driverrel játszani kell, hogy a BOOT a CD-ről menjen, majd utána betenni a floppyt, de a virtuális gép BIOS-ában is lehet váltani a Boot-olási sorrendet.

Célszerű a floppyt kivenni boot után, majd betenni az F6 nyomkodása után (Windows telepítő). Kezdőknél egy pár újraindítás simán belefér, mire minden összejön. Olyan ez, mint a mélygarázsban parkolás… nem mindig jön össze elsőre (különösen dél körül).

Az a bizonyos „VMware SCSI” vezérlő. Állítólag a „LSILogic” jobb és gyorsabb, viszont macerásabb, a gyártótól kell letölteni a legfrissebbet, és floppy ISO-t készíteni belőle…

Szokásos XP telepítő.

Szegény notebookom, a Virtuális ESX-ben a virtuális XP már nagyon kiverte biztosítékot, demóra még éppen jó.

VMware Tools telepítése, akárcsak az eddig is megismert VMware Server vagy Workstation termékek esetén.

Virtuális gép mozgatása VMotion segítségével

A következő képsor a sokat emlegetett VMotion folyamatát mutatja be az általam létrehozott teszt környezetben.

Az XP virtuális gép az ESX01-ről az ESX02-re kúszik át.

A VMotion előtt bevizsgálja, hogy mehet-e a migráció. Ha a VMkernel IP címét elírtad (és nem látják az ESX-ek kernel-ei egymást), azt nem veszi észre, és fura hibát kapsz a végén L

Hurrá, mehet! Az infrastruktúra sebességétől függően mozgatás alatt álló virtuális XP-t egy harmadik helyről ping-elve egy csomag szokott kimaradni.

Fontos apróságok (melyekre nem maradt időm)

Sajnos nem tudtam mindenről írni és mindent bemutatni e két VI3 cikkem során! Fontos például az ESX 3.5 „NIC Teaming” és „load balancing” tudása, mely a „Jumbo frame”-ek használatával jelentősen felgyorsítja a virtuális gépek hálózati elérését (így akár 9000 bájtos hálózati csomagok használatára is rá lehet bírni az ESX-et). Akikkel beszélek (nap mint nap), komoly teljesítmény-orientált nagyvállalati rendszereket üzemeltetnek, szerintük a „Jumbo frame”-ek használata komoly előnyt jelent (és ahol erre valóban szükség van, ott pedig FC-t használnak iSCSI helyett). Az ehhez hasonló „kis” apróságokon múlnak sokszor milliós beszerzések vagy várakozó megrendelések sorsa. Egyes cégek vezetőitől azt is hallom, hogy nincs idejük mostanság „pilot projektekre”, hogy az összes konkurens gyártó nemrég megjelent termékét tesztelgesse, amikor világszinten komoly referencia háttérrel rendelkező megoldást is választhat a VMware termékei közt keresgélve.

A „Jumbo frame”-ekről itt: http://www.vmware.com/support/vi3/doc/whatsnew_esx35_vc25.html [1]

És itt: http://en.wikipedia.org/wiki/Jumbo_frame [2]

Cikkemben nem esik szó a „Resource Pool”-okról, mint erőforrás csoportokról, és még számos területet kihagytam, hiszen mire megírom az egészet, kijön a következő verzió, és írhatom át. Az érdeklődők számára javasolom a „VATC” VI3 tanfolyamokat, majd a tanfolyamot követő VMware Certified Profressional (VCP) vizsga lehetőséget. Következő cikkeimben a VI3-ra épülő egyéb lehetőségeket fogom bemutatni.

A dinamikusan skálázható adatközpont ára és a konkurens gyártók

Mostanság minden gyártó dinamikus adatközpontokról beszél, ahol az erőforrások menet közben bővíthetőek, és nincs lustálkodó szerver. Mindennek alapja a VMotion (szerű technológia), mely technológiát a VMware fejlesztett ki elsőként, és jelenített meg a piacon évekkel ezelőtt. Lassan más gyártók is (Citrix XenServer 5 – Live motion vagy Microsoft Hyper-V Server – Quick Migration hamarosan LiveMigration) felzárkóznak és hasonló tudást „ingyen” kínálnak (Valóban ingyen? Ugyan már! Pontosan mit is kapunk ingyen és miért kell fizetni majd?). De vajon mikor jutnak olyan szintre, hogy megoldásuk valódi konkurenciát jelentene a VMware kiforrt, piacvezető megoldásával szemben? A kérdés itt is inkább a management eszközökről szól majd, ami természetesen egyik gyártónál sem lesz ingyenes – ezek csomagolását (kiforrtságát/tudását/árait) kell tanulmányozni!

A VMware már számos technológiát készített, melynek alapja a működő VMotion, úgymint terheléselosztó DRS http://www.vmware.com/products/vi/vc/drs.html [3] illetve DPM (energiatakarékosság a virtuális gépek kevesebb számú fizikai gépre történő összeterelgetésével) http://www.vmwarevideos.com/video-vmwares-distributed-power-management-dpm-in-action [4].

„VMware vSphere4” újdonságok

A sokak által várt, hamarosan megjelenő (pontos dátumot még nem találunk sehol az Interneten) VI4 rengeteg újdonságot hoz magával ismét feladva a leckét a „platformjáték” többi szereplőjének.

VMotion CPU Matrix

Saját bőrömön is tapasztaltam, hogy időnként szükség van “vízzel főzni”, azaz külső erőforrás bevonása nélkül lefedni egy adott tesztkörnyezet igényeit.

Az Openfiler tökéletesen alkalmas a VI család SAN-ra épülő funkcionalitásának teszteléséhez, ahogy azt community supported állapota is jelzi. Tárolórendszerünk kialakításához mindössze egy olyan szerverre van szükség, amelynek a tároló-vezérlője openfiler-kompatibilis. Az openfiler telepítése után az iSCSI felületen megosztott tár-terület máris kiosztható az ESX szerver farmnak. Persze azt a szervert másra nem tudjuk használni, csak hálózatos tárolóként. Ha még ennyi szabad hardverrel sem rendelkezünk, az Openfiler nyilván futtatható desktop virtualizációs környezetben, bár én ezt nem próbáltam… Elvetemültebbek két ESX node-ot és egy Openfiler-t is belepasszíroznak egy WS6 környezetbe – aki ilyet már csinált, jelentkezzen

Mivel szoftver RAID-re is képes az Openfiler, akár éles rendszert is rá lehet rakni egy hw RAID nélküli rendszerre, persze megfelelő tesztelés után. A hálózatos terhelés-megosztás aktiválása is ajánlott, a switch képességekhez illeszkedő módon. Utóbbi azonban csak az update lefuttatása után jelenik meg, mint GUI-ból vezérelhető funkció.

Egy buggal szembesültem, amibe mások is belefutottak: ha egynél több, azonos méretű LUN-t definiálunk iSCSI targetként, az ESX egy LUN-ként kezeli őket, mint egymás “alternate path”-ja. Ezt egy manuális konfig javítással lehet megkerülni: részleteket lásd itt és itt.

Amit nem teszteltem még: NAS (NFS) képesség, de annak is mennie kéne.

Emlékeztető: a VI35 kiszerelései közül már a Foundation is (a Starter utódja) is képes NFS mellett már mindenféle SAN hálózatra csatlakozni – azaz az ilyen jellegű korábbi licensz korlátozások eltűntek.