GFS2 - GFS2

Na computação , o Global File System 2 ou GFS2 é um sistema de arquivo de disco compartilhado para clusters de computador Linux . O GFS2 permite que todos os membros de um cluster tenham acesso simultâneo direto ao mesmo armazenamento de bloco compartilhado , em contraste com os sistemas de arquivos distribuídos que distribuem dados por todo o cluster. O GFS2 também pode ser usado como um sistema de arquivos local em um único computador.

O GFS2 não possui modo operacional desconectado e não possui funções de cliente ou servidor. Todos os nós em um cluster GFS2 funcionam como pares. Usar o GFS2 em um cluster requer hardware para permitir acesso ao armazenamento compartilhado e um gerenciador de bloqueio para controlar o acesso ao armazenamento. O gerenciador de bloqueio opera como um módulo separado: assim, o GFS2 pode usar o Gerenciador de Bloqueio Distribuído (DLM) para configurações de cluster e o gerenciador de bloqueio "nolock" para sistemas de arquivos locais. Versões mais antigas do GFS também suportam GULM, um gerenciador de bloqueio baseado em servidor que implementa redundância via failover.

GFS e GFS2 são softwares livres , distribuídos sob os termos da GNU General Public License .

História

O desenvolvimento do GFS começou em 1995 e foi originalmente desenvolvido pelo professor da Universidade de Minnesota , Matthew O'Keefe, e um grupo de alunos. Ele foi originalmente escrito para SGI 's IRIX sistema operacional, mas em 1998 ele foi portado para Linux já que o código aberto código fornecido uma plataforma de desenvolvimento mais conveniente. No final de 1999 / início de 2000, ele abriu caminho para a Sistina Software , onde viveu por um tempo como um projeto de código aberto. Em 2001, a Sistina optou por tornar o GFS um produto proprietário.

Os desenvolvedores separaram o OpenGFS da última versão pública do GFS e, em seguida, aprimoraram-no para incluir atualizações que permitem que funcione com o OpenDLM. Mas OpenGFS e OpenDLM tornaram-se extintos, uma vez que a Red Hat comprou a Sistina em dezembro de 2003 e lançou o GFS e muitas peças de infraestrutura de cluster sob a GPL no final de junho de 2004.

A Red Hat subseqüentemente financiou mais desenvolvimento voltado para correção de bugs e estabilização. Um desenvolvimento adicional, o GFS2 deriva do GFS e foi incluído junto com seu gerenciador de bloqueio distribuído (compartilhado com o GFS) no Linux 2.6.19. O Red Hat Enterprise Linux 5.2 incluiu o GFS2 como um módulo do kernel para fins de avaliação. Com a atualização 5.3, o GFS2 tornou-se parte do pacote do kernel.

O GFS2 faz parte do Fedora , Red Hat Enterprise Linux e distribuições CentOS Linux associadas . Os usuários podem adquirir suporte comercial para executar o GFS2 totalmente suportado no Red Hat Enterprise Linux . A partir do Red Hat Enterprise Linux 8.3, o GFS2 é suportado em ambientes de computação em nuvem nos quais dispositivos de armazenamento compartilhado estão disponíveis.

A lista a seguir resume alguns números de versão e principais recursos introduzidos:

• v1.0 (1996) SGI IRIX apenas
• porta v3.0 para Linux
• diário v4
• Gerenciador de bloqueio redundante v5
• v6.1 (2005) Gerenciador de bloqueio distribuído
• Linux 2.6.19 - GFS2 e DLM fundidos no kernel Linux
• O Red Hat Enterprise Linux 5.3 lança o primeiro GFS2 totalmente suportado

Hardware

O design do GFS e do GFS2 visa ambientes semelhantes a SAN . Embora seja possível usá-los como um sistema de arquivos de nó único, o conjunto completo de recursos requer uma SAN. Isso pode assumir a forma de iSCSI , FibreChannel , AoE ou qualquer outro dispositivo que pode ser apresentado no Linux como um dispositivo de bloco compartilhado por vários nós, por exemplo, um dispositivo DRBD .

O DLM requer uma rede baseada em IP para se comunicar. Normalmente é apenas Ethernet , mas, novamente, existem muitas outras soluções possíveis. Dependendo da escolha de SAN, pode ser possível combinar isso, mas a prática normal envolve redes separadas para o DLM e o armazenamento.

