Avaliação do risco de falha de um servidor doméstico com pool único

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Um único conjunto de armazenamento pode ser a escolha certa para um servidor doméstico, mas os conjuntos de dados e as pastas não criam domínios independentes de falha de hardware. Se o conjunto, o controlador, o anfitrião, a fonte de alimentação ou o sistema de ficheiros ficar indisponível, todos os serviços nele alojados podem parar em simultâneo.

Mapeie o que o conjunto torna indisponível em simultâneo

Enumere as bases de dados das aplicações, os volumes dos contentores, os discos das máquinas virtuais, os ficheiros da família, os conteúdos multimédia, as transferências, os instantâneos e os repositórios de cópias de segurança. Indique quais são dados primários, réplicas, caches ou conteúdos que podem ser reconstruídos.

Identifique as dependências partilhadas para além dos discos: HBA, expansor SATA, ponte USB, placa-mãe, fonte de alimentação, UPS, chaves de encriptação, configuração de arranque e credenciais de administrador. Os conjuntos de dados separados podem limitar as permissões e o crescimento sem sobreviverem a estas falhas partilhadas.

Defina um tempo de recuperação aceitável para cada serviço. Perder uma biblioteca multimédia durante dois dias pode ser tolerável, enquanto perder dados de palavras-passe, fotografias ou domótica pode não ser.

Meça a capacidade e a interdependência das cargas de trabalho

Estime as escritas normais e no pior caso provenientes de bases de dados, transferências, gravações de câmaras, instantâneos, verificações, replicação e retenção de cópias de segurança. Um único registo ou uma árvore de instantâneos descontrolados pode consumir o espaço livre necessário para serviços não relacionados.

Observe a latência durante as verificações, reconstruções, cópias grandes, análises de conteúdos multimédia e janelas de cópia de segurança. Um conjunto saudável pode ainda assim não cumprir os objetivos das aplicações quando as cargas de trabalho sequenciais e aleatórias competem pelas mesmas unidades.

Utilize a tabela para avaliar se o benefício da simplicidade supera o custo do risco partilhado.

Área de decisão Avaliação Limite
Indisponibilidade do conjunto ou do controlador Todos os serviços alojados param Exigir recuperação fora do conjunto
Esgotamento da capacidade As aplicações e os instantâneos competem entre si Utilizar quotas e alertas
Manutenção e reconstrução Impacto partilhado no desempenho Agendar e testar o tempo de inatividade

Separe a proteção do conjunto

Os instantâneos ajudam a recuperar ficheiros eliminados e versões anteriores enquanto o conjunto permanece legível. Os espelhos e a paridade ajudam a manter a disponibilidade após falhas limitadas dos discos. Nenhum deles é uma cópia de segurança independente se todas as cópias dependerem do mesmo conjunto.

Mantenha pelo menos uma cópia recuperável noutro dispositivo ou localização, incluindo exportações de bases de dados consistentes com as aplicações, configuração, chaves de encriptação e uma lista de caminhos de montagem. Teste uma recuperação sem depender do anfitrião original.

Uma lista de verificação de conjuntos de armazenamento para contentores relacionada da ZimaSpace mostra quando os limites da carga de trabalho e da recuperação justificam uma separação.

Uma explicação independente da estratégia de cópia de segurança 3-2-1 descreve por que motivo as cópias em diferentes suportes e localizações reduzem as perdas por causas comuns.

Escolha um único conjunto, separe as funções ou adicione um segundo sistema

Mantenha um único conjunto quando o tempo de inatividade for aceitável, os conjuntos de dados impuserem quotas e permissões, o desempenho se mantiver previsível e as cópias de segurança verificadas ficarem fora do domínio de falha. A simplicidade pode melhorar a recuperação quando o design está documentado.

Separe o armazenamento quando as aplicações com muitas escritas interferirem com os dados em massa, um serviço experimental puder esgotar a capacidade, as cópias de segurança tiverem de permanecer disponíveis durante a reparação do conjunto principal ou diferentes dispositivos exigirem características incompatíveis de resistência e latência.

Não compre um segundo conjunto apenas para duplicar a complexidade. Primeiro, comprove uma recuperação, registe a ordem de recuperação, adicione alertas para o estado de funcionamento e o espaço livre e decida quais os serviços que podem permanecer offline enquanto o conjunto único é reparado.

Guia de Compra

Mais para Ler

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.