Kiedy warto rozdzielić usługi Jellyfin na wielu hostach?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

When Should You Split Jellyfin Services Across Multiple Hosts? - Zima Store Online

Rozdziel usługi związane z Jellyfinem między wiele hostów, gdy jedna maszyna nie jest już w stanie spełnić jasno określonych wymagań dotyczących zasobów, niezawodności lub lokalizacji — a nie tylko dlatego, że diagram z wieloma hostami wygląda schludniej. Dopóki zmierzony wąski gardło lub granica awarii nie uzasadnią użycia kolejnej maszyny, utrzymuj aplikację Jellyfin i jej aktywną bazę danych w prostej konfiguracji.

W większości domów pierwsze przydatne podziały obejmują oddzielenie pamięci masowej od obliczeń, odwrotnego proxy lub VPN-u od hosta multimediów, intensywnych zadań pobierania i indeksowania od odtwarzania albo wyspecjalizowanego transkodowania od głównego serwera. Każdy podział dodaje zależności sieciowe, spójność ścieżek, dane uwierzytelniające, monitoring i pracę związaną z kopiami zapasowymi, dlatego wprowadzaj jedno rozdzielenie naraz i sprawdzaj, czy pierwotny problem poprawia się przy takim samym obciążeniu domowym, zanim dodasz kolejny host.

Udowodnij, że jeden host ma rzeczywisty problem z rywalizacją o zasoby

Zmierz objaw podczas obciążenia, które ma znaczenie: odtwarzanie zacina się, gdy działają zadania kopii zapasowych, skanowanie przeciąża pamięć masową, zadania GPU pozbawiają transkodowanie zasobów albo konserwacja powoduje niedopuszczalnie długą niedostępność. Jeśli host ma wystarczający zapas mocy procesora, pamięci, operacji wejścia-wyjścia i przepustowości sieci, dodanie maszyn samo w sobie prawdopodobnie nie poprawi niezawodności.

Korzystaj z powtarzalnych obserwacji, takich jak wysycenie procesora, kolejki GPU, opóźnienia pamięci masowej czy utrzymująca się przepustowość sieci. Serwer domowy, który pokazuje tylko krótkotrwałe skoki obciążenia, ale normalnie kończy odtwarzanie, nie ma jeszcze problemu ze skalowaniem.

To samo podejście, koncentrujące się najpierw na granicach, jest przydatne przy ocenie współdzielonych obciążeń serwera domowego: oddziel rzeczywiste ograniczenie współdzielonego zasobu od maszyny, która tylko wygląda na zajętą na pulpicie monitoringu.

Rozdziel pamięć masową, gdy pojemność i topologia dysków wymagają innego miejsca

Przenieś pamięć masową multimediów na serwer NAS lub host skoncentrowany na pamięci masowej, gdy liczba dysków, układ RAID, hałas, lokalizacja fizyczna albo potrzeby związane z kopiami zapasowymi przestają pasować do urządzenia obliczeniowego Jellyfin. Bazę danych i pamięć podręczną Jellyfin pozostaw na niezawodnej pamięci masowej o niskich opóźnieniach, blisko aplikacji, chyba że masz sprawdzony powód, by przenieść je zdalnie.

Po rozdzieleniu przetestuj ścieżkę multimediów podczas jednego odtwarzania Direct Play z wysoką przepływnością, jednego skanowania biblioteki i równoczesnego transferu plików. Jeśli nowa pamięć masowa dostępna przez sieć powoduje zacięcia, których wcześniej lokalnie nie było, podział przeniósł wąskie gardło zamiast je rozwiązać.

Zachowaj stabilne ścieżki montowania i kolejność uruchamiania, aby Jellyfin nie rozpoczynał czyszczenia ani skanowania, gdy zdalny udział multimediów jest niedostępny. Traktuj dostępność montowania jako zależność, która musi działać, zanim rozpocznie się konserwacja biblioteki.

Rozdziel wyspecjalizowane transkodowanie tylko wtedy, gdy usuwa udowodnione ograniczenie obliczeniowe

Jeśli główny host Jellyfin nie zapewnia potrzebnego sprzętowego przyspieszania, zdalne transkodowanie może być wyspecjalizowanym podziałem — ale jest bardziej złożone niż zwykłe dodanie drugiego serwera. Współdzielone ścieżki, przepustowość sieci, uprawnienia i obsługa awarii stają się częścią odtwarzania.

Dokumentacja Jellyfin opisuje ścieżkę zdalnego sprzętowego przyspieszania z użyciem rffmpeg do delegowania transkodowania na inną maszynę z systemem Linux, przy wymaganiach dotyczących SSH i współdzielonej pamięci masowej. Korzystaj z tej opcji tylko wtedy, gdy korzyść obliczeniowa jest warta dodatkowych zależności.

Zweryfikuj podział przy użyciu dokładnie tych przypadków dotyczących kodeka, napisów, HDR i przepływności, które spowodowały pierwotne przeciążenie. Jeśli obciążenie procesora głównego serwera spadnie, ale opóźnienia sieci lub współdzielonej pamięci masowej zaczną powodować buforowanie, zdalny serwer roboczy nie zapewnił rzeczywistej poprawy.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Oddziel usługi brzegowe sieci, gdy ich granica awarii powinna być inna

Odwrotne proxy, brama VPN lub węzeł zdalnego dostępu mogą działać na innym hoście, gdy chcesz aktualizować albo ponownie uruchamiać Jellyfin bez ingerowania w brzeg sieci lub gdy brzeg wymaga innej polityki udostępniania. Utrzymuj ścieżkę na tyle prostą, aby lokalne odtwarzanie domowe nie zależało od niepotrzebnych komponentów wystawionych do internetu.

Projekty VPN typu site-to-site i routowane wymagają jawnego skonfigurowania podsieci i tras; Tailscale na przykład opisuje wymagania i ograniczenia routingu site-to-site dla routingu między wieloma podsieciami. Zaplanuj te trasy, zanim użyjesz drugiego hosta jako przezroczystej zależności.

Przetestuj osobno dostęp lokalny, dostęp zdalny i awarię hosta brzegowego. Klienci lokalni powinni zachować zamierzoną lokalną ścieżkę, gdy maszyna zdalnego dostępu jest wyłączona, chyba że celowo zaprojektowano inaczej.

Przestań dzielić usługi, gdy obsługa staje się trudniejsza niż samo wąskie gardło

Każdy host dodaje konieczność instalowania poprawek, kontroli stanu, obsługi danych uwierzytelniających, logów, kopii zapasowych i nowego przeskoku sieciowego. Prowadź prostą mapę zależności pokazującą, która usługa musi uruchomić się pierwsza i co powinno się stać, gdy zniknie host pamięci masowej, transkodowania, DNS-u lub proxy.

Po każdym rozdzieleniu uruchom pierwotne obciążenie z godzin największego ruchu i porównaj stabilność odtwarzania, użycie CPU/GPU, opóźnienia pamięci masowej oraz zachowanie podczas odzyskiwania z bazową konfiguracją jednego hosta. Zachowaj rozdzielenie tylko wtedy, gdy zmierzony problem się poprawia, a odzyskiwanie pozostaje zrozumiałe.

Jeśli nie potrafisz wyjaśnić, który host przechowuje bazę danych, które ścieżki są nadrzędne, jak przywraca się kopie zapasowe i co dzieje się po wyłączeniu jednego węzła, wstrzymaj dalsze rozdzielanie. Prostsze wdrożenie Jellyfin na jednym hoście z większym zapasem zasobów jest często bezpieczniejsze niż niedostatecznie udokumentowany stos wielohostowy.