2.4. Configurando o NFS sobre o GFS2
Devido à complexidade adicional do subsistema de travamento GFS2 e sua natureza agrupada, a configuração do NFS sobre o GFS2 requer tomar muitas precauções e uma configuração cuidadosa. Esta seção descreve as advertências que você deve levar em conta ao configurar um serviço NFS sobre um sistema de arquivos GFS2.
Se o sistema de arquivo GFS2 é NFS exportado, então você deve montar o sistema de arquivo com a opção localflocks. Como a utilização da opção localflocks impede o acesso seguro ao sistema de arquivos GFS2 de múltiplos locais, e não é viável exportar o GFS2 de múltiplos nós simultaneamente, é um requisito de suporte que o sistema de arquivos GFS2 seja montado em apenas um nó de cada vez ao utilizar esta configuração. O efeito pretendido disto é forçar os bloqueios POSIX de cada servidor a serem locais: não exclusivos, independentes uns dos outros. Isto ocorre porque existe uma série de problemas se o GFS2 tentar implementar bloqueios POSIX a partir do NFS através dos nós de um cluster. Para aplicações rodando em clientes NFS, fechaduras POSIX localizadas significam que dois clientes podem segurar a mesma fechadura simultaneamente se os dois clientes forem montados a partir de servidores diferentes, o que poderia causar corrupção de dados. Se todos os clientes montam NFS a partir de um servidor, então o problema de servidores separados concedendo os mesmos bloqueios independentemente vai embora. Se você não tiver certeza se deve montar seu sistema de arquivos com a opção localflocks, você não deve usar a opção. Contate imediatamente o suporte da Red Hat para discutir a configuração apropriada a fim de evitar a perda de dados. A exportação do GFS2 via NFS, embora tecnicamente suportada em algumas circunstâncias, não é recomendada.
Para todas as outras aplicações (não-NFS) GFS2, não monte seu sistema de arquivos usando localflocks, para que o GFS2 gerencie os bloqueios POSIX e os bandos entre todos os nós do cluster (em uma base de cluster). Se você especificar localflocks e não usar NFS, os outros nós do aglomerado não terão conhecimento dos bloqueios e bandos POSIX uns dos outros, tornando-os assim inseguros em um ambiente agrupado
Além das considerações de bloqueio, você deve levar em conta o seguinte ao configurar um serviço NFS sobre um sistema de arquivos GFS2.
A Red Hat suporta apenas as configurações do Red Hat High Availability Add-On usando NFSv3 com travamento em uma configuração ativa/passiva com as seguintes características. Esta configuração fornece Alta Disponibilidade (HA) para o sistema de arquivo e reduz o tempo de inatividade do sistema, já que um nó com falha não resulta na necessidade de executar o comando
fsckquando falha o servidor NFS de um nó para outro.- O sistema de arquivo back-end é um sistema de arquivo GFS2 que roda em um cluster de 2 a 16 nós.
- Um servidor NFSv3 é definido como um serviço que exporta todo o sistema de arquivos GFS2 a partir de um único nó de cluster de cada vez.
- O servidor NFS pode falhar de um nó de cluster para outro (configuração ativa/passiva).
- Nenhum acesso ao sistema de arquivos GFS2 é permitido except através do servidor NFS. Isto inclui tanto o acesso ao sistema de arquivos local GFS2 quanto o acesso através do Samba ou Clustered Samba. O acesso ao sistema de arquivo localmente através do nó de cluster a partir do qual ele é montado pode resultar em corrupção de dados.
- Não há suporte de cota NFS no sistema.
-
A opção
fsid=NFS é obrigatória para as exportações NFS de GFS2. - Se surgirem problemas com seu agrupamento (por exemplo, o agrupamento se torna inquieto e a vedação não é bem sucedida), os volumes lógicos do agrupamento e o sistema de arquivos GFS2 serão congelados e nenhum acesso será possível até que o agrupamento seja quorato. Você deve considerar esta possibilidade ao determinar se uma simples solução de failover, como a definida neste procedimento, é a mais apropriada para seu sistema.
