Tentando corromper dados em um mirror ZFS

Imagem meramente ilustrativa 😛

Esse é o primeira de uma série de posts que eu pretendo escrever ao mesmo tempo que eu estudo mais sobre OpenSolaris. A idéia é criar artigos simples mostrando funcionalidades bem específicas através de experimentos práticos que você pode replicar em seu computador.

Uma das funcionalidades mais interessantes do OpenSolaris é o sistema de arquivo de 128-bits ZFS. Para quem está começando a principal diferença é a abstração utilizadas para os volumes. Ao contrário dos sistemas de arquivos tradicionais, onde cada um reside em um único dispositivo e requerem um gerente de volumes para usar mais de um dispositivo, o sistema de arquivo ZFS é construído sob pools de armazenamento virtuais chamados zpools. Um zpool é construído de dispositivos virtuais (vdevs) quem são constituídos de volumes de bloco (arquivos, partições de um disco ou discos inteiros, o que é o recomendado).

Esse primeiro experimento vai ser construir zpool espelhado (RAID-1) e depois tentar corromper os dados dele e ver o que acontece. Em um pool espelhado, os dados são replicados para vários discos e isso elimina o ponto crítico, ou seja, se um disco parar de funcionar, os dados não são corrompidos. Você pode criar um espelho com dois ou mais discos e dentro de um mesmo pool você pode ter vários espelhos. Por exemplo, um pool de 100Gb formado por dois espelhos, cada um com 50GB e cada espelho formado por discos rígidos de 25Gb cada um. Você vai dimensionar seu pool de acordo com suas necessidades e capacidades.

Essa parte de corromper os dados faz experimento ser um pouco perigoso. Eu te aconselho a fazer uma dessas sugestões:

• Instalar o OpenSolaris no seu disco e pelo menos outros dois discos rígidos para fazer um zpool espelhado. Eu não recomendo essa opção porque se você não souber muito bem o que está fazendo você pode corromper dados acidentalmente.
• Instalar o OpenSolaris em uma máquina virtual e criar discos rígidos falsos para utilizar no experimento. Assim mesmo que você cometa algum erro nada de muito ruim vai acontecer. Essa é a opção que eu escolhi e aqui eu estou usando o VirtualBox com o OpenSolaris 2008.5. É uma máquina virtual livre, muito fácil de usar e o OpenSolaris se dá muito bem com ele.

Embora já exista uma interface gráfica para controle para ZFS, está não está incluída no OpenSolaris 2008.5. Além disso para quem quer estudar o ZFS um pouco mais a fundo, acho que conhecer seu controle via linha de comando é interessante.

Com o OpenSolaris já bootado, abra um terminal, logue-se como root e consulte os seus dispositivos com echo|format.

Se você esta bem familiarizado com Linux você deve estranhar a nomenclatura dos dispositivos no OpenSolaris, eu recomendo voce dar uma olhada nesse documento.

Parar criar um pool com os dispositivos c4d1 (80G) e o c5d1 (60GB) basta simplesmente um zpool create ourpool mirror c4d1 c5d1.

Explicando esse comando palavra a palavra:

• zpool: para usar o ZFS você só precisa estar familiarizado com dois comandos: zpool e zfs. O comando zpool é quem configura os storages pools ZFS.
• create: a acao a ser tomada, no caso, criacao.
• ourpool: o nome que eu escolhi para o pool.
• mirror: diz que vamos fazer espelhamento, logo as próximas palavras serão dois ou mais dispositivos.
• c4d1 c5d1: os dispositivos usados.

Diagrama do pool que criamos. Ícones do Everaldo Coelho.

Se o comando funcionou, ele agira silenciosamente e nao retornar nada. Para checar o estatus do pool fazemos um zpool status ourpool.

Essa saída nos diz que o pool chamado ourpool está com o status ONLINE e que o pool é composto de um único mirror que por sua vez é composto dos dispositivos c4d1 e c5d1.

Podemos listar todos pools com zpool list.

O ourpool tem aproximadamente 60GB de tamanho dos quais 900kb já foram usados para guardar metadados. Como nós usamos um espelho de discos de 60GB e de 80GB, o tamanho do pool foi determinado pelo tamanho do menor disco. O outro pool, rpool é o pool que o OpenSolaris cria por default para abrigar o sistema inteiro.

