{"id":836,"date":"2023-08-22T19:02:52","date_gmt":"2023-08-22T17:02:52","guid":{"rendered":"https:\/\/eonea.pl\/?p=836"},"modified":"2024-04-05T10:57:13","modified_gmt":"2024-04-05T08:57:13","slug":"truenas-zfs-praktyczny-dobor-dyskow","status":"publish","type":"post","link":"https:\/\/eonea.pl\/en\/truenas-zfs-praktyczny-dobor-dyskow\/","title":{"rendered":"TrueNAS ZFS - practical drive selection"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Cz\u0119sto padaj\u0105 pytania w rodzaju: \u201emam osiem dysk\u00f3w jaki RAID najlepiej u\u017cy\u0107?\u201d albo \u201ejaka konfiguracja RAID-Z jest najlepsza\u201d. Cz\u0119sto te\u017c zdarzaj\u0105 si\u0119 sytuacje, \u017ce klient kupi\u0142 sobie serwer na NAS i prosi o skonfigurowanie na nim TrueNAS bo jest fajny. Oczywi\u015bcie nie ma problemu te\u017c uwa\u017cam, \u017ce jest fajny, ch\u0119tnie je konfigurujemy i wpieramy.<\/p>

\u00a0<\/p>

Tylko, \u017ce cz\u0119sto s\u0105 to serwery dobierane, c\u00f3\u017c, nie koniecznie optymalnie. Je\u017celi decydujemy si\u0119 na prosty dysk sieciowy jak na przyk\u0142ad niewielki QNAP czy Synology i jego wydajno\u015b\u0107 nie jest kluczowa to wtedy tak.\u00a0 Mno\u017cymy pojemno\u015b\u0107 dysku razy ilo\u015b\u0107 dysk\u00f3w potem odejmujemy jeden, ten zapasowy, i mamy pojemno\u015b\u0107 macierzy. Koniec oblicze\u0144, nic prostszego.<\/p>

\u00a0<\/p>

Tylko, \u017ce planuj\u0105c serwer plik\u00f3w oparty na ZFS jakim jest TrueNAS robi si\u0119 to troch\u0119 bardziej skomplikowane. A je\u017celi dodatkowo mamy w planach intensywnie korzysta\u0107 z naszego serwera bo planujemy na nim trzyma\u0107 dyski witalnych maszyn albo bazy danych albo monta\u017c i edycj\u0119 materia\u0142\u00f3w video to sprawa si\u0119 komplikuje bardziej.<\/p>

\u00a0<\/p>

Jasne mo\u017cemy kupi\u0107 macierz ALL-flash wpakowa\u0107 w ni\u0105 najszybsze dyski NVMe, kup\u0119 RAM jaki\u015b niezgorszy procesor i b\u0119dzie dzia\u0142a\u0142o jak trzeba. Co wi\u0119cej czasem olbrzymie wymagania sprawiaj\u0105, \u017ce nie ma innego wyj\u015bcia. Tylko, \u017ce je\u017celi dodatkowo potrzebujemy, \u017ceby nasza macierz mia\u0142a pojemno\u015b\u0107 dziesi\u0105tek czy setek TB to takie rozwi\u0105zanie b\u0119dzie kosztowa\u0142o kilka work\u00f3w pieni\u0119dzy.<\/p>

\u00a0<\/p>

Ale je\u017celi wpadniecie na pomys\u0142 zastosowania rozwi\u0105zanie tzw Hybrydowego czyli dyski talerzowe uzupe\u0142niane dyskami SSD i chcecie to zrobi\u0107 optymalnie a co za tym idzie wyda\u0107 mniej work\u00f3w pieni\u0119dzy wykorzystuj\u0105c zalety ZFS. To wtedy dob\u00f3r i konfiguracja dysk\u00f3w mo\u017ce si\u0119 zrobi\u0107 skomplikowany i odpowied\u017a na pytanie \u201eJakie dyski potrzebuje do mojego NAS?\u201d wybrzmi, kto by si\u0119 spodziewa\u0142 uwaga: \u201eto zale\u017cy\u201d<\/p>

\u00a0<\/p>

Chcia\u0142em jeszcze zwr\u00f3ci\u0107 uwag\u0119, \u017ceby nie przywi\u0105zywa\u0107 si\u0119 jako\u015b szczeg\u00f3lnie to konkretnych liczb bo cz\u0119\u015b\u0107 z nich zmienia si\u0119 zale\u017cnie od modeli i czasu. Chodzi bardziej o rz\u0119dy wielko\u015bci i por\u00f3wnanie. Podane parametry s\u0105 mniej wi\u0119cej aktualne na sierpie\u0144 2023. Bardziej chcia\u0142 skupi\u0107 si\u0119 na przekazaniu r\u00f3\u017cnic i mechanizm\u00f3w wyboru ni\u017c konkretnych liczb.<\/p>

\u00a0<\/h4>

Sterownik dysk\u00f3w z HBA dla TrueNAS (ZFS)<\/strong><\/p>

Zaczynaj\u0105c od podstaw zanim zaczniemy pod\u0142\u0105cza\u0107 dyski musimy mie\u0107 do czego.
Wi\u0119kszo\u015b\u0107 serwer\u00f3w jest domy\u015blnie wyposa\u017cana w sprz\u0119towe rozwi\u0105zania RAID. No i to jest spoko. Spoko do momentu kiedy chcemy korzysta\u0107 z ZFS. ZFS potrzebuje komunikowa\u0107 si\u0119 bezpo\u015brednio z dyskiem dlatego potrzebujemy albo wbudowanego w p\u0142yt\u0119 kontrolera dysk\u00f3w albo kontroler\u00f3w do dysk\u00f3w z funkcj\u0105 HBA (host bus adapter). Je\u017celi pod\u0142\u0105czymy dyski przez kontroler pe\u0142ni\u0105cy funkcj\u0119 sprz\u0119towego RAID to:<\/p>

  • niepotrzebnie dublujemy funkcjonalno\u015b\u0107 RAID (ZFS da rad\u0119)<\/li>
  • utrudniamy\/uniemo\u017cliwiamy dost\u0119p do S.M.A.R.T. (ang. Self-Monitoring, Analysis and Reporting Technology) czyli mechanizmu dostarczaj\u0105cemu systemowi informacji o stanie dysku, usterkach a nawet przewidywanych usterkach zanim do nich dojdzie, to wa\u017cne informacje. S.M.A.R.T. daje r\u00f3wnie\u017c mo\u017cliwo\u015b\u0107 odczytania\u00a0 numeru seryjnego a ZFS rozpoznaje dyski w\u0142a\u015bnie po numerze seryjnym.<\/li>
  • utrudniamy sobie wymian\u0119 dysku poniewa\u017c w wypadku HBA wy\u0142\u0105czmy serwer (albo i nie) zmieniamy dysk i reszt\u0119 konfigurujemy przez stron\u0119 administracyjn\u0105 TrueNAS . Je\u015bli mamy po drodze jaki\u015b kontroler RAID to musimy konfigurowa\u0107 wymian\u0119 dysku ju\u017c nie tylko w TrueNAS ale i w kontrolerze RAID i to cz\u0119sto przy wy\u0142\u0105czonym serwerze przez jakie\u015b menu dost\u0119pne przy uruchamianiu serwera.<\/li>
  • kontrolery sprz\u0119towe s\u0105 szybsze w opcji HBA ni\u017c w funkcji RAID, maj\u0105 mnie pracy<\/li>
  • je\u015bli kontroler dysk\u00f3w u\u017cywa wbudowanego cache a z jakich powod\u00f3w nie zorientujemy si\u0119, \u017ce baterie w tym cache si\u0119 ko\u0144czy\u0142y to ryzykujemy utrat\u0119 danych w razie awarii zasilania.<\/li><\/ul>

    \u00a0<\/p>

    Rodzaje no\u015bnik\u00f3w danych<\/strong><\/p>

    Je\u017celi chodzi o same no\u015bniki danych nazywane przez zasz\u0142o\u015bci technologiczne \u201edyskami\u201d w rzeczywisto\u015bci ju\u017c przecie\u017c najcz\u0119\u015bciej dyskami nie s\u0105. Dodatkowo okre\u015blenie \u201edyski twardy\u201d w odr\u00f3\u017cnieniu do mi\u0119kkich niegdy\u015b dyskietek, wydaje si\u0119 by\u0107 ju\u017c jednak skrajnie nieadekwatne. Ale trzymaj\u0105c si\u0119 jednak tej nomenklatury dyski co za pewne wiecie dzieli na talerzowe gdzie dane przechowywane s\u0105 w\u0142a\u015bnie na kr\u0119c\u0105cych si\u0119 talerzach magnetycznych potocznie HDD i dyski p\u00f3\u0142przewodnikowe tzw SSD.<\/p>

    \u00a0<\/p>

    Dyski HDD\u00a0 <\/strong><\/p>

    Dyski HDD charakteryzuj\u0105 si\u0119 dobrym stosunkiem pojemno\u015bci do ceny. Na chwil\u0119 obecn\u0105 nic nie zapowiada, \u017ceby w \u015bwiecie macierzy dyskowych nastawionych na du\u017ce czy ogromne pojemno\u015bci dyski talerzowe posz\u0142y w odstawk\u0119. Je\u017celi chodzi o ich osi\u0105gi to ich wsp\u00f3\u0142czesny limit to ko\u0142o 150MB\/s\u00a0 najwi\u0119ksze komercyjne produkty to ko\u0142o 20TB<\/p>

    \u00a0<\/h4>

    Dyski SSD<\/strong><\/p>

    \"\" \"\"<\/p>

    Dyski SSD s\u0105 znacz\u0105co szybsze od dysk\u00f3w talerzowych zw\u0142aszcza je\u017celi chodzi o losowy dost\u0119p do r\u00f3\u017cnych danych. Tak jak w operacjach liniowych odczytu du\u017cej ilo\u015bci ci\u0105g\u0142ych danych dyski talerzowe jeszcze jako\u015b daj\u0105 rad\u0119 tak w wypadku odczyt\u00f3w drobnych ilo\u015bci losowych danych bezw\u0142adno\u015b\u0107 mechaniki dysk\u00f3w talerzowych znacz\u0105co obni\u017ca wydajno\u015b\u0107 dysku talerzowego. Obecnie pojemno\u015bci i ceny dysk\u00f3w SSD sprawiaj\u0105, \u017ce do zastosowa\u0144 codziennych jak desktopy czy laptopy s\u0105 one zdecydowanie pierwszym wyborem. Odno\u015bnie osi\u0105g\u00f3w wsp\u00f3\u0142czesnych SSD to mo\u017cemy m\u00f3wi\u0107 nawet o 7000MB\/s a pojemno\u015bci to 8TB<\/p>

    \u00a0<\/p>

    Interfejsy no\u015bnik\u00f3w danych<\/strong><\/p>

    Jak ju\u017c mamy gdzie pod\u0142\u0105czy\u0107 nasze dyski, wiemy ju\u017c jakie dyski to teraz pozostaje kwestia jak czyli jakie mamy do dyspozycji interfejsy dysk\u00f3w bo zaraz si\u0119 oka\u017ce jak maj\u0105 du\u017ce znaczenie.<\/p>

    \u00a0<\/p>

    SATA<\/strong><\/p>

    \"\"<\/p>

    Zacznijmy od SATA (od ang. Serial Advanced Technology Attachment) popularny i chyba aktualnie najstarszy z u\u017cywanych Tak jak w wypadku dysk\u00f3w talerzowych limit SATA na poziomie 600MB\/s jest wystarczaj\u0105cy tak w wypadku dysk\u00f3w SSD z przepustowo\u015bciami sprz\u0119tu 7000MB\/s stanowi on ju\u017c w\u0105skie gard\u0142o.<\/p>

    \u00a0<\/p>

    SAS<\/strong><\/p>

    \"\"<\/p>

    Nast\u0119pnym interfejsem u\u017cywanym jeszcze w macierzach dyskowych jest SAS (Serial Attached SCSI) do momentu rozpowszechnienia si\u0119 dysk\u00f3w SSD by\u0142y on liderem na rynku wysoko wydajnych serwerowych magazyn\u00f3w danych. Jest szybszy on dysk\u00f3w SATA chocia\u017cby ze wzgl\u0119du na pr\u0119dko\u015bci obrotowe talerzy rz\u0119du 15k w por\u00f3wnaniu do 5,4k lub 7,2k dla SATA. Jednak to umieraj\u0105ca technologia.<\/p>

    \u00a0<\/p>

    Nearline SAS NL-SAS \u2013 Multipath<\/strong><\/p>

    Jest jednak wyj\u0105tek. Nearline SAS jest raczej nieznanym rozwi\u0105zaniem poza \u015bwiatem macierzy dyskowych. Jest rozwi\u0105zaniem po\u015brednim pomi\u0119dzy SATA i SAS. Ma on przepustowo\u015b\u0107, pojemno\u015b\u0107 i konstrukcj\u0119 dysk\u00f3w SATA czyli pr\u0119dko\u015b\u0107 obrotow\u0105 7.2k, du\u017ce pojemno\u015bci, to sprawia, \u017ce cena nie jest ju\u017c wyra\u017cenie wi\u0119ksza jak w wypadku SAS. Po co wi\u0119c? Zapytacie. Bo przecie\u017c ta\u0144szy od SATA na b\u0119dzie. A no nie b\u0119dzie ale z rozwi\u0105za\u0144 SAS ma zapo\u017cyczony kontroler i komunikacj\u0119. I na c\u00f3\u017c kombinowa\u0107 jak to ani szybsze ani ta\u0144sze? Zapytacie.<\/p>

    \u00a0<\/p>

    A no po pierwsze ma lepiej rozbudowan\u0105 komunikacje a b\u0142\u0119dach i predykcj\u0119 usterek i wydajniejszy interface no ale uznajmy to jako troch\u0119 bla bla bla. Najciekawszy smaczek to obs\u0142uga Multipath. Pozwala on na kontrol\u0119\u00a0 tego samego dysku z dw\u00f3ch ro\u017cnych kontroler\u00f3w. Nie a tej samej chwili oczywi\u015bcie. Chodzi o mo\u017cliwo\u015b\u0107 zastosowanie architektury wysokiej dost\u0119pno\u015bci. tzw high-availability. Pozwala na pe\u0142n\u0105 redundancj\u0119. Macierze TrueNAS serii X i M maj\u0105 mo\u017cliwo\u015b\u0107 redundantnego kontrolera wykorzystuj\u0105c w\u0142a\u015bnie funkcjonalno\u015b\u0107 Mutipath. W efekcie zepsu\u0107 si\u0119 mo\u017ce wszystko procesor RAM, zasilacz, nawet kontroler dysk\u00f3w a i tak rezerwowy kontroler b\u0119dzie w stanie dzia\u0142a\u0107 dalej na dok\u0142adnie\u00a0 tych samych dyskach.<\/p>

    \u00a0<\/h4>

    M.2<\/strong><\/p>

    Nast\u0119pnym wsp\u00f3\u0142cze\u015bnie cz\u0119sto wykorzystywanym interfejsem jest M.2. To te p\u0142askie pami\u0119ci przypominaj\u0105ce troch\u0119 ko\u015bci RAM. Obecnie pod\u0142\u0105cza si\u0119 je albo bezpo\u015brednio przez dedykowane porty na p\u0142ycie g\u0142\u00f3wnej. Nie wszystkie p\u0142yty g\u0142\u00f3wne je maj\u0105 albo prosto w p\u0142yt\u0119 g\u0142\u00f3wne w port PCIe przez odpowiedni\u0105 przej\u015bci\u00f3wk\u0119. Ewentualnie przez adapter w port zwyk\u0142ego syku SATA.<\/p>

    \u00a0<\/p>

    M.2 SATA <\/strong><\/p>

    JOdmiana M.2 SATA wyst\u0119puje rzadziej. M.2 SATA niewiele w wnosi do sprawy bo mimo, \u017ce jest dyskiem SSD to wykorzystuje\u00a0 komunikacj\u0119 SATA wi\u0119c nadal wyst\u0119puje limit 600MB\/s jest sza\u0142u nie robi. Wspominam g\u0142\u00f3wnie po to \u017ceby si\u0119 nie nadzia\u0107 przy zakupie.<\/p>

    \u00a0<\/p>

    M.2 NVMe \u2013 PCIe<\/strong><\/p>

    Jednak ju\u017c wersja M.2 NVMe to zupe\u0142nie inna sprawa. To absolutny gamechanger. Pod\u0142\u0105czony prosto do magistrali PCIe powala otworzy\u0107 skrzyd\u0142a technologii SSD. W zale\u017cno\u015bci od wersji PCIe daje przepustowo\u015bci rz\u0119du kilku GB\/s. Co ciekawe te dyski mimo, \u017ce znacznie szybsze nie s\u0105 dro\u017csze ni\u017c dyski SSD a interfiksacjami SATA. Uwaga techniczna na sierpie\u0144 2023 TrueNAS jeszcze nie obs\u0142uguje S.M.A.R.T. dla dysk\u00f3w NVMe. Druga uwaga to, \u017ce nie wszystkie p\u0142yty obs\u0142uguj\u0105 uruchamianie z dysk\u00f3w NVMe, zw\u0142aszcza starsze serwerowe, wi\u0119c jak by\u015bcie planowali u\u017cy\u0107 ma\u0142ego NVMe na system, co jest \u015bwietnym pomys\u0142em, to sprawd\u017acie najpierw czy p\u0142yta potrafi si\u0119 obudzi\u0107 z takiego dysku.<\/p>

    \u00a0<\/p>

    U.3<\/strong><\/p>

    Na horyzoncie wida\u0107 ju\u017c pierwsze dyski z interfejsami U.3 kt\u00f3re powinny pozwala\u0107 wykorzysta\u0107 pe\u0142ne mo\u017cliwo\u015bci SSD Przez z\u0142\u0105cza wygl\u0105daj\u0105ce ja SATA i co wa\u017cniejsze wstecznie kompatybilne. Ale nie mieli\u015bmy jeszcze z nimi do czynienia i zobaczymy jak si\u0119 to potoczy.<\/p>

    \u00a0<\/p>

    Jakie dyski do NAS?<\/strong><\/p>

    Odno\u015bnie ju\u017c konkretnych dysk\u00f3w jaki zaleca\u0142 bym do stosowania w serwerach plik\u00f3w to zawsze celujcie w serie przeznaczone do NAS. Czy to b\u0119d\u0105 Segate Ironwolf, Ironerolf Pro, WD RED czy WD-RED PRO jest ju\u017c nieco mniej wa\u017cne ni\u017c fakt, \u017ce b\u0119dzie to seria do NAS.
    Tak informacyjnie WD-RED od wersji pro r\u00f3\u017cni si\u0119 tym, \u017ce jest w technologii SMR mi\u0119dzy innymi wi\u0119c nieco wolniejszej.<\/p>

    \u00a0<\/p>

    Jedno czego nie r\u00f3bcie to nie wk\u0142adajcie do swoich NAS dysk\u00f3w z serii konsumenckich. Znane s\u0105 przypadki, \u017ce ju\u017c poci\u0105gniemy tej samej marki, dyski WD BLUE po kilku miesi\u0105cach pracy w NAS pada\u0142y jak muchy, jeden po drugim.<\/p>

    \u00a0<\/p>

    Dyski zalecane przez TrueNAS<\/strong><\/p>

    Odnosz\u0105c si\u0119 do zalece\u0144 samego TrueNAS to zaleca on dyski z serii WD-RED pro. Wyj\u0105tkiem jest seria produkt\u00f3w X i M ze wzgl\u0119du architektur\u0119 wysokiej dost\u0119pno\u015bci\u00a0 jest konieczno\u015b\u0107 zastosowania dysk\u00f3w NL-SAS zaleca si\u0119 seri\u0119 WD UltraStar<\/p>

    \u00a0<\/p>

    Ostatnio zrobi\u0142a si\u0119 ma\u0142a awanturka poniewa\u017c zdarzy\u0142o si\u0119 ju\u017c kilka nag\u0142o\u015bnionych przypadk\u00f3w, \u017ce dyski WD po trzech latach u\u017cytkowania zacz\u0119\u0142y zg\u0142asza\u0107 ostrze\u017cenie informuj\u0105ce, \u017ce dysk ma ju\u017c 3 lata i rekomenduj\u0105ce wymiany. Przyznam, \u017ce to do\u015b\u0107 dziwne poniewa\u017c dyski\u00a0 WD RED s\u0105 w\u0142a\u015bnie dyskami do ci\u0105g\u0142ego obci\u0105\u017cenia. I nawet po 6 latach awarie takiego dysku uzna\u0142 bym bardziej za wyj\u0105tek ni\u017c norm\u0119.<\/p>

    \u00a0<\/p>

    Nawiasem m\u00f3wi\u0105c dyski WD-red pro s\u0105 r\u00f3wnie\u017c polecane przez firmy takie jak Synology.<\/p>

    \u00a0<\/p>

    vDev<\/strong><\/p>

    Przechodz\u0105c ju\u017c do organizacji fizycznych dysk\u00f3w w ZFS wspomn\u0119 tylko, \u017ce podstawow\u0105 jednostk\u0105 organizacyjn\u0105 w ZFS jest vDev. Ka\u017cdy vDev mo\u017ce si\u0119 sk\u0142ada\u0107 jednego lub wi\u0119cej dysk\u00f3w.\u00a0 Co bardzo wa\u017cne niezawodno\u015b\u0107 zapewniamy na bazie vDev wi\u0119c to w nich w\u0142a\u015bnie dyski \u0142\u0105czymy w Mirror czy RAZD-Z ale o tym p\u00f3\u017aniej.<\/p>

    \u00a0<\/p>

    Jak wspomnia\u0142em na pocz\u0105tku w ZFS dysk mo\u017ce pe\u0142ni\u0107 jedn\u0105 z pi\u0119ciu r\u00f3l(vDev) poza oczywi\u015bcie samym przechowywaniem danych.
    Du\u017co bardziej szczeg\u00f3\u0142owo funkcjonowanie vDev omawiam filmie [TrueNAS \u2013 ZFS dlaczego jest zajefajny]<\/strong>. Tutaj chcia\u0142em si\u0119 skupi\u0107 ju\u017c na praktycznym doborze dysk\u00f3w dla konkretnych vDev. Rzadko kiedy ma sens u\u017cywa\u0107 ich wszystkich.\u00a0 Cz\u0119sto nawet nie ma sensu u\u017cywa\u0107 ich wcale. Ale po kolei.<\/p>

    \u00a0<\/p>

    Dyski do vDev Data<\/strong><\/p>

    To vDev Data przechowuje dane na przyk\u0142ad w kt\u00f3rym\u015b z RAID-Z.<\/p>

    \u00a0<\/p>

    W przybli\u017ceniu pojemno\u015b\u0107 takiego vDev to ilo\u015b\u0107 dysk\u00f3w minus ilo\u015b\u0107 dysk\u00f3w parzysto\u015bci (RAID-z1 (1). RAID-z2 (2), RAID-z3 (3)) pomno\u017cona przez wielko\u015b\u0107 dysk\u00f3w. To w zasadzie nic nieodzwyczajenie ale pami\u0119tajcie, \u017ce je\u017celi planujecie potem rozszerza\u0107 sw\u00f3j pool o nast\u0119pny vDev\u00a0 z danymi to musi by\u0107 on tak samo zorganizowany. Je\u017celi macie ju\u017c w poolu vDev zorganizowany w RAID-Z3 to nast\u0119pny vDev zaleca si\u0119 \u017ceby by\u0142 tej samej wielko\u015bci ale na pewno musi by\u0107\u00a0 zorganizowany te\u017c w RAID-Z3.<\/p>

    \u00a0<\/p>

    Pool mo\u017cemy prawie bez ogranicze\u0144 rozszerza\u0107 o nast\u0119pne identyczne\u00a0 vDev co b\u0119dzie tylko przyspiesza\u0142o nasz pool. Raz pod\u0142\u0105czony vDev z danymi nie mo\u017cemy praktycznie ju\u017c od\u0142\u0105cza\u0107 od pool.<\/p>

    \u00a0<\/p>

    Dyski do Hot Spare<\/strong><\/p>

    Poza nadmiarowo\u015bci\u0105 wynikaj\u0105c\u0105 z RAID-Z Warto te\u017c mie\u0107 dyski zapasowe czyli Hot Spare. W wypadku awarii jednego z dysk\u00f3w automatycznie zast\u0119puj\u0105 one uszkodzony dysk i macierz jest odbudowywana bez niczyjej interwencji. Co oczywiste w tym wypadku, \u017ce dyski musz\u0105 by\u0107 wi\u0119c identyczne jak te tworz\u0105ce vDev Data.<\/p>

    \u00a0<\/p>

    Dyski do vDev Cache<\/strong><\/p>

    vDev cache (L2ARC) jest rozszerzeniem pami\u0119ci cache w RAM wszystko co przestaje si\u0119 mie\u015bci\u0107 w RAM a pozostaje przydatne zostaje wys\u0142ane do L2ARC i stamt\u0105d pobierane w razie potrzeby. Oczywi\u015bcie takie rozwi\u0105zanie ma sens tylko wtedy je\u017celi dysk L2ARC jest szybszy ni\u017c same dyski z danymi. Je\u017celi mamy macierz dyskow\u0105 z\u0142o\u017con\u0105 z dysk\u00f3w SSD to zastosowanie dysk\u00f3w L2ARC spowolni nam osi\u0105gi macierzy.<\/p>

    \u00a0<\/p>

    Z kolei zastosowanie za du\u017cego dysku L2ARC te\u017c nie jest dobrym pomys\u0142em poniewa\u017c ka\u017cdy blok danych na dysku L2ARC posiada sw\u00f3j 88 bajtowy adres w pami\u0119ci RAM. Wiec dla przyk\u0142adu Je\u017celi pod\u0142\u0105czymy 480GB dysk L2ARC wype\u0142niony blokami danych po 4KB<\/p>

    \u00a0<\/p>

    to zapchamy sobie 10GB RAM tylko na adresy w L2ARC.<\/p>

    \u00a0<\/p>

    Zaleca si\u0119 wi\u0119c, \u017ceby L2ARC by\u0142 5 do 20 razy wielko\u015bci naszego RAM<\/p>

    \u00a0<\/p>

    Dyski nie musz\u0105 by\u0107 w \u017cadne spos\u00f3b redundantne poniewa\u017c dane s\u0105 wt\u00f3rne istniej\u0105 tak czy inaczej w oryginale a po ka\u017cdym restarcie tez zas\u00f3b danych i tak jest budowany od nowa. Dyski mo\u017cna pod\u0142\u0105cza\u0107 i od\u0142\u0105cza\u0107 na \u017cywo bez konsekwencji.<\/p>

    \u00a0<\/p>

    Dyski do vDev SLOG (separate intent log)<\/strong><\/p>

    Nast\u0119pnym ciekawym vDevem w ZFS jest SLOG. Jest on wykorzystywany je\u017celi wykorzystujemy zapis synchroniczny, czyli \u017c\u0105damy od serwera potwierdzenia zapisu danych po tym jak faktycznie b\u0119d\u0105 one zapisane nieulotnie. Tu wkracza szczypta teorii. ZFS ze wzgl\u0119d\u00f3w optymalizacji zapisuje na dyski dane uporz\u0105dkowanymi partiami co 5 sekund. Mi\u0119dzy przybyciem danych za zapisem dane znajduj\u0105 si\u0119 w RAM. Niespodziewany restart serwera doprowadzi do utraty danych nie zapisanych na dyski. Je\u015bli zaczniemy u\u017cywa\u0107 trybu synchronicznego, czyli gwarantuj\u0105cego zapis, ZFS zacznie zapisywa\u0107 te dane na bie\u017c\u0105co, mi\u0119dzy partiami zapisu. Szkopu\u0142 tylko w tym o, \u017ce te tymczasowe dane b\u0119dzie zapisywa\u0142\u00a0 w ZIL (ZFS intent log) kt\u00f3ry to jest domy\u015blnie na tym samym dysku co dane. W efekcie praktycznie b\u0119dziemy te same dane dwukrotnie zapisywa\u0107 na nasz pool. Co mo\u017ce doci\u0105\u017cy\u0107 lub przeci\u0105\u017cy\u0107 nasz serwer. I tu w\u0142a\u015bnie ca\u0142y na bia\u0142o wkracza SLOG. Jest on osobnym vDevem przeznaczonym na zapisywanie danych ZIL.<\/p>

    \u00a0<\/p>

    SLOG ma wi\u0119c sens tylko je\u017celi u\u017cywamy operacji synchronicznych. A powinni\u015bmy ich u\u017cywa\u0107 do wszystkich wa\u017cnych danych.<\/p>

    \u00a0<\/p>

    Wielko\u015b\u0107 SLOG mo\u017ce by\u0107 zaskakuj\u0105ca ale w praktyce musi on pomie\u015bci\u0107 tylko tyle danych ile mo\u017ce trafi\u0107 do serwera w pi\u0119\u0107 sekund. Nawet maj\u0105c ju\u017c naprawd\u0119 du\u017c\u0105 macierz talerzow\u0105 potrafi\u0105c\u0105 przyj\u0105\u0107 zape\u0142niaj\u0105c po brzegi \u0142\u0105cze 10Gb, czyli jakie\u015b 1,25GB\/s. To maksymalna ilo\u015b\u0107 danych mog\u0105ca trafi\u0107 na SLOG w pi\u0119\u0107 sekund to 6,25GB danych. Bior\u0105c to pod uwag\u0119 16GB, tak 16 GB to zalecana wielko\u015b\u0107 dla wi\u0119kszo\u015bci konfiguracji.<\/p>

    \u00a0<\/p>

    Wykorzystanie wi\u0119kszej pojemno\u015bci mo\u017ce ewentualnie przed\u0142u\u017cy\u0107 \u017cywotno\u015b\u0107 takiego dysku. Pami\u0119tajmy, \u017ce na ten dysk b\u0119d\u0105 zapisywane wszystkie dane zapisywane z trybie synchronicznym prze zapisem na w\u0142a\u015bciwe dyski.<\/p>

    \u00a0<\/p>

    SLOG mo\u017ce nie mie\u0107 sensu je\u017celi macierz podstawowa sk\u0142ada si\u0119 z dysk\u00f3w SSD lub NVMe. M\u00f3g\u0142 by si\u0119 okaza\u0107 w\u0105skim gard\u0142em.
    SLOG mo\u017ce by\u0107 dowolnie dodawany i odejmowany w trakcie dzia\u0142ania systemu.<\/p>

    \u00a0<\/p>

    Dyski do vDev Metadata<\/strong><\/p>

    Nast\u0119pnym sposobem na przyspieszenie naszej talerzowej macierzy jest zastosowanie vDeva Metadata. Oczywi\u015bcie przy u\u017cyciu technologii SSD. Inne nazwy tego samego rozwi\u0105zania to Fusion Pools czy ZFS allocation classes ale to to samo. Po pod\u0142\u0105czeniu go na naszego poola b\u0119dzie od przechowywa\u0142 metadane, czyli na przyk\u0142ad informacje o po\u0142o\u017ceniu danych na dyskach.<\/p>

    \u00a0<\/p>

    To rozwi\u0105zanie sprawdzi si\u0119, je\u015bli nasz pool na macierzy obci\u0105\u017cany jest du\u017c\u0105 ilo\u015bci\u0105 przypadkowych ma\u0142ych odczyt\u00f3w. W losowych operacjach dost\u0119pu do ma\u0142ych danych mo\u017ce odci\u0105\u017cy\u0107 dyski nawet po po\u0142ow\u0119. Co ostatecznie znacz\u0105co przyspiesza takie operacje.<\/p>

    \u00a0<\/p>

    Wa\u017cna uwaga, raz dodany vDev Metadata nie mo\u017ce ju\u017c by\u0107 odj\u0119ty bo przechowuje on integraln\u0105 cz\u0119\u015b\u0107 danych. Co za tym idzie taki vDev koniecznie musi mie\u0107 redundancj\u0119 poniewa\u017c je\u017celi go stracimy to stracimy te\u017c dane. Je\u017celi pod\u0142\u0105czymy wi\u0119cej ni\u017c jedne vDev Metedata ZFS b\u0119dzie si\u0119 star\u0142 r\u00f3wnowa\u017cy\u0107 obci\u0105\u017cenie mi\u0119dzy nie. Je\u015bli zabraknie na nich miejsca zacznie zn\u00f3w pisa\u0107 na podstawowych dyskach poola.<\/p>

    \u00a0<\/p>

    Dyski na vDev dedup<\/strong><\/p>

    Je\u017celi za\u015b dojdziemy do wniosku, \u017ce mamy du\u017co powtarzaj\u0105cych si\u0119 danych i b\u0119dziemy potrzebowali u\u017cy\u0107 de duplikacji to metadane de duplikacji b\u0119d\u0119 domy\u015blnie na tych samych dyskach co dane. To mo\u017ce przeci\u0105\u017cy\u0107 nasze dyski. W takim wypadku pod\u0142\u0105czmy vDev Dedup. Ka\u017cda blok danych przychodz\u0105cy b\u0119dzie sprawdzany pod k\u0105tem podobie\u0144stwa do wszystkich ju\u017c zaspanych na naszych dyskach. To bardzo obci\u0105\u017caj\u0105ce. \u017beby rozwi\u0105zanie mia\u0142o sens zaleca si\u0119 najszybsze mo\u017cliwe dyski NVMe.<\/p>

    \u00a0<\/p>

    Raz pod\u0142\u0105czonego vDev dedup nie mo\u017cna od\u0142\u0105czy\u0107 poniewa\u017c zawiera on sumy kontrolne blok\u00f3w danych i ich adresy. Co za tym idzie po stracie vDeva dedup tracimy nasze dane. Koniecznym jest r\u00f3wnie\u017c zachowanie redundancji.<\/p>

    \u00a0<\/p>

    Rozmiar takiego vDev szacuje si\u0119 na 1 GB na ka\u017cde 1TB danych poddanych de duplikacji.<\/p>

    \u00a0<\/p>

    Dyski na system<\/strong><\/p>

    Ka\u017cdy serwer NAS poza dyskami na dane i innymi wspomagaj\u0105cymi, o kt\u00f3rych si\u0119 ju\u017c tutaj naopowiada\u0142em, musi mie\u0107 te\u017c dyski na system operacyjny. Tutaj nie ma wi\u0119kszych wymaga\u0144 odno\u015bnie wielko\u015bci czy szybko\u015bci poniewa\u017c na dych dyskach przechowywana jest tylko konfiguracja i troch\u0119 log\u00f3w. \u017badnych naszych danych. W praktyce dyski wielko\u015bci 16 GB w wi\u0119kszo\u015bci wypadk\u00f3w s\u0105 wystarczaj\u0105ce.<\/p>

    \u00a0<\/p>

    Ze wzgl\u0119du na koniczn\u0105 redundancj\u0119 optymalnym rozwi\u0105zaniem s\u0105 dwa minimalne dysku SSD czyli pewnie 256GB czy ju\u017c nawet 500GB. W praktyce Odradza si\u0119 dyski talerzowe i dysku USB.<\/p>

    \u00a0<\/p>

    Cho\u0107 jako ciekawostka powiem, \u017ce jeden z naszych TrueNAS z ma\u0142ym poolem kilkana\u015bcie TB przerzucaj\u0105cy dziennie setki GB dzia\u0142a sobie na dw\u00f3ch 16GB dyskach USB. Absolutnie nie jest to nic co bym poleca\u0142 na rozwi\u0105zanie produkcyjne ale w zupe\u0142no\u015bci spe\u0142nia rol\u0119 jako ma\u0142y podr\u0119czny, nie krytyczny magazyn danych. No i u\u017cywaj\u0105c USB zostaje wi\u0119cej miejsca na dyski z danymi.<\/p>

    \u00a0<\/p>

    linki<\/strong><\/p>

    https:\/\/www.truenas.com\/docs\/core\/gettingstarted\/corehardwareguide\/#minimum-hardware-requirements<\/a><\/p>

    https:\/\/www.truenas.com\/docs\/core\/coretutorials\/storage\/pools\/poolcreate\/#vdev-layout<\/a><\/p>

    \u00a0<\/p>