Marketing: “Naše mega-super-zálohovací řešení je integrováno s tím a tamtím a je to jediný způsob získání konzistentní funkční zálohy.” Velké prohlášení. Dá se něco takového udělat ve světě open source v Helion OpenStack? Podívejme se, jak na to.

Nekonzistentní záloha

Představte si, že chcete zálohovat svět kolem vás. Máte fotoaparát, ten ale nedokáže na jedno cvaknutí sejmout 360 stupňů. Můžete se tedy otáčet a udělat třeba čtyři snímky a svět tak pokryjete celý. Výsledkem bude nekonzistentní záloha. Proč? Dejme tomu, že v okolní scéně si Martin s Tomášem hází míček. Možná jste Martina vyfotili těsně po odhození míčku (a Tomáš v tomto snímku není) a po otočení jste vyfotili Tomáše, ale ten byl zrovna těsně před zachycením míčku. Ve vaší záloze světa jsou míčky dva! Nebo je to možná naopak – zachytili jste Tomáše čekajícího na míček a Martina po tom, co už míček dávno odhodil. Ve vaší záloze míček přestal existovat. Nahraďte míček daty nebo soubory a víte, kde je problém. Takhle se zálohovat opravdu nedá.

Jaké je řešení? V průběhu zálohování nedělat žádné změny, tedy říct všem, že se po dobu focení nesmí hýbat. U velkého disku ale záloha trvá dost dlouho, takže lidi potom bolí nohy (a aplikace se odmlčí na takovou dobu, že dojde k timeoutům a šéfa provozu pak bolí hlava). Ke slovu tak přichází snapshot technologie – zmrazení stavu, které proběhne extrémně rychle a všechny další změny se dočasně zapisují někam bokem. Tím vzniká čas v klidu vytvořit kopii zmrazené části a až je to hotové, dopsat změny uložené někde bokem do původního prostoru. Je to způsob jak rychle a efektivně získat fotografii celého systému v jednom jediném čase, tedy fotku se záběrem 360 stupňů. Snapshot je vlastnost vaší storage, třeba HP 3PAR, HP StoreVirtual nebo některé další. OpenStack Cinder driver ji umí využít, takže snapshot uděláte přímo z OpenStack.

Crash konzistentní záloha

Snapshot je crash konzistentní záloha – zachycuje reálný svět, nevznikají nové míčky ani žádné záhadně nemizí. Snapshot je v zásadě totéž, jako když serveru vypnete proud. Určitě si pamatujete doby, kdy něco takového zaručeně končilo tím, že váš počítač příště nenabootoval. V moderním světě je ale překvapivě vysoká odolnost vůči následkům takových situací. V naší analogii bychom potřebovali, aby míček byl buď u Martina nebo Tomáše, ale ne ve vzduchu bez možnosti rozeznat vektor pohybu. To můžeme řešit například tím, že najmeme komentátora, který bude zapisovat dění v našem světě – v záloze pak bude obsaženo i něco jako “Martin právě hází míček Tomášovi”. Tato informace postačí k rozhodnutí takových sporných situací. Takový žurnál najdete v moderních souborových systémech (NTFS, Ext3, Ext4), databázových i jiných systémech. Prakticky všechny použitelné OS a velká většina aplikací se z crash konzistentní zálohy bez problému zotaví. Dokonce například síťové prvky, které jsou postaveny obvykle na nějaké odnoži Linux OS, nemají žádnou možnost vypnutí – ani příkaz, ani tlačítko. Jednoduše se vypojí ze zásuvky a ještě jsem neslyšel o tom, že by to komukoli způsobilo problém. Řekněme, že u OS samotného máte 99% šanci, že systém ze zálohy v pohodě naběhne. U aplikací jako jsou webové servery a tak podobně je to třeba 90%. Nejhůře na tom budou databázové systémy, ale řada z nich to přežije také s velmi vysokou pravděpodobností.

Aplikačně konzistentní záloha

Někdy crash konzistence nestačí. Možná to není o tom, že by se databáze dostala do nějakého neopravitelného fatálního stavu, ale obnovení konzistence případně “dojetí” transakcí z žurnálu může trvat dlouho (dopad na výkon aplikace) nebo nemusí být automatické (nutnost někoho se připojit a “poladit”). Potřebovali bychom tedy aplikaci připravit na to, že se bude zálohovat, aby se nepouštěla do žádných větších akcí. Právě to je míněno onou integrací – způsob jak aplikaci dostat do backup aware stavu (což není vlastnost backup software, ale aplikace). Může to být nějaký generický systém (Microsoft VSS), generické API nebo aplikačně specifické záležitosti (například skript, který v MySQL zamkne tabulky a provede flush na disky). Co je flush v naší analogii? Počkejme, než všechny míčky ve vzduchu skončí v rukou příjemců a po tuto dobu nic dalšího neházejme. Jaký je tedy postup tak, aby se potřebný čas zkrátil natolik, že ostatní aplikace pocítí nedostupnost tak krátce, že nedojde k timeoutům?

1. Provést freeze (flush všech operací)
2. Zahájit snapshot
3. Ještě v jeho průběhu uvolnit freeze (změny se píší bokem)
4. Snapshot doběhne a nová data se dopíší

OpenStack – jakou zvolit strategii?

Vypínat VM

První možnost samozřejmě je VM vypnout. Jasně, do produkce to není nejlepší nápad, ale vývojové a testovací prostředí? Není problém napsat si jednoduchý skript, který v noci vypne vývojové VM, provede zálohu a zase je nastartuje. Konzistence zaručena.

Používat crash konzistentní backup

Pro většinu úloh je to postačující. Přemýšlejme třeba takto – chcete dělat zálohu jednou denně a nakoupíte řešení na aplikačně konzistentní zálohu a zaintegrujete s OpenStack. Druhá možnost je, že budete dělat crash konzistentní backup jednou za 12 hodin. Pakliže je pravděpodobnost rozchození zálohy třeba jen 90% tak ale vy máte místo jedné denně připravené dvě. Pravděpodobnost, že jedna z nich bude fungovat je 99%. Pokud je výchozí pravděpodobnost (třeba u OS) 99%, tak máme jistotu 99,99%. Pokud máte inteligentní storage s deduplikací, nebude vás taková strategie stát ani mnoho místa navíc. Pro vývojové a testovací prostředí? Neváhal bych.

Napsat si vlastní aplikačně konzistentní backup

Zálohovací software, jak už jsem popisoval, volá některé zabudované technologie, API nebo skriptem provede freeze – možná to zvládnete sami.

Integrovat externí řešení

Můžete použít libovolné komerčně dostupné řešení integrované do VMware (pokud používáte ve svém OpenStack prostředí) nebo KVM či přímo do OpenStack. Funkci zálohování tak můžete vyvést zcela mimo drápy OpenStacku.

Psát cloud native aplikace

Proč? Jsou bezestavové, takže zálohovat jejich VM je naprosto zbytečné. Nic z předchozího jednoduše nepotřebujete – ale o tom až někdy příště.

OpenStack Freezer: Backup as a Service

Pár Irů z HP založilo open source projekt Backup as a Service pro OpenStack s názvem Freezer. Cílem je zavést aplikačně konzistentní zálohování přímo do prostředí tenantů v OpenStack včetně integrace do GUI (Horizon). Ještě letos bude použit v HP Helion OpenStack, zatím pro zálohování sebe sama (rozuměj backup control plane), ale jak bude tento projekt dospívat, určitě se později objeví i pro použití pro vaše VM. Koukněte na informace o projektu: https://launchpad.net/freezer

Proč zálohovací software?

Myslím, že důvodů je spousta, ale samotná záloha to už ani není. Spíše jde o vlastnosti jako je deduplikace přímo uvnitř VM samotné (snížení potřebného datového toku), uživatelská přívětivost, možnost obnovovat jednotlivé elementy z vnitřku zálohy, verzování a tak podobně.

Zálohování v Helion OpenStack má více řešení, snad vám tento příspěvek pomůže s výběrem ideální strategie pro vaše prostředí.