Cluster do Meta Data Server (MDS) para pnfs

2

TL; DR

O pNFS parece um ótimo método para múltiplos acessos simultâneos ao armazenamento compartilhado centralizado, mas tem um problema: o único servidor NFS que fornece metadados NFS (servidor de metadados, MDS) é um ponto único de falha. Se o MDS ficar inacessível, o armazenamento compartilhado ficará inacessível em pouco tempo.

Para evitar esse problema, estou tentando configurar um cluster MDS. Como isso pode ser conseguido sem negar aos clientes I / O direto com o armazenamento centralizado ?

Existem soluções para o HA-NFS, mas todas quebram o recurso direto de E / S do pNFS.

A longa história

Estou explorando (várias) opções para implementar um "armazenamento de dados" compartilhado para um ambiente OpenStack.

Atualmente, estou vendo cenários em que o armazenamento é servido como armazenamento em bloco de um sistema de armazenamento centralizado. Nesses cenários, surgem problemas, porque a maioria dos sistemas de arquivos não pode ser montada várias vezes de forma concorrente com segurança, pelo menos não quando há E / S simultânea de leitura e gravação de vários hosts.

Uma abordagem possível para o problema de montagem múltipla pode ser o NFS 4.1 em combinação com o XFS. Começando com esta versão, há o pNFS, que permite E / S baseada em block clients direta do NFS com o sistema de armazenamento. De acordo com a documentação do kernel, atualmente apenas o XFS suporta o layout do bloco nfs.

Com essa abordagem, o servidor NFS exporta o compartilhamento para os clientes como de costume, mas quando um cliente realmente faz E / S, ele interage diretamente com o sistema de armazenamento, não com o servidor NFS. Especialmente com o caso de uso de máquinas virtuais (que pode ser assumido para rodar apenas em um host de cada vez), isso parece um ótimo ajuste.

The NFS server which exports the share to the clients is a single point of failure. If it goes down, no additional clients can mount the share and no unopened files can be accessed. The solution is a cluster of NFS servers where another server can take over if a server fails. How can pNFS servers be clustered?

Existem alguns tutoriais sobre clustering NFS com a ajuda de gluster ou drbd. As soluções baseadas nesses ajudantes indicam que a E / S de dados é executada entre o cliente NFS e o servidor NFS. No entanto, o recurso intrigante do pNFS é que a E / S de dados é executada entre o cliente NFS e o sistema de armazenamento central, que não é o servidor NFS. Portanto, usar qualquer uma dessas abordagens quebra a característica importante do pNFS, portanto, não pode ser considerada uma solução.

Eu apreciaria muito o trabalho existente sobre isso. Mas também valorizo comentários sobre ...

minhas próprias teorias

Apesar de o pNFS estar presente e estável há alguns anos, não há muito ruído em torno dele. A pouca informação que tenho me diz isso:

  • a maioria / todos os estados estão no cliente. Isso significa que, se um servidor NFS ficar inativo, os estados não serão perdidos imediatamente.

  • quando o cliente executa E / S diretamente com o sistema de armazenamento, nenhum fluxo de dados em andamento é interrompido pelo encerramento do servidor.

Com essas informações, acho que o seguinte pode ser uma abordagem viável:

  1. Crie o LUN compartilhado e use um servidor para colocar um XFS nele.
  2. Configure o kernel nfsd em todos os servidores NFS.
  3. O grupo de servidores NFS todos monta o mesmo LUN somente leitura.
  4. Crie um ramdisk em cada servidor
  5. Use o DRBD para configurar um espelho síncrono em todos os discos ramificados
  6. Use o ramdisk espelhado síncrono para armazenar o estado dos servidores NFS montando-o em / var / lib / nfs (e reinicie o serviço nfs)
  7. Use keepalived para organizar o grupo de servidores em um cluster ativo / passivo com um VIP em que apenas um servidor está ativo por vez.
  8. Use o mecanismo de notificação keepalived para que o servidor NFS ativo monte a leitura / gravação do LUN e faça com que os outros servidores montem o LUN somente leitura.

A carga no servidor NFS "primário" seria relativamente baixa e diretamente correlacionada com as alterações nas máquinas virtuais. Portanto, ter apenas um servidor NFS por vez não parece ser um problema em ambientes de virtualização de pequeno a médio porte.

Com a maneira como o NFS 4. * funciona, o estado do servidor NFS espelhado de forma síncrona deve permitir que outro servidor assuma o controle após a falha do servidor principal. Ao usar o gluster para o diretório de estado do servidor compartilhado, acredito que isso deve permitir um cluster ativo / ativo, mas não consigo encontrar nenhum trabalho sobre isso.

Mesmo que o estado do servidor espelhado não funcione, o aumento quando outro servidor assume um cluster ativo / passivo não deve ser tão grande, pois a E / S é executada diretamente com o sistema de armazenamento central. Correto?

    
por Bananguin 05.12.2016 / 16:35

0 respostas