Często padają pytania w rodzaju: „mam osiem dysków jaki RAID najlepiej użyć?” albo „jaka konfiguracja RAID-Z jest najlepsza”. Często też zdarzają się sytuacje, że klient kupił sobie serwer na NAS i prosi o skonfigurowanie na nim TrueNAS bo jest fajny. Oczywiście nie ma problemu też uważam, że jest fajny, chętnie je konfigurujemy i wpieramy.

Tylko, że często są to serwery dobierane, cóż, nie koniecznie optymalnie. Jeżeli decydujemy się na prosty dysk sieciowy jak na przykład niewielki QNAP czy Synology i jego wydajność nie jest kluczowa to wtedy tak.  Mnożymy pojemność dysku razy ilość dysków potem odejmujemy jeden, ten zapasowy, i mamy pojemność macierzy. Koniec obliczeń, nic prostszego.

Tylko, że planując serwer plików oparty na ZFS jakim jest TrueNAS robi się to trochę bardziej skomplikowane. A jeżeli dodatkowo mamy w planach intensywnie korzystać z naszego serwera bo planujemy na nim trzymać dyski witalnych maszyn albo bazy danych albo montaż i edycję materiałów video to sprawa się komplikuje bardziej.

Jasne możemy kupić macierz ALL-flash wpakować w nią najszybsze dyski NVMe, kupę RAM jakiś niezgorszy procesor i będzie działało jak trzeba. Co więcej czasem olbrzymie wymagania sprawiają, że nie ma innego wyjścia. Tylko, że jeżeli dodatkowo potrzebujemy, żeby nasza macierz miała pojemność dziesiątek czy setek TB to takie rozwiązanie będzie kosztowało kilka worków pieniędzy.

Ale jeżeli wpadniecie na pomysł zastosowania rozwiązanie tzw Hybrydowego czyli dyski talerzowe uzupełniane dyskami SSD i chcecie to zrobić optymalnie a co za tym idzie wydać mniej worków pieniędzy wykorzystując zalety ZFS. To wtedy dobór i konfiguracja dysków może się zrobić skomplikowany i odpowiedź na pytanie „Jakie dyski potrzebuje do mojego NAS?” wybrzmi, kto by się spodziewał uwaga: „to zależy”

Chciałem jeszcze zwrócić uwagę, żeby nie przywiązywać się jakoś szczególnie to konkretnych liczb bo część z nich zmienia się zależnie od modeli i czasu. Chodzi bardziej o rzędy wielkości i porównanie. Podane parametry są mniej więcej aktualne na sierpień 2023. Bardziej chciał skupić się na przekazaniu różnic i mechanizmów wyboru niż konkretnych liczb.

Sterownik dysków z HBA dla TrueNAS (ZFS)

Zaczynając od podstaw zanim zaczniemy podłączać dyski musimy mieć do czego.
Większość serwerów jest domyślnie wyposażana w sprzętowe rozwiązania RAID. No i to jest spoko. Spoko do momentu kiedy chcemy korzystać z ZFS. ZFS potrzebuje komunikować się bezpośrednio z dyskiem dlatego potrzebujemy albo wbudowanego w płytę kontrolera dysków albo kontrolerów do dysków z funkcją HBA (host bus adapter). Jeżeli podłączymy dyski przez kontroler pełniący funkcję sprzętowego RAID to:

• niepotrzebnie dublujemy funkcjonalność RAID (ZFS da radę)
• utrudniamy/uniemożliwiamy dostęp do S.M.A.R.T. (ang. Self-Monitoring, Analysis and Reporting Technology) czyli mechanizmu dostarczającemu systemowi informacji o stanie dysku, usterkach a nawet przewidywanych usterkach zanim do nich dojdzie, to ważne informacje. S.M.A.R.T. daje również możliwość odczytania  numeru seryjnego a ZFS rozpoznaje dyski właśnie po numerze seryjnym.
• utrudniamy sobie wymianę dysku ponieważ w wypadku HBA wyłączmy serwer (albo i nie) zmieniamy dysk i resztę konfigurujemy przez stronę administracyjną TrueNAS . Jeśli mamy po drodze jakiś kontroler RAID to musimy konfigurować wymianę dysku już nie tylko w TrueNAS ale i w kontrolerze RAID i to często przy wyłączonym serwerze przez jakieś menu dostępne przy uruchamianiu serwera.
• kontrolery sprzętowe są szybsze w opcji HBA niż w funkcji RAID, mają mnie pracy
• jeśli kontroler dysków używa wbudowanego cache a z jakich powodów nie zorientujemy się, że baterie w tym cache się kończyły to ryzykujemy utratę danych w razie awarii zasilania.

