A saját tapasztalatom az, hogy — legalábbis Windows-ok esetében — bizony készpénznek kell venni a VMware állítását (ld. a lenti táblázat), mert hiába állítottam egy W2k3STD Exchange szerverről, hogy ő voltaképpen egy Enterprise Edition, plusz memóriát a géphez adva az nem reagált rá, csak újraindítás után lett használható az utólag (menet közben) hozzáadott memória. CPU-val még nem próbáltam, akinek van tapasztalata, kérem ossza meg velem, velünk!

Íme táblázat a Hot-Add/Hot-Plug jelenlegi helyzetéről:

Sajnos (?) jelen pillanatban se a memória, se a CPU üzem közbeni eltávolítása nem működik egyetlen vendég operációs rendszer esetében sem.

LangDetecten>hu YahooCerror

beállítani

A hiba esetén a képernyőn elsőre talán ijesztő üzenet fogadja a gazdit:

fsck.ext3: Unable to resolve ‘UUID=46f5a369-e9e7-4bad-bc9a-4d45078c70c3′

Tömören annyi a probléma, hogy a szerver a kötetek automatikus csatolásakor nem találja az /etc/fstab-ban a hibaüzenetben megjelölt UUID-val rendelkező kötetet. Valószínűleg a telepítés során a kérdéses kötet azonosítója megváltozott, ezt a mai nap során leellenőrzöm.

Az a gyanúm, hogy a hiba csak azoknál a telepítéseknél fordul elő, amelyek nem nulláról történtek, hanem a meglévő ESX (pl. 3.5) lett frissítve, mint például nálam is. Ha “szűz” telepítéseken is megjelenik a probléma, kérem értesítsetek!

A gyanúmat az alábbi fstab tartalom táplálja, amit én a szervereimen találtam, és amely sorok közül az első sornál állt meg az indulási folyamat:

# BEGIN migrated entries
#   Note: Any entries in this section will be removed
#   when cleaning out the ESX v3 installation.
UUID=46f5a369-e9e7-4bad-bc9a-4d45078c70c3 /esx3-installation/ ext3 defaults,ro 1 1
UUID=e335a2ca-7dd0-4af9-951d-89646c70c167 /esx3-installation/boot ext3 defaults 1 2
UUID=fa99e301-71ae-4b42-a240-5b188c7566eb /esx3-installation/var/log ext3 defaults,ro 1 2
# END migrated entries

Javítás

A root jelszó begépelésével be kell lépni a konzolra, majd mivel a gyökér kötet csak olvasható módban lett felcsatolva, újra kell azt csatolni az írhatóvá tételéhez és szerkeszteni kell az fstab-ot kikommentezve belőle a korábbi telepítésre utaló csatolási pontokat, amik a normál működéshez amúgy sem kellenek.

$ mount -o remount,rw /
$ nano /etc/fstab  (vagy a mazochistább arcoknak: vi /etc/fstab :] )
$ exit

A szerver ekkor újraindul és remélhetőleg immár semmitől sem zavartatva teszi a dolgát, természetesen a feltelepített javításokkal.

A csomagok leírását itt lehet megtalálni.

- FONTOS –

2010. május 21-i dátummal a VMware megszünteti az ESX 3.x sorozatok támogatását. A VCB esetén ez a dátum 2010. július 25.

Ezért nem árt lassan átállni vSphere, illetve a VCB-t kiváltó  Data Recovery megoldásra, esetleg beszerezni egy vStorage API-ra épülő mentési megoldást.

Azon esetekben, ahol HW kompatibilitási okokból nem lehetséges az UPGRADE, igénylehető u.n. kibővített támogatás, amellyel a támogatás kinyújtható 2013-ig. Azonban ez csak a 3.5U5 esetére érvényes, illetve a legutolsó vCenter2.x update-re.

Support matrix

VCB info

A hiba azon vsphere ESX telepítéseknél jön elő, ahová valamilyen management agent-et már feltettetek. U1 telepítés és újraindítás után ezek a box-ok lila halálba mennek.

Workaround-ként a a mgmt agent-eket le kell szedni a gépről majd U1 telepítés után visszatenni.

KB cikk

A nemrég megjelent VMware vSphere 4 (ESX 4.0) kapcsán talán az egyik legfontosabb dokumentum most a frissítési útmutató (ESX 3.5-ről), a napokban a legtöbb kérdés ezzel kapcsolatban ér utol. Az ünnepek alatt szakítottam egy kis időt, és megírtam a magyar nyelvű cikkemet (nemcsak a lusták kedvéért). Igyekeztem egy-két fontos tanácsot is elrejteni az amúgy dokumentációból is kiolvasható frissítéssel kapcsolatos tudnivalók közé. Jó frissítést mindenkinek!

Előkészületek: ESX3.5 szerverek és VI3 (2.5) felügyelet

A kiindulás alapom 2db ESX 3.5.0 (U3) szerverből álló fürt, a hozzávaló VI3 felülettel (ahol a VirtualCenter verziószáma 2.5). Gondolom, a legtöbb helyen ez a verzió van telepítve, hogy pontosan milyen liszenszel rendelkezünk (foundation-enterprise), a frissítés szempontjából ez most lényegtelen.

Frissítendő teszt környezet részletei (lényegtelen a frissítés szempontjából)

A VirtualCenter 2.5 szerver virtuális gépként fut (egy harmadik fizikai gépen), a frissítendő „szerverek”ez alkalommal fizikai gépek, a legkisebb Intel-VT-t már tartalmazó desktop processzorral szerelve (E6550), 4GB RAM-mal gépenként, valamint az ESX3 illetve ESX4 futtatására legalkalmasabb ASUS P5N-D alaplapot választottam (már nem nagyon lehet ilyesfélét kapni). Effélét bárki össze tud guberálni, aki a frissítést szeretné elpróbálni otthon, mielőtt, nekiesne az éles rendszernek. Persze bármilyen valódi szervernek látszó tárgy jobb kiindulási alap ennél (úgy látszik még mindig nem tudtam elszakadni az otthoni gagyi gépektől, amikor cikket írok J). Természetesen VMware Workstation 6.5 alatt is el lehet játszani a frissítést csupán virtuális gépekkel, itt arra kell csak figyelni, hogy az ESX-ek a 4.0-ás változattal már 2GB RAM-ot igényelnek.

Maradék zsebpénzemet ismét brand Intel NIC-ekre költöttem, vettem Intel Pro 1000-ből új PCI-E 1X-es változatot (PT), illetve a régi PCI-os változatot (GT). Illetve volt egy korábbi Intel Pro 100-am (ez 3.5 alatt még ment, de 4.0 alatt már le kell mondanom róla – hacsak nem teszek fel drivert hozzá – erről majd később még írok). Az alaplapra integráltan csak NForce Chipset-et használok, így az ASUS P5N-D alaplapi gigabit hálózat prímán működik mindenféle ESX/ESXi verziók alatt. Mondanom sem kell a teszt környezet (frissítésének) költségvetése így 300E forint alatt tudott maradni a végére, melynek jelentős része a hálózati kártyákra ment el.

Ami a memóriát illeti a szerviz konzol a szokásos alapértelmezett 272MB-ot eszi meg a kiszolgálón. A maradék 3.5GB-ot lehet szétosztani a virtuális gépek közt.

Storage hálózat szinten még mindig OpenFiler a barátom, lassan jön össze a zsebpénzemből egy EMC vagy NetApp FC storage+a hozzávaló HBA-k. Jó alternatíva lehet pl. a HP LeftHand VSA megoldása, amint lesz egy kis időm, utána nézek. Éles szeműek észrevehetik, hogy a VMFS 3.31-es változatot az ESX 3.5-tel formáztam, egy 3.33-ra fog változni, amikor majd 4.0-val formázok. Minden irányban kompatibilis, nem kell aggódni.

A hálózat a lehető legegyszerűbb hármas (Szerviz konzol, VMKernel – iSCSI és VMotion miatt, Virtuális gépek hálózata), és sajnos még nem redundáns (ezért a kis felkiáltójel a DRS_Cluster-en).

