Dotaz: NAS software

[JLL]

Ahoj,

znáte nějaký vhodný NAS software/distribuci? Jde mi o nějaký webový ksicht, který bude přikrývat bězné věci jako řešení práv (přes LDAP), sambu, FTP(s), rsync (rdiff)... Určitě ne ZFS (na moje nasazení hodně pomalé a složité) ideálně něco, co dokáže jet i na ARM.

Díky.

Odpovědi

[_]

Armbian + Openmediavault na odroid HC2 - za mě na malý domácí nas ok, bohužel se objevují věci co chtějí více ram, nebo 64 bitový system a to chce pak asi koukat jinam

[Dave]

Mam

 

HPE ProLiant MicroServer Gen8 12GB RAM (SSD na system a plotnove disky do RAIDu) + Openmediavault + ZFS

 

a velka spokojenost.

 

V dnesni dobe bych asi zkusil FreeNAS misto Openmediavault.

 

D.

[Dave]

Teda FreeNas se prejmenoval na TrueNAS.

D.

[JLL]

ZFS nechci. Kdekoliv jsem to nasadil, tak to bylo pekelne pomale a nakonec jsen to predelaval. Podle me to neni na male veci vubec vhodne.

[Dave]

ZFS neni nutne staci si vybrat cokoliv jineho co Openmediavault poporuje v GUI

EXT3/EXT4/XFS/JFS/… filesystem support Software RAID JBOD/0/1/5/6/…

Pokud GUI na nastavovani nepotrebujes tak pod openmediavault bezi Debian tak cokoliv co podporuje Debian.

[Heron]

Já teda nevím, jedu FreeBSD + ZFS na serveru postaveného z desktopu z roku 2013 a nic pomalého mi na tom nepřijde. Stejně to limitují ty rotační disky a zápis 600MB/s na pole mi stačí. 6 disků ZFS + SSD pro systém a jak krásně to doma frčí.

[JLL]

Be pochyby to jde, ale jednak je na to potřeba dost zdojů (QC a 16GB) a také to asi naladit. Zrovna tak jsem zjistil, že je to zcela nepoužitelné v libovolné firmě, kdy to není příko na HW (virtualizace, nebo třeba svazek nad luks).

[Heron]

Na takto malé instalace to možná fakt není, ale upřímně QC a 16GB je tak rok 2010. Do firmy bych se o tom vůbec nebavil. Skládačka s 32GB RAM, 8/16 cpu a dvěma SSD (třeba pro ZFS cache) se dá pořídit i za dnešní ceny kolem 14tis. + disky (které je potřeba mít u každého řešení). Případně v serverové variantě od značky za 30+.

[JLL]

To jo, ale mým cílem je něco malého a nežravého - tzn. Atom nebo ARM, potřebuju saturovat jen gigabit. ZFS je na takové využití zbytečný overkill.

[JLL]

Ad. ono se to nezdá, ale mě už teď tahle osobní infrastruktura žere asi 25 MWh ročně, což docela leze do peněz. Nasů mám 6 na různých místech, z toho pouze 2 provozní, ostatní jsou zálohy. Jeden z mých cílů je to i redukovat na spotřebě (ono to fakticky není zase tak moc - cca 280W trvale). Každých 10W je cca 500,-....

[JLL]

*2800

[Heron]

Neznám váš setup, ale těch 6NASů máte v jednom bytě / domě nebo na více lokalitách? Tohle by měl levou zadní zvládnout jeden dobře dimenzovaný server (a nemusí to být žádné dělo) s příkonem do 100W.

Nemám rád slovo NAS, ale doma starý desktop vždy slouží ještě jako domácí server a aktuálně je to ten FX8350 z roku 2013, 32GB RAM + ultralevná grafika + disky. Spotřeba (bez vytíženého CPU) do 100W (typicky 80W) a na nasování to bohatě stačí. Výkon ZFS stejně brzdí rotační disky nebo síť.

Nic proti různým armům, tohle píšu jen spíš pro inspiraci, že x86 není nutně tak nenažrané jak se tvrdí a poměr spotřeba výkon je někde jinde. (A dneska se dá samozřejmě postavit úspornější stroj, než bývalý herní desktop.)

[JLL]