Rodzaje nośników danych

Jeżeli chodzi o same nośniki danych nazywane przez zaszłości technologiczne „dyskami” w rzeczywistości już przecież najczęściej dyskami nie są. Dodatkowo określenie „dyski twardy” w odróżnieniu do miękkich niegdyś dyskietek, wydaje się być już jednak skrajnie nieadekwatne. Ale trzymając się jednak tej nomenklatury dyski co za pewne wiecie dzieli na talerzowe gdzie dane przechowywane są właśnie na kręcących się talerzach magnetycznych potocznie HDD i dyski półprzewodnikowe tzw SSD.

Dyski HDD 

Dyski HDD charakteryzują się dobrym stosunkiem pojemności do ceny. Na chwilę obecną nic nie zapowiada, żeby w świecie macierzy dyskowych nastawionych na duże czy ogromne pojemności dyski talerzowe poszły w odstawkę. Jeżeli chodzi o ich osiągi to ich współczesny limit to koło 150MB/s  największe komercyjne produkty to koło 20TB

Dyski SSD

Dyski SSD są znacząco szybsze od dysków talerzowych zwłaszcza jeżeli chodzi o losowy dostęp do różnych danych. Tak jak w operacjach liniowych odczytu dużej ilości ciągłych danych dyski talerzowe jeszcze jakoś dają radę tak w wypadku odczytów drobnych ilości losowych danych bezwładność mechaniki dysków talerzowych znacząco obniża wydajność dysku talerzowego. Obecnie pojemności i ceny dysków SSD sprawiają, że do zastosowań codziennych jak desktopy czy laptopy są one zdecydowanie pierwszym wyborem. Odnośnie osiągów współczesnych SSD to możemy mówić nawet o 7000MB/s a pojemności to 8TB

Interfejsy nośników danych

Jak już mamy gdzie podłączyć nasze dyski, wiemy już jakie dyski to teraz pozostaje kwestia jak czyli jakie mamy do dyspozycji interfejsy dysków bo zaraz się okaże jak mają duże znaczenie.

SATA

Zacznijmy od SATA (od ang. Serial Advanced Technology Attachment) popularny i chyba aktualnie najstarszy z używanych Tak jak w wypadku dysków talerzowych limit SATA na poziomie 600MB/s jest wystarczający tak w wypadku dysków SSD z przepustowościami sprzętu 7000MB/s stanowi on już wąskie gardło.

SAS

Następnym interfejsem używanym jeszcze w macierzach dyskowych jest SAS (Serial Attached SCSI) do momentu rozpowszechnienia się dysków SSD były on liderem na rynku wysoko wydajnych serwerowych magazynów danych. Jest szybszy on dysków SATA chociażby ze względu na prędkości obrotowe talerzy rzędu 15k w porównaniu do 5,4k lub 7,2k dla SATA. Jednak to umierająca technologia.

Nearline SAS NL-SAS – Multipath

Jest jednak wyjątek. Nearline SAS jest raczej nieznanym rozwiązaniem poza światem macierzy dyskowych. Jest rozwiązaniem pośrednim pomiędzy SATA i SAS. Ma on przepustowość, pojemność i konstrukcję dysków SATA czyli prędkość obrotową 7.2k, duże pojemności, to sprawia, że cena nie jest już wyrażenie większa jak w wypadku SAS. Po co więc? Zapytacie. Bo przecież tańszy od SATA na będzie. A no nie będzie ale z rozwiązań SAS ma zapożyczony kontroler i komunikację. I na cóż kombinować jak to ani szybsze ani tańsze? Zapytacie.

A no po pierwsze ma lepiej rozbudowaną komunikacje a błędach i predykcję usterek i wydajniejszy interface no ale uznajmy to jako trochę bla bla bla. Najciekawszy smaczek to obsługa Multipath. Pozwala on na kontrolę  tego samego dysku z dwóch rożnych kontrolerów. Nie a tej samej chwili oczywiście. Chodzi o możliwość zastosowanie architektury wysokiej dostępności. tzw high-availability. Pozwala na pełną redundancję. Macierze TrueNAS serii X i M mają możliwość redundantnego kontrolera wykorzystując właśnie funkcjonalność Mutipath. W efekcie zepsuć się może wszystko procesor RAM, zasilacz, nawet kontroler dysków a i tak rezerwowy kontroler będzie w stanie działać dalej na dokładnie  tych samych dyskach.