O GFS exige uma esgrima mecanismo de algum tipo. Este é um requisito da infraestrutura do cluster, em vez do próprio GFS / GFS2, mas é necessário para todos os clusters de vários nós. As opções usuais incluem interruptores de energia e controladores de acesso remoto (por exemplo , DRAC , IPMI ou ILO ). Mecanismos de fencing virtuais e baseados em hipervisor também podem ser usados. Fencing é usado para garantir que um nó que o cluster acredita estar com falha não possa voltar a funcionar repentinamente enquanto outro nó está recuperando o diário para o nó com falha. Ele também pode, opcionalmente, reiniciar o nó com falha automaticamente assim que a recuperação for concluída.

Diferenças de um sistema de arquivos local

Embora os designers do GFS / GFS2 tenham como objetivo emular um sistema de arquivos local de perto, há uma série de diferenças a serem observadas. Algumas delas são devido às interfaces do sistema de arquivos existentes não permitindo a passagem de informações relacionadas ao cluster. Algumas decorrem da dificuldade de implementar esses recursos de maneira eficiente de maneira agrupada. Por exemplo:

• A chamada de sistema flock () no GFS / GFS2 não é interrompida por sinais .
• A chamada de sistema fcntl () F_GETLK retorna um PID de qualquer bloqueio de bloqueio. Como este é um sistema de arquivos de cluster, esse PID pode se referir a um processo em qualquer um dos nós que possuem o sistema de arquivos montado. Como o objetivo dessa interface é permitir que um sinal seja enviado ao processo de bloqueio, isso não é mais possível.
• Concessões não são suportadas com o módulo de bloqueio lock_dlm (cluster), mas são suportadas quando usadas como um sistema de arquivos local
• dnotify funcionará na base do "mesmo nó", mas seu uso com GFS / GFS2 não é recomendado
• O inotify também funcionará na base do "mesmo nó" e também não é recomendado (mas pode se tornar compatível no futuro)
• splice é suportado apenas em GFS2

A outra diferença principal, e que é compartilhada por todos os sistemas de arquivos de cluster semelhantes, é que o mecanismo de controle de cache, conhecido como glocks (pronuncia-se Gee-locks) para GFS / GFS2, tem um efeito em todo o cluster. Cada inode no sistema de arquivos tem dois glocks associados a ele. Um (chamado de iopen glock) controla quais processos têm o inode aberto. O outro (o inode glock) controla o cache relacionado a esse inode. Um glock tem quatro estados, UN (desbloqueado), SH (compartilhado - um bloqueio de leitura), DF (adiado - um bloqueio de leitura incompatível com SH) e EX (exclusivo). Cada um dos quatro modos mapeia diretamente para um modo de bloqueio DLM .

Quando no modo EX, um inode tem permissão para armazenar dados e metadados em cache (que podem estar "sujos", ou seja, aguardando a gravação de volta no sistema de arquivos). No modo SH, o inode pode armazenar dados e metadados em cache, mas não deve estar sujo. No modo DF, o inode tem permissão para armazenar metadados em cache apenas e, novamente, não deve estar sujo. O modo DF é usado apenas para E / S direta. No modo ONU, o inode não deve armazenar nenhum metadado em cache.

Para que as operações que alteram os dados ou metadados de um inode não interfiram umas com as outras, é usado um bloqueio EX. Isso significa que certas operações, como criar / desvincular arquivos do mesmo diretório e gravar no mesmo arquivo, devem ser, em geral, restritas a um nó no cluster. Obviamente, fazer essas operações a partir de vários nós funcionará conforme o esperado, mas devido à necessidade de liberar caches com frequência, não será muito eficiente.

A única pergunta mais frequente sobre o desempenho do GFS / GFS2 é por que o desempenho pode ser ruim com servidores de e-mail. A solução é dividir o spool de correio em diretórios separados e tentar manter (na medida do possível) cada nó lendo e gravando em um conjunto privado de diretórios.

Journaling

GFS e GFS2 são ambos sistemas de arquivos registrados ; e o GFS2 suporta um conjunto semelhante de modos de journaling como ext3 . No modo data = writeback , apenas os metadados são registrados. Este é o único modo suportado pelo GFS, no entanto, é possível ativar o registro em diário em arquivos de dados individuais, mas apenas quando eles são de tamanho zero. Os arquivos registrados no GFS têm uma série de restrições impostas a eles, como nenhum suporte para as chamadas de sistema mmap ou sendfile; eles também usam um formato em disco diferente dos arquivos regulares. Há também um atributo "inherit-journal" que, quando definido em um diretório, faz com que todos os arquivos (e subdiretórios) criados nesse diretório tenham o sinalizador do diário (ou do jornal herdado, respectivamente) definido. Isso pode ser usado em vez da opção de montagem data = journal que ext3 suporta (e GFS / GFS2 não).

