Quando deve o Jellyfin usar uma base de dados ou um anfitrião de armazenamento separado?

Na maioria das casas que utilizam o Jellyfin, separe primeiro o servidor de armazenamento multimédia, antes do servidor de base de dados: mantenha o estado da aplicação de produção num SSD local de baixa latência e distribua os ficheiros multimédia em massa apenas quando a capacidade, a recuperação ou a localização o exigirem.

Esta decisão diz respeito às funções dos dados, não ao número de máquinas. O Jellyfin tem configuração e estado da base de dados sensíveis à latência, caches que podem ser recriadas, dados temporários de transcodificação e ficheiros multimédia de grande dimensão, maioritariamente sequenciais. Estas classes beneficiam de armazenamento, cópias de segurança e limites de falha diferentes. Um segundo servidor só é útil se proporcionar a uma das funções uma vantagem mais clara em termos de capacidade ou recuperação, sem transformar uma dependência anteriormente local num percurso de rede frágil.

Separe as funções dos dados antes de separar as máquinas

Comece por quatro funções: estado autoritativo da aplicação, dados derivados que podem ser recriados, espaço de trabalho temporário e multimédia. A base de dados, os utilizadores, o estado de visualização, as listas de reprodução, a configuração e os metadados selecionados pertencem à unidade de recuperação. Normalmente, é possível recriar a cache e os segmentos de transcodificação. Os ficheiros de filmes e música são objetos de origem de grande dimensão cuja estratégia de proteção pode ser completamente diferente da da base de dados da aplicação.

Um guia de manutenção da base de dados do Jellyfin atualizado descreve a base de dados unificada da versão 10.11 como estado operacional ativo, e não como uma cache descartável. Por isso, a localização do servidor deve começar pelos requisitos de propriedade e recuperação, em vez de colocar todas as pastas com o nome «Jellyfin» na mesma partilha.

Defina essas funções antes de definir os servidores. Se o servidor atual tiver espaço SSD suficiente e cobertura de cópias de segurança para o estado da aplicação, não há qualquer vantagem arquitetónica em movê-lo. Se a biblioteca multimédia já excedeu a capacidade das baias locais, da alimentação, do arrefecimento ou do isolamento de falhas, há uma razão concreta para mover essa função para um NAS ou servidor de armazenamento, mantendo a aplicação local.

Mantenha a base de dados de produção local, a menos que a utilização de uma base de dados externa seja realmente suportada

O Jellyfin 10.11 concluiu uma migração significativa para o EF Core, mas isso não faz de um servidor PostgreSQL separado a topologia de produção predefinida. Existem adaptadores experimentais para PostgreSQL, mas acrescentam outro serviço, credenciais, compatibilidade entre versões, ordem de cópia de segurança e dependência da rede. Para uma casa comum, esses custos superam a elegância teórica de um servidor de base de dados dedicado.

A própria versão experimental do PostgreSQL avisa que o adaptador se destina a avaliação, não a um servidor pronto para produção. Esse limite da base de dados experimental é um sinal de paragem: não conceba um plano de recuperação doméstico em torno de um sistema não suportado apenas para tornar a topologia mais semelhante à de uma empresa.

Em produção, manter os dados localmente não significa deixá-los desprotegidos. Coloque o estado da aplicação num SSD fiável, faça cópias de segurança para outro domínio de falha e confirme que a cópia é restaurada com a versão correspondente do Jellyfin. Separe o serviço de base de dados apenas quando o sistema escolhido for suportado pela sua versão, puder ser administrado de forma independente e o benefício para a recuperação compensar as novas dependências de rede e de versões.

Transfira os conteúdos multimédia para um anfitrião de armazenamento separado quando a capacidade ou a configuração dos discos o exigir

Os conteúdos multimédia em massa têm um padrão de acesso diferente. A Reprodução Direta lê sobretudo ficheiros grandes de forma sequencial, à taxa de bits de reprodução, pelo que um NAS pode servir os conteúdos sem problemas quando a rede, o ponto de montagem e os discos suportam o conjunto de transmissões. Separar os conteúdos multimédia também permite manter compacto o nó de computação, enquanto o anfitrião de armazenamento pode crescer com conjuntos maiores, mais compartimentos ou uma estratégia de cópias de segurança diferente.

Uma configuração doméstica recente com o Jellyfin mantém os dados do Docker num SSD, enquanto os conteúdos multimédia ficam num HDD, mostrando uma prática separação entre aplicações em SSD e conteúdos multimédia em HDD. A desvantagem nota-se no início da reprodução: os HDD em suspensão podem acrescentar latência ao reativarem, apesar de a navegação continuar rápida graças aos dados das aplicações guardados no SSD.

Escolha um anfitrião de armazenamento separado quando a expansão dos discos, a localização acústica, a redundância ou o armazenamento para vários serviços justificarem o percurso adicional. Mantenha os conteúdos multimédia localmente quando um único chassis já satisfaz as necessidades de capacidade e cópias de segurança. Separar por separar acrescenta trabalho com DNS, pontos de montagem, permissões, falhas de rede e ordem de arranque, sem alterar o resultado para o utilizador.

Featured

NAS de nuvem pessoal doméstica ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Trate a rede de armazenamento como uma dependência obrigatória, não como um cabo invisível

Quando os conteúdos multimédia passam para outro anfitrião, o Jellyfin depende de um ponto de montagem disponível antes das análises e do funcionamento normal. A ausência do NAS pode deixar um ponto de montagem vazio que continua a parecer um diretório válido, enquanto uma rede lenta ou instável pode transformar um problema de armazenamento em atrasos na reprodução. A topologia precisa, por isso, de uma regra de arranque que falhe em segurança e de um objetivo de largura de banda mensurável.

A experiência da comunidade mostra que disponibilizar ficheiros multimédia a partir de um NAS separado através de uma rede doméstica normal pode funcionar bem quando a rede tem capacidade adequada; uma discussão recente revelou que muitos utilizadores fazem exatamente isso sem problemas de reprodução. A lição útil do armazenamento de multimédia num NAS separado é que esta configuração de rede é viável, mas tem de ser tratada como parte do percurso dos ficheiros multimédia, e não como algo que não tem custos.

Valide o segmento mais lento: o conjunto de armazenamento, a placa de rede do NAS, o switch, a placa de rede do servidor, o protocolo de montagem e a procura simultânea de transmissões. Pare o Jellyfin ou suspenda operações de manutenção destrutivas da biblioteca quando a montagem prevista do suporte multimédia não estiver disponível. Um segundo anfitrião só melhora a fiabilidade quando a sua falha é evidente e contida, em vez de ser silenciosamente convertida numa biblioteca vazia.

Use testes de recuperação e expansão para decidir se deve separar os componentes

Antes de acrescentar outro anfitrião, ensaie dois cenários: a perda do nó de computação do Jellyfin e a perda do nó de armazenamento de multimédia. Um fluxo de trabalho de recuperação que dá prioridade ao restauro, devidamente testado, mostra por que motivo a configuração, os dados persistentes, as definições versionadas dos serviços e a ordem de restauro têm de ser validados em conjunto, em vez de se presumirem garantidos pela existência de ficheiros de cópia de segurança. O teste do anfitrião de armazenamento deve também fazer com que o Jellyfin funcione de forma degradada previsível, sem reescrever nem eliminar o estado autoritativo dos ficheiros multimédia.

A auditoria de recuperação do armazenamento do Jellyfin da ZimaSpace aplica o mesmo teste de responsabilidade: cada caminho persistente deve ter uma função identificada, um âmbito de cópia de segurança e um método de restauro definidos antes de ocorrer um incidente.

Mantenha tudo num único anfitrião quando o estado da aplicação, a capacidade para multimédia, as cópias de segurança e a I/O nos picos normais couberem confortavelmente. Separe o armazenamento de multimédia quando a capacidade ou o ciclo de vida do armazenamento se tornarem o fator limitante. Trate um anfitrião de base de dados separado como uma exceção avançada até que o fornecedor da base de dados seja suportado em produção e possa ser recuperado de forma independente. O ponto de paragem é uma topologia cujas funções consegue identificar e restaurar - não o número máximo de caixas que pode acrescentar.