M.2

Następnym współcześnie często wykorzystywanym interfejsem jest M.2. To te płaskie pamięci przypominające trochę kości RAM. Obecnie podłącza się je albo bezpośrednio przez dedykowane porty na płycie głównej. Nie wszystkie płyty główne je mają albo prosto w płytę główne w port PCIe przez odpowiednią przejściówkę. Ewentualnie przez adapter w port zwykłego syku SATA.

M.2 SATA

JOdmiana M.2 SATA występuje rzadziej. M.2 SATA niewiele w wnosi do sprawy bo mimo, że jest dyskiem SSD to wykorzystuje  komunikację SATA więc nadal występuje limit 600MB/s jest szału nie robi. Wspominam głównie po to żeby się nie nadziać przy zakupie.

M.2 NVMe – PCIe

Jednak już wersja M.2 NVMe to zupełnie inna sprawa. To absolutny gamechanger. Podłączony prosto do magistrali PCIe powala otworzyć skrzydła technologii SSD. W zależności od wersji PCIe daje przepustowości rzędu kilku GB/s. Co ciekawe te dyski mimo, że znacznie szybsze nie są droższe niż dyski SSD a interfiksacjami SATA. Uwaga techniczna na sierpień 2023 TrueNAS jeszcze nie obsługuje S.M.A.R.T. dla dysków NVMe. Druga uwaga to, że nie wszystkie płyty obsługują uruchamianie z dysków NVMe, zwłaszcza starsze serwerowe, więc jak byście planowali użyć małego NVMe na system, co jest świetnym pomysłem, to sprawdźcie najpierw czy płyta potrafi się obudzić z takiego dysku.

U.3

Na horyzoncie widać już pierwsze dyski z interfejsami U.3 które powinny pozwalać wykorzystać pełne możliwości SSD Przez złącza wyglądające ja SATA i co ważniejsze wstecznie kompatybilne. Ale nie mieliśmy jeszcze z nimi do czynienia i zobaczymy jak się to potoczy.

Jakie dyski do NAS?

Odnośnie już konkretnych dysków jaki zalecał bym do stosowania w serwerach plików to zawsze celujcie w serie przeznaczone do NAS. Czy to będą Segate Ironwolf, Ironerolf Pro, WD RED czy WD-RED PRO jest już nieco mniej ważne niż fakt, że będzie to seria do NAS.
Tak informacyjnie WD-RED od wersji pro różni się tym, że jest w technologii SMR między innymi więc nieco wolniejszej.

Jedno czego nie róbcie to nie wkładajcie do swoich NAS dysków z serii konsumenckich. Znane są przypadki, że już pociągniemy tej samej marki, dyski WD BLUE po kilku miesiącach pracy w NAS padały jak muchy, jeden po drugim.

Dyski zalecane przez TrueNAS

Odnosząc się do zaleceń samego TrueNAS to zaleca on dyski z serii WD-RED pro. Wyjątkiem jest seria produktów X i M ze względu architekturę wysokiej dostępności  jest konieczność zastosowania dysków NL-SAS zaleca się serię WD UltraStar

Ostatnio zrobiła się mała awanturka ponieważ zdarzyło się już kilka nagłośnionych przypadków, że dyski WD po trzech latach użytkowania zaczęły zgłaszać ostrzeżenie informujące, że dysk ma już 3 lata i rekomendujące wymiany. Przyznam, że to dość dziwne ponieważ dyski  WD RED są właśnie dyskami do ciągłego obciążenia. I nawet po 6 latach awarie takiego dysku uznał bym bardziej za wyjątek niż normę.

Nawiasem mówiąc dyski WD-red pro są również polecane przez firmy takie jak Synology.

vDev

Przechodząc już do organizacji fizycznych dysków w ZFS wspomnę tylko, że podstawową jednostką organizacyjną w ZFS jest vDev. Każdy vDev może się składać jednego lub więcej dysków.  Co bardzo ważne niezawodność zapewniamy na bazie vDev więc to w nich właśnie dyski łączymy w Mirror czy RAZD-Z ale o tym później.

Jak wspomniałem na początku w ZFS dysk może pełnić jedną z pięciu ról(vDev) poza oczywiście samym przechowywaniem danych.
Dużo bardziej szczegółowo funkcjonowanie vDev omawiam filmie [TrueNAS – ZFS dlaczego jest zajefajny]. Tutaj chciałem się skupić już na praktycznym doborze dysków dla konkretnych vDev. Rzadko kiedy ma sens używać ich wszystkich.  Często nawet nie ma sensu używać ich wcale. Ale po kolei.

