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

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)

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ě!)

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.

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.