Prototyp deduplikace záloh virtuálních serverů

Zálohování

Zálohování je součástí každé infrastruktury a jiné to není ani u nás.

Běžné servery se snažíme zálohovat vždy tak, abychom byli co nejblíže provozovaným aplikací. Během zálohování tedy používáme celou škálu nástrojů tak, abychom zajistili maximální konzistenci záloh. Např. pro MySQL databází u většiny instancí využíváme mysqldump. Ve specifických případech pak zálohujeme celou instanci pomocí xtrabackup) včetně transakčních logů, čímž můžeme obnovit databázi až do požadované transakce.

Zálohování virtuálních serverů

Zálohování celých virtuálních serverů je trochu komplikovanější, protože neznáme aplikace, které v nich běží, a do samotných serverů nemáme ani přístup. V takovýchto případech zálohujeme celé obrazy virtuálních serverů, přičemž samotné zálohování je velmi jednoduché. Nejdříve se vytvoří snapshot serveru, následně se zkopíruje celý obraz serveru a na konci se snapshot odstraní.

Všechny obrazy jednotlivých virtuálních serverů, které stáhneme jsou vždy uchovány na zálohovací serverech ve stejné podobě, v jaké jsou uložené na originálním serveru tak, abychom mohli image buď rovnou spustit nebo jej bez velkého přemýšlení obnovit.

Cíle prototypu

Řekli jsme si, že by bylo zajímavé zjistit, kolik místa bychom ušetřili deduplikací těchto obrazů, kdybychom deduplikovali jednotlivé bloky.

V rámci testu také porovnáme 2 extrémy. V prvním testu rozdělíme zálohy na velké 10MB bloky, v druhém testu na velmi malé 128kB bloky.

Pro jednoduchost jsme při testu použili hashovací funkci md5. Pro další vývoj bychom volili asi již nějakou jinou - nejspíše sha256.

Předpoklady

Základní předpoklad, se kterým při deduplikaci počítáme je, že se velká část dat na serverech mění minimálně (např. systémové nástroje, atd).

Další faktor, který nám velmi ulehčuje práci, je rychlost výpočtu otisků (hashů) jednotlivých bloků, který se dá dělat už při stahování obrazů serverů přímo za běhu. Procesor to zatíží minimálně a stejně budeme dřív omezeni rychlosti sítě nebo množstvím IO operací.

Prostředí

Udělali jsme si rychlý research a našli jsme, že z filesystémů v současné době deduplikaci podporuje jen ZFS, které má ale obrovské paměťové nároky. Dále pak btrfs, u kterého se ale jedná o experimentální funkci. Pro potřeby prototypu jsme tedy použili běžný filesystém a data sesbíráme na aplikační úrovni.

Testy deduplikace budou probíhat na zálohách serveru, který má označení AD (nejspíše Active Directory) a běží na něm Windows Server 2012. Podle popisu by se tedy mělo jednat o server, kde nedochází k moc velkým změnám. Na hyper-visoru má virtuální server alokováný 225GB obraz.

Test provedeme na 2 zálohách, kde je časový rozdíl 48 hodin.

Prototyp s 10MB bloky

Zálohu rozdělíme na 10MB bloky:

split backup1 -b 10M

A pro jednotlivé bloky následně vypočítáme md5 otisk, který budeme používat k deduplikaci:

md5sum x* | tee backup1.md5

To samé pak provedeme i s druhou zálohou.

Celkem jsme získali 45 056 bloků po 10MB:

cat backup1.md5 backup2.md5 | awk '{print $1}' |  wc -l
45056

Předchozí příkaz trochu rozšíříme a zjistíme, že unikátních bloků je 26 531:

cat backup1.md5 backup2.md5 | awk '{print $1}' | sort | uniq | wc -l
26531

Deduplikační poměr je při 10MB blocích: 1,698

Pro zajímavost se zde hodí dodat, že v rámci jedné zálohy je i 308 bloků duplicitních:

cat backup1.md5 | awk '{print $1}' | sort |  wc -l
22528
cat backup1.md5 | awk '{print $1}' | sort | uniq | wc -l
22220

Prototyp s 128kB bloky

ZFS používá deduplikaci 128kB bloky. Zkusíme tedy test opakovat test s tím, že soubory znovu rozděíme na menší bloky:

split backup1 -b 128k

Celkový počet bloků je 3 604 482:

cat backup1.md5 backup2.md5 | awk '{print $1}' | wc -l
3604482

Celkový počet unikátních bloků je 1 769 364:

cat backup1.md5 backup2.md5 | awk '{print $1}' | sort | uniq | wc -l
1769364

Deduplikační poměr je v tomto případě: 2,037

Stejně jako v předchozím případě se pro úplnost podíváme na počet duplicitních bloků v rámci jedné zálohy, kterých je 113 109

cat backup1.md5 | awk '{print $1}' | sort |  wc -l
1802241
cat backup1.md5 | awk '{print $1}' | sort | uniq |  wc -l
1689132

Komprese

Ještě, než se pustíme do vyhodnocení, tak zde zmíním informace o kompresi, kterou u zálohování používáme.

Na zálohovacích serverech používáme ZFS, které podoporuje několik kompresních metod. My používáme lz4. U výše zmíněných záloh máme kompresní poměr 2,682:

du -h backup1
82G     backup1
du -h --apparent-size backup1
220G    backup1

Vyhodnocení

Je potřeba si uvědomit, že naměřené hodnoty jsou jen mezi 2 obrazy virtuálních serverů. Pokud bychom vzali v potaz, že držíme historii 14 dnů, tak se můžeme dostat na velmi zajímavý kompresní poměr vůči celé historii záloh virtuálního serveru. Pokud bychom navíc přihlédli k faktu, že značná část virtuálních serverů vzniká jako klon minimalistické image nebo z jiného virtuálního serveru, mohli bychom se s celkovou storage dostat ještě níže.

Je zde ale jedno velké riziko. Při plánování kapacity zálohovací storage není dobré se úplně spoléhat na deduplikační poměr a je dobré si držet dostatečnou záložní kapacitu. V momentě, kdy zákazník např. reinstaluje server nebo změní filesystém serveru, tak se může výrazně snížit i deduplikační poměr. Ve výsledku pak může dojít zálohovací kapacita velmi rychle.

Zatím máme náklady na zálohování relativně nízké a na zálohovacích serverech si bohatě vystačíme s kompresí, která má už těď parádní poměr. Deduplikace je ale cesta, kterou se vydáme v momentě, kdy ušetřená kapacita bude mít vyšší hodnotu než čas, který do vývoje budeme muset investovat. Nebo pokud příjde produktový požadavek, abychom drželi zálohy s výrazně delší historií.

Otázkou dalšího meření bude určení správné velikosti bloků, na který rozdělíme originální soubor.

Témata

Podobné články