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.