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!
- 2110 megtekintés
Hozzászólások
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. ;-)
- A hozzászóláshoz be kell jelentkezni
Minden kezdo zfs felhasznalo ra van izgulva a dedup-ra.
Marginalis mennyisegu a valos felhasznalasi lehetoseg a jelenlegi megoldassal.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
nekem pl anno 100G sqldumpoknal jol jott a dedup :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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,
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Oh, pardon, tényleg.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Nem.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Szorri de a 3T-s lemezek raid6 az eléggé elcseszett konstrukció.
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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....
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 ?
- A hozzászóláshoz be kell jelentkezni
az a baj h csak az async write-ra van a write cache alapból.
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Milyen write cache? A memóriában van cache mindennek kiírásig.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Mi legyen akkor a sync? Ki is kapcsolhatod.
- A hozzászóláshoz be kell jelentkezni
Ezen morfondírozok már pár napja h meglépem.
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
1T/1G-t én a dedup nélkülire értettem.
A Dedup az egy külön állatfaj ebből a szempontból :D
- A hozzászóláshoz be kell jelentkezni
mdadm, zseniális.
- A hozzászóláshoz be kell jelentkezni
Gyakorlatilag bárhogy hangoltuk Linux alatt
Talán érdemes lenne más, stabilabb ZFS implementációt is kipróbálni.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Tömörítés jó ötlet, tegyél alá ssd-t cache-nek.
Dedup nem kell, nincs értelme.
--
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
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!”
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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")
- A hozzászóláshoz be kell jelentkezni
otrs article zfs-en
refcompressratio 1.84x
usedbydataset 49.5G
logicalused 82.6G
ugye itt is a levelek vannak gyakorlatilag
- A hozzászóláshoz be kell jelentkezni