2011. augusztus 29., hétfő

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>

2011. augusztus 15., hétfő

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).

2011. augusztus 12., péntek

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:

2011. augusztus 11., csütörtök

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.

2011. augusztus 9., kedd

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 GB96 GB
vSphere Enterprise 32 GB64 GB
vSphere Standard 24 GB32 GB
vSphere Essentials+ 24 GB32 GB
vSphere Essentials 24 GB32 GB
Free vSphere Hypervisor 8 GB32 GB
vSphere DesktopUnlimitedUnlimited