VMware Data Recovery 2.0

A vSphere 5 bejelentésével egy időben a VMware Data Recovery-nek (a továbbiakban VDR) is elérhetővé vált egy új verziója. Ráadásul a fő verzió szám ugrott egyet, így akár arra is gondolhattam volna, hogy egy sor újdonság, fejlesztés lesz benne. Mivel az előző verziót élesben használom egy kis környezetben, és mint egy régebbi bejegyzésben írtam, nagyon hiányzik egy riportoló, mail küldő funkció, ezért ez volt az első amit az új funkciók között kerestem. Erről egy kicsit később.
A telepítésről nem akarok részletesen írni, mivel az semmit nem változott. Az upgrade-re sem kell sok betűt pazarolni, mivel ha a régi környezet mentéseit tartalmazó diszkjeit (vagy megosztásait) lecsatoljuk, majd az új appliance-hez felcsatoljuk, akkor tulajdonképpen készen is vagyunk.

Akkor vegyük sorra, mi változott:

• 64 bites CentOS 5.5 operációs rendszeren fut az Appliance.
• Növelték a mentések, integritás ellenőrzések sebességét. Aki már használta, az tudja hogy főleg az utóbbi esetében szükség is volt rá. 100-200GB mentés esetében képes volt órákig tekergetni a diszket úgy, hogy visszajelzés csak arról volt, hogy éppen történik valami. De hogy éppen hol tart, kb. mennyi idő van még hátra, stb. arról mélyen hallgatott.
• A megszakadt integritás ellenőrzést most már tudja folytatni. Eddig, ha valami miatt nem végzett, minden kezdődött előröl. Az ellenőrzés során nem csak azt ellenőrzi, hogy az adatok rendben vannak-e, hanem a megőrzési szabályoknak megfelelően törli a feleslegessé vált mentéseket.
• Most már van egy kis beleszólásunk abba, hogy ezek az ellenőrzések mikor fussanak le. Ha nem állítunk be semmit, vagy a Default-ot választjuk, akkor minden hétköznap délelőtt kilenc és délután öt között fog futni

• Az ellenőrzések futtatása alatt is képes menteni vagy visszatölteni
• Van email küldési lehetőség. Az smtp szerver beállítása semmiben nem különbözik más rendszerekétől. Ezen kívül pedig csak azt tudjuk beállítani, hogy mely napokon és hány órakor akarjuk kapni a levelet. Ennyi. A levél tartalma logikusan felépített, és minden fontos információt tartalmaz. (Appliance paraméterek, futott jobok, mentett gépek, sikertelen mentések, mentési idők, destination-ök állapota)

• Lehetőségünk van arra, hogy futó backup job esetében felfüggesszük a jobot olyan értelemben, hogy amit éppen ment azt még befejezi, de új virtuális gépek mentésébe már nem kezd bele

Néhány tulajdonság, képesség ami nem változott:

• Továbbra is a kisebb környezetek mentésének ideális eszköze. A hangsúly a kisebben van, mivel továbbra is élnek a korlátok (egy appliance max. 100 gépet képes menteni, egy vCenteren max. 10 appliance lehet, max. 2 destination tartozhat egy VDR-hez, és ezek mérete is korlátos)
• Dinamikusan képes új gépeket is menteni, amennyiben datacentert, clustert, vagy foldert jelölünk ki. Ilyenkor az adott helyre bekerült új gép mentése automatikusan megtörténik a következő futásnál.
• Rendkívül rugalmas retention policy (léteznek előre beállított sablonok, de ha kell mi magunk állítjuk be, hogy hány darabot őrizzen meg a legutolsó mentésekből, mennyit a heti mentésekből, a haviból, negyedévesből, évesből)
• A mentési ablak is csak úgy állítható, ahogy az ellenőrzéseket is tudjuk ütemezni. Azaz korlátozhatjuk egy adott időszakra, de pontosan nem tudjuk megmondani, hogy mikor történjen a mentés
• Külön kliens program telepítése után képes file szintű visszaállításra is (itt a telepítés egy .exe file bemásolását jelenti csupán)
• Tudtam, hogy valami fontosat elfelejtek: a nagyon jó deduplikációs  képességet

Mindenki döntse el magában, hogy ez így megérdemli-e a 2.0-ás verziót...

VMware környezet és a TSM BA Client 6.2.3.x