Agora vamos povoar o pool com dados. Estes dados poderiam ser dados reais importantes como os arquivos de um banco de dados, sua coleção de fotos ou seu arquivo de documentos. Para efeitos ilustrativos eu vou usar aqui um arquivo vazio de 100Mb chamado data. mkfile 100m data.

Durante a criação do arquivo eu dei um zpool iostat -v ourpool para ver o tráfego na entrada/saída do pool. Note que há tráfego em ambos os discos já que eles formam um espelho.

Vamos criar e guardar um checksum md5 do arquivo data para podermos checar sua integridade mais tarde, md5sum data > data.md5. Para checarmos se esse checksum bate com o checksum do arquivo fazemos um md5sum –check data.md5.

Agora vem a parte crítica dessa simulação. Vamos simular um defeito físico no disco. Dispositivos de armazenamento vão falhar em algum momento, só não sabemos quando, e quando acontecer ele poderá corromper seus dados ou parar aplicações importantes.

Vamos pegar 20 Mb de lixo retirado do /dev/urandom e joga-los no disco c4d1, dd if=/dev/urandom of=/dev/dsk/c4d1 bs=1024 count=20480. Existem formas mais divertidas (e caras) de provocar defeitos físicos, dê uma olhada nesse vídeo onde eles usam ZFS e martelos. 🙂

Pronto, o estrago foi feito. Olhamos o status do pool, zpool status ourpool.

Não vemos nenhum erro até porque o ZFS é baseado em cache na memória. Vamos forçar ele a limpar esse cache derrubando e subindo o pool. Primeiro cd / para termos certeza que não estamos dentro do pool, depois um zpool export ourpool seguido de um zpool import ourpool.

Olhamos o status novamente, zpool status ourpool.

O pool continua ONLINE mas o ZFS sabe que alguma coisa está errada.

Vamos checar a integridade dos dados checando nosso checksum md5, md5sum –check data.md5.

Os dados estão intactos.

Essa é uma das características de self-healing do ZFS. A corrupção de dados que ocorreu em um dos volumes espelhados foi reparada silenciosamente. Em um gerenciador de volumes tradicional você não só teria perdido seus dados como nem sequer saberia que houve corrupção.

Mas nesse ponto o administrador do sistema deve ser avisado para tomar alguma atitude em relação ao disco defeituoso. Estas são algumas sugestões:

• Descobrir o disco defeituoso: se o disco já deu problema é provável que ele vá dar problema novamente e pode até levar a falhas em outros discos. O ZFS possui um mecanismo chamado scrubbing (esfregagem) que varre os blocos a procura de erros de checksum e os corrige usando os dados saudáveis. Um zpool scrub ourpool vai forçar o processo de scrubbing, que vai rodar em background. Verificando o status do pool com zpool status ourpool você pode descobrir o disco defeituoso.
• Examinar o histórico do pool: você pode examinar todo o histórico do pool para entender o que aconteceu com ele antes de você chegar. Um zpool history ourpool vai mostrar que comandos de pool foram dados desde a criação do pool.
• Restaurar o espelho: um zpool clean ourpool vai restaurar o espelho, mas isso mantém o disco defeituoso, o que pode ser perigoso.
• Desligar o disco defeituoso: você pode desliga-lo usando zpool offline ourpool c4d1 sem precisar alterar a estrutura do pool.
• Desespelhar o pool: com um zpool detach ourpool c4d1 você retira o dispositivo do pool, mas como o espelho era formado de dois dispositivos, ele passa a não ser mais um espelho.
• Trocar o disco defeituoso: se você tem um outro disco, por exemplo c6d1, você pode coloca-lo no lugar do disco defeituoso e ele vai assumir seu lugar no espelho. Para isso use um zpool replace c4d1 c6d1. A partir desse momento ira começar em background um processo chamado de resilvering (re-espelhamento), mas isso já é tema para um outro post. 🙂

Pra resumir tudo, eu fiz esse screencast:

Download do vídeo: opensolaris_zpool_mirror.mpeg.

Documentação complementar:

• Self Healing with ZFS
• ZFS Best Practices Guide
• OpenSolaris ZFS Documentation Page
• Solaris ZFS Administration Guide
• ZFS, Sun’s Cutting-edge File System
• ZFS Hot Spares
• Vídeos em português sobre OpenSolaris

Há uma tradução para inglês desse post.