Grzegorz Wita IT - TrueNAS CORE 13.0 na Supermicro SuperStorage SSG-5018A-AR12L

Ostatnia aktualizacja: 15.06.2023 r.

W 2021 roku cały czas miałem pod swoją opieką serwer HP (dokładnego modelu już nie pamiętam, ale był wyposażony w oszałamiające 4 GB RAM 😅) z zainstalowanym systemem Microsoft Windows Server 2008 R2, który całościowe wsparcie stracił 14 stycznia 2020 roku. Hulała na nim domena z serwerem plików, która skonfigurowana była w RAID-1 z dwóch dysków HDD 1 TB. Napiszę to tak - działało to byle jak, ale działało. Na początku, gdy dostęp do serwera uzyskiwało kilku użytkowników i danych było mało, to wydajność była bardzo dobra. Po kilkunastu latach załoga powiększyła się kilkukrotnie, ilość danych liczona jest już w setkach gigabajtów, a wydajność tego rozwiązania pozostawiała już wiele do życzenia i obsługa całego tego rozwiązania stawała się uciążliwa. Modernizacja urządzenia nie miała większego sensu ze względu na wiek sprzętu także postanowiłem to wszystko "zaorać" i zmigrować na lepszy sprzęt i oprogramowanie.

Założenia nowego rozwiązania

nowsze i wydajniejsze urządzenie z możliwością montażu więcej niż 2 dysków twardych
nowoczesny otwartoźródłowy system operacyjny pozwalający na połączenia z systemów Windows, Linux oraz macOS
ochrona przed ransomware
możliwość wykonywania dziennych kopii plików w ramach urządzenia zamiast na osobny dysk USB
automatyzacja pracy
wbudowane mechanizmy raportowania pracy

Supermicro SuperStorage SSG-5018A-AR12L

Na początku dość długo szukałem odpowiedniego urządzenia. Po głowie chodziły mi macierze, półki dyskowe, komputery typu Tower czy mikroserwery. Ostatecznie zdecydowałem się na rozwiązanie Supermicro SuperStorage SSG-5018A-AR12L (na zdjęciu to ten środkowy, szary).

Za nim przejdę do opisu urządzenia i mojej konfiguracji, to w tym momencie zwrócę Twoją uwagę na dwa ważne elementy - głębokość urządzenia oraz plastykowe blokery szyn RACK. Zaskoczyły mnie one podczas montażu urządzenia w szafie RACK więc lepiej żebyś to wiedział(-a) teraz niż później. Moja szafa RACK ma wymiary 2000x800x1000mm (z cokołem 2120x800x1000mm), do której mogę zamontować urządzenia teleinformatyczne o maksymalnej głębokości 705mm (choć miałem już w niej serwer o wymiarach 735mm), natomiast serwer jest dedykowany dla szaf 2000x800x1200mm, gdyż jego głębokość wynosi 813mm. Bez problemów wsadziłem go do szafy, ale jakie było moje zdziwienie jak poszedłem na tył szafy:

Wyprzedzając Twoje pytanie - tak, przed zakupem nie zweryfikowałem rozmiarów urządzenia na stronie producenta gdyż wyszedłem z założenia, że jest to ustandaryzowane i tak też jest w większości przypadków. Cóż, myliłem się, ale tak wygląda prawdziwe życie i praktyczne zdobywanie wiedzy oraz umiejętności. 😏 Co prawda głębokość serwera jest na styk i przy zastosowaniu kątowych kabli zasilających jego tył byłby milimetry od tylnej ściany. Niestety szyny są dłuższe i wystają poza obręb szafy:

U mnie nie jest to problem, gdyż nie mam zamontowanej tylnej ściany szafy więc może to tak wyglądać - jedyne utrudnienie będzie podczas prac z tyłu szafy, gdyż będę musiał uważać na te wystające elementy. Kilka razy już w nie uderzyłem głową podczas wstawania czy zahaczyłem rękami. Krawędzie nie są przesadnie ostre, ale przy intensywnych ruchach da radę się o to skaleczyć. Jeśli u Ciebie jest odwrotnie i nie możesz sobie pozwolić na nie posiadanie zamontowanej tylnej ściany szafy RACK to niestety to urządzenie nie jest dla Ciebie. No chyba, że szlifierką kątową skrócisz szyny. 😅

Drugi element to plastikowe blokery szyn RACK. Supermicro to super (🙃) firma, która do swoich urządzeń (oczywiście nie wszystkich) dodaje w komplecie szyny. Podczas ich rozpakowywania pierwotnie myślałem, że są to poprostu plastikowe osłony na końce szyn. Je same zamontowałem bez nich, na pewniaka osadziłem w nich serwer i podczas wsuwania go przednia część szyn odpięła mi się od pionowego wspornika i zostałem z serwerem w rękach. Na domiar złego, kiedy zaczepy puściły, to szarpnąłem serwerem do siebie i odpięła się tylna część szyn. Efekt był taki, że całość pod kątem 45 stopni zakleszczyła mi się między pionowymi wspornikami szafy. Gdyby nie pomoc kolegi, który jeszcze był w firmie, w pojedynkę szybko bym go nie wyciągnął. 😢 Po wyjęciu serwera z szafy i kilkunastu minutach rozpracowałem temat, który okazał się banalny - żółtych plastikowych elementów nie należy wogóle zdejmować z szyn, wystarczy je przesunąć lekko do tyłu z każdej ze stron, zamontować szyny w szafie, a na koniec przesunąć plastikowe elementy do przodu, które zabezpieczą je przed wypięciem. Pierwszy raz coś takiego widziałem więc nie dziwota, że nie wiedziałem z czym to się je.

