QNAP TS-664 — konfiguracja domowego serwera NAS

W okolicach maja 2024 roku przyszedł czas na unowocześnienie mojego NASa (Network-Attached Storage — co to takiego?) a to ze względu na starzenie się poprzedniego rozwiązania i wyższe wymagania względem dotychczasowego urządzenia. Postaram się pokrótce opisać co i po co dobrałem, do maszynki wrzuciłem i jak to się z perspektywy czasu sprawdziło…

Jak w każdym przypadku konfiguracji nowego urządzenia NAS, wyszedłem od potrzeb, które miały być zaspokojone. Dobrze zrobić sobie taką listę zanim zacznie się dobierać sprzęt i jego podzespoły, bo owa lista w znacznym stopniu zdefiniuje, co brać pod uwagę przy zakupie sprzętu. U mnie lista potrzeb wyglądała następująco:

1. Serwer do zastosowań domowych, nieobciążony zbytnio zadaniami, z kilkoma raptem użytkownikami.
2. Podstawowe zadanie serwera NAS: torrenty i udostępnianie mediów za pomocą serwera mediów Plex.
3. Drugoplanowe zadanie serwera NAS: kopie zapasowe najważniejszych danych moich i rodziny wraz z zabezpieczeniem tych kopii.
4. Trzecioplanowe zadanie serwera NAS: szereg usług dodatkowych realizowanych za pomocą oprogramowania twórców serwera oraz Dockera, mających na celu głównie uniezależnienie się od coraz droższych usług chmurowych Google, Microsoft i innych firm.

Lista krótka i przejrzysta ale dająca już pewne pojęcie o wymaganiach odnośnie sprzętu:

• Filmy i Plex = transkodowanie w locie materiału wideo w przypadku niekompatybilnych odtwarzaczy. W grę wchodziły więc tylko urządzenia z procesorem Intela z obsługą technologii QuickSync — zapewnia to bezproblemowe wsparcie ze strony Pleksa oraz sprzętowe wsparcie dla dekodowania i kodowania wideo już w samym procesorze. Dodatkowo architektura x86 byłaby wielkim ułatwieniem w kwestii wykorzystania Dockera.
• Torrenty — z natury swojej torrenty obciążają ogromnie dyski procesami wielokrotnego odczytu i zapisu danych a więc na potrzeby pobierania torrentów potrzebny był dysk SSD. Niekoniecznie NVMe, wolałem pojemniejszy dysk SSD SATA, który z racji na koszty po prostu był lepszym wyborem do tego celu.
• Kopie zapasowe + media = potrzeba dużej pojemności. Im więcej, tym lepiej acz z uwzględnieniem budżetu. W grę wchodziły więc rozwiązania z minimum 4 dyskami HDD + 1 SSD SATA dla wspomnianych wcześniej torrentów.
• Usługi dodatkowe, media, torrenty i co tam jeszcze = RAM. Potrzeba pamięci RAM! Im więcej, tym oczywiście lepiej! Minimum 16GB i najchętniej rozszerzalnej w przypadku zwiększonych potrzeb.
• Wszystko powyższe wymaga responsywnego systemu i miejsca dla tysięcy drobnych plików (np. miniatur zdjęć, okładek, plakatów itd.), które będzie te pliki podawało możliwie najszybciej. A więc SSD NVMe! A najlepiej dwa, aby móc spiąć te dyski w macierz RAID 1.

Wiedząc do czego urządzenie będzie wykorzystywane i mniej-więcej czego w nim potrzebuję, ruszyłem na zakupy. A nie była to sprawa łatwa, oj nie była!

Po pierwsze: który model NASa wybrać? Na rynku obrodziło ostatnimi czasy firmami tworzącymi NASy i o ile może te nowe firmy w kwestii software odstają nieco od liderów, o tyle w kwestii hardware nadrabiają zaległości programowe z nawiązką. Nie eksperymentowałem jednak zbytnio, po raz kolejny postawiłem na rozsądny kompromis i zakupiłem model QNAP TS-664.

Ten model ma wszystko, na czym mi zależało:

• całkiem wydajny acz oszczędny procesor Intela z technologią Quick Sync wspierającą transkodowanie sprzętowe materiałów wideo;
• sześć zatok na dyski SATA dające pole manewru jeśli chodzi o miejsce na dane;
• dwa sloty na dyski NVMe, co pozwoliło na stworzenie szybkiej puli z najgorętszymi danymi, aplikacjami i usługami;
• rozszerzalną pamięć, którą w razie potrzeby mogę po prostu rozbudować;
• porty Ethernet 2,5Gb, których to prędkości jeszcze nie obsłużę ale w niedalekiej przyszłości już tak, więc zakup futureproof;
• możliwość dalszego, prostego zwiększenia pojemności za pomocą jednostek rozszerzających QNAPa;
• porty kart rozszerzeń PCIe, które mam nadzieję wykorzystać z czasem na dodatkowe dyski NVMe;
• rozsądna (choć nie niska) cena.