Liszensz szempontjából minden földi jó be van állítva teszt célból, az ENTERPRISE változatot fogom frissíteni (host liszensz fájl alapján).

Új szerverek minimum követelménye

Az ESX 4.0 fizikai kiszolgálókkal szemben elvárásrok

· 64 bites szerver

· minimum 2GB RAM

VirtualCenter 4.0 számára támogatott operációs rendszerek

· Windows XP Professional

· Windows 2003

· Windows 2008 (újdonság, eddig nem volt támogatott)

Támogatott adatbázis hátterek a VirtualCenter mögé, amennyiben nem a beépítettet akarjuk használni (MSDE avagy SQL 2005 Express Edition)

· IBM DB2

· Microsoft SQL Server 2005

· Microsoft SQL Server 2008

· Oracle 10g

· Oracle 11g (újdonság)

Az ESX/VI környezet frissítési folyamatának lépései

Az alábbi rajzon láthatóak a frissítés lépései, célszerű ezeket követni:

Az izgalom a 3-as pontnál kezdődik. Mivel nekem a VirtualCenter 2.5 is egy VM, ezért nyomtam róla egy mentést a folyamat előtt. Természetesen nagyobb rendszerek esetén célszerű követni a frissítési útmutatóban bemutatott forgatókönyveket:

(vsp_40_upgrade_guide.pdf)

Még egyszer összefoglalásképpen tehát:

To complete the upgrade, you will perform the following tasks:

· Upgrade VirtualCenter Server 2.5 to vCenter Server 4.0.

· Upgrade VMware Update Manager 1.0 to vCenter Update Manager 4.0.

· Use Update Manager to upgrade the ESX 3.5 server to ESX 4.0.

· Use Update Manager to upgrade the virtual machines on the ESX host to the latest version of VMware Tools and Hardware Version 7.

A VirtualCenter Server 2.5 – vCenter Server 4.0-re frissítése

Első feladat tehát a VirtualCenter Server frissítése. Nem kell aggódni, a frissítés után természetesen látni fogja a VC4 a korábbi 3.5-ös ESX szervereket is és az új 4.0-ás ESX-eket is egyaránt  (ez szokott lenni az első kérdés).

A frissítést megelőzendő lépjünk be a VirtualCenter-t futtató jellemzően Windows 2003 szerverre, és állítsuk le a „VMware VirtualCenter” Server szervizt.

Ezt követően a letölthető ZIP vagy ISO állományban indítsuk el az autorun.exe-t! Én a ZIP-et töltöttem le, mert az kisebb (VMware-VIMSetup-all-4.0.0-162902.zip).

Egyből figyelmeztet is, hogy egy korábbi verzió már telepítve lett a gépen, és az frissítve lesz.

A telepítés során az alábbi lépések érdekesek:

A korábbi liszensz fájlok helyett a 4.0-ás változatnál egyszerű sorozatszámokat lehet majd használni. Így van ez a Virtual Center esetén is, illetve az ESX hosztok esetén is. Én nem adok meg sorozatszámot, így EVAL módban fog futni a termék. Akinek van korábbi 3.5 érvényes S&S-e, azaz verziókövetése, azok megkapták a VMware-től e-mailben az új termék használatához szükséges kulcsokat. Erről még a későbbiekben írok.

Az adatbázis beállításokon most nem módosítok:

A megjelenő figyelmeztetés teljesen normális, ezeket a komponenseket majd később fogjuk frissíteni.

Érdekességképpen, ha a telepítőt újraindítjuk, akkor ez a rész tér csak el és akkor így jelenik meg:

Normál esetben a fenti képpel nem találkozunk.

Igen, frissíteni akarom az adatbázist. Legyen akár helyi MS SQL Express vagy távoli Oracle.

Célszerűen ezen nem változtatok, hogy milyen felhasználó alatt fusson a Virtual Center szervert szervize.

Az alapértelmezett portokat sem érdemes babrálni, hacsak nincs valami különös oka annak:

Ha tűzfalas környezetbe telepítjük a rendszert, akkor ezeket érdemes felírni a telepítés során, később nagyon hasznos lehet.

Nem árt, ha van Internet kapcsolata a gépnek, miközben a MS.NET keretrendszer újabb változatát telepíti a telepítő J

A telepítés ekkor van készen:

A START menüben kotorászva új ikonokat találunk:

A telepítés befejeztével indítsuk újra a gépet!

Virtual Center kliens frissítése (Virtual Center helyett vSphere 4.0 kliensre)

Ha megvagyunk a szerver frissítésével, akkor jöhet a kliens frissítése. Ez új telepítés esetén nem jár a VC-vel, de utólag fel lehet tenni. Illetve természetesen lehet frissíteni. Célszerűen most a VC szerverre telepítem, de természetesen lehet külön gépre is tenni.

A kliens új nevet kapott: vSphere Client.

A Host Update Utility-t NE tegyük fel! Ez majd később kerül fel, frissítve.

A telepítő a Visual J# 2.0 keretrendszer után pár fájlt még a helyére tesz.

Első belépéskor az SSL (self-signed) tanúsítvány miatt figyelmeztetés jelenik meg.

A belépés során új üzenetek jelennek meg, mint pl. „Discovering Plugins…”

Belépve a „Home” rész fogad. A korábbi 3.5-ös kliensben megszokott nézethez kattintsunk a „Host and Clusters” ikonra!

A képen jól látható, hogy a korábbi 2.5-ös VirtualCenter-t sikeresen megfrissítettem 4.0-ra, és minden objektum, ami az ESX szervereken volt megmaradt és használható.

Update Manager frissítése

Folytassuk a munkát az Update Manager frissítésével! Ezt szintén a telepítőkészlettel lehet indítani (autorun.exe).

Ne ijedjünk meg a felugró figyelmeztetéstől, ez teljesen normális, ha korábban volt 2.5-höz Update Manager telepítve.

Első feladat a belépés:

Használjuk a VC-hez használt felhasználónevet és jelszót!

Az adatbázist is frissítsük!

A frissítés után indítsuk el a klienst újra, majd frissítsük a kapcsolódó Plug-in-t!

ESX hosztok frissítése az Update Manager segítségével

Remediate an ESX Host

Now that Update Manager is installed, you can configure it so that compliance equates to an installed hypervisor running ESX 4.0. Then when you remediate against that baseline, Update Manager performs the upgrade.

ESX hosztok frissítése, első lépés – update csomag elkészítése

Az új VI4 klienssel az „Update Manager” ikont válasszuk!

Majd kattintsunk a „Baselines and Groups” fülre!

A „Baselines and Groups” fület választva a „Hosts” legyen benyomva, és válasszuk a „Create…” lehetőséget!

Ekkor az új „Baseline” varázsló fogad:

Adjuk meg neki az ESX4 telepítő ISO-t!

Várjuk meg, míg feltölti!

Fogadjuk el az alapértelmezettet!

Fogadjuk el az alapértelmezettet!

Eredmény:

ESX hosztok frissítése, második lépés – update csomag hozzárendelése

Válasszuk ki a frissítendő ESX szervert a „Host and Clusters” nézetet használva. Kattintsunk az „Update Manager” fülre. Most nyomjuk meg az „Attach…” gombot!

Adjuk hozzá a korábban létrehozott ESX 4.0 csomagot!

Most nyomjunk a választott host-on „Scan For Updates”-t!

Ne felejtsük el benyomni az „Upgrades” részt!

A hozzárendelést követően lehetséges, hogy nem fog megfelelni a host a HCL listának (Non-Compliant) de ettől még a frissítést el lehet végezni rajta. Sajnos a „zsuga-home-desktop” gépek nem mentek át a HCL listán, de ez várható volt!

Korábban egy tanfolyamon HP szervereket használva nem volt semmi gond. Ha esetleg a szerver nem felel nem, akkor sem kell kétségbe esni, ettől még nyugodtan mehet neki a frissítés, nagy valószínűséggel sikeres lesz a művelet végére.

Mi van, ha mégsem sikerülne? Semmi különös, a CD-ről még bármikor újra lehet húzni a host-ot, bár akkor sajnos az összes beállítást újra el kell majd végezni rajta, tehát ez amennyire lehet elkerülendő. Persze ezen (új host beállítsának automatizálása) is segíthet a „Host profiles” nevű újdonság!