Dyski do vDev Data

To vDev Data przechowuje dane na przykład w którymś z RAID-Z.

W przybliżeniu pojemność takiego vDev to ilość dysków minus ilość dysków parzystości (RAID-z1 (1). RAID-z2 (2), RAID-z3 (3)) pomnożona przez wielkość dysków. To w zasadzie nic nieodzwyczajenie ale pamiętajcie, że jeżeli planujecie potem rozszerzać swój pool o następny vDev  z danymi to musi być on tak samo zorganizowany. Jeżeli macie już w poolu vDev zorganizowany w RAID-Z3 to następny vDev zaleca się żeby był tej samej wielkości ale na pewno musi być  zorganizowany też w RAID-Z3.

Pool możemy prawie bez ograniczeń rozszerzać o następne identyczne  vDev co będzie tylko przyspieszało nasz pool. Raz podłączony vDev z danymi nie możemy praktycznie już odłączać od pool.

Dyski do Hot Spare

Poza nadmiarowością wynikającą z RAID-Z Warto też mieć dyski zapasowe czyli Hot Spare. W wypadku awarii jednego z dysków automatycznie zastępują one uszkodzony dysk i macierz jest odbudowywana bez niczyjej interwencji. Co oczywiste w tym wypadku, że dyski muszą być więc identyczne jak te tworzące vDev Data.

Dyski do vDev Cache

vDev cache (L2ARC) jest rozszerzeniem pamięci cache w RAM wszystko co przestaje się mieścić w RAM a pozostaje przydatne zostaje wysłane do L2ARC i stamtąd pobierane w razie potrzeby. Oczywiście takie rozwiązanie ma sens tylko wtedy jeżeli dysk L2ARC jest szybszy niż same dyski z danymi. Jeżeli mamy macierz dyskową złożoną z dysków SSD to zastosowanie dysków L2ARC spowolni nam osiągi macierzy.

Z kolei zastosowanie za dużego dysku L2ARC też nie jest dobrym pomysłem ponieważ każdy blok danych na dysku L2ARC posiada swój 88 bajtowy adres w pamięci RAM. Wiec dla przykładu Jeżeli podłączymy 480GB dysk L2ARC wypełniony blokami danych po 4KB

to zapchamy sobie 10GB RAM tylko na adresy w L2ARC.

Zaleca się więc, żeby L2ARC był 5 do 20 razy wielkości naszego RAM

Dyski nie muszą być w żadne sposób redundantne ponieważ dane są wtórne istnieją tak czy inaczej w oryginale a po każdym restarcie tez zasób danych i tak jest budowany od nowa. Dyski można podłączać i odłączać na żywo bez konsekwencji.

Dyski do vDev SLOG (separate intent log)

Następnym ciekawym vDevem w ZFS jest SLOG. Jest on wykorzystywany jeżeli wykorzystujemy zapis synchroniczny, czyli żądamy od serwera potwierdzenia zapisu danych po tym jak faktycznie będą one zapisane nieulotnie. Tu wkracza szczypta teorii. ZFS ze względów optymalizacji zapisuje na dyski dane uporządkowanymi partiami co 5 sekund. Między przybyciem danych za zapisem dane znajdują się w RAM. Niespodziewany restart serwera doprowadzi do utraty danych nie zapisanych na dyski. Jeśli zaczniemy używać trybu synchronicznego, czyli gwarantującego zapis, ZFS zacznie zapisywać te dane na bieżąco, między partiami zapisu. Szkopuł tylko w tym o, że te tymczasowe dane będzie zapisywał  w ZIL (ZFS intent log) który to jest domyślnie na tym samym dysku co dane. W efekcie praktycznie będziemy te same dane dwukrotnie zapisywać na nasz pool. Co może dociążyć lub przeciążyć nasz serwer. I tu właśnie cały na biało wkracza SLOG. Jest on osobnym vDevem przeznaczonym na zapisywanie danych ZIL.

SLOG ma więc sens tylko jeżeli używamy operacji synchronicznych. A powinniśmy ich używać do wszystkich ważnych danych.

