{"id":845,"date":"2023-08-28T17:55:33","date_gmt":"2023-08-28T15:55:33","guid":{"rendered":"https:\/\/eonea.pl\/?p=845"},"modified":"2024-04-05T10:55:59","modified_gmt":"2024-04-05T08:55:59","slug":"truenas-zfs-rozszerzanie-pool","status":"publish","type":"post","link":"https:\/\/eonea.pl\/en\/truenas-zfs-rozszerzanie-pool\/","title":{"rendered":"TrueNAS ZFS pool expansion"},"content":{"rendered":"

Na pocz\u0105tku s\u0142owem szybkiego wst\u0119pu, po szczeg\u00f3\u0142y na temat ZFS zapraszam do materia\u0142u [TrueNas ZFS \u2013 dlaczego jest zajefajny?<\/a>].<\/strong><\/p>\n

 <\/p>\n

W ZFS jednostk\u0105 organizacyjn\u0105 w kt\u00f3rej trzymamy dane jest pool. Do tego poola podpinamy tzw vDev. Podstawowym vDev bez kt\u00f3rego nasza zabawa w NAS nie mia\u0142a by sensu to vDev data w kt\u00f3rym trzymane s\u0105 dane. Ten vDev podpi\u0119ty do pool musi mie\u0107 dyski by\u0107 jako\u015b zorganizowane czy to w tzw stipe czy mirror czy w\u0142a\u015bnie w RAID-Z. G\u0142\u00f3wnie w\u0142a\u015bnie rozszerzania tego RAID-Z tyczy si\u0119 dzisiejszy materia\u0142.<\/p>\n

<\/h4>\n

ZFS pool \u2013 kiedy rozszerza\u0107?<\/strong><\/p>\n

Na pocz\u0105tek kilka zalece\u0144 dotycz\u0105cych dzisiejszego tematu.<\/p>\n

 <\/p>\n

Kiedy warto rozwa\u017cy\u0107 rozszerzenie poola? Limitem zaj\u0119to\u015bci do kt\u00f3rego powinni\u015bmy dopuszcza\u0107 to 80%. \u017beby zachowa\u0107 optymalny poziom wydajno\u015bci naszego NAS z ZFS zawsze powinni\u015bmy zachowa\u0107 minimum 20% wolnego miejsca. Przyczyn\u0105 mi\u0119dzy innymi jest fakt, \u017ce ZFS u\u017cywa mechanizmu Copy on Write. W skr\u00f3cie dzia\u0142a on tak, \u017ce je\u017celi nadpisujemy jakie\u015b dane to ZFS pod spodem zapisuje je w zupe\u0142nie innym miejscu i nie dotyka miejsca gdzie dane s\u0105 oryginalnie.\u00a0 Dopiero jak dane zostan\u0105 z sukcesem zapisane w miejscu docelowym to adres do danych si\u0119 zmiana i zaczyna wskazywa\u0107 na nowe miejsce. To sprawia, \u017ce ZFS jest znaczenie mniej podany na uszkodzenie danych podczas zapisu ale kosztem w\u0142a\u015bnie tego, \u017ce potrzebujemy trzyma\u0107 20% wolnego miejsca na pool \u017ceby jego osi\u0105gi by\u0142y optymalne. Czy co\u015b wybuchnie jak miejsce zejdzie poni\u017cej 20%? Oczywi\u015bcie, \u017ce nie mo\u017cesz u\u017cywa\u0107 ca\u0142o\u015bci miejsca tylko licz si\u0119 tym, \u017ce osi\u0105gi takiego wyp\u0142onionego poola spadn\u0105.<\/p>\n

<\/h4>\n

ZFS pool \u2013 jak rozszerza\u0107?<\/strong><\/p>\n

Odno\u015bnie ju\u017c samego rozszerzania to s\u0105 trzy g\u0142\u00f3wne sposoby rozszerzania poola. Pierwszym mo\u017ce nawet najbardziej oczywistym jest zakup nowej paczki dysk\u00f3w, stworzenie nowego pool, czy nawet nowego serwera i migracja danych. Ale my dzisiaj zdecydowanie nie o tym, przynajmniej g\u0142\u00f3wnie nie o tym. Dzisiaj spr\u00f3bujemy bardziej subtelnie.<\/p>\n

<\/h4>\n

ZFS rozszerzanie pool \u2013 dodawanie nowego vDev<\/strong><\/p>\n

Jednym ze sposob\u00f3w jest dodanie nowego vDev Data. Jest to potencjalnie fajne rozwi\u0105zanie, je\u017celi tylko brali\u015bmy to wcze\u015bniej pod uwag\u0119. Uznajmy to za co\u015b w rodzaju naturalnej planowanej drogi rozszerzania pool. Kupuj\u0105c serwer bior\u0105c pod uwag\u0119 przysz\u0142y wzrost albo zostawiamy wolne kieszenie albo mo\u017cliwo\u015b\u0107 pod\u0142\u0105czenia zewn\u0119trznych p\u00f3\u0142ek na dyski. Tylko, \u017ce wszyscy wiemy, \u017ce nie zawsze tak si\u0119 da.<\/p>\n

 <\/p>\n

Oczywist\u0105 wad\u0105 tego rozwi\u0105zania jest fakt, \u017ce musimy od pocz\u0105tku trzyma\u0107 wolne sloty. Nast\u0119pnym obostrzeniem jest to, \u017ce zaleca si\u0119 rozszerza\u0107 pool o identyczne vDev data. Czyli takie same dyski, ten sam poziom RAID-Z.<\/p>\n

 <\/p>\n

Przyczyn\u0105 takich wymaga\u0144 jest to, \u017ce ZFS podczas zapisu na pool wykonuje load balancing. Czyli b\u0119dzie r\u00f3wnomiernie obci\u0105\u017ca\u0142 zapisem wszystkie vDev i je\u017celi jeden b\u0119dzie wi\u0119kszy czy szybszy to ca\u0142o\u015b\u0107 b\u0119dzie dzia\u0142a\u0142a dostosowuj\u0105c si\u0119 do wolniejszego. I zn\u00f3w czy co\u015b si\u0119 stanie jak b\u0119d\u0105 inne dyski? Nie, je\u017celi akceptujecie nie opylane osi\u0105gi swojego serwera.<\/p>\n

 <\/p>\n

Ale ale my\u015bl\u0119, \u017ce najcz\u0119\u015bciej mo\u017cemy dobie podarowa\u0107 ten brak optymalno\u015bci poniewa\u017c ten sam load balancing rozdzielaj\u0105cy prace zapisu po r\u00f3wno na dwa vDev sprawia, \u017ce teoretycznie w du\u017cym przybli\u017ceniu mo\u017cemy si\u0119 spodziewa\u0107 osi\u0105g\u00f3w zapisu dwukrotno\u015bci osi\u0105g\u00f3w tego s\u0142abszego vDev. W praktyce nie spodziewa\u0142 bym si\u0119 a\u017c dwukrotno\u015bci. Jednak przyspieszenie zw\u0142aszcza zapisu b\u0119dzie znacz\u0105ce. Odno\u015bnie odczytu to zale\u017cy na kt\u00f3rym vDev mamy konkretne dane. Z czasem powinny si\u0119 w miar\u0119 r\u00f3wnomiernie rozproszy\u0107 i odczyt te\u017c powinien znacz\u0105co przyspieszy\u0107.<\/p>\n

 <\/p>\n

Wydajno\u015b\u0107 i osi\u0105gi ZFS bardzo zale\u017cy od sposobu organizacji dysk\u00f3w w vDev i vDev w pool. To z\u0142o\u017cony temat i powinien nied\u0142ugo powsta\u0107 o tym osobny materia\u0142. Dodam tylko na zach\u0119t\u0119, \u017ce r\u00f3\u017cnica w niekt\u00f3rych zastosowaniach w wydajno\u015b\u0107 w organizacji dysk\u00f3w w\u0142a\u015bciwe vs niew\u0142a\u015bciwa mog\u0105 by\u0107 wielokrotne.<\/p>\n

<\/h4>\n

ZFS rozszerzanie pool \u2013 wymiana dysk\u00f3w<\/strong><\/p>\n

Je\u017celi jednak macie sw\u00f3j serwer i ma on wype\u0142nione wszystkie sloty jest te\u017c inny ciekawy spos\u00f3b. Wystarczy podmieni\u0107 dyski, sztuka po sztuce na wi\u0119ksze i pool sam si\u0119 zorientuje, \u017ce ma wi\u0119cej miejsca. My\u015bl\u0119, \u017ce to te\u017c w wielu wypadkach mo\u017ce okaza\u0107 si\u0119 dobrym rozwi\u0105zaniem. Nie musimy nic migrowa\u0107, zmienia\u0107 po prostu wymieniamy dyski na wi\u0119ksze.<\/p>\n

 <\/p>\n

Najlepiej je\u017celi mamy wolne miejsce na dysk, \u017ceby pod\u0142\u0105czy\u0107 nowy\u00a0 i migrowa\u0107 sztuka po sztuce. W takim wypadku jak mamy dyski hot-swap to przeprowadzimy operacje nawet bez przerwy w dzia\u0142aniu serwera. W przeciwnym wypadku mo\u017cna od\u0142\u0105czy\u0107 dysk wsadzi\u0107 nowy i odbudowywa\u0107 RAID ale to niesie ze sob\u0105 ryzyko utraty danych je\u015bli podczas synchronizacji cokolwiek stanie si\u0119 co\u015b z pozosta\u0142ymi dyskami. Pami\u0119tajmy, \u017ce odbudowanie du\u017cego RAID to jest taki stres test dla dysk\u00f3w i je\u017celi s\u0105 ju\u017c starsze to mo\u017cemy sobie strzeli\u0107 w kolano. \u017beby tego unikn\u0105\u0107 mo\u017cemy nawet wykorzysta\u0107 przej\u015bci\u00f3wk\u0119 pod\u0142\u0105czaj\u0105c dysk przez USB. Wtedy pod\u0142\u0105czamy nowy dysk przez takie USB, wymieniamy dysk w pool, wyjmujemy zast\u0105piony dysk, wk\u0142adamy do \u015brodka ten z USB. Potem pod\u0142\u0105czamy przez USB nast\u0119pny. I tak po kolej.<\/p>\n

 <\/p>\n

Zalet\u0105 rozwi\u0105zania jest brak konieczno\u015bci wymiany serwera, utrzymywania wolnych slot\u00f3w czy zakupu p\u00f3\u0142ek na dyski. Wad\u0105 w por\u00f3wnaniu do dodawania nowego vDev mo\u017ce, by\u0107 to, \u017ce stare dysku przestaj\u0105 pracowa\u0107 i je\u015bli nie mamy dla nich innego zastosowania to le\u017c\u0105 bezu\u017cytecznie.\u00a0 Oczywi\u015bcie ta opcja mniej wi\u0119cej pozostawia osi\u0105gi pool bez zmian je\u017celi r\u00f3\u017cnica w dyskach nie jest jaka\u015b olbrzymia.<\/p>\n

 <\/p>\n

Zanim zaczniecie swoje laboratoriom pami\u0119tajcie prosz\u0119, \u017ce zawsze taka operacja mo\u017ce si\u0119 nie powie\u015b\u0107. Mo\u017ce sta\u0107 si\u0119 co\u015b czego nie przewidzimy. Awaria zasilania, awaria dysku. Zanim przyst\u0105picie do dzia\u0142ania u siebie upewnijcie si\u0119, \u017ce macie kopie konfiguracji TrueNAS i samych danych w innym miejscu.<\/p>\n

 <\/p>\n