Isenção de responsabilidade: não tenho muitos links e referências para fazer backup de tudo abaixo no momento e não testei extensivamente. Este é apenas um resumo das coisas que li nos últimos cinco a sete anos sobre o ZFS e como ele funciona, e alguns testes próprios limitados (não coordenados, mas principalmente reinicializações aleatórias).

Além disso, tudo abaixo é dito sem relação a eventos catastróficos (o servidor queima completamente), bugs de software (bugs no ZFS e no sistema operacional principal, bem como nos controladores de hardware) e malícia ativa (administrador desonesto, erros de administração). Para todos esses casos, você ainda precisa ter backups regulares e restauráveis!

Dados em repouso/consistência em disco

Não me importo com erros que surjam em outro software ou conexões remotas ao fazer isso, ou abortar qualquer transferência de arquivo longa prematuramente, só quero que ele desligue o pool da maneira mais rápida que seja consistente em manter sua consistência e possivelmente dar alguns segundos para que qualquer gravação pendente seja concluída e o pool esteja em um estado consistente para fins de dados.

Primeiro, a boa notícia: como o ZFS usa CoW e transações atômicas, seus dados já existentes estarão seguros mesmo em caso de perda repentina de energia. Isso inclui o layout e os metadados do pool. Como os dados antigos nunca são movidos antes que os novos dados tenham sido completamente gravados (na verdade, nunca são movidos, apenas realocados), esses dados não podem correr perigo de forma alguma se a gravação for interrompida repentinamente.

Além disso, somas de verificação (árvores de hash Merkle) ajudam a certificar que nada de ruim aconteceu durante a reinicialização, o que você pode verificar limpando o pool. Se você tiver vdevs redundantes, o ZFS corrigirá automaticamente quaisquer erros encontrados em uma cópia em bom estado. Se alguns blocos tivessem sido corrompidos de alguma forma (por exemplo, por um controlador de disco desonesto que não escreve, mas diz que sim), suas somas de verificação não corresponderiam às de outros vdevs e os erros seriam exibidos.

Dados em modos de voo/gravação e perda dos últimos n segundos

Gravações sincronizadas e assíncronas

Normalmente, o ZFS coleta várias transações para acelerar as gravações dispendiosas em unidades rotativas - posicionar o cabeçote de gravação do HDD leva muito mais tempo do que realmente gravar, portanto, você desejará enfileirar o máximo possível e, em seguida, gravá-lo em sequencial (mais rápido !) ordem (lembre-se, temos CoW, isso funciona naturalmente aqui).

A desvantagem disso é que quanto mais tempo você coletar, mais tempo seus aplicativos terão que esperar por uma mensagem de "gravação bem-sucedida" - o que significa que seu sistema travará por vários segundos, o que é inaceitável. Pior ainda - você perderá todos os dados que devem ser gravados no disco, mas ainda não foram gravados em caso de falha de energia. Se seus aplicativos não puderem lidar com isso, pode ocorrer corrupção na camada do aplicativo.

Para combater isso, o ZIL (ZFS intent log) foi adicionado. Todas as transações de sincronização são coletadas neste log (que é armazenado por padrão no disco do pool lento, mas pode ser armazenado em SSDs espelhados mais rápidos, chamados de dispositivos SLOG) e depois de armazenados, "gravação bem-sucedida" é retornada ao aplicativo que pode continuar com suas tarefas (não há mais bloqueios longos). Além disso, todas as transações assíncronas são feitas sem o ZIL, para que possam ser mais rápidas - desde que o aplicativo chame as operações de gravação corretas para seus dados (sincronização versus assíncrona).

Propriedades do ZFS

Agora, a parte mais interessante - o que acontece com suas gravações? Aí temos que discernir o modo de operação do sistema de arquivos (é uma propriedade do ZFS e pode ser definido individualmente para cada sistema de arquivos). Os três modos possíveis são (das páginas de manual):