6 uložišt na 5 lokalit (dvě vyloženě pracovní, 3 mimo jako zálohy). Větěšinu z toho co mám jede na DL380/DL360 G8 (ty dva primární jsou virtualizované nad tím, ZFS na virtualizaci - luks + lvm - fakt neee) cca 200W IDLE (2 CPU, 144GB ram). Ostatní jsou právě nějaké staré deskopy. Je možné, že dělám nějakou systematickou chybu, ale ze ZFS jsem vždycky dostal tak 40MBps a ještě velkou latenci. A jako bonus, ze se to občas totálně zasekalo.

[Heron]

Asi tam bude někde chybka, protože tyhle stroje musejí zvládat zfs levou zadní. Mám zkušenosti pouze s FreeBSD (nativní zfs v jádře), takže nevím, jak jsou (byly) na tom implementace zfs na linuxu, takže těžko radit. Nebyla tam zaplá deduplikace? Příliš velká komprese? Disky přímo v ZFS, nebo přes nějakou další vrstvu?

[JLL]

Zkoušel jse různé konfigurace.

Na výše uvedených byl buď proxmox a storage nad luks+lvm, ev. jsem zkoušel i luks+zfs přímo (což jsem následně zrušil, protože to bylo nepoužitelné).

Zkoušel jsem i FreeNAS na fyzickém železe (N54L + 8GB) taky zlo...

Nevím, prostě c ZFS je nějaký problém, vyžadující silný hardware a asi i jeho dost velkou znalost, na moje použití to tak není (neumím tuto znalost už dále prodat, nemá tím smysl do toho pálit více času). Kolega s tím vyhořel úplně stejně.

[dustin]

A nedělá tam problém ta vrstva luksu? ZFS na linuxu ve starším Dellu se 128GB RAM, RAID1, cca 16 disků (napřímo bez expandéru), jede parádně, rychlost výborná.

[MP]

Samozrejme, ze problem je v LUKSu. Je to single core, cili to rozbiji vykon SSD, ktere rady vyuzivaji paralelizaci. A G8 zrovna nejrychlejsi sifrovani nemaji, protoze jsou stare. Chcete dukaz? 2 roky stare Delly s Gold Xeony a 12Gbps SAS SSD polem trpelo ztratou 25% vykonu na luks vs nonluks.

[GeorgeWH]

Dell R630, 6GB RAM, Debian 10

2x enterprise SATA SSD => ZFS mirror => ZFS zvol => DRBD (10Gb) => GFS2

bs=10M

# fio --name=seqwrite --rw=write --direct=1 --ioengine=libaio --bs=10M --numjobs=4 --size=3G --runtime=30 --group_reporting
seqwrite: (g=0): rw=write, bs=(R) 10.0MiB-10.0MiB, (W) 10.0MiB-10.0MiB, (T) 10.0MiB-10.0MiB, ioengine=libaio, iodepth=1
...
fio-3.12
Starting 4 processes
seqwrite: Laying out IO file (1 file / 3072MiB)
seqwrite: Laying out IO file (1 file / 3072MiB)
seqwrite: Laying out IO file (1 file / 3072MiB)
seqwrite: Laying out IO file (1 file / 3072MiB)
Jobs: 4 (f=4): [W(4)][100.0%][w=340MiB/s][w=34 IOPS][eta 00m:00s]
seqwrite: (groupid=0, jobs=4): err= 0: pid=2827: Fri Jul  2 09:20:12 2021
  write: IOPS=35, BW=351MiB/s (368MB/s)(10.3GiB/30062msec); 0 zone resets
    slat (usec): min=1301, max=284189, avg=5095.55, stdev=9403.91
    clat (msec): min=10, max=916, avg=108.87, stdev=95.46
     lat (msec): min=13, max=1084, avg=113.97, stdev=97.74
    clat percentiles (msec):
     |  1.00th=[   15],  5.00th=[   25], 10.00th=[   30], 20.00th=[   37],
     | 30.00th=[   47], 40.00th=[   58], 50.00th=[   75], 60.00th=[  103],
     | 70.00th=[  136], 80.00th=[  171], 90.00th=[  230], 95.00th=[  292],
     | 99.00th=[  376], 99.50th=[  447], 99.90th=[  885], 99.95th=[  919],
     | 99.99th=[  919]
   bw (  KiB/s): min=20439, max=204800, per=25.37%, avg=91068.26, stdev=31490.80, samples=236
   iops        : min=    1, max=   20, avg= 8.75, stdev= 3.11, samples=236
  lat (msec)   : 20=2.37%, 50=30.74%, 100=26.38%, 250=32.16%, 500=7.97%
  lat (msec)   : 1000=0.38%
  cpu          : usr=1.66%, sys=1.05%, ctx=6872, majf=0, minf=52
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,1054,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=351MiB/s (368MB/s), 351MiB/s-351MiB/s (368MB/s-368MB/s), io=10.3GiB (11.1GB), run=30062-30062msec

