NFS de alta disponibilidade

Question

Estamos pensando em hospedar um aplicativo da Web no Amazon AWS. Desenhei uma configuração proposta para isso, que tentarei resumir em algumas linhas:

• O aplicativo da Web é veiculado em servidores da Web em 3 zonas de disponibilidade, atrás de um balanceador de carga. Os servidores da Web são automaticamente aumentados de 3 quando a carga aumenta. Isso é feito por meio de um arquivo de dados do usuário que executa alguns comandos bash.
• O banco de dados é colocado em uma solução Multi-AZ RDS
• Como o aplicativo grava no sistema de arquivos, também precisamos montar algum tipo de sistema de arquivos conectado à rede na webroot.

A última parte é o que me preocupa. Eu tenho alguma experiência com AWS e além de lidar com a latência entre duas Zonas de Disponibilidade, isso forneceria um único ponto de falha.

Então, eu tenho olhado para o GlusterFS, porque é isso que alguém em serverfault sugeriu para alguém que estava lidando com um pickle similar. Eu tenho configurado um ambiente com um nó Gluster em cada AZ. No script de inicialização dos meus servidores da Web, avalio o nome do AZ em que ele está e escolho o nó do Gluster que está no mesmo AZ para reduzir a latência. Isso é perfeito!

Mas digamos que o nó em AZ us-east-1a falhe de alguma forma. Existe uma maneira de recuperar meus servidores da web em us-east-1a para o nó em us-east-1b se o nó em us-east-1a não estiver disponível? E, claro, se ambos estiverem indisponíveis, também para us-east-1c ?

Até agora, só vi exemplos de pessoas usando a funcionalidade de servidor e cliente do Gluster nas mesmas máquinas, o que eu gostaria de evitar. Provavelmente é bom notar que usarei o cliente NFS por motivos de desempenho.

É claro que qualquer outra sugestão para este sistema de armazenamento de arquivos seria muito bem-vinda.

    

Answer 1

Gostaria de atualizar qualquer pessoa interessada em como decidi fazer isso. Como eu disse, S3 não se adequa a nossa situação, que é provavelmente algo com que mais pessoas lutam.

Gluster parecia o caminho a percorrer na época, porque se destina especificamente a fazer essas coisas. No entanto, em nosso ambiente de testes, a velocidade do Glusters nos atrasou. Sim, as transferências de arquivos para um sistema de arquivos Gluster são muito rápidas, mas fazemos muitas pesquisas e leituras e gravações rápidas nesses volumes montados e, ao testar cargas mais altas, isso se tornou um gargalo. O cliente Gluster NFS é muito mais rápido para essas operações, mas não suporta a tolerância a falhas interna do Glusters.

Então, voltamos à nossa ideia original: simplesmente usando um servidor NFS com um failover em outro AZ. Para manter os nós em sincronia, usamos DRBD . Contornamos o problema de não ter um IP virtual usando o VTun (estou muito aberto a outras sugestões) e estou usando o Heartbeat para promover o escravo quando o mestre está inativo.