No dobrze, jeśli to, co do tej pory napisałem nie jest dla Ciebie problemem (chodzi głównie o głębokość serwera, bo drugi temat to w zasadzie pierdoła, aczkolwiek może sprawić problemy, czego jestem niezbitym dowodem 😆), to możemy iść dalej. Serwer sprzedawany jest jako tzw. barebone czyli bez pamięci RAM oraz dysków twardych i posiada następujące parametry:

rozmiar 1U
procesor Intel Atom® C2750 - 8 rdzeni (bez HT) o bazowym taktowaniu 2,40 GHz (turbo do 2,60 GHz),
max. 64 GB RAM DDR3-1600 ECC/non-ECC w czterech slotach
max. 12 HDD 3.5" SATA3/SAS2 w kieszeniach Hot-swap
2x RJ45 LAN 1 GbE oparty o kontroler I354 w SoC
1x RJ45 IPMI
2x zasilacze 400W

Tak prezentuje się moje urządzenie po zdjęciu dwóch górnych paneli z zainstalowanym całym osprzętem:

Mój egzemplarz posiada 32 GB DDR3-1600 ECC 2Rx8 (4x8GB) w Dual Channel, a system operacyjny zainstalowany jest na 128 GB module SATA DOM (SuperDOM), który jest wpięty w specjalny port na płycie głównej (żółty port SATA, widoczny na poniższym zdjęciu niedaleko lewego górnego rogu radiatora procesora).

Prezentowana konfiguracja składa się z 8 dysków twardych HDD w układzie 4 dyski po 2 TB SAS2 7200 rpm (dolna czwórka) oraz 4 dyski po 4 TB SATA3 5400 rpm (górna czwórka).

Dyski twarde przykręcane są od spodu do specjalnych ramek, które fabrycznie zamontowane są w urządzeniu, a komplet śrubek znajduje się w kartonie dołączonym do zestawu.

W komplecie znajdują się również naklejki z numerami. Tak prezentuje się całość po skręceniu:

Ramki umieszczamy w urządzeniu w odpowiednich miejscach i delikatnie przesuwamy w kierunku portu. Dźwięk "kliku" oznacza poprawny montaż. Dodatkowo każdą z ramek możemy zabezpieczyć śrubką. Na poniższym zdjęciu widoczny jest również mechanizm służący do wyciągania dysków twardych.

Tak prezentuje się mój egzemplarz. 😎 W tym momencie jeszcze nie zamykam urządzania i nie przykręcam po prawej stronie dwóch śrubkek zabezpieczających (celowo o tym tutaj wspominam, gdyż raz już o nich zapomniałem i zastanawiałem się jak do diabła zdejmowało się z niego te panele 😅) ponieważ w mojej konfiguracji kilkukrotnie włączam i wyłączam urządzenie, i dokładam dyski twarde ponieważ chcę dokładnie wiedzieć które dyski są w jakich zatokach i jakie idą do odpowiednich puli.

Konfiguracja TrueNAS CORE 13.0

Całe urządzenie skonfigurowałem na systemie TrueNAS 13.0. Jest to otwartoźródłowy system operacyjny oparty o FreeBSD rozwijany przez firmę iXsystems, który wykorzystuje OpenZFS jako system plików. Projekt wystartował w październiku 2005 roku pod nazwą FreeNAS, a we wrześniu 2009 roku przeszedł pod skrzydła firmy iXsystems i od tego czasu jest przez nich nieprzerwanie rozwijany. Opiekunowie projektu w związku z ujednoliceniem repozytoriów darmowego FreeNAS`a oraz komercyjnego TrueNAS`a w jedną bazę kodu oficjalnie zmienili, czy raczej ujednolicili, nazwę na TrueNAS, która oficjalnie obowiązuje od 20 października 2020 roku jako edycja darmowa CORE i płatna ENTERPRISE, która sprzedawana jest razem z dedykowanymi urządzeniami iXsystems. W lutym 2022 roku swoją premierę miał system TrueNAS SCALE, który jest oparty o dystrubucję Debian Linux. Zdecydowałem się na wersję CORE ponieważ w dniu uruchamiania systemu wersja SCALE była ciągle w wersji testowej, a nawet gdyby była dostępna wersja GA to nie zdecydowałbym się na jej wdrożenie z powodu "problemów wieku dziecięcego".

Poniższe zrzuty ekranowe zrobiłem na maszynie wirtualnej w Hyper-V, jednak na fizycznym serwerze postępowałem identycznie.

