Relatívne nedávno som tiež riešil nové NAS. To pôvodné bežalo na mini-ITX s integrovaným Intel CPU a ako skriňa Fractal Node 304. Vhodných mini-ITX dosiek a skriniek pre NAS v našich končinách prakticky niet (viď článok), tak som presedlal na klasické mATX.
- mobo ASRock B550M Pro4 (podporuje ECC)
- CPU AMD Ryzen 3 4350G (integrovaná GPU), RAM 32 GB ECC
- skriňa Fractal Node 804
- 2x SSD SATA + 6x HDD SATA 6 TB WD Red Pro + 1x SSD NVME
- OS Debian, mdraid 1+lvm (SSD), zfs (HDD), xfs (NVME)
10. 9. 2025, 09:06 editováno autorem komentáře
Já zase Wira obdivuju, že do toho šel. Ač umím s 3D CADem celkem dobře, tak jenom to patlání to nakonstruovat je na víc hodin. Teď momentálně čekám na 3 skříňky https://www.iovstech.com/nasstorageserver/nas-4bays-case-nas04j.html
Ale než se dočkám, tak schválně zkusím udělat tu Wirovo (je moc pěkná).
Jinak fakt pěkný článek Wiro, díky za něj.
Jenom bych se chtěl zeptat, teďkon rozjíždím GARAGE S3, a tam doporučují XFS, a nemusí se dělat raid vzhledem k tomu, že budou 3 geograficky oddělená místa. Doporučili byste to taky?
Dík.
Jednoducha odpoved je, ze pokud to doporucujou, tak bych to pouzil taky :)
Sirsi odpoved je ze zalezi na workloadu. Neplati uplne ze vzdy je XFS lepsi nez treba Ext4.
XFS ma hlavni vyhody pokud:
- se jedna o praci s velkyma souborama
- pozadavek na velke prenosove rychlosti
- duraz na zvladani velkeho mnozstvi paralelnich operaci
Predpokladam ze u S3 je prave potencial naplnit ty podminky kde XFS muze vyrazne lip performovat.
Ahoj Wiro,
primární použití bude bucket pro Nextcloud: více méně malé soubory do 100MB. Připojení na internet mám pomalé (2 místa do 300Mb/s, 1 místo do 100Mb/s, na VPS si až to rozjedu přikoupím 1Gb/s) a dále na inkrementální zálohu mail serveru (bucket pro email, pouze 6 lidí, zabírat to bude pár giga). Disky mám co jsem tady sehnal jsou to SATA3 do 6Gb/s. Mám v plánu tam mít cca 6TB na data, zbytek budou archivní věci, na které budu šahat sporadicky -> 4. NASka 2xraid1.
V.
O ty ostatní zmíněné výhody XFS (alokační skupiny, lepší paralelismus, škálování atd.) až tak nejde.
Ten primární důvod je pevný počet inodů (prealokované místo) u ext4, kde se to specifikuje jen při vytváření filesystému (většinou jako poměr - např. "mkfs.ext4 -i 4096" vyhradí pro každé 4 kilobajty dat jeden bajt na inody, default je myslím 16k).
Za normální situace každý soubor, adresář nebo symlink spotřebuje jeden inode.
S tím S3 serverem tam je ale ještě další vrstva, která větší soubory rozděluje na chunky (což může být např. 1 megabajt, nebo něco jiného podle potřeby). Na filesystému pod tím je pak každý chunk uložený jako samostatný soubor, takže ta spotřeba inodů může být výrazně větší, než když se to ukládá rovnou.
Je to asi primárně záležitost větších úložišť, ale ovlivňuje to i zvolená velikost chunku, délka ukládaných souborů, nastavení při vytváření fs atp. Dá se pak také samozřejmě dopočítat, kdy by to byl problém, resp. kolik inodů se na daný systém vejde.
XFS.. pak má dynamickou alokaci místa na inody, tzn. prakticky to pevné rozdělení vůbec nemusíte dopředu řešit, proto to doporučení.
Jinak CoW filesystémy jako Btrfs nebo ZFS mají také dynamickou alokaci inodů, ale obecně mnoho jejich výhod v tomhle použití trochu padá tím, že je nad fs další vrstva, kde se také počítají checksumy a redundance je v tomhle případě řešená replikací celých souborů resp. chunků na jiné nody.
U RAIDu pod tím je to pak nejspíš na zvážení podle použití..
Pokud tam bude a dojde k výpadku jednoho z disků, tak ten node kompletně pojede dál v degradovaném režimu a po výměně bude citelně rychlejší rebuild (data se berou lokálně blokově), na druhou stranu zas přijdete o místo.
Pokud použijete multi-disk v Garage, tak bude mít víc místa, ale zároveň když nastane výpadek, vyměníte disk, vytvoříte fs a připojíte jej do stejného adresáře, tak se všechny chunky budou zpátky kopírovat po síti, aby se doplnil nastavený počet reundantních kopií.
Finálně při těch uvahách o rychlostech je třeba brát v potaz také to, že pokud mám např. tři nody a na jeden kontinuálně zapisuji (např. v rámci LAN, nebo jednoho serveru s virtuály, kontejnery), tak se ty chunky musí dostat na zbylé dva nody.. a teoretická rychlost uploadu se pak dělí dvěma.
U krátkých zápisů (co jsou menší než nastavený buffer) mu stačí potvrdit zápis jen z jednoho dalšího nodu, aby si splnil kvórum, a do třetího (nejpomalejšího) pak zapíše asynchronně. Ale když do toho budu kontinuálně hrnout data, naplní se ten buffer a v podstatě pořád čekám na oba dva. Další faktor, co v tom hraje roli, bude pak samozřejmě i latence sítě mezi nody.
Já to čtu tak, že cesta a svoboda je cíl. Nejlepší investice je investice do rozšiřování vlastních zkušeností/dovedností. Za mne krásný seriál a děkuji za něj.
Ano, je možné koupit hotový case nebo koupit hotový NAS. Modelář si také může koupit hotový model a nemusí stovky hodin lepit jedno letadýlko. Těžko mu ale jeho počínání rozmluvíte. :)
Přesně! Já třeba si bastlil prakticky všechno na moje koníčky (včely: medomet-oříšek co jsem neuměl a naučil se byl regulák na motor z pračky, abych to nemusel kupovat za 10+ tisíc, líheň na matky -> tam jsem se naučil dělat reguláky pomocí arduina+esp a dělal jsem si jednoduchý monitoring na webovkách + upozornění pomocí externího cronu do mailů, drony, 3d tiskárny, OpenCV na počítání včel apod...:-), občas taky něco nakonstruuju, abych v tý Catii úplně nezakrněl ). Tak právě proto dělám to S3 úložiště, protože mě to zajímá. Nejspíš by mi stačila obyč NASka za pár korun, ale to bych se právě nenaučil plno věcí okolo, co je třeba k tomu, aby to bylo funkční - doteď jsem vše řešil exterňákama a více či méně mi to stačilo. Cesta je cíl a pro mnoho lidí je největší odměna, že to zvládli udělat sami i když by ostatní řekli "takový práce a přitom taková blbost" :-)