A közelmúltban lehetőségem volt részleteiben tesztelni a Tivoli Data Protection for VMware-t. De most nem a teszt eredményéről szeretnék írni, hanem a fenti TSM kiegészítéshez kötelezően használandó 6.2.3.x kliensről. Egy régebbi bejegyzésben volt már arról szó, hogy a jól működő 6.2.2.x kliens után, ha áttérünk a 6.2.3.x-re, akkor egy igen kellemetlen meglepetésben lesz részünk. Pontosabban csak abban az esetben a mentéseinket fizikai szalagokon (tehát nem VTL) tároljuk. A jelenség az, hogy visszaállításkor minden 128MB után a kliens mintegy 2 percig elgondolkodik, majd újabb 128MB, és így tovább egészen a visszaállítás végéig. Könnyű belátni, hogy egy átlagos virtuális szerver esetében is ez mennyire le tudja lassítani a visszaállítást.
A tesztelés során többek között ennek a viselkedésnek az okára is kíváncsi voltam, illetve szerettem volna megtudni, hogy orvosolható-e ez.Mint majd láthatjátok részben igen.

Nézzük előbb a fenti fura viselkedés okát. A 6.2.2.x verzióban ha megnézzük egy virtuális gép esetében, hogy a TSM milyen és mennyi file-t tárol le, akkor a következőt tapasztaljuk:

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\BUDATS02.ovf

Stored Size: 6,715

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\Hard Disk 1\JOB026000001\MBLK0000.DAT

Stored Size: 40,968.00 M

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\Hard Disk 1\JOB026000001\MBLK0000.NCTL

Stored Size: 369

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\Hard Disk 2\JOB026000002\MBLK0000.DAT

Stored Size: 18,599.33 M

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\Hard Disk 2\JOB026000002\MBLK0000.NCTL

Stored Size: 385

Látható, hogy egy két diszket tartalmazó gép esetében összesen öt file kerül a szalagokra. Egy .ovf file, a diszkek, illetve diszkenként egy un. kontroll file. Ez így a visszaállíthatóság szempontjából optimális megoldás, hiszen egyetlen pozicionálással egy teljes diszket el tud olvasni a TSM szerver a szalagrol.

Mivel a TSM 6.2.3.x-et fel kellett készíteni az inkrementális mentések tárolására is (persze ehhez szükséges a TDP is, de ez most nem fontos), ezért az IBM megváltoztatta a virtuális gépek tárolási módját. Nézzünk egy részletet a fenti géphez kapcsoló mentés szalagon található file-jaiból.

Client's Name for File: \NODE1\SNAPSHOT_001000000_2011091-3131944\Hard Disk 1\JOB001000001\MBLK0000-.DAT

Stored Size: 128.02 M

Client's Name for File: \NODE1\SNAPSHOT_001000000_2011091-3131944\Hard Disk 1\JOB001000001\MBLK0001-.DAT

Stored Size: 128.02 M

Client's Name for File: \NODE1\SNAPSHOT_001000000_2011091-3131944\Hard Disk 1\JOB001000001\MBLK0002-.DAT

Stored Size: 128.02 M

Client's Name for File: \NODE1\SNAPSHOT_001000000_2011091-3131944\Hard Disk 1\JOB001000001\MBLK0003-.DAT

Stored Size: 128.02 M

Látható, hogy a tárolás szempontjából lényegesen megváltozott a helyzet. A fenti virtuális gépet  nem 5, hanem közel 1000 darabban tárolja a TSM szerver. (Minden egyes darabhoz tartozik egy kontroll file is, valamint a 60GB-ot kb. 480 db 128MB-os darabban tárolja)
Ennek kivédésére a legjobb megoldás az lenne, ha a fizikai szalagokat lemezes pool-lal tudnánk helyettesíteni, hiszen ott kevésbé okoz gondot a nagy számú file, mivel nem gond a pozicionálás. De mi van, ha ez nem lehetséges? Egy új, dsm.opt-ba írható opcióval lényegesen fel tudjuk gyorsítani a visszatöltést. Ehhez előbb létre kell hoznunk a TSM szerveren egy új lemezes pool-t (legyen MC_VCB_CONTROL), majd pedig a policy domain-ban egy új management class-t. A gyorsítás lényege, hogy a kontroll file-okat nem a szalagon tároljuk a feldarabolt diszkek között, hanem diszken. Így, ha a MAXNUNMP értékét megfelelően állítjuk be, akkor visszaállításkor a TSM szerver a gyors lemezes pool-ból ki tudja olvasni a kontroll file-okat.
A dsm.opt file a következő sort kell beszúrni:

