Dobrý den,
pokud to vezmu postupně:
1, raidz vs mirror
Obecně by se dalo říct že raidz má mírně lepší bandwidth a mirror má lepší IOPS.
U klasického raid5 platí že pokud chceme přečíst malý blok který je jen na jednom disku tak poté nám stačí číst jen z tohoto jednoho disku. ZFS ovšem u všech dat ověřuje konzistenci a checksum je uložen pro celý stripe. Takže pokud chceme přečíst jeden blok z jednoho disku v raidz tak stejně musíme přečíst data i z ostatních abychom mohli ověřit součet.
Proto u mirroru máme teoretickou rychlost čtení <počet_disků>*<rychlost_disku> a u raidz máme 1*<rychlost_nejpomalejšího_disku>
Pěkné porovnání rychlostí různých raidů na zfs je zde:
https://calomel.org/zfs_raid_speed_capacity.htmlPokud to nechcete procházet celé tak jen porovnání 2*mirror vs raidz2
4x 4TB, 2 striped mirrors, 7.5 TB, w=226MB/s , rw=53MB/s , r=644MB/s
4x 4TB, raidz2 (raid6), 7.5 TB, w=204MB/s , rw=54MB/s , r=183MB/s
2, Rozdělení poolů
Zde je to podle preferencí. Já osobně bych udělal, jak píšete, pool pro proxmox, pool a pro zálohy ale jen jeden pool na data. Výkon toho datového poolu bude mnohem lepší když v něm budou všechny VDEV a ne jen polovina a druhá polovina v testovacím poolu.
A ten pool pro data bych dělal takhle:
disky bych dával v mirroru. Nejen že se to dá krásně rozšířit ale pokud by jste chtěl dev pool tak jen zavoláte "zpool split"
https://openzfs.github.io/openzfs-docs/man/8/zpool-split.8.htmla z poolu máte najednou 2 pooly kde druhý pool má naprosto stejná data i nastavení, můžete na něm cokoliv testovat a pak až nebude potřeba tak ho jen zrušíte a pomocí "zpool attach" postupně předěláte první zpool aby byl opět redundatní.
backup pool bych udělal jako raidz1 ze 3 disků. Je to odolné proti výpadku jednoho disku a to mi přijde že je na zálohy dostatečné (samozřejmě záleží jaké Vy máte nároky na zálohy).
Backup pool osobně využívám jen pro případ že by hlavní pool odešel takže pro mě pokud odejde backup pool a produkce zůstane funkční tak to není problém protože data mám na produkčním poolu ve snapshotech.
A šance že se rozbije produkce a zároveň odejdou 2 ze 3 disků na backupu je mizivá.
3, rozdělení na datasety, opět je to jen můj názor:
Rád si data uspořádávám logicky do datasetů. Nic mě to nestojí a můžu pro každá data nastavit přesně to co jim vyhovuje.
Například:
iso dataset - recorsize například 1M (stejně většina čtení bude sekvenční), primarycache=metadata (předpokládám že isa se nečtou tak často aby mělo smysl je cachovat v RAM)
dataset pro obrázky,hudbu: asi bych asi nastavil secondarycache=none. To že se malý obrázek zacachuje v RAM mi nevadí ale asi nechci aby mi opotřebovával SSD a cachoval se na ssd když u toho obrázku o výkon načtení tolik nejde.
Pokud jsou videa v jednotné cestě tak bych pro ně udělal zvlášť dataset, pokud jsou namíchané mezi obrázky tak bych pro ně dataset nedělal.
ostatní datasety pro osobní data bych udělal analogicky.
4, jak využít SSD
Na obou ssd bych udělal malý oddíl pro SLOG, stačí 4GB a ten dal v mirroru pro proxmox pool.
Jen pro vysvětlení: oproti na různých forech opakovanému omylu tak stačí SLOG jen hodně malý. SLOG drží synchronně zapisovaná data co jsou v RAM aby mohlo zfs potvrdit že data jsou na bezpečném uložišti. Takže velikost slogu nemá smysl větší než velikost zápisové části RAM v ZFS a to je 4GB. Data se ale při normálním provozu z SLOGU nečtou. Z něj by se čeli jen při pádu systemu když má data ještě v RAM. Takže i když je častý omyl že SLOG zrychlí zápis na pool tak SLOG sníží jen latenci zápisu protože půjde zápis potvrdit dřív ale bandwith je pořád omezený tím pomalým úložištěm.
SLOG pro data pool bych asi nedával. Nevím sice co tam půjde za provoz ale moc synchronních zápisů tam předpokládám nebude (v porovnání s SQL serverem na proxmoxu) a pro asynchronní zápisy se nepoužije.
Cache bych pro datový pool nedával při vatvoření poolu, podle toho co píšete tak NAS má dost RAM, takže možná bude hitrate dobrý i bez cache.
Pokud by se ukázalo že L2ARC není potřeba a hitrate je dobrý i bez ní tak bych zvážil z toho udělat special device v mirroru a dal jí pro datový pool.
https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954Pak by právě malé soubory jako metadata byly na rychlém SSD takže se uleví plotnám a podle povahy dat by šlo pro dataset kde jsou osobní data a maily nastavit parametr "special_small_blocks".
To dělá to že soubory menší než nastavená hodnota se budou preferovaně ukládat na special device.
Tedy malé náhodné zápisy a čtení které dělá plotnám největší problém přesunete na ssd které s tím nemá problém.
Jen pozor že na to zatímco slog a L2ARC se dá odebrat kdykoliv tak special device ne (teda jo, ale až v zfs2.0)
5, pár rychlých poznámek na konec
při vytváření poolu nastavit ashift=12, jinak bude problém když se přidá disk co má fyzicky 4k sektory
vypnout ashift, zfs je CoW filesystem a aktualizace času přístupu k souboru znamená změnit data v hlavičce -> tedy kvůli CoW udělat kopii hlavičky jinde. To vede k velké fragmentaci
vždy zapnout kompresi - zfs detekuje nekomprimovatelná data a ty nekomprimuje a dekomprese samotná je stejně hodně optimalizovaná a na vytížení CPU není poznat.
snapshot nezabírá při vytvoření skoro žádné místo a i pak jsou v něm jen změněné bloky a dobře chrání proti smazání dat omylem. Je mnohem lepší namountovat pár minut starý snapshot a jen obnovit smazanou složku nebo dokonce udělat roolback celého snapshotu při větším smazání, než si tahat data den stará data z backup serveru.
zfs send je mnohem lepší na zálohování než rsync. Oproti rsyncu nepřenáší změněné soubory ale jen změněné bloky.
Vytvoření zpoolu a nastavení zfs stejně nejvíc záleží na uložených datech a osobních preferencích ale snad Vám tyto rady pomůžou.
18 Odpovědí
12519 Zhlédnutí