Wielkość SLOG może być zaskakująca ale w praktyce musi on pomieścić tylko tyle danych ile może trafić do serwera w pięć sekund. Nawet mając już naprawdę dużą macierz talerzową potrafiącą przyjąć zapełniając po brzegi łącze 10Gb, czyli jakieś 1,25GB/s. To maksymalna ilość danych mogąca trafić na SLOG w pięć sekund to 6,25GB danych. Biorąc to pod uwagę 16GB, tak 16 GB to zalecana wielkość dla większości konfiguracji.

Wykorzystanie większej pojemności może ewentualnie przedłużyć żywotność takiego dysku. Pamiętajmy, że na ten dysk będą zapisywane wszystkie dane zapisywane z trybie synchronicznym prze zapisem na właściwe dyski.

SLOG może nie mieć sensu jeżeli macierz podstawowa składa się z dysków SSD lub NVMe. Mógł by się okazać wąskim gardłem.
SLOG może być dowolnie dodawany i odejmowany w trakcie działania systemu.

Dyski do vDev Metadata

Następnym sposobem na przyspieszenie naszej talerzowej macierzy jest zastosowanie vDeva Metadata. Oczywiście przy użyciu technologii SSD. Inne nazwy tego samego rozwiązania to Fusion Pools czy ZFS allocation classes ale to to samo. Po podłączeniu go na naszego poola będzie od przechowywał metadane, czyli na przykład informacje o położeniu danych na dyskach.

To rozwiązanie sprawdzi się, jeśli nasz pool na macierzy obciążany jest dużą ilością przypadkowych małych odczytów. W losowych operacjach dostępu do małych danych może odciążyć dyski nawet po połowę. Co ostatecznie znacząco przyspiesza takie operacje.

Ważna uwaga, raz dodany vDev Metadata nie może już być odjęty bo przechowuje on integralną część danych. Co za tym idzie taki vDev koniecznie musi mieć redundancję ponieważ jeżeli go stracimy to stracimy też dane. Jeżeli podłączymy więcej niż jedne vDev Metedata ZFS będzie się starł równoważyć obciążenie między nie. Jeśli zabraknie na nich miejsca zacznie znów pisać na podstawowych dyskach poola.

Dyski na vDev dedup

Jeżeli zaś dojdziemy do wniosku, że mamy dużo powtarzających się danych i będziemy potrzebowali użyć de duplikacji to metadane de duplikacji będę domyślnie na tych samych dyskach co dane. To może przeciążyć nasze dyski. W takim wypadku podłączmy vDev Dedup. Każda blok danych przychodzący będzie sprawdzany pod kątem podobieństwa do wszystkich już zaspanych na naszych dyskach. To bardzo obciążające. Żeby rozwiązanie miało sens zaleca się najszybsze możliwe dyski NVMe.

Raz podłączonego vDev dedup nie można odłączyć ponieważ zawiera on sumy kontrolne bloków danych i ich adresy. Co za tym idzie po stracie vDeva dedup tracimy nasze dane. Koniecznym jest również zachowanie redundancji.

Rozmiar takiego vDev szacuje się na 1 GB na każde 1TB danych poddanych de duplikacji.

Dyski na system

Każdy serwer NAS poza dyskami na dane i innymi wspomagającymi, o których się już tutaj naopowiadałem, musi mieć też dyski na system operacyjny. Tutaj nie ma większych wymagań odnośnie wielkości czy szybkości ponieważ na dych dyskach przechowywana jest tylko konfiguracja i trochę logów. Żadnych naszych danych. W praktyce dyski wielkości 16 GB w większości wypadków są wystarczające.

Ze względu na koniczną redundancję optymalnym rozwiązaniem są dwa minimalne dysku SSD czyli pewnie 256GB czy już nawet 500GB. W praktyce Odradza się dyski talerzowe i dysku USB.

Choć jako ciekawostka powiem, że jeden z naszych TrueNAS z małym poolem kilkanaście TB przerzucający dziennie setki GB działa sobie na dwóch 16GB dyskach USB. Absolutnie nie jest to nic co bym polecał na rozwiązanie produkcyjne ale w zupełności spełnia rolę jako mały podręczny, nie krytyczny magazyn danych. No i używając USB zostaje więcej miejsca na dyski z danymi.

linki

https://www.truenas.com/docs/core/gettingstarted/corehardwareguide/#minimum-hardware-requirements

https://www.truenas.com/docs/core/coretutorials/storage/pools/poolcreate/#vdev-layout

Jeśli chcielibyście dowiedzieć się więcej o TrueNAS napiszcie do nas. Opowiemy Wam jak działa i dlaczego warto?