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. „
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.)
Nincsenek megjegyzések:
Megjegyzés küldése