Teste do sistema de arquivos para gravações contidas

Question

Eu tenho usado um conjunto de ferramentas de teste de sistemas de arquivos para avaliar e abusar de um volume GlusterFS. O volume é um volume de réplica 3 distribuído por 6 hosts.

Fio, iozone e Bonnie indicam que o Gluster está funcionando bem e a largura de banda é aproximadamente igual à dos adaptadores de rede do cliente e do servidor, portanto, o desempenho não pode ser realmente melhorado. A maioria dos casos de teste operava em arquivos de 32GB, além da iozone e da Bonnie.

Recebi relatos de quebras do cérebro ocorreram em determinados arquivos que estão sendo gravados simultaneamente por vários clientes. Toda a documentação que li parece indicar que o cérebro dividido ocorre em grande parte quando ocorrem partições de rede, e isso claramente não é o caso, a julgar pelos logs.

Infelizmente, esse cérebro dividido parece ocorrer apenas quando se usa um determinado serviço hospedado, e eu não tenho nenhuma introspecção sobre como esse serviço funciona, qual versão do cliente Gluster ele possui, etc. Os servidores estão executando a última versão 4.0.

A julgar pelo caso de falha que me foi apresentado ("split brain acontece quando dois containers estão gravando no mesmo arquivo ao mesmo tempo"), eu preciso de um teste que reproduza uma situação semelhante.

Eu definitivamente poderia escrever meu próprio caso de teste em C ou Rust, mas há algo lá fora que irá testar este caso exato sem ter que escrever nada?

Eu tenho acesso (mas não introspecção) a este serviço hospedado, então provavelmente testarei isso também. Eu também estou coçando a cabeça para o problema real: qual é o resultado desejado quando dois programas gravam dados diferentes para o mesmo arquivo ao mesmo tempo?

EDITAR: Os servidores estão executando a versão mais recente do CentOS 7. Meu servidor cliente de teste também está executando o mesmo. O sistema de arquivos subjacente é o XFS.

Existe um caso de teste específico que eu possa usar para tentar recriar o problema?

    

Answer 1

Parece que você tem um aplicativo PHP e seu log de erros está corrompido. Portanto, o teste mais realista seria executar vários processos PHP, que estão em paralelo chamando error_log ().

Você pode rastrear o aplicativo fazendo um registro de erros ou ler o código-fonte para descobrir sua implementação precisa. Particularmente interessante seria se ele fosse aberto no modo de anexação com O_APPEND. Append tem condições de corrida no NFS, portanto, isso não necessariamente corrige o problema nos sistemas de arquivos de rede.

Considere trocar error_log para syslog e deixar seu syslogd encaminhar para um syslog central. Isso irá convertê-lo para um único escritor de arquivos. Ou você pode encaminhar para uma plataforma de análise de log como Graylog, ELK ou Splunk, que possuem bancos de dados apropriados.

    

Answer 2

Basta criar dois trabalhos separados de fio que estão fazendo direct I / O para o mesmo arquivo que é controlado pelo parâmetro filename . Faça com que o size do arquivo seja pequeno e talvez tenha um ou ambos das tarefas do fio, escreva E / S aleatoriamente e, talvez, defina cada trabalho para usar um blocksize diferente. Pontos de bônus por usar o modo cliente / servidor do fio para que os trabalhos venham de máquinas diferentes. Use runtime e time_based para manter o loop de fio.