Kiedy Jellyfin powinien korzystać z osobnego serwera baz danych lub pamięci masowej?

W większości domowych konfiguracji Jellyfin najpierw oddziel serwer przechowujący multimedia od serwera bazy danych: pozostaw produkcyjny stan aplikacji na lokalnym dysku SSD o niskim opóźnieniu, a multimedia przenieś osobno tylko wtedy, gdy wymaga tego pojemność, odzyskiwanie lub lokalizacja.

Ta decyzja dotyczy ról danych, a nie liczby maszyn. Jellyfin obejmuje wrażliwy na opóźnienia stan konfiguracji i bazy danych, pamięci podręczne możliwe do odtworzenia, tymczasowe dane transkodowania oraz duże, głównie sekwencyjne pliki multimedialne. Te klasy danych korzystają z różnych typów pamięci masowej, kopii zapasowych i granic awarii. Drugi serwer jest przydatny tylko wtedy, gdy daje jednej z ról wyraźną przewagę pod względem pojemności lub odzyskiwania, nie zamieniając przy tym dotychczasowej lokalnej zależności w zawodną ścieżkę sieciową.

Oddziel role danych, zanim rozdzielisz je między maszyny

Zacznij od podziału na cztery role: nadrzędny stan aplikacji, dane pochodne, które można odtworzyć, tymczasowe miejsce robocze oraz multimedia. Baza danych, użytkownicy, historia oglądania, playlisty, konfiguracja i wybrane metadane należą do zestawu danych podlegających odzyskiwaniu. Pamięć podręczną i segmenty transkodowania można zwykle odtworzyć. Pliki filmów i muzyki to duże obiekty źródłowe, których strategia ochrony może znacznie różnić się od strategii dla bazy danych aplikacji.

Aktualny przewodnik po konserwacji bazy danych Jellyfin opisuje ujednoliconą bazę danych w wersji 10.11 jako aktywny stan operacyjny, a nie zbędną pamięć podręczną. Dlatego rozmieszczenie na serwerach należy zacząć od określenia, kto jest właścicielem danych i jakie są wymagania dotyczące ich odzyskiwania, zamiast umieszczać każdy katalog o nazwie „Jellyfin” na tym samym udziale.

Najpierw określ te role, a dopiero potem rozmieść je na serwerach. Jeśli obecny serwer ma wystarczająco dużo miejsca na dysku SSD i obejmuje stan aplikacji kopią zapasową, przenoszenie go nie przyniesie żadnych korzyści architektonicznych. Jeśli biblioteka multimediów przekroczyła możliwości lokalnych zatok na dyski, zasilania, chłodzenia lub izolacji awarii, ma konkretny powód, by przenieść tę rolę na NAS lub serwer pamięci masowej, pozostawiając aplikację lokalnie.

Pozostaw produkcyjną bazę danych lokalnie, chyba że zewnętrzna baza danych jest naprawdę obsługiwana

Jellyfin 10.11 przeszło poważną migrację do EF Core, ale nie oznacza to, że osobny serwer PostgreSQL jest domyślną topologią produkcyjną. Istnieją eksperymentalne adaptery PostgreSQL, ale wymagają dodatkowej usługi, danych uwierzytelniających, zgodności wersji, ustalenia kolejności tworzenia kopii zapasowych oraz połączenia sieciowego. W typowym gospodarstwie domowym te koszty przewyższają teoretyczną elegancję dedykowanego serwera baz danych.

Samo eksperymentalne wydanie PostgreSQL ostrzega, że adapter jest przeznaczony do testów, a nie do serwera gotowego do produkcji. Ta granica eksperymentalnej bazy danych to sygnał ostrzegawczy: nie opieraj planu odzyskiwania danych w domu na nieobsługiwanym silniku tylko po to, by topologia wyglądała bardziej profesjonalnie.

W środowisku produkcyjnym lokalnie nie znaczy bez ochrony. Umieść stan aplikacji na niezawodnym dysku SSD, twórz jego kopie zapasowe w innej domenie awarii i sprawdź, czy można je przywrócić przy użyciu zgodnej wersji Jellyfin. Usługę bazy danych wydzielaj tylko wtedy, gdy wybrany silnik jest obsługiwany w Twoim wydaniu, potrafisz zarządzać nim niezależnie, a korzyści z odzyskiwania przewyższają nowe zależności od sieci i wersji.

Przenieś multimedia na osobny host pamięci masowej, gdy wymaga tego pojemność lub układ dysków

Duże zbiory multimediów mają inny wzorzec dostępu. Bezpośrednie odtwarzanie odczytuje głównie duże pliki sekwencyjnie, z szybkością transmisji odpowiadającą odtwarzaniu, dlatego NAS może bez problemu udostępniać multimedia, jeśli sieć, punkt montowania i dyski obsługują łączną liczbę strumieni. Oddzielenie multimediów pozwala też zachować kompaktowy węzeł obliczeniowy, podczas gdy host pamięci masowej można rozbudować o większe pule, większą liczbę kieszeni lub inny układ kopii zapasowych.

W niedawnej konfiguracji domowej z Jellyfin dane Dockera są przechowywane na dysku SSD, a multimedia na HDD, co pokazuje praktyczny podział na aplikacje na SSD i multimedia na HDD. Kompromis jest widoczny na początku odtwarzania: uśpione dyski HDD mogą powodować opóźnienie wybudzania, mimo że przeglądanie pozostaje szybkie dzięki danym aplikacji na SSD.

Wybierz osobny host pamięci masowej, gdy rozbudowa dysków, umiejscowienie ze względu na hałas, redundancja lub obsługa wielu usług uzasadniają dodatkową ścieżkę. Trzymaj multimedia lokalnie, jeśli jedna obudowa spełnia już wymagania dotyczące pojemności i kopii zapasowych. Samo rozdzielanie dodaje obsługę DNS, punktów montowania, uprawnień, awarii sieci i kolejności uruchamiania, nie zmieniając efektu dla użytkownika.

Featured

Osobista chmura i domowy NAS ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Traktuj sieć pamięci masowej jako wymagany element, a nie niewidoczny kabel

Gdy multimedia trafiają na inny host, Jellyfin wymaga dostępnego punktu montowania przed skanowaniem i normalną pracą. Niedostępny NAS może pozostawić pusty punkt montowania, który nadal wygląda jak prawidłowy katalog, a powolna lub niestabilna sieć może zmienić problem z pamięcią masową w opóźnienia podczas odtwarzania. Dlatego topologia wymaga zasady uruchamiania w trybie fail-closed oraz mierzalnego celu przepustowości.

Doświadczenia społeczności pokazują, że udostępnianie multimediów z osobnego NAS-a przez typową sieć domową może działać bardzo dobrze, jeśli sieć ma odpowiednie parametry; w niedawnej dyskusji okazało się, że wielu użytkowników korzysta z takiego rozwiązania bez problemów z odtwarzaniem. Warto pamiętać, że przechowywanie multimediów na osobnym NAS-ie jest możliwe, ale sieć stanowi część ścieżki dostępu do multimediów i nie można zakładać, że nie wpływa na jej działanie.

Sprawdź najwolniejszy element: pulę pamięci masowej, kartę sieciową NAS-a, przełącznik, kartę sieciową serwera, protokół montowania i zapotrzebowanie na jednoczesne odtwarzanie. Zatrzymaj Jellyfin lub wstrzymaj destrukcyjne operacje porządkowania biblioteki, jeśli oczekiwany punkt montowania multimediów jest niedostępny. Drugi host poprawia niezawodność tylko wtedy, gdy jego awaria jest oczywista i ograniczona w skutkach, a nie po cichu powoduje wyświetlenie pustej biblioteki.

Podejmij decyzję o rozdzieleniu na podstawie testów odzyskiwania i rozbudowy

Zanim dodasz kolejny host, przećwicz dwa scenariusze: utratę węzła obliczeniowego Jellyfin i utratę węzła pamięci masowej z multimediami. Przetestowany proces odzyskiwania z priorytetem przywracania pokazuje, dlaczego konfigurację, dane trwałe, wersjonowane definicje usług i kolejność przywracania trzeba sprawdzić łącznie, zamiast zakładać, że wystarczą same pliki kopii zapasowej. Test hosta pamięci masowej powinien też wykazać, że Jellyfin działa w ograniczonym trybie w przewidywalny sposób, bez przepisywania ani usuwania źródłowych danych multimedialnych.

Audyt odzyskiwania danych z pamięci masowej Jellyfin w ZimaSpace opiera się na tej samej zasadzie własności: każda trwała ścieżka powinna mieć określoną rolę, zakres kopii zapasowej i metodę przywracania, zanim dojdzie do awarii.

Pozostań przy jednym hoście, jeśli stan aplikacji, pojemność na multimedia, kopie zapasowe i typowe szczytowe obciążenie wejścia/wyjścia mieszczą się w jego możliwościach z zapasem. Rozdziel przechowywanie multimediów, gdy ograniczeniem staje się pojemność lub cykl życia pamięci masowej. Osobny host bazy danych traktuj jako zaawansowany wyjątek, dopóki dostawca bazy danych nie będzie obsługiwany w środowisku produkcyjnym, a baza nie będzie mogła być niezależnie odzyskana. Zatrzymaj się na takiej topologii, której role potrafisz nazwać i przywrócić — nie dodawaj maksymalnej możliwej liczby maszyn.