W pierwszej kolejności pobieram najnowszą wersję TrueNAS`a ze strony producenta, który następnie ładuję do programu Rufus w celu przygotowania bootowalnego pendrive`a, z którego będę instalował system operacyjny na dedykowany 128 GB moduł SATA DOM. Sam proces instalacji jest bardzo prosty - po uruchomieniu kreatora wybieram tryb instalacji, wspomiany dysk, ustawiam hasło dla konta root, wybieram tryb uruchamiania (BIOS lub UEFI, u mnie to pierwsze), ustawiam 16 GB partycję SWAP i czekam na zakończenie pracy kreatora. Na koniec restartuję serwer, wyciągam pendrive i czekam na załadowanie systemu operacyjnego. Dostęp do systemu jest przez przeglądarkę internetową na wskazany adres IP.
Osobiście stosuję nietypową metodę instalacji jakiegokolwiek systemu operacyjnego czyli na czas instalacji w urządzeniu umieszczam wyłącznie dysk na system operacyjny. Dzięki temu nie pomylę się podczas wyboru nośnika oraz sam instalator nie utworzy mi na innych dyskach jakiś partycji. Co prawda są to doświadczenia z ekosystemu Windows, jednak cały czas je stosuję jako zabezpieczenie przed samym sobą. Takie moje widzi misię.

W tym przypadku instaluję system na jednym dysku twardym. Ta metoda nie jest zalecana, gdyż system powinien wylądować na minimum dwóch dyskach w RAID-1.
Loguję się do systemu i rozpoczynam wstępną konfigurację. W menu po lewej stronie wybieram Network ➔ Global Configuration, gdzie w polu Hostname wpisuję nazwę serwera. W moim przypadku będzie to poprostu TrueNAS. Uzupełniam też pole Domain, choć nie jest to wymagane. Zapisuję zmiany klikając przycisk SAVE .
Następnie z menu wybieram System ➔ General, w celu ustawienia odpowiedniej strefy czasowej. Zapisuję zmiany przyciskiem SAVE , po których system ustawi dla wybranej strefy odpowiedni format czasu i godzinę.
Przechodzę na System ➔ Advanced, gdzie w sekcji Console odznaczam opcję "[ ] Show Text Console without Password Prompt" w celu utwardzenia urządzenia i zabezpieczenia dostępu do konsoli systemu. W sekcji Replication usuwam limit 5 jednoczesnych zadań replikacji. Co prawda w moim przypadku całkowita liczba zadań póki co wynosi mniej niż 5 więc ten limit mógłbym zostawić jednak go usunąłem aby sprawdzić przy jakiej liczbie system będzie miał problem z ilością zadań. Także zmiana tego ustawienia zależy od Ciebie. Zapisuję zmiany przyciskiem SAVE .
Teraz przechodzę na System ➔ Email, w celu ustawienia adresu e-mail, na który system będzie wysyłał wiadomości w przypadku poblemów. Po wprowadzaniu danych klikam przycisk SEND TEST MAIL w celu sprawdzenia poprawności konfiguracji. Jeśli mail dotarł na skrzynkę to konfiguracja jest poprawna więc zapisuję ją przyciskiem SAVE .
W tym momencie wyłączam serwer i montuję pierwsze cztery dyski twarde po 2 TB na interfejsie SAS2, które będą tworzyć moją główną, produkcyjną przestrzeń. W dokumentacji zapisuję numery dysków twardych oraz zatok, w których je umieszczam. Uruchamiam urządzenie i po zalogowaniu się do systemu w menu wybieram Storage ➔ Pools i klikam przycisk ADD . W kolejnym oknie zostawiam domyślne wartości i klikam przycisk CREATE POOL . W menadżerze puli nadaję nazwę mojej przestrzeni, ustawiam szyfrowanie, zaznaczam wszystkie cztery dyski i ustawiam je jako RAIDZ-1, co jest odpowiednikiem RAID-5 czyli mogę stracić jeden dysk bez utraty danych. Klikam przycisk CREATE i potwierdzam komunikat, a na koniec klikam przycisk CREATE POOL i czekam na utworzenie puli.
Po utworzeniu puli system poprosi o pobranie klucza deszyfrującego. Pobieram go klikając czerwony przycisk DOWNLOAD ENCRYPTION KEY i zapisuję w bezpiecznym miejscu. Jest on niezwykle ważny ponieważ jeśli go stracę i np. podczas awarii będę musiał zaimportować pulę na innym systemie to bez tego pliku nie uzyskam dostępu do danych i stracę je bezpowrotnie. Dlatego jeśli ustawiłeś(-aś) szyfrowanie to koniecznie pobierz ten plik! Po pobraniu pliku klikam przycisk DONE . Można go oczywiście pobrać później, jednak lepiej zrobić to od razu.
Powtarzam kroki 6-7 dla drugich czterech dysków twardych po 4 TB na interfejsie SATA3, które będą tworzyć moją zapasową przestrzeń danych w ramach tego samego urządzenia. Po wykonaniu wszystkich czynności na ekranie zobaczę dwa baseny danych.
Przechodzę w menu na System ➔ System Dataset i przestawiam konfigurację z puli ZEUS na boot-pool ponieważ całość konfiguracji chcę mieć na dysku systemowym. Zapisuję zmiany przyciskiem SAVE .

//SMB

Domena Active Directory na Windows Server idzie w odstawkę, gdyż konta służymi mi tylko i wyłącznie do logowania się do udziałów sieciowych. Nie korzystałem z kont domenowych na komputerach klienckich więc tak naprawdę AD nie jest mi potrzebne skoro niewykorzystuję jego możliwości, a co za tym idzie szkoda wydawać na nie pieniądze. W przypadku TrueNAS`a wszystkie konta użytkowników, usług i konta dla urządzeń będą obsługiwane przez serwer plików Samba.

W pierwszej kolejności przygotowuję grupy. Nazywam je zgodnie z nazewnictwem wykorzystywanym w firmie lub ich zastosowaniem. Swoje grupy możesz nazywać w podobny sposób, jednak stosuj się do nazewnictwa wykorzystywanego w swojej organizacji lub do innych przyjętych założeń. W celu dodania grupy z menu wybieram Accounts ➔ Groups i klikam w przycisk ADD , a na koniec klikam przycisk SUBMIT . Czynność tą powtarzam tyle razy ile grup potrzebuję dodać.
Przechodzę w menu na Accounts ➔ Users, w celu dodania konta administracyjnego dla siebie zgodnie z nazewnictwem wykorzystywanym w organizacji. W moim przypadku jako Full Name wpisuję imię i nazwisko, system na podstawie tych danych przygotuje login (czasami wymagana jest ręczna korekta gdyż nie może ono zawierać polskich znaków) oraz adres e-mail. Odznaczam opcję "[ ] New Primary Group" ponieważ nie chcę aby system dla mojego konta tworzył osobno grupę. Z listy Primary Group wybieram pozycję buildin_administrators. Listę Auxiliary Groups zostawiam pustą gdyż po dodaniu konta system automatycznie wstawi tam grupę buildin_users (grupa ta jest automatycznie dodawana dla każdego tworzonego konta).

Resztę opcji pozostawiam w ich wartościach domyślnych i na koniec klikam przycisk SUBMIT .
W przypadku kont zwykłych użytkowników stosuję tą samą zasadę co w poprzednim punkcie z tą różnicą, że na liście Primary Group wybieram firmę (tj. grupę), w której dany pracownik jest zatrudniony, a z listy Auxiliary Groups wybieram grupę KSERO oraz inne grupy, do których dany użytkownik musi mieć dostęp. Resztę opcji pozostawiam w ich wartościach domyślnych i na koniec klikam przycisk SUBMIT .
Konta usługowe tworzy się w dokładnie taki sam sposób jak zwykłe konta - podobnie jak w AD na Windows Server. U mnie konto o nazwie Backup przypisuję do grupy BACKUP i będzie ono wykorzystywane przez inny system do logowania się do udziału w którym będą zapisywane kopie zapasowe.
Teraz przyszła pora na przygotowanie zbiorów danych. W tym celu w menu przechodzę na Storage ➔ Pools, wybieram basen ZEUS, klikam w "⋮" po lewej stronie i z menu wybieram pozycję Add Dataset (tak samo postępuję jeśli w ramach dataset`u chcę dodać kolejny dataset - najechanie kursorem podświetli pozycję w ramach której będą następowały zmiany).
Nadaję nazwę zbiorowi danych, dodaję komentarz (jeśli potrzeba) i resztę opcji zostawiam w wartościach domyślnych i klikam przycisk SUBMIT w celu dodania "folderu danych". Czynność powtarzam tyle razy ile zbiorów potrzebuję dodać.

Zbiory danych nazywam w taki sam sposób jak grupy oraz ważne dataset`y zebrałem w ramach jednego, dużego zbioru danych dla zachowania porządku na liście (struktura drzewiasta). Tak wygląda finalny efekt.
Teraz przygotowuję udziały sieciowe dla utworzonych dataset`ów. W tym celu z menu wybieram Sharing ➔ Windows Shares (SMB) i klikam przycisk ADD . Wskazuję odpowiednią ścieżkę oraz opcjonalnie zmieniam nazwę dla udziału sieciowego. W moim przypadku udział sieciowy nazywa się tak samo jak dataset. Resztę ustawień zostawiam w wartościach domyślnych i na koniec klikam przycisk SUBMIT . Czynność powtarzam tyle razy ile udziałów sieciowych potrzebuję dodać.

Przy pierwszym tworzonym udziale system poprosi o włączenie usługi SMB więc klikam przycisk ENABLE SERVICE , a po paru sekundach wyświetli się kolejny komunikat czy chcę teraz skonfigurować listy ACL dla tego udziału. Odpowiadam twierdząco klikają przycisk CONFIGURA NOW . Po kolejnych kilku sekundach system poprosi o wybranie presetu ACL. Wybieram opcję "◎ Create a custom ACL" gdyż chcę całość skonfigurować po swojemu i w celu zatwierdzenia wyboru klikam przycisk CONTINUE .

Tymczasowo zmieniam właściciela plików z root na gwita (wpisuję ręcznie lub wybieram z listy), zaznaczam opcję "[✓] Apply User" i na liście ACL po prawej stronie przy pierwszej górnej pozycji ustawiam pole "Flags *" na Inherit. Resztę opcji zostawiam bez zmian i zatwierdzam całość przyciskiem SAVE .

Czynności te powtarzam tyle razy ile udziałów muszę przygotować. Tak wygląda wstępny efekt.
W tym momencie migruję dane do odpowiednich folderów korzystając z mojego konta administracyjnego w TrueNAS. U mnie było to kilkaset gigabajtów danych więc leciało to kilka godzin. Mając już wszystkie dane na nowym serwerze przystępuję do konfiguracji docelowych list ACL dla udziałów sieciowych. W menu przechodzę na Sharing ➔ Windows Shares (SMB) ➔ przy odpowiednim udziale klikam "⋮" ➔ Edit Filesystem ACL ➔ "◎ Create a custom ACL" i na klikam przycisk CONTINUE .

Moja konfiguracja uprawnień jest taka (poniższy przykład dla FIRMA1):
- zmieniam użytkownika z gwita na root i zaznaczam opcję "[✓] Apply User",
- zmieniam grupę z wheel na FIRMA1 i zaznaczam opcję "[✓] Apply Group",
- na liście ACL w drugiej sekcji zmieniam wartość pola "Permissions Type *" z Advanced na Basic oraz wartość pola "Flags *" z No Inherit na Inherit,
- usuwam sekcję everyone@ przyciskiem DELETE ,

- klikam przycisk ADD ACL ITEM , a następnie pole "Who *" ustawiam na Group, pole "Group *" na builtin_administrators, pole "Permissions *" na Full Control,
- ponownie klikam przycisk ADD ACL ITEM , a następnie pole "Who *" ustawiam na Group i pole "Group *" na ZARZAD,

- zaznaczam opcję "[✓] Apply permissions recursively", potwierdzam komunikat i klikam CONTINUE oraz SAVE . Czekam na zaaplikowanie zmian, których czas zależy od ilości danych. W/w czynności powtarzam dla każdego przygotowywanego udziału sieciowego.

Jeden z moich udziałów dodatkowo zawiera sekcję z uprawnieniami dla jednej osoby, która musi mieć dostęp do określonych katalogów na tym dysku sieciowym i tylko do nich. W celu skonfigurowania tego ustawienia na liście ACL systemu plików klikam przycisk ADD ALC ITEM , a następnie pole "Who *" ustawiam na User i w polu poniżej wpisuję nazwę użytkownika oraz ustawiam pole "Flags *" na No Inherit, a na koniec klikam przycisk SAVE w celu zapisania zmian.

To ustawienie spowoduje, że wprowadzone konto użytkownika będzie mogło "wejść" na udział, ale nic w nim nie zobaczy dopóty dopóki ręcznie nie nadam uprawnień do określonego katalogu lub katalogów więc loguję się na udział sieciowy swoimi poświadczeniami, a następnie na zakładce Zabezpieczenia we właściwościach wybranego folderu klikam przyciski Edytuj... ➔ Dodaj... ➔ Zaawansowane... ➔ Znajdź teraz . Z listy wybieram odpowiednie konto i klikam dwa razy przycisk OK , następnie nadaję uprawnienia (w moim przypadku były to wszystkie opcje prócz pełnej kontroli) i na koniec klikam przyciski Zastosuj i OK w celu zapisania zmian.
Powtarzam punkt 8 dla innych udziałów sieciowych.
Na koniec wprowadzam małą zmianę do konfiguracji usługi SMB. Z menu wybieram Services, na liście wybieram pozycję SMB i klikam ikonę ołówka. Dalej klikam przycisk ADVANCED OPTIONS i w polu Auxiliary Parameters wklejam poniższy parametr:
```
kernel change notify = yes
```
Powoduje on, że jądro systemu TrueNAS za pośrednictwem protokołu inotify poinformuje Sambę o zmianach w katalogach, aby klienci SMB mogli odświeżyć dane na serwerze. Innymi słowy - jeśli w jednym katalogu jest dwóch użytkowników i jeden z nich doda katalog/plik to ten drugi nie będzie musiał odświeżać katalogu, aby zobaczyć tą zmianę, gdyż odświeżenie nastąpi automatycznie. Dodatkowo zaznaczam opcję "[✓] Enable Apple SMB2/3 Protocol Extensions" ponieważ u mnie prócz klientów Windows do plików będą miały też dostęp komputery z macOS. W celu zatwierdzenia zmiam klikam przycisk SAVE .

//FTP

Powstały w 1970 roku FTP jest umierającym protokołem. Generalnie nie powinien być on już używany, szczególnie w scenariuszach, gdzie jest wystawiony na świat ponieważ przesyłane za jego pośrednictwem pliki nie są szyfrowane. U mnie działa on tylko i wyłącznie lokalnie, na potrzeby skanowania do pliku z kserokopiarki także nie stanowi to dużego zagrożenia bezpieczeństwa. 🙃

Z menu wybieram Accounts ➔ Users i klikam przycisk ADD .
Wprowadzam dane:
- w polu "Full Name *" wpisuję Kserokopiarka,
- w polu "Username *" wpisuję Ksero (celowo z dużej litery),
- w polu "Email" wpisuję adres e-mail wykorzystywany przez urządzenie do wysyłania skanów na adres e-mail użytkownika,
- w polach "Password *" oraz "Confim Password *" wpisuję hasło,
- odznaczam opcję "[ ] New Primary Group" i z listy Primary Group wybieram ftp,

- w sekcji "Directories and Permissions" wskazuję katalog oraz ustawiam uprawnienia go niego,
- odznaczam opcję "[ ] Samba Authentication" i zapisuję całość przyciskiem SUBMIT .
Przechodzę w menu na Account ➔ Group i dodaję grupę o nazwie KSERO, a następnie dodaję do niej w/w konto.
Przechodzę na menu Sharing ➔ Windows Shares (SMB) i dodaję uprawnienia do udziału KSERO:
- pole "User" ustawiam na konto Ksero z opcją "[✓] Apply User",
- pole "Group" ustawiam na grupę KSERO z opcję "[✓] Apply Group",
- w sekcji "group@" "Permisions Type *" przestawiam z Advanced na Basic, a pole "Flags *" z No Inherit na Inherit,
- usuwam sekcję "everyone@" przyciskiem DELETE ,
- klikam przycisk ADD ACL ITEM , a następnie pole "Who *" ustawiam na Group, pole "Group *" na builtin_administrators, pole "Permissions *" na Full Control,
- ponownie klikam przycisk ADD ACL ITEM , a następnie pole "Who *" ustawiam na Group i pole "Group *" na ZARZAD i na koniec zaznaczam pole "[✓] Apply permisions recursively" i zapisuję zmiany przyciskiem SAVE .
Na koniec przechodzę na menu Services i przy pozycji FTP uruchamiam usługę oraz zaznaczam "[✓]" w kolumnie "Start Automatically", aby usługa startowała w przypadku restartu systemu.

//Kopie zapasowe

Kiedyś przez lukę w oprogramowaniu Atlassian wpadł mi do sieci firmowej wirus ransomware GrandCrab. Na szczęście rozstrzał jego działania nie objął całej mojej infrastruktury, ale dwa dni miałem wycięte z życia na usuwanie skutków jego działania. Doświadczenie to obnażyło kilka dziur w moich założeniach wykonywania kopii zapasowej i dzięki TrueNAS`owi postanowiłem je wyeliminować.

Moje ustawienie jest takie, że kopię zapasową ważnych plików wykonuję w ramach tego samego serwera, na drugim basenie. Takie ustawienie zabezpiecza mnie przed awarią puli, ale nie samego urządzenia. Idealnie byłoby stosować zasadę 3-2-1-1, nie mniej jednak w ogólnym rozrachunku nowe ustawienie i tak zapewnia mi lepsze bezpieczeństwo względem poprzedniej konfiguracji.

Przechodzę do menu Storage ➔ Pools i w basenie POSEJDON dodaję dwa datasety - _BACKUP i _ZEUS (plus górne drzewo katalogów czyli w moim przypadku _BACKUP, _SMB oraz INSTALKI). W pierwszmy katalogu będę przechowywał 90-dniowe kopie ważnych plików (czyli kopie wykonywane codziennie i przechowywane przez okres 90 dni) oraz 3-dniowe kopie maszyn wirtualnych z serwera Proxmox. Natomiast drugi katalog będzie lustrzanym odbiciem puli ZEUS.
W pierwszej kolejności ustawiam zadania do automatycznego wykonywania migawek systemu plików. W tym celu przechodzę do menu Tasks ➔ Peridic Snapshot Tasks i klikam przycisk ADD . Na liście "Dataset *" wybieram lokalizację, dla której chcę wykonywać migawkę. Wybieram pozycję ZEUS czyli chcę wykonywać migawkę dla całej puli ZEUS. W sekcji "Snapshot Lifetime *" wpisuję 1 DAY czyli chcę przechowywać migawki przez jeden dzień. Na liście "Schedule *" wybieram pozycję "Custom (0 0 * * *)" i w polu "Hours *" zamieniam 0 na */12 gdyż chcę aby system uruchamiał to zadanie co 12 godzin czyli o północy (00:00) oraz w południe (12:00). W lewym dolnym rogu system wyświetla przydatną podpowiedź czasu uruchamiania zadania więc w czasie rzeczywistym możemy weryfikować harmonogram.

Klikam przyciski DONE oraz SUBMIT w celu utworzenia zadania.

Powtarzam w/w kroki, tym razem dla lokalizacji ZEUS\_SMB, w której chcę przechowywań dzienne migawki przez okres 90 dni (ale wpisuję 91), a samo zadanie ma się uruchamiać codziennie w nocy o 03:00.

Po dodaniu zadań będę one miały status PENDING, a po pierwszym i każdym kolejnym pomyślnym wykonaniu zmieni się on na zielony FINISHED lub czerwony ERROR, jeśli wyskoczy błąd, a kliknięcie w niego wyświetli okno logu.

Migawki w TrueNAS dostępne są z poziomu zakładki "Poprzednie wersje" we właściwościach plików/folderów w Windows. dzięki temu możemy w łatwy sposób odzyskać starsze wersje plików/folderów. Super przydatna funkcja. 😎 Punkt 2 powtarzam tyle razy ile zadań migawek potrzebuję dodać.

W menu Storage ➔ Snapshots TrueNAS wyświetla wszystkie migawki dostępne w systemie. Na mojej produkcyjnej konfiguracji trochę tego jest. 😛 Migawki tworzone w TrueNAS`ie są zawsze tylko do odczytu więc użytkownicy oraz wirusy nie są wstanie ich zmodyfikować.
Mam przygotowane zadania migawek, więc pora na zadania replikacji. Przechodzę w menu do Tasks ➔ Replication Tasks i klikam przyciski ADD ➔ ADVANCED REPLICATION CREATION . Nie korzystam z uproszczonego kreatora ponieważ w przygotowywanych zadaniach replikacji chcę wykorzystać wcześniej przygotowane zadania migawek. Podstawowy kreator utworzy nowe zadanie snapshot`a uruchamiane codziennie o północy (00:00) z 14-dniowym okresem przetrzymywania migawek. Mógłbym pójść tą drogą i później podmienić zadanie migawek, a niepotrzebne usunąć, jednak wolę skorzystać z rozbudowanego kreatora i od razu dobrze całość ustawić. Także w polu "Name *" wpisuję _SMB (ponieważ to zadanie będzie replikowało dane produkcyjnych udziałów sieciowych), pole Transport zmieniam z SSH na LOCAL, w polach "Source *" oraz "Destination *" wskazuję lokalizację źródłową i docelową, zaznaczam opcję "[✓] Recursive" ponieważ dataset _SMB zawiera w sobie inne datasety.

Na liście pola "Periodic Snapshot Tasks" wskazuję wcześniej przygotowane zadanie migawki czyli 90-dniowe przechowywanie migawek dzień po dniu. Resztę opcji zostawiam bez zmian (czyli zadanie będzie uruchamiane codzienie o północy (00:00)) ) i na koniec klikam przycisk SUBMIT .

W przypadku korzystania z podstawowego kreatora (przy zaawansowanym tego komunikatu nie ma) w tym momencie wyskoczyłby komunikat informujący, że wykonuję kopię datasetu, który jest szyfrowany więc będzie on zablokowany w lokalizacji docelowej do moment podania klucza deszyfrującego. Jest to kolejna zaleta TrueNAS`a, gdyż dzięki temu możemy np. replikować swoje dane na zewnętrzne serwery i Nasze dane będą bezpieczne. Dlatego też tak ważne jest posiadanie klucza, którego kopię polecałem zrobić podczas konfigurowania basenu. 😉 Podobnie jak w przypadku zadań migawki, tak też i tutaj zadania będą miały status PENDING i po pierwszym, i każdym kolejnym pomyślnym wykonaniu zostanie on zmieniony na zielony FINISHED lub czerwony ERROR, jeśli wyskoczy błąd. Poniższy zrzut ekranu z produkcyjnego serwera. Punkt 3 powtarzam tyle razy ile zadań replikacji potrzebuję dodać.

Dodatkowo ustawiam zadanie Cron w celu wykonywania dodatkowej kopii zapasowej maszyn wirtualnych, które na TrueNAS`a codziennie przesyła serwer Proxmox. Przechodzę w menu na Tasks ➔ Cron Jobs i klikam przycisk ADD . W polu Description wpisuję "PROXMOX BACKUP", w polu "Command *" wklejem poniższe polecenie rsync, które w trybie cichym (czyli z pominięciem komunikatów innych niż błędy) rekurencyjnie, bez kompresji kopiuje całe pliki z odpowiedniego katalogu na basenie ZEUS do odpowiedniego katalogu na basenie POSEJDON i dodatkowo z tego drugiego usuwa pliki starsze niż 4 dni (czyli przechowuję 3 kopie wstecz):

rsync -rqW --inplace --no-compress /mnt/ZEUS/_BACKUP/dump/ /mnt/POSEJDON/_BACKUP/PROXMOX/ && find /mnt/POSEJDON/_BACKUP/PROXMOX/* -mtime +4 -delete

Z listy pola "Run As User *" wybieram (lub wpisuję ręcznie) konto Backup (konto usługowe specjalnie przygotowane pod to zadanie, którym do TrueNAS`a loguje się Proxmox), a z listy "Schedule *" wybieram "Custom (0 0 * * *)" i ustawiam harmonogram aby to zadanie było uruchamiane codziennie o 04:00 nad ranem.

Na koniec klikam przyciski DONE i SAVE w celu zapisania zadania.

