Újabb pofon – LAnFree vs Virtuális gépek

Sajnos újabb inkompatibilitási problémába ütköztem, ami hosszú távon nagyon kényelmetlen lehet a számunkra. Az IBM egy tudásbázis cikke szerint – megerősítve a BCSS Kft munkatársainak állítását – nem lehet LANFree mentést végezni virtuális gépről.
 
Mi is a LANFree mentés? Adott ugye egy TSM szerver, amely egy SAN-hoz kapcsolódik Fibre Channel kártyákon keresztül. Ez a szerver lát a SAN-on saját meghajtókat és látja a szalagos könyvtárat is. Ezen felül vannak kliensek, amelyek ugyanahhoz a SAN-hoz kapcsolódnak, ugyanúgy megvan a lehetőségük a szalagos egységgel való kommunikációra. A hagyományos mentésnél a kliensre telepített agent nem figyel a SAN architektúrára, fogja a mentendő adatokat, átküldi a "rendes" Ethernet hálózaton a TSM mentőszervernek, amely azután a saját FC kártyáján a saját lemezeire, vagy a szalagra menti az adatokat. A LanFree mentés ezzel szemben felfogja, hogy itt felesleges utat jár be az adat, hiszen egy jó library-sharing mechanizmus segítségével a mentő agent "elkérheti" a szalagos egység egy meghjtóját és közvetlenül odairányíthatná a mentendő adatok, s csupán a mentés meta-adatai kerülnének az Etherneten át a TSM szerverbe. (A library-sharing egyébként önmagában is egy nagyon izgalmas téma, megérne néhány bejegyzést. Íme egy kis ízelítő.) Az előnyök egyértelműek: nem kell a helyi hálózatot használni, a mentés gyorsabb, a TSM szerver kevésbé terhelt, és ami a leglényegesebb, a LanFree mentés mellett LanFree Restore is megvalósítható, tehát csökkenthető a helyreállításhoz szükséges idő.
 
Nos, a virtuális szerverekből ez a funkció nem érhető el. A virtuális szerverek ugyanis a SAN-on található eszközöket virtuális SCSI kártyákon keresztül érik el, nem virtuális FC kártyákon, így megbukik a LanFree mutatvány. (A pontos, műszaki magyarázatot még keresem)
 
Milyen következményei vannak mindennek és hogyan mászhatunk ki a csávából? A következmény az, hogy ha megnő az Exchange adatbázisunk, akkor bizony akár 6-8-10 órás visszaállítgatással is számolni kell, ami nem biztos, hogy elfogadható (az izgalmakról nem beszélve). Az SQL szerverünk esetén pedig már most sem lenne acceptálható ilyen idő. Ha nem találunk megoldást, akkor az SQL cluster nem lesz virtualizálható, akkor viszont az egész x445 – x460 migrációnak lőttek, ergo nem tudom, hogy mikor és hogyan lehete longhorn platformra váltani. Vagyis a következmények súlyosak.
A lehetséges megoldások:
  1.  Gigabit LAN, dedikált hálózati kártyákkal. 1 GBit/sec az 1024 Mbit/sec, ami 128 Mbyte. Ha ennek a sebességnek csak a harmada használható ki, akkor is kb 42 MB /sec mentési sebességgel számolhatunk. 100 GB adat esetén ( (100*1024)/42 = 2438 másodperc) 40,6 perc mentési idővel számolhatunk. 200 GB esetén kb 80 perccel. Ez még úgy ahogy elfogadható. Visszaállításnál 1,5-el számolva kb 2 óra. Ideális esetben. Hálózatbővítéssel amúgy is számoltunk, tehát ez a változat megvalósítható.
  2. ESX 3. Nem tudni még, hogy idén mikor, de biztosan megjelenik, a verzióra pedig jogosultak vagyunk. Az ígéretek szerint "VMware Consolidated Backup simplifies and accelerates backup with host-free, LAN-free, agentless backup of Windows virtual machines." várható, de hogy ez technikailag mit jelent, s főleg, hogy plusz pénzt kell-e fizetni érte, azt nem tudni.
  3. Storage snapshot. Messze a leggyorsabb megoldás, ezzel együtt viszont a legdrágább és legbonyolultabb. Bővíteni kell a storage-ot, esetleg licence is kell hozzá, majd áttervezni a teljes TSM mentést, már ami az SQL-t és az Exchange-et illeti. Minimum elvárás lehetne hogy tükrözött legyen a pillanatfelvétel, amit aztán szalagra lehetne kiírni. Egyelőre még becsülni sem szeretném az árát, bár a visszaállítási idő bizonyosan itt lenne a legkisebb.
Hát itt tartunk jelenleg.

3 Responses to Újabb pofon – LAnFree vs Virtuális gépek

  1. Petrenyi Jozsef says:

    Azért vigyázz az időbecslésnél. Nálunk elég sok időt az visz el, hogy az inkrementális mentések visszatöltésekor egy csomó kazettával játszik a TSM szerver.

  2. Tamas says:

    Ajánlom a "Collocation" funkciót. Ez a szétszóródott inkrementumokat egymás mellé sakkozza. Ha így túl sok  szalagot használna fel, akkor megoldás a "Collocation Groups" – de ehhez TSM 5.3 kell!

  3. Petrenyi Jozsef says:

    Igen, olvastam már korábban, hogy írtál erről, rá is kérdeztem az ügyfél emberénél, hogy hogyan is van ez – azt a választ kaptam, hogy a Tivoli szerver minden nap dolgozik, nincs ráérő ideje rendezgetni. Bővíteni meg nem akarnak.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: