Nota od Zima
Dziękujemy, Ted, za udokumentowanie ZimaCube 2 jako systemu, który rozwija się warstwami, a nie gotowego urządzenia. Twoja budowa w ramach Pioneer Program rejestruje udane modernizacje, testy pamięci masowej, migrację Immich oraz elementy, które sprawiały problemy — w tym ścieżkę Thunderbolt, która ostatecznie ustąpiła miejsca rozwiązaniu OCuLink. Publikując pomiary, obejścia problemów, błędy i zmieniające się decyzje sprzętowe w miarę rozwoju projektu, dajesz społeczności coś bardziej użytecznego niż końcową kartę specyfikacji: zapis tego, jak w praktyce rozwija się domowe laboratorium ZimaOS.
— Zima
Poznaj Teda-knighta
Ted-knight dokumentuje jedną z bardziej metodycznych budów ZimaCube 2 w ramach Pioneer Program. Jego budowa ZimaCube 2 nie koncentruje się na jednej finalnej konfiguracji. Zamiast tego projekt jest podzielony na etapy, a każda warstwa jest testowana przed dodaniem kolejnej.
Cel tej budowy jest prosty: stworzyć serwer NAS, któremu już dziś można powierzyć ważne dane, a jednocześnie pozostawić wystarczająco dużo miejsca na self-hosting, multimedia, lokalną sztuczną inteligencję i inne obciążenia w przyszłości. Doprowadziło to Teda do opracowania architektury pamięci masowej, ZFS, btrfs, modernizacji pamięci RAM i dysków NVMe, rozbudowy OCuLink, testów wydajności, integracji z ZimaOS, migracji Immich oraz coraz bardziej szczegółowej mapy drogowej dalszego rozwoju maszyny.
Zaczął od ZimaCube 2 Standard: systemu z procesorem Intel Core i3-1215U, 8 GB pamięci DDR5 i systemowym dyskiem NVMe o pojemności 256 GB. Oryginalna konfiguracja nie pozostała niezmieniona na długo.
Budowanie podstaw pamięci masowej przed dodawaniem kolejnych usług
Pierwszym priorytetem Teda nie było zapełnienie serwera aplikacjami. Chodziło o ustalenie, gdzie powinny znajdować się poszczególne rodzaje danych.
Powstały system korzysta z kilku warstw pamięci masowej, z których każda ma celowo inne zadanie. ZimaOS pozostaje na własnym dysku Kingston NVMe o pojemności 256 GB. Crucial P510 2 TB NVMe stał się warstwą Arctic-Storage opartą na btrfs, przeznaczoną na dane aplikacji, obrazy Dockera, bazy danych i inne aktywne obciążenia. Cztery dyski NVMe 2 TB tworzą pulę glacier ZFS RAIDZ1 o użytecznej pojemności około 5,5 TB. Później cztery dyski Seagate IronWolf 4 TB utworzyły pulę btrfs RAID5 o pojemności 12 TB, przeznaczoną na multimedia i rzadziej używane dane.
Ta architektura w mniejszym stopniu polega na tym, aby każdy dysk działał tak samo, a w większym na dopasowaniu pamięci masowej do obciążenia. Bazy danych intensywnie korzystające z losowych operacji wejścia-wyjścia powinny znajdować się na szybkim P510. Większe obciążenia sekwencyjne i dane, które korzystają z sum kontrolnych oraz nadmiarowości ZFS, mogą trafić do glacier. Duże zbiory multimediów można przenieść do warstwy IronWolf o większej pojemności.
Gdy Thunderbolt 4 nie zadziałał, zmieniła się architektura
Jednym z najbardziej wartościowych elementów projektu teda jest to, że nieudane eksperymenty pozostały w dokumentacji.
Pierwotny plan zakładał podłączenie obudowy Aoostar TB4S-OC na cztery dyski NVMe do ZimaCube 2 przez Thunderbolt 4. Ted przetestował różne kable 40 Gb/s, oba porty Thunderbolt, zasilanie zewnętrzne oraz działanie bazowego jądra, ale obudowa nadal nie nawiązywała stabilnego połączenia PCIe.
Śledztwo ostatecznie wskazało na interakcję między konfiguracją Thunderbolt w ZimaOS a kontrolerem ASMedia ASM2462PDX znajdującym się w obudowie. Zamiast nadal forsować pierwotny plan, ted zmienił architekturę.
Adapter PCIe x4 do OCuLink trafił do Slotu 1. Obudowa Aoostar została przełączona z Thunderbolt na bezpośrednie połączenie OCuLink. Wszystkie cztery dyski NVMe pojawiły się przy pierwszym uruchomieniu, bez problemów z tunelowaniem i autoryzacją, które zablokowały konfigurację Thunderbolt.
Zmiana wpłynęła również na późniejsze plany. Slot 1 jest teraz zajęty przez pamięć masową, a dwa porty Thunderbolt pozostają dostępne do przyszłych eksperymentów, takich jak bezpośrednie połączenia sieciowe lub inna konfiguracja z eGPU. Nieudane połączenie nie stało się po prostu przypisem w dokumentacji rozwiązywania problemów — zmieniło plan rozwoju całej maszyny.
Testowanie pamięci masowej zamiast zakładania, która warstwa była szybsza
Gdy pamięć masowa była już gotowa, ted wykonał jej pomiary.
Jego prace w ramach fazy 1.5 wykorzystują fio aby porównać pulę ZFS RAIDZ1 glacier z Arctic-Storage, zamiast traktować „NVMe” jako jedną kategorię wydajności. Zimny test wykazał, że glacier osiąga 1 726 MB/s przy sekwencyjnym zapisie i 2 591 MB/s przy sekwencyjnym odczycie, podczas gdy jednon dyskowy poziom Arctic był znacznie lepszy w losowych operacjach wejścia-wyjścia, osiągając w pierwotnej lokalizacji 205 588 IOPS przy losowym odczycie 4K.
Ciekawszy rezultat pojawił się, gdy do gry wkroczył ZFS ARC. Powtarzane odczyty z glacier mogły być obsługiwane z pamięci RAM zamiast ponownie odczytywać dane z dysków NVMe. Przy wcześniejszej konfiguracji z 16 GB pamięci rozgrzane losowe odczyty osiągały około 83 929 IOPS zamiast 14 781 IOPS w stanie zimnym.
To odkrycie wpłynęło później na kolejną decyzję sprzętową. Ted rozbudował maszynę do 32 GB za pomocą dwóch modułów DDR5 o pojemności 16 GB, przechodząc z pamięci jednokanałowej na dwukanałową. Po modernizacji rozgrzane losowe odczyty ARC wzrosły ponownie do 126 816 IOPS — to zmierzona poprawa o 51 procent względem wcześniejszego wyniku.
Testy podważyły również pierwotne umiejscowienie Crucial P510. W 7. zatoce modelu Standard przepustowość sekwencyjna była ograniczona przez mostek. Ted przeniósł dysk do wbudowanego gniazda M.2 i zmierzył wzrost sekwencyjnego odczytu z 874 MB/s do 1 677 MB/s, podczas gdy wydajność losowego odczytu 4K wzrosła z 205 588 do 403 078 IOPS.
Wniosek nie sprowadzał się po prostu do tego, że jedno gniazdo było szybsze. Pomiary zmieniły sposób przypisania obciążeń oraz pokazały, które ulepszenia rzeczywiście były warte wykonania.
Uruchamianie ZFS obok ZimaOS
Ta konstrukcja pokazuje również interesującą granicę między tym, czym ZimaOS zarządza natywnie, a tym, co doświadczony użytkownik może dodać pod spodem.
Ted celowo używa btrfs dla Arctic-Storage i puli IronWolf, ponieważ te woluminy naturalnie integrują się z ZimaOS. Pula glacier jest inna. Została utworzona z wiersza poleceń jako ZFS RAIDZ1, zapewniając Tedowi datasety ZFS, sumy kontrolne, buforowanie ARC, migawki oraz model pamięci lepiej dopasowany do niektórych planowanych obciążeń.
Ta elastyczność ma jednak pewną wadę: pule ZFS utworzone z wiersza poleceń nie pojawiają się w interfejsie jako natywne woluminy pamięci ZimaOS.
Obejście zastosowane przez Teda jest proste i praktyczne. Udostępnia on poszczególne datasety ZFS za pomocą dowiązań symbolicznych w katalogu /DATA, umożliwiając wyświetlanie ścieżek takich jak dokumenty glacier, multimedia, kopie zapasowe i pamięć maszyn wirtualnych w aplikacji Pliki ZimaOS, podczas gdy bazowa pula pozostaje zarządzana przez ZFS.
Odkrył kolejny problem z widocznością pamięci. ZimaOS może zgłaszać dużą część pamięci RAM jako „używaną”, gdy ZFS ARC zapełnia w przeciwnym razie bezczynną pamięć. Patrząc na btop oraz statystyki ARC opowiadają bardziej użyteczną historię: pamięć podręczna zużywa pamięć, ponieważ jest ona dostępna, a ZFS może ją zwolnić, gdy aplikacje będą potrzebować więcej.
To właśnie taki rodzaj opinii ma znaczenie w przypadku projektu Pioneer. Ted nie tylko pokazuje, co działa w ZimaOS; dokumentuje również, w którym miejscu zaawansowana konfiguracja pamięci masowej dociera do granic obecnego interfejsu oraz co robi, gdy do nich dotrze.
Przenoszenie istniejącej biblioteki Immich bez utraty jej historii
Architektura pamięci masowej nabiera znacznie większego znaczenia, gdy zaczynają trafiać do niej dane, których nie można zastąpić.
Dla Teda tym testem była aplikacja Immich. Miał już instancję Immich działającą na starszym, samodzielnie zbudowanym serwerze ZimaOS i chciał przenieść ją na ZimaCube 2 bez rozpoczynania od zera.
Migracja obejmowała 14 505 zdjęć i 925 nagrań wideo — łącznie 134 GiB. Jednak ważne dane nie ograniczały się do plików obrazów. Albumy, osoby, rozpoznawanie twarzy, wspomnienia, udostępnione łącza i inne metadane były przechowywane w PostgreSQL.
Korzystając z aplikacji Pliki w ZimaOS przez sieć LAN, Ted skopiował oba /DATA/Gallery/immich oraz kompletny /DATA/AppData/immich katalog, w tym pgdata. Źródłowa instancja Immich została zatrzymana przed kopiowaniem, aby zachować spójność danych PostgreSQL.
Po migracji konto, albumy, informacje o twarzach, wspomnienia i biblioteka pozostały nienaruszone, bez zgłoszonej utraty danych. Ted zweryfikował następnie bezpośrednio bazę danych PostgreSQL, zamiast zakładać, że pomyślne logowanie oznacza zachowanie wszystkich danych.
Jeśli planujesz podobną migrację, nasz przewodnik migracji Immich na ZimaCube 2 omawia to samo kluczowe rozróżnienie: samo przeniesienie biblioteki multimediów nie wystarczy — bazę danych również trzeba przenieść.
Od migracji obejmującej 134 GiB do 725 GiB samodzielnie hostowanych zdjęć i nagrań wideo
Etap z Immich nie zakończył się wraz z pomyślną migracją ze starego serwera.
To, co zaczęło się od przenoszenia istniejącej biblioteki ZimaOS, przerodziło się w znacznie większe odejście od korzystania z iCloud jako głównego miejsca przechowywania zdjęć i nagrań wideo Teda. Jego iPhone rozpoczął przesyłanie oryginalnej biblioteki iCloud do aplikacji Immich działającej na ZimaCube 2.
Pod koniec tej fazy serwer zawierał 63 665 plików o łącznym rozmiarze 725 GiB: 55 604 zdjęcia i 8 061 nagrań wideo. Sam transfer z iCloud odpowiadał za około 655 GB, z czego większość zajmowały materiały wideo 4K.
Celem nie było udawanie, że każdą usługę chmurową Apple można zastąpić. Ted nadal wskazał kopie zapasowe urządzeń, wiadomości i inne dane specyficzne dla iOS, które warto przechowywać w mniejszym planie iCloud. Zmiana była bardziej ukierunkowana: przenieść dużą bibliotekę zdjęć i filmów do pamięci masowej, nad którą ma kontrolę, zachowując usługi chmurowe, które wciąż są przydatne.
Ta decyzja stworzyła również nowe zobowiązanie. Samodzielnie hostowana biblioteka zdjęć staje się bezpieczniejsza od kopii w chmurze dopiero wtedy, gdy jest właściwie tworzona jej kopia zapasowa. Dlatego notatki Teda dotyczące migracji obejmują również drugą kopię w TrueNAS, przygotowując grunt pod szerszą fazę tworzenia kopii zapasowych w modelu 3-2-1, która wciąż pozostaje w planach.
Budowanie wokół tego, co ułatwia ZimaOS — i mierzenie reszty
Ted celowo wybrał ZimaOS. Po latach korzystania z Synology i długim okresie używania CasaOS chciał prostszego, skoncentrowanego na Dockerze modelu aplikacji, zachowując jednocześnie dostęp do systemu bazowego, gdy projekt wymagał czegoś bardziej zaawansowanego.
Kilka elementów projektu korzysta z tej równowagi. Wbudowane narzędzie migracji AppData przeniosło dane aplikacji Dockera z dysku systemowego na Arctic-Storage bez konieczności ponownego konfigurowania każdej aplikacji. Aplikacja Files zapewniła przepływ pracy w sieci LAN wykorzystany podczas migracji Immich. Natywne narzędzia, w tym fio, zpool, zfs, nvme, a także iostat umożliwiły pomiar i zarządzanie architekturą pamięci masowej poniżej warstwy graficznej.
Inne elementy pokazują, gdzie doświadczenie wciąż jest mniej zintegrowane. Pamięć masowa ZFS utworzona za pomocą CLI wymaga obejścia z dowiązaniem symbolicznym. ARC sprawia, że standardową ilość pamięci RAM łatwo źle zinterpretować. Zachowanie Thunderbolt wymusiło przeprojektowanie sprzętu.
Te obserwacje sprawiają, że projekt jest cenniejszy niż prezentacja, w której każdy eksperyment działa za pierwszym razem. Ted dokumentuje granicę między prostym doświadczeniem z ZimaOS a bardziej zaawansowaną pracą w domowym laboratorium, która zaczyna się, gdy ktoś postanawia ją przekroczyć.
Co już zbudowano — a co wciąż pozostaje w planach
Tytuł repozytorium Teda opisuje miejsce docelowe jako skromny serwer NAS wspomagany przez sztuczną inteligencję, ale projekt jest celowo budowany etapami.
Podstawy już istnieją. Magazynowanie warstwowe działa. Lodowcowa pula ZFS RAIDZ1 jest aktywna. Arctic-Storage został przeniesiony do wbudowanego gniazda M.2. Pamięć osiągnęła 32 GB w trybie dwukanałowym. Istnieje pula IronWolf RAID5. Testy wydajności pamięci masowej zostały ukończone. Migracja Immich i szersza konsolidacja zdjęć z iCloud również dobiegły końca.
Warstwa multimediów wciąż się rozwija. Pula IronWolf została utworzona z myślą o przechowywaniu dużych zbiorów multimediów, natomiast Jellyfin i szerszy stos *arr nadal należą do bieżących prac fazy 2.
Warstwy AI są jeszcze przed nami. Obecny plan ted przewiduje testy Ollama działającej wyłącznie na CPU w etapie 4a, następnie ścieżkę eGPU z RTX 4090 w etapie 4b oraz wyszukiwanie semantyczne w lokalnej pamięci masowej w etapie 5.
To rozróżnienie jest ważne. ZimaCube 2 jest już przygotowywany do lokalnej sztucznej inteligencji poprzez rozmieszczenie pamięci masowej, pojemność pamięci, decyzje dotyczące PCIe i planowanie obciążeń, ale projekt nie osiągnął jeszcze etapu, na którym można przedstawiać wnioskowanie GPU jako ukończony rezultat.
Dla czytelników, którzy już teraz badają ten przyszły kierunek, nasz przewodnik po lokalnej sztucznej inteligencji na ZimaCube 2 pokazuje, jak Ollama, pamięć, rozszerzenia PCIe i późniejsze ulepszenia GPU mogą wpisać się w podobny plan rozwoju domowego laboratorium.
Konfiguracja, która zmienia się wraz z dowodami
Najbardziej konsekwentnym wzorcem w projekcie ted nie jest ZFS, Immich ani żaden konkretny element sprzętu. Jest nim gotowość do zmiany decyzji po zmierzeniu tego, co rzeczywiście się wydarzyło.
Obudowa Thunderbolt nie działała, dlatego ścieżkę pamięci masowej przeniesiono na OCuLink.
P510 nie mógł wykorzystać swojego potencjału w 7. zatoce, więc przeniesiono go do wbudowanego gniazda M.2.
ZFS ARC działał lepiej, niż oczekiwano, dlatego pamięć stała się ulepszeniem wydajności, a nie tylko zwiększeniem pojemności.
Migracja 134 GiB danych Immich przebiegła bez utraty bazy danych, więc eksperyment rozszerzono o przeniesienie kolejnych setek gigabajtów z iCloud.
Każdy etap pozostawia po sobie pomiary, polecenia, błędy i zaktualizowane założenia na potrzeby kolejnego etapu. Dzięki temu repozytorium jest przydatne nawet dla osób, które nigdy nie zbudują dokładnie takiej samej konfiguracji pamięci masowej.
Historia wciąż się pisze
Historia ted-knight i Zima wciąż się pisze. ZimaCube 2 rozpoczął jako model Standard z 8 GB pamięci, a już stał się wielopoziomowym systemem pamięci masowej z btrfs, ZFS RAIDZ1, rozszerzeniem NVMe przez OCuLink, 32 GB pamięci dwukanałowej, archiwum IronWolf RAID5 oraz samodzielnie hostowaną biblioteką Immich zawierającą setki gigabajtów prywatnych multimediów.
Kolejne etapy celowo pozostają otwarte: Jellyfin i stos multimedialny, lepsze procedury tworzenia kopii zapasowych, lokalna sztuczna inteligencja działająca wyłącznie na CPU, przyszła ścieżka GPU, wyszukiwanie semantyczne oraz wszystko, co pomiary zmuszą ted do ponownego rozważenia po drodze.
Jeśli chcesz śledzić, jak te etapy przechodzą z planów do rzeczywistych rezultatów, śledź na GitHubie trwającą budowę ZimaCube 2 autorstwa ted-knight.
