Administração do ZFS no Solaris 11.4: pools, datasets, snapshots e scrubs

O que é

O ZFS é o sistema de arquivos padrão do Oracle Solaris 11.4 e o único com suporte como sistema de arquivos raiz (o UFS continua suportado para dados, mas os boot environments exigem ZFS). Dois comandos cobrem quase toda a administração: o zpool gerencia os pools de armazenamento (os dispositivos físicos e a redundância), e o zfs gerencia os datasets — sistemas de arquivos, volumes e snapshots — que ficam dentro de um pool.

Por que importa

Ao contrário de uma pilha Linux com LVM mais sistema de arquivos, os pools e datasets do ZFS são gerenciados como um único sistema, com checksums integrados, snapshots e, com send/receive, replicação nativa. Como os boot environments (veja o artigo sobre o beadm nesta série) são, eles próprios, datasets ZFS, entender zfs/zpool é pré-requisito para aplicar patches com segurança, e não apenas para administrar armazenamento.

Como aplicar

• Verifique primeiro a saúde do pool: zpool status mostra os dispositivos de cada pool, o estado deles (ONLINE, DEGRADED, FAULTED) e qualquer ação de reparo necessária; zpool status -x informa apenas os pools com problemas; zpool list dá um resumo de uma linha por pool, com tamanho, alocação e saúde.
• Liste e inspecione os datasets: zfs list mostra os sistemas de arquivos montados, os volumes e o uso de espaço de cada um; zfs list -t snapshot restringe a exibição aos snapshots.
• Crie um dataset já com uma propriedade definida na criação: zfs create -o compression=on tank/data; para alterar uma propriedade depois, em um dataset existente, use zfs set compression=on tank/data.
• Faça uma cópia de um ponto no tempo: zfs snapshot tank/data@before-change. Os snapshots são somente leitura e consomem espaço apenas para os blocos que mudarem depois.
• Desfaça uma alteração voltando a um snapshot: zfs rollback tank/data@before-change. Todos os dados gravados desde esse snapshot são descartados; por padrão, o comando só reverte para o snapshot mais recente e se recusa a continuar se existirem snapshots mais novos.
• Replique ou faça backup de um dataset: zfs send tank/data@snap | zfs receive backuppool/data envia o fluxo de dados de um snapshot como envio completo; o subcomando send também suporta fluxos incrementais entre dois snapshots.
• Verifique a integridade dos dados de forma proativa: zpool scrub <pool> lê e confere cada bloco com o respectivo checksum, reparando o que a redundância permitir; zpool status informa o andamento do scrub e quando o último foi concluído.
• Acompanhe a E/S no nível do pool: zpool iostat -v <pool> <interval> (veja também o artigo sobre desempenho nesta série) mostra as operações de leitura/escrita e a largura de banda por dispositivo, repetidas no intervalo indicado.

Armadilhas

• Forçar um rollback passando por cima de snapshots mais novos: -r destrói todos os snapshots mais recentes, e -R destrói também os clones deles; por isso, confirme antes o que existe com zfs list -t snapshot. Para os datasets de boot environment do pool raiz, use o beadm em vez de zfs rollback/destroy diretamente.
• Tratar o zpool scrub como backup: ele verifica e repara usando a redundância, mas não protege contra a exclusão de um dataset nem contra um pool sem nenhuma redundância configurada.
• Esquecer que destruir um snapshot com clones dependentes exige uma opção explícita de cascata — liste sempre os dependentes antes de destruir qualquer coisa.