Po wielu testach ta konfiguracja cronjob`a działa u mnie najszybciej - łączny czas działania zadania to 1:06:14 dla 595 GB danych. Poniżej zostawiam ku pamięci inne warianty zadania wraz z błędami, jakie mi wyskoczyły i czasami działania:

rsync -avqzz /mnt/ZEUS/_BACKUP/dump/ /mnt/POSEJDON/_BACKUP/PROXMOX/ && find /mnt/POSEJDON/_BACKUP/PROXMOX/* -mtime +7 -exec rm{} \;
--------------
czas trwania od 04:00 do 15:57:41
--------------
rsync: failed to set permissions on "/mnt/POSEJDON/_BACKUP/PROXMOX/.": Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1191) [sender=3.1.3]
Executed CronTask - rsync -avqzz /mnt/ZEUS/_BACKUP/dump/ /mnt/POSEJDON/_BACKUP/PROXMOX/ && find /mnt/POSEJDON/_BACKUP/PROXMOX/* -mtime +7 -exec rm{} \; > /dev/null:
rsync: failed to set permissions on "/mnt/POSEJDON/_BACKUP/PROXMOX/.": Operation not permitted (1) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1191) [sender=3.1.3]

rsync -avq --inplace --no-compress /mnt/ZEUS/_BACKUP/dump/ /mnt/POSEJDON/_BACKUP/PROXMOX/ && find /mnt/POSEJDON/_BACKUP/PROXMOX/* -mtime +7 -exec rm{} \;
--------------
czas trwania od 04:00 do 05:38:38
--------------
rsync: failed to set permissions on "/mnt/POSEJDON/_BACKUP/PROXMOX/.": Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1191) [sender=3.1.3]
Executed CronTask - rsync -avq --inplace --no-compress /mnt/ZEUS/_BACKUP/dump/ /mnt/POSEJDON/_BACKUP/PROXMOX/ && find /mnt/POSEJDON/_BACKUP/PROXMOX/* -mtime +7 -exec rm{} \; > /dev/null:
rsync: failed to set permissions on "/mnt/POSEJDON/_BACKUP/PROXMOX/.": Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1191) [sender=3.1.3]

rsync --inplace --no-compress /mnt/ZEUS/_BACKUP/dump/ /mnt/POSEJDON/_BACKUP/PROXMOX/ && find /mnt/POSEJDON/_BACKUP/PROXMOX/* -mtime +7 -delete
--------------
czas od 04:00 do 04:00:03
--------------
skipping directory .
Executed CronTask - rsync --inplace --no-compress /mnt/ZEUS/_BACKUP/dump/ /mnt/POSEJDON/_BACKUP/PROXMOX/ && find /mnt/POSEJDON/_BACKUP/PROXMOX/* -mtime +7 -delete > /dev/null: skipping directory .

rsync -rq --inplace --no-compress /mnt/ZEUS/_BACKUP/dump/ /mnt/POSEJDON/_BACKUP/PROXMOX/ && find /mnt/POSEJDON/_BACKUP/PROXMOX/* -mtime +7 -delete
--------------
czas od 04:00 do 05:38:34

//Bezpieczeństwo

W systemach TrueNAS, które mam pod swoją opieką dodatkowo ustawiam krótkie i długie testy S.M.A.R.T. dla dysków twardych.

Przechodzę w menu na Tasks ➔ S.M.A.R.T. Tests i klikam przycisk ADD .
Zaznaczam opcję "[✓] All Disks", z listy "Type *" wybieram LONG, w polu Description wpisuję "Długie sprawdzenie dysków", a na liście "Schedule *" wybieram "Custom (0 0 * * *)" i ustawiam harmonogram aby system uruchamiał zadanie o 12:01 pierwszego marca, czerwca, września i grudnia (czyli co 3 miesiące) po czym klikam przyciski DONE i SUBMIT w celu zapisania zadania.
Powtarzam punkt 2 z tą różnicą, że z listy "Type *" wybieram SHORT, w polu Description wpisuję "Krótkie sprawdzenie dysków", a na liście "Schedule *" wybieram "Custom (0 0 * * *)" i ustawiam harmonogram aby system uruchamiał zadanie co tydzień w niedzielę o 12:00 po czym klikam przyciski DONE i SUBMIT w celu zapisania zadania.
Oba zadania przygotowane dzięki którym system będzie na bieżąco monitorował stan wszystkich dysków twardych i informował mnie o ewentualnych problemach.

I tak system sobie działa nieprzerwanie już od ponad 1,5 roku i jestem bardzo zadowolony z efektów tej migracji i konfiguracji (czyli Supermicro i TrueNAS). 😎 Przy zakupie serwera niektórzy mówili mi, że oszalałem, że taki nic nie warty procesor chcę mieć w serwerze. No cóż, może nie jest to Intel® Xeon® czy AMD EPYC™, jednak w moim środowisku sprawuje się wyśmienicie i mam jeszcze spory, naprawdę spory zapas mocy. Jako potwierdzenie moich słów umieszczam poniższy wycinek obciążenia procesora na przestrzeni ostatnich 7 dni - te widoczne "piki" to okres kiedy wykonywane są kopie zapasowe, więc najbardziej interesujące są wartości między nimi, które jak widać szorują po dnie, a z serwera korzysta codziennie ponad 20 osób - część lokalnie, część zdalnie po OpenVPN i Wireguard, z komputerów z Windowsem i macOS. Myślę, że i 100 osób nie zrobiłoby na urządzeniu wrażenia. Także procesory Intel Atom® nadają się jako procesory dla systemów storage`owych, a nie tylko do netbook`ów. 😉

0 komentarzy

Konfiguracja Supermicro TrueNAS CORE