Konfiguracja Jellyfin z dwoma nośnikami: metadane na SSD, dane na HDD

Eva Wong jest redaktorką techniczną i rezydentką majsterkowania w ZimaSpace. Jest geekiem od zawsze, z pasją do domowych laboratoriów i oprogramowania open source, a jej specjalnością jest przekładanie złożonych zagadnień technicznych na przystępne, praktyczne poradniki. Eva wierzy, że samodzielne hostowanie powinno sprawiać radość, a nie onieśmielać. Dzięki swoim samouczkom pomaga społeczności oswoić konfigurację sprzętu, od budowy pierwszego serwera NAS po opanowanie kontenerów Docker.

Wydajna konfiguracja Jellyfin z dwoma rodzajami pamięci masowej przechowuje wrażliwy na opóźnienia stan aplikacji i aktywne metadane na SSD, a duże pliki multimedialne na pojemnych dyskach HDD.

Nie chodzi o to, że każdy plik Jellyfin wymaga najszybszego nośnika. Bazy danych, indeksy grafik, miniatury i pamięci podręczne generują wiele niewielkich operacji wyszukiwania; filmy i muzyka to głównie duże, sekwencyjne odczyty; przestrzeń tymczasowa na transkodowanie jest ulotna i może wymagać wielu zapisów. Przypisz każdej roli warstwę pamięci masowej o opóźnieniach, pojemności, wytrzymałości, możliwościach tworzenia kopii zapasowych i odzyskiwania odpowiednich do danego zastosowania, a następnie przetestuj całą konfigurację podczas skanowania biblioteki i odtwarzania.

Przypisz SSD i HDD różne zadania

Użyj SSD do systemu operacyjnego lub danych aplikacji w kontenerach, bazy danych Jellyfin, konfiguracji, aktywnych metadanych, indeksów i pamięci podręcznej. Duże pliki filmów, odcinków, muzyki i domowych nagrań wideo przechowuj w puli HDD. Przestrzeń na transkodowanie potraktuj jako osobną kwestię: może znajdować się na SSD, jeśli pojemność i wytrzymałość nośnika są wystarczające, albo w innej szybkiej przestrzeni tymczasowej, gdy równoczesne transkodowanie generuje dużo zapisów.

Praktyczny poradnik dotyczący obciążenia SSD w domowym laboratorium uwzględnia ten sam podział ról: bazy danych i aktywne aplikacje korzystają z niskich opóźnień pamięci flash, natomiast pojemne warstwy pamięci masowej nie potrzebują wydajności klasy NVMe tylko dlatego, że dostępne są szybsze nośniki.

Nie dziel danych wyłącznie według nazw folderów. Niektóre „metadane” są kluczowe lub ręcznie uzupełnione i wymagają kopii zapasowej, a pamięć podręczną obrazów można odtworzyć. Konfigurację łatwiej przywrócić, gdy wiesz, które dane z SSD trzeba odzyskać po awarii, a które można odbudować na podstawie plików multimedialnych.

Umieść aplikację i jej dane o losowym dostępie na SSD

Przeglądanie i wyszukiwanie w Jellyfin, aktualizowanie stanu użytkownika, wyszukiwanie grafik, transakcje bazy danych oraz wiele operacji na bibliotece są wrażliwe na opóźnienia, w przeciwieństwie do sekwencyjnego odczytu filmu. Przeniesienie roboczego zestawu danych aplikacji z HDD na SSD eliminuje opóźnienia związane z mechanicznym pozycjonowaniem głowicy i ogranicza zakłócenia między niewielkimi operacjami wejścia-wyjścia metadanych a dużymi odczytami plików multimedialnych.

Aktualny poradnik dotyczący wydajności Jellyfin wskazuje wolne przechowywanie metadanych jako bezpośrednią przyczynę powolnego przeglądania biblioteki, ponieważ dane aplikacji wymagają wielu niewielkich odczytów. Analiza ZimaSpace Jellyfin na SSD i HDD wskazuje na ten sam podział ról: mniejsze opóźnienia danych aplikacji zapewnia SSD, natomiast duże pliki multimedialne mogą pozostać na HDD.

Dobierz pojemność SSD na podstawie rzeczywistego wzrostu ilości danych aplikacji i zapasu miejsca, a nie pojemności biblioteki multimediów. Pozostaw wolne miejsce na rozrost bazy danych, metadane, podglądy trickplay lub grafiki, jeśli są włączone, lokalne kopie zapasowe tworzone przed eksportem oraz największe tymczasowe obciążenie, które celowo umieszczasz na tym dysku. Mały, zapełniony SSD sprawdzi się gorzej niż większy, umiarkowanie wykorzystany SSD z odpowiednim zapasem wolnego miejsca.

Przechowuj multimedia na HDD, chyba że inne wymagania zmieniają tę decyzję

Dysk HDD pozostaje rozsądnym wyborem do przechowywania multimediów, ponieważ odtwarzanie filmu zwykle polega na ciągłym, sekwencyjnym odczycie, a jego przepływność jest znacznie niższa niż przepustowość sprawnego, nowoczesnego dysku. Pojemność w przeliczeniu na cenę, zatoki na dyski, nadmiarowość i kopie zapasowe często mają większe znaczenie niż szybkość interfejsu SSD, jeśli chodzi o sam plik z multimediami.

Niedawno użytkownik Jellyfin na NAS-ie opisał układ z kontenerami na SSD i multimediami na HDD, w którym przeglądanie zawartości z dysku SSD jest szybkie, ale rozpoczęcie odtwarzania wymaga odczekania 15–20 sekund, gdy trzeba wybudzić uśpione dyski twarde. To pokazuje, na czym polega kompromis: nie chodzi o stałą przepustowość, lecz o opóźnienie przy pierwszym odczycie i działanie funkcji zarządzania energią.

Jeśli szybki start jest ważniejszy niż oszczędności wynikające z zatrzymywania dysków, pozostaw dyski z multimediami aktywne podczas typowych godzin oglądania albo dostosuj ich ustawienia zasilania. Jeśli ważniejsza jest cicha praca przy niskim poborze energii, zaakceptuj opóźnienie przy pierwszym odtwarzaniu, gdy dysk się wybudza. Przenoszenie wszystkich multimediów na SSD tylko po to, by uniknąć krótkiej przerwy na rozruch dysku, to zwykle decyzja dotycząca kosztu pojemności, a nie wymóg Jellyfin.

Chroń dysk SSD jako niewielki, ale kluczowy zestaw danych potrzebnych do odzyskiwania

Dysk SSD może zawierać znacznie mniej danych niż pula dysków HDD, a mimo to przechowywać stan, dzięki któremu serwer sprawia wrażenie tej samej instancji Jellyfin. Awaria dysku SSD z danymi aplikacji może usunąć użytkowników, historię oglądania, konfigurację, listy odtwarzania i wyselekcjonowane metadane, nawet jeśli wszystkie filmy pozostaną nienaruszone. Często twórz kopie zapasowe tego niewielkiego zestawu danych potrzebnych do odzyskiwania i przechowuj je poza domeną awarii dysku SSD.

Dwupoziomowy układ sprawdza się najlepiej, gdy stan aplikacji przechowywany na dysku SSD ma własną, przetestowaną ścieżkę odtwarzania. Procedura testowania odtwarzania kopii zapasowych kładzie nacisk na sprawdzenie aplikacji w odizolowanym środowisku, zamiast traktować skopiowane pliki jako dowód. Przechowuj specyficzne dla serwera dane w wersjonowanych kopiach zapasowych na dysku SSD, a wybrane pliki towarzyszące multimediom zachowuj tylko wtedy, gdy ułatwiają migrację lub odtworzenie systemu.

Nie twórz kopii lustrzanej SSD tylko po to, by uniknąć kopii zapasowych. Nadmiarowość może skrócić przestój po awarii jednego urządzenia, ale nie pozwoli odzyskać danych po nieudanej aktualizacji, przypadkowym usunięciu, uszkodzeniu bazy danych ani utracie hosta. Zachowuj wersjonowane punkty odzyskiwania i przetestuj przywracanie danych w odizolowanej instancji Jellyfin.

Nie pozwól, by zadania generujące mieszane operacje wejścia-wyjścia zniweczyły podział pamięci masowej

Taki układ najlepiej sprawdza się, gdy operacje wejścia-wyjścia związane z danymi aplikacji odbywają się na SSD, a duże transfery multimediów — na HDD. Kopie zapasowe, pobieranie, rozpakowywanie, analiza multimediów lub zapis transkodowanych danych mogą zniweczyć ten podział, jeśli wszystkie te zadania jednocześnie korzystają z jednego urządzenia. Zdecyduj, gdzie zapisuje każde regularnie wykonywane zadanie, i w razie potrzeby zaplanuj intensywne operacje poza godzinami największego obciążenia związanego z oglądaniem.

Domowe laboratorium z dwoma rodzajami pamięci masowej należy testować przy użyciu tego samego rodzaju mieszanego obciążenia losowymi operacjami wejścia-wyjścia, które uwidacznia kolejki operacji pamięci masowej. Dokładne wyniki testów porównawczych nie przekładają się bezpośrednio na Jellyfin, ale sama zasada już tak: równoległe, niewielkie operacje na bazie danych reagują na opóźnienia zupełnie inaczej niż długi, sekwencyjny odczyt multimediów.

Podczas jednego typowego nakładania się zadań zmierz czas ładowania pulpitu, wyszukiwania, rozpoczęcia odtwarzania, skanowania, kolejki HDD i opóźnienia SSD. Jeśli przeglądanie pozostaje szybkie, ale odtwarzanie opóźniają tylko wybudzające się dyski, konfiguracja działa zgodnie z założeniami. Jeśli obie warstwy zwalniają podczas tworzenia kopii zapasowej lub importowania, zanim kupisz szybszą pamięć flash, usuń wąskie gardło we współdzielonym kontrolerze, sieci lub harmonogramie zadań.

Rozbuduj warstwę, która faktycznie osiąga swój limit

Zwiększ pojemność SSD, gdy dane aplikacji Jellyfin, metadane lub przestrzeń robocza zbliżają się do progu wolnego miejsca albo gdy inna baza danych działająca na tym samym hoście potrzebuje tej samej warstwy o niskich opóźnieniach. Zwiększ pojemność HDD, gdy biblioteka multimediów osiągnie limit puli. Ulepsz sieć tylko wtedy, gdy wydzielona ścieżka multimediów staje się zmierzonym wąskim gardłem.

Niedawny przewodnik po warstwach pamięci masowej w serwerze multimediów wskazuje na to samo rozróżnienie: pojemność SSD powinna służyć danym serwera wrażliwym na opóźnienia, a pojemność HDD — dużym bibliotekom multimediów. Rozbuduj tę warstwę, której zmierzony limit pojemności lub opóźnień jest faktycznie osiągany.

Zatrzymaj rozbudowę, gdy SSD pomieści aktywny zestaw roboczy aplikacji i zapas miejsca na odzyskiwanie, pula HDD obsłuży typowe zapotrzebowanie na media, kopie zapasowe odpowiednio zabezpieczą oba zastosowania, a maksymalne typowe nakładanie się zadań mieści się w docelowych wartościach opóźnień. Konfiguracja z dwoma rodzajami pamięci masowej jest udana, gdy każdy z nich ma jasno określone zadanie, a nie wtedy, gdy do każdego dostępnego złącza podłączony jest dysk.

Konfiguracja NAS-a i serwera

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.