Jak bezpiecznie uruchamiać Jellyfin obok innych samodzielnie hostowanych aplikacji

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.

How to Run Jellyfin Alongside Other Self-Hosted Apps Safely - Zima Store Online

Uruchamiaj Jellyfin obok innych aplikacji hostowanych samodzielnie, rozdzielając role danych, chroniąc zasoby odtwarzania i testując hosta przy najbardziej obciążającym nakładającym się obciążeniu.

Współdzielony serwer domowy może niezawodnie obsługiwać multimedia, kopie zapasowe, indeksowanie zdjęć, automatykę domową, programy pobierające, pulpity nawigacyjne i bazy danych, jeśli żadne pojedyncze obciążenie nie wykorzystuje wszystkich zasobów. Zapewnij Jellyfin stabilną ścieżkę danych aplikacji, przechowuj duże zbiory multimediów i tymczasowe pliki transkodowania w osobnych lokalizacjach, zarezerwuj wystarczającą moc CPU, pamięć, przepustowość wejścia-wyjścia pamięci masowej oraz dostęp do sprzętowego dekodowania wideo na potrzeby odtwarzania, a także ogranicz sąsiednie usługi, których skoki obciążenia mogłyby zakłócić działanie domowej sieci.

Uczyń Jellyfin rolą odtwarzania, a nie właścicielem całego hosta

Zacznij od określenia zadań, które muszą pozostać responsywne. Jellyfin odpowiada za indeksowanie multimediów, sesje klientów i wymagane transkodowanie; narzędzie do tworzenia kopii zapasowych odpowiada za kopie odzyskiwania; aplikacja do zdjęć odpowiada za import i analizę obrazów; program pobierający odpowiada za pobieranie; a automatyka domowa może odpowiadać za sterowanie działające przez cały czas. Host może być współdzielony, ale każda usługa powinna mieć jasno określoną rolę i przewidywany okres największego obciążenia.

Przełóż listę aplikacji na nakładające się obciążenia, zamiast liczyć kontenery. Mały pulpit nawigacyjny, który cały dzień pozostaje bezczynny, nie jest porównywalny z ponownym indeksowaniem zdjęć, kompresowaniem kopii zapasowej ani transkodowaniem wideo 4K. Zapisz, które wymagające zadania mogą wystąpić podczas wieczornego oglądania, a które można przenieść poza ten przedział czasowy.

Ten model oparty na rolach zapobiega również temu, by konsolidacja przerodziła się w rozrost zależności. Przewodnik ZimaSpace dotyczący konsolidowania kilku usług domowych na jednym serwerze opiera się na tej samej zasadzie: jedno urządzenie jest skuteczne tylko wtedy, gdy każdy przepływ pracy pozostaje użyteczny i możliwy do odtworzenia, gdy pozostałe są aktywne.

Rozdziel trwały stan, duże zbiory multimediów i nietrwałe dane robocze

Przypisz trwałej konfiguracji Jellyfin, bazie danych, metadanym i stanowi wtyczek określoną lokalizację pamięci masowej, która przetrwa wymianę kontenera. Dużą bibliotekę multimediów przechowuj we własnej, nastawionej na pojemność lokalizacji, a dane wyjściowe transkodowania, pamięci podręczne i pliki tymczasowe traktuj jako osobną rolę danych roboczych, którą można wyczyścić bez niszczenia tożsamości serwera.

Ta sama zasada powinna dotyczyć każdej sąsiedniej usługi przechowującej stan. Praktyczny przewodnik po trwałej pamięci masowej kontenerów wyjaśnia, dlaczego dane, które muszą przetrwać wymianę kontenera, powinny znajdować się poza nietrwałą warstwą kontenera. Udokumentuj nadrzędną ścieżkę danych każdej aplikacji, zanim kilka usług zgromadzi ukryty stan na dysku systemowym.

Nie kieruj niezależnych baz danych, pamięci podręcznych, pobranych plików i danych tymczasowych transkodowania na jeden mały dysk SSD tylko dlatego, że jest szybki. Współdzielona pamięć masowa o niskich opóźnieniach jest użyteczna do momentu, gdy jednoczesne zapisy zaczną powodować opóźnienia lub presję związaną z brakiem miejsca; gdy to nastąpi, rozdziel najbardziej intensywne zapisy albo przenieś nietrwałe dane tymczasowe z dala od krytycznego stanu aplikacji.

Zarezerwuj zapas na odtwarzanie i ogranicz usługi sąsiednie o skokowym obciążeniu

Ustal minimalny poziom zasobów odtwarzania, który musi pozostać dostępny nawet wtedy, gdy host jest zajęty. Może to być jedna sesja bezpośredniego odtwarzania w salonie oraz wymagane transkodowanie sprzętowe albo najbardziej wymagające typowe połączenie, z którego faktycznie korzysta dom. Zmierz użycie CPU, pamięci, GPU lub silnika wideo oraz opóźnienia pamięci masowej, gdy ten poziom jest aktywny.

Kontenery nie stają się nieszkodliwe tylko dlatego, że są odizolowane nazwą. Wskazówki dotyczące limitów zasobów kontenerów podkreślają, że limity CPU i pamięci można wykorzystać, aby uniemożliwić jednemu kontenerowi nieograniczone zużywanie zasobów hosta. Najpierw zastosuj limity do usług o skokowym obciążeniu lub eksperymentalnych, których spowolnienie jest akceptowalne, zamiast bez zastanowienia ograniczać Jellyfin, zanim poznasz jego szczytowe zapotrzebowanie podczas odtwarzania.

Pozostaw również system operacyjny i usługi pamięci masowej poza tą rywalizacją. Konfiguracja, która pozwala obciążeniom aplikacji doprowadzić hosta do użycia pamięci wymiany, zabijania procesów z powodu braku pamięci albo zapełnienia całego woluminu systemowego, nie jest bezpiecznie skonsolidowana, nawet jeśli sam Jellyfin ma nominalną rezerwację CPU.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Jawnie zarządzaj współdzielonymi ścieżkami GPU, sieci i pamięci masowej

Akceleracja sprzętowa korzysta ze współdzielonej ścieżki urządzenia, a nie z abstrakcyjnego ustawienia. Jeśli inny kontener również używa GPU do lokalnej sztucznej inteligencji, przetwarzania obrazów lub pracy z wideo, sprawdź, czy oba obciążenia mogą działać jednocześnie bez kolejkowania lub konfliktów sterownika. Jeśli nie mogą, zaplanuj dodatkowe obciążenie albo przenieś je na inny host, zamiast zakładać, że większa liczba rdzeni CPU rozwiąże problem ograniczenia silnika multimedialnego.

Tak samo traktuj sieć i pamięć masową. Jellyfin może odczytywać źródło o wysokiej przepływności, podczas gdy kopia zapasowa zapisuje duże dane sekwencyjne, a aplikacja do zdjęć wykonuje wiele małych operacji na metadanych. Jeśli multimedia znajdują się w sieciowej pamięci masowej, ścieżka między obliczeniami a pamięcią staje się częścią topologii odtwarzania i musi zostać przetestowana podczas konkurencyjnego transferu.

Unikaj niepotrzebnego współdzielenia dostępu do zapisu. Program pobierający może umieszczać ukończone pliki w lokalizacji przyjmującej, z której Jellyfin odczyta je później; nie potrzebuje dostępu do zapisu konfiguracji Jellyfin. Kontener monitorujący może odczytywać metryki bez przejmowania danych aplikacji. Ograniczone uprawnienia zmniejszają liczbę usług, które mogą uszkodzić lub usunąć stan innej usługi.

Planuj intensywne zadania w tle poza godzinami użytkowania przez domowników

Przenoś elastyczne zadania poza okres największego odtwarzania. Skanowanie całej biblioteki, ponowne indeksowanie zdjęć, kompresowanie kopii zapasowych, sprawdzanie integralności, indeksowanie przez sztuczną inteligencję i duże pobieranie często można uruchamiać w nocy lub po głównym czasie oglądania, bez zmiany końcowego rezultatu.

Planowanie nie zastępuje odpowiedniej wydajności, ale jest narzędziem kształtowania topologii. Jeśli dwa uzasadnione, wymagające zadania nigdy nie muszą działać jednocześnie, rozdzielenie ich w czasie może zachować małą i wydajną konstrukcję opartą na jednym hoście. Jeśli muszą nakładać się każdego dnia, dobierz rozmiar systemu lub rozdziel go z myślą o takim nakładaniu, zamiast polegać na kruchym harmonogramie.

Uwzględnij również zachowanie podczas ponownego uruchamiania i zależności. Jellyfin nie powinien uruchamiać się bez zamontowanej zdalnej lokalizacji multimediów, a awaria eksperymentalnej aplikacji nie powinna blokować ścieżek DNS, pamięci masowej ani uwierzytelniania, których domownicy potrzebują do uzyskania dostępu do serwera multimediów.

Zweryfikuj współdzielonego hosta, odtwarzając warunki największego obciążenia

Zanim uznasz konfigurację za bezpieczną, odtwórz najgorsze typowe nakładanie się obciążeń: odtwórz najbardziej wymagające reprezentatywne multimedia, uruchom kopię zapasową lub zadanie związane ze zdjęciami, które zwykle odbywa się w tym samym czasie, i pozostaw pozostałe usługi działające przez cały czas. Obserwuj stabilność odtwarzania, presję pamięci, opóźnienia pamięci masowej, wolne miejsce, temperatury oraz ścieżkę sprzętowego przetwarzania wideo.

Jeśli test przejdzie pomyślnie z wyraźnym zapasem, przestań dodawać złożoności. Nie potrzebujesz drugiego serwera tylko dlatego, że pierwszy obsługuje kilka aplikacji. Nadal wykonuj pomiary po większych zmianach aplikacji, migracjach pamięci masowej lub dodaniu nowego obciążenia GPU, ponieważ zmienił się wykres wykorzystania zasobów.

Rozdziel role tylko wtedy, gdy ten sam zmierzony konflikt powraca po zaplanowaniu zadań i zastosowaniu rozsądnych limitów: opóźnienia pamięci masowej wielokrotnie zakłócają odtwarzanie, GPU nie może obsłużyć dwóch wymaganych obciążeń, presja pamięci zagraża podstawowym usługom albo jeden eksperymentalny stos wymaga innego okna konserwacyjnego. W takim momencie kolejny host ma określone zadanie, zamiast być rozbudową dla samej rozbudowy.