ESX hosztok frissítése, harmadik lépés – update csomag hozzárendelése után futtatása (a host tényleges frissítése)

Ezt a lépést „Remediate” –nek hívják. Én először az 1-es szervert fogom frissíteni. Ilyenkor le kell állítani vagy át kell migrálni a virtuális gépeket róla egy másik hosztra a frissítés ideje alatt. Én az egyszerűség kedvéért most leállítottam a 2 VM-et, természetesen éles környezetben ezeket át kell migrálni másik hosztra!

A varázsló megjelenik:

Adjuk hozzá a Baseline-t, amit frissíteni kell majd.

Fogadjuk el a liszensz-t!

Tovább…

Illetve azonnal mehet a frissítés!

A Finish-re kattintva már indul is a hoszt gép frissítése!

Először szépen Maintenance mode-ba teszi a gépet, majd újraindítja és megkezdi a frissítését!

A host-on a háttérben ilyenkor ez történik (itt csaltam, mert ez ILO-val egy másik szerver – egy korábbi tanfolyam alapján) J

Betöltődnek a szükséges meghajtók.

Települnek a csomagok, természetesen minden karakteres módban, felhasználói beavatkozás nélkül, hiszen távolról kerül rá a frissítés!

Végezetül egy kis post config, majd készen is van a host! Amikor a host újraindul, multiboot-os lesz – mindenki nagy örömére J

Ha esetleg valami oknál fogva a 3.5-ös verziót szeretnék kipróbálni, a host indításakor erre is van lehetőség!

A host frissítése sikeresen végbement! Jól látszik, hogy a frissítés után az 1-es host-ban megjelent a másik hálózati kártya is! Hurrá, nem lesz végre amatőr „No redundant service console” figyelmeztetésem!

Ez eddig a 3.5 alatt nem látszott!

Most, hogy van 2-2 NIC mindkét hosztban, ideje létrehozni egy distributed switch-et!

Erről a következő cikkemben fogok írni!

Virtuális gépek frissítése az új Virtuális Hardverre (VMHW7) és VMware Tools frissítés

Nincs más tennivaló, mint a virtuális gépeket megfrissíteni! Majd a virtuális gépeken belül a VMware Tools-t is frissíteni az aktuális verzióra. Ezt célszerűen kötegelten kell elvégezni!

Célszerűen előbb a VMware Tools-t frissítsük majd utána módosítsuk a Virtuális Hardvert 4-ről 7-re!

A virtuális hardver frissítését itt lehet kérni (csak kikapcsolt VM-nél lehetséges!):

A figyelmezetést érdemes átnézni, visszafelé már nem lesz kompatibilis a gép innentől ESX3.5-tel!

VM Version: 7! J Természetesen nem egyenként, hanem ezt is tömegesen kell elvégezni a host-okra. Ehhez szintén az Update Manager-t hívhatjuk segítségül, csak ezúttal nem host, hanem VM-ek kötelgelt frissítésére használva.

Különálló (nem VC által felügyelt) hosztok frissítése

Megemlíteném, hogy kapunk egy Host Update Utility-t is, mely segítségével különálló ESX szervereket lehet megfrissíteni.

A tool segítéségével gyerekjáték különálló hosztokat frissíteni!

Liszensz kulcsokkal kapcsolatos tudnivalók meglévő ügyfeleknek

A VMware.com –on belépve a saját felhasználónévvel lehet letölteni a korábbi ESX3.5 felhasználóknak az ESX4.0-hoz tartozó liszensz kulcsokat! Ha több szerverre volt liszensz, akkor a kulcsokat össze is lehet konszolidálni, és egy sorozatszám fogja reprezentálni a korábbi sok szerverre érvényes CPU liszenszt. Erről majd még később részletesebben írok!

Összegzés

Ahogy látható, a frissítés ESX 3.5-ről 4.0-ra viszonylag egyszerű feladat, kb. egy fél napos munka (nagyobb rendszerek esetén valamivel tovább is eltarthat). A frissítés során az éles üzemet nem kell leállítani, amennyiben több fizikai gépünkből álló fürtön a virtuális gépeket az éppen frissítendő host-ról mindig elköltöztetjük, majd vissza).

A frissítés csak az első lépés, első feladatunk a korábbi virtual switch-ek helyett a „Distributed Switch” megismerése. Következő cikkemben az erre történő migrációt fogom bemutatni. Célszerűen, akik az elosztott hálózatos változatú ESX környezetre ruháznak be (Enterprise Plus), számukra célszerű a Cisco Nexus 1000V virtuális switch beszerzése is, így a legjobban kihasználva a rendszer lehetőségeit.

Jó frissítést kívánok mindenkinek!

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.

Előző cikkeimben „szigetszerűen” telepítettem ESX 3.5 vagy ESXi 3.5 kiszolgálókat. Felügyeletükhöz a szerverre kapcsolódva letölthető VI klienst használtuk. Természetesen ez csak a kezdet, az ESX VI környezet előnyeit több fizikai gépből álló fürt (clusa ter) estén tudjuk kamatoztatni. Ehhez azonban egy központi felügyeleti szerver kell telepítenünk, melynek neve Virtual Center. Ez egy Windows 2003 szerverre épülő szoftver, mely egy MS SQL (vagy Oracle) adatbázis háttérrel támogatva az összes ESX/ESXi kiszolgáló együttes felügyeletét ellátja. Ilyenkor a VI kliens nem a fizikai kiszolgálóhoz, hanem a Virtual Center szerverhez kapcsolódik. Ebben a formában már definiálhatunk szerverek közötti kapcsolatokat, úgymint „Adatközpontok/DataCenter” vagy „Fürtök/Cluster”. Az így definiált gépcsoportokon már elérhetőek olyan szolgáltatások is, melyek a folyamatos üzemet támogatják (COS). Ide tartozik a virtuális gépek fizikai kiszolgálók közt történő tervezett mozgatása (VMotion) illetve az erre épülő szolgáltatások úgymint DRS vagy DPM. A magas rendelkezésre állást a 3.5-ös ESX szerverek esetén a HA agent biztosítja, mely nem tervezett esetekben valamely kiszolgáló kiesése esetén a leállt virtuális gépeket a fürtben elérhető szabad kapacitású kiszolgálókon újraindítja. A kiesés ilyenkor az észrevételi idő (15 mp, de állítható) plusz a virtuális gépek újraindítási idejével arányos. Akinek ez nem volna elég, és katasztrófatűrő telephelyek építésén gondolkoznak, ők a VMware SRM-et nézegessék. Egy másik irány a hibatűrő rendszerek világa, vagyis az FT (Fault Tolerance). Jelenleg az ESX 3.5-ben ilyen jellegű támogatás még nem elérhető. Termszetesen továbbra is lehet szoftveres clustering-et alkalmazni a különböző fizikai gépek azonos virtuális hálózatára kapcsolódó virtuális gépei között (DNS, MS Clustering, Linux Clusterek, stb. Lehet próbálkozni Oracle RAC-cal is, működik, de a támogatást ekkor inkább valamely szolgáltató partnertől kérjük, mint közvetlen a RAC gyártójától).

Tesztkörnyezet a bemutatóhoz

Az egyszerűség kedvéért olyan tesztkörnyezetet választottam, amit bárki kipróbálhat otthon is. Nem kell hozzá más, mint 1-2 olyan desktop vagy notebook, melynek a CPU-ja Intel-VT képes.

Az alábbi virtuális gépeket hoztam létre VMware Workstation 6.5.1 alatt:

· SAN01, egy Openfiler gép (iSCSI megosztott hálózati tárolónak fogom használni)

· ESX01 az egyik ESX hoszt

· ESX02 a másik ESX kiszolgáló

· Windows 2003 R2 Standard x32, ez a VirtualCenter kiszolágóia

· Valamint egy gazdagép, ahol a VI kliens fut, illetve a virtuális gépekre lehet kapcsolódni