sync=standard
  This is the default option. Synchronous file system transactions
  (fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log)
  and then secondly all devices written are flushed to ensure
  the data is stable (not cached by device controllers).

sync=always
  For the ultra-cautious, every file system transaction is
  written and flushed to stable storage by a system call return.
  This obviously has a big performance penalty.

sync=disabled
  Synchronous requests are disabled.  File system transactions
  only commit to stable storage on the next DMU transaction group
  commit which can be many seconds.  This option gives the
  highest performance.  However, it is very dangerous as ZFS
  is ignoring the synchronous transaction demands of
  applications such as databases or NFS.
  Setting sync=disabled on the currently active root or /var
  file system may result in out-of-spec behavior, application data
  loss and increased vulnerability to replay attacks.
  This option does *NOT* affect ZFS on-disk consistency.
  Administrators should only use this when these risks are understood.

Você notará que, mesmo que disabledseja escolhido, o layout/consistência interna do seu pool não é afetado - você perderá apenas seus últimos 5 segundos de dados e isso pode colocar seus arquivos em um estado incorreto (por exemplo, porque você tem uma VM em top que espera gravações de sincronização, mas você forneceu apenas um zvol assíncrono como um armazenamento de dados de apoio).

Por outro lado, se você não quer perder nada , defina todos os seus sistemas de arquivos alwayse mude para SSDs de alto desempenho, pelo menos para o dispositivo SLOG (ou sofra os tempos de espera).

standardé um compromisso e o mais flexível - o próprio aplicativo decide qual modo de gravação ele precisa. Se seus aplicativos estiverem ruins, você pode sofrer perda de dados. Se eles se comportarem, você terá o melhor desempenho possível com uma determinada linha de base de segurança.

Exportação/importação de pool:

Da documentação sobre zpool export:

O comando tenta desmontar quaisquer sistemas de arquivos montados no conjunto antes de continuar. Se algum dos sistemas de arquivos falhar ao desmontar, você pode desmontá-los à força usando a opção -f.

Se os dispositivos estiverem indisponíveis no momento da exportação, eles não poderão ser identificados como exportados corretamente. Se um desses dispositivos for posteriormente conectado a um sistema sem nenhum dos dispositivos em funcionamento, ele aparecerá como “potencialmente ativo”.

Se os volumes ZFS estiverem em uso no pool, o pool não poderá ser exportado, mesmo com a opção -f. Para exportar um pool com um volume ZFS, primeiro certifique-se de que todos os consumidores do volume não estejam mais ativos.

Isso significa aproximadamente três coisas:

• -fforça o pool a ser exportado pela desmontagem forçada de todos os sistemas de arquivos, mesmo que estejam ativos (desconsiderando bloqueios ou aplicativos gravados lá)
• Isso não funciona com zvols
• Você não deve dividir pools e usá-los em sistemas diferentes (tenha cuidado com situações de failover )

Resumo:

• Se tudo o que importa é a consistência no disco, você está export -fpronto ou um desligamento completo
• Se você se preocupa com todos os dados, use sync=alwaysSSDs rápidos
• Em relação ao iSCSI/NFS como armazenamento de dados para VMs, esta visão geral também pode ser útil (trecho: use NFS ou desabilite o cache de write-back iSCSI no host convidado/VM; desative a VM antes de tirar um instantâneo do ZFS, o ZFS funcionará de qualquer maneira, mas a VM convidada ser apenas consistente com falhas)

Em resposta às perguntas de acompanhamento dos comentários (perguntas omitidas para as quais não tenho respostas úteis):

(1) "boas notícias/COW" - e se os blocos de nível superior estivessem prestes a atualizar - sempre encontrará um bloco de nível superior utilizável (mesmo que aponte para versões ligeiramente antigas da árvore de metadados)? Quão ruim isso pode ficar?

