Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Capítulo 2. Configuração do GFS2 e Considerações Operacionais

O sistema de arquivo (GFS2) do Global File System 2 permite que diversos computadores ("nós") em um cluster, compartilhem o mesmo armazenamento de forma cooperativa. Para alcançar esta cooperação e manter uma consistência de dados entre os nós, os nós empregam um esquema de bloqueio em todo o cluster para os recursos de sistema de arquivo. Este esquema de bloqueio utiliza protocolos de comunicação tais como o TCP/IP para troca de informações de bloqueio.
Você pode aprimorar o desempenho seguindo as recomendações descritas neste capítulo, incluindo recomendações para a criação, utilizando e mantendo um sistema de arquivo GFS2.

Importante

Certifique-se que sua implantação do Complemento de Alta Disponibilidade atenda suas necessidades e possa ser suportada. Consulte um representante autorizado Red Hat para verificar suas configurações antes da implementação.

2.1. Formatando Considerações

Esta seção provê recomendações para como formatar seu sistema de arquivo do GFS2 para otimizar desempenho.

2.1.1. Tamanho do Sistema de Arquivo: Quanto Menor Melhor

O GFS2 é baseado em uma arquitetura de 16-bits que pode teoricamente acomodar um sistema de arquivos 8 EB. Entretanto, atualmente o tamanho máximo suportado de um sistema de arquivos GFS2 para hardware de 64-bits é de 100 TB e o tamanho máximo suportado atual de um sistema de arquivos GFS2 de 32-bits é de 16 TB.
Observe que mesmo que os sistemas de arquivo grandes do GFS2 sejam possíveis, não significa que são recomendados. Como via de regra, com o GFS2, quanto menor melhor será: é melhor ter 10 1TB sistemas de arquivo do que 10TB sistema de arquivo.
Existem diversas razões pela qual você deveria manter seus sistemas de arquivo GFS2 pequenos:
  • É necessário menos tempo para fazer o back up de cada sistema de arquivo.
  • É necessário menos tempo caso você precise verificar o sistema de arquivo com o comando fsck.gfs2.
  • É necessário menos memória caso você precise verificar o sistema de arquivo com o comando fsck.gfs2.
Além disso, menos grupos de recurso para manutenção significa um melhor desempenho.
É claro que se você diminui muito seu sistema de arquivo GFS2, você pode não ter mais espaço e isto lhe trará consequências. Você deve considerar seus próprios casos de uso antes de decidir sobre o tamanho.

2.1.2. Tamanho do Bloco: Prefere-se (4K) Blocos Padrão

Desde o lançamento do Red Hat Enterprise Linux, o comando mkfs.gfs2 tenta estimular um tamanho de bloco mais adequado baseado na topologia do dispositivo. Em geral, prefere-se blocos com 4K, pois é o tamanho da página padrão (memória) para Linux. Ao contrário de alguns sistemas de arquivo, o GFS2 faz a maioria de suas operações utilizando os buffers do kernel de 4K. Se o tamanho do seu bloco é de 4K, o kernel dispenderá de menos trabalho para manipular os buffers.
Recomenda-se que você utilize o tamanho de bloco padrão, o qual deve gerar um maior desempenho. Você pode precisar utilizar um tamanho de bloco diferente somente se desejar armazenamento eficiente de muitos arquivos bem pequenos.

2.1.3. Números de Diários: Um para cada Nó que Monta

O GFS2 requer um jornal para cada nó no cluster que precise montar o sistema de arquivo. Por exemplo, se você possui um cluster de 16 nós, mas precisa montar somente o sistema de arquivo de dois nós, você precisará somente de dois diários. Se você precisar montar um terceiro nó, você pode adicionar um diário com o comando gfs2_jadd. Com o GFS2 você poderá adicionar diários imediatamente.

2.1.4. Tamanho do Diário: Padrão (128 MB) É Geralmente o mais adequado