Természetesen, a valóságban fizikai gépekre telepítünk, lehetőség szerint helytakarékos BLADE szerű gépekre. Az iSCSI helyett inkább FC hálózatokat használunk. A Virtual Center lehet itt is virtuális gép. 5 fizikai szerver felett célszerű külön MS SQL szervert is üzembe helyezni a Virtual Center-be beépített MSDE használata helyett.

Ennek a leírásnak nem célja a teljes hálózat bemutatása, melyet a teszt környezetez használtam. Célom elsősorban az volt, hogy bemutassam, milyen szolgáltatások érhetőek el az ESX szerverekből épített VI3 környezet alatt.

Openfiler 2.3 (NAS/SAN) mint a legegyszerűbb közös iSCSI alapú hálózati tároló

Miután otthon nem igazán szokott lenni FC hálózat és közös pl. EMC lemezrendszer, valamint a HBA kártyákat nem igazán desktop gépekbe szokták tenni így a legkézenfekvőbbnek a mostani teszthez egy bárki számára ingyenesen elérhető Openfiler iSCSI tároló bizonyult.

http://www.openfiler.com/about [1]

A virtuális gépet még csak telepíteni sem kellett, mert az Openfiler honlapjáról többféle VMware image is letölthető volt. A virtuális gépet csak el kellett indítani. Célszerűen hozzáadtam még pár virtuális merevlemezt indítás előtt.

Az Openfiler divatos webes felületen konfigurálható ingyenes NAS/SAN megoldás. Mindenféle protokolon keresztül kínálja a gépbe helyezett fizikai lemezeket. Nekünk az ESX szempontjából az NFS vagy iSCSI tudása jelent segítséget a (ESX kiszolgálók számára) közös (hozzáférésű) tárolók létrehozásában. Mivel a VMFS fájlrendszer egy fürtözött fájlrendszer, így ha egyszerre több kiszolgáló fér hozzá ugyanahhoz a kötethez, a kiszolgáló csak a fájl szinten helyez el lock-okat és nem a kötet szintjén. Így egyszerre több kiszolgáló is ugyanazt a „fizikainak látszó” merevlemezt láthatja.

Az Openfiler ezzel a képernyővel fogad telepítés után.

A hozzáadott lemezen először fizikai partíciót kell létrehozni.

Ezt követi a kötet csoport, azaz a Volume Group létrezása.

A volume group létrehozás után (illeve ezt már korábban kellett volna) kapcsoljuk be az iSCSI szervert, mert csak akkor tudunk iSCSI-ra formázott lemezeket kiajánlani.

Ne felejtsük el az iSCSI target-et beállítani, ezen az IQN-en lehet majd megkeresni a lemezeket az ESX szerverek alól.

Az előbb létrehozott kötet csoport után most már hozzunk létre egy kötetet.

Figyeljünk, hogy a típusa iSCSI legyen!

Végezetül használjuk a LUN mapping részt, ahol a LUN és VOLUME összerendelés történik. Legyen a kötet írható olvasható. A CHAP-ot nem használtam, inkább külön izolált storage hálózatot hoztam létre. Ez fizikai környezetben lehet külön kábelezve is. Az ESX szerver csak 1 CHAP felhasználónév/jelszó párt tud megjegyezni, de támogatja a CHAP azonosítást.

A VirtualCenter háttere: DNS, Microsoft AD (Active Directory)

Mielőtt nekifognánk a Virtual Center telepítéséhez, pár dolgot meg kell vizsgáljunk. Normál vállalati környezetben szokott lenne DNS illetve AD szolgáltatás. Nekem most nem volt itthon, így gyorsan összedobtam ezeket a VirtualCenter virtuális gépen.

A DNS kritikusan fontos az ESX VI környezetben. Ha valami nem megy (HA agent, vagy VI konzol elérés) minden esetben a DNS-re kezdjünk gyanakodni! A hibák 95%-ában a hibás DNS konfiguráció a felelős!

A következő képsort nem szeretném túlmagyarázni, mert nem része a cikkemnek, csak nálam kellett a demó környezet összeállításához.

Minden rendben, működik a DNS feloldás.

Az AD nem kötelező, de használata erősen ajánlott Windows Domain környezetben. Ha a VI3 környezetre később View3-at is tervezünk, akkor pedig kifejezetten hasznos a jogosultsági rendszerhez. Ha nincs AD, akkor a Virtual Center alatti Windows 2003 szerver helyi felhasználóiból gazdálkodhatunk.

Virtual Center telepítése

A következő néhány kép a Virtual Center telepítését tekinti át. Ahogy a cikk elején is említettem, erre a célra külön létrehoztam egy virtuális gépet. Valódi éles környezetben is szokták virtuális gépként létrehozni a VirtualCenter-t. A telepítés esetemben a DNS és AD mellé kerül. A valóságban az AD és DNS összevonható, de a VirtualCenter-t mindenképpen egy külön erre a célra dedikált Windows szerverre tegyük!

Válasszuk a VirtualCenter szerver lehetőséget!

Ahogy említettem, ha 5-nél több ESX-et akarunk felügyelni, akkor ne a helyi MS SQL 2005 expressz változatot használjuk, hanem egy meglévő teljes MS SQL 2005+ szerveren hozzunk létre a VIM számára egy külön adatbázist!

Ha van liszenszünk, már a telepítés elején megetethetjük vele! Az EVAL idő lejárta előtt a liszenszt a VirtualCenter szerveren egy kis eszköz segítségével lehet kicserélni (liszensz tool) a szerviz újraindításával.

Útmutató az ajándék (kölcsön) lóhoz. Sokan nem tudják pontosan mi lesz, amikor lejár a 60 nap? Az adatok természetesen nem vesznek el, de virtuális gépeket nem tudunk majd elindítani az ESX hosztokon. Az ESXi-n amúgy igen, de csak szigetszerűen újra VirtualCenter nélkül.

Becsapós, de ez nem új felhasználót hoz létre, hanem meglévő admin felhasználóra kérdez rá.

Ha még nem lenne, a telepítés során kapunk ajándékba egy .NET FrameWork 2.0-át.

Illetve az említett helyi MS SQL adatbázist.

Kész is van. Most akár a VirtualCenter szerveren, akár távolról is rá tudunk kapcsolódni a Management szerverre.

Virtual Center Server, első lépések (adatközpont létrehozása, fizikai gépek regisztrációja)

A VirtualCenter szerver egyszerű telepítését követően csatlakozzunk a szerverhez pontosan úgy, ahogy korábban az ESX szerverekhez kapcsolódtunk, csak más az IP cím, és itt jellemzően nem root hanem  administrator lesz a felhasználónév (Windows környezet, AD backend).

Sajnos a Virtual Center jelenlegi változata nem tud még Linux-on futni és nem ismeri az LDAP-ot sem, de szerintem csak idő kérdése, hogy teljesen „Microsoft mentes” VMware környezet lesz majd létrehozható. Ezzel is csökkentve a felesleges liszensz költségeket.

Belépés hasonlóan, mint az egyedi szerverek esetén.

No, hát megjöttünk. Az első feladat a hierarchia legmagasabb szintjének létrehozása, az ADATKÖZPONT (DC) regisztrációja. Kevesen tudják, de az adatközpont szab határt például a VMotion-nak, tehát Szegedről-Debrecenbe nem lehet költöztetni leállás nélkül a virtuális gépeket, legalábbis még nem (kivéve, ha transzparens bérelt FC hálózat van a telephelyek közt).

Első feladat a fizikai gépek Virtual Center alá történő regisztrációja.

Mi történik ilyenkor? A korábbi hostd (hoszt démon) leáll, és helyette a Virtual Center démon indul el, és jegyzi be, hogy melyik Virtual Center alá lett bekötve az ESX host.

Innentől kezdve lehet, de nem javasolt a fizikai gépek VirtualCenter megkerülésével történő felügyelete. Figyelmeztet is a rendszer, ha erre készülne valaki (VI klienssel közvetlenül kapcsolódna az ESX kiszolgálóhoz).

Adatközpont kiválasztása.

