Kilka słów od Zima
Dziękujemy, MorgothTheBauglir, za pokazanie, jak daleko może zajść kompaktowa platforma domowego serwera, gdy rozbudowę traktuje się jako narzędzie projektowe, a nie sztywny limit. Od odkrycia ZimaOS na samodzielnie zbudowanym serwerze NAS po przekształcenie ZimaBoard 2 w punkt sterowania systemem pamięci masowej o pojemności przekraczającej 350 TB — Twoja praca odzwierciedla rodzaj praktycznych eksperymentów, które nadają społecznościom self-hostingowym prawdziwą wartość.
Szczególnie doceniamy to, że podzieliłeś się czymś więcej niż tylko końcową wartością pojemności. Udokumentowałeś budowę, wyjaśniłeś wybór sprzętu i kompromisy, odpowiadałeś na pytania innych użytkowników homelabów i otwarcie opisywałeś rozwój systemu, który ostatecznie ujawnił nową granicę wydajności. Ta otwartość daje innym twórcom coś cenniejszego niż prezentacja: prawdziwy projekt, który mogą analizować, kwestionować i na jego podstawie się uczyć.
— Zima
Poznaj MorgothTheBauglir
MorgothTheBauglir to redditowa tożsamość twórcy przedstawionego jako Igor w opublikowanym wcześniej przez ZimaSpace studium przypadku dotyczącym 350 TB. W tym profilu opisano go jako inżyniera sieci z Brazylii, od dawna interesującego się komputerami, architekturą serwerów i zarządzaniem danymi. Jego praca nad homelabem przebiega według tej samej zasady: zachować rozsądne rozmiary konstrukcji, w miarę możliwości ponownie wykorzystywać praktyczny sprzęt i pozostawić wystarczająco dużo miejsca na dalsze eksperymenty.
Jego przygoda z Zima zaczęła się od odkrycia ZimaOS na samodzielnie zbudowanym serwerze NAS, a następnie doprowadziła do przekształcenia ZimaBoard 2 w punkt sterowania systemem pamięci masowej, który rozrósł się do ponad 350 TB. Jego publiczna aktywność na Reddicie nadal odzwierciedla to praktyczne podejście — obejmuje dyskusje o pamięci masowej, kartach HBA, wirtualizacji, sieciach, self-hostingu i ZimaOS. Możesz obserwować MorgothTheBauglir na Reddicie, aby śledzić dalszy rozwój projektów i rozmów poza tą stroną.
Od ZimaOS do dedykowanego ZimaBoard 2
Droga do ZimaBoard 2 zaczęła się od oprogramowania. Zgodnie z pierwotnym studium przypadku ZimaSpace Igor po raz pierwszy zetknął się z ZimaOS za pośrednictwem NAS Compares i zainstalował je na serwerze NAS zbudowanym samodzielnie. Wyróżniała się nie pojedyncza funkcja, lecz połączenie dopracowanego interfejsu, niewielkiego obciążenia zasobów i przystępnego podejścia do self-hostingu, które nie ukrywało przy tym sprzętu znajdującego się pod spodem.
Po dołączeniu do społeczności IceWhale wygrał w konkursie ZimaBoard 2 832, a wkrótce potem przesiadł się na wyższy model ZimaBoard 2 1664. Dzięki temu kolejny eksperyment z pamięcią masową zyskał coś, czego jego wcześniejszy uniwersalny minikomputer nie oferował w równie kompaktowej formie: bezpośrednią ścieżkę rozbudowy PCIe, którą można było potraktować jako punkt wyjścia do znacznie większego systemu.
Przekształcenie jednej ścieżki rozszerzenia PCIe w ponad 350 TB
Projekt, który wyróżnił tę konstrukcję, rozpoczął się jako NAS o pojemności 80 TB i stale się rozrastał. Do stycznia 2026 roku MorgothTheBauglir przebudował go wokół ZimaBoard 2 w 10-calowym mini racku i zwiększył pojemność mieszanego magazynu danych do ponad 350 TB.
Główny łańcuch sprzętowy łączył ZimaBoard 2 z kontrolerem HBA IBM M1210 oraz ekspanderem SAS Adaptec AEC-82885T. Wokół tego zestawu wykorzystano mieszankę dysków HDD i SSD, a także dedykowaną dystrybucję zasilania, profile aluminiowe, rozbudowane okablowanie, chłodzenie i drukowane w 3D uchwyty. Rezultat przypominał mniej gotowy NAS z półki, a bardziej kompaktową obudowę pamięci masowej zaprojektowaną wokół dokładnie dostępnych części, pojemności i przestrzeni.
ZimaSpace opisało architekturę, stos oprogramowania i decyzje dotyczące rozbudowy w studium przypadku pamięci masowej ZimaBoard 2 o pojemności ponad 350 TB. Oryginalny dziennik budowy na Reddicie dodaje szczegóły z poziomu warsztatu: problemy z przepływem powietrza, kieszenie na dyski, części drukowane w 3D, prowadzenie kabli, dystrybucję zasilania oraz drobne modyfikacje niezbędne do urzeczywistnienia praktycznego, gęstego racka.
Rozbudowa jako narzędzie projektowe
W tym projekcie najważniejszą cechą ZimaBoard 2 nie było samo podłączenie większej liczby urządzeń pamięci masowej. Chodziło o to, że gniazdo PCIe mogło bezpośrednio obsługiwać pełnoprawny kontroler HBA. Dzięki temu system mógł przejść od kompaktowej płytki do topologii rozszerzenia SAS bez przekształcania samego hosta w duży, konwencjonalny serwer.
MorgothTheBauglir opisał różnicę w prosty sposób: bezpośrednia obsługa HBA zmienia sposób projektowania kompaktowego, wysokogęstościowego NAS-a. Płytka pozostała mała, podczas gdy otaczająca ją infrastruktura pamięci masowej znacznie się rozrosła.
Chłodzenie, zasilanie i przestrzeń były częścią problemu pamięci masowej
Pojemność była tylko jednym z ograniczeń. Ciepła pogoda, dyski klasy enterprise, ograniczona przestrzeń w domu i gęsta szafa rackowa o szerokości 10 cali oznaczały, że przepływ powietrza i dystrybucję zasilania trzeba było zaprojektować równolegle ze ścieżką danych. Wentylatory, mocowania dysków, rozmieszczenie zasilacza i trasy kabli musiały współgrać w tym samym układzie fizycznym.
To jeden z powodów, dla których projekt jest wartościowy niezależnie od jego nagłówkowej pojemności. Pokazuje, że bardzo duża domowa pamięć masowa rzadko sprowadza się tylko do podłączenia większej liczby dysków; układ mechaniczny, temperatury, zasilanie, okablowanie i łatwość serwisowania stają się częścią architektury.
Dobór oprogramowania z uwzględnieniem ograniczeń
Oprogramowanie pamięci masowej opierało się na tej samej logice stawiania ograniczeń na pierwszym miejscu. Zamiast budować całą pulę wokół wymagającej dużej ilości pamięci topologii ZFS, użył Proxmox VE jako warstwy wirtualizacji, lekkiej maszyny wirtualnej z systemem Windows IoT do obsługi zadań związanych z zarządzaniem pamięcią masową oraz StableBit DrivePool do elastycznego łączenia dysków w pulę i duplikowania folderów na różnych dyskach.
Jego podsumowanie w studium przypadku ZimaSpace było celowo nieskomplikowane: „Nie każdy potrzebuje RAID-u.” Nie chodziło o to, że jeden projekt pamięci masowej jest uniwersalnie lepszy od pozostałych. Chodziło o to, że stos programowy powinien odpowiadać rzeczywistemu sprzętowi, modelowi odzyskiwania danych i obciążeniu, zamiast być wybierany tylko dlatego, że jest najbardziej rozbudowaną dostępną opcją.
Udostępnianie procesu budowy, a nie tylko rezultatu
Publiczny dziennik budowy jest ważną częścią tej historii. MorgothTheBauglir nie opublikował tylko zdjęcia gotowej szafy rackowej — wymienił główne komponenty, zamieścił linki do modeli do druku 3D, opisał problemy z montażem i zaprosił do zadawania pytań dotyczących części oraz napotkanych trudności. W późniejszej dyskusji odpowiadał na pytania o pobór mocy, szybkość sieci, wykorzystanie pamięci masowej, profile aluminiowe, mocowania dysków i przyszłe modernizacje.
Ten sam praktyczny ton pojawia się w jego szerszych dyskusjach na temat self-hostingu. Na swoim profilu Reddit polecał podejście z kontrolerem HBA w trybie IT do rozbudowy SATA, a w późniejszej dyskusji o migracji opisał ZimaOS jako swój wybór ze względu na łatwość obsługi, jednocześnie sugerując wirtualizację Proxmox, gdy priorytetami są migawki, wycofywanie zmian i łatwiejsza migracja.
Rozbudowa do momentu ujawnienia ograniczenia
Historia nie zakończyła się na 350 TB. Gdy system przekroczył 450 TB, MorgothTheBauglir poinformował o wolniejszych transferach sieciowych, którym towarzyszyły długotrwałe obciążenie procesora i przerwania. Konfiguracja ZimaBoard 2 sprawdziła się na etapie 350 TB, ale większe obciążenie ujawniło kolejne wąskie gardło.
Zamiast uznać to za porażkę, zmienił architekturę. Główne zadania obliczeniowe związane z pamięcią masową przeniósł na wydajniejszy host z większą ilością pamięci, szybszą łącznością PCIe i 10GbE, a prace nad szafą rackową i rozbudową nadal ewoluowały. Jego aktualizacja dotycząca 450 TB na Reddicie jest wartościowym uzupełnieniem, ponieważ dokumentuje moment, w którym udana kompaktowa konstrukcja stała się wreszcie na tyle duża, by uzasadniać użycie hosta innej klasy.
Taki rozwój jest cenniejszą lekcją niż twierdzenie o nieograniczonej pojemności. ZimaBoard 2 umożliwił przeprowadzenie niezwykle gęstego eksperymentu z domową pamięcią masową, a eksperyment dostarczył następnie konkretnych informacji o tym, gdzie platforma się sprawdziła, a gdzie obciążenie wykroczyło poza jej możliwości.
Co pozostało niezmienne
Mimo zmian w sprzęcie wciąż widać te same nawyki inżynierskie: korzystanie ze ścieżki rozbudowy, która rozwiązuje aktualny problem, unikanie złożoności, która nie przynosi odpowiednich korzyści, traktowanie konstrukcji mechanicznej jako części architektury systemu oraz udostępnianie wystarczającej ilości szczegółów, aby inni mogli wyciągnąć wnioski z tego rezultatu.
Właśnie dlatego relacja między tą historią użytkownika a technicznym studium przypadku ma znaczenie. Artykuł o pojemności 350 TB wyjaśnia architekturę. Ta strona przedstawia osobę stojącą za projektem, decyzje, które do niego doprowadziły, oraz to, co się wydarzyło, gdy projekt nadal się rozrastał.
Historia wciąż się pisze
Historia MorgothTheBauglir i Zima wciąż się pisze. Projekt przeszedł już od mniejszego serwera NAS DIY do systemu ZimaBoard 2 o pojemności ponad 350 TB, a następnie wkroczył w nową fazę, przekraczając 450 TB. Szafa rackowa, pula pamięci masowej i wybór oprogramowania nadal się zmieniają wraz z pojawianiem się nowych ograniczeń.
Jeśli chcesz poznać techniczne szczegóły konfiguracji ZimaBoard 2, przeczytaj pełne studium przypadku ZimaBoard 2 o pojemności 350 TB. Aby zobaczyć, co buduje, testuje i poleca dalej, obserwuj MorgothTheBauglir na Reddicie.
