Red Hat Training

A Red Hat training course is available for RHEL 8

1.3. Considerações sobre a formatação GFS2

Esta seção fornece recomendações sobre como formatar seu sistema de arquivos GFS2 para otimizar o desempenho.

Importante

Certifique-se de que sua implementação do Red Hat High Availability Add-On atende às suas necessidades e pode ser apoiada. Consulte um representante autorizado da Red Hat para verificar sua configuração antes de sua implementação.

Tamanho do sistema de arquivo: Mais pequeno é melhor

O GFS2 é baseado em uma arquitetura de 64 bits, que teoricamente pode acomodar um sistema de arquivos 8 EB. Entretanto, o tamanho máximo atualmente suportado de um sistema de arquivo GFS2 para hardware de 64 bits é de 100TB.

Observe que, embora os sistemas de arquivos grandes GFS2 sejam possíveis, isso não significa que eles sejam recomendados. A regra geral com GFS2 é que menor é melhor: é melhor ter sistemas de arquivo de 10 1TB do que um sistema de arquivo de 10TB.

Há várias razões pelas quais você deve manter seus sistemas de arquivos GFS2 pequenos:

  • É necessário menos tempo para fazer o backup de cada sistema de arquivo.
  • É necessário menos tempo se você precisar verificar o sistema de arquivo com o comando fsck.gfs2.
  • Menos memória é necessária se você precisar verificar o sistema de arquivos com o comando fsck.gfs2.

Além disso, menos grupos de recursos para manter significam um melhor desempenho.

É claro, se você tornar seu sistema de arquivos GFS2 muito pequeno, você pode ficar sem espaço, e isso tem suas próprias conseqüências. Você deve considerar seus próprios casos de uso antes de decidir sobre um tamanho.

Tamanho do bloco: Blocos padrão (4K) são preferidos

O comando mkfs.gfs2 tenta estimar um tamanho de bloco ideal com base na topologia do dispositivo. Em geral, blocos 4K são o tamanho de bloco preferido porque 4K é o tamanho de página padrão (memória) para o Red Hat Enterprise Linux. Ao contrário de alguns outros sistemas de arquivo, o GFS2 faz a maioria de suas operações usando buffers de kernel 4K. Se seu tamanho de bloco for 4K, o kernel tem que fazer menos trabalho para manipular os buffers.

Recomenda-se usar o tamanho padrão do bloco, que deve render o mais alto desempenho. Você pode precisar usar um tamanho de bloco diferente somente se você precisar de um armazenamento eficiente de muitos arquivos muito pequenos.

Tamanho da revista: Padrão (128MB) Normalmente é o ideal

Ao executar o comando mkfs.gfs2 para criar um sistema de arquivos GFS2, você pode especificar o tamanho dos periódicos. Se você não especificar um tamanho, ele será padrão para 128MB, o que deve ser ideal para a maioria das aplicações.

Alguns administradores de sistema podem pensar que 128MB é excessivo e ser tentados a reduzir o tamanho do periódico para o mínimo de 8MB ou um 32MB mais conservador. Embora isso possa funcionar, pode ter um impacto severo no desempenho. Como muitos sistemas de arquivo de periódicos, toda vez que o GFS2 escreve metadados, os metadados são comprometidos com o periódico antes de ser colocado em funcionamento. Isto assegura que se o sistema falhar ou perder energia, você recuperará todos os metadados quando o periódico for reproduzido automaticamente no momento da montagem. Entretanto, não é necessária muita atividade do sistema de arquivos para preencher um diário de 8MB, e quando o diário está cheio, o desempenho diminui porque o GFS2 tem que esperar por escritos para o armazenamento.

Recomenda-se geralmente usar o tamanho padrão do diário de 128MB. Se seu sistema de arquivo for muito pequeno (por exemplo, 5GB), ter um diário de 128MB pode ser impraticável. Se você tiver um sistema de arquivo maior e puder arcar com o espaço, o uso de periódicos de 256MB pode melhorar o desempenho.

Tamanho e número de grupos de recursos

Quando um sistema de arquivo GFS2 é criado com o comando mkfs.gfs2, ele divide o armazenamento em fatias uniformes conhecidas como grupos de recursos. Ele tenta estimar um tamanho ideal de grupo de recursos (variando de 32MB a 2GB). Você pode substituir o padrão com a opção -r do comando mkfs.gfs2.

O tamanho ideal de seu grupo de recursos depende de como você utilizará o sistema de arquivo. Considere quão cheio ele estará e se será ou não severamente fragmentado.

Você deve experimentar com diferentes tamanhos de grupos de recursos para ver qual resulta em um ótimo desempenho. É uma melhor prática experimentar com um grupo de teste antes de implantar o GFS2 na produção total.

Se seu sistema de arquivo tiver muitos grupos de recursos, cada um deles muito pequeno, a alocação de blocos pode perder muito tempo procurando dezenas de milhares de grupos de recursos por um bloco livre. Quanto mais cheio seu sistema de arquivo, mais grupos de recursos serão pesquisados, e cada um deles requer um bloqueio de cluster. Isto leva a um desempenho lento.

Se, no entanto, seu sistema de arquivo tiver muito poucos grupos de recursos, cada um dos quais é muito grande, as alocações de blocos podem ter mais freqüência para o mesmo bloqueio de grupo de recursos, o que também impacta o desempenho. Por exemplo, se você tem um sistema de arquivo de 10GB que é dividido em cinco grupos de recursos de 2GB, os nós em seu grupo lutarão mais frequentemente por esses cinco grupos de recursos do que se o mesmo sistema de arquivo fosse dividido em 320 grupos de recursos de 32MB. O problema é exacerbado se seu sistema de arquivos estiver quase cheio porque cada alocação de blocos pode ter que procurar em vários grupos de recursos antes de encontrar um com um bloco livre. O GFS2 tenta mitigar este problema de duas maneiras:

  • Primeiro, quando um grupo de recursos está completamente cheio, ele se lembra disso e tenta evitar verificá-lo para futuras alocações até que um bloco seja liberado dele. Se você nunca apagar arquivos, a contenção será menos severa. Entretanto, se sua aplicação estiver constantemente apagando blocos e alocando novos blocos em um sistema de arquivos que esteja na maioria das vezes cheio, a contenção será muito alta e isto terá um impacto severo no desempenho.
  • Segundo, quando novos blocos são adicionados a um arquivo existente (por exemplo, anexando) o GFS2 tentará agrupar os novos blocos no mesmo grupo de recursos que o arquivo. Isto é feito para aumentar o desempenho: em um disco giratório, as operações de busca demoram menos tempo quando estão fisicamente próximas entre si.

O pior cenário é quando existe um diretório central no qual todos os nós criam arquivos porque todos os nós lutarão constantemente para bloquear o mesmo grupo de recursos.