VMCTLMC   MC_VCB_CONTROL

Számomra a végkövetkeztetés az, hogy ha nem akarjuk használni a TDP for VMware-t, akkor maradjunk inkább a 6.2.2.x verziójú kliensek használatánál. Ezzel nem csak a fenti problémákat tudjuk elkerülni, hanem nyilvánvalóan a mentés is gyorsabb lesz.

VMware Syslog Collector használata vSphere 4 környezetben

Az ötös verzió egyik újdonsága, hogy saját syslog gyűjtő szolgáltatást tartalmaz, azaz minden külső alkalmazás nélkül elérhetjük, hogy a hostjaink logját egy központi helyen tároljuk. Persze ezt eddig is megtehettük a vMA segítségével, de aki Windows környezetben érzi jól magát (mint én), annak ez nagy segítséget jelent. (Tudom, hogy ebben a körben többségben vannak a Linux hívők és ismerők, de én már azt hiszem így maradok)

Mivel a Syslog Collectornak van vCenter független telepítési módja, azért jött az ötlet: mi lenne ha a meglévő vSphere 4 környezet logjait is már ezzel gyűjtögetném egy helyre. Erre igazából csak egy 64 bites, elegendő szabad diszk kapacitással rendelkező szerverre van szükség, hiszen az egész nem más mint egyetlen szolgáltatás, ami nem is kér sok erőforrást.
Az egyelőre nem tiszta számomra, hogy licence szempontjából ez rendben van-e, de kipróbálni akkor is érdemes.

A telepítés nagyon egyszerű.
Indítsuk el a vCenter 5 telepítőjét, majd onnan a VMware Syslog Collector telepítést.

A szokásos üdvözlő és egyéb képernyő után megadhatjuk a telepítés alap könyvtárának és a logok tárolásának helyét.

A Repository helyét szabadon megváltoztathatjuk, de arra ügyelni kell, hogy a könyvtárstruktúra maradjon meg, mivel az feltétele a helyes működésnek.

Itt válasszuk a Stanadalone módot. Utána már csak a default portokat kell elfogadnunk, valamint hogy milyen IP címen akarjuk elérni a Syslog szervert. (Ha esetleg több IP címe lenne a szervernek)

Ha mindez megvan, akkor a telepítés néhány másodperc alatt megtörténik. Ezután már csak annyi a dolgunk, hogy a hostokon beállítsuk a most telepített Syslog szerver IP címét.

A beállítás után, ha visszanézünk a Syslog szerverre, akkor láthatjuk a beállított mappában minden Host egy külön almappába küldi a logokat.

Az egyes logok megnyitása után annyi furcsaság látszik, hogy a logbejegyzések közötti elválasztó karakter nem az új sor, hanem a <166> karakter sorozat. Ahhoz, hogy olvasható legyen a log, ki kell cserélni a <166> stringet egy új sor jelre. Pl. a Notepad++ esetében a \n szekvenciára. Így már olvasható az eredmény:

Tehát mielőtt nekikezdenénk a nagy upgrade folyamatnak, már előtte élvezhetjük a vSphere 5 egyik újdonságát.

Egy kis kiegészítés. Amennyiben utólag szeretnénk módosítani az egyes log file-ok méretét, illetve a megmaradó rotációk számát, akkor az operációs rendszertől függő helyen lévő vmconfig-syslog.xml file-t kell szerkeszteni.

Az .xml helye és tartalma:

Windows 2003 –> C:\Users\All Users\VMware\VMware Syslog Collector\vmconfig-syslog.xml
Windows 2008 –> C:\ProgramData\VMware\VMware Syslog Collector\vmconfig-syslog.xml

<defaultValues>
<port>514</port>
<protocol>TCP,UDP</protocol>
<maxSize>2</maxSize>
<rotate>8</rotate>
<sslPort>1514</sslPort>
</defaultValues>

VMware vSphere Health Check Report v5.0.0

Ha már az előző bejegyzésben szó esett a vCheck scriptről, ami a PowerCLI-t kedvelőknek ad segítséget a rendszerük feltérképezésére, akkor ejtsünk szót a másik, nagyon régóta fejlesztett eszközről is, a VMware vSphere Health Check Report-ról is. Ezt Perl-ben fejleszti William Lam, és már a 38-as verziójánál tart. Ez futtatható vMA-ból, de ha feltelepítjük a VMware vSphere CLI-t, akkor akár Windows alól is.
Futás közben jelentősen leterheli a Windows-t, így arra a fél órára érdemes minden más tevékenységet szüneteltetni. Az output egy .htm file, ami a környezet méretétől függően elég nagyra is meghízhat. (kb. 40 Host és kb. 400 VM esetében 3-4MB).

Itt részletes leírást kapunk a lehetséges paraméterekről, ötleteket a használat módjával kapcsolatban, illetve script tudásáról is kaphatunk egy átfogó képet.
Külön fórum tartozik hozzá, ahol a felhasználók a fejlesztő felé jelezhetik problémáikat, fejlesztési ötleteiket, stb.

Ami még érdekesség, hogy akár vSphere 5 környezetben is futtathatjuk, a fejlesztő felkészítette néhány, csak ott lévő képesség riportolására is (storage DRS).

PowerCLI vCheck 5.40

Nem tudom, ki milyen eszközt használ arra, hogy gyors áttekintést kapjon a virtuális környezete állapotáról, értesüljön a hibákról, lássa mi történt mostanság (ha többen adminisztrálnak) a virtuális gépek terén, stb. Mivel még a VMware megismerése előtt szívesen foglalkoztam Powershell-lel, nagyon örültem amikor láttam, milyen aktív közösségi élet folyik a PowerCLI terén. Így arra gondoltam, majd PowerCLI lesz az alapja annak a napi riportnak, amit készítek. Még mielőtt igen nagy energiát fektettem volna bele, belebotlottam Alan Renouf nagyon hasznos és nagyon sok mindenre kiterjedő scriptjére, a vCheck-re. Rendületlenül fejlődik a script, nem csak Alan által, hanem a közösség tagjai is legalább ötlet szinten hozzájárulnak.  Nem sorolnám fel, hogy milyen lekérdezéseket hajt végre, akit érdekel töltse le innen, és akár a futtatása nélkül (a script elejének elolvasásával) is meggyőződhet a tudásáról.

Használatának feltételei:

• Powershell 2.0
• VMware vSphere PowerCLI 4.1 U1
• VMware vCenter Update Manager PowerCLI 4.1 (opcionális)

A script változtatás nélkül egy HTML formátumú levelet kreál, és küld el a megadott címre, címekre. A kényelmesebb használat érdekében két módosítást végeztem el.

• A riportot a levélben mint csatolt állományt küldöm el.
• Beintegráltam a vSphere kliensbe, így mindig az előző éjszakai állapotot onnan is meg tudom tekinteni

Ahhoz, hogy csatolt állományként kapjam a riportot, módosítani kellett a Send-SMTPmail eljárást a következő módon:

function Send-SMTPmail($to, $from, $subject, $smtpserver, $body, $att1) {
    $mailer = new-object Net.Mail.SMTPclient($smtpserver)
    $msg = new-object Net.Mail.MailMessage($from,$to,$subject,$body)
    $mailer.useDefaultCredentials = $true
    $att = new-object Net.Mail.Attachment($att1)
    $msg.Attachments.Add($att)
    $msg.IsBodyHTML = $true
    $mailer.send($msg)
}

A tényleges küldésnél pedig:

if ($SendEmail) {
    Write-CustomOut "..Sending Email"
    $Filename = "C:\tmp\" + $VIServer + "vCheck" + "_" + $Date.Day + "-" + $Date.Month + "-" + $Date.Year + ".htm"
    $MyReport | out-file -encoding ASCII -filepath $Filename
    send-SMTPmail $EmailTo $EmailFrom "$VISRV vCheck Report" $SMTPSRV "Lásd a csatolt állományban!!" $Filename
}

A vSphere kliens integráció egy kicsit trükkösebb, de mint itt olvasható nem lehetetlen. Érdemes megcsinálni, mert praktikus, és milyen jó látni, hogy egy saját plugin is van a vSphere kliensben:)

  Végül egy részlet a riportból:

vSphere Licencing Advisor

