Výkonnostní aspekty nejen zálohování dat
Se zálohování dat se pojí i otázka výkonu celého řešení – tedy za jak dlouho zazálohuju a obnovím data? Bohužel je smutným faktem, že si část IT populace tuto otázku neklade a nestačí se pak divit ... pojďme tedy věnovat chvíli času disputaci na toto téma.
Pravidlo 3-2-1 stokrát jinak?
Každý kdo se jen trochu ochomýtl kolem zálohování dat jistě o pravidlu 3-2-1 slyšel, je ovšem "vtipné", že každý dodavatel zálohovacího řešení ho interpretuje jinak - tak, aby odpovídalo právě jeho schopnostem a omezením. Nejprve si proto musíme srovnat noty v této "3-2-1" definici. A nedejte se zmást tím, že vám někdo bude vysvětlovat, že "to je přece jinak", strejda google vám bude tvrdošíně vylistovávat 100x opakovanou vadnou definici 3-2-1 - na správnou odpověď stačí selský rozum!
Je jistě zřejmé, že při řešení přesunu dat je musíme vzít z primárního umístění, přenést a uložit na cílové sekundární úložiště (alias repository), ev. na úložiště terciální. A v optimálním případě podle mého* názoru potřebujete:
3 - kopie dat, ve
2 - lokalitách a z toho
1 - kopie nesmí být přímo zranitelná = musí být v off-line režimu.
V off-line režimu proto, že si jistě dokážete představit situaci, kdy se chybou administrace nebo ransomwarem dostanete na primární (diskové) i sekundární (typicky opět diskové) úložiště - a přijdete tak o primární data i o zálohu. Co byste v takovém případě dali za nepoškozenou (protože off-line) kopii dat v trezoru? A věřte - cloud není off-line, jak se vám leckdo bude snažit nakukat, nýbrž jen off-site!
Tuto definici lze zajistit různě: například schémata D2D2T (disku>disk>páska), kde je sekundární disk nebo páska v jiné lokalitě; či D2C2R, kde R je úložiště s nastavitelnou retencí běžnými prostředky nepřepsatelné ... i takto může být zajištěn požadavek na off-line. Takovým úložištěm je třeba klasika - EMC Centera.
*Abych zmínil příklad jiné interpretace pravidla 3-2-1 od věhlasného Veeam, shodneme se jen na 3 kopiích, ale pak tvrdí, že na dvou různých médiích a jedna kopie má být off-site. Že to vypadá podobně? No pokud na to navážete popisem implementace, že za dvě různá média považujete primární storage + cloud resp., že cloud je ta off-site lokalita, rozdíl bude zjevný => tvrdí, že stačí vzít D2D2C schéma a je hotovo. To, že touto interpretací máte všechny tři kopie instantně přístupné a tedy zranitelné, je netrápí - ale dobře to odpovídá cílení na prodej Veeam Cloud Connect řešení;)
Rychlost dodávky a akceptace dat na disková úložiště Obecně se bavíme o přesunech dat z místa na místo a je celkem lhostejno, zda jde o repliku, zálohu či obnovu. Zkušený ITýk jistě slyšel o tom, že výkon diskového pole je definován hodnotou IOPS (vstupně-výstupními operacemi za sekundu), ev. typem, počtem a konfigurací disků. Pojďme si ale připomenout, jak to skutečně je – tyto tři faktory jsou ve hře vždy:
Předně nemá smysl se bavit o „nějakých IOPSech“, nýbrž vždy musí zaznít režim, ve kterém byly vypočteny či změřeny. Je totiž podstatný rozdíl mezi transakčním provozem (typicky poměr čtení a zápisu 60/40) a sekvenčním režimem (kdy převažuje čtení či zápis). Zatímco totiž při transakčním režimu může pomoci vyrovnávací paměť (cache) na disku či kontroléru, při sekvenčním režimu práce jí brzo dojde dech a výkon je determinován jen a jen disky. Proto taky IOPS R/W 60/40 jsou vesměs 10x vyšší než hodnoty sekvenční! Příklad: totéž pole může mít IOPS RW60/40 přes 50k, zatímco čisté sekvenční čtení 5k a zápis jen 3k.
Druhým aspektem je velikost použitých bloků, neboť výsledný datový tok bude součinem hodnoty IOPS a velikosti bloků. Tudíž jen změna v rámci běžného rozptylu od 8 do 64 kB na blok může způsobit řádový rozdíl.
No a konečně vlastní disky – ignorujte všechny nesmysly o megaIOPSech, které s oblibou publikuje většina výrobců a jsou zcela mimo realitu! U rotačních disků je obvyklá hodnota kolem 200 na jeden rychlý SAS, u SATA disků budete rádi za 100 IOPS/disk. Tedy svazek např. 8 disků SATA bude mít v prvním přiblížení max. 800 IOPS, při velikosti 8kB/blok tedy 6,4 MB/sec. A to dělá pouhopouhých 23 GB/hodinu. Ano – je to tak, pouhých 23 gigabajtů za hodinu!! Běžnější 32 kB bloky pak do 100 GB/hodinu atp. Po pravdě – RAID5 či RAID6 vás potrestá za úsporu místa penalizací na výkonu a bude to min. o 20-30% méně, odtud pak typická hodnota 60 - 80 MB/s.
Analogicky lze postupovat u dalších typů, konfigurací atp. Ušetříme čas a
podíváme se rovnou na výsledky z reálného světa:
Velikost bloků vše nespasí Malý český člověk je zvyklý nalézat alternativní cesty, to jistě patří k naší národní mentalitě stejně jako brblání na poměry. Tedy proč nezvýšit výkon prostým zvětšením velikostí bloků? Tak jednoduché to ovšem není, neboť:
Primární úložiště (kde máte databázi či poštu) by mělo být optimalizované dle požadavků aplikací. U databází je to zpravidla 64 kB, u pošty a souborových systémů naopak 8 kB.
Zvětšení velikosti bloků může znamenat plýtvání místem, protože neúplně zaplněné bloky = plýtvání (pokud tedy nemáte pole vyšší třídy ala HPE 3PAR, které pracuje s malými chunklety a tento problém si vyřeší sdružením jakkoliv velkých segmentů do zaplněných bloků).
Přenášení velkých bloků u SAN iSCSI znamená segmentaci (a tedy vyšší režii při přenosu) na úrovni datagramů, i ty největší Jumbo pakety mají „jen“ 9 kB.
A problém může rovněž vzniknout, pokud se liší velikost bloků výchozího a cílového úložiště - zvláště pokud máte zapnuté šifrování. Tento rozdíl ve velikosti bloků pak zpomalí výměnu dat i několikanásobně.
Celý systém by tedy měl být navržen s ohledem na další aspekty a hlavně yváženě, vč. přenosové trasy! Pro rotační disky si vystačíte s SAN iSCSI 1GE či lépe s FC 8G. Pro all-flash pole SSD ale nešetřete a pořiďte si iSCSI 10GE či FC 16G.
Nejen disky živí data aneb „ať žije páska?“ Nejprve si tedy zrekapitulujme, co vyplývá z tabulky výše – ať se budete snažit sebevíc, tak v oblíbeném modelu zálohování D2D s použitím SATA disků na sekundárním úložišti vesměs „nenatočíte“ více jak 5 TB/24h, a může to být i méně. A to se bavíme o záloze, obnova bývá zpravidla citelně pomalejší – tím víc, když se jedná o velké množství malých souborů. Takže nevím nevím, zda IT získá pochvalu až bude takto obnovovat kapacity desítek TB (nic neobvyklého u běžných SMB/E firem natož v ENT sféře) v případě havárie ... celý týden? U toho bych nechtěl být odpovědnou osobou! A zde tedy nezbude, než si vzpomenout na řadou ITýků „opovrhovanou“ pásku, dnes prakticky jedině LTO. Když se podíváte do následující tabulky, uvidíte poněkud jiné hodnoty než u disků – hodinová maxima jsou super a blíží se 3 TB/h, kapacity na jedno médium se již v poslední generaci TO8 vyšplhaly na 30 TB (s kompresí 2,5:1).
Takto vysoký výkon působí jiný problém, na který chci upozornit – a tím je minimální rychlost „přítoku“ dat do mechaniky. Ta totiž sice umí zpomalit otáčky, ale nikoliv na nulu, nýbrž zhruba na třetinu maximální rychlosti. U LTO čtvrté až šesté generace tedy potřebujete dodat min. 50 MByte/sec a to BEZ komprese!! S tolik užitečnou kompresí pak min. 2x tolik, jinak se páska bude zastavovat (tzv. šoupání), proces zálohy se zpomalí o řád a mechanika bude za pár měsíců zralá na výměnu. Z toho ovšem plyne, že hiearchická záloha D2D2T s meziúložištěm na SATA discích bude fungovat jen za ideálních podmínek, a to ještě na starších generacích jako LTO4. S postupně narůstajícím požadavkem na minimální přítok dat a zlepšením komprimačních mechanismů už to nepůjde... stačí se podívat na parametry LTO7/LTO8 – nativně min. 100 MB/s bez komprese resp. 250 Mb/s s kompresí – a to jiný zdroj než all-flash pole těžko poskytne. Takže až někdo ohrne nos nad LTO páskou, je namístě mu připomenout prostý fakt => 1 TB trvá na rotačních discích několik hodin (na SATA/NL typicky 8)... zatímco na pásce pouze 30-60´podle typu. Páska je tedy průměrně 8x rychlejší než tak oblíbené diskové sekundární repository na SATA. A je citelný rozdíl, zda vaše 10 TB data budete obnovovat 3 dny či jen 8 hodin. Co na to vaše provozní SLA? A pak, že je páska mrtvá ...
A na téma BaaS tj. Backup as a Service (kterážto fantasy předpokládá, že podobné operace s jednotkami či desítkami TB budete denně provádět po internetu z vašeho datového centra kamsi do cloudu) se zasmějeme někdy jindy :-D
