X
  • ZFS
    June 2, 2008

Espelhos esfumaçados

Guest Author

A restauração, também conhecida como ressincronização, reconstrução ou remontagem, é o processo de reparar um dispositivo danificado usando o conteúdo de dispositivos em bom estado. É isso que cada gerenciador de volume ou matriz RAID deve fazer quando um de seus discos pára de funcionar, é substituído ou sofre uma interrupção temporária de energia.

Para um espelho, a restauração pode ser tão simples quanto copiar o disco todo. Para o RAID-5, isso é um pouco mais complicado: em vez de copiar um disco para outro, todos os outros discos da faixa RAID-5 devem ser submetidos juntos ao processo XOR. Mas a idéia básica é a mesma.

Em um sistema de armazenamento tradicional, a restauração ocorre no gerenciador de volume ou no hardware RAID. De qualquer maneira, ocorre bem abaixo do sistema de arquivos.

Mas este é o ZFS, assim, certamente tínhamos que ser diferentes.

Em uma postagem anterior, mencionei que a reconstrução do RAID-Z requer uma abordagem diferente, porque ele precisa dos metadados do sistema de arquivos para determinar a geometria RAID-Z. Na verdade, o ZFS faz uma 'cp -r' (cópia e restauração) da árvore de blocos do pool de armazenamento de um disco para outro. Pode parecer menos eficiente do que uma cópia direta de todo o disco, e percorrer todo um pool ativo com segurança é, sem a menor dúvida, complicado (falaremos mais sobre esse assunto numa futura postagem). Mas a restauração orientada por metadados oferece tantas vantagens que preferimos usá-la até mesmo para espelhamento simples.

A razão mais importante é a integridade de dados. Com uma cópia simples de disco, não há como saber se o disco de origem está retornando dados válidos. A integridade dos dados ponta a ponta requer que cada bloco de dados seja comparado com uma soma de verificação independente; não é suficiente saber que cada bloco é meramente consistente consigo mesmo, porque isso não detecta erros comuns de hardware e de firmware, como leituras equivocadas e gravações fantasmas.

Ao percorrer os metadados, o ZFS pode usar suas somas de verificação ponta a ponta para detectar e corrigir corrupção silenciosa de dados, exatamente como ele faz durante as leituras normais. Se um disco retornar dados inválidos de maneira transitória, o ZFS detectará e tentará ler de novo. Se for um espelhamento de três vias e um dos dois discos supostamente bons estiver danificado, o ZFS usará a soma de verificação para determinar qual está correto, copiará os dados para o novo disco e reparará o disco danificado.

Uma cópia simples de todo o disco ignoraria toda essa proteção de dados. Apenas isso seria suficiente para tornar a restauração orientada por metadados aconselhável, mesmo à custa de uma significativa redução de desempenho.

Felizmente, na maioria dos casos, não é o que ocorre. Na realidade, a restauração orientada por metadados oferece diversas vantagens:

Somente blocos ativos. O ZFS não perde tempo e largura de banda de E/S copiando blocos de disco livres porque eles não fazem parte da árvore de blocos do pool de armazenamento. Se o seu pool estiver com apenas de 10 a 20% de sua capacidade ocupados, isso será um grande ganho.

Remoção de transações. Se um disco sofrer uma queda transitória de energia, não será necessário restaurar todo o disco, mas somente as partes que foram alteradas. Em uma futura postagem, vou descrever isso com mais detalhes, mas resumindo: o ZFS usa a hora de origem de cada bloco para determinar se há algo mais recente na árvore que precise de restauração. Isso permite pular enormes ramificações da árvore e descobrir rapidamente os dados que realmente foram alterados desde o início da interrupção.

Na prática, isso significa que se um disco sofrer uma interrupção de cinco segundos, demorará cerca de cinco segundos para restaurá-lo. E você não terá custo extra por isso, nem em termos financeiros nem de desempenho, como acontece quando o Veritas modifica objetos. A remoção de transações é um recurso intrínseco da arquitetura do ZFS.

Restauração descendente. Um pool de armazenamento é uma árvore de blocos. Quanto mais alto você estiver na árvore, mais desastrosa será a perda de um bloco, porque você perderá acesso a tudo abaixo dele.

Passar pelos metadados permite que o ZFS faça uma restauração descendente. Ou seja, o primeiro item que o ZFS restaura é o bloco inicial e as identificações do disco. A seguir, ele restaura os metadados de todo o pool de armazenamento, depois, cada metadado do sistema de arquivos e assim por diante até chegar à base da árvore. Durante todo o processo, o ZFS obedece a esta regra: nenhum bloco será restaurado até que todos os seus antecessores tenham sido restaurados.

É difícil enfatizar o quanto isso é importante. Em uma cópia de todo o disco, mesmo com 99% prontos, há uma grande possibilidade de um dos primeiros 100 blocos da árvore ainda não ter sido copiado. Isso significa que, de uma perspectiva de MTTR (tempo médio para reparos), na realidade, você não fez qualquer progresso: neste ponto, uma segunda falha de disco ainda seria catastrófica.

Com a restauração descendente, cada bloco individual copiado aumenta a quantidade de dados detectáveis. Se ocorrer uma segunda falha no disco, tudo o que tiver sido restaurado até este ponto estará disponível.

Restauração baseada em prioridade. O ZFS ainda não faz isso, mas está a caminho. A restauração do ZFS segue a estrutura lógica dos dados, logo, seria muito fácil marcar sistemas de arquivos ou arquivos individuais com uma prioridade específica de restauração. Por exemplo, em um servidor de arquivos, convém restaurar primeiro os calendários (eles são importantes, ainda que muito pequenos), a seguir, os diretórios /var/mail, depois, o diretório inicial e assim por diante.


O que espero transmitir em cada uma destas postagens não é somente a mecânica de como um recurso específico foi implementado, mas ilustrar como todas as partes do ZFS formam um todo integrado. Por exemplo, não fica imediatamente óbvio que a semântica transacional tenha algo a ver com a restauração, ainda que a remoção de transações torne a recuperação de interrupções transitórias literalmente muito mais rápida. Mais a respeito de como isso funciona na próxima postagem.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha