vmware - nastroj Data Recovery - vyber vSphere Kitu

Mraku Mraku, tohle je spis na to obratit se na firmu, ktera ty produkty dela Schodou okolnosti u nas je to moje portfolio .

Predne, snapshot neni zaloha. Data jsou v nem ne vzdy konzistentni (kdyz je udelany za chodu) a NEDA se normalnim zpusobem zalohovat. Snapshot slouzi jako kratkodobe ulozeni stavu v pripade, ze treba delas nejaky krok, ktery si nejsi jisty jak dopadne. Rozhodne neslouzi k zaloham.
System netbackup (od symantecu) vyuziva snapshotu a VMware API k tomu, aby zalohy vytvarel (v case snapshotu necha vyprazdnit diskove cache operacniho systemu a propsat data na disk, takze jsou v zaloze konzistenti), ale snapshot samotny neslouzi jako zaloha. Totez, ale s mensimi moznostmi dela Data Recovery

Co se tyce kitu:
pokud mate jeden server, staci vam hypervizor zdarma (ESXi), zalohovat v nem ale budete moct jen z uvnitr virtualnich operacnich systemu.

Rozdil, mezi uvedenymi kity vysvetlim jen na tech rozdilovych vlastnostech:
HA - pri selhani fyzickeho hardware jednoho ze serveru se virtualni servery, ktere na nem bezely pusti na jinem serveru (vyzaduje nejmene dva a spolecne uloziste, iSCSI ci jinou SAN)
Moznost presouvat zapnuty virtualni server z jednoho fyzickeho stroje na druhy. Bez vypadku, bez toho, aby to uzivatel poznal. Vyhoda je zrejma. Muzes provadet udrzbu, update nebo vymenu HW, aniz bys musel ten virtual vypinat.

Vyhoda virtualniho prostredi, jak jsi zminil je urcite ta, ze pri vymene HW nemusis preinstalovat system. A na novem zeleze muzes provozovat i letite operacni systemy. VMware ve verzi 4 pribral DOS a jeho nadstavby (Win 3.x, winf 95, win 98), win NT, Free BSD, OS/2 WMware podporuje vic verzi windows, nez microsoft na hyper-V

JR

Asi tak. Já jen doplním, že osobně z hlediska zálohování nevidím přínos mít vmware (ačkoli to je jinak skvělá platforma na některé méně náročné aplikace) a možnosti přesunu mezi jednotlivými fyzickými stroji. Jednak je na to třeba licence ESX (a nestačí vSphere, ale je třeba koupit vCenter) a pak z hlediska zálohování resp. zajištění činnosti je SAN typický single point of failure. Navíc zrovna disková úložiště jsou tím nejvíce kolabujícím prvkem moderních serverů - za celou mou kariéru mi odcházejí jen disky a semtam RAID řadiče, resp. jejich akumulátory... Znám přes 10 let staré servery, kterým se neměnil ani ventilátor, ale kterým zgrejznuly disky... a SAN je defacto jen specializovaný "server".

Co je u tebe mena narocna aplikace? Ve svete x86 v podstate vsechno, vyjma velkych DB serveru a zalohovacich serveru pro velka prostredi. Prumerne zatizeni procesoru x86 v enterprise prostredi je 8% . Samozrejme software bezici na vykonych AIX ci i5 (OS400) serverech je pro virtualizaci opravdu nevhodny .

Právě ty databáze

Ale ono to je taky trochu poznat v tom, že dost serverů/aplikací běhává "spřaženě" - tj. např. databázový a aplikační server. Už jsem to viděl virtualizované na jednom ESXu a bylo to jak píšeš - ESX se většinu času flákal, ale když přišel workload, tak byly zatížené oba servery na 100% a celé to bylo nechutně pomalé (přitom databáze nebyla nějak extrémně veliká, pouhých pár GB)

Jo, databaze je obecne nedoporucene virtualizovat. U aplikacnich serveru to zalezi na spouste parametru, rozhodujici neni ani tak zatizeni procesoru (ani ve spickach), ale pocet stranek v pameti a I/O operaci na discich. Tak pak byva uzke hrdlo.

Jinak vetsi infrastruktury (rozumej virtualni infrastruktury), samozrejme s adekvatnimi licencemi umi:

load balancing napric servery (migruji virtualy mezi hosty tak, aby byly vykonove vyvazene)
vypinat nepotrebne servery - budi je pak pomoci na wake-on-lan v pripade, ze zbyvajicim serverum zacina pretekat zatez.
disponuje technikami na sdileni, balooning a kompresi stranek v pameti, takze lze v nejhorsich pripadech na jednom serveru bezet virtualy s pridelenym vetsim mnozstvim pameti, nez je fyzicka pamet serveru (coz je ale hranicni scenar).

Osobně bych dneska řešil zálohy serverovny nějakým DataDomain/NetWorker. Podporuje nativně (a inteligentně) zálohy vmware (aby taky ne, když je to jedna firma ) a hlavně se to dá využít nejen jako VTL, ale i jako běžné síťové úložiště.

Cau, tise jsem doufal, ze se k tomu vyjadrite mj. vy dva , dik.
_______________________________________________

JR
- jsme se taky na vas obratili (mozna jsi do toho byl i zatahnut, pokud stale delas ve stejne firme), ale snazim se ziskat info i z jinych zdroju. Takze dovol jeste par dotazu - pises:

Predne, snapshot neni zaloha. Data jsou v nem ne vzdy konzistentni (kdyz je udelany za chodu) a NEDA se normalnim zpusobem zalohovat. Snapshot slouzi jako kratkodobe ulozeni stavu v pripade, ze treba delas nejaky krok, ktery si nejsi jisty jak dopadne. Rozhodne neslouzi k zaloham.

- v nasem prostredi by se nemusel delat za chodu, tzn. pokud bychom virtualni stroj zastavili, a az pote udelali snapshot - predpokladam, ze pak by byl konzistentni a virtualni stroj by bylo mozne obnovit do stavu v dobe snapshotu...?

- dale pises:

Co se tyce kitu: pokud mate jeden server, staci vam hypervizor zdarma (ESXi), zalohovat v nem ale budete moct jen z uvnitr virtualnich operacnich systemu.

- stale vsak preci muzu udelat kopii virtualniho stroje (disku) a ten v pripade nutnosti rozbehnout nekde jinde...?

- za vysvetleni rozdilu mezi kity dik, myslim, ze jsem to i tak pochopil, pro nase ucely (alespon pro soucasne aplikace) asi zbytecny luxus (HA)
______________________________________________

tw
- pises, ze v vmware nevidis prinos, ze je treba koupit vCenter - jak pisi vyse, preci pokud by se udelala kopie virtualniho stroje "zvenci" (coz by snad melo byt mozne jak u verze vCenter tak vSphere), tak ten by se pak dal spustit jinde a ucel by to splnilo...? A pokud by se pomoci vmware virtualizoval (a pomoci snaphotu zalohoval) pouze aplikacni server a SAN by se zalohovalo oddelene, pak by vmware smysl melo...? Pripadne ma smysl uvazovat o nejakem jinem virtualizacnim nastroji (Xen, KVM)?
_______________________________________________

Oba se shodujete, ze databaze by se (kvuli I/O operacim) virtualizovat nemely - toto jsem slysel i z jinych zdroju a proto se k tomu nechystame.

Jinak asi je z mych vylevu patrne, ze se snazim minimalizovat naklady (i za cenu vyssi pracnosti) a proto se obavam, ze tacudem navrhovana reseni (DataDomain/NetWorker), byt by pravdepodobne delaly to, co potrebujeme, jsou pro nas prilis nakladna.

Diky za vas cas,
M.

odpovím na svou část --

zálohování přes snapshoty (respektive jakékoli zálohování) tě nezbavuje potřeby mít "alternativní" úložiště, na které ta data budeš zálohovat - a bavíme se o úložišti v řádu minimálně stovek GB, spíše však jednotek až desítek TB (v závislosti na zvoleném zálohovacím schématu versus velikost záloh, která bude v případě zálohování snapshotů doslova enormní). To je to, nač jsem tě chtěl v souvislosti se SAN upozornit, záloha na stejný fyzický SAN není zálohou. A to už nemluvím o tom, že správná záloha by měla ležet úplně jinde, než jsou servery (ideálně tak 100km mimo )

P.S.: já jsem už dospěl do stadia, kdy vím, že přílišné šetření se nevyplácí - má smysl šetřit tam, kde to neovlivní výslednou funkci, ve tvém případě se ale obávám, že "neinteligentní" zálohování celých snapshotů je neefektivní, pracné, složité a v konečném důsledku i extrémně nákladné.

Mluvíme o záloháchm nebo archivaci?

Jinak co se SAN týče, pokud je dobře navržená SAN Ifrastruktura, tak neobsahuje Single point of failure:

Raid pole (raid 10, Raid 6 + spare), dva zdroje, kazdy na jinou UPS, dva kontrolery, kazdy minimalne dva porty, dva switche a na serverech nejlepe dve karty...

Takze ani SAN nemusi byt v dnesni dobe single point of failure

já mluvím o zálohách dvou strojů

ad SAN - ale stále se jedná o jedno zařízení v jedné lokaci. Případný požár, zátopa, zlovolná, nebo nechtěná (omylem) akce způsobí nevratné škody.

Vysvetlim snapshoty:

kdyz uz budes mit pocitac vypnuty, tak nemusis delat snapshot, staci jen skopirovat jeho virutalni disk a konfiguracni soubor jinam, tim to odzalohujes.

Popisu ti, co se deje, kdyz se udela snapshot, at uz s vypnutym, nebo zapnutym pocitacem:

Ulozi se soucasny stav disku (pripadne pameti, pokud to delas za chodu) a vytvori se alternativni soubor, do ktereho se zapisuji "diskove operace". Pokud tedy udelas druhy snapshot, tak uz "souborove" nebudes mit obraz disku, ale jen disk, soubor se zmenami do druheho snapshotu a nove se vytvarejici soubor se zmenami od druheho snapshotu.