Unidade não disponível do autoreplace do ZFS

Question

Eu tenho a seguinte configuração do pool de testes do ZFS em minha VM:

    NAME        STATE     READ WRITE CKSUM
    pool        DEGRADED     0     0     0
      mirror-0  DEGRADED     0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
    spares
      sdd       AVAIL

Estou tentando testar a capacidade de substituir uma unidade que se torna indisponível automaticamente em um pool do zfs. Por exemplo, se por algum motivo a unidade for removida do sistema, o mergulho sobressalente poderá ocorrer imediatamente após a remoção da unidade. Configurei uma unidade spare e, a partir da leitura que fiz, a maneira como entendo é que isso deve atingir minha meta. Eu também configurei o sinal autoreplace para on para informar ao zfs para substituir qualquer unidade defeituosa se detectada. Quando remover uma unidade da vm, digamos sdb e verifique novamente o status do zfs, ela se parece com a seguinte:

    NAME        STATE     READ WRITE CKSUM
    pool        DEGRADED     0     0     0
      mirror-0  DEGRADED     0     0     0
        sdb     UNAVAIL      0     0     0
        sdc     ONLINE       0     0     0
    spares
      sdd       AVAIL

O dispositivo sdb fica indisponível, mas nunca é substituído pelo sobressalente. Existe uma maneira de fazer meu caso de uso funcionar?

    

Answer 1

Introdução

Em primeiro lugar, para quem está tendo o mesmo problema no Ubuntu 16.04, ele é atualmente um bug em andamento e, até o momento, que eu saiba, não foi corrigido. Você pode visitar a conversa do github aqui para ver o erro que estou referenciando. Em segundo lugar estou escrevendo este post como um usuário entusiasta e intermediário linux, eu não sou um desenvolvedor ou atualmente trabalho no linux como profissão. Dito isto, vou fornecer as informações que encontrei sobre esta questão, tanto quanto é do meu conhecimento.

O problema:

A funcionalidade de hot spare incorporada no pacote zfsonlinux atualmente não funciona como indicado na página do manual. zpool man page:

Hot Spares
   ZFS allows devices to be associated with pools as "hot spares".
   These devices are not actively used in the pool, but when an active
   device fails, it is automatically replaced by a hot spare.

Nota: A funcionalidade de reserva a frio (uma sobressalente não substituída automaticamente) está funcionando, mas apenas em configurações que consistem em mirrors ou qualquer raidz's . Se você tem uma configuração como a seguinte:

NAME      STATE     READ WRITE CKSUM
pool      ONLINE       0     0     0
  sdb     ONLINE       0     0     0
  sdc     ONLINE       0     0     0
spares
  sdd     AVAIL

Após a falha de uma unidade, você não poderá substituí-la pelo sobressalente devido ao erro pool I/O is currently suspended .

Soluções tentadas:

Esta é uma lista de soluções tentadas pelas quais passei e os resultados obtidos:

1. Substituição automática do ZFS: Acontece que, de acordo com a página zpool man e minha compreensão, a funcionalidade autoreplace não é substituir uma unidade danificada pelo sobressalente, mas substituir a própria unidade danificada por qualquer novo dispositivo encontrado em sua localização. zpool man page:

   If set to "on", any new device, found in the same physical location
   as a device that previously belonged to the pool, is automatically 
   formatted and replaced.
   

   autoreplace é bom de se ter, mas para conseguir a funcionalidade de um hot spare não acredito que seja necessário. Não consigo confirmar isso além da página de manual porque não consegui colocar o sobressalente no trabalho.

2. ZED.rc: Mais tarde, descobri que, dentro da conversa no github, os sinalizadores ZED_SPARE_ON_CHECKSUM_ERRORS e ZED_SPARE_ON_IO_ERRORS precisavam ser definidos dentro do zed.rc . Como o @ user121391 disse em sua resposta a este post, o serviço / daemon zed é o que determina o status do pool e o que é necessário ser feito com base nesse status. Você pode ver zed.d no trabalho executando zpool events . Depois de definir os sinalizadores, reinicializar e reconfigurar um novo pool apenas no caso, o teste do hot spare ficou negativo novamente.

3. Scripts ZED.d: No comentário do @Michael Kjörling , ele mencionou alguns scripts incluídos no ZED, que foram escritos para ajudar no cenário de hot spare. Eu realmente encontrei os scripts localizados em /etc/zfs/zed.d . Você pode ver esses scripts na página do github aqui . Do meu entendimento de zed.d, quando um evento é acionado, o daemon ZED executa um desses scripts com base em seu status. Dito isto, tentei executar o io-spare.sh e checksum-spare.sh manualmente e, a julgar pelo tempo que eles levaram para executar, bem como o status inalterado do conjunto, eles não pareciam estar funcionando corretamente. Talvez esta seja uma fonte potencial para o problema.

Meus Planos

Para usuários do Ubuntu 16.04 do ZFS, até onde sei, atualmente parece não haver nenhuma correção para esse problema. Eu pretendo continuar a usar o ZFS com a configuração de um mirrored ou raidz (RAID5), dependendo do desempenho que recebo no teste. (Espelhado será mais rápido, mas eu quero ver a velocidade de raidz ) spare aumentaria a redundância de ambas as configurações, mas infelizmente teremos que esperar até o desenvolvimento do projeto zfsonlinux . v