Uma configuração do Jellyfin com armazenamento duplo, metadados em SSD e dados em HDD

Uma configuração robusta do Jellyfin com dois tipos de armazenamento coloca os dados da aplicação sensíveis à latência e os metadados ativos num SSD, mantendo os ficheiros multimédia volumosos em HDDs de grande capacidade e baixo custo.

O objetivo não é que todos os ficheiros do Jellyfin precisem do dispositivo mais rápido. As bases de dados, os índices de imagens, as miniaturas e as caches geram muitas pesquisas pequenas; os filmes e a música são sobretudo lidos em grandes sequências; o espaço temporário para transcodificação é temporário e pode implicar muitas escritas. Atribua a cada função um nível de armazenamento cuja latência, capacidade, resistência, cópia de segurança e comportamento de recuperação correspondam ao fluxo de trabalho e, depois, teste a configuração combinada durante as análises e a reprodução.

Atribua funções diferentes ao SSD e ao HDD

Utilize o SSD para o sistema operativo ou para os dados das aplicações em contentores, a base de dados do Jellyfin, a configuração, os metadados ativos, os índices e a cache. Mantenha os ficheiros de filmes, episódios, música e vídeos caseiros no conjunto de HDD. Considere o armazenamento de transcodificação como uma decisão à parte: pode usar um SSD quando há espaço e a resistência são suficientes, ou outra via rápida de armazenamento temporário quando as transcodificações simultâneas geram muitas escritas.

Um guia prático sobre cargas de trabalho em SSD para homelab estabelece a mesma distinção de funções: as bases de dados e as aplicações ativas beneficiam da memória flash de baixa latência, enquanto os níveis de armazenamento de grande capacidade não precisam de desempenho ao nível de NVMe só por existir armazenamento mais rápido.

Não separe os ficheiros apenas pelo nome da pasta. Alguns «metadados» são dados oficiais ou selecionados manualmente e merecem cópias de segurança, enquanto a cache de imagens pode ser regenerada. A configuração torna-se recuperável quando sabe que conteúdos do SSD têm de ser repostos após uma falha e quais podem ser reconstruídos a partir dos ficheiros multimédia.

Coloque os dados da aplicação de acesso aleatório num SSD

A navegação no Jellyfin, as pesquisas, as atualizações do estado do utilizador, a localização de imagens, as transações da base de dados e muitas operações da biblioteca são sensíveis à latência, ao contrário da leitura sequencial de um filme. Ao transferir do HDD para o SSD este conjunto de dados de trabalho da aplicação, elimina-se o custo das pesquisas mecânicas e reduz-se a interferência entre as pequenas operações de E/S dos metadados e as grandes leituras de ficheiros multimédia.

Um guia atual sobre o desempenho do Jellyfin identifica o armazenamento lento de metadados como causa direta da lentidão na navegação pela biblioteca, porque os dados da aplicação implicam muitas pequenas leituras. A análise do ZimaSpace sobre Jellyfin em SSD versus HDD chega à mesma distinção de funções: a latência dos dados da aplicação beneficia de um SSD, enquanto os ficheiros multimédia volumosos podem continuar num HDD.

Dimensione o SSD com base no crescimento real dos dados das aplicações, acrescido de uma margem, e não na capacidade dos conteúdos multimédia. Reserve espaço livre para o crescimento da base de dados, metadados, imagens de pré-visualização ou ilustrações, se estiverem ativados, cópias de segurança criadas localmente antes da exportação e a maior carga de trabalho temporária que pretenda alojar nesse espaço. Um SSD pequeno e cheio é pior do que um SSD maior, mesmo que modesto, com uma margem estável de espaço livre.

Mantenha os conteúdos multimédia volumosos no HDD, salvo se outro requisito alterar a decisão

O HDD continua a ser uma opção sensata para conteúdos multimédia, porque a transmissão de um filme consiste normalmente numa leitura sequencial contínua, cuja taxa de bits é muito inferior à velocidade de transferência de um disco moderno em bom estado. O custo por unidade de capacidade, as baías para discos, a redundância e as cópias de segurança pesam muitas vezes mais na decisão do que a velocidade da interface SSD, no que diz respeito ao próprio ficheiro multimédia.

Um operador de NAS com Jellyfin descreve recentemente uma disposição com contentores no SSD e conteúdos multimédia no HDD, que permite navegar rapidamente a partir do SSD, mas implica uma espera de 15–20 segundos quando os discos rígidos em suspensão têm de ser ativados para iniciar a reprodução. Isto ilustra a verdadeira compensação: não a largura de banda sustentada, mas a latência da primeira leitura e o comportamento da gestão de energia.

Se o arranque imediato for mais importante do que a poupança obtida ao parar os discos, mantenha os discos de multimédia ativos durante os períodos normais de visualização ou ajuste a respetiva política de energia. Se o funcionamento silencioso e de baixo consumo for mais importante, aceite o atraso até ao início da reprodução. Transferir todos os conteúdos multimédia para SSD apenas para evitar uma pausa durante o arranque de um disco é, normalmente, uma decisão sobre o custo da capacidade, não um requisito do Jellyfin.

Featured

NAS de nuvem pessoal doméstica ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Proteja o SSD como uma unidade de recuperação pequena, mas essencial

O SSD pode conter muito menos dados do que o conjunto de HDD, mas guardar o estado que faz com que o servidor pareça a mesma instância do Jellyfin. Uma falha no SSD com os dados da aplicação pode apagar utilizadores, histórico de visualização, configuração, listas de reprodução e metadados organizados, mesmo que todos os filmes permaneçam intactos. Faça cópias de segurança frequentes desta pequena unidade de recuperação e mantenha-as fora do domínio de falha do SSD.

Uma disposição em duas camadas funciona melhor quando os dados de estado das aplicações residentes no SSD têm um processo de restauro próprio e testado. Um processo de teste de restauro privilegia a validação da aplicação num destino isolado, em vez de tratar os ficheiros copiados como prova. Preserve o estado específico do servidor em cópias de segurança versionadas no SSD e mantenha apenas os ficheiros auxiliares de multimédia selecionados quando estes facilitarem a migração ou a reconstrução.

Não espelhe o SSD apenas para evitar cópias de segurança. A redundância pode reduzir o tempo de inatividade após a falha de um dispositivo, mas não permite recuperar de uma atualização mal sucedida, de uma eliminação acidental, de danos na base de dados ou da perda do anfitrião. Mantenha pontos de recuperação com versões e teste uma restauração numa instância Jellyfin isolada.

Evite que as tarefas com E/S mista anulem a separação do armazenamento

Esta configuração é mais útil quando a E/S do estado das aplicações permanece no SSD e as transferências de grandes ficheiros multimédia permanecem no HDD. As cópias de segurança, os downloads, a descompactação, a análise de conteúdos multimédia ou a escrita de transcodificações podem anular essa separação se forem todos direcionados para o mesmo dispositivo ao mesmo tempo. Decida onde escreve cada tarefa recorrente e, se necessário, agende as tarefas mais exigentes fora do período de maior atividade de visualização.

Um homelab com armazenamento duplo deve ser testado com o mesmo tipo de carga de trabalho mista de E/S aleatória que torna visíveis as filas de armazenamento. Os valores exatos das medições de desempenho não se aplicam diretamente ao Jellyfin, mas o mecanismo é o mesmo: as operações simultâneas de pequena dimensão na base de dados reagem à latência de forma muito diferente de uma leitura sequencial longa de conteúdos multimédia.

Meça o carregamento do painel, as pesquisas, o início da reprodução, a duração das análises, o enfileiramento no HDD e a latência do SSD durante uma sobreposição normal. Se a navegação continuar rápida, mas a reprodução ficar à espera apenas de discos em repouso, a configuração está a funcionar como previsto. Se ambos os níveis abrandarem durante uma cópia de segurança ou importação, resolva o estrangulamento partilhado no controlador, na rede ou no agendamento antes de comprar memória flash mais rápida.

Expanda o nível que efetivamente atinge o seu limite

Aumente a capacidade do SSD quando o estado da aplicação Jellyfin, os metadados ou o espaço temporário se aproximarem do limite de espaço livre, ou quando outra base de dados alojada no mesmo servidor precisar do mesmo nível de baixa latência. Aumente a capacidade do HDD quando a retenção de conteúdos multimédia atingir o limite do conjunto. Atualize a rede apenas quando o percurso separado dos conteúdos multimédia se tornar o estrangulamento medido.

Um guia recente sobre níveis de armazenamento para servidores multimédia faz a mesma distinção entre cargas de trabalho: a capacidade do SSD deve servir os dados do servidor sensíveis à latência, enquanto a capacidade do HDD deve servir grandes bibliotecas multimédia. Expanda o nível cujo limite de capacidade ou latência medido estiver efetivamente a ser atingido.

Pare quando o SSD tiver capacidade para os dados ativos das aplicações, com margem para recuperação, o conjunto de HDD suportar a procura normal de conteúdos multimédia, as cópias de segurança protegerem adequadamente ambas as funções e a maior sobreposição normal se mantiver dentro dos limites de latência. A configuração de armazenamento duplo é bem-sucedida quando cada nível tem uma função clara — não quando todas as ligações disponíveis têm uma unidade ligada.