Disk stats (read/write):
    drbd0: ios=1/23989, merge=0/0, ticks=76/2306840, in_queue=2312500, util=99.49%, aggrios=1/23991, aggrmerge=0/0, aggrticks=4/859528, aggrin_queue=860172, aggrutil=96.89%
  zd0: ios=1/23991, merge=0/0, ticks=4/859528, in_queue=860172, util=96.89%

bs=64k

# fio --name=seqwrite --rw=write --direct=1 --ioengine=libaio --bs=64k --numjobs=4 --size=3G --runtime=30 --group_reporting
seqwrite: (g=0): rw=write, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=1
...
fio-3.12
Starting 4 processes
seqwrite: Laying out IO file (1 file / 3072MiB)
seqwrite: Laying out IO file (1 file / 3072MiB)
seqwrite: Laying out IO file (1 file / 3072MiB)
seqwrite: Laying out IO file (1 file / 3072MiB)
Jobs: 4 (f=4): [W(4)][100.0%][w=139MiB/s][w=2229 IOPS][eta 00m:00s]
seqwrite: (groupid=0, jobs=4): err= 0: pid=20925: Fri Jul  2 09:24:44 2021
  write: IOPS=2138, BW=134MiB/s (140MB/s)(4011MiB/30002msec); 0 zone resets
    slat (usec): min=28, max=186285, avg=66.17, stdev=983.59
    clat (usec): min=5, max=847636, avg=1799.67, stdev=8268.41
     lat (usec): min=356, max=871106, avg=1866.48, stdev=8731.90
    clat percentiles (usec):
     |  1.00th=[   371],  5.00th=[   424], 10.00th=[   469], 20.00th=[   529],
     | 30.00th=[   603], 40.00th=[   783], 50.00th=[  1582], 60.00th=[  1876],
     | 70.00th=[  2147], 80.00th=[  2442], 90.00th=[  3752], 95.00th=[  4146],
     | 99.00th=[  5800], 99.50th=[ 10814], 99.90th=[ 18220], 99.95th=[ 19530],
     | 99.99th=[633340]
   bw (  KiB/s): min= 3968, max=41728, per=25.41%, avg=34780.64, stdev=6360.12, samples=235
   iops        : min=   62, max=  652, avg=543.37, stdev=99.36, samples=235
  lat (usec)   : 10=0.01%, 20=0.01%, 50=0.01%, 100=0.01%, 250=0.03%
  lat (usec)   : 500=14.79%, 750=24.03%, 1000=5.51%
  lat (msec)   : 2=21.33%, 4=27.47%, 10=6.26%, 20=0.53%, 50=0.02%
  lat (msec)   : 100=0.01%, 250=0.01%, 750=0.01%, 1000=0.01%
  cpu          : usr=1.01%, sys=4.35%, ctx=65714, majf=0, minf=55
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,64173,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=134MiB/s (140MB/s), 134MiB/s-134MiB/s (140MB/s-140MB/s), io=4011MiB (4206MB), run=30002-30002msec

Disk stats (read/write):
    drbd0: ios=1/69350, merge=0/0, ticks=0/1137592, in_queue=1137612, util=99.29%, aggrios=1/69393, aggrmerge=0/0, aggrticks=0/103032, aggrin_queue=103052, aggrutil=81.78%
  zd0: ios=1/69393, merge=0/0, ticks=0/103032, in_queue=103052, util=81.78%

[GeorgeWH]

Poznamka - velkost bloku (volblocksize) som musel nastavit na 128k, inac to bolo velmi pomale. Kompresiu mam vypnutu, primarycache=metadata a secondarycache=metadata - toto mi myslim tiez pomohlo.

Zapnuta kompresia (lz4):

