Fórum Root.cz
Hlavní témata => Server => Téma založeno: Pavko 27. 11. 2017, 11:03:09
-
Zdravím. Chtěl bych se zeptat s Vaší zkušeností se souborovým systémem ZFS (vždy dedup on). Chtěl bych ho nasadit na svazek s maildiry. Udělal jsem dost testů a jsem z nich - se zapnutou deduplikací, celkem nepříjemně, rozčarován. Nejdřív jsem na prvním stroji udělal 500GB svazek, 8GB RAM. Po zaplnění cca 70GB rychlost 300-500kB - nepoužitelné. Tak jsem vzal jiný stroj 2x CPU, 24GB ECC RAM, 1TB svazek, a po zaplnění cca 500GB crash systému. Zkoušel jsem i jiný stroj s FreeNAS a tam během kopírování dat svazek úplně lehnul. HW je ověřený, značkový. Máte nějakou zkušenost se ZFS a případně jakou? Vše bylo se zapnutou deduplikací, zkoušel jsem i různé velikosti bloků, distribuce Debian, FreeBSD. Netušíte co dělám špatně?
-
zkusenosti mam podobne, dedup potrebuje spoustu RAM, nekde jde najit vypocet kolik, ale je to moc
mi to fungovalo pomalu a pak to dokonce tuhlo, ani to neslo rozduplikovat, bylo potreba docasne pripojit SSD jako ARC a docasne zvetsit RAM
zaver - deduplikaci ne
-
Díky za informaci. Zkusím testy bez deduplikace, pouze s kompresí. Pro mě je deduplikace nepoužitelná, když na 500 GB dat nestačí ani 24 GB RAM. Nezkoušel jste s SSD připojený trvale? Přece jenom se na SSD vejde více než do RAM.
Zkusil jsem simulaci násilného vypnutí stroje během usilovného zápisu na ZFS a poté rekonstrukce trvala (při dedup on) cca 70 GB dat cca 5 hodin. Sice se to povedlo, ale ten čas.
-
SSD jsem tam chvili mel, ale pomale to bylo stejne
jediny kladny vliv to melo, ze se mi podarilo data odduplikovate bez vytuhnuti
vypocet potrebne pameti je tu: http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html
-
Virtuální stroj pod ESX, 2 CPU, 4GB RAM, data nextcloudu ve vlastnim poolu ...
ZFS mám jen na data, OS běží z EXT4. Z ext4 občas na ZFS přemigruju konkrétní adresáře, typicky /var/log/, /var/lib/mysql/ apod ...
V tuto chvíli cca do 20 strojů, b2hem dvou let žádná ztracená data, žádné výkonnostní problémy/excesy ...
Vše na debianu od deb 7 ...
zpool status -D datapool
pool: datapool
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
datapool ONLINE 0 0 0
f37a2fb8-f9aa-4671-9ff4-d5df4a83a5d2 ONLINE 0 0 0
errors: No known data errors
dedup: DDT entries 1494947, size 291 on disk, 157 in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 1.08M 136G 136G 136G 1.08M 136G 136G 136G
2 278K 34.5G 34.5G 34.5G 645K 80.2G 80.2G 80.2G
4 68.4K 8.54G 8.54G 8.54G 275K 34.4G 34.4G 34.4G
8 279 32.8M 32.8M 32.8M 2.53K 300M 300M 300M
16 45 5.01M 5.01M 5.01M 870 98.1M 98.1M 98.1M
32 118 14.3M 14.3M 14.3M 5.76K 718M 718M 718M
64 350 43.5M 43.5M 43.5M 40.5K 5.04G 5.04G 5.04G
128 20 2.50M 2.50M 2.50M 3.62K 464M 464M 464M
256 2.94K 376M 376M 376M 1.05M 135G 135G 135G
128K 1 128K 128K 128K 200K 25.0G 25.0G 25.0G
Total 1.43M 179G 179G 179G 3.28M 417G 417G 417G
-
OK. Kolik tam máte dat?
-
podle vypoctu oraklu staci numirovi 0.5GB ram na deduplikaci
ja mel bloku radove vic a daleko mensi duplikaci
-
Netušíte co dělám špatně?
Nic. Je to prostě nepoužitelné na normálním hardwaru.
-
První, co je pro deduplikaci potřeba, je mít hash bloku dat. Zkuste změnit nastavení na skein,verify - je to rychlejší, terpve při kolizi porovná data fyzicky. Jde o to, jak moc deduplikovatelná vůbec jsou.
Jako minimum vůbec pro ZFS se doporučují 4 GB RAM + 1 GB na každý 1 TB dat.
-
OK. Kolik tam máte dat?
Poslední řádek :)
Total 1.43M 179G 179G 179G 3.28M 417G 417G 417G
Takže referenced: 417G dat, fyzicky uložených na 179G (allocated)
-
...Zkuste změnit nastavení na skein,verify - je to rychlejší, terpve při kolizi porovná data fyzicky...
aha, zajimave, to tenkrat nebylo
co jeste te nrychlejsi Edon-R?
-
co jeste te nrychlejsi Edon-R?
Nezkoušel jsem, ani jsem nestudoval. Jen jsem chtěl naznačit cestu. Znám to taky jen na FreeBSD.
Patrně by chtělo změnit ještě zfs set checksum=skein, ale opět, hlouběji jsem nezkoumal.
Deduplikaci mám jen na jednom datasetu, a tam je mi zrovna výkon jedno :(.
-
....Netušíte co dělám špatně?
Spatne nedelas nic. ...Tuhle mas vypocet http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html
Abys to nemusel cist, tak je to pocet bloku x 320. Tzn na 130GB disku kterej ma kilovy bloky potrebujes pri 129059324 blocich x 320 = 38GB RAM. Pocitaj teda s alokovanejma blokama, ja prozmenu s plnym diskem.
Na terovej disk s 4k blokama bys tudiz potreboval zhruba 80GB RAM
Takze viz Lol Phirae - je to zcela nepouzitelny na zcela libovolnym HW.
-
Na terovej disk s 4k blokama bys tudiz potreboval zhruba 80GB RAM
Takze viz Lol Phirae - je to zcela nepouzitelny na zcela libovolnym HW.
Abychom se zde nedopouštěli ještě hlubších chyb, tak výchozí recordsize je na ZFS 128 KiB.
1 TB disk (10^12) / 128 KiB (2^17) = 7 629 394 recordů
Pokud by byla deduplikace nulová, pak by pro 1 TB disk bylo potřeba 7 629 394 × 320 B = 2,27 GiB.
V estimacích se pracuje s tím, že nemá smysl používat deduplikaci pod cílový poměr 1:2, proto se uvádí, že na každý 1 TB dat je potřeba cca 1 GiB RAM. Pokud jsou data deuplikovatelná v lepším poměru, bude spotřeba RAM nižší. Pokud jsou naopak deduplikovatelná v horším poměru, tak nejhorší poměr je 2,27 GiB / 1 TB disku při nulové deduplikaci (poměr 1:1).
Na živých datech můžete simulovat efekt deduplikace pomocí příkazu zdb -S jmeno_poolu a posoudit, jestli se vyplatí.
Záměrně používám pro disky desítkovou základnu, protože výrobci disků uvádějí 1 TB = 10^12 B, zatímco výrobci RAM jako 2^x.
Zdroje:
http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html
https://www.freebsd.org/cgi/man.cgi?query=zdb&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html
-
....Netušíte co dělám špatně?
Spatne nedelas nic. ...Tuhle mas vypocet http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html
Abys to nemusel cist, tak je to pocet bloku x 320. Tzn na 130GB disku kterej ma kilovy bloky potrebujes pri 129059324 blocich x 320 = 38GB RAM. Pocitaj teda s alokovanejma blokama, ja prozmenu s plnym diskem.
Na terovej disk s 4k blokama bys tudiz potreboval zhruba 80GB RAM
Defaultně se používají bloky 128 KB, takže to zas taková hrůza není.
-
...
Abychom se zde nedopouštěli ještě hlubších chyb, tak výchozí recordsize je na ZFS 128 KiB.
...
Tj, to bude deduplikace jak noha ... nebo jako u vmware. Kolik asi tak najdes identickych 128k bloku vs 4k.
Defaultně se používají bloky 128 KB, takže to zas taková hrůza není.
Prave ze to hruza je, soudruzi ve vmware pouzivaj blok 1MB (a nemuzes ho zmenit), vede to pak k tomu, ze misto aby se ti zalohovalo 100MB zmen, tak se zalohuje 10GB. U databazi se velice snadno a rychle dostanes do stavu, kdy libovolnej backup = fullbackup. Pricemz realne je zmen naprosty minimum.
BTW: Nektery zalohovace pouzivaj velikost bloku plovouci.
-
Defaultně se používají bloky 128 KB, takže to zas taková hrůza není.
Prave ze to hruza je, soudruzi ve vmware pouzivaj blok 1MB (a nemuzes ho zmenit), vede to pak k tomu, ze misto aby se ti zalohovalo 100MB zmen, tak se zalohuje 10GB. U databazi se velice snadno a rychle dostanes do stavu, kdy libovolnej backup = fullbackup. Pricemz realne je zmen naprosty minimum.
BTW: Nektery zalohovace pouzivaj velikost bloku plovouci.
VMvare používá velké bloky, protože image operačních systémů bývají velké a často shodné. Šetří tím RAM.
Nevidím důvod, proč by někdo měl dávat databázi na ZFS s deduplikací. To je IMHO nesmysl. Čím primitivnější FS (nejlépe žádný), tím to databázi víc vyhovuje.
-
Tj, to bude deduplikace jak noha ... nebo jako u vmware. Kolik asi tak najdes identickych 128k bloku vs 4k.
To se mýlíte. V praxi jsou identické buďto celé soubory, nebo se neshodují vůbec. Prakticky se nezmění deduplikační poměr, náhoda, že by ve dvou souvislých řadách dat byly shodné jen vybrané bloky, je extrémně nízká.
Deduplikace se rozhodně nehodí na většinu dat, jsou to jen speciální případy.
ZFS používá deduplikaci za letu, ta je náročná na RAM a výkon. Např. NTFS používá deduplikaci, kterou provádí v nastavených intervalech (např. 1-2x denně), lze vyloučit určité typy souborů, nastavit deduplikaci na souborech starších X dní (nemá smysl ji dělat na často měnících se souborech) a provádí se nad 4k nebo 64k blocích.
Uživatel si pak musí spočítat cenu prostoru dat, cenu RAM, cenu za umístění HW (např. v racku) a odhadovaný poměr, aby se mohl rozhodnout, jestli deduplikaci zavést.
U ZFS se vyplatí přemýšlet, na kterých datasetech deup povolíte, a na kterých ne, a rozlišit, která data kam ukládáte. U NTFS máte zase jiné možnosti, ale efekt je zpožděný.
Jinak VM se zálohují pomocí technologie označování změněných bloků. Veeam Backup podporuje tzv. dedup-friendly komrpesi, kdy komprimuje zarovnaně na bloky, aby stejně zkomprimovaná data zvýšila šanci na deduplikaci. Kombinací těchto technologií zálohujete velmi lehce a s poměrně rozumnou datovou náročností.
-
Díky všem za reakce. Dle vašich reakcí i po mých pár pokusech ZFS s dedup pro produkci vhodné není, při nešetrném vypnutí se to snaží o mount ZFS, furt to píše "A start job is running for Mount ZFS filesystems" a pak tainted:P, asi se to přes noc mountnout povede. Zkoušel jsem pro data maildirů a dedup poměr je 1,14 (blok 128k) - což se nevyplatí. Ještě udělám pokusy se "zfs set checksum=skein", verify a pak s dedup off.
Nemáte někdo zkušenost se Solarisem a ZFS? Pokusím se vyzkoušet.
Ještě jednou díky všem.
-
Pro maildir jsem kdysi úspěšně vyzkoušel ReiserFS, který umí významně šetřit místo na disku u drobných souborů. Možná by se dnes pro tento účel hodil spíše BtrFS.
-
Díky všem za reakce. Dle vašich reakcí i po mých pár pokusech ZFS s dedup pro produkci vhodné není, při nešetrném vypnutí se to snaží o mount ZFS, furt to píše "A start job is running for Mount ZFS filesystems" a pak tainted:P, asi se to přes noc mountnout povede. Zkoušel jsem pro data maildirů a dedup poměr je 1,14 (blok 128k) - což se nevyplatí. Ještě udělám pokusy se "zfs set checksum=skein", verify a pak s dedup off.
Nemáte někdo zkušenost se Solarisem a ZFS? Pokusím se vyzkoušet.
Ještě jednou díky všem.
Na maildir by stálo za zvážení vyzkoušet různé typy kompresí (zfs set compression=), bude to určitě účinnější, než deduplikace. Je možné, že výkon Vám bude dostačovat i na gzip > 5, nebo naopak zjistíte, že musíte použít "jen" lz4.
-
Nemáte někdo zkušenost se Solarisem a ZFS? Pokusím se vyzkoušet.
Mohu poskytnout konkrétnější informace na FreeBSD.
-
Jestli mohu poprosit o informaci kolik tam máte dat/charakter dat a nastavení poolu? Existují nějaké nástroje na rekonstrukci dat na ZFS? Můžete příp. i na můj e-mail: hphp@seznam.cz.
Dnes jsem zkoušel dát na ZFS svazek milion malých souborů a to je očistec (dedup on), zvlášť poslední čtvrtina. Stále si myslím, že deduplikací musím hodně ušetřit, maily jsou často posílány více příjemcům s těmi 14% se nechci smířit.
Děkuji, Pavko.
-
Jestli mohu poprosit o informaci kolik tam máte dat/charakter dat a nastavení poolu? Existují nějaké nástroje na rekonstrukci dat na ZFS? Můžete příp. i na můj e-mail: hphp@seznam.cz.
Dnes jsem zkoušel dát na ZFS svazek milion malých souborů a to je očistec (dedup on), zvlášť poslední čtvrtina. Stále si myslím, že deduplikací musím hodně ušetřit, maily jsou často posílány více příjemcům s těmi 14% se nechci smířit.
Děkuji, Pavko.
Kdo chce kam, pomozme mu tam.
Stále nechápete, že to není dobrý nápad, tak vám tady okopíruji výtah z manuálu:
Be warned: deduplication requires an extremely large amount of memory, and most of the space savings can be had without the extra cost by enabling compression instead.
-
Pravdepodobne nechape, co ta deduplikace dela -- nekdo, kdo vi, jak je to technicky realizovane by mu to mel vysvetlit.
Moje chapani je, ze pro kazdy blok (128kB) si pamatuje hash a ten drzi v pameti. Kdyz prijde na zapis dalsi blok, zkontroluje hash a pokud najde shodny, potom obsahuje obsah. Pokud je obsah stejny, tak jenom vytvori alias na ten puvodni blok. Pokud to takto funguje (a mohu se samozrejme plest), tak se mi zda nepravdepodobne, ze by to mohlo pro maily poskytnout nejakou extra vyhodu. To komprese (protoze text) se mi zda mnohem zajimavejsi (potencialne mnohem vic odmenujici) experiment.
-
Maily maji mozna stejny obsah ale hlavicky jine a ty jsou na zacatku. Bohuzel v promenlive delce a uvazovat o deduplikaci je proto cisty nesmysl. Nekdy by to chtelo premyslet a znat trocha tu strukturu dat. Vzhledem k tomu ze jak ascii tak base64 by slo komprimovat dobre, tak pouzivej jenom on the fly kompresi (napr. zmineny ReiserFS). A dnes je taky misto docela levne - co vam brani si sestavit N*10TB pole? Jiste to bude levnejsi nez N*10GB ram :)
-
ReiserFS byl původně určen pro hromadu malých souborů, tedy i pro maildir. Pokud vím, tak kompresi neumožňuje.
On the fly kompresi jsem našel jen u BtrFS, který by se na ten maildir mohl nakonec hodit. Ovšem bez deduplikace, která je u mailů evidentně k ničemu.
-
Stále si myslím, že deduplikací musím hodně ušetřit, maily jsou často posílány více příjemcům s těmi 14% se nechci smířit.
Jenže ty e-maily nejsou stejné, liší se v hlavičce - tj. ten blok dat je jako celek jiný. Každá hlavička má i jinou délku, takže ani od druhého bloku se to nepotká. Proto Vám deduplikace nefunguje. To by musel někdo vymyslet dedup friendly náhradu pro maildir - např. hlavičky mailů mít v jiném souboru, než těla zpráv. Pak by byla těla zpráv, teoreticky, deduplikovatelná.
-
Máte pravdu, hlavičky jsou jiné. U maildirů je to 50% na 50% - deduplikace poměr 1,14; komprese také 1,14. Teoreticky obojím se lze dostat na cca 1,3; ale použitím deduplikace se šíleně zpomaluje rychlost čtení i zápisu. Deduplikaci vyzkouším pro jiný typ dat a vrhnu se na zkoušení různých metod komprese a btrfs, moc děkuji za nakopnutí.
Co lze udělat s poškozeným ZFS filesystemem? Neznáte někdo opravný nástroj na ZFS?
Zase dám ozvu, Pavko.
-
Co lze udělat s poškozeným ZFS filesystemem? Neznáte někdo opravný nástroj na ZFS?
ZFS se (jako všechny checksumované filesystémy) opravuje samo, když narazí na chybu. Zkontrolovat (a opravit) všechny soubory lze pomocí scrubu. Pokud narazí na chybu, kterou opravit nedokáže, tak opravit nejde.
-
Ahoj,
momentalne kupujeme od Oracle ZS5-2. Interne to bezi na solarisu a pouziva to ZFS. Durazne jsem zadal ze nechceme deduplikaci. Technik me ujistil ze zatim nikdo nechtel od nich zapnout deduplikaci a ani to standarnet nenabizeji. Cena(RAM) za deduplikaci je strasne vysoka. Podle meho osobniho nazoru se jedna o nejhorsi vlastnost ZFS a ja bych si ji niky nezapnul.
Naopak komprese je velmi uzitecna vlastnost. Na maildir bych ji urcite zapnul. ZSF dokonce umi, pokud se nepletu, "chytrou" kompresi. Nejprve zkomprimuje prvni blok a pokud je kompresni pomer spatnej, dale nekomprimuje. Pokud je dobrej, zkomprimuje celej soubor.
Radek
-
@Pavko
"Pro mě je deduplikace nepoužitelná, když na 500 GB dat nestačí ani 24 GB RAM"
pokud se to chova takhle tak tam mas neco zatracene spatne.
Obecne se doporucuje:
"If you plan to use ZFS deduplication, ensure you have at least 5 GB RAM per TB of storage to be deduplicated."
viz http://doc.freenas.org/9.3/freenas_intro.html#ram
dale "The recommended minimum (mysleno pro FreeNAS system) is 8 GB of RAM" viz URL vyse.
Myslim ze by sis mel pozorne procist tenhle manual co napsali primo vyvojari co delaj FreeNAS/ZFS abys nemarnil cas zbytecnymi experimenty......
Taky je dobry si procist tohle https://forum.root.cz/index.php?topic=12850.60 vlakno kde zdejsi pleenum ZFS/dedup probiralo :o)
Pokud te ZFS problematika zajima vic skoukni tohle video:
http://www.jupiterbroadcasting.com/116766/for-the-love-of-zfs-bsd-now-203/
Krome exkursu do historie ZFS tam probiraj prave i DEDUP a posledni napady ohledne jeho vylepseni, napr Intel chce rozhazovat files podle typu a vhodnosti na komprimaci/dedup na ruzny datasety, dale "zastropovani" velikosti DDT (=DeDuplicatinTable) ci jeji prehozeni na NVMe
https://en.wikipedia.org/wiki/NVM_Express
ktery se rychlosti priblizuje RAM ale cenove/kapacitne je stravitelnejsi, indexovani "pozmenenych bloku", megabloky atd atd
Vsechny dily tohodle podcastu se v podstate nezabyvaj nicim jinym nez problematiku *BSD a ZFS:
http://www.jupiterbroadcasting.com/show/bsdnow/page/2/
@trubicoid2
"podle vypoctu oraklu staci numirovi 0.5GB ram na deduplikaci"
Nejsem si vubec jistej jestli vypocty pro Oracle system maj nejakou relevanci pro openZFS....?
ZFS u obou sice vychazi ze stejnyho zakladu od Sun, ale uz davno se rozdelil a podle openZFS devs je pres polovina kodu uz jina nez u Oraclu, dukazem ceho budiz ze Oracle zatim neodtahl lidi z iXSystems k soudu prestoze urcite diky open source povaze ZFS kodu z dilny iXSystems je soudruzi od Oraclu pravidelne procitaji...... uz jen pro "inspiraci" ohledne novych napadu ;o)
@LolPhirae
RE: dedup--"Nic. Je to prostě nepoužitelné na normálním hardwaru."
Ano- to je spravna odpoved! :o)))) https://www.youtube.com/watch?v=QEsVL9Lr80k#t=6m1s
Dedup ale je myslen spise jako enterprise feature (i kdyz i tam to drhne) pro servery ktery u iXsystems davaj dohromady a ktery maj >128GB RAM.....
@Miroslav Silhavy
"Jako minimum vůbec pro ZFS se doporučují 4 GB RAM + 1 GB na každý 1 TB dat."
To je SPATNA ODPOVED - viz vyse ;o)
@KIt
"Možná by se dnes pro tento účel hodil spíše BtrFS."
Ne nehodil- BtrS rozhodne neni "production ready" a lidi co diky nemu prisli o data by to povrdili.
Naproti tomu uzivatele ZFS -pokud si vlastni blbosti pod sebou nepodrizli vetev- pouzivaj ZFS uz roky bez problemu =
jsem 1 z nich.
@MS
"....vyzkoušet různé typy kompresí (zfs set compression=), bude to určitě účinnější, než deduplikace"
Ano to je spravna odpoved viz:
Unless you have a lot of RAM and a lot of duplicate data, do not change the default deduplication setting of “Off”. For performance reasons, consider using compression rather than turning this option on.
http://doc.freenas.org/9.3/freenas_storage.html?highlight=deduplication#deduplication
https://constantin.glez.de/2011/07/27/zfs-to-dedupe-or-not-dedupe/
@Y.
"...Pravdepodobne nechape, co ta deduplikace dela..."
Mas to skoro na jednicku, jen bych dodal ze pri zapisu se pocitaji i hashe samotnych hashu a ty se pak rozhazuji ve Vdev tak aby i ztrata 1 az 3 disku na ne nemela vliv..... (RaidZ1-RaidZ3)
Komprimace textu je velmi vyhodna, komprimace hodne zkomprimovanych napr.MP3 ci videa je prakticky nemozna, takze je rozumne tyto typy drzet na vlastnim datasetu BEZ komprimace.
Jinak opakem dedup je "klonovani" alias rekneme ZFS systemu aby STEJNA data pri zapisu nakopiroval i jinam a to podle algoritmu ktery zaruci ze "totozny zlomek souboru" NEBUDE na stejnem disku.............coz uz je docela voodoo :o)))
@Sten
"ZFS se (jako všechny checksumované filesystémy) opravuje samo, když narazí na chybu. Zkontrolovat (a opravit) všechny soubory lze pomocí scrubu. Pokud narazí na chybu, kterou opravit nedokáže, tak opravit nejde."
V principu to vypada nejak takhle https://derivadow.files.wordpress.com/2007/01/zfs-self-healing.jpg?w=620
Scrub se pak v podstate tvari jako ze chce cist vsechno naraz a projizdi cely Vdev.......coz muze zabrat i nekolik hodin nicmene to funguje VELMI SPOLEHLIVE! = vlastni zkusenost.
Vice o scrub+self-healing system zde:
http://doc.freenas.org/9.3/zfsprimer.html?highlight=scrub#zfs-primer
-
@Radek
"momentalne kupujeme od Oracle ZS5-2. Interne to bezi na solarisu a pouziva to ZFS.... Technik me ujistil ze zatim nikdo nechtel od nich zapnout deduplikaci"
Az budes priste mluvit s tim technikem zeptej se ho schvalne nakolik je mozny namountovat ZFSpool vytvoreny na FreeNASu (alias openZFS) na jejich Oracle....?
Docela by me zajimalo jestli tam je vubec nejaka kompatibilita.....
THX
-
Nemohu souhlasit, že je to nepoužitelné. FreeNAS a jeho tabulku nároků na deduplikaci čtu poprvé, ale nesedí to proti ostatním informacím, které jsem kde četl, ani proti výpočtu Oraclu. Je možné, že FreeNAS používá menší blok než 128 KiB.. (? ví někdo, já na žádném FreeNASU nemám ZFS).
Deduplikaci používám např. na storage záloh fotografií, kde mi vůbec nevadí nižší rychlost, protože data tam stejně lezou pomalu rsyncem. Dokonce mám méně paměti, než je doporučení, a i tak to stačí. Ale je taky pravda, že se mi to vyplatí - deduplikační poměr mám > 2:1.
Pak ještě pouštím deduplikaci jen nad datasety jailů FreeBSD, tam se provádí zápis jen jednou při updatu systému / jailů, takže ke zpomalení dojde jen v ten okamžik, za běhu už pak ne (vše ostatní se zapisuje do /home, /usr/local a /var, které dedup mají zakázaný).
Na produkci, na proměnlivá data běžného serveru, to asi opravdu k ničemu není.
-
FreeNAS implicitně používá velikost bloku 128k, ale lze změnit.
Mezitím jsem vyzkoušel ZFS (ještě s dedup on) pro jinou strukturu dat a tam to celkem rychlostně je celkem dobré. Zatím jsem zjistil, že rychlostní problém dělá velké množství malých souborů.
Děkuji všem, hlavně hugochavez-ovi, budu se dál učit.
-
Deduplikaci používám např. na storage záloh fotografií, kde mi vůbec nevadí nižší rychlost, protože data tam stejně lezou pomalu rsyncem. Dokonce mám méně paměti, než je doporučení, a i tak to stačí. Ale je taky pravda, že se mi to vyplatí - deduplikační poměr mám > 2:1.
To je také správné použití deduplikace. Z podobných důvodů ji používám na jednom ze serverů, kde se schází opravdu velké množství totožných souborů od různých uživatelů.
-
...... kde se schází opravdu velké množství totožných souborů od různých uživatelů.
Coz je duvodem proc expertem na deduplikaci jsou napr. soudruzi z Dropboxu, tam to ma pomerne zasadni alias $ vyznam :)
Bohuzel jsou rovnez experti i na hashovani obsahu uzivatelu a "nevhodny" obsah bez pardonu a varovani mazou.....
Coz ovsem BFU ktery neni uplne padly na hlavu dokaze obejit tak ze napr. film o par sekund zkrati ci MP3 prekomprimuje ;)
Takze "cat and mouse game" vesele pokracuje.....
-
Ještě jsem nenarazil na situaci, kdy by mi deduplikace nějak výrazně pomohla a to i v situacích zdánlivě ideálních (.vmdk soubory mnoha v zásadě identických virtuálek). S paměti jsem ovšem nikdy problém neměl, už jsem totiž pochopil, že pro ZFS je hodně paměti prostě třeba takže všude cpu 256GB (chystám se nasadit EPYC a tam půjde už 512GB) s tím, že velikost ARC limituju na 180GB.
arc_summary
------------------------------------------------------------------------
ZFS Subsystem Report Fri Dec 01 11:23:06 2017
ARC Summary: (HEALTHY)
Memory Throttle Count: 0
ARC Misc:
Deleted: 5.29m
Mutex Misses: 266
Evict Skips: 266
ARC Size: 100.00% 180.00 GiB
Target Size: (Adaptive) 100.00% 180.00 GiB
Min Size (Hard Limit): 83.33% 150.00 GiB
Max Size (High Water): 1:1 180.00 GiB
ARC Size Breakdown:
Recently Used Cache Size: 40.73% 73.31 GiB
Frequently Used Cache Size: 59.27% 106.69 GiB
ARC Hash Breakdown:
Elements Max: 3.81m
Elements Current: 95.56% 3.64m
Collisions: 2.17m
Chain Max: 4
Chains: 181.10k
ARC Total accesses: 125.26m
Cache Hit Ratio: 94.89% 118.86m
Cache Miss Ratio: 5.11% 6.40m
Actual Hit Ratio: 91.49% 114.61m
Data Demand Efficiency: 99.86% 100.99m
Data Prefetch Efficiency: 44.54% 7.36m
CACHE HITS BY CACHE LIST:
Anonymously Used: 3.00% 3.57m
Most Recently Used: 7.37% 8.77m
Most Frequently Used: 89.05% 105.84m
Most Recently Used Ghost: 0.23% 277.31k
Most Frequently Used Ghost: 0.35% 410.63k
CACHE HITS BY DATA TYPE:
Demand Data: 84.85% 100.85m
Prefetch Data: 2.76% 3.28m
Demand Metadata: 9.21% 10.95m
Prefetch Metadata: 3.18% 3.78m
CACHE MISSES BY DATA TYPE:
Demand Data: 2.17% 139.02k
Prefetch Data: 63.78% 4.08m
Demand Metadata: 17.10% 1.10m
Prefetch Metadata: 16.95% 1.09m
File-Level Prefetch: (HEALTHY)
DMU Efficiency: 144.76m
Hit Ratio: 70.88% 102.60m
Miss Ratio: 29.12% 42.15m
Colinear: 42.15m
Hit Ratio: 0.01% 2.45k
Miss Ratio: 99.99% 42.15m
Stride: 95.55m
Hit Ratio: 100.00% 95.55m
Miss Ratio: 0.00% 2.25k
DMU Misc:
Reclaim: 42.15m
Successes: 0.18% 75.01k
Failures: 99.82% 42.08m
Streams: 7.05m
+Resets: 0.00% 253
-Resets: 100.00% 7.05m
Bogus: 0
-
Ještě jsem nenarazil na situaci, kdy by mi deduplikace nějak výrazně pomohla a to i v situacích zdánlivě ideálních (.vmdk soubory mnoha v zásadě identických virtuálek). S paměti jsem ovšem nikdy problém neměl, už jsem totiž pochopil, že pro ZFS je hodně paměti prostě třeba takže všude cpu 256GB (chystám se nasadit EPYC a tam půjde už 512GB) s tím, že velikost ARC limituju na 180GB.
Myslím, že na takové použití je ZFS zbytečné úplně.
Dedkuplikaci na vmdk bych stopro vůbec nepouštěl, to je absolutní zabiják výkonu.
Má to smysl nad běžnými soubory, tj. buďto uvnitř vmdk, nebo třeba přes NFS.
-
Myslím, že na takové použití je ZFS zbytečné úplně.
Dedkuplikaci na vmdk bych stopro vůbec nepouštěl, to je absolutní zabiják výkonu.
Má to smysl nad běžnými soubory, tj. buďto uvnitř vmdk, nebo třeba přes NFS.
Pokud se deduplikační tabulka vejde do paměti tak je propad výkonu minimální. Ověřeno testy v praxi. Nicméně deduplikaci vzhledem k nepřesvědčivým výsledkům nepoužívám. ZFS tam mám kvůli snapshotům (včetně send/receive) a kvůli kontrolním součtům (jak naprd je běžný RAID10 bez kontrolních součtů jsem se bolestivě přesvědčil na vlastní kůži).
-
Ono opravdu zalezi na use-case. Zapinat deduplikaci by default nebo pool-wide je nesmysl a zbytecne plytvani pameti. Sam mi s uspechem pouzivam u ZVOLu, ktere slouzi jako uloziste exportovane pres iSCSI bezdiskovym stanicim. Na stanicich bezi Windows 7 a dedup ratio je celkem velke cca 3.5:1.
Je ale potreba dat bacha na parametry, treba ja u tech ZVOLu mam volblocksize 32k a velikost clusteru v tech Windows je tez 32k. Pri tomto nastaveni ma DDT tabulka 3505973 polozek a kazda z nich zabira v pameti 194 bajtu - tzn. nejakych 648MB. Pokud bych ovsem volblocksize nechal na 4k a stejne tak NTFS cluster size tak tech polozek bude 8x vice a spotreba pameti pro DDT pak vice nez 5 GB, coz uz je znatelne.
Takze za mne, deduplikaci ano, ale s _velkym_ rozmyslem a hlavne tam kde to ma smysl. U mail serveru to smysl nema protoze i stejne zpravy se na zacatku budou lisit hlavickami, takze ty bloky budou jine.
Dale je dobre dat na datasety nebo ZVOLy checksum vhodnou pro deduplikaci (napr. SHA256), jinak bude dochazet ke kolizim a celoblokovym porovnanim, coz se odrazi na vykonu.