O conjunto de ZFS-HA está com falha na corrupção de metadados

Question

Eu configurei o ZFS-HA seguindo a excelente descrição do Github (veja aqui ). Após testes extensivos, rolei a configuração para produção usando discos 5x12 em RAIDZ3 conectados a dois nós usando controladores HBA. Isso funcionou perfeitamente até a noite anterior, quando um dos dois pools de armazenamento falhou repentinamente com "Os metadados do pool estão corrompidos". durante uma execução de scrub . Neste ponto, posso apenas especular sobre o que causou isso, ambos os pools foram configurados com fence SCSI no marcapasso e as reservas de disco funcionaram perfeitamente durante todos os cenários de falha que testei antes de entrar em produção. O único grande incidente que ocorreu recentemente foram duas interrupções completas de energia sem o suporte da UPS (leia-se: a energia acabou de passar de um momento para o outro). No entanto, também pode ser que a verdadeira razão para a corrupção seja algo completamente diferente.

A situação agora é que eu não posso mais import do pool (gentilmente ver a saída de zpool import no final desta questão). Até agora, todas as minhas intenções para resgatar o pool falharam:

# zpool import -f tank
cannot import 'tank': one or more devices is currently unavailable

# zpool import -F tank
cannot import 'tank': one or more devices is currently unavailable

Isso me intriga um pouco, já que na verdade não diz que a única opção seria destruir o pool (que seria a resposta esperada em um pool letalmente corrompido).

# zpool clear -F tank
cannot open 'tank': no such pool

Também removi manualmente todas as reservas SCSI, por exemplo:

# DEVICE=35000c5008472696f
# sg_persist --in --no-inquiry --read-reservation --device=/dev/mapper/$DEVICE
# sg_persist --in --no-inquiry --read-key --device=/dev/mapper/$DEVICE
# sg_persist --out --no-inquiry --register --param-sark=0x80d0001 --device=/dev/mapper/$DEVICE
# sg_persist --out --no-inquiry --clear --param-rk=0x80d0001 --device=/dev/mapper/$DEVICE
# sg_persist --in --no-inquiry --read-reservation --device=/dev/mapper/$DEVICE

Eu também tentei remover o A / C das prateleiras de disco para limpar qualquer informação temporária que possa permanecer nas mesas.

Estou francamente com poucas opções. A única coisa que resta na minha lista é a opção -X para zpool import - que tentarei depois que todas as outras medidas falharem.

Então, a minha pergunta é: você se deparou com algo assim antes e - mais importante - você encontrou uma maneira de resolver isso? Eu ficaria muito grato por qualquer sugestão que você possa ter.

=========