Quando você executa o comando mkfs.gfs2 para criar um sistema de arquivo GFS2, você pode especificar o tamanho dos diários. Se você não especificar um tamanho, ele terá 128MB como padrão, o qual deve ser mais adequado para a maioria dos aplicativos.
Alguns administradores de sistema devem achar que 128MB é excessivo, e podem tentar reduzir o tamanho do diário para um mínimo de 8MB ou 32MB como mais tradicional. Embora possa funcionar, ele pode impactar de forma severa o desempenho. Como muitos sistemas de arquivos de diário, todas as vezes que o GFS2 grava um metadado, o metadado fica comprometido com o diário antes que seja colocado em prática. Isto assegura que se o sistema travar, ou perder força, você pode recuperar todos os metadados quando o diário for reproduzido automaticamente durante a montagem. No entanto, não é necessário muita atividade de sistema de arquivo para preencher um diário de 8MB e quando o diário estiver cheio, o desempenho será mais lento pois o GFS precisa esperar para gravar no armazenamento.
Geralmente recomenda-se que utilize o tamanho de diário padrão de 128MB. Se seu sistema de arquivo for muito pequeno (por exemplo, 5GB), um diário de 128MB pode não ser prático. Se você possuir um sistema de arquivo maior e puder ter o espaço, o uso dos diários de 256MB pode aprimorar o desempenho.

2.1.5. 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 faixas uniformes conhecidas como grupos de recursos. Ele tenta estimar o tamanho do grupo de recurso mais adequado (variando entre 32MB até 2GB). Você pode sobrescrever o padrão como a opção -r do comando mkfs.gfs2.
Seu tamanho de grupo de recurso mais adequado depende de como você irá utilizar o sistema de arquivo. Pense no quão cheio estará e se será fragmentado ou não.
VocÊ deveria experimentar com tamanhos de grupo de recursos diferentes para ver quais resultam em um desempenho mais avançado. É uma boa prática experimentar com um cluster de teste antes de implementar o GFS2 em total produção.
Se seu sistema de arquivo possuir muitos grupos de recursos (cada qual sendo muito pequeno), a alocação de blocos pode perder muito tempo tentando encontrar dezenas (ou centenas) de grupos de recursos para um bloco livre. O quanto mais cheio o sistema de arquivo estiver, mais os grupos de recursos serão vasculhados e cada um deles requer um bloqueio em todo o cluster. Isto levará a um desempenho mais lento.
Caso seu sistema de arquivo possua muito poucos grupos de recursos (cada qual sendo muito grande), as alocações de blocos podem lutar mais vezes pelo mesmo bloqueio de grupo de recurso, o qual também impactará o desempenho. Por exemplo, se você possui um sistema de arquivo de 10GB que está dividido em cinco grupos de recursos de 2GB, os nós em seu cluster irão lutar por estes cinco grupos de recurso mais vezes 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 completo, pois toda a alocação de bloco deve precisar procurar em diversos grupos de recursos antes que ele encontre um com bloco livre. O GFS2 tenta suavizar este problema de duas formas:
  • Primeiro, quando um grupo de recurso estiver completamente cheio, ele se lembra disto e tenta evitar verificá-lo em alocações no futuro (até que um bloco seja liberado dele). Se você nunca remover arquivos, a contenção será menos severa. No entanto, se seu aplicativo remover constantemente blocos e alocar novos blocos em um sistema de arquivo que esteja quase cheio, a contenção será muito alta e terá um impacto no desempenho bastante severo.
  • Em segundo lugar, quando novos blocos são adicionados a um arquivo existente (por exemplo, acrescentando) o GFS2 tentará agrupar os novos blocos no mesmo grupo de recursos como o arquivo. Isto é feito para aumentar o desempenho: em um disco rotativo, procura por menos tempo quando estão fisicamente juntos.
No pior dos casos, existirá 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 recurso.