Lista zakupów rozszerzyła się dodatkowo o:

• dwa dyski Lexar NM620 512GB M.2 PCIe Gen3x4 NVMe;
• pięć dysków Toshiba N300 HDWG480EZSTA 8TB 3,5″;
• 1 kość pamięci Kingston 16GB 2666MHz CL19.

Miałem więc dyski HDD do obsadzenia pięciu zatok, kupiony wcześniej dysk SSD SATA do obsadzenia szóstej, dwa dyski NVMe do stworzenia ultraszybkiej puli na najgorętsze dane i kostkę pamięci, której w NASie zawsze za mało.

OK, przejdźmy do tego, po co tu jesteś: jak to wszystko skonfigurowałem pod swoje potrzeby?

Po raz kolejny okazuje się, jak ważne jest wcześniejsze określenie owych potrzeb i sposobu korzystania z NASa. Potrzebowałem miejsca na naprawdę gorące dane: tysiące drobnych plików podawanych w usługach, których używam i które udostępniam rodzinie i znajomym, bazy danych większe i mniejsze, biblioteki tego i owego… Przerabiałem już trzymanie takich danych na dyskach SSD SATA i powiadam ci: NVMe to je ono! Jeśli mądrze to poukładasz, twoje kontenery Dockera będą zasuwały, serwery mediów będą szybko i responsywnie wyświetlały metadane (serio, Plex mi fruwa lokalnie a zdalnie — czyli z sieci zewnętrznej — doświadczenie jest porównywalne z używaniem jakiegoś VOD) i tak dalej, i tak dalej. Masz już chyba wyobrażenie, o co mi chodzi.

Przy bardzo aktywnym torrentowaniu same operacje dyskowe potrafią wbić nieprawdopodobne obciążenie serwera a w konsekwencji ubić nawet bardzo wydajną maszynę. Jeśli chcesz się bawić w torrenty, zadbaj o prędkość, szczególnie zapisu (no i skonfiguruj odpowiednio swojego klienta). Do tego celu używam dysku SSD SATA, który ze spokojem obsłuży kilka albo i kilkanaście równoległych pobierań. Ten dysk nie jest w żadnej puli RAID — jeśli zdechnie, to zdechnie, nie mam z tym problemu, po prostu wymienię na nowy i już a jeśli coś przepadnie, to tylko aktualnie pobierane torrenty (nie seedowane, te podaję z innej puli dyskowej, tej wolnej, stworzonej z dysków HDD). Ten dysk służy praktycznie tylko torrentowaniu i trzymaniu ciepłych (ale nie gorących!) danych. Klient torrenta korzysta z rozszerzonej pamięci RAM i wypełnia mi grzecznie cache wykorzystując do tego pamięć RAM właśnie, a nie dysk.

Dane chłodne, backupy, ściągnięte torrentem pliki mediów i inne dane przerzucane są na pięć dysków HDD spiętych w macierz RAID5.

Dzięki takiemu rozrzuceniu danych po pulach różnej prędkości, całość działa nadzwyczaj wydajnie, nie doświadczam większych obciążeń związanych z zapisami/odczytami do/z dysków a dodatkowo mam całkiem logicznie poukładane te dane, które mogę w prosty sposób backupować na dysk zewnętrzny i — te najistotniejsze — także do chmury.

Firma QNAP oferuje w swoim oprogramowaniu systemowym pewne rozwiązania przyspieszające zapis czy/i odczyt danych. Można warstwę ultraszybką (dyski NVMe) przeznaczyć na systemowy cache pracujący w trybach tylko do odczytu bądź tylko do zapisu, bądź obydwu na raz. Innym podejściem oferowanym przez oprogramowanie QNAPa jest technologia QTier, czyli automatycznego przerzucania (warstwowania) przez system danych między warstwą ultraszybką (NVMe), szybką (SSD) i wolną (HDD). Obydwie metody mają swoje plusy i minusy, obydwie mają swoje zastosowania i obydwie są warte osobnych o nich wpisów…

ALE

Czy przydają się w zastosowaniach domowych?

Mówiąc szczerze, w domowych zastosowaniach, takich jak moje, te technologie nie wniosą zbyt wiele. Ba! Najprawdopodobniej szybko je wyłączysz, bo ich przeznaczeniem nie jest tego typu praca. W wielu testach wyszło mi, że wciąż zasuwające i przerzucające dane dyski czynią w diabły hałasu a już szczególnie jest to uciążliwe w nocy, kiedy system pracuje pod mniejszym obciążeniem i zaczyna przewalać tony danych między tierami czy akurat zrzuca gigabajty danych z buforów. To pewne ma sens w obciążonych środowiskach bazodanowych ale szczerze mówiąc, jeśli sensownie rozplanujesz rozłożenie danych, zaoszczędzisz sobie i systemowi sporo hałasu i obciążenia, przez co bardzo wydatnie przyczynisz się do utrzymania długowieczności swoich dysków.

Żeby nie być gołosłownym: testując technologię cache, prawie zarżnąłem dysk SSD SATA, który niemal co dzień pokazywał mi postępujące zużycie i nadawałby się do wymiany po jakimś półroczu użytkowania. Taki sam dysk SSD SATA używany teraz właściwie tylko do torrentowania i podawania cieplejszych danych szczęśliwie buja mi się od 9 miesięcy i pokazuje zużycie w okolicach może 3 procent. Posłuży mi jeszcze długo mimo aktywnego użytkowania. Podobnie miała się sprawa z QTier — to na pewno świetna technologia ale nie w moim przypadku. Przerzucanie danych między tierami powodowało, że praktycznie cały czas wszystkie dyski zasuwały na pełnych prędkościach. Oczywiście, do pewnego momentu masz nad tym kontrolę ale technologia działa w sposób automatyczny i po pewnym czasie szlag mnie trafiał, że mój NAS robiący teoretycznie niewiele, był jedną, wielką grzałką z wariującymi dyskami i wyjącymi wiatrakami.

Pomyślałem chwilę, jak działają aplikacje, z których korzystam. Wykorzystuję aplikacje z repozytoriów QNAPa i MyQNAP.org (natywne aplikacje dla systemu QTS) oraz oczywiście korzystam z Dockera (via Container Station dostarczany przez QNAPa). Kluczem do sukcesu będzie w takiej sytuacji GDZIE te aplikacje trzymają dane, które obrabiają.

Może posłużmy się przykładem serwera mediów Plex.

Plex to przede wszystkim baza danych mediów plus assety wyświetlane w klientach (na komórkach, na telewizorach, w przeglądarkach). Te assety to dziesiątki tysięcy plików z plakatami, zdjęciami aktorów i gazylionem innych danych wyświetlanych podczas używania klientów. Ergo: baza danych i te dziesiątki czy setki tysięcy plików muszą znajdować się na możliwie najszybszym nośniku, by dostęp do nich był natychmiastowy, co zredukuje lagi w działaniu klientów do minimum. Przy okazji te dane nie zajmują jakichś wielkich ilości miejsca, po prostu jest ich ogrom i muszą być dostępne najszybciej, jak to jest możliwe. Podobnie folder przeznaczony na tymczasowe pliki transkodowania — najlepiej, by znajdował się na rączym dysku (a jeszcze lepiej w jakimś ramdysku). Natomiast same media mogą spokojnie leżeć sobie na dyskach HDD, skąd będą wręcz leniwie czytane i przesyłane do dalszej obróbki lub wprost do klienta.

I tak jest praktycznie ze wszystkimi aplikacjami, których używam. Kolejny przykład: aplikacja Immich, czyli coś, co zastępuje mi Zdjęcia Google… Aplikacja bardzo intensywnie używa bazy danych, modeli AI do rozpoznawania twarzy i różnych rzeczy na zdjęciach oraz stworzonych przez siebie miniatur zdjęć. Te wszystkie dane po prostu muszą znajdować się na jak najszybszych dyskach, by zapewnić odpowiednią wydajność pracy aplikacji i wyświetlającemu bibliotekę zdjęć (via miniatury) użytkownikowi. Sama biblioteka zdjęć natomiast może spokojnie leżeć sobie na dysku SSD (to wciąż setki tysięcy raczej niezbyt wielkich plików, które powinny być dostępne “na kliknięcie”) — aplikacja wyśle do klienta zdjęcie po jego wyborze przez użytkownika, tu szybkość nie ma aż tak krytycznego znaczenia.

Widzisz już wzór? Na realia NASa przeniosłem to w następujący sposób:

1. Stworzyłem pulę pamięci złożoną z pięciu dysków HDD spiętych w macierzy RAID5. To jest miejsce dla zimnych danych: media, seedowane torrenty, backup maszyn domowych… Tu znajduje się wolumin o nazwie “DataVol1”.
2. Stworzyłem pulę pamięci złożoną z dwóch dysków SSD NVMe w macierzy RAID1. Tu trzymam najgorętsze dane czyli wszystkie te bazy i pliki dla serwera mediów, bazy danych i miniatury dla aplikacji Immich, bazy danych i pliki konfiguracyjne różnych innych aplikacji i kontenerów Dockera. Tu trzymam wszystko to, co wymaga szybkości i natychmiastowej dostępności. Tu znajduje się wolumin o nazwie “DataVol2”.
3. Stworzyłem pulę pamięci złożoną z jednego dysku SSD SATA, na którym leżą ciepłe dane: biblioteka zdjęć dla aplikacji Immich, biblioteka ebooków dla aplikacji Calibre i Calibre-Web, na ten dysk są też pobierane torrenty, które po pobraniu przenoszone są na pulę z dyskami HDD do woluminu “DataVol1”. Na tym dysku SDD stworzyłem wolumin “DataVol3”.

Podsumowując: mam trzy woluminy, w kolejności jak poniżej:

• “DataVol1” — wolny, dane trzymane na HDD.
• “DataVol2” — najszybszy, dane trzymane na dyskach SSD NVMe.
• “DataVol3” — średni, dane trzymane na dysku SSD.

Całości dopełnia zewnętrzny dysk twardy, na który zrzucam kopie zapasowe z systemowych woluminów oraz osobny NAS, który załącza mi się raz dziennie i na który zrzucane są kopie kopii, ot żeby choć trochę bezpieczniej było.

Jeśli się przyjrzysz, zauważysz, że wolumin DataVol1 (ten na dyskach HDD) nie wypełnia całej puli pamięci. Dlaczego tak? A dlatego, że zostawiam sobie miejsce w puli na różne dodatkowe rozwiązania, które będę chciał wdrożyć w przyszłości. Na dziś znajdują się tam dane cache dla dwóch dysków w chmurze, które udostępniam sobie za pomocą NASa: Dysk Google i QNAP Cloud Storage. System QTS oferuje coś, co nazywa się “Brama do chmury plików” i jest właśnie lokalnym cache dla wymiany danych między chmurą a systemem plików. Na screenie powyżej jest to widoczne jako przestrzenie HybridMount wydzielone na puli (osobno dla każdej usługi chmurowej). To całkiem fajna technologia i temat na kolejny wpis, bo działa to dobrze i uelastycznia dostęp do plików w chmurze.

I to wszystko. Aplikacje z repozytoriów QNAPa i MyQNAP.org (te natywne dla systemu) instaluję na wolumenie “DataVol2”, czyli tym najszybszym. Kontenery Dockera to już w ogóle bajka, bo tam mogę wskazać konkretne wolumeny dla konkretnych danych i tak dla przykładu klient Torrenta, którego używam (qBittorrent) trzyma swoją konfigurację na wolumenie “DataVol2” (najszybszym), pobierane torrenty zapisuje na wolumenie “DataVol3” (tym średniej prędkości) a po zakończeniu pobierania przenosi torrenta w odpowiednie miejsce na wolumenie “DataVol1” (tym najwolniejszym i najpojemniejszym). Mocno posiedziałem nad konfiguracją samego klienta, by możliwie najlepiej wykorzystywał systemowy cache, dzięki czemu ograniczam operacje zapisu/odczytu na ile tylko mogę.

Podobny schemat stosuję do wszystkich aplikacji i to działa bardzo przyzwoicie. System jest responsywny, nawet podczas bardzo aktywnych sesji Torrenta nie jest jakoś znacznie obciążony operacjami zapisu/odczytu, aplikacje działają całkiem szparko a dane podawane są szybko i bez większych opóźnień. System jest raczej chłodny i to mimo zamknięcia gdzieś w szafce (niestety serwer musi stać w pokoju, w którym śpimy, więc skończyło się na zamknięciu w diabły ) — wiatraki nie szaleją, dyski też wciąż nie mielą… Jestem zadowolony z tej konfiguracji.

Cała zabawa z NASem sprowadza się tak po prawdzie do konkretnego określenia potrzeb i dostosowania do nich sprzętu i oprogramowania. Ot owych potrzeb będzie zależał dobór hardware i software oraz możliwie najlepsza konfiguracja całości, tak by uzyskać system wydajny i owe potrzeby zaspokajający. W moim przypadku okazało się, że w całkiem sensownym budżecie mogłem skonfigurować maszynkę, która teraz służy nie tylko mnie i mojej rodzinie ale i bandzie moich znajomych. I robi to całkiem nieźle!

Czego i tobie życzę 🙂