Sistema de arquivos compartilhado replicado

Question

Eu estou olhando para a criação de um sistema de arquivos / servidor de arquivos compartilhados na infraestrutura da AWS (EC2) que oferece replicação e failover indolor. Esse sistema de arquivos hospedaria potencialmente milhões de arquivos com alguns megas de tamanho. Esses arquivos seriam acessados (leitura / gravação) de várias VMs cliente. Se o servidor de arquivos primário falhar, eu quero que os clientes façam failover para o servidor de arquivos de réplica sem perder nenhum arquivo (por exemplo, eu quero que a replicação seja em tempo real). Eu olhei algumas opções:

• Use S3 com s3fs. Estou preocupado com a latência de cada solicitação será problemática ao executar operações em milhares de arquivos (por exemplo, ao copiar / mover arquivos ao redor). Eu também ouvi alguns relatórios que me fazem questionar a estabilidade do s3fs - não tenho certeza se ainda é o caso.
• Configure um servidor NFS em uma instância do EC2, usando drbd para replicar blocos entre duas instâncias. Desvantagens:
  1. Eu tive problemas de confiabilidade com o drbd no passado, especialmente em links de alta latência
  2. Se o servidor NFS principal ficar inativo, os clientes serão removidos, exigindo a intervenção do sysadmin e / ou reinicializações para fazer com que eles se reconectem ao servidor secundário. Não há failover automático.

Existe alguma solução melhor?

    

Answer 1

Apenas algumas informações atualizadas. Se você é como eu e deseja essa funcionalidade por um período MUITO MUITO longo, use o Amazon Elastic File System (EFS). É uma montagem do NFS replicada em várias zonas de disponibilidade.

(Desculpe por resolver o problema, mas o ranking do Google dessa resposta é alto o suficiente para que algumas pessoas provavelmente estejam procurando por essa solução.)

    

Answer 2

É possível, embora não trivial, configurar NFS Clusters no Amazon EC2 usando DRBD para replicação síncrona e Pacemaker + Corosync para automatizar o failover do serviço NFS e exportar entre nós (sem interromper o acesso do cliente).

Se você estiver planejando replicar de forma síncrona ("em tempo real"), precisará que ambas as instâncias do EC2 estejam na mesma zona para limitar a latência entre elas; caso contrário, a latência da rede se traduzirá em latência de disco.

Além disso, não é possível atribuir / cancelar a atribuição de um endereço IP facilmente nas instâncias do Amazon EC2; você precisa usar sua API (ou usar seu web-gui) para reatribuir um endereço IP. Mover um endereço IP é necessário para o endereço IP flutuante que os clientes usarão para se conectar ao nó ativo. Alguma modificação do agente de recursos do marca-passo 'IPaddr2' será necessária para que isso funcione; é um script bash.

    

Answer 3

Dada a complexidade de configurar um servidor NFS replicado, optamos por usar o S3. O desempenho de s3fs-fuze foi péssimo (fazer um ls em um diretório com mais de 1.000 arquivos seria próximo a um minuto devido à necessidade de consultar os metadados de cada arquivo, e o armazenamento em cache não pareceu ajudar). No entanto, experimentei o RioFS , que me forneceu respostas instantâneas nas operações de diretório e, em geral, senti-me muito rápido.

Ainda estou planejando investigar algumas opções adicionais ( S3QL e YAS3FS em particular) mas até agora as opções parecem promissoras.