Layout / configuração do pool:

   pool: tank
     id: 1858269358818362832
  state: FAULTED
 status: The pool metadata is corrupted.
 action: The pool cannot be imported due to damaged devices or data.
        The pool may be active on another system, but can be imported using
        the '-f' flag.
   see: http://zfsonlinux.org/msg/ZFS-8000-72
 config:

        tank                   FAULTED  corrupted data
          raidz3-0             FAULTED  corrupted data
            35000c5008472696f  ONLINE
            35000c5008472765f  ONLINE
            35000c500986607bf  ONLINE
            35000c5008472687f  ONLINE
            35000c500847272ef  ONLINE
            35000c50084727ce7  ONLINE
            35000c50084729723  ONLINE
            35000c500847298cf  ONLINE
            35000c50084728f6b  ONLINE
            35000c50084726753  ONLINE
            35000c50085dd15bb  ONLINE
            35000c50084726e87  ONLINE
          raidz3-1             FAULTED  corrupted data
            35000c50084a8a163  ONLINE
            35000c50084e80807  ONLINE
            35000c5008472940f  ONLINE
            35000c50084a8f373  ONLINE
            35000c500847266a3  ONLINE
            35000c50084726307  ONLINE
            35000c50084726897  ONLINE
            35000c5008472908f  ONLINE
            35000c50084727083  ONLINE
            35000c50084727c8b  ONLINE
            35000c500847284e3  ONLINE
            35000c5008472670b  ONLINE
          raidz3-2             FAULTED  corrupted data
            35000c50084a884eb  ONLINE
            35000c500847262bb  ONLINE
            35000c50084eb9f43  ONLINE
            35000c50085030a4b  ONLINE
            35000c50084eb238f  ONLINE
            35000c50084eb6873  ONLINE
            35000c50084728baf  ONLINE
            35000c50084eb4c83  ONLINE
            35000c50084727443  ONLINE
            35000c50084a8405b  ONLINE
            35000c5008472868f  ONLINE
            35000c50084727c6f  ONLINE
          raidz3-3             FAULTED  corrupted data
            35000c50084eaa467  ONLINE
            35000c50084e7d99b  ONLINE
            35000c50084eb55e3  ONLINE
            35000c500847271d7  ONLINE
            35000c50084726cef  ONLINE
            35000c50084726763  ONLINE
            35000c50084727713  ONLINE
            35000c50084728127  ONLINE
            35000c50084ed0457  ONLINE
            35000c50084e5eefb  ONLINE
            35000c50084ecae2f  ONLINE
            35000c50085522177  ONLINE
          raidz3-4             FAULTED  corrupted data
            35000c500855223c7  ONLINE
            35000c50085521a07  ONLINE
            35000c50085595dff  ONLINE
            35000c500855948a3  ONLINE
            35000c50084f98757  ONLINE
            35000c50084f981eb  ONLINE
            35000c50084f8b0d7  ONLINE
            35000c50084f8d7f7  ONLINE
            35000c5008539d9a7  ONLINE
            35000c5008552148b  ONLINE
            35000c50085521457  ONLINE
            35000c500855212b3  ONLINE

Editar:

Os servidores são 2x Dell PowerEdge R630, os Controladores são versões DELL OEM do Broardcom SAS HBA (devem ser semelhantes ao SAS 9300-8e) e todos os 60 discos neste pool são Seagate ST6000NM0034. O gabinete é o Quanta MESOS M4600H.

Editar 2:

OS é o CentOS 7

O ZFS é zfs-0.7.3-1.el7_4.x86_64

    

Answer 1

No final, recorri ao uso da opção -X para o import . Isso exercitou todos os discos lendo a 2 GB / s por cerca de 36 horas. Depois disso, nenhuma mensagem de erro foi fornecida, o sistema de arquivos foi montado e agora está totalmente acessível novamente. Até agora, não foram detectadas inconsistências de dados ( zfs scrub ainda está em execução). Obrigado por todas as suas respostas.

No entanto, para futuros leitores, quero passar o aviso sobre a opção -X da página man: Essa opção pode ser extremamente perigosa para a integridade de seu pool e deve ser usada apenas como um último recurso.

    

Answer 2

Parece que o upstream não tem muitas opções aqui (isso é de Oracle Solaris ZFS Solução de problemas e recuperação de pool documento, informando que zpool import -F é a única opção que você realmente tem, exceto contratar o guru do ZFS que realmente examinará como os metadados estão corrompidos):

If the pool cannot be recovered by the pool recovery method described above, you must restore the pool and all its data from a backup copy.

E eu não acho que a aliança OpenZFS trouxe muita coisa aqui que mudaria a situação. E isso é realmente triste notícia.

P.S. Isso não tem nada a ver com o motivo pelo qual o pool chegou ao seu estado, mas você não acha que criar 10 arrays de largura de disco é o problema por si só? Mesmo com 2 ou mais discos de reposição. Dados frios e assim por diante, você sabe.

    

Answer 3

Quais são os detalhes do hardware? Faz e modela servidores, discos, compartimentos e controladores.

Desativo todos os recursos de alta disponibilidade e foco em trabalhar em um sistema.

• Coloque um nó em espera: pcs cluster standby ou apenas desative o marcapasso.

• Importe manualmente o pool no nó em que você estará trabalhando:

  zpool import tank -d /dev/mapper/ e observe o resultado.

Além disso, o que você vê em dmesg depois de fazer isso?