# fio --name=seqwrite --rw=write --direct=1 --ioengine=libaio --bs=10M --numjobs=4 --size=3G --runtime=30 --group_reporting
seqwrite: (g=0): rw=write, bs=(R) 10.0MiB-10.0MiB, (W) 10.0MiB-10.0MiB, (T) 10.0MiB-10.0MiB, ioengine=libaio, iodepth=1
...
fio-3.12
Starting 4 processes
seqwrite: Laying out IO file (1 file / 3072MiB)
seqwrite: Laying out IO file (1 file / 3072MiB)
seqwrite: Laying out IO file (1 file / 3072MiB)
seqwrite: Laying out IO file (1 file / 3072MiB)
Jobs: 3 (f=3): [W(3),_(1)][90.3%][w=380MiB/s][w=38 IOPS][eta 00m:03s]
seqwrite: (groupid=0, jobs=4): err= 0: pid=5138: Fri Jul  2 09:30:52 2021
  write: IOPS=42, BW=428MiB/s (449MB/s)(11.0GiB/28701msec); 0 zone resets
    slat (usec): min=982, max=63277, avg=4766.85, stdev=3506.68
    clat (msec): min=8, max=646, avg=85.36, stdev=87.74
     lat (msec): min=12, max=648, avg=90.14, stdev=87.62
    clat percentiles (msec):
     |  1.00th=[   11],  5.00th=[   14], 10.00th=[   17], 20.00th=[   33],
     | 30.00th=[   42], 40.00th=[   48], 50.00th=[   55], 60.00th=[   64],
     | 70.00th=[   77], 80.00th=[  106], 90.00th=[  243], 95.00th=[  305],
     | 99.00th=[  359], 99.50th=[  380], 99.90th=[  634], 99.95th=[  651],
     | 99.99th=[  651]
   bw (  KiB/s): min=20398, max=397319, per=25.48%, avg=111653.06, stdev=52861.71, samples=219
   iops        : min=    1, max=   38, avg=10.61, stdev= 5.12, samples=219
  lat (msec)   : 10=0.41%, 20=12.13%, 50=30.86%, 100=35.83%, 250=11.24%
  lat (msec)   : 500=9.36%, 750=0.16%
  cpu          : usr=1.56%, sys=1.12%, ctx=13276, majf=0, minf=47
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,1228,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=428MiB/s (449MB/s), 428MiB/s-428MiB/s (449MB/s-449MB/s), io=11.0GiB (12.9GB), run=28701-28701msec

Disk stats (read/write):
    drbd0: ios=1/26500, merge=0/0, ticks=0/1655876, in_queue=1655352, util=99.55%, aggrios=1/26609, aggrmerge=0/0, aggrticks=0/555608, aggrin_queue=567840, aggrutil=81.35%
  zd0: ios=1/26609, merge=0/0, ticks=0/555608, in_queue=567840, util=81.35%

Ale to sa mi nezda. fio generuje prazdne bloky?

[JiK]

neni neco jako ten TrueNAS core, ale vic lightweight? Aby to sice melo hezke webove ui, ale zaroven bezelo na raspberry s jednim nebo vice 1TB SSD diskem? Aby to delalo time machine pro domaci macbooky, sklad filmu pro kodi, a nic moc vic?

[Ruža Becelin]

Pouzival jsem OpenMediaVault 4, na domaci i firemni pouziti OK, bezi mi to na HP MicroServer G7, jakmile prevedu primarni data na nove reseni, tak tam dam OMV 5 a bude to delat backup.

[Max]

Myslím si,že se rozhoduješ mezi:

• OpenMediaVault
• unraid
• Xpenlogy (fork oss varianty Synology)

Zdar Max

[bigBRAMBOR]

Xpenlogy - ufff to bych se dost bal, zkousel to nekdo?

[vladky]

Je to v pohode funkcne, problem je iba ak sa to aktualizuje. Ale nepouzivam to produkcne, bolo to len na test. Na test sa do da spustit aj napr. vo virtualboxe.

[Max]

Tak já osobně bych nešel ani do Xpenlogy ani do OMV, není k tomu reálně žádný důvod. Nastavit si sambu, nfs, nějaký dlna apod. není tak ukrutně těžký, ale zase chápu, že se tím někdo nechce zabývat.
Zdar Max

[JLL]

Není, ale když tam potřebuješ jednou ročně něco změnit, tak strávíš den luštěním, jak to vlastně bylo a co se jak dělá.

[Max]

Nestrávím, protože buď si dávám do konfiguráků poznámky, nebo mám na serveru readme :)
To samozřejmě platí pro homodomo individuální věci. V rámci jobu jedu plnohodnotnou dokumentaci.
Zdar Max

