Dotaz: Výběr deduplikovacího souborového systému

[atrak]

Ahoj. Mám backup server s diskovým polem o velikosti 6 TB. Zálohuji na něj servery a klientské stanice. Zálohovaná data (zvlášť u těch stanic) jsou z většiny naprosto totožná, proto chci nasadit na backup server nějaký deduplikační souborový systém. Našel jsem následující možnosti:

• ZFS
  výhody: zřejmě dost odladěné
  nevýhody: musel bych z linuxu přejít na freebsd nebo třeba na openindiana; na 1 TB dat potřebuje pro deduplikaci až 6 GB RAM
• SDFS (http://opendedup.org/)
  výhody: ?
  nevýhody: napsané v javě, nemožnost používat příkaz df, většina příkazů vrátí java Exception (to už o kvalitě tohoto fs něco napovídá) - funguje z LANG=C (problém s českou desetinnou čárkou), ..., pro detekci stejných bloků používá hashování
• LessFS
  výhody: napsané v C
  nevýhody: pro detekci stejných bloků používá hashování
• DDumbFS
  výhody: napsané v C
  nevýhody: pro detekci stejných bloků používá hashování

Poslední zkoušený systém DDumbFS je "nejlehčí" - umí jen deduplikaci, což mi vyhovuje. Rovněž funguje spolehlivě (to i LessFS). Nicméně mám zásadní problém s tím, že to používá pro detekci stejných bloků hash funkci => při hash kolizi mohu přijít o data. Co používá ZFS nevím, ale ten jeho paměťový nárok je nesplnitelný.

Jaký deduplikační systém používáte vy nebo jaký byste mi doporučili?

Odpovědi

[kyytaM]

Nie je moznost pouzit zalohovaci SW, ktory robi deduplikaciu sam o sebe? Myslim, ze napr. BackupPC to vie. :)

[atrak]

Hledám něco, co umí deduplikaci na úrovni bloků, BackupPC umí jen na úrovni souborů.

[Josef Kufner]

A vadí, že by to bylo na úrovni souborů? Pokud záloha vypadá tak, že máš adresář, kde je nakopírovaný filesystem ze zálohovaného stroje, tak to bude v pohodě, ne?

[j]

Rek bych ze to vadi celkem zasadne, protoze to bude razantne vetsi. Zkus si predstavit, ze mas 2x 100GB databaze, ktera je z 99% totozna ... => budes tam mit 200GB nebo 101GB ... celkem rozdil, ze...

[Josef Kufner]

Pokud má tazatel takto velké a takto podobné soubory, tak pak jo. Otázkou je, zda takové soubory má a zda jich je dost na to, aby to vadilo. U pracovních stanic to prakticky nehrozí, u serverů zas je celkem malá šance na tak velikou podobnost.

[dustin]

Pokud jsou ty databáze živé, tak stejně taková záloha s dost vysokou pravděpodobností nebude fungovat a to i přes filesystémový snapshot. DB bych zálohoval jejich nástroji, ne přes filesystém.

Používáme již roky backuppc a jeho deduplikace je docela obstojná a spolehlivá. Momentálně máme zabráno cca 50 mil. inodů, soubory jsem nepočítal, odhaduji tak 5x více.

Běží na XFS, 3GB RAM, pro xfs_check (/repair) to vyžaduje připojit do externí esata kolébky ssd disk jako swap, pak doběhne za pár hodin. Kolébky jsou tam stejně pro pravidlné kopírování na offline disky, takže jde o triviální úkon.

[MilanK]

ZFS je i na linuxu [1], byť se doporučuje pouze 64bitová architektura. Z dotazu není jasné, zda to pole je redundantní či nikoliv. (Případné snížení rizika při redundanci.)

Paměťové nároky při deduplikaci souvisejí s velikostí bloku a lze je snad trochu snížit použitím L2ARC [2] na SSD. Ale stále to nepochybně bude velký "žrout". Paměťové nároky jsou dány zpracováním v režimu "pre-write dedup".

Hash funkci u ZFS lze zvolit, standardně je tuším SHA256. Pokud ji nevěříte, umí pracovat v režimu zpětného ověřování dat už při zápisu a při kolizi to nějak vyřeší.

[1] http://comments.gmane.org/gmane.linux.file-systems.zfs.user/2911 [2] http://mail.opensolaris.org/pipermail/zfs-discuss/2011-May/048171.html

[atrak]

To diskové pole je software raid 5. Server má k dispozici jen 5 GB RAM. Když jsem na svém PC zkoušel DDumbFS, tak pro 4 TB svazek o velikosti bloku 64k mi to zabralo něco přes 2,5 GB RAM. Kdybych se u ZFS vešel na 6 TB do cca 4 GB RAM, tak by nebylo co řešit. Ale podle toho, co jsem našel by bylo potřeba tak 36 GB RAM. Umožňuje ZFS zvolit minimální velikost bloku a zmenšit tak razantně paměťové nároky? Podle toho, co jsem našel má ZFS dynamickou velikost bloku ...

[atrak]

Tak podle http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html jsem si spočítal, že i pro 128k bloky bych potřeboval 15 GB RAM.

[atrak]

Napadlo mě dát DDumbFS přímo na diskový oddíl, takže DDumbFS by pod sebou neměl žádný fs. Potom ten fs připojit a v něm vytvořit přes dd soubor plný nul a na něm vytvořit btrfs nebo zfs. Takže by btrfs byl uvnitř toho deduplikovacího fs. Tak bych se totiž alespoň mohl dozvědět, jestli jsou data v pořádku (v případě hash kolize v DDumbFS). Je to hodně špatná myšlenka?

[MIlanK]

IMHO, DDumbFS je FUSE FS a vyžaduje pod sebou nějaký FS. Nenašel jsem, jaký má DDumbFS limit na velikost souboru.

Máte tedy v plánu něco takového: nějaký sw raid + ext4 + DDumbFS + ZFS (s kontrolou dat, ale v neredundantním poli, takže bez možnosti obnovení).

Nebo s omezením efektu deduplikace na část raidu:

HDD1 s ext4 + DDumbFS + kontejner1 2 TB
HDD2 s ext4 + DDumbFS + kontejner2 2 TB
HDD3 s ext4 + DDumbFS + kontejner3 2 TB

a poté

ZFS raidz z kontejner1+2+3

(tedy s redundancí a možností obnovení)

Pokud to zkusíte, dejte vědět.

[atrak]

No tak jsem to vyzkoušel a je to nesmysl. Zkoušel jsem na tedy prozatím na kombinaci RAID5->EXT4->DDUMBFS->EXT4. Problém je ten, že pokud vytvořím souborový systém v DDumbFS stejně velký jako velikost DDumbFS, pak vlastně přicházím o výhodu deduplikace. Pokud ten souborový systém vytvořím větší než je velikost DDumbFS, pak sice výhodu deduplikace mám a funguje perfektně (paradoxně lépe než bez té další vrstvy FS), ale po zaplnění DDumbFS přejde Ext4 do read-only módu, protože ačkoliv si myslí, že má ještě nějaké volné místo, tak ve skutečnosti žádné není.

ZFS také vzdávám, protože jsem našel nějaké testy a i při použití SSD jako mezicache je zápis či čtení mnohonásobně pomalejší než s 1 cache v RAM.

Nakonec asi udělám to, že na raid 5 oddílu vytvořím btrfs a uvnitř DDumbFS, takže budu mít výhodu deduplikace v DDumbFS a snapshotů v btrfs. Jenom mi vadí ta pravděpodobnost hash kolize, i když je hrozně malá.

[Nikola Ciprich]

Nakonec asi udělám to, že na raid 5 oddílu vytvořím btrfs a uvnitř DDumbFS, takže budu mít výhodu deduplikace v DDumbFS a snapshotů v btrfs. Jenom mi vadí ta pravděpodobnost hash kolize, i když je hrozně malá.

neberte to jako rypani, ale nemuzu si pomoct - vy to mate na zalohovani nejakych serioznich dat, nebo jako hrani s daty na kterych Vam nezalezi??

[freak]

Pravdepodobnost bugu v celym tom bastlu vam jako vubec nevadi? Na data typu porno si radsi kupte dalsi disky..

[Nikola Ciprich]

presne proto jsem se ptal jestli na tech datech vubec zalezi.. nejaky relativne novy projekt na deduplikaci nad fuse v kombinaci s FS ktery je stale oznacen jako experimental s moznou zmenou formatu, to mi prijde jako dobra ruleta..

[atrak]

Samozřejmě, že mi na datech záleží. Problém je, že je jich moc, datové pole plné a nejsou finance na jeho rozšíření. Když jsem testoval deduplikaci na časti dat, tak deduplikovaná data zabrala místo 800 GB jen cca 250 GB, což už je obrovská úspora.

[atrak]

A místo btrfs vlastně můžu použít něco stabilního (ext4), protože snapshoty udělám jednoduše pomocí příkazu cp (mám přece deduplikaci, ne?).

[linuxik]

HA HA HA, myslis to vazne?

[atrak]

Proč ne? Nebudu samozřejmě kopírovat soubory v DDumbFS, ale v ddfsroot, kde jsou umístěny soubory ve tvaru |adresa|hash|adresa|hash..., takže 1 GB soubor vlastně na této úrovni zabírá 422 KB. Celý snapshot proces může sestávat z této jednoduché kopie, která bude trvat maximálně několik málo sekund. Má to nevýhodu v tom, že během kopírování se mohou původní data v souboru/souborech měnit, nicméně v tomto případě (backup úložiště) k tomu docházet nebude.

[l4m4]

nevýhody: pro detekci stejných bloků používá hashování

A to je nevýhoda proč?

Vy nečetli, a přesto rozmrazili? Samozřejmě, že kolize hashů je ošetřena, v technické dokumentaci se dokonce docela podrobně píše jak.

[atrak]

Já jsem koukal do zdrojáků LessFS, DDumbFS i SDFS a nikde jsem neviděl, že by byla kolize ošetřena. To, co se píše na stránkách DDumbFS se podle mě týká umístění bloků v BlockFilu nežli hashů samotných bloků dat. Všechny tyto souborové systémy spoléhají jen na to, že možnost kolize je extrémně malá.

[l4m4]

OK, pokud jsi četl zdrojáky, tak počítám, že víš, jak je to doopravdy. Což je tedy smutné, čekal bych, že když matchne hash, tak se porovnávají data (nebo alespoň další hashe -- sníží-li se pravděpodobnost o dalších 2^{-128}, tak to už může primární i sekundární zálohovací místo taky současně vyhořet...).

[atrak]

Oni takhle dokonce asi fungují i některá komerční řešení viz. http://www.backupcentral.com/wiki/index.php/Disk_Targets,_currently_shipping. Pravděpodobnost poškození dat chybou pamětí (i ECC pamětí), disků, řadičů, ... je mnohonásobně vyšší než pravděpodobnost kolize, proto na to asi výrobci kašlou.

[linuxik]

Ne ze bych nejak podcenoval bezpecnost ale pri pouziti SHA256 a dejme tomu pri 1 bilionu bloku v dedup filesystemu, je pravdepodobnost kolize 10 na minus 60. To drive skonci nas vesmir velkym krachem, nez se neco takoveho stane. Pouze v pripade ze plati teorie o tepelne smrti vesmiru by jsi mel sanci, pokud se driv nerozpadnou vsechny protony

[atrak]

Na 64bitové architektuře všechny tyhle FS používají plný Tiger-192 hash, protože je podle všeho nějak akcelerovaný či co, ale i tak je ta pravděpodobnost velice malá. Hlavní problém může být v tom, že tohle je teoretická pravděpodobnost. Prakticky může být o dost vyšší (špatný návrh algoritmu, špatná implementace).

[lertimir]

Tedy mě to připadá jako blábol někoho, kdo není zvyklý počítat s velkými čísly. Jako když při spouštění LHC neznalci mluvili o zničení země černou dirou vyrobenou v tom CERNu O čem to mluvíte?

Špatný návrh algoritmu? Tiger je z roku 1996, byl podroben už dost silné kryptoanalýze a jsou samozřejmě konstrukce kolizních útoků, ale ty jsou na redukovaný počet rund a není znám žádný útok snižující bezpečnost a odolnost proti kolizi pro plný Tiger.

Špatná implementace? Tady je to citlivější téma, chybná implementace typicky vyrábí další informaci například v čase zpracování a pak je využití této informace cílem útoků tzv. postranními kanály. Ale Tiger je jednoduchý hash vlastního disku, buď na konci výpočtu máme cílovou a kontrolovatelnou hodnotu nebo ne.

Navíc Vaše argumentace není o cíleném útoku, ale o náhodné kolizi. Máte přestavu jaké jsou to pravděpodobnosti?

V roce 2010 před krizí byly čtvrtletní prodeje disků někde pod 170 miliony kusů tedy ročne 610mil cca 2^30 kusů, předpokládejme (nadsazenou) zivotnost disků 16 let. a předchozí prodeje ve stejné výši. tedy je v provozu 2^34 disků. Nechť všechny disky zapisují maximální rychlostí cca 256 MB/s to je 512 tisíc sektorů za vteřinu. tedy 2^19 sektorů. Dohromady všechny disky na planetě zapisují v této nadsazené úvaze 2^53 sektorů. Otázka je jak dlouho, by musely ty disky běžet, aby pravděpodobnost vygenerování stejného hashe byla větší než zadaná hodnota (limit). Stejný hash myslím mezi všemi možnými již dříve použitými hashi. Díky "narozenivému paradoxu" je to projítí 2^((192-ln2(limit))/2) možností, kde ln2 je dvojkový logaritmus čísla. pro např. pravděpodobnost 1 miliontinu to znamená 2^((192-20)/2) = 2^86, takže teprve za 2^(86-53)=2^33 sekund nastane situace, kdy pravděpodobnost, že za celou tu dobu ve dvou discích na celé planetě byly dva různé sektory se stejným hashem, přesáhla jednu miliontinu. A 2^33 sekund je něco přes 272 let. Nebo jinak, za dobu životnosti disků řekněme (16 let) se pravděpodobnost, že za celou dobu se vyskytly ve dvou sektorech všech disků planety v libovolném čase dva stejné hashe je pod 10^(-9).

Kolize těch vašich několik TB opravdu neohrožuje.

[l4m4]

Toto je argument, že slow path řešící kolize může být fakt very slow. Ale že by tam vůbec neměla být, tj. že i teoretický návrh může fungovat pouze pravděpodonostně... Chytnou-li se této myšlenky vývojáři software obecně, skončí to u programů, které budou fungovat ve čtyřech případech z pěti.

[Josef Kufner]

Ono to tak ale často opravdu je. Pokud je pravděpodobnost chyby dostatečně nízká a případné škody akceptovatelné, tak se na to prostě kašle, protože se to nevyplatí řešit. Spousty algoritmů jsou jen aproximace, které teoreticky nemusí nikdy doběhnout, ale většinou doběhnou výrazně dřív než jejich exaktní varianty.

[l4m4]

Jistě, ovšem když používám Marquardt-Levenbergův algoritmus k fitování, tak rozumím a akceptuji, že může dokonvergovat k ledasčemu. Není to ovšem vlastnost, kterou bych tak snadno akceptoval u zálohování...

[linuxik]

Prave naopak, pokud je pravdepodobnost selhani ostatnich komponent radove vyssi ( v tomto pripade minimalne o 40 radu) nema zadnou cenu resit hash kolize. Tim ze pridate do aplikace dalsi kod, ktery bude mit take nejakou pravdepodobnost vyskytu chyby, muzete ve skutecnosti problem jeste zhorsit. Chapu ze vyrobci enterprise reseni neco takoveho delaji, ale matemeticky je to nesmysl a slouzi pouze k uklidneni manageru, kteri neco o hash kolizi zaslechli.

[FooBar]

Deduplikacni reseni jsou natolik niche market, ze bych se bal cokoliv nasazovat. Doporucil bych se spis snazit o file-level deduplikaci nebo provadet agresivnejsi kompresi (komprimujes vubec? kdy? jak?).

Hodne mne desi ze chces nasadit deduplikaci po blocich, ale absolutne nezminujes ze bys mel jakykoliv data potvrzujici ze by to bylo o tolik lepsi nez deduplikace po souborech. To je hodne silny varovny znameni, ze sahas po okrajovejch resenich bez toho abys mel podlozeny ze je fakt potrebujes.

Co se tyka ZFS a zrani RAM, to je naprosto ocekavatelny jak kvuli deduplikaci, tak i jen kvuli tomu ze jde o ZFS -- ZFS minimalne na FBSD implementaci z dostatku RAM hodne tezi.

[atrak]

V současné době používám kompresi (bzip2 většinou) a deduplikaci na úrovni souborů (hardlinky), nestačí to.

[Milan Beneš]

Ahoj, taky dost záleží na tom, jakej charakter mají data, která chceš deduplikovat. Nspříklad můžu říct, že na datech z webhostingu není ZFS deduplikace žádná sláva. Mám za to, že se vyplatí nasadit pouze u úložiště virtuálních strojů a dedup ratio by mělo být tak aspoň 10, aby se ospravedlnily nároky na paměť. Pokud mě paměť neklame, tak deduplikace jednoho bloku sežere v ARC nějakých 170 byte. Jinak teď zkouším ZFS on Linux proti jádru 3.7.1 a tváří se to moc hezky . Na produkční mašinu bych to ale dal jen tehdy, pokud bych měl dobré zálohování a nebyla to nějaká mission-critical aplikace.

[Heron]

Dokoupit paměť nasadit ZFS a užívat si dalších výhod .

Netuším, jaký je tam FS teď, ale i na ext3,4 se ti může stát, že neuděláš ani fsck (resp. ano, ale jen jeho extrémně pomalou variantu šetřící paměť). U XFS by ten check byl úplně nemožný. Na takhle velké pole té paměti musí být mnohem víc.

[Zdeněk Zámečník]

Řešil jsem stejnou otázku téměř dva roky, přičemž jsem zkoušel stejná řešení jako ty, ale nakonec jsem došel k tomu, že ani jeden z těchto projektů se pro zálohy nehodí. U každého jsem dokázal celkem snadno docílit pádu filesystému, resp. Fuse v různých distrech (Debian, CentOS a Ubuntu), přičemž jsem byl limitován 8GB RAM. Dlouho jsem tomu dával šanci a trápil se s tím, ale velké zálohy mnoha malých souborů (emaily) znamenaly těžko překonatelný problém.

Dnes používám pro zálohy BTRFS se zapnutou kompresí a jsem spokojen. Úspora místa je obvykle menší než při deduplikaci, ale rychlost a spolehlivost je někde úplně jinde. Ano, připravil jsem se o několik desítek, možná stovek GB na 6TB poli, ale na druhou stranu jsem si ušetřil spoustu času a nervů s nekonzistentními anebo ještě hůře žádnými zálohami. Pokud zálohujete na nějaké ne příliš drahé disky, zvažte zda vám v dnešní době ta úspora místa za to stojí.

[Heron]

K tomu bych ještě doplnil, že u BTRFS lze využít reflinků, tedy pokud se teď někde dělá deduplikace souborů pomocí hardlinků (což lze dělat pouze u souborů, které se nikdy měnit nebudou), tak u reflinků je možné se všemi soubory dále pracovat.

[atrak]

No já už jsem nasadil ddumbfs a funguje naprosto bez problému. Jediný zádrhel může být správně si vypočítat velikost filesystému: podkladový ext4 má nějaký "režijní" informace + samotné uložené soubory (jsou v nich adresy bloků) na podkladovém fs mají nějakou velikost. Zálohuju na to virtuální stroje + windows server (přes tu jejich zálohu + cobian). Deduplikovaná data zabírají 23% původní velikosti, což je obrovská úspora.