Komplett topologi för Jellyfin-hemmserver med beräkning, lagring och säkerhetskopiering

En komplett Jellyfin-topologi separerar beräkning, aktiva appdata, masslagring för medier och säkerhetskopiering, samtidigt som uppspelningsvägen hålls så kort och lätt att testa som möjligt.

Topologin kan finnas i ett enda chassi eller på flera maskiner; den viktiga skillnaden gäller rollerna, inte antalet lådor. Beräkningsdelen hanterar klienter och kan transkoda, applagringen innehåller Jellyfins fördröjningskänsliga tillstånd, medielagringen tillhandahåller stora filer och säkerhetskopian skyddar det som måste finnas kvar vid ett fel. Dela bara upp rollerna när en uppmätt konflikt uppstår i den gemensamma lösningen, eftersom varje extra värd och nätverkshopp medför ytterligare ett beroende.

Definiera de fyra datarollerna innan du väljer var de ska lagras

Dela in data i fyra roller: källmedia, Jellyfins beständiga tillstånd, återskapningsbara arbetsdata och säkerhetskopior. Källmedia kräver mycket utrymme; beständigt tillstånd omfattar databasen och användar-/serverkonfigurationen; arbetsdata omfattar cache och transkodningsutdata; säkerhetskopior finns bara till för att återställa data i någon av de andra rollerna.

Den här klassificeringen förebygger ett vanligt topologimisstag: att behandla ”lagring” som en enda odifferentierad pool. En hårddiskbaserad lagringsuppsättning med hög kapacitet kan vara utmärkt för videofiler men olämplig för en aktiv metadatadatabas, medan en snabb SSD är användbar för appdata men dyr och onödig för ett stort, sällan använt bibliotek.

ZimaSpaces guide till placering av metadata använder samma rollfördelning: behåll aktiva databaser och cache på snabb lagring, och avgör separat vilka portabla sidofiler eller bilder som ska lagras tillsammans med medierna för att underlätta migrering.

Håll den primära uppspelningsvägen enkel

Den kritiska vägen är klient → nätverk → Jellyfin-beräkning → mediekälla. Om beräkningen och medierna finns på samma maskin är medieöverföringen lokal. Om de är separerade måste beräkningsnoden läsa varje byte som ska levereras eller transkodas via nätverket innan resultatet skickas till klienten.

För en uppdelad beräknings- och lagringslösning ska du dimensionera länken mellan noderna efter den sammanlagda källtrafiken, inte bara klientens slutliga bithastighet. En transkodning kan läsa en källa med hög bithastighet från lagringen och samtidigt skicka en utdata med lägre bithastighet till klienten, så lagringslänken och klientlänken har olika uppgifter.

Håll hantering, experiment och valfria tjänster borta från uppspelningsvägen när de orsakar konkurrens om resurser. Ett andra VLAN, ett separat containernätverk eller helt enkelt schemalagda säkerhetskopieringsfönster kan räcka; ett helt separat fysiskt nätverk är motiverat bara om den delade anslutningen mätbart försämrar tjänsten.

Placera beräkningskapaciteten där mediemotorer och tjänsteisolering är enklast att verifiera

Välj beräkningskapacitet utifrån det uppspelningsarbete den faktiskt ska utföra. Direct Play kräver lite beräkningskapacitet för video, medan inkompatibla klienter, inbränning av undertexter, HDR-konvertering eller begränsningar av bithastigheten för fjärruppspelning kan göra transkodning till den dominerande uppgiften.

Jellyfins guide till val av hårdvara rekommenderar modern hårdvaruacceleration för nya servrar, eftersom videotranskodning i programvara kan vara extremt krävande. Den skiljer också mellan processorns uppgifter och grafikprocessorns mediemotor, vilket är mer användbart än att bedöma en server enbart utifrån antalet processorkärnor.

Om Jellyfin delar värd med fotoindexering, säkerhetskopiering, hemautomation eller AI-arbetsbelastningar bör du ge medietjänsten tydliga gränser för CPU, minne och enhetsåtkomst. En större allt-i-ett-nod som ZimaCube 2 kan användas för en konsoliderad topologi, men topologin behöver fortfarande separata roller för appdata, media och säkerhetskopior, i stället för att behandla ett chassi som en enda felzon.

Featured

ZimaCube 2 personlig moln-NAS för hemmet

ZimaCube2

$799.00 - $2,499.00

Buy Now

Använd SSD för Jellyfins aktiva tillstånd och lagring med hög kapacitet för biblioteket

Placera Jellyfin-databasen, index, cache och andra tillstånd som ofta används på SSD eller lagring med liknande låg fördröjning. Lägg det stora videobiblioteket på HDD, i en NAS-pool eller på annat lagringsmedium som klarar de nödvändiga sekventiella läsningarna.

Jellyfin skiljer uttryckligen mellan dessa arbetsbelastningar: dess lagringsrekommendationer anger att mediefiler främst behöver en sekventiell genomströmning som överstiger deras bithastighet, medan Jellyfins egna filer kräver omfattande slumpmässig åtkomst och därför med fördel placeras på SSD.

Om biblioteket finns på en fjärrplats ska du montera det på ett förutsägbart sätt och dokumentera sökvägen som Jellyfin-tjänsten ser. Återställningen blir mycket enklare när sökvägarna för applikationens tillstånd och media kan återställas oberoende av varandra, i stället för att ingå i en odokumenterad kedja av tillfälliga monteringar.

Gör säkerhetskopian till en separat destination, inte en annan mapp inom samma felområde

En säkerhetskopia som lagras på samma SSD eller i samma diskpool som det aktiva Jellyfin-tillståndet skyddar inte mot fel på den lagringen. Destinationen för säkerhetskopian bör klara det fel du försöker återställa efter, oavsett om det innebär en annan uppsättning diskar, en annan maskin eller en offlinekopia eller kopia på annan plats.

Jellyfins dokumentation om säkerhetskopiering och återställning anger databas, metadata, undertexter och trickplay som separata innehållskategorier för säkerhetskopiering. Bestäm vad som är kritiskt, vad som går att återskapa och hur stor kapacitet destinationen behöver när innehållet växer.

Säkerhetskopiering av media är ett separat policybeslut eftersom ett stort bibliotek kan vara mycket större än applikationens tillstånd. Skydda oersättliga hemmafilmer bättre än media som går att ersätta, och räkna inte paritet eller RAID-redundans som den enda säkerhetskopian om borttagning, skada eller handhavandefel ingår i hotbilden.

Verifiera återställningen först, dela sedan upp eller bygg ut topologin

Kör tre tester innan du bygger ut: en representativ lokal strömning, en representativt framtvingad omkodning och en återställning av Jellyfin-tillståndet till en ren plats eller reservinstans. De här testerna prövar den primära uppspelningsvägen, undantagsvägen för beräkning respektive återställningsvägen.

Dela upp beräkning och lagring först när det finns en anledning att ändra den befintliga lösningen - behov av ett lagringschassi, oberoende underhållsfönster, placering av GPU, begränsningar vad gäller ljud eller temperatur, eller ihållande I/O-belastning. En uppdelad design kan ge bättre isolering mellan rollerna, men då blir även nätverket och fjärrmonteringen en del av varje uppspelning.

Sluta bygga ut när varje roll har en namngiven ansvarig, den kritiska vägen går att mäta, säkerhetskopian klarar det avsedda felet och nästa komponent inte skulle undanröja en känd flaskhals eller förbättra återställningen. Den gränsen gör topologin för en hemmaserver tillräckligt lätt att förstå för att kunna repareras under press.