O pior caso seria que o uberblock (aquele no topo de todos os outros) fosse danificado em todos os dispositivos redundantes. Como não há bloco acima dele, você não pode reconstruí-lo de cima, então existem várias cópias de cada uberblock (IIRC eram cerca de 3 ou 4), então uma pode ser perdida e uma cópia de substituição ainda está lá.

(2) Estou familiarizado com TXGs e uso ESXi. Usando APC UPS + bom PSU/hw + P3700 NVMe ZIL, então é uma potência decente + ZIL rápido. Mas é improvável que as gravações atuais sejam todas sincronizadas e, como você diz, a sincronização = sempre é lenta. Mas sua resposta levanta um pensamento, posso fazer alguns testes de desempenho. Estou usando dedup (economia de 4x, vale a pena), então escreva = lento de qualquer maneira (precisa procurar DDT). O motivo de sincronizar = sempre afeta apenas a gravação, que é lenta devido ao DDT. Mas definir sync=always força o ZIL, o ZIL é muito rápido e isso torna os TXGs longos seguros, o que pode significar que o acesso ao disco é mais eficiente. Ou pode matar a latência. Não faço ideia de qual! Pode ter que tentar!

Não tenho experiência real com dedup, então não posso dizer nada de útil aqui, exceto que você já fez boas escolhas em hardware (baixa latência, alta IOPS de gravação aleatória de 64k, interface NVMe). Só poderia ser mais rápido se você investisse em alguma unidade de RAM permanente realmente cara (ZeusRAM et al.).

(6) Por "consistência de disco" você quer dizer que o ZFS é feliz e o pool é autoconsistente? Não estou preocupado se alguns arquivos/diretórios. terminar com conteúdo inválido ou não movido/excluído é o pool que desaparece repentinamente ou o sistema de arquivos como NTFWS/VMFS em um zvol é corrompido internamente (ou seja, como um ZFS zvol está bom, mas da perspectiva do cliente ele precisa de fsck/chkdsk), pool fornecido é seguro/consistente como o ZFS o vê

Sim. Essencialmente "minha piscina não está fodida, yay!" em uma configuração multiusuário - mesmo que um usuário tenha problemas com seus arquivos, os outros não sofrem.

(7) Por "crash consistente" você quer dizer o que eu quero dizer (acho que sim) - que o ZFS vai ficar bem, o pool até onde o ZFS vê vai ficar bem, mas os dados do cliente remoto podem ser mutilados daquele cliente perspectiva da mesma forma como se o cliente tivesse atingido uma falha repentina de E/S de disco e as gravações tivessem sido perdidas? == o pool ficará bem, o cliente pode ter dados perdidos/inconsistentes e pode precisar de ajuda para recuperar, como em qualquer outra falha de E/S de disco ou travamento do sistema?

Sim, essencialmente um hard power off da VM em vez de um desligamento limpo e ENTÃO tirando um instantâneo - se você ligá-lo depois, fsckou similar dependendo do sistema de arquivos será executado e pode reclamar de desligamento impuro. Isso contrasta com os instantâneos do ESXi, que são retomados no ponto exato no tempo como se nada tivesse acontecido, mas precisam de interação com o sistema convidado (adições de convidado instaladas) e incluem a memória virtual da VM.

Você pode combinar ambos a seu favor: primeiro tire um instantâneo do ESXi e depois um instantâneo do ZFS do armazenamento de dados (o ESXi armazena seus instantâneos junto com a VM). Em seguida, exclua seu instantâneo ESXi, mas mantenha o ZFS (ocupa muito menos espaço devido às cópias em nível de bloco). Ao restaurar, primeiro restaure o instantâneo do ZFS e, em seguida, reverta para o instantâneo do ESXi (salvo) e você continuará de onde parou. napp-it (excelente sistema de gerenciamento ZFS com interface da Web) tem esse conceito integrado (pelo menos para armazenamentos de dados NFS, não verifiquei o iSCSI, mas suponho que seja semelhante).