NFS redundante na Amazon EC2

4

Estou interessado em criar dois servidores NFS tolerantes a falhas / redundantes com failover no Amazon EC2. Estou familiarizado com ferramentas / tecnologias como DRBD, Heartbeat, etc. A Amazon fornece alguma maneira específica de alcançar isso através de sua plataforma?

Um exemplo adequado pode ser que os arquivos sejam mantidos em um EBS separado e redundante - se ocorrer uma falha, uma nova instância será automaticamente iniciada a partir de uma AMI pré-construída, o volume do EBS será montado e o endereço IP será transferido perfeitamente.

Isso é possível? Existem plataformas melhores que a Amazon? Você pode me dar uma idéia ampla da arquitetura subjacente que estamos falando para conseguir isso?

    
por Trent Scott 09.01.2012 / 03:26

2 respostas

9

Na AWS, o uso do GlusterFS com um Elastic Load Balancer e instâncias EC2 de escalonamento automático deve atingir o que você deseja. Não posso comentar sobre qualquer outra IaaS.

A Amazon fornece um pouco do que você precisa para atingir seu objetivo - e permite que você implemente o restante.

Os servidores EC2 da Amazon são essencialmente VPSes - você pode configurar Heartbeat / Corosync / Pacemaker, etc neles (embora da última vez que verifiquei, você não pode usar broadcast em sua rede - você pode usar unicast embora - udpu).

Você menciona duas ideias que a Amazon aborda (um pouco) separadamente: tolerância a falhas e redundância.

Não há mecanismo embutido para redundância no EC2, embora dependendo do que você está procurando, existem algumas maneiras de alcançá-lo.

  • Teoricamente, o S3 é projetado com várias camadas de redudancy e "projetado para fornecer 99,999999999% de durabilidade de objetos em um determinado ano ". Seu SLA é para 99,9% de disponibilidade por ano. Se você quiser seguir essa rota para arquivos estáticos, poderá montar um bucket do S3 usando o s3fuse como um sistema de arquivos local. Isso é bastante lento, no entanto, e não é realmente aconselhável para a maioria das finalidades (código, banco de dados, software de servidor, etc.).
  • Os instantâneos do
  • EBS fornecerão a você uma imagem de ponto-no-tempo diferencial e compactada do seu volume do EBS. Estes são ótimos como um backup - e você pode lançar novas instâncias a partir de um instantâneo - eles não são, no entanto, a redundância verdadeira.
  • Para qualquer solução de redundância real, você deve configurá-lo por conta própria. Uma abordagem projetada para esse problema é o GlusterFS. Você pode configurar seus blocos como distribuídos, replicados ou ambos, e os dados serão espalhados pelo sistema - eles são resilientes à remoção de nós individuais, e eles têm uma AMI pré-construída da qual você pode iniciar várias instâncias para criar um cluster.

A tolerância a falhas, por outro lado, é melhor fornecida pela plataforma da Amazon:

  • A rede do EC2 oferece várias regiões e zonas de disponibilidade - que (teoricamente) fornecem centros de dados isolados e / ou separados geograficamente para evitar pontos únicos de falha
  • A Amazon oferece monitoramento (Cloudwatch) de várias métricas de instância (CPU, rede, E / S de disco, etc.), além de métricas personalizadas. Estes podem ser usados como um gatilho para o lançamento de novas instâncias a partir de uma AMI pré-construída, um processo chamado 'Auto scaling'.
  • O EC2 tem endereços Elastic IP - esses são endereços IP públicos que podem ser reservados e rapidamente remapeados para outra instância sob demanda, permitindo evitar atrasos de propagação de DNS quando uma instância fica inativa.
  • Finalmente, a Amazon tem balanceadores Elastic Load - eles devem ser projetados para evitar um único ponto de falha e para escalar com o tráfego de entrada (eles não sofrem as mesmas limitações de largura de banda que uma única instância configurada como um balanceador de carga estaria sujeito a). Os ELBs podem monitorar a "integridade" das instâncias de back-end e trabalhar com o escalonamento automático para manter um número apropriado de instâncias.

Além do acima, você pode passar parâmetros personalizados para suas instâncias recém-lançadas ou recuperar informações sobre suas instâncias em execução com bastante facilidade - o que pode permitir que você faça o script de algumas das configurações (e, é claro, a AWS uma API que permitirá que você crie scripts de todas as ações que eles oferecem - incluindo o remapeamento de um endereço IP elástico, o lançamento de novas instâncias, a remoção / anexação de volumes do EBS, etc.).

Você descreveu que 'arquivos são mantidos em um EBS separado e redundante ... [que é então] montado'. Em primeiro lugar, no EC2, um volume do EBS só pode ser anexado a uma instância de cada vez (para copiar dados para ele, o volume do EBS precisaria ser anexado). Cabe a você manter a redundância (você pode configurar matrizes RAID de dispositivos EBS ou fazer praticamente qualquer outra coisa). O problema, no entanto, é que às vezes os volumes do EBS não são desconectados quando uma instância falha - você pode forçar a desconexão deles (que tem uma taxa de sucesso melhor, mas não perfeita), e você pode tirar um instantâneo de um volume do EBS, mesmo em uso você poderia então criar um novo volume do EBS e iniciar um AMI usando). É melhor (menor tempo para recuperar, mais flexível, etc), para manter réplicas de seus dados em várias instâncias, ao contrário de vários volumes do EBS na mesma instância.

    
por 09.01.2012 / 04:34
-1

Outra opção é usar o Zadara Storage, que é um NFS "como um serviço". Por ser um serviço, você não precisa gerenciar a pilha do servidor NFS e é o HA por padrão. Você nem precisa pagar pelas instâncias do servidor NFS. Você pode conectar todas as máquinas EC2 aos seus compartilhamentos usando o NFS padrão.

Divulgação: Estou com o Zadara Storage.

    
por 29.08.2013 / 00:58