Pesquisar

2.9. Bloqueio de Nó GFS2

download PDF
Para conseguir o melhor desempenho de um sistema de arquivos GFS2, é muito importante entender algumas teorias básicas de suas operações. Um sistema de arquivo de nó único é implementado junto com um cache, a razão do qual é eliminar a latência de acessos ao disco quando usar dados frequentemente requeridos. No Linux o cache de página (e históricamente o cache de buffer) fornece essa função de cache.
Com o GFS2, cada nó tem seu próprio cache de página que pode conter algumas porções de dados no disco. O GFS2 usa um mecanismo de bloqueio chamado glocks (pronunciado em inglês gee-locks) para manter a integridade do cache entre os nós. O subsistema glock fornece uma função de gerenciamento de cache que é implementada usando o gerenciador de bloqueio distribuído (DLM - distributed lock manager) como a camada de comunicação subjacente.
Os glocks fornecem proteção para o cache em uma base por nó, para que então haja um bloqueio por inode que é usado para controlar a camada de cache. Se esse glock é concedido para um modo compartilhado (DLM lock mode: PR) então os dados sob esse glock podem ser colocados em cache em um ou mais nós ao mesmo tempo, que então todos os nós possam ter acesso local aos dados.
Se o glock é concedido em modo exclusivo (DLM lock mode: EX) então somente um nó único pode fazer o cache dos dados sobre este glock. Este modo é usado por todas as operações que modificam os dados (tais como uma chamada de sistema write).
Se um outro nó solicita um glock que não pode ser feito imediatamente, então o DLM envia uma mensagem ao nó ou nós que atualmente possuem os glocks bloqueando a nova solicitação para pedir aos nós para remover seus bloqueios. Removendo glocks pode ser (pelo padrão da maioria dos sistemas operacionais) um longo processo. Removendo um glock compartilhado requer somente que o cache seja invalidado, que é relativamente rápido e proporcional ao tamanho dos dados em cache.
Despejar (drop) um glock exclusivo requer uma liberação de log e escrever de volta quaisquer dados alterados no disco, seguido pela invalidação como por glock compartilhado.
A diferença entre um sistema de arquivos de nó único e o GFS2 então, é que um sistema de arquivos de nó único possui um cache único e o GFS2 possui um cache separado em cada nó. Em ambos os casos, a latência para acessar os dados em cache é como uma ordem similar de magnitude mas a latência para acessar dados sem cache é muito maior no GFS2 se outro nó tiver anteriormente feito o cache dos mesmos dados.

Nota

Devido à maneira na qual o cache do GFS2 é implementada, o melhor desempenho é obtido quando qualquer umas das situações seguintes acontecem:
  • Um inode é usado em uma forma de leitura somente em todos os nós
  • Um inode é escrito ou modificado a partir de um nó único somente.
Note que inserindo e removendo entradas de um diretório durante criação e exclusão de arquivos conta como escrita no diretório inode.
É possível quebrar esta regra desde que ela seja quebrada relativamente com infrequencia. Ignorando esta regra com frequencia resultará em uma severa penalidade no desempenho.
Se você usar mmap() em um arquivo em GFS2 com mapeamento de escrita e leitura, mas somente leitura é feita, se contará apenas como leitura. No GFS entretanto, se conta como uma escrita, então o GFS2 é muito mais escalável com o mmap() de E/S.
Se você não ajudar o parâmetro noatime mount, então leituras também resultarão em escritas para atualizar o arquivo timestamps. Nós recomendamos que todos usuários GFS2 deveriam ser montados com noatime ao menos que eles tenham um requerimento específico para o atime.

2.9.1. Problemas com o Bloqueio de Posix

Ao utilizar o bloqueio de Posix, você deve levar em consideração:
  • Ao utilizar o Flocks, você irá gerar processamento mais rápido do que se utilizar os bloqueios de Posix.
  • Programas que utilizam os bloqueios Posix no GFS2 devem evitar utilizar a função GETLK, pois em um ambiente em cluster, o ID do processo pode ser para um nó diferente no cluster.
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.