Utilize um anfitrião separado quando a capacidade de armazenamento, a manutenção ou o isolamento de falhas tiverem de escalar de forma independente do processamento do Plex; não mova a base de dados apenas por uma questão de organização.
Os conteúdos multimédia em grande volume são naturalmente separáveis, pois necessitam de capacidade e débito sequencial, enquanto a base de dados e os metadados do Plex são dados de estado sensíveis à latência. Um segundo anfitrião também introduz acessibilidade pela rede, permissões e uma ordem de recuperação. A arquitetura justifica-se quando essas dependências adicionais resolvem uma limitação medida que não pode ser tratada de forma simples num único servidor.
Separe primeiro os conteúdos multimédia em grande volume dos dados de estado sensíveis à latência
Os ficheiros multimédia podem residir num armazenamento NAS, enquanto o processamento do Plex permanece noutro local, desde que o caminho de rede disponha de débito sustentado suficiente e montagens fiáveis. Esta divisão apresenta menos riscos do que o armazenamento remoto dos dados da aplicação.
O armazenamento deve seguir escolhas de armazenamento específicas para a carga de trabalho, o que favorece manter os conteúdos multimédia sequenciais de elevada capacidade separados dos dados de estado que dependem de acesso aleatório de baixa latência.
Meça o débito dos conteúdos multimédia durante a reprodução de maior intensidade e durante uma transferência de grande dimensão. Se o caminho multimédia em rede permanecer estável e com margem suficiente, a divisão terá justificado a sua complexidade.
Por predefinição, mantenha a base de dados do Plex próxima do processamento
O armazenamento remoto da base de dados ou dos metadados acrescenta latência de rede e outro ponto de falha a cada acesso aos dados de estado. Esta pode ser uma má troca quando o SSD local não é o fator limitante.
A latência da base de dados pode variar devido à sensibilidade do desempenho à latência do armazenamento, o que constitui uma razão para testar o caminho dos dados de estado antes de o colocar atrás de um sistema de ficheiros de rede.
Mantenha os dados da aplicação no anfitrião que processa o Plex, salvo se um requisito medido compensar os custos de latência e recuperação. A topologia de centro multimédia doméstico com NAS pode continuar a centralizar os conteúdos multimédia em grande volume sem centralizar todos os ficheiros de estado.
Utilize um anfitrião separado quando os domínios de falha tiverem de ser diferentes
Um anfitrião de armazenamento pode ser mantido ou expandido de forma independente, e um anfitrião de processamento pode ser substituído sem mover o conjunto de armazenamento multimédia. Essa separação é valiosa quando cada função tem um procedimento de recuperação claro.
A divisão de funções só é útil quando as dependências entre serviços são suficientemente explícitas para reiniciar ou substituir um anfitrião sem criar uma propriedade oculta dos dados de estado através da rede.
Documente a ordem de arranque, as dependências das montagens e o comportamento da reprodução local quando o anfitrião de armazenamento estiver indisponível. Se a recuperação exigir alterações manuais aos caminhos, simplifique a divisão.
Não confunda um anfitrião separado com uma cópia de segurança
Mover os conteúdos multimédia para um NAS não cria uma segunda cópia. O armazenamento remoto pode continuar a ser a única cópia e, por isso, permanecer um único ponto de perda de dados.
O desenho da cópia de segurança deve separar o armazenamento de proteção do armazenamento primário; por isso, crie uma cópia de recuperação independente ou fora do dispositivo, além da divisão da topologia.
Teste a restauração do estado do Plex e de pelo menos um caminho multimédia representativo sem depender do anfitrião de armazenamento ativo. A arquitetura só é resiliente quando a separação do armazenamento e a cópia de segurança estão ambas explicitamente definidas.
Configuração de NAS e Servidor
Mais para Ler

Como a análise e a automatização semelhantes à IA alteram as necessidades de armazenamento e computação do Jellyfin
A automatização e a análise de IA associada acrescentam digitalizações, dados derivados, processamento de CPU/GPU, cache, espaço temporário e agendamento em segundo plano, para...

Como integrar o Jellyfin numa rede de um apartamento pequeno ou arrendado
Crie uma rede Jellyfin adequada para arrendamento, com endereçamento local estável, cablagem mínima, hardware silencioso, acesso remoto compatível com CGNAT e alterações reversíveis.

Quantos utilizadores e tarefas em segundo plano deverá suportar um único servidor Jellyfin?
Trate os utilizadores do Jellyfin e as tarefas em segundo plano como uma única capacidade de carga partilhada; a capacidade esgota-se quando a latência...

