RAID Z1: Um arranjo de disco de paridade simples

Índice:

• RAID Z1: o que é e como a paridade protege os dados
• Quantos discos são necessários e qual capacidade fica disponível?
• O que acontece quando um disco falha no RAIDZ1?
• RAID Z1 afeta o desempenho do servidor ou storage?
• Quando o RAIDZ1 faz sentido e quando evitar
• Por que RAIDZ1 não substitui um backup?
• Como decidir entre RAIDZ1, RAIDZ2 e espelhos

Um disco falha, o servidor continua funcionando e, à primeira vista, parece que o problema pode esperar. Em um ambiente com dados importantes, essa espera é justamente o momento mais delicado: o arranjo passa a operar sem redundância e uma segunda falha pode transformar uma ocorrência controlável em indisponibilidade ou perda de dados.

O RAID Z1 é uma configuração de armazenamento do ZFS que usa paridade distribuída para tolerar a falha de um disco dentro do mesmo grupo. Ele pode ser útil em servidores, storages domésticos e ambientes empresariais de menor porte, mas exige atenção à capacidade aproveitável, ao processo de recuperação, ao desempenho e ao fato de que redundância não substitui backup.

RAID Z1: o que é e como a paridade protege os dados

RAID Z1 é um nível de RAID baseado no sistema de arquivos ZFS que distribui dados e uma informação de paridade entre vários discos. A paridade permite reconstruir o conteúdo de um disco que falhou usando os dados restantes. Como há apenas uma camada de paridade, o arranjo suporta a perda de um disco por grupo sem perder o acesso aos dados, desde que não exista outro problema grave durante a recuperação.

Em vez de gravar um arquivo inteiro em um único disco, o ZFS divide os blocos em partes e distribui essas partes pelo vdev, que é o grupo de dispositivos usado pelo pool. Para cada conjunto de dados, o sistema calcula informações matemáticas de paridade. Se um disco deixar de responder, os blocos ausentes podem ser recalculados a partir dos blocos disponíveis e da paridade.

A paridade não é uma cópia simples de cada arquivo. Ela é uma informação calculada. Em termos práticos, isso reduz o espaço consumido pela redundância em comparação com um espelhamento completo, mas também exige trabalho adicional para gravar e reconstruir dados. A proteção depende de todos os discos envolvidos no vdev; não é possível remover um disco de um RAIDZ1 e esperar que o restante continue funcionando como um volume independente.

O ZFS acrescenta uma característica importante: mantém somas de verificação dos dados e dos metadados. Assim, não verifica apenas se um disco está presente, mas também se o bloco lido corresponde ao que foi gravado. Com uma cópia redundante disponível, o sistema pode detectar um bloco corrompido e tentar corrigi-lo. Essa proteção contra corrupção silenciosa é uma das diferenças relevantes entre RAIDZ e implementações de RAID que não integram o sistema de arquivos dessa maneira.

Quantos discos são necessários e qual capacidade fica disponível?

Um vdev RAIDZ1 precisa de pelo menos três discos. A capacidade útil aproximada corresponde à quantidade de discos menos um, multiplicada pela capacidade do menor disco do grupo, descontando a formatação, os metadados, a reserva operacional e a forma como o pool será utilizado.

Uma configuração com quatro discos de 8 TB, por exemplo, não oferece 24 TB exatamente para gravação. A conta bruta sugere três discos de capacidade, mas o espaço exibido e o espaço recomendado para uso serão menores. Misturar discos de tamanhos diferentes também costuma fazer com que a capacidade seja limitada pelo menor dispositivo, dependendo da composição do vdev.

Há outro detalhe que costuma passar despercebido: capacidade nominal não é o mesmo que capacidade saudável de operação. O ZFS precisa de espaço livre para organizar gravações, atualizar metadados e executar tarefas internas. Encher o pool até o limite pode prejudicar o desempenho e dificultar a administração, mesmo que ainda apareça algum espaço disponível.

O número de discos não deve ser definido apenas pela capacidade desejada. Também entram na decisão o tamanho individual dos discos, a importância dos dados, o tempo aceitável de recuperação, a carga de leitura e escrita e a possibilidade de substituir componentes rapidamente.

O que acontece quando um disco falha no RAIDZ1?

Quando um disco apresenta falha, o pool fica degradado, mas os dados continuam acessíveis porque o ZFS recompõe os blocos ausentes com os discos restantes e a paridade. A prioridade passa a ser identificar a causa, confirmar qual dispositivo falhou, providenciar um substituto compatível e iniciar a reconstrução sem interromper desnecessariamente as operações.

O processo de recuperação é chamado de resilver. O ZFS lê informações dos dispositivos sobreviventes e grava no novo disco os blocos necessários para que o vdev volte a ter redundância. A duração depende da quantidade de dados efetivamente usados, do desempenho dos discos, da atividade simultânea do storage, da interface e de outros fatores do ambiente.

Durante o resilver, o storage continua trabalhando, mas normalmente com maior pressão de leitura e escrita. Aplicações que dependem de baixa latência podem perceber lentidão, especialmente quando o mesmo conjunto de discos atende arquivos grandes, máquinas virtuais, bancos de dados ou muitas solicitações simultâneas.

O risco mais importante está no intervalo entre a primeira falha e a conclusão da recuperação. O RAIDZ1 não tem uma segunda paridade para cobrir outro disco que pare de funcionar nesse período. Um erro de leitura irrecuperável em um disco sobrevivente, uma falha adicional ou uma inconsistência severa pode impedir a reconstrução completa do vdev.

Por esse motivo, uma luz de alerta não deve ser tratada como um inconveniente menor. O ideal é investigar também registros do sistema, saúde dos discos, temperatura, cabos, controladoras e alimentação. Trocar o disco errado, por exemplo, pode agravar o incidente em vez de resolvê-lo.

RAID Z1 afeta o desempenho do servidor ou storage?

O desempenho do RAIDZ1 varia conforme o padrão de uso. Ele costuma ser interessante para armazenar arquivos, cópias de segurança, mídia, documentos e dados acessados de forma sequencial, mas pode entregar menos IOPS e maior latência em gravações pequenas e aleatórias do que um conjunto de espelhos bem dimensionado.

A razão está na paridade. Em muitas gravações, o sistema precisa organizar os dados e calcular a informação redundante antes de confirmar a operação. O impacto pode ser discreto em arquivos grandes e sequenciais, mas mais perceptível em workloads com muitas operações pequenas, como máquinas virtuais, bancos de dados e aplicações que fazem gravações síncronas frequentes.

O desenho do vdev também importa. Adicionar discos a um pool não transforma automaticamente um vdev RAIDZ1 existente em outro formato, nem corrige uma escolha estrutural feita no início. A expansão e a reorganização dependem dos recursos disponíveis na versão do ZFS, do equipamento e do planejamento adotado. Em muitos projetos, mudar o layout depois exige migração de dados ou recriação controlada.

SSD ou disco mais rápido não elimina os limites da arquitetura. Da mesma forma, uma rede veloz não garante que o storage acompanhará a carga se o gargalo estiver na quantidade de operações por segundo, na memória, no processador, na controladora ou no próprio padrão de acesso.

A decisão fica mais precisa quando a rotina é descrita antes da compra: arquivos grandes ou pequenos, leitura ou escrita predominante, acesso sequencial ou aleatório, quantidade de usuários, necessidade de baixa latência e crescimento esperado. A especificação “RAIDZ1” isolada não informa se o desempenho será adequado.

Quando o RAIDZ1 faz sentido e quando evitar

RAIDZ1 pode fazer sentido quando a prioridade é obter uma combinação equilibrada entre capacidade e proteção contra uma falha, sem duplicar integralmente todos os dados. Um servidor de arquivos de pequeno porte, um storage doméstico com dados substituíveis e um repositório com backup independente são exemplos em que essa configuração pode ser considerada.

Ele tende a ser menos indicado quando os discos são muito grandes, o vdev é extenso, a recuperação pode levar muitas horas ou a indisponibilidade tem custo elevado. Quanto maior a quantidade de dados que precisa ser lida e reconstruída, mais relevante se torna a exposição a uma segunda falha durante o resilver.

Também merece cautela em ambientes nos quais o storage guarda a única cópia de informações importantes. Se não há backup separado, uma falha do pool, erro humano, exclusão acidental, ransomware, incêndio, furto ou corrupção lógica pode atingir os dados mesmo que nenhum disco esteja quebrado.

• RAIDZ1 costuma ser uma opção razoável quando existe backup verificável, os dados toleram uma janela de recuperação e a capacidade aproveitável pesa bastante na decisão.
• RAIDZ2 tende a ser mais prudente quando a continuidade é importante, os discos têm alta capacidade ou a reconstrução pode deixar o grupo vulnerável por tempo prolongado.
• Mirrors podem ser preferíveis para cargas com muitas operações aleatórias e necessidade de IOPS, ainda que o custo em capacidade seja maior.
• RAIDZ3 entra em projetos nos quais a tolerância a falhas precisa ser superior e a perda de três discos deve ser considerada no planejamento.

A comparação não deve ser reduzida a “qual nível é mais seguro”. RAIDZ2 e RAIDZ3 oferecem mais tolerância, mas consomem mais discos para redundância. Mirrors podem responder melhor a determinados padrões de acesso, porém não entregam a mesma eficiência de capacidade. A configuração mais adequada é aquela que combina risco aceitável, desempenho necessário, orçamento e capacidade de operação.

Por que RAIDZ1 não substitui um backup?

RAIDZ1 protege principalmente contra a falha de um disco dentro do vdev. Backup tem outra finalidade: manter uma cópia independente para recuperar dados apagados, sobrescritos, criptografados por malware, corrompidos logicamente ou perdidos junto com o equipamento inteiro.

Uma cópia em outro disco dentro do mesmo pool não representa, sozinha, um backup adequado. Ela pode desaparecer com o mesmo problema físico, erro de administração ou incidente que afetar o conjunto original. O backup precisa considerar outro destino, outra camada de proteção e, conforme a importância dos dados, uma cópia fora do ambiente principal.

Também é necessário testar a restauração. Um job marcado como concluído não prova que os arquivos podem ser recuperados, que as permissões foram preservadas ou que a cópia contém as informações esperadas. A recuperação de um arquivo específico costuma revelar problemas que não aparecem em uma verificação superficial.

Snapshots ajudam a voltar a estados anteriores e são muito úteis contra exclusões acidentais e alterações indesejadas, mas não devem ser confundidos automaticamente com backup. Se os snapshots ficam no mesmo pool, uma falha grave do storage pode atingir as duas coisas.

O RAIDZ1, portanto, reduz o impacto de uma falha de disco; não elimina a necessidade de uma estratégia de proteção de dados. Essa distinção evita uma das decisões mais caras em armazenamento: confundir disponibilidade imediata com capacidade de recuperação.

Como decidir entre RAIDZ1, RAIDZ2 e espelhos

A escolha começa pelo impacto de perder o serviço e pelo tempo necessário para recuperar o ambiente, não pela quantidade de discos disponível no orçamento. Vale levantar a capacidade realmente necessária, o crescimento previsto, o tipo de carga, o tempo de substituição dos discos e a existência de uma cópia independente antes de escolher o layout.

Para uso doméstico, um RAIDZ1 pode atender quando os dados são importantes, mas contam com cópia adicional e a operação aceita uma recuperação mais lenta. Em um servidor empresarial que concentra documentos, sistemas ou arquivos de trabalho, a análise costuma ser mais conservadora: a tolerância a duas falhas pode justificar o consumo adicional de capacidade do RAIDZ2.

Se o ambiente roda máquinas virtuais ou aplicações com muitas gravações pequenas, o espelhamento merece uma avaliação específica. Ele não é automaticamente superior em todos os casos, mas costuma oferecer comportamento mais previsível para operações aleatórias, especialmente quando o pool é construído com vários vdevs em mirror.

Antes de colocar o pool em produção, é prudente validar o modelo de disco, a compatibilidade do hardware, o método de monitoramento, o procedimento de substituição e o destino dos backups. Um arranjo bem escolhido ainda precisa de alertas funcionando, manutenção planejada e alguém capaz de interpretar o que acontece quando uma unidade entra em estado degradado.

O RAIDZ1 pode ser uma solução equilibrada para determinados servidores e storages, desde que seus limites sejam aceitos: uma única falha por vdev, recuperação potencialmente demorada, impacto de paridade em algumas cargas e nenhuma proteção contra incidentes que atinjam os dados fora do contexto de uma falha de disco. Para aprofundar essa decisão, vale acompanhar os conteúdos do Storages e conhecer as soluções relacionadas a armazenamento, backup e segurança digital, usando esses critérios para otimizar o ambiente com mais segurança.