[j]

Mnohem horsi je provozovat nejaky jak reseto deravy veci, ktery sou pusteny do site a navic je nejde nijak normalne aktualizovat.

Osobne neznam ani jedinyho homeusera, kterej by po nastaveni toho co chce, chtel nekdy v pristich 15 letech neco na konfiguraci menit.

Proto tvrdim, ze NAS ma byt Pclike x86 HW* a standardni distro dle preferenci soudruha, kterej to bude nastavovat.

*Proc ze to? Protoze nic jinyho nema vykon a neni dlouhodobe provozovatelny. Pokud se teda bavime v cenach, ktery je soho user ochotnej akceptovat. To PC se totiz pro danej ucel da vytahnout doslova z popelnice.

BTW: Tohle je jen mala ukazka jak to dopadne, kdyz si poridis neco co vsechno dela samo ... uz to propiraji i ty (ne?)fakenews media https://www.idnes.cz/technet/pc-mac/wd-western-digital-mybook-live-smazana-data-hackersky-utok.A210630_082800_hardware_nyv

---

Dete s tim guuglem dopice!

[tlacenka]

zkoušel a provozuju jako virtual na Proxmoxu + data na extra disku. Jeden starší "originál" Synology mám, tak jsem na to zvyklej. Ono jde i o ty aplikace co pak má běžný user v mobilu, nebo je používá přes web gui. Jsem spokojen. Problém mám s automatizací instalace, protože synology APi není uplne zdokumentované. Proto se chystám vyzkoušet OMV, někdy "až na to bude čas" :).

[JLL]

To teď používám. Ale je to blackbox, kde občas něco funguje podivně a bývá problém to opravit. Navíc je to poměrně pomalé.

[Petr Šobáň]

Já mám na rpi4 openmediavault.

A v něm mám i Pi-hole proti reklamám.

[JSOB]

Ted jsem to resil. Chtel jsem neco kde bych ukladal obrazy virtualnich stroju. Openmediavault - asi by vyhral, kdyby mel nejaky managment snapshotu. Toto tam proste chybi. Ano, jde to udelat v CMD.

Freenas - bohužel ZFS a její naročnost na HW (RAM). Jinak dobrý.

Rockstore - velmi zajimavé a pro mě má budoucnost. Ale nejak blblo GUI pri obnovováni ze snapshotu nebo mazani poolu...uz si to presne nepamatuji. V budoucnu mu dam urcite sanci.

Xpenology - nakonec vitez, ale nejak z nej odvazany nejsem. Radsi to neaktualizovat. Pri obnove z BTRFS snapshotu se to nejak kousne, ale po restartu to nabehne s pozadovanými daty. Nebo něco dělam blbě.

Když to shrnu asi by vyhrál OpenMediaVault kdyby měl ten management. Nevím jak je na tom s LDAP, který požaduješ. Byl v omv-extras na to plugin.

[cz_motyl]

OMV mam velmi rad, ale kdyz jej nekdo chce spojit s AD, je to proste problem. Proto vidim jako velmi zajimavou aktivitu projekt TrueNAS SCALE, coz je, zjednodusene receno, "konverze" zname NAS distribuce TrueNAS (drive FreeNAS nad FreeBSD) nad Debian. V teto chvili je uz v bete a verim, ze na podzim bude uz ve verzi pouzitelne pro produkcni prostredi. Vice zde: https://www.truenas.com/download-tn-scale/#

Bohuzel pro tazajiciho, byt z jeho potizemi se nemohu ztotoznit (mozna mel blbe nastavene cachovani), klicovym a jedinym filesystemem je zde opet ZFS, prinejmensim v alfa verzi tomu tak bylo, betu jsem jeste netestoval.

P.S. XPEnology mam nainstalovanych na spouste NASek a slape skvele. Krome zde jiz zminenych problemovych aktualizacich, zejmena ta posledni zpusobi nedostupnost, je zde dost vazna otazka legality pouziti...

[tlacenka]

jenom doplnim, že prblém s aktualizacema se týká samotného systému DSM, aktualizace aplikací funguje normálně.

[JLL]

Já jsem OMV zkoušel před cca třemi lety, ale bylo to tako porůznu rozbité (padající a selhávající GUI).

[Ruža Becelin]

Tohle trochu smrdi:

Downloading Xpenology is easy as pie. Subscribe to our newsletter, and we will send you the download links.