Snapshoty - vyšší level zálohování firemních dat

R. Schutz, O. Bačina, 15. červenec 2011 12:34 2 komentářů
Rubriky: Hardware

Chlazení
Začneme možná trochu zeširoka. Problémem, který pálí každou firmu, je výpadek provozu často doplněn o ztrátu dat. Proti ztrátě dat nás chrání technologie zálohování dat, s výpadkem provozu si poradí technologie vysoké dostupnosti.


V současnosti prožíváme datovou explozi. Sami si dokážete představit, jak se v poslední době znásobila velikost soborů, které ukládáme. Ovšem jde o to, udržet tempo v oblasti zálohování dat a jejich vysoké dostupnosti, když nám jejich množství roste exponenciálně pod rukama. Důležité je uvědomit si, že když data ukládáme, děláme to většinou po menších přírůstcích, avšak zálohovat bychom měli co nejrychleji. Co to je nejrychleji? Rychlost souvisí s více faktory.

Chceme-li zálohovat data, která jsme vytvořili, musí být tato data konzistentní. Nejlepší konzistence dat lze dosáhnout, pokud se s daty v průběhu zálohování nepracuje. Proto je také zálohování ve firmách většinou nastaveno přes noční hodiny, tak aby se nekrylo s dobou, kdy by ještě mohli uživatelé pracovat (např. od 22:00 – 6:00 = 8h). Pokud se tedy ve firmě zálohování „vejde“ do tzv. zálohovacího okna (v našem případě 8h), je všechno v pořádku. Jestli-že by ale zálohování trvalo déle, můžeme mít velký problém.

Parametry pro určení cíle zálohování a vysokou dostupnost

Recovery Point Objective (RPO)


Technologie, které nám zde pomáhají:

  • Pravidelné zálohování – Na pásky nebo na pevné disky

  • Clony & Snapy

  • Replikace (diskových polí)


Parametr, který nám určuje, kolik dat zpátky od kritické události máme. Opět platí jednoduché pravidlo: pokud mám nastaveno zálohování 1xdenně je jasné, že pokud se mi něco stane ve 12:00 a přijdu o všechna data, tak jsem schopen obnovit ze zálohy pouze data vytvořená do 22:00, tedy data vytvořená včera (opět bereme náš příklad). Je na vedení firmy, aby si rozhodlo, kde chce na této časové ose být. Samozřejmě čím blíže jsme nulové ztrátě dat, tím dražší technologii musíme použít.

Recovery Point Objective (RPO)


Recovery Point Objective je technický parametr, který nám určuje, za jak dlouho od kritické události bude systém opět 100% funkční. Zde jsou již zmíněné technologie typu High Availibility atp. Pro určení kvality řešení se uvádí systém tzv. devítek - jedná se o procenta dostupnosti systému jako celku. Ve velkých enterprise řešeních se většinou bavíme o tzv. 5ti devítkách (= 99.999% dostupnosti). Takovéto řešení musí mít maximální výpadek za rok 5.26 minuty! (Jen pro představu si můžeme vyzkoušet restartovat notebook, který již nějakou dobu používáme a hodně se přiblížíme této hodnotě!)


Technologie a procesy, které nám zde pomáhají:

  • Pravidelné zálohování – (páska/HDD)

  • Clony & Snapy

  • Clustering

  • Servisní smlouva

  • Replikace




Přirovnání: Můžeme si to představit na vaně, do které se jdeme vykoupat. Když vanu napouštíme, máme k dispozici vodovodní baterii a určitý tlak vody. Vana se tedy nenapustí hned, ale trvá to jistou dobu (jako vytváření dat). Jakmile se vykoupeme, vanu vypustíme (přesuneme vodu do jiné oblasti - do kanalizace). To se dá přirovnat k zálohování, kde sice nedochází k přesunu, ale „jen“ kopírování dat, nicméně jako příklad to lze dobře použít. Tedy pokud začneme vypouštět vanu, pak rychlost, s jakou se vana vypustí, je závislá na tom, jak velký „otvor“ mám pro výpusť. Pokud bych chtěl mít vanu vypuštěnu „okamžitě“, musím ji překlopit a použít pak jako výpusť celý horní otvor. To je ale v našem případě v podstatě neproveditelné. Jediné, co se tomu blíží je právě technologie Klonů a Snímků (Clone & Snapshot). Nejdůležitější je tato technologie právě pro RTO, protože snap je připraven ihned k použití. Tyto technologie si teď představíme.

Co je snapshot a jak na něj