Miután végleges lett az új licence konstrukció, a VMware letölthetővé tette a tárgyban szereplő toolt, amivel mindenki saját maga ellenőrizheti, hogy a meglévő környezetét mekkora plusz költséggel tudná vSphere 5-re upgrade-elni. Szerencsés esetben persze ingyenesen, de az előző bejegyzés alapján látható, hogy lesznek vesztesei az új konstrukciónak. A tool letölthető innen.

A telepítés ettől egyszerűbb nem is lehetne (illetve de, ha telepíteni sem kellene). Indulás után meg kell adni a vCenter szerver nevét vagy IP címét, valamint a bejelentkezési adatokat. Ha több vCenter szerverünk van, akkor egy kis .txt file-ban is lehetőségünk van a szerverek felsorolására, majd a tool-lal beolvastathatjuk.
Az infrastruktúra méretétől függően néhány perc alatt kész is van a kimutatás. Mielőtt az eredményt megtekinthetnénk, az alábbi információt jeleníti meg, ami segít a verziók közti eligazodásban.



Az eredmény egy könnyen áttekinthető táblázat, amelyben néhány alap információt láthatunk. Köztük a lényeget: a meglévő licenceink alapján mennyi vRAM használatára vagyunk jogosultak, illetve jelenleg mennyit használunk.

Pozitív változások a vSphere 5 licencek terén

A július 12-én történt vSphere 5 bejelentés körül támadt nagy öröm mámort csupán egyetlen negatív hír árnyékolta be. Ez a hír pedig nem ám valami régen várt funkció hiánya volt, hanem a licenc struktúra megváltoztatása. Nevezetesen a vRAM alapú licencelés bevezetése.

Miért is váltott ki ellenérzést a meglévő, vagy éppen a virtuálizációt a közeljövőben tervező felhasználók között? Természetesen azért, mert könnyen belátható módon nagyon sok infrastruktúra esetében az áttérés az 5-ös verzióra jelentős többlet költséggel járna. Vegyünk egy egyszerű példát. 2 darab szerver esetében (egyenként 2 darab 4 magos processzorral valamint egyenként 256GB RAM-mal számolva) elegendő 4 darab Enterprise Plus licence vásárlása vSphere 4 alkalmazásakor.
A bejelentés szerint négy darab vSphere 5 Enterprise Plus licence 4*48GB vRAM használatát tette lehetővé. Az összesen 192GB vRAM. Ahhoz, hogy a szervereinkben lévő összes RAM-ot kihasználhassuk, ahhoz még további licencek vásárlása szükséges.
Bár a VMware indokait is meg lehet érteni, a felhasználók számára ez egy elég barátságtalan lépés volt. Meg is teltek a különböző fórumok, blogok az ezzel foglalkozó hozzászólásokkal. Olyanok is elhangzottak, hogy  inkább akkor Hyper-V vagy Xen, mert az lényegesen olcsóbb. Persze kevesebbet is nyújtanak, de ha egy adott költséget nem lehet túllépni, akkor nincs mit tenni.
Úgy tűnik, ezek a negatív hangok eljutottak a megfelelő helyre is, mert hat nappal ezelőtt a VMware bejelentette, hogy bár a vRAM szerinti licencelést megtartja, de módosítja az egyes licencekkel együtt használható vRAM nagyságát. A példában vázolt konfigurációt még így sem lehet teljes mértékben kihasználni a négy darab Enterprise Plus licence vásárlásával, de azért már sokkal kedvezőbb a helyzet. Ha hozzávesszük, hogy a fenti fizikai memória egy szerverben még elég ritka (256GB), így már a felhasználók igen nagy százalékának nem jelent költség növekedést a vSphere 5-re való áttérés.
Bár a teljes igazsághoz hozzátartozik, hogy minél alacsonyabb licence konstrukcióval rendelkezik valaki (pl. Essentials), annál nagyobb esélye van arra, hogy az áttérés csak plusz licence vásárlásával oldható meg. Így meglepő lenne, ha a módosítások hatására teljesen megszűnne a felhasználói panasz áradat.

A lenti táblázatban az eredeti és módosított értékek láthatóak.

vSphere Edition	Previous vRAM  Entitlement	New vRAM Entitlement
vSphere Enterprise+	48 GB	96 GB
vSphere Enterprise	32 GB	64 GB
vSphere Standard	24 GB	32 GB
vSphere Essentials+	24 GB	32 GB
vSphere Essentials	24 GB	32 GB
Free vSphere Hypervisor	8 GB	32 GB
vSphere Desktop	Unlimited	Unlimited