2011. július 20., szerda

VMware View for Android

Azt hiszem, már sokan várták, hogy iPad után mikor lesz Androidon is elérhető a View kliens. Ez az idő most jött el. Nekem üröm az örömben, hogy csak tableten érhető el, telefonon nem. Remélem ez hamarosan meg fog változni.

Két link:

Android Market: https://market.android.com/details?id=com.vmware.view.client.android&feature=search_result

A fejlesztők oldala: http://blogs.vmware.com/euc/2011/07/android-tablets-now-have-an-awesome-view.html

2011. július 19., kedd

Hibás VMware Data Recovery működés

Bár a virtuális gépek mentésére használt elsődleges eszköz a TSM, bizonyos esetekben jól meghatározott gépek körére tökéletes megoldás nyújthat a VDR is. Főleg, hogy az 1.2.0-ás verzió már egészen megbízhatóan működik. Most persze ellentmondtam a bejegyzés címének, de tényleg ez az igazság. Hogy néha mégis történik egy kis gubanc? Melyik termékkel nem?

A VDR egyik nagy hiányossága, hogy nem képes üzeneteket küldeni a mentések státuszáról. Éppen ezért fordulhatott elő, hogy néhány napig a backup jobok nem futottak le. Ez onnan derült ki, hogy folyamatosan ellenőrzöm a snapshotok méretét, korát, és az egyik mentendő szervernél feltűnt, hogy a VDR által készített snapshot még mindig létezett. Hogy pontosan mi történt, az már nem fog kiderülni. De az biztos, hogy a VDR már nem törölte a saját maga által kreált snapshot, a mentéshez saját magához felcsatolt diszkek még mindig ott voltak, illetve a backup sem futott attól az eseméyntől kezdve.

Gyors keresés a Neten, és a következő KB cikkhez jutottam el. Bár a körülmények nem voltak teljesen azonosak, de mégis kecsegtetett némi reménnyel.
A cikkben foglaltaknak megfelelően letöltöttem a fixdeletable.py Perl scriptet, bemásoltam a virtuális gép folderébe, majd futtattam.







Látható, hogy bizonyos vmdk file-ok esetében végre is hajtotta a módosításokat (törölhetővé tette a snapshotokat). Ezután létrehoztam egy snapshotot, majd a snapshot manager-ben a Delete All paranccsal igyekeztem megszabadulni az összes snapshottól. A várt siker helyett a következő üzenet fogadott:








A zárolást nyílván nem okozhatta más, mint maga a VDR, hiszen a két diszk továbbra is látszott a VDR erőforrásai között. Ezután még négy lépés hiányzott a sikerhez:

  • VDR leállítása
  • mivel így a lock megszünt,  a snapshotok törlése
  • a VDR lemezei közül a nem oda valók törlése (vigyázva arra, hogy csak a VDR-től vegye el, a datastore-on maradjon
  • VDR indítás, ellenőrzés
Ha a Data Recovery rendelkezne valamilyen beépített üzenetküldő szolgáltatással, mindez még a hiba napján megoldódhatott volna. Remélhetőleg a következő verzióban ez a hiányosság megszűnik.

2011. július 18., hétfő

TSM 6.2.2 kliens problémák VMware környezetben

Ahogy ez várható volt, az IBM is igyekszik lépést tartani a többi gyártóval, hogy minél jobban kihasználja a vStorage API for Data Protection (VADP) nyújtotta lehetőségeket.  Bár véleményem szerint soha nem lesz képes olyan szinten integrálni a TSM klienst a VMware környezetbe, mint teszik ezt más gyártók (VEEAM, EMC, stb), de talán nem is az a legfontosabb.  Aki már rendelkezik TSM infrastruktúrával, szeretné minél hatékonyabban használni azt. Pl. ha a VMware támogatja az inkrementális virtuális gép mentést, akkor jó lenne ki is használni a benne rejlő lehetőséget, és nem minden alkalommal lementeni a teljes gépet.
A következőkben szeretném saját tapasztalataim alapján összefoglalni, hogy a TSM mennyit képes használni a VADP lehetőségei közül.
De mielőtt ebbe belemennék, nézzük meg hogy mi a gond a jól ismert VCB-vel. A legnagyobb egyértelműen az, hogy a támogatása meg fog szűnni. Ezt már korábban is ígérte a VMware, de ennek ellenére továbbra is használható. De egészen biztos, hogy ez az állapot változni fog a jövőben. Hátrányként említhetem még a szükséges átmeneti diszk meglétét, vagy még inkább a körülményes visszaállítást (első lépésben a TSM BA klienssel a proxy szerverre, majd a VMware konverterrel beilleszteni az infrastruktúrába).
Nézzük, hogyan fejlődött a TSM a közelmúltban:
-          BA Client 6.2.0
Megjelent a vStorage API használatának lehetősége. Igaz, hogy egyelőre csak a file szintű mentésekhez használta a TSM, de látszott, hogy jó az irány
-          BA Client 6.2.2
Ebben már akár FULLVM akár file szintű mentést is végezhetünk a VADP használatával. Azaz a proxy szerveren a továbbiakban nincs szükség a VCB-re. Mivel a VADP használatkor közvetlenül a datastore-okról történik a mentés, az átmeneti tárterület is felszabadítható. Nem utolsó sorban pedig a visszaállítás leegyszerűsödik egyetlen műveletre
-          BA Client 6.2.3
Még mindig nincs inkrementális vm mentési lehetőség, még mindig nem lehet full vm mentésből egyedi fájlokat visszaállítani.
Miközben arra vártam, hogy mikor jelenik meg az a TSM verzió, ami már a fenti dolgokat is tudja, a fórumokban feltűnt egy TSM for Virtual Environments vagy más néven TDP for VMware nevű termék. Ez a termék  képes inkrementális vm mentésre, képes teljes gép mentésből fájlok visszaállítására, stb. Gondolom ezek után mindenki számára világossá vált, hogy az IBM nem a hagyományos BA klienst fogja tovább okosítani, hanem egy külön terméket fejleszt.  Ami hasonlóan más TDP termékekhez, külön licence ellenében használható.  Nem erre számíttottam….
A fenti információ kissé hivatalosabb formában megtalálható a következő linken.
 De aki nem akar sokat olvasni, annak idézem:
„Full VM block level incremental support is provided in the Tivoli Storage Manager Backup-Archive Client version 6.2.3 level for those customers who have purchased the "Tivoli Storage Manager for Virtual Environment - Data Protection for VMware" product. Full VM incremental backup requires VMware Change Block Tracking (CBT) and is only available on virtual machines on ESX 4.0 or later host with virtual hardware level 7.

To enable the Backup-Archive Client full VM incremental support (dsmc backup vm -mode=incremental), run the install package for "TSM for Virtual Environment - TDP for VMware". Under custom install, select the "Data Protection for VMware Enablement File" component. The "Data Protection for VMware Mount" component can also be installed on the same machine to enable the individual file restore from full VM backups. When using these features, use the Client Preference Editor to ensure backup type is set to FULLVM and VM Full type is set to use the vStorage APIs. „
Aki szeretne technikai részleteket megtudni a termékről, az IBM oldalán találhat róla némi információt. Ezek mellett június 26-án az IBM tartott az Interneten egy live traininget, amit utólag is meg lehet nézni egy rövid regisztráció után a következő linken:
Végül pedig szeretném megosztani azokat a tapasztalatokat, amiket a vStorage API-t használó TSM környezet kialakításánál szereztem. Nem állítom, hogy mindenki belefut ezekbe a dolgokba, de a fórumokat olvasva másnak is voltak hasonló tapasztalatai.
-          A restore vm parancs nem működik, ha a vmware környezetben a vcenter alatt közvetlenül nem a Datacenterek vannak, hanem valamilyen megfontolásból mappák. A mentések rendben mennek, de visszatöltéskor hibát jelez. Ez igaz mind a GUI mind a parancssor használata estén
-          Ha már történtek mentések a VCB-vel, és ugyanazokat a gépeket egy adott időtől kezdve a vStorage API-n keresztül mentünk, akkor a GUI nem tudja jól megjeleníteni a kétféle mentését ugyannak a virtuális gépnek (Aktív és inaktív). Ez akkor oldódik fel, ha már elegendő idő eltelik, és törölhető a VCB mentéseket tartalmazó filespace. Amíg ez nem lehetséges, a parancssoros restore a járható út. Ott a –pick opció használatával (és persze az –inactive opcióval) kilistázza mindkét féle mentést.
-           A restore folyamán a vcenter szerveren tömegestől jelenik meg a ’Clear lazy zero’ üzenet. Ez a vcenter működéséből fakad, igaz hogy valamelyest lassítja a visszatöltést, de más problémát nem okoz. A vcenter következő verziójában ígérik, hogy kijavítják. Közvetlen hostra való visszatöltés esetén nem jelentkezik (fórum hozzászólások szerint).
-          Egy virtuális gép diszkje két féle lehet. Thick vagy thin. Az első esetben a diszk létrehozásakor lefoglalja a teljes területet a storage-on, míg a második esetben csak annyit, amennyit ténylegesen elfoglalnak rajta az adatok. Viszont visszatöltés után az eredetileg thin diszk thick lesz. Ezt egy storage vMotion-nel lehet utólag orvosolni. Ez megint csak nem a TSM működéséből fakad, hanem a vStorage API-ból. Gondolom, ez is javítva lesz a későbbiekben.
-          6.2.2 à6.2.3 upgrade után kb. 2 percenként töltött vissza 128MB-ot. Visszatöltött 128MB-ot, majd várt 2 percet, újra visszatöltött 128MB-ot, és így tovább. Erre valaki már nyitott esetet az IBM felé. Ha visszaálltam  6.2.2-re, a 6.2.3-mal mentett adatok visszatöltése továbbra is lassú maradt, de az újabb mentésekből történő visszatöltések már normál sebességűek.
-          Mivel a vm restore egy új gépet hoz létre, ezért a visszatöltött gép újabb mentése hibára fog futni, mert az adott gépnek már más lesz a vm id-je, mint a mentett régebbi verzióké. Ezért vagy törölni kell az adott gép mentésit tartalmazó filespace-t, vagy a vm-nek adni kell egy másik nevet visszatöltés után. (ettől a dns neve nem változik.)