O GFS2 também suporta o modo data = encomendado que é semelhante a data = writeback, exceto que os dados sujos são sincronizados antes de cada liberação de diário ser concluída. Isso garante que os blocos que foram adicionados a um inode terão seu conteúdo sincronizado de volta ao disco antes que os metadados sejam atualizados para registrar o novo tamanho e, assim, evita que blocos não inicializados apareçam em um arquivo sob condições de falha de nó. O modo de registro em diário padrão é data = encomendado , para corresponder ao padrão de ext3 .

A partir de 2010, o GFS2 ainda não oferece suporte ao modo data = journal , mas (ao contrário do GFS) usa o mesmo formato em disco para arquivos regulares e registrados, e também suporta os mesmos atributos de journaling e de herança. O GFS2 também relaxa as restrições de quando um arquivo pode ter seu atributo journaled alterado para qualquer momento em que o arquivo não está aberto (também o mesmo que ext3 ).

Por motivos de desempenho, cada nó no GFS e GFS2 tem seu próprio diário. No GFS, os diários são extensões de disco, no GFS2 os diários são apenas arquivos regulares. O número de nós que podem montar o sistema de arquivos a qualquer momento é limitado pelo número de diários disponíveis.

Características do GFS2 em comparação com GFS

O GFS2 adiciona uma série de novos recursos que não estão no GFS. Aqui está um resumo dos recursos ainda não mencionados nas caixas à direita desta página:

• O sistema de arquivos de metadados (na verdade uma raiz diferente) - veja Compatibilidade e o sistema de arquivos meta GFS2 abaixo
• Os pontos de rastreamento específicos do GFS2 estão disponíveis desde o kernel 2.6.32
• A interface de cotas no estilo XFS está disponível no GFS2 desde o kernel 2.6.33
• Caching ACLs estão disponíveis no GFS2 desde 2.6.33
• O GFS2 suporta a geração de solicitações de "descarte" para solicitações thin provisioning / SCSI TRIM
• O GFS2 suporta barreiras de E / S (ativado por padrão, assumindo que o dispositivo subjacente o suporte. Configurável a partir do kernel 2.6.33 e superior)
• FIEMAP ioctl (para consultar mapeamentos de inodes no disco)
• Suporte de emenda (chamada de sistema)
• Suporte a mmap / splice para arquivos registrados (habilitado usando o mesmo formato de disco usado para arquivos regulares)
• Muito menos sintonizáveis ​​(tornando a configuração menos complicada)
• Modo de gravação ordenado (de acordo com ext3, GFS só tem modo de write-back)

Compatibilidade e o meta sistema de arquivos GFS2

O GFS2 foi projetado para que a atualização do GFS seja um procedimento simples. Para este fim, a maior parte da estrutura do disco permaneceu a mesma do GFS, incluindo a ordenação de bytes big-endian . No entanto, existem algumas diferenças:

• O GFS2 tem um "meta-sistema de arquivos" através do qual os processos acessam os arquivos do sistema
• GFS2 usa o mesmo formato em disco para arquivos registrados como para arquivos regulares
• O GFS2 usa arquivos regulares (sistema) para diários, enquanto o GFS usa extensões especiais
• GFS2 tem alguns outros arquivos de sistema " per_node "
• O layout do inode é (ligeiramente) diferente
• O layout dos blocos indiretos difere um pouco

Os sistemas de journaling do GFS e GFS2 não são compatíveis entre si. A atualização é possível por meio de uma ferramenta ( gfs2_convert ) que é executada com o sistema de arquivos off-line para atualizar os metadados. Alguns blocos sobressalentes nos diários GFS são usados ​​para criar os arquivos per_node (muito pequenos) exigidos pelo GFS2 durante o processo de atualização. A maioria dos dados permanece no local.

O "meta sistema de arquivos" do GFS2 não é um sistema de arquivos por si só, mas uma raiz alternativa do sistema de arquivos principal. Embora se comporte como um sistema de arquivos "normal", seu conteúdo são os vários arquivos de sistema usados ​​pelo GFS2, e normalmente os usuários não precisam nunca olhar para eles. Os utilitários GFS2 montam e desmontam o meta sistema de arquivos conforme necessário, nos bastidores.

Veja também

• Comparação de sistemas de arquivos
• GPFS , ZFS , VxFS
• Brilho
• GlusterFS
• Lista de sistemas de arquivos
• OCFS2
• QFS
• Sistema de arquivos SAN
• Esgrima
• Open-Sharedroot
• Ceph (software)

Referências

links externos

• Red Hat Red Hat Enterprise Linux 6 - Sistema de Arquivos Global 2
• Red Hat Cluster Suite e página de documentação GFS
• Página do Projeto GFS
• Página do projeto OpenGFS (obsoleto)
• A árvore git de desenvolvimento do GFS2
• A árvore git de desenvolvimento de utilitários do GFS2