Egy fizikai szerver jellemzően egy Virtual Center alá tartozik. Ha több Virtual Center-ünk lenne, és a host gépet egy már egy korábbi VC-nek odaadtuk, akkor figyelmeztet, de a host átregisztrálható másik VirtualCenter alá (ilyenkor számolni kell a következményekkel, hiszen különálló hostra butul vissza az a gép olyankor) szóval ez nem javasolt művelet. Célszerűen egy adatközpontban egy Virtual Center fut, és a telepítés előtt tervezéssel indul a feladat (átgondoljuk az igényeket, LAN, FC, stb.)

Ez és a következő képek a hálózat beállításáról szólnak. Erről egy külön cikket írhatnék, itt csak igyekszem összefoglalni a fontosabb szabályokat:

· A HA használatához két független szerviz konzolra lesz szükség

· A VMkernel-nek külön IP címet kell adni, a VMkernel felel a VMotion illetve a IP alapú tárolók kezeléséért. Itt az iSCSI esetén ez fontos, hogy létezzen.

· A Virtual Machine típusú hálózatokat lehet kiválasztani a virtuális gépek esetén.

· Minden egyes host esetén ugyanúgy kell kinéznie a hálózati beállításoknak, ha azokból a gépekből fürtöt akarunk készíteni! Ez nagyon fontos. A felületen kattintgatásnál ügyesebb ezt ESX konfig parancssor segítségével végezni (esxcfg-vswitch)! Erről már nem írok, mert lehet a VI4-ben ez a probléma megoldódik J Amúgy számos ilyen videó található az interneten.

Sokan meglepődnek, de az ingyenes ESXi telepítése során az egyetlen észrevehető különbség a VC alól, hogy a Service Console eltűnik (pontosabban összeolvad a VMkernel-el).

IP címet adok a VMkernel-nek!

A VMkernel esetén nem szükséges Gateway címet megadni, mert a VMkernel csak az ESX gépek közti belső kommunikációért felel. Ezen keresztül meg pl. a VMotion is. Ha IP storage célokra is használjuk (ahogy én is tettem), célszerű a tárolót vele azonos subnet-en elhelyezni, hogy lássák egymást átjáró hiányában is.

Hozzáadom a másodlagos szerviz konzolt is.

A másodlagos szerviz konzol esetén később is meg lehet adni az Gateway IP címét.

Így néz ki a teszt hálózatom. Készen van!

Nagyon fontos, hogy az ESX kiszolgálók órája együtt járjon! Ehhez mindenképpen aktiváljuk és állítsuk be az NTP klienst!

Példámban itt a kfki.hu szerverét használom.

Új fürt létrehozás (VMware HA és DRS beállítása)

A következő lépésekben egy új fürtöt fogok létrehozni.

Az adatközpont definiálása után (nálam itt VMUG) a következő szint a Cluster-ek szintje. Gyakori kérdés, hogy milyen gépeket lehet egy fürtbe szervezni? Röviden a válaszom, az egy processzor családba tartozó gépeket (tehát nem lehet keverni az INTEL-VT és AMD-V technológiákat, azaz nem lehet egy fürtön belül INTEL és AMD processzorral szerelt gép). További korlátozás, hogy a CPU-k utasításkészletének egyeznie kell pl. INTEL esetén. Ezt azonban egy felület segítségével lehet finomítani, vagyis megoldható, hogy a régebbi szerverekhez vásárolt új szerverek processzoraiban megjelent új utasításkészleteket letiltsuk (CPU masking).

Az új fürtvarázsló a VMware HA (magas rendelkezésre állás) és DRS (terhelés-elosztó) szolgáltatások beállításában nyúlt segítséget.

Az RDS működése kapcsán három lehetőség közül választhatunk. Itt az utóbbi kettő jellemző: félig automatizált illetve teljesen automatizált. Félig automatizált beállítás esetén a rendszer csak javaslatokat tesz, hogy mely gépeket kellene átmozgatni a fizikai hosztokról, egyenletesebb terhelés érdekében. Itt a VMware a VMotion technológiát használja a háttérben. A képen található csúszka segítségével lehet „adjust-olni” az ajánlások érzékenységé: agresszív módban már kisebb CPU terhelések esetén is javaslatot tesz a rendszer. Ilyenkor félig automatizált módban a rendszergazda munkakedve alapján tesztre szabható, hogy naponta hány ajánlást van kedve a rendszer üzemeltetőjének feldolgozni (átolvasni). Lusta rendszergazdáknak a konzervatív beállítás a barátjuk. Természetesen a gyártó is tudja, hogy a terhelés elosztás pusztán a számok alapján (CPU%) nem teljesen optimális, a fejlődés az irányba megy tovább, hogy pontosan tudjuk, mi történik a dobozban. Egy komolyabb adatbázis tranzakció vagy egy vírusellenőrzés miatt nem oldódik meg a probléma, ha egy másik gépre mozgatjuk a gépet (ott is megeszi ugyanazt az erőforrást). Tehát olykor szervezési feladatok is szükségesek a rendhez: lehetőleg ne egy időben fusson a vírusirtó, mint az adatbázis tranzakció. Ez csak egy buta nem életszerű példa, de segítségével remélem érthető a DRS lehetséges továbbfejlesztési iránya. Ez a probléma amúgy bármely más hasonló szolgáltatást ajánló gyártónál jelentkezik. A megoldásban a szoftvereknek kell majd üzenniük állapotukról egy jövőbeni API segítségével, melyeket a Hypervisorra épülő management ért, és a mozgassuk / ne mozgassuk döntéseknél felhasználni. Pl. a Microsoft ez ügyben már tett ajánlásokat, de még inkább kísérleti stádiumban jár a probléma megoldás náluk is.

A HA kapcsán számos lehetőség beállítható. Akinek ez nem elég, az ADVANCED beállítások résznél lehet pöcögtetni, hogy hány másodperc után gondolja, hogy kiesett egy host, stb.

Összefoglalás, majd készen van az új fürt.

Én a fürt létrehozása után tettem bele a korábban hozzáadott gépeket, valójában célszerű előbb a fürtöt elkészíteni, majd a gépeket egyből oda regisztrálni.

A gépek (fizikai ESX-ek)  fürhöz való hozzáadáskor egy HA ügynök is települ a gépekre.

A fürt maximum 32 gépből állhat. FONTOS, hogy az első 5 gép őrzi a fürt adatbázisát, ők az úgynevezett „primary node”-ok. Pl, amikor blade-ekre telepítünk és több keretünk van, célszerű elosztani az első 5 gépet a keretek között és nem mindet az első keretből választani, mert annak tápegység hibája esetén a teljes fürt fejre állhat. Tervezési hiba miatt (hiszen ez világosan benne van a dokumentációban).

A HA agent telepítése viszonylag gyorsan végez.

Összefoglalás

Ezzel elkészítettük a virtuális gépeink számára magas rendelkezést biztosító fürtöt. Ugye nem is volt bonyolult? Tényleg nagyjából igaz a marketing blabla, hogy egyetlen pipa a magas rendelkezésre állás beállítása. Minden esetre, aki küzdött már a Linux-HA heartbeat beállítással, az ezt most biztosan nagyra értékeli. A 2003-as MS Clusteringről sokaktól hallom, hogy nem triviális annak beállítása. Igaz, a 2008 szerver esetén ez sokat javult. VMware virtualizált környezetben is támogatott effélét művelni, de szinte itt találkozunk a legtöbb korlátozással (RAW disk, stb). Elnézést, nem akartam keverni a HA és FT-t, de lássuk be hasonló dolgokról van szó, csak a HA esetén van (egy rövid) szolgáltatás kiesés, FT esetén nincs. A szoftveres clustering-gel szemben van egy hihetetlen előnye a VMware HA-nak. Operációs rendszertől függetlenül működik, mindenféle további ráfordítás (programozás vagy konfiguráció) nélkül. Gondoljuk csak át, micsoda előnye van ennek valami olyan kliens-szerver alkalmazásnál, ahol a szerver oldali szolgáltatást fejlesztő cég több milliós ajánlatot ad, hogy a szerver fürt képes tudjon lenni. Ha egyáltalán meg tudják csinálni (pl. valamilyen speciális .NET vagy Delphi egyedi fejlesztés esetén). Minden olyan esetben, ahol az SLA megengedi a szolgáltatás néhány percre való kiesését a VMware HA a barátunk. Azt gondolom ez nem csak nagy, hanem egyre inkább a kis és középvállalatok igényeiben is megfogalmazódik. Ahol heterogén környezetet használnak (Linux és Windows alapú operációs rendszerek egyaránt) a legegyszerűbb működő megoldás a VMware HA szolgáltatás beszerzése.

