Identificando a causa da corrupção de dados do GlusterFS

Question

Eu tenho sofrido corrupção de dados ao gravar dados em um volume do GlusterFS replicado que configurei em dois servidores.

A configuração que eu configurei é a seguinte:

• Os servidores estão executando o Ubuntu 16.04 e o GlusterFS v3.10.6
• Os clientes estão executando o Ubuntu 14.04 e o GlusterFS v3.10.6
• Dois volumes no GlusterFS foram configurados, cada um com dois blocos distribuídos com um bloco em cada servidor.
• Cada bloco é um array MDADM RAID5 com um sistema de arquivos EXT4 / LUKS.

• Cada volume é configurado com as opções padrão, além da detecção de bitrot. Estes são os seguintes:

  features.scrub: Active
  features.bitrot: on
  features.inode-quota: on
  features.quota: on
  nfs.disable: on
  

A corrupção de dados se manifesta quando grandes diretórios são copiados do sistema de arquivos local em uma das máquinas clientes para um dos volumes GlusterFS configurados. Quando as somas de verificação md5 são calculadas para os arquivos copiados e os arquivos de origem e os dois são comparados, um certo número de somas de verificação diferem.

O acionamento manual de uma recuperação automática em volumes GlusterFS não mostra arquivos identificados para a recuperação. Além disso, observar a saída de gluster volume bitrot <volname> scrub status e os registros de saída em /var/log/glusterfs/bitd.log e /var/log/glusterfs/scrub.log não parecem identificar erros.

Esses problemas só se manifestaram recentemente após cerca de uma semana de uso de ambos os volumes em aproximadamente 10 clientes.

Eu tentei colocar os volumes offline e testei a gravação de dados em cada um dos blocos diretamente por meio do sistema de arquivos local subjacente e não consegui reproduzir os problemas.

Para depurar ainda mais o problema, configurei uma configuração semelhante em VMs no VirtualBox e não consegui reproduzir o problema. Eu estou, portanto, com uma certa perda quanto ao que pode ser a causa desses erros.

Qualquer sugestão de mais passos de depuração que eu possa ter ou problemas conhecidos com o GlusterFS e minha configuração serão apreciados.

    

Answer 1

Após não conseguir que o GlusterFS se comportasse corretamente, decidi mover minha configuração para o NFS, com um mestre ao vivo e um espelho sincronizados a cada hora para fornecer um grau de failover no caso de o servidor principal ficar inativo.

Recentemente, estávamos realizando manutenção no servidor fornecendo o espelho e descobrimos que estávamos tendo problemas semelhantes com a corrupção de dados no NFS nesse servidor.

Depois de muita depuração das possíveis causas da corrupção, nós eventualmente rastreamos a transferência de hardware para a interface de rede, depois percebi que também ocasionalmente recebíamos Disconnecting: Packet corrupt de erros com pacotes grandes em SSH.

Analisando as possíveis causas dos erros de SSH, encontrei o seguinte Unix & Questão do Linux: packet_write_wait Tubulação quebrada mesmo saindo em alta velocidade?

Algumas das discussões neste tópico sugeriram que um driver de interface de rede com bugs poderia levar à corrupção de pacotes quando a segmentação e a soma de verificação rx / tx fossem passadas para a interface.

Depois de desativar o rx / tx e o descarregamento de segmentação (seguindo as instruções na postagem do blog a seguir: Como resolver problemas de corrupção do pacote de desconexão ssh ) e testar o servidor sob carga de rede pesada, descobri que os erros de SSH e a corrupção de dados no NFS desapareceram.

Como não tenho mais o GlusterFS configurado nos servidores, não posso verificar se essa foi a causa da corrupção de dados que tivemos. No entanto, considerando que o problema persistiu em um dos servidores depois que nos mudamos para o NFS, é provável que isso tenha sido a causa de nossos problemas.

Como uma nota secundária, o driver da interface de rede estava usando o driver e1000e . Posteriormente, encontrei a seguinte discussão sobre o rastreador de bugs do RHEL: Bug 504811 - e1000 silenciosamente corrompendo dados , o que sugere que a corrupção de pacotes é possível como resultado do descarregamento de hardware para uma interface de rede, como certos cartões usando o driver e1000e .

    

Answer 2

Se o Gluster disser que não há corrupção, provavelmente não há corrupção detectável em seus volumes. No entanto, pelo que você descreve, não há réplicas de dados nesses volumes gluster além de 1. Sem várias repicas (idealmente três completas ou 2n + a), não podemos determinar se um nó corrompeu seus dados, pois não tem outra réplica para compare-se a.

Uma forma de contornar isso é habilitar o daemon de detecção de bitrot, que é desabilitado por padrão. Isso permitirá a limpeza de dados usando as somas de verificação de arquivos. Isso pode ser feito usando gluster volume bitrot VOLNAME enable . Erros detectados são registrados em /var/log/glusterfs/bitd.log e /var/log/glusterfs/scrub.log

Nada disso explica a corrupção durante o voo.

Você pode verificar os próprios clientes se nada acima mostrar algo e qualquer registro relevante do cliente e do servidor. Você também pode ter que testar seu hardware de rede, cliente ou servidor ao longo desse caminho para determinar exatamente onde essa corrupção está ocorrendo. Espero que você não tenha que ir tão longe.