Na téměř neslužebním setkání s firmou M Computers, která dodává především servery a storage a specializuje se na superpočítače a AI, byl hostem také Petr Krstev, IT administrátor Sherlog Technology. Právě v té méně služební části při grilování začal pomyslně grilovat některé dodavatele a praktiky ohledně deduplikace. Takže jsme se domluvili na setkání a rozhovoru.
Co je ve stručnosti deduplikace?
Deduplikace je postup, který vede k odstranění duplikací dat, tedy jejich opakování. Ještě bych podotknul, že deduplikace zde byla dávno před IT a počítači vůbec. Například zákoníky jsou plné deduplikací, na nějakém místě je odvolávka na jiný zákon. Místo toho, aby tam byl přímo citovaný text, je tam jen odvolávka na číslo paragrafu, případně odstavec. Podobně se dělají odvolávky v IT, pouze je třeba odlišit, upřesnit, jakou deduplikaci máme na mysli, protože deduplikací máme více druhů. Rozlišujeme deduplikaci na přenosu dat a deduplikaci na ukládání dat. Deduplikace na přenosu dat už s námi je od nějakých 60. let minulého století, kdy se data posílala mezi modemy po telefonu, a bylo cenné ušetřit přenášená data. Proto se hledalo v již poslaných datech to, co poslat chci, a pokud jsem mezi nimi našel alespoň částečnou shodu, už jsme jen řekli „přečti si to z dat, co už jsi dostal, tam a tam“. Nás asi zajímá spíše ukládání dat, respektive zmenšení dat objemu při jejich ukládání. Zde je to podobné, snažíme se zmenšit prostor, na který data ukládáme. Deduplikace je podmnožinou komprese dat, tj. jedna z možností komprese dat. Řada kompresních algoritmů v sobě nese deduplikační postupy.
Kdy se v historii s deduplikací v IT začalo, od jakého technologického stupně pokroku?
S deduplikací při ukládání dat se začalo zhruba v 80. letech minulého století, kdy se používala u páskových jednotek, zachraňovala tím cenné pásky od opakovaného ukládání stejných dat. Když se pak koncem století začaly používat disková pole s virtualizací, začala se deduplikace používat i tam. Když jsme v roce 2008 nakupovali VTL (Virtual Tape Library, virtuální pásková jednotka) u které mi výrobce rovnou řekl, že neprovádí porovnání nových dat která přicházejí s již uloženými. Od onoho výrobce mi to přišlo čestné, ale vzhledem k zamýšlenému použití na zálohování jsme s tím souhlasili. Kdyby šlo o primární úložiště, a nikoliv VTL, tak bych to takto nechtěl. Mimochodem, právě u této VTL jsem zaznamenal ztrátu dat vlivem deduplikace. Zapsaná a přečtená data se nekryla s originálními daty. Počítal jsem s tím předem a ztráta nebyla fatální. Tou dobou jsme ve VTL měli zapsáno cca 80 TB dat a kontrolovaná data měla cca 120 GB. Od té doby vždy, když jsme zamýšleli pořídit nějaké nové úložiště a výrobce tvrdil, že umí deduplikaci, moje první otázka zněla, jak řeší kolize hashe.
Jak se deduplikace provádí?
Deduplikace se většinou provádí tak, že hledáme nově zapsaná data v datech již uložených. Pokud taková data najdu, pak místo abych je znovu uložil, umístím jen odkaz na data již existující. Výsledkem jsou dva odkazy na stejné místo v databázi jedinečných dat (vzorků). Pokud nová data nemám dosud uložena, zkompresuji je a umístím do databáze jedinečných vzorků a vytvořím na toto místo odkaz. Protože se deduplikace provádí na softwarové vrstvě, je zapotřebí ji spojit s virtualizací úložiště. To znamená, že musím mezi klienta (typicky server) a poskytovatele úložiště (diskové pole) vložit softwarovou vrstvu, která onu virtualizaci provede. Tato vrstva může být součástí úložiště, nebo je samostatná. Provádí se zde tzv. úplný překlad adres bloků. To znamená, že blok na adrese XY, který poslal server na disk (LUN), se musí uložit do úložiště na adresu PQ. Pokud už tam takovouto virtualizaci úložiště mám, mohu začít dělat další kouzla, jako například přesouvat virtuální disky (LUNy, vDisky, atd.) v rozsahu úložiště někam jinam, případně i na jiné úložiště, vytvářet snapshoty a, kromě jiného, mi umožňuje provádět deduplikaci. Ta mi nakonec může s výhodou pomoci i při zvýšení výkonnosti, protože pokud chci načíst 1 TB dat, a v něm existují nějaké duplikáty, pak je nemusíme číst opakovaně. Daný blok už je třeba ve vyrovnávací paměti cache a nemusíme jej načíst znovu. Záleží na tom, jak dobře je software napsaný.
Petr Krstev
Může dojít při deduplikaci ke ztrátě dat? Pokud ano, v jakých případech?
Záleží na tom, jak se deduplikace provádí. Většinou se používá výpočet hashe, což je postup, kdy většímu množství dat vypočítáme sekvenci bytů. Například ke 4KB blokům, které jsou pro blokové storage typické, přiřadíme hash, která má třeba 64 bytů. Pomocí takového hashe pak mohu předpovědět, zda jsem tento blok už před tím uložil či nikoliv. Když už hash používáme, má nějaké vlastnosti. Jednou z nich je, že může dojít k tzv. kolizi, což definujeme jako stav, kdy dva různé bloky dat mají stejný hash. Je to záležitost matematiky a dá se říci, že bloky různých obsahů, pokud jsou větší než je velikost hashe, musí nutně mít stejný výsledný hash. Znamená to také, že pokud je různých dat dostatečné množství, musí k nějakým kolizím vždy dojít. Bavíme se zde o pravděpodobnostech. Když je ukládaných dat málo, je pravděpodobnost kolize velmi nízká. Až když je dat hodně, pravděpodobnost kolize hashe roste, až je významná. Pak už jen záleží na tom, jak se k takové kolizi hashe zachováme. První možnost je kolizi ignorovat a ke každému hashi ukládáme pouze jeden vzorek dat (většinou první, někdy poslední). Druhá možnost je s kolizí předem počítat a nová data porovnávat s těmi, které už máme a mají stejný hash a při neshodě obsahu nová data uložit.
Lze ztrátu dat eliminovat, případně jí úplně zamezit?
Pokud chci ztrátě dat zamezit, pak musím už uložená data porovnávat s daty, která nově přišla, a pokud mám blok, který ještě uložený není, musím jej nově uložit k těm, které už uloženy jsou se stejným hashem. To znamená, že jako programátor musím už od začátku připustit, že existuje víc bloků, které mohou mít stejný hash, a takto s tím pracovat.
Jak se chovají výrobci?
Jsou výrobci, kteří kolize neřeší. Problém s kolizemi tají. Když na ně zatlačíte, tak říkají, že kolize hashe je tak málo pravděpodobná, že nemá smysl se jí zabývat. Klidně vám to řeknou i na konferenci jako potenciálnímu zákazníkovi, i když v praxi to znamená, že si uložíte dva různé bloky dat, a při jejich čtení získáte jen první z nich, když čtete ten druhý, nebo obráceně. U primárního úložiště jde, podle mě, o naprosto nepřípustný stav, u sekundárního by se toto dalo teoreticky tolerovat, ale jen za určitých okolností. Naprosto bych to netoleroval u archivace, kde vše, co do archivu vložíte, z něho také musíte identicky přečíst. Dále jsem se setkal s výrobci, kteří vám sami řeknou, že jejich úložiště kolize neřeší, že o problému vědí a nechávají na zákazníkovi, zda je pro něj takové úložiště vhodné. A potom jsou výrobci, kteří mají kolize ošetřené a dokonce vám na to dají certifikát.
Můžete porovnat časovou a finanční náročnost deduplikace před dvaceti, deseti lety, když byly k ukládání dat používány točivé disky, s dneškem, kdy jsou k dispozici rychlá flashová pole?
Když se data začala ukládat na točivé disky, bylo to samozřejmě lepší než u pásek, ale stále ještě bylo poměrně drahé porovnávat stávající data s těmi, která nově přišla. Drahé z hlediska financí, času i výkonnosti řídících jednotek, které deduplikaci prováděly. Řešení byla různá. Například se deduplikace prováděla Offline, tedy se časově odložila na dobu menší zátěže. U přenosově velmi zatížených polí toto nebylo možné ani praktické. Také se často sahalo k použití hashe na kryptografické úrovni, aby ke kolizím docházelo co nejméně, a pak se porovnávání obsahu neprovádělo/zanedbalo. Výpočet takových hashů je ovšem pro jednotku náročný, proto se někdy používaly HW akcelerátory.
Postupem času se zrychlovaly disky, používala se vetší cache a zvětšovala se výpočetní výkonnost jednotek úložišť. Největší průlom přineslo až použití pamětí FLASH namísto točivých disků pro ukládání dat. Pro AllFlash pole již není takový problém porovnávat nová data se starými. Také není třeba používat hashe kryptografické úrovně. Stačí tzv. Fast hash. Rychle se počítá, nezatěžuje tolik jednotku a nepotřebuje HW akcelerátor. Moje zkušenost mi říká, že není třeba deduplikaci provádět Online, protože zdržuje zápis, ale stačí Near-Online. Data se přijmou, uloží se bez deduplikace a potvrdí se rychle zápis. Poté se provede deduplikace s nižší výpočetní prioritou.
Stále existují hybridní pole, které mají flash paměti i točivé disky, ale u těch je porovnávání s daty na discích nejméně o dva řády pomalejší.
Také existují pole, výrobcem označené jako all-flash, a přitom mají flash paměti připojené k řadiči jako disky SAS nebo FC. To je ovšem degradace all-flash na úroveň hybridních polí.
Existují vůbec výrobci, kteří dodávají deduplikaci tzv. hash-collision-free?
Určitě, sami taková pole provozujeme, ale takových výrobců je menšina.
Kromě toho, v roce 2009 se objevila schopnost deduplikace u souborového systému ZFS u OS Solaris. Zde má deduplikace dva režimy práce. V jednom módu porovnávání neprovádí, nezabývá se jím, a ve druhém ano. Pak už je na člověku, který systém nasazuje, zda porovnávání zapne či nikoliv. Osobně myslím, že by se implicitně porovnávat mělo, s možností jeho vypnutí administrátorem, pokud si řekne, že jej nepotřebuje; u ZFS je ale implicitně porovnávání vypnuto. Od systému ZFS existují různé odvozeniny a některá úložiště je používají s vypnutou funkcí porovnávání.
Jak se provádí deduplikace dat v dnešním virtualizovaném prostředí, když jsou data rozprostřena přes více úložných zařízení, případně více geografických míst?
Dnes se provádí deduplikace na několika úrovních. Buď na straně klienta/serveru. Pak je deduplikace platná pouze na tomto místě. Lépe je ale ji provádět na nějakém uzlu, přes který tečou všechna data. Čím více dat jsem schopen uchopit, tím větší zisk deduplikace má. U výkonnosti deduplikace většinou uvádíme poměr mezi daty před a po deduplikaci. Například náš deduplikační poměr 1 : 6 znamená, že bychom bez deduplikace potřebovali šestkrát víc prostoru; jde o poměrně normální hodnotu pro náš typ dat (SQL). Při deduplikaci lze ale dosáhnout až dvouciferných hodnot, klidně i 1 : 30 až 1 : 50. Záleží totiž na tom, jaká mám data, jestli na serverech provozuji databáze, virtuální desktopy, nestrukturovaná data, soubory, to všechno hraje při stupni deduplikace roli, a to se ještě předpokládá, že za deduplikací nastává komprese, která výsledné ukládané bloky ještě zmenší. Jsou výrobci, kteří nabízejí storage s deduplikací, a rovnou zaručí deduplikační poměry pro určitý typ ukládaných dat.
V případě geograficky distribuovaných dat, kdy ukládám data nikoliv do jednoho místa, jednoho úložiště, ale do lokací, sleduji dva cíle: zabránit ztrátě dat a zvýšení výkonu. I tak je možné a žádoucí deduplikaci provádět. Zde potom nastupují pokročilé postupy. Je třeba rozdělit databázi jedinečných vzorků podle nějakého klíče na jednotlivé uzly. Počítání hashe často provádí klient. Zbytek deduplikačního postupu provede uzel. Uzel udržuje tabulku pouze svých hashů a má tak s tím méně práce. Pro zamezení ztráty dat celého uzlu, uzel posílá svoje data ještě na další uzel či uzly. Máme tak všechna data uložená na více než jednom místě.
Takže je možné pořídit pole a nebát se o data?
Jistě, jen musím o problému kolizí hash vědět a chtít od dodavatele odpověď.