A HA már a Standard (közepes) változatban is elérhető szolgáltatás. Sokan nem tudják, hogy a kb. 3000 dollár befizetésekor a liszensz megosztható 2 fizikai vas közt (bizonyos vasak esetén), amennyiben a magok száma ezt lehetővé teszi. Tehát, már 1 ESX Standard liszensz segítségével is biztosítható a magas rendelkezésre állás egy két fizikai tagból álló fürt esetén!

A nyugalom ára

Vajon, kb. 740 ezer forintért (mai USD árfolyam alapján) átírja-e egy fejlesztő cég a kliens/szerver alkalmazását cluster baráttá? Vajon, hányszor lehet hétvégi túlórát fizetni ebből a pénzből a rendszergazdá(k)nak, aki(k) a meghibásodott Exhange kiszolgálót állítja(k) vissza éppen a mentésekből? Nekem a nyugodt éjszakáim ennél többet is megérnének, nem beszélve a szolgáltatás kiesése miatti kellemetlenségekről, és pénzben nem kifejezhető szégyenről, amikor az ügyfeleknek magyarázkodni kell, hogy éppen az alaplap vagy a tápegység sült el valamelyik fizikai gépben. Szerintem, a folyamatos szolgáltatás kiesés a mai napig minden szolgáltató cég rémálma, legyen az LAN vagy WAN környezet.

Magyar nyelvű ESX Server 3.5 telepítési útmutató

Ez a rövid bemutató képekben átfutja, hogyan lehet az ESX 3.5-öt telepíteni. A napokban még mindig találkozom olyanokkal, akiknek a telepítéssel kapcsolatos kérdési vannak. A cikk további célja, hogy egy helyen legyen megtalálható az ESX3 és ESX4 telepítése, így a különbségeket/változásokat jól lehet majd látni. Amúgy nem bonyolult a telepítés, a lépések nagyon hasonlítanak egy sima RHEL telepítésre. Ez nem véletlen, hiszen az ESX szerver konzol operációs rendszere ebből származik.

A telepítés első lépéseként tesztelhetjük a CD lemezt, de nem ajánlott, csak az időt húzzuk vele. Én egy virtuális gépként teszteltem, ez ne zavarjon meg senkit (így lehet a legegyszerűbben képernyőképeket készíteni szerverek nélkül), normál esetben fizikai gépre ugyanígy történik a telepítés. Legközelebb, ha minden terveim szerint alakul már pl. az IBM BladeCenter Management webes felületén fogok mutogatni, amint a VI4-et telepítem, remélhetőleg hamarosan.

A kezdő képernyőn a logó megcsodálása után a Next az egyetlen lehetőség.

Valószínűleg a szerverszoba KVM-jén nem magyar billentyűzet fogad.

Egérrel kapcsolatos beállítások, nagyjából mindegy, maradhat a default-on.

Az ESX szervernek nem jellemző a grafikus X felülete, inkább a helyi konzolon szoktunk bejelentkezni vagy jellemzően SSH-n keresztül, akárcsak egy Linux gépre.

A liszensz (vagy licensz?) figyelmes elolvasása után nyomjuk meg a Next-et. Az EULA sokszor átlépésre kerül, hozzáteszem a “mit szabad és mit nem” jellegű kérdésekre sokszor választ kapunk benne. Nyilván nagy része bla, bla, de van benne pár érdekes rész.

A lemezek particionálása után Next. Itt célszerű az “auto” üzemmódot választani, mert jó pár particiót létrehoz a rendszer. A maradék helyet az ESX helyi VMFS fájlrendszernek hozza létre, ahová szintén lehet majd virtuális gépeket elhelyezni. A VMware nem támogatja a helyi lemezeken tárolt virtuális gépeket, így ezeket csak teszt célokra használjuk. A virtuális gépeket mindig valamilyen közös, megosztott tárolón szokás tartani. Ez lehet FC, iSCSI és NFS. Az utóbbi mivel nem blokk elérésű eszköz nem lehet VMFS-re sem formázni. Teljesítmény kapcsán megoszlanak a vélemények, az biztos, hogy az FC +HBA a leggyorsabb megoldás, utána jöhet az iSCSI bár egyesek szerint a hanyományos Linux NFS jobban muzsikál. Kérdés persze akkor, hogy mire formázzuk a távoli lemezt (ext3 vagy XFS, stb.)

A szokásos biztos akarod hogy mindent töröljek képernyő.

Nekem ezeket a particiókat hozta létre a rendszer automata módban. A swap particiót a VMkernel használja a virtuális gépek túlzott memória túlfoglalása esetén. A vmkcore partición található meg újraindítás után a “purple screen of death” utáni kernel dump, melyből ki lehet bogarászni, hogy melyik hardverrész meghibásodása okozta a rendszer váratlan leállását.

Amúgy, aki még nem látott ilyet, annak bemutatom (a starting coredump to disk rész érdekes):

Forrás: http://vinf.net/2008/07/08/psod-purple-screen-of-death/ [1]  (PSOD – Purple Screen of Death)

Windowsnál van kék, web alkalmazásoknál fehér, a VMware a lilát választotta. Hozzáteszem, az utóbbi 2 év alatt még személyesen nem láttam ilyet Persze szándékosan előidézhető, ahogy a blog írója is tette. Vagy egy (fém) csavarhúzó segítségével a CPU foglalat körül kapirgálva.

Boot loader lehetőségek, jellemzően nem használjuk.

Az IP cím beállítása rész. Ez talán az egyik legfontosabb rész a telepítés során. Itt célszerű nagyon figyelni, hogy ne írjunk el semmit, mert utólag bosszantó, ha emiatt nem tudunk távolról csatlakozni a virtuális gépünkhöz.

Ha már itt járunk, tisztázzuk, hol tárolja az ESX szerver ezeket a kulcsfontosságú beállításokat:

Gép neve (hostname)

· /etc/hosts

· /etc/sysconfig/network

Frissítéshez: service network restart

IP címe

· /etc/hosts

· /etc/resolv.conf

· /etc/sysconfig/network

· /etc/sysconfig/network-scripts/ifcfg-vswif0

Frissítéshez: service network restart

Hálózati kártya fizikai címének megváltoztatása (MAC)

· 1. /etc/vmware/esx.conf

· 2. töröld a "/system/uuid" sort

· 3. /etc/sysconfig/network-scripts/ ifcfg-vsiwf0

· 4. Töröld a  "MACADDR" sort

· 5. Ismételd meg mindezt az összes “vswif” (szerviz konzol)  interfészre, ha szükséges

· 6. Indítsd újra az ESX-ed!

Az időzóna beállíátások, nem hatékony módja, ha a Budapestet jelölő kis sárga pontot próbáljuk eltaláni a térképen általános iskolai földrajz ismereteinkre hagyatkozva. A listából választva jóval egyszerűbb a helyzetünk.

Én nem tettem meg, de célszerű felvenni egybő egy dummy felhasználót is, mert a root nem tud belépni távolról SSH-n át kezdetben ( /etc/ssh/sshd_config – PermitRootLogin no ).

Az összefoglalást megtekintve indíthatjuk a telepítést.

A telepítés után egyetlen újraindítás szükséges, és máris munkára kész a rendszerünk. Nekem a telepítés egy HP DL580 (G5) szerveren kb. 15 percig tartott újraindítással együtt. Ügyesebbek a SAN boot-ot választják, és írnak egy scriptet a hálózat beállítására minden gép esetén.

Telepítés utáni újraindítás.

Indul az ESX szerver.

Indulnak a szolgáltatások.

Készen vagyunk! Így néz ki az ESX üdvözlő képernyője. A szokásos ALT+F[1-12] gombokat nyomkodva lehet változatni a helyi konzolok közt. Az ALT+F11-en kapott helyet az ESX információs lapja.

Összefoglalás

Tudom, hogy nem nagy szám ez a cikk, és picit offtopic, de úgy láttam eddig hiányzott egy rövid magyar nyelvű összefoglaló a telepítés menetéről. Bízom benne, hogy akad olyan, aki majd hasznosnak véli. A következő cikkemben a VI3 környezet konfigurációjáról és az ESX szerverek együttes tudásáról lesz szó. Ez alapozó lecke a VI4 megjelenése előtt, hogy jobban tudjak majd utalni a változásokra. Az itt leírtak nem helyettesítik a „VI3.5 Install & Configure (alap) + VCP Workshop” tanfolyamon megtanulható részletes ismereteket, de legalább alapszintű útmutatót nyújtanak.

Kapcsolódó anyagok:

VMware vSphere 4.0 – Configuration Maximums

http://vmwaretips.com/wp/2009/02/25/vmware-vsphere-40-configuration-maximums/ [2]

VMworld Europe 2009

http://www.vmworld.com/europe [3]

VMware Infrastructure 3.5 oktatás – hivatalos VATC tanfolyamok (2009)

http://www.dns-hungary.hu/products/vmware/vmware_education.php [4]

• Check the HOSTNAME entry in /etc/sysconfig/network to the short name
• Check if your FQDN is greater than 30 characters, in which case HA will not configure properly. This is a known bug in VC20 (see KB article 2259).
• Check IP, routing, and DNS for each host.
• Make sure that storage and network are available across the cluster – Ensure that the hosts are not managed directly: perform all host management through VC.
• May want to add nodes to /etc/hosts on ESX Server AND hosts file on VC Server. A better plan would be to use primary and secondary DNS servers.
• Check if Service Console has default gateway defined.
• Verify logs: /opt/LGTOaam512/* and /opt/LGTOaam512/vmsupport/*.
• Check /etc/hosts and /etc/resolv.conf.
• In ESX 3.x the memory reservation is zero, and the limit is “unlimited.” To see this, edit the settings of a virtual machine, click on the Resources tab, and select Memory on the left. To conform to the ESX 3.x defaults, change the settings to a reservation of 0, and check the Unlimited box under limit. After doing this for all virtual machines, edit the settings for the cluster. Disable HA, and then edit the cluser settings again to reenable HA. The current failover capacity should now match the configured capacity.

Alapvetően két megoldás létezik

1. A meglévő Service Console-hoz tartozó vSwitch-hez adunk legalább két NIC-et
2. Dedikálunk egy kölünálló NIC-et egy új vSwitch-hez, amihez aztán egy második SC hálózatot rendelünk

Látszólag egyszerű a dolog, de mindkét megoldásnak vannak erős követelményei.

Teaming

Az első megoldás tűnik a legegyszerűbbnek, azonban ez a felállás magában foglal egy lehetséges Single-Point-of-Failure, nevezetesen a mögöttes fizikai switch-et. Nyilvánvaló, ha mindkét NIC-et ugyanabba a fizikai switch-be kötjük, akkor az adott switch meghibásodása esetén az egész HA redundacia bedől. Emiatt mindenképpen külön-külön switch-be kell kábeleznünk a két Service Console-t. Azonban! Ez a kettőzés megköveteli, hogy a két fizikai port-on FastPort (Etherchannel) legyen konfigurálva, amely két fizikai switch esetében csak akkor lehetséges, ha a switch-ek STACK-elve vannak, erre pedig nem minden switch képes!!

Még egy SC

A második lehetőségünk, hogy használunk egy meglévő vSwitch-et és ezen alakítunk ki a második Service Console-t. A VMware ajánlása, hogy erre nyugodtan használjuk a meglévő VMotion-VMKernel vswitch-et, ami valóban a legegyszerűbb megoldás. Sajna ezzel is van egy kis bibi… A VMotion hálózattal szemben követelmény, hogy ez egy teljesen izolált fizikai hálózat legyen; a HA-ról pedig tudjuk, hogy erősen kötődik a DNS-hez, így rögtön felmerül a kérdés: az a Service Console hálózat, amely a VMotion hálózatot használja hogy az ördögbe fog tudni a DNS-hez csatlakozni? Szerencsére van megoldás: /etc/hosts.

Tehát ha a VMotion hálózathoz szeretnénk kötni a redundáns SC-t ezt így tehetjük meg:

1. alakítsuk ki a VMotion vSwitch-en a második SC-t és adjunk neki IP a vmotion subnet-ből
2. szerkesszük meg az /etc/hosts állomány és kézzel vegyük fel a HA cluster minden tagjának a VMotion subnet beli IP-címét
3. Bizonyosojunk meg arról, hogy az elsődleges SC-nél konfiguráltunk DNS-t és ellenőrizzük, hogy létezik-e DNS host rekord minden node-hoz (itt terménszetesen a management LAN beli IP címet kell használni)
4. szerkesszük meg az /etc/nsswitch.conf állományt, hogy ez legyen benne.
   hosts: files dns

Ennek hatására a HA cluster mindkét SC irányba képes lesz név szerint elérni a node-okat. Az nsswitch beállítása miatt előszőr a hosts file-ból fog pingelni (ekkor használja a VMotion-re kötött SC-t), és ha ez nem megy, akkor fordul a DNS-hez (mikor is a mgmt lan-hoz kötött SC-t használ).

Azt csiripelik a madarak…

hogy az ESX 3.5 szerver (és VI3 infrastruktúra) akár virtuális gépként is működik a nemrég megjelent VMware Workstation 6.5 alatt. Ez magában is érdekesen hangzik, hiszen a virtuális gépek nem mindig használhatóak további virtualizációs környezet létrehozására. Ez amolyan virtuális gép a virtuális gépben kérdést vet fel. Lehet próbálkozni, bizonyos korlátozásokkal ez-az összejöhet (VMware alatt Xen?) bár nem sok értelme van, és a performancia igencsak elúszik. Azonban oktatási vagy érdeklődési céllal nyerő lehet egy gépen működtetni egy komplett virtualizációs rendszert (pl. VI3).

Kezdeti nehézségek: Windows 2008 (x64) host + VMware Workstation 6.5 beta (91182) nem nyert

Dual boot-os gépem WinXP/Win2008 (x64)-at tartalmazó fizikai partícióin próbálgattam a VMware Workstation 6.5-öt. Win2008 x64 alatt elég pocsékul szerepelt: simán kiakad a VMware 6.5 konzol, ha véletlen magyar billentyűzetről nyomok be neki egy karaktert. A gépem tudja az Intel-VT-t, de mégsem látszik ennek támogatása, simán kiteszti a csúnya „kis sárga háromszöget”, hogy nem biztos benne, hogy az x64-es Linux guest menni fog. Innentől már ismerem a járást, tuti nem fog menni, nem viccből jelenik meg a figyelmeztetés az új virtuális gép létrehozásakor. Miközben indult a virtuális gépem Win2008/x64 + VMware 6.5 beta kombinációval, egyszer csak egy szép kék halál szórakoztatott (gazdagép Windows 2008 szinten). Biztos valamit én csinálok rosszul, de inkább feladtam, próbálkozzunk a jól bevált Windows XP alatt.

ESX virtuális gép létrehozása (Windows XP x32 + VMware WS 6.5)

Az internetes forrásokat olvasva az alábbiakra jöttem rá: mivel az ESX egyfajta Linux származék, célszerű a létrehozandó virtuális gép operációs rendszerének Linux-ot választani. A kapcsolódó cikkek kizárólag a 64-bites Linux-ot javasolják. Memóriát adjunk neki 1GB-ot (az ESX szervernek), a lemezeknél célszerű az SCSI-t előnyben részesíteni (hiszen a korábbi ESX verziókban csak ez volt, még a SATA nem volt támogatva).

Ami a lemez méretét illeti, 20GB virtuális SCSI lemez elegendő lehet 1-2 gép tesztelésére, persze ízlés szerint akár többet is adhatsz. Az előre inicializált (lefoglalt) lemezek jóval (!) gyorsabbak, bár több helyet igényelnek, ezért az így létrehozott gép mozgatása nehézkesebb lesz.

A beta termék debug módja lassú: várjuk a teljes verziót vagy bináris csere (hack)?

A telepítést követően az alapértelmezett „C:\Program Files\VMware\VMware Workstation” mappában találsz egy ”vmware-vmx.exe” valamint egy „vmware-vmx-debug.exe”-t. Alapértelmezetten a debug-os bináris működik. Amikor indul egy virtuális gép, figyelmeztet, hogy vigyázat, debug módban vagyunk. Itt azt írja, nem is lehet kikapcsolni azt:

Nyilván a debug mód probléma a Server 2.0-ás változatában is jelentkezik. Még nem próbáltam, de úgy látom, a binárist kicserélve megszabadulhatunk a debug mód okozta lassulástól.
Guide: how to make server 2.0b1 usable: http://communities.vmware.com/message/828241
Running Vmware Esx Server On Workstation: http://www.petri.co.il/forums/showthread.php?t=24497
Ez jól hangzik – nem próbáltam még: „rename the vmware-vmx-debug.exe file (C:\Program Files\VMware\VMware Workstation), copy vmware-vmx.exe to new name of vmware-vmx-debug.exe and restart workstation, debug mode is gone….”

ESX szerver virtuális gép létrehozása után VMX ácsolás indítás előtt

Az ESX szerver virtuális gép indítása előtt szabadulj meg a virtuális floppy és hangkártyától, azokkal csak a gond lesz később.

Ha ez megvan, nyisd meg a VMX fájlt, ami a virtuális hardvert leírja.

A neten talált instrukciók szerint az „ethernet0.virtualDev” bejegyzést is hozzá kell adni, de az már benne volt nekem, tehát csak a fájl végére kellett csapni ezt:

monitor.virtual_exec = “hardware”

monitor_control.restrict_backdoor = “true”

E mágikus kifejezések után azt ígérik, zökkenőmentesen fog futni az ESX szerver virtuális gépünk a VMware workstation 6.5 alatt. Elég nagy a sumákolás az interneten ezekről a kapcsolókról, pár perc alatt nem találtam meg, hogy pontosan mire valók, azon kívül, hogy ESX-et futtassunk (lehet ez valami szándékos reklámfogás-kiskapu?). Mindegy, megy.

ESX szerver 3.5 telepítés – ismerős, akár bármely Linux disztribúció

Az ESX telepítő nagyon hasonlít egy bármely Linux rendszer telepítőjére (különösen RHEL).

A csomagok telepítése közben nagyon sok ismerős Linux alap-csomag neve szaladgál a képernyőn, de közben nem csak a címsorból tudjuk, hogy éppen ESX-et telepítünk, a csomagok nevei is gyakran kezdődnek VMware-esx-szel. A virtuális gép telepítése kb. 10 perc volt.

Indul az ESX szerver: karakteres felület – lokálisan ne piszkáld!

Induláskor a szokásos GRUB köszönt:

A System Interface-ek elhasalnak, ez a hiba az összes internetes cikkben megvolt, tehát nem hiba. Talán nem tetszik neki, hogy virtuális gépként fut.

Amikor elindul, a lényeget kiírja a képernyőre, hostnév, IP cím.

Alapvetően az ESX konzolon ritkán kell nyomkodni, hiszen arra ott a VI3 kezelőfelület. Ennek ellenére természetesen be lehet lépni a konzolon is, akár bármely linux alapú masinára.

Mivel a notebook-omon épp nincs DNS szerver (miért is lenne?), marad a „poormansdns”, vagyis a hosts fájl. Windows XP alatt ez a jól megszokott C:\WINDOWS\system32\drivers\etc\hosts fájl. Szépen beleírtam a gép nevét:
10.10.1.10 esx1.nyitolap.hu

ESX szerver hálózaton át elérhető web-es felület

A futó ESX szerverre hálózaton is rá lehet jelentkezni, akár egy internet böngésző segítségével is. Az elején van egy kis küzdelem az SSL tanúsítványokkal, de ha ügyesen nyomkodod a gombokat összevissza (többnyire az „elfogadom, csak hagyjál már!”-ra kattintva) előbb utóbb bejön a VMware Server 2.0-hoz hasonló élményt nyújtó ESX szerver web-es felület.

A szerver IP címén ez fogad:

Máris szól, hogy jobban teszem, ha Internet Explorer-t használok! Ejnye, a VMware Server 2.0 felülete nem piszkált emiatt, pedig a bal oldali kék maszattól (víz?) eltekintve kb. így néz ki.

A felületen nem sikerült új virtuális gépet létrehozni, ez inkább csak monitorozási célokra van, de majd még utána nézek. A cím a https://esx1.nyitolap.hu/ui/ volt, ahol elértem, ez is nagyon hasonló az ingyenes Server 2.0-hoz.

Felügyelet: VMware Infrastucture Management – a gazdag ember konzolja

Hogyan lehet új virtuális gépet létrehozni? Sokféleképpen, az egyik (legnyilvánvalóbb) módszer az ESX-hez járó konzol segítségével, a VMware Infrastucture Management-tel. Ezt a szerver (esx-3.5.0_Update_1-82663.iso) mellett szintén le lehet tölteni (VMware-VIMSetup-2.5.0-84782.iso).

A telepítés közben látszik, hogy ez komoly elosztott rendszer lesz, hiszen a kezelőfelülethez adatbázis is jár. Nocsak, SQL szerver 2005 express edition! Haha! Biztos nem volt más: jót tesz ez a Microsoft VMware barátságnak – tessék csak használni egymás megoldását!

A belépésnél a „localhost” itt azt jelenti, hogy a helyi management szerverre lépek be, amiről elérhetőek a távoli ESX szerverek.

A következő képen nem a népszerű torrent kliens új verziója látható (ahogy viccesen beszólt Márió kollégám, amikor mutattam neki), hanem az ESX szerverek (szerver) központi kezelőfelülete.

Nálam most kb. ez a helyzet, illetve még egyszerűbb: a VI client a gazdagép XP-m, a Host pedig egy Virtuális gép. Ilyen rajz nincs?

Mára ennyi elég lesz, fut az ESX, elérhető a VI3 felületről.

Legközelebb az ESX üzemeltetési tapasztalataim osztom meg veletek!

Kapcsolódó hivatkozások, felhasznált irodalom:

Running ESX 3.5 and 3i Under VMWare Workstation 6.5 Beta Build 91182
http://vinf.net/2008/05/18/running-esx-35-and-3i-under-vmware-workstation-65-beta-build-91182/

ESX 3.5 is running on Workstation 6.5 Build 91182 !!!
http://www.ntpro.nl/blog/archives/470-ESX-3.5-is-running-on-Workstation-6.5-Build-91182-!!!.html

Note – you need to select an x64 Linux version from the VM type drop down, if you have to go back and change it via the GUI after you’ve edited the .vmx file it overwrites the Ethernet card “e1000″ setting to “vlance” so you need to edit again otherwise the ESX installer won’t find a compatible NIC and won’t install.
ethernet0.virtualDev = “e1000″
monitor.virtual_exec = “hardware”
monitor_control.restrict_backdoor = “true”

New VMWare Workstation 6.5 Build(s) and ability to run ESX 3.5
http://vinf.net/2008/05/18/new-vmware-workstation-65-builds-and-ability-to-run-esx-35/
I’ll be trying this out in the coming week and hopefully will be able to get ESX running on my laptop under VMWare Workstation (very handy mobile demo platform).

Gondoljuk csak végig, milyen előnyökkel járna, ha egy vállalkozás (adó-, villamos energia- vagy virtualizációs támogatás formájában) kedvezményt kaphatna, amennyiben csökkentené villamos energia felhasználását, ezzel együtt hozzájárulna környezetünk védelméhez. Kíváncsian várom, mikor lesz esetleg valamilyen visszhangja a tőlünk nyugatra már régóta megfigyelhető szerver konszolidációnak, és energiacsökkentéseknek.

Részletek itt: http://www.vmware.com/solutions/consolidation/green/