Na początku słowem szybkiego wstępu, po szczegóły na temat ZFS zapraszam do materiału [TrueNas ZFS – dlaczego jest zajefajny?].

 

W ZFS jednostką organizacyjną w której trzymamy dane jest pool. Do tego poola podpinamy tzw vDev. Podstawowym vDev bez którego nasza zabawa w NAS nie miała by sensu to vDev data w którym trzymane są dane. Ten vDev podpięty do pool musi mieć dyski być jakoś zorganizowane czy to w tzw stipe czy mirror czy właśnie w RAID-Z. Głównie właśnie rozszerzania tego RAID-Z tyczy się dzisiejszy materiał.

ZFS pool – kiedy rozszerzać?

Na początek kilka zaleceń dotyczących dzisiejszego tematu.

 

Kiedy warto rozważyć rozszerzenie poola? Limitem zajętości do którego powinniśmy dopuszczać to 80%. Żeby zachować optymalny poziom wydajności naszego NAS z ZFS zawsze powinniśmy zachować minimum 20% wolnego miejsca. Przyczyną między innymi jest fakt, że ZFS używa mechanizmu Copy on Write. W skrócie działa on tak, że jeżeli nadpisujemy jakieś dane to ZFS pod spodem zapisuje je w zupełnie innym miejscu i nie dotyka miejsca gdzie dane są oryginalnie.  Dopiero jak dane zostaną z sukcesem zapisane w miejscu docelowym to adres do danych się zmiana i zaczyna wskazywać na nowe miejsce. To sprawia, że ZFS jest znaczenie mniej podany na uszkodzenie danych podczas zapisu ale kosztem właśnie tego, że potrzebujemy trzymać 20% wolnego miejsca na pool żeby jego osiągi były optymalne. Czy coś wybuchnie jak miejsce zejdzie poniżej 20%? Oczywiście, że nie możesz używać całości miejsca tylko licz się tym, że osiągi takiego wypłonionego poola spadną.

ZFS pool – jak rozszerzać?

Odnośnie już samego rozszerzania to są trzy główne sposoby rozszerzania poola. Pierwszym może nawet najbardziej oczywistym jest zakup nowej paczki dysków, stworzenie nowego pool, czy nawet nowego serwera i migracja danych. Ale my dzisiaj zdecydowanie nie o tym, przynajmniej głównie nie o tym. Dzisiaj spróbujemy bardziej subtelnie.

ZFS rozszerzanie pool – dodawanie nowego vDev

Jednym ze sposobów jest dodanie nowego vDev Data. Jest to potencjalnie fajne rozwiązanie, jeżeli tylko braliśmy to wcześniej pod uwagę. Uznajmy to za coś w rodzaju naturalnej planowanej drogi rozszerzania pool. Kupując serwer biorąc pod uwagę przyszły wzrost albo zostawiamy wolne kieszenie albo możliwość podłączenia zewnętrznych półek na dyski. Tylko, że wszyscy wiemy, że nie zawsze tak się da.

 

Oczywistą wadą tego rozwiązania jest fakt, że musimy od początku trzymać wolne sloty. Następnym obostrzeniem jest to, że zaleca się rozszerzać pool o identyczne vDev data. Czyli takie same dyski, ten sam poziom RAID-Z.

 

Przyczyną takich wymagań jest to, że ZFS podczas zapisu na pool wykonuje load balancing. Czyli będzie równomiernie obciążał zapisem wszystkie vDev i jeżeli jeden będzie większy czy szybszy to całość będzie działała dostosowując się do wolniejszego. I znów czy coś się stanie jak będą inne dyski? Nie, jeżeli akceptujecie nie opylane osiągi swojego serwera.

 

Ale ale myślę, że najczęściej możemy dobie podarować ten brak optymalności ponieważ ten sam load balancing rozdzielający prace zapisu po równo na dwa vDev sprawia, że teoretycznie w dużym przybliżeniu możemy się spodziewać osiągów zapisu dwukrotności osiągów tego słabszego vDev. W praktyce nie spodziewał bym się aż dwukrotności. Jednak przyspieszenie zwłaszcza zapisu będzie znaczące. Odnośnie odczytu to zależy na którym vDev mamy konkretne dane. Z czasem powinny się w miarę równomiernie rozproszyć i odczyt też powinien znacząco przyspieszyć.

 

Wydajność i osiągi ZFS bardzo zależy od sposobu organizacji dysków w vDev i vDev w pool. To złożony temat i powinien niedługo powstać o tym osobny materiał. Dodam tylko na zachętę, że różnica w niektórych zastosowaniach w wydajność w organizacji dysków właściwe vs niewłaściwa mogą być wielokrotne.

ZFS rozszerzanie pool – wymiana dysków

Jeżeli jednak macie swój serwer i ma on wypełnione wszystkie sloty jest też inny ciekawy sposób. Wystarczy podmienić dyski, sztuka po sztuce na większe i pool sam się zorientuje, że ma więcej miejsca. Myślę, że to też w wielu wypadkach może okazać się dobrym rozwiązaniem. Nie musimy nic migrować, zmieniać po prostu wymieniamy dyski na większe.

 

Najlepiej jeżeli mamy wolne miejsce na dysk, żeby podłączyć nowy  i migrować sztuka po sztuce. W takim wypadku jak mamy dyski hot-swap to przeprowadzimy operacje nawet bez przerwy w działaniu serwera. W przeciwnym wypadku można odłączyć dysk wsadzić nowy i odbudowywać RAID ale to niesie ze sobą ryzyko utraty danych jeśli podczas synchronizacji cokolwiek stanie się coś z pozostałymi dyskami. Pamiętajmy, że odbudowanie dużego RAID to jest taki stres test dla dysków i jeżeli są już starsze to możemy sobie strzelić w kolano. Żeby tego uniknąć możemy nawet wykorzystać przejściówkę podłączając dysk przez USB. Wtedy podłączamy nowy dysk przez takie USB, wymieniamy dysk w pool, wyjmujemy zastąpiony dysk, wkładamy do środka ten z USB. Potem podłączamy przez USB następny. I tak po kolej.

 

Zaletą rozwiązania jest brak konieczności wymiany serwera, utrzymywania wolnych slotów czy zakupu półek na dyski. Wadą w porównaniu do dodawania nowego vDev może, być to, że stare dysku przestają pracować i jeśli nie mamy dla nich innego zastosowania to leżą bezużytecznie.  Oczywiście ta opcja mniej więcej pozostawia osiągi pool bez zmian jeżeli różnica w dyskach nie jest jakaś olbrzymia.

 

Zanim zaczniecie swoje laboratoriom pamiętajcie proszę, że zawsze taka operacja może się nie powieść. Może stać się coś czego nie przewidzimy. Awaria zasilania, awaria dysku. Zanim przystąpicie do działania u siebie upewnijcie się, że macie kopie konfiguracji TrueNAS i samych danych w innym miejscu.

 

 

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