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

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:

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.

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.

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.

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.

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:

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.