Snapshot je standardní termín pro schopnost zaznamenat stav paměťového zařízení k danému okamžiku, určená pro rychlou obnovu dat. Snapshot je kopií dat k určitému času (Point-in-time-copy). Většinou je Snapshot po vytvoření okamžitě k dispozici pro použití v jiných aplikacích, jako je zálohování, testování či analýza dat. Originální data jsou i nadále k dispozici aplikaci bez přerušení provozu, pouze s minimálním pozastavením datového toku. Díky snapshotům je možné rychle obnovit například omylem smazaná data bez nutnosti použití obnovy pomocí zálohovacího software. To je obzvláště přínosné, pokud úložiště umožňuje vytvořit velké množství snapshotů v krátkých časových intervalech. Vytváření snapshotů s sebou nese nároky jak na výkon, tak na kapacitu datového úložiště v závislosti na použité metodě tvorby snapshotů.
Existuje několik způsobů vytváření snapshotů, z nichž každý má své výhody a nevýhody. Nejčastěji používanou metodou je „kopie při zápisu“ (Copy-on-write). Copy-on-write snapshot je vytvořen v prostoru vyhrazeném pro snapshoty. Při úvodním vytvoření snapshotu jsou pouze zkopírována metadata s definicí umístění bloků originálních dat. Při změně originálních dat jsou nejprve bloky, které mají být přepsány, zkopírovány do prostoru vyhrazeném pro snapshoty a pak jsou teprve přepsány.

Postup fungování Copy-on-write snapshotů se dá shrnout do následujícího jednoduchého postupu:


  1. Snapshot vytvoří logickou kopii dat. (tzv. Pointry, můžeme si představit jako zástupce na ploše)

  2. Požadavek na přepis originálních dat způsobí nejprve zkopírování těchto dat do prostoru vyhrazenému pro snapshoty a pak teprve přepsání dat.

  3. Čtení ze snapshotu je přesměrováno na originální data, pokud ještě nebyla změněna.

  4. Čtení ze snapshotu dat, která již v originální lokaci byla změněna, je provedeno ze snapshotu.

  5. V případě snapshotu s povoleným zápisem, nemají zápisy do snapshotu vliv na originální data.

Největší nevýhodou Copy-on-write snapshotů je vysoký nárok na výkon zařízení, které snapshoty vytváří, jelikož při změně originálních dat je nutné provést dvě operace. Nejprve originální data zkopírovat do prostoru pro snapshoty a pak teprve provest jejich změnu. Z tohoto důvodu mají zařízení, používající tuto technologii snapshotů, poměrně nízké limity na maximální množství vytvořených snapshotů.

Druhou metodou vytváření snapshotů je metoda Split-Mirror (také známý jako Clone). Při ní dochází k zrcadlení dat na další disky a v případě potřeby snapshotu dojde k přerušení tohoto zrcadlení. Výhodou metody Split-Mirror je fyzické oddělení kopie dat, kdy při vytvoření snapshotu nedochází k zatěžování disků s originálními daty. Nevýhodou jsou vysoké nároky na kapacitu, protože je potřeba mít dvojnásobnou kapacitu diskového úložiště.

Třetí, nejzajímavější metodou je „přesměrování při zápisu“ (Redirect-on-Write). Redirect-on-write při vytvoření snapshotu zmrazí originální data a nové zápisy jsou přesměrovány do volného diskového prostoru, což platí jak pro originální data, tak pro přepis dat ve snapshotu. Díky tomu je vliv snapshotu na originální data minimální a k jejich zatěžování dochází pouze při intenzivních čtení snapshotu. Rovněž je vytvoření snapshotu touto metodou méně náročné než při použití Copy-on-Write. Věcí, na kterou je třeba si dát pozor při R-O-W snapshotu, je fragmentace. Jednoduché řešení fragmentace je například Automatický Storage Tiering.

Hlavní je být konzistentní (nejen v názorech)


Při vytváření snapshotů, ať již jakoukoliv metodou, je potřeba si uvědomit, že ačkoliv se jedná o okamžitou kopii dat, je potřeba na krátkou dobu zastavit IO operace pro zajištění konzistentních dat. K zajištění konzistence nejrozšířenějších aplikací (MS SQL, Exchange, Oracle, Sharepoint a další) bývá k dispozici od dodavatele datových úložišť integrační software, který komunikuje přímo s úložištěm a stará se o pozastavení IO během vytváření snapshotů. Krátkodobé pozastavení IO má na běh aplikace zanedbatelný vliv a zaručuje snadnou obnovu dat ze snapshotu.

