Pesquisar

4.14. A Função de Retirada do GFS2

download PDF
A função withdraw (retirada) do GFS2 é um recurso de integridade de dados dos sistemas de arquivos GFS2 em um cluster. Se o modulo do kernel GFS2 detecta uma inconsistência em um sistema de arquivos GFS2 depois de uma operação de E/S, o sistema de arquivos se torna indisponível ao cluster. A operação de E/S pára e o sistema aguarda por mais operações de E/S para dar como erro, prevenindo mais danos. Quando isso ocorre, você pode parar quaisquer outros serviços ou aplicações manualmente, depois do qual você pode reinicializar e remontar o sistema de arquivos GFS2 para re-executar os diários. Se o problema repetir, você pode desmontar o sistema de arquivos de todos os nós no cluster e realizar uma recuperação do sistema de arquivos com o comando fsck.gfs2. A retirada da função GFS é menos severa que um pânico do kernel, que causaria um outro nó fazer um fence neste nó.
Se seu sistema estiver configurado com o script de inicialização gfs2 ativado e o sistema de arquivos GFS2 estiver incluído no arquivo /etc/fstab, o sistema de arquivos GFS2 será remontado quando você reinicializar. Se o sistema de arquivos GFS2 foi retirado porque percebeu uma corrupção do sistema de arquivos, é recomendado que você execute o comando fsck.gfs2 antes de remontar o sistema de arquivos. Neste caso, para previnir seu sistema de arquivos de remontar na inicialização, você pode seguir o seguinte procedimento:
  1. Temporiariamente desative o script de inicialização no nó afetado com o seguinte comando:
    # chkconfig gfs2 off
  2. Reinicialize o nó afetado, iniciando o software de cluster. O sistema de arquivos GFS2 não será montado.
  3. Desmontar o sistema de arquivos em todos os nós no cluster.
  4. Execute o comando fsck.gfs2 no sistema de arquivos de um nó somente para assegurar que não há corrupção do sistema de arquivos.
  5. Reative o script de inicialização no nó afetado executando o seguinte comando:
    # chkconfig gfs2 on
  6. Remonte o sistema de arquivos de todos os nós no cluster.
Um exemplo de uma inconsistência que submeteria uma remoção do GFS2 é uma contagem de blocos incorreta. Quando o kernel GFS deleta um arquivo de um sistema de arquivos, ele semânticamente remove todos os dados e blocos de metadados associados com esse arquivo. Quando isso é feito, ele checa a contagem de blocos. Se a contagem de blocos não é "um" (significando que tudo que restou é o próprio inode de disco), que indica que uma inconsistência do sistema de arquivos já que a contagem de bloco não correspondeu à lista de blocos encontradas.
Você pode sobrescrever a função de retirada do GFS2 montado o sistema de arquivos com a opção -o errors=panic especificada. Quando esta opção é especificada, quaisquer erros que normalmente causariam a retirada do sistema faz o sistema entrar em pânico. Isto pára as comunicações de cluster dos nós, que faz o nó entrar em fence.
Internamente, a maneira que a função de retirada do GFS2 trabalha é fazer o kernel enviar uma mensagem ao daemon gfs_controld requerendo a retirada. O daemon gfs_controld roda o programa dmsetup para colocar o alvo do erro do mapeador de dispositivos sob o sistema de arquivos prevenindo acesso ao dispositivo de bloco. Ele então diz ao kernel que a operação foi completada. Esta é a razão para o requerimento de suporte do GFS2 para sempre usar um dispositivo CLVM sob GFS2, já que de outra maneira não é possível inserir um alvo de mapeador de dispositivo.
O propósito do alvo de erro do mapeador de dispositivo é garantir que todas as operações de E/S futuras resultarão em um erro de E/S que permitirão ao sistema de arquivos ser desmontado de uma maneira ordenada. Como um resultado, quando a retirada ocorre, é normal ver erros de E/S do dispositivo mapeador relatados nos sistemas de logs.
Ocasionalmente, a retirada pode falhar se não for possível para o programa dmsetup inserir os alvos de erro conforme requeridos. Isto pode ocorrer se há uma falta de memória no ponto de retirada e mais memória não pode ser recuperada devido ao problema que desencadeou a retirada em primeiro lugar.
Uma retirada nem sempre significa que há um erro no GFS2. As vezes a função de retirada pode ser iniciada por erros no dispositivo de E/S relacionado ao bloco de dispositivo subjacente. É altamente recomendável verificar os logs para ver se esse é o motivo se uma retirada ocorrer.
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja oBlog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

© 2024 Red Hat, Inc.