ZFS méretezés segítség!

Naplózó filerendszerek (journaling)

Sziasztok!

Nem teljesen pontosan írja le a cím a problémát, vagy inkább a segítségkérés okát, de picit kifejtem:
- van 12 db 6T-s diszk egy JBOD dobozban
- 2*1T lemez, meg 2*240 GB SSD a gépben

Hogyan lenne érdemes összefogni a lemezeket, hogy optimális legyen a helykihasználás, és a redundancia legalább 2 lemez halálát elviselje. (elsősorban azért, mert a fene tudja, mennyi idő alatt tudunk pótolni kieső lemezeket... - egyetemen vagyunk...)
Raidz2 nyilván a cél, de azt írják, érdemes inkább 8 lemezzel megcsinálni, ekkor olyan 35T lesz a nettó kapacitás.
Ebben az esetben marad 4 lemez, amit mondjuk össze tudok fogni 2*2 mirrorba, vagy egy másik Raidz2-be.

Esetleg érdemes a vdeveket másképp szervezni?

Másik kérdés, hogy a 2 SSD-t az egyik zpool-hoz rendeljem hozzá, vagy mondjuk megfelezve kapja meg mindkettő a rá eső részt log-ként.
A nagyobb részre sok, relatíve nagy, nyers videó menne, a kisebbre elsősorban asztali gépek mentései.
De igazából feltétlenül muszáj megosztani a tárolókapacitást.
Igazán nem kritikus a sebesség, a szerverben 2db GbE van, a kliensek is gigabiten ülnek.

A fő problémám az, hogy ez egy picit (ha nem is nagyon) túl van a hobbi-kategórián, és a RAID-ek méretezése, optimializálása az eddigi tudásomtól, tapasztalataimtól messze áll.
Olvasgattam, de kíváncsi vagyok, ki mit ajánl, milyen megfontolások lennének (amikről esetleg nem is hallottam), mikre érdemes odafigyelni.

Openindiana van rajta.

Kiegészítés:
16GB, Xeon 1620-V3
A lemezek egy LSI SAS2008 vezérlőn ücsörögnek, egy Intel JBOD dobozban. Ez utóbbi pontos típusát nem tudom fejből.
A lemezek típusa: Seagate ST6000VN0031 7200rpm

Köszönöm!

  • 1511 megtekintés

( sibike | 2017. 03. 21., k – 13:32 )

"Raidz2 nyilván a cél, de azt írják, érdemes inkább 8 lemezzel megcsinálni, ekkor olyan 35T lesz a nettó kapacitás."

Nem tudok 8 lemezes korlátról. Használhatod 12 lemezes RAIDZ2-ként, a sebesség lesz a kérdéses. Ha nem vagytok szűkében a helynek, akkor két 6 lemez RAIDZ2-vel jobban járnátok.

"Másik kérdés, hogy a 2 SSD-t az egyik zpool-hoz rendeljem hozzá, vagy mondjuk megfelezve kapja meg mindkettő a rá eső részt log-ként."

A log device csak szinkron írásnál játszik szerepet, ilyenből az általad használt felhasználásnál nincs sok, lehet L2ARC cache-ként jobban tudod az ssd-t hasznosítani. (Vagy elvágva az ssd nagyobb fele ramdisk, a kisebb log device)

Mennyi RAM van a szerverben?

Nem, a videókat ott csak tároljuk majd.
Feldolgozva helyben lesznek: nyers videó feltölt, ha kell kikeres, letölt, csinálamitakar vele :), visszatölt.
Mosom kezeimet... Akkora kupi lesz itt az adatokkal, mint annak a rendje. De az nem az én bulim :)
<-------
You can't grep on dead trees.

( aspirin v | 2017. 03. 21., k – 13:47 )

Sziasztok,
beleírtam a nyitó hozzászólásba a RAM, CPU, SAS HBA, és a lemezek típusát.
<-------
You can't grep on dead trees.

( akoscomp | 2017. 03. 21., k – 14:26 )

Használhatsz raidz3-at vagy inkább nested raidz-t, ami azt jelenti, hogy 3 darab raidz-t fog egy poolba.
A 2 SSD-t pedig stripe-ban cache-ként adhatod hozzá a pool-hoz.

( mauser1 v | 2017. 03. 21., k – 15:51 )

Openindiana? biztos, már leálltak a fejlesztésével.

( AiRLAC v | 2017. 03. 21., k – 16:00 )

16G RAM 35T adathoz lehet kevés lesz. Inkább több ram mint SSD cache, főleg ilyen sequential IO patternnél.

A FreeNAS-osok ajanljak ezt elsosorban, de meg ok is azt mondjak, hogy ez az okolszabaly 16G-ig ervenyes, utana nem feltetlen, es alapvetoen a hasznalattol es beallitasoktol fugg. Tehat peldaul keves klienshez, dedup nelkul teljesen oke 32G/128T. Ezenkivul lehet jatszani az ARC-el meg a ZIL-al.

----------------------
while (!sleep) sheep++;

( nagylzs v | 2017. 03. 24., p – 20:24 )

http://wintelguy.com/zfs-calc.pl

Amúgy raidz-nél ha több a lemezek száma akkor nagyobb a kihasználtság, de ezzel azért vigyázni kell. A lemezek számával lineárisan növekszik a meghibásodás esélye is.