Přirovnání: Pokud bychom používali diskové pole, které nemá konzistentní snapshoty je to totéž, jako kdybychom najali skupinku sice velice rychlých a šikovných dělníků, ale bez mistra, aby vyložili hromady uhlí z nákladního auta do sklepa. Oni by sice vše provedli rychle, ale neotevřeli by okénko do sklepa. Hromadu tedy máte, ale je vám to vlastně k ničemu. Snapy bez aplikační konzistence jsou na tom podobně. K čemu mi jsou data, které sice mám, ale v případě havárie, když je chci obnovit, mi aplikace napíše, že jsou nekonzistentní a já je (v lepším případě) musím podrobit nějaké kontrole konzistence, v horším případě je pak nemohu použít vůbec? Toto mi pak opět prodlužuje RTO.

Všechny typy snapshotů potřebují nějaké místo navíc. Kromě split-mirror(Clon), které potřebuje 100 % kapacity ostatní typy potřebují „jen“ tolik, kolik bude změn. Jak však toto predikovat? Velice špatně. Můžeme vycházet z nějakých doporučení cca 20-30 % kapacity. Problém je, že toto místo bývá pevně prealokováno a ubírá nám tak volné místo v diskovém poli. Tato rezervovaná kapacita může zabrat opravdu velký prostor a je třeba tedy tuto část nepodcenit. To bývá také jeden z důvodů, proč u některých diskových polí není tento systém moc využíván. Nicméně jsou také výrobci, kteří používání snapshotů nijak nelimitují na prealokaci prostoru. Šetří tím velice kapacitu zákazníkova zařízení.

Důležitá je také správa snapshotů. Pokud chci snapshoty využívat pravidelně, je třeba, abych na to měl nějaký komfortní nástroj - snapshot manager. Ten mi umožní nastavit pravidelnost (tzv. schedule) a tím mi zajistí právě již zmiňovanou aplikační konzistenci. V neposlední řadě také umožní nastavit trvanlivost snapshotu. Tyto parametry pak, spolu s četností snapshotů, dají dohromady počet snapshotů, který se bude udržovat metodou FIFO (z anglického First In, First Out, česky První dovnitř, první ven). Dejme tomu, že nastavíme snapshot každých 15minut a jeho trvanlivost na 2dny. To je 192 snapshotů. Proto je velice důležitý parametr, kolik pole snapshotů podporuje. Z tohoto příkladu ale také vidíme, že je vhodné provést nějakou kombinaci více snapshotů k jednomu svazku. Pro dosažení co nejkratšího RPO, ale zároveň pro vylepšení zálohování, doplnění nějakého denního, týdenního popřípadě měsíčního schématu.


Doporučená kritéria pro výběr
Rozhodneme-li se pro pořízení diskového pole s technologií Shapshots, je vhodné zjistit si dopředu několik základních parametrů:

  1. Jaký typ snapshotů a klonů pole skutečně podporuje? Nejlepší je Redirect On Write (pak ale, podporuje pole Automatický Storage Tiering?).

  2. Je nějaký limit ve vytvoření snapshotů? Nejlepší je bez omezení.

  3. Je nějaká prealokace prostoru pro klony a snapy? Nejepší je bez prealokace prostoru.

  4. Umí storage provádět aplikačně konzistentní snapshoty? Důležité je pro vámi používané aplikace.

  5. Kolik mohu vytvořit snapshotů pro jeden svazek? Jsou pole, kde mohu vytvořit jen jeden!

  6. Jakým způsobem jsou snapshoty spravovány – Snapshot manager?

  7. Jaký je nejmenší čas periody vytváření snapshotů?



Nechte snapshoty pomoci zlepšit RTO a RPO


Jak již bylo zmíněno výše, snapshoty nám mohou výrazně pomoci při zlepšení těchto parametrů. Jednak je to jejich četnost (zde jsme schopni se dnes již dostat na úroveň minut) = RPO, dále pak je to rychlost a jednoduchost zapojení do ostrého provozu = RTO. Snapshoty nám ale mohou pomoci i ke zlepšení „klasického“ zálohování použitím zálohovacího SW. Pokud totiž používám aplikačně konzistentní snapshoty, mohu si dovolit zkombinovat tuto technologii a připojit si tento snap k zálohovacímu serveru a čerpat data z této oblasti.

Proč je toto důležité? Opět se vraťme na začátek článku. Jestliže mi toto „klasické“ zálohování trvá 8h, tak se bohužel určitě dostanu do stavu, kdy část dat, která již mám zálohována, odpovídají času 22:00, ale část dat odpovídá třeba 04:00. Díky tomuto logickému paradoxu se může jednoduše stát, že dokončená záloha nebude odpovídat chtěnému stavu. Použitím snapu začínám zálohovat tzv. zmražená data, jejichž konzistence odpovídá času vytvoření snapu. Jak dlouho takováto data zálohuji, mě v podstatě nezajímá (nesmím samozřejmě překročit další mezník, což je 24 hodin), jelikož se již nemohou změnit a dokonce mám zajištěnou jejich konzistenci.

Autoři pracují na pozicích Storage Architect a Enterprise Brand Manager ve společnosti Dell.


Komentáře

Marek Stopka #1
Marek Stopka 21. červenec 2011 11:38

Není jediný důvod proč by zálohovací aplikace nemohla překročit čas pro získávání dat ze snapshotu více než 24 hodin. Pokud mám dobře integrovanou zálohovací aplikaci s diskovým polem (například pomocí NDMP), a navázanou na snapshot id, pak i když změním jméno starého snapshotu a vytvořím nový se stejným jménem snapshot id starého snapshotu zůstane stejné, takže NDMP session bude pořád čerpat data ze starého snapshotu... Nehledě na to, že se dají jmenné konvence pro snapshoty nastavit tak, aby se jejich jméno neměnilo a pak se dá NDMP klient nastavit tak, aby bral data z nějaké cesty, která se nemění... Což opět vyžaduje nějakou integraci na zálohovacím serveru, aby se na diskové pole přihlásil, provedl list snapshotů, vybral ten správný a pak použil vhodnou cestu, ale rozhodně se nejedná o nepřekonatelnou překážku.

A zálohování databázových aplikací pomocí split přístupu se snad používá už roky, ne? Na jedne sadě disků běží databáze, ta se drží synchronizovaná s druhým párem disků, v případě požadavku na vytvoření zálohy se příslušné tablespace (databáze) přepne do hot-backup režimu, provede se poslední synchroniozace repliky s originálem, mirror se dočasně rozpojí, databáze se přepne zpět do produkčního režimu, provede se záloha dat přes DR server na pásku, po dokončení zálohy se mirror zase naváže.

Pokud by v průběhu zálohy došlo k aktivaci DR plánu, pak se zálohování na DR hostovi ukončí, a provede se media recovery s aplikací příslušných archivních logů od posledního rozpojení mirroru.

Náhodný kolemjdoucí #2
Náhodný kolemjdoucí 15. červenec 2011 15:20

A dá se k tomu Snapshotu připojit iPod?


RSS 

Komentujeme

Chatbot mluví za mrtvého – od nápadu k realizaci

Pavel Houser , 30. listopad 2016 13:00
Pavel Houser

Na webu The Verge popsala Casey Newton příběh dvou přátel (Eugenia Kuyda a Roman Mazurenko). Peripet...

Více





Kalendář

RSS 

Zprávičky

Tchajwanský Foxconn jedná o rozšíření svých aktivit v USA

ČTK , 07. prosinec 2016 15:00

Tchajwanská společnost Foxconn jedná o rozšíření svých aktivit ve Spojených státech. Oznámila to dne...

Více 0 komentářů

Nejvyšší soud USA se postavil na stranu Samsungu proti Applu

ČTK , 07. prosinec 2016 12:30

Americký nejvyšší soud se v mnohaletém patentovém sporu mezi výrobci chytrých telefonů Apple a Samsu...

Více 0 komentářů

Evropská komise Microsoftu schválila převzetí sítě LinkedIn

ČTK , 07. prosinec 2016 10:30

Evropská komise schválila americké softwarové společnosti Microsoft záměr koupit za 26 miliard dolar...

Více 0 komentářů

Starší zprávičky

Porozumění větám, konkurence pro Turingův test

Pavel Houser , 06. prosinec 2016 18:00

Konverzační roboti mají stále problémy pochopit věty, kde smysl nelze vyvodit ze samotné gramatické ...

Více 0 komentářů

Americká GoDaddy koupí evropský webhosting Host Europe

ČTK , 06. prosinec 2016 16:00

Americký registrátor internetových domén GoDaddy, který je ve svém oboru největší na světě, se dohod...

Více 0 komentářů

Ruská Centrální banka oznámila masivní útok hackerů

ČTK , 06. prosinec 2016 11:00

Do systému ruské Centrální banky se letos dostali hackeři a s pomocí zfalšovaných hesel se pokusili ...

Více 0 komentářů

CETIN vydal dluhopisy za 25 miliard Kč

ČTK , 05. prosinec 2016 18:00

Česká telekomunikační infrastruktura (CETIN) upsala dluhopisy v eurech a korunách v celkovém objemu ...

Více 1 komentářů