vmware felhasználói közösség

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!

Comments are closed.