ZFS dedupe levelező szerver alá

 ( pista_ | 2017. december 12., kedd - 16:55 )

Hi!

Levelező szerver minden beérkező és kiküldött levélről készít egy másolatot (bcc).
Szervercsere kapcsán felmerült bennem, hogy a levelek alá ZFS-t teszek LZ4 tömörítéssel. A bcc miatt felmerült bennem a dedup bekapcsolása, ha már a levelek tényleg duplikálva vannak. Viszont a levelek csak "ránézésre" megegyezők, a file neve, a levél fejléce picit más.
Szóval a kérdés az, hogy így lenne -e értelme a dedup bekapcsolásának? (A dedup működése sajna nincs meg.)

Igen, az megvan, hogy bekapcsolás után már nem kapcsolhatom ki és rengeteg memóriát igényel a dedup, ezért is kérdezem.

Jelenleg ~2TB a levelek mennyisége, ami naponta ~3GB-al nő. Az új szerverben 32GB RAM lesz, ez szerintem a 2TB-nak elegendő (2x5GB RAM-al számoltam a dedupnak), tehát egy jó darabig elegendő lehet(ne), a tárterület pedig 10TB egyenlőre.

Szóval a kérdés, hogy a fentieket ismerve Ti használnátok -e a dedup-ot?

Előre is köszönöm az észrevételeket, ötleteket!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A dedup blokk szinten és nem file szinten működik a ZFS-nél emlékeim szerint. A tömörítéssel jársz jól, a dedup valszin nem lesz előnyös és plusz memó igénye is van. A ZFS már tud online bővülni további diszkkel? Lehet inkább olyan irányba indulnék, hogy a bcc-s emaileket egy lassú vagy másodlagos tömbre irányítanám.

De, szerintem lenne vagy 3-4x-es nyereseg vele.
Mas kerdes, h majd nez, amikor szarra fragmentalodott az fs es halal lassu vmint amikor megsem tudja importalni, mert csak. Olyankor megis inkabb ugy gondolja az ember, h igazabol apropenzbe kerul a HDD.

Igen, pont ezért kérdeztem, ,hogy akinek van tapasztalata azt meghallgatnám és tanulnék belőle.
A tömörítés adja magát, az rendben is van, de ZFS-el kapcsolatban szinte mindenhol úgy kezdenek, hogy "dedupot felejtsük el" az erőforrás igénye miatt.

Azon az elven, hogy, ha "lúd akkor legyen kövér" és használjuk az új technikát - mert egyébként nem feltétlen lenne rá szükség - került előtérbe a dedup, de a hozzászólások méginkább meggyőztek, hogy nincs erre nekem szükségem. ;-)

Minden kezdo zfs felhasznalo ra van izgulva a dedup-ra.
Marginalis mennyisegu a valos felhasznalasi lehetoseg a jelenlegi megoldassal.

Bár már közel 1 éve használok élesben zfs-t, de valóban kezdőnek mondom magam, annyira nem mélyültem el benne. Különösen úgy nem, hogy eddig nem volt olyan vas, ami felett a dedup szóba jöhetett volna, de most minden adva lenne, de mindenáron azért nem kell. :-)

Eddig md+lvm+xfs volt, -e helyett lesz az új masinán zfs lz4 tömörítéssel és dedup felejtéssel. :-)

Köszönöm!

nekem pl anno 100G sqldumpoknal jol jott a dedup :)

Az elmélet jó, amin elindult, de sj leírta a problémát és ahogy látom "véletlenül" megoldása is van rá. :) ZFS-t mondjuk pont email alatt nem, csak backup alatt próbáltam, de a dedup minimális extrát adott, hacsaknem azonos teljesen file-ok voltak. Az általában szöveges emailezés a tömörítésre nagyon jól reagál, akár a file szintűre is. Sajnos dovecottal sikerült Debian alatt szívni egyet ezzel, azóta hanyagolom.

Igen ránéztem, mailFS mintha leállt volna 2013-ban, vagy benéztem, vagy "csak" tökéletesre sikerült. :-)

A piler érdekesnek tűnik, adunk neki 1 esélyt. ;-)

A dovecot-os szívásról pár gondolatot megosztanál?

szoval amit lentebb mondani akartam, hogy a leveleket idealis esetben egy levelekre tervezett filerendszerben tartanank. De en ilyen fs-rol nem tudok (nem is tudtam, hogy van egy obsoleted projekt mailfs neven :-)).

Ha meg akarod sporolni a telepitest, es szereted a docker-t, akkor toltsd le a sutoj/piler:test image-et, es mar hasznalhatod* is

*:teszt celra, mert ugye mindent a konteneren belul tarol...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

A dovecot-os szívásról is írnál? Nekem kis forgalmú szerveren pár postafióknál prímán működik. A levelek gzip-pel vannek tömörítve,

azt nem en irtam, hanem andrej_ :-) Mondjuk en nem tomoritem dovecot-tal a leveleket :-)

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Oh, pardon, tényleg.

A régi megoldás szerint nem a dovecot tömörített, hanem külön tömörítő script volt. Ezt a Debian Wheezy-s dovecot vagy zlib sehogy szereti/szerette és állandóan fiókhibák jöttek, tehát minden ilyen emailt ki kellett bontani. A dolgot tetézi, hogy úgy egyébként se tudtam Wheezyn életre kelteni a beépített tömörítését.

Igen, ez nem volt meg, gyanús is volt, hogy nem file szinten csinálja - logikusan úgy nem sok értelme lenne.

Az ötlet viszont remek!! Köszönöm!!
Backup storage-ra iSCSI-n keresztül mehet a bcc, így minden levél megvan külön is.

Még egyszer köszönöm!

Nem.

leveleket MailFS-en kene tarolni :-) A ZFS bar szipi-szupi, de egy atlag fs dedup-ja valoszinu pont azert nem (eleg) jo, mert 2 level lehet ugyanaz ugy, hogy a Message-ID egyezik, de a queue id-k, datumok nem egeszen. Mivel blokk szinten deduplikal, ezert siman lehet az, hogy mondjuk az image001.jpg-t (ami kb. minden elszabott levelben benne van) azert nem tudja dedup-olni, mert mindig elcsuszik a blokkhatar.

Probald ki a piler nevu cuccot, ami kb. azt tudja (meg annal joval tobbet is), amit elvarsz tole: egyreszt message-id alapjan eldobaja a mar ismert leveleket, masreszt a mellekleteket kiszedi a levelbol, kulon tarolja 1 db peldanyban. Ja, es tomorit is. Bar a telepitese kapcsan az javasolt, hogy dedikalt gepre (akar virtualisra is) keruljon...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

+1

Mentő szever alá tettünk ZFS-t, mondvan a COW és a snapshot milyen jó. S legyen már kövér, adtunk neki dedupot is. Bár hozta a 2-es dedup, de dedikált Dl380G6-os szerver 50G rammal 18T ZFS hellyel simán 10LOAD-al ment. 24 core!

Gyakorlatilag bárhogy hangoltuk Linux alatt , nem lett stabil. Igaz ide tartozik, hogy RAID6-os 3T diskek voltak és kevés IOPS volt.
A sima kompresszio jó ötlet !

ZFS lol.
PZ

ui: bár a végén a mentésre használt bacula, alkalmazás(a fizikai gépre ment) oldali tömörítéssel sima EXT4-es rávert a fenti megoldásra.

Hálásan köszönöm!

Ilyen, tapasztalatból származó véleményt vártam, hogy mire számíthatok.

Egyenlőre nincs több kérdésem dedup-al kapcsolatban. :-)

Köszönöm!

Szorri de a 3T-s lemezek raid6 az eléggé elcseszett konstrukció.

--
Gábriel Ákos

Mentés alá miért lenne rossz konstrukció? Mi a javaslatod olcsó és nagy kapacitás vonalon, ami legalább hasonló redundanciával bír?

Külön-külön oké lehet bármelyik része de így együtt nem oké.
Tehát az, hogy van kevés tengelyem, nagy diszkek, választok egy olyan redundanciát aminek van egy csomó overhead-je (a visszaírogatások miatt), ezt még megtolom egy kis deduppal és csodálkozok hogy lassú + nagy load van.
Ha a mentések amúgy tömörítettek eleve, akkor már a compression bekapcsolásának sincs értelme.

Backup servernek lehet a raidz2 nagy diszkekkel, semmi dedup, semmi compression, mellétennék egy ssd cache-t és kész (ha már zfs).

De amúgy ha nem zfs akkor csinálnék egy sima linuxos mdraid + lvm + ext4 cuccot (de ez lehet csak azért van, mert zfs témában én is newbie vagyok)

--
Gábriel Ákos

Tapasztalataimat én is megosztom kettő versenyző backup szerverről (mailszerver, fileszerver, minden egyéb backupja):

- HP microserver 4 GB RAM
- 4 db 8 TB-os SATA
- RAID5 (mdadm) + titkosítás (cryptsetup) + zfs (gzip tömörítéssel)
- 14 TB adat

Másik:
- HP microserver 16 GB RAM
- 4 db 4 TB-os SATA
- RAID5 (mdadm) + titkosítás (cryptsetup) + zfs (lz4 tömörítéssel + dedup)
- 14 TB adat

Mindkettőnél 39-40 % a tányérokon a helyfoglalás (a deduposban fele diszk van).
A tömörítés gzip esetén 1,65x, lz4 esetén 1,52x.
A deduplikálás 1,94-es szorzót hozott.

Fragmentáció: 17% az egyiken, 42% a dedup-oson.

És a tapasztalat: a tömörítéssel egészen jól dolgozik a ZFS backupolás céljára. A deduplikálás viszont szörnyen lassú és kb. 100 MB adat után perces időtartamra megakad (háttérben vakar) majd folytatja. Esetleg SSD-s zfs cache segíthet, de nem tudom mennyit. Sajnos csak az egyébként is terhelt forgótányér másik partícióján tudtam a zfs cache-t beállítani és így kipróbálni, ami nem hozott áttörő sikert.
A scrub is kb. 120 óra alatt végez vele, míg dedup nélkül 29 óra alatt átnézte.

Általánosságban: zfs compress rendben, viszont a deduplikációval tényleg vigyázni kell, borzasztóan lassú és a megakadásaira (miközben a háttérben vakar) is számítani kell.

Az mennyire van meg, hogy a ZFS alá 1T tárhely => 1G Ram az erősen javallot....
Nem viccből találták ki... egy nem túl szabályos helyreállításnál a
fájlrendszer felcsatolásakor lehetnek majd kellemetlen perceid/óráid :D

És a 4G-re ráadásul rátolni a dedupot is....

ui: nem aludnék nyugodtan a helyedben....

Valójában Terabyte-onként legalább 5GB RAM az ajánlott:

"For every TB of pool data, you should expect 5 GB of dedup table data, assuming an average block size of 64K."

Köszönöm. Már érdemes volt bedobnom az esetet.

Ezek szerint a 12 TB-os zpool-hoz (amit deduplikáltatok) ha beraknék 60+ GB RAM-ot, akkor ez is frankón felgyorsulna. Viszont a HP microserverbe max 16 GB RAM megy bele, tehát más utat kell átmenetileg választanom.

Kérdés: SSD-s cache-sel felgyorsítható-e? Mit kell ehhez tennem?

A rövid válasz az hogy nem.
A cache (l2arc) az csak olvasáskor kap szerepet, a dedup meg pont írási feladat.
Az slog/zil ssd-n pedig gyakorlatilag csak szabálytalan leállítás után jut szerephez.
Ha jól értettem a doksit...

Pedig én is azért rakattam ssd-t a gépbe hogy hátha tudok jó kis write-back cache-t csinálni ssd-ből, de eddig ez nem jött össze...

--
Gábriel Ákos

ZIL = intent log, gyakorlatilag write cache. Van, ha ki nem kapcsolod - ne tedd! SLOG = separate log, azaz dedikált log device a poolban, ami nincs, ha nem csinálsz, de ha csinálsz, ott lakik a ZIL, ami enélkül is van - lásd fent. Rendszerint ez van hybrid pool-ban SSD-n; all-flash tömb esetén a SLOG indifferens, a ZIL nem lesz lassabb a tömbnél (persze a csatoló itt sem mindegy és sokat számít). L2ARC helyett inkább több DRAM az ajánlás. Ha van, a SLOG legyen mirror, az L2ARC pedig stripe.
------------------------
{0} ok boto
boto ?

az a baj h csak az async write-ra van a write cache alapból.

--
Gábriel Ákos

Milyen write cache? A memóriában van cache mindennek kiírásig.

Yep. Az async write rendben is van.
De a sync write sajna csak akkor tér vissza amikor kint van a diszken - ez ami lassúnak érződik nálam.
--
Gábriel Ákos

Mi legyen akkor a sync? Ki is kapcsolhatod.

Ezen morfondírozok már pár napja h meglépem.
--
Gábriel Ákos

1T/1G-t én a dedup nélkülire értettem.
A Dedup az egy külön állatfaj ebből a szempontból :D

mdadm, zseniális.

Idézet:
Gyakorlatilag bárhogy hangoltuk Linux alatt

Talán érdemes lenne más, stabilabb ZFS implementációt is kipróbálni.

Tömörítés jó ötlet, tegyél alá ssd-t cache-nek.
Dedup nem kell, nincs értelme.
--
Gábriel Ákos

Lazán kapcsolódik: én még sose használtam Linux alatt ZFS-t, csak Solaris 10/11-en (munkahely) és FreeBSD-n (otthoni FreeNAS-ok), ezért érdekes a szívásokról olvasni.

A dedupot én se javasolnám itt, nem hoz annyi előnyt, amennyi memóriát fölzabál. Az email szöveg, jellemzően a mailbox és a Maildir formátum is úgy tárolja, emiatt remekül tömöríthető, azt mindenképpen kapcsold be.

Az meg tévedés (bár a linuxos implementációt nem ismerem), hogy menet közben a dedupot nem lehet ki-bekapcsolni. Lehet, de csak az utána kiírt adatokra lesz hatással. Ahogy a tömörítés is.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Dedup-al több a szívás mint, amit megér... főleg ha borul valami.
Akkor már inkább rendszeres archiválás.

ui: Ha esetleg szemezgetnél a btrfs-el akkor azzal is csak óvatosan.
A btrfs-transaction process sok kis fájlművelet esetén úgy bezabálja a gépet, hogy öröm nézni.
pl: drivish alapú biztonsági mentés alá kb egyenlő egy atombombával.

Levelező szerverre felejtős a zfs dedup.
A zfs blokk szinten deduplikál, a default 128k-s blokkméretnél az átlag levél kisebb, vagyis 1 blokkban elfér. A minimálisan, de mégis eltérő fejlécek miatt ezért gyakorlatilag semmi nem lesz deduplikálva.
A dedup nem csak a memóriát zabálja fel, de a cpu-nak is odatesz.

lz4-el lehet spórolni 10-40%-ot, attól függően, hogy az adatmennyiségben mennyi a csatolt kép(vagy video, vagy egyéb nem tömöríthető adat) (Sőt az IO terhelést is tudja kicsit csökkenteni a cpu "kárára")

otrs article zfs-en
refcompressratio 1.84x
usedbydataset 49.5G
logicalused 82.6G

ugye itt is a levelek vannak gyakorlatilag