Não há estatísticas MTBF publicadas. "Mais frequentemente do que você gostaria" é sobre o melhor que você vai conseguir. Além disso, os outros pôsteres forneceram excelentes respostas sobre como lidar com a arquitetura de sua aplicação.
Atualmente, estou executando uma única instância do EC2 e pretendo migrar para uma arquitetura tolerante a falhas. Algo que me ajudará a decidir quão urgente é essa migração é o EC2 MTBF.
Existe algum dado sobre quantas vezes as máquinas EC2 falham?
Eu geralmente espero que o MTBF seja maior para as instâncias do EC2 do que para o hardware de ponta que eu compraria e colocaria em um data center.
A grande diferença é que posso projetar minha configuração do EC2 para que, quando uma instância falhar, eu possa abrir uma nova dentro de minutos após ser alertado e chegar a uma conexão com a Internet. Este é um contraste enorme para o que eu costumava fazer quando um servidor falhava em uma colo a 40 minutos de distância, onde eu tinha que dirigir até lá, depurar os problemas de hardware, instalar peças de reposição se eu as tivesse em mãos. p>
Por exemplo, se um hardware subjacente de uma instância falhar, você pode descartá-lo e mudar para um novo hardware com alguns comandos:
A Simpler Way To Replace Instance Hardware on EC2
http://alestic.com/2011/02/ec2-move-hardware
Portanto, embora algumas vezes eu projete para replicação e recuperação automatizada ou failover, outras vezes eu me vejo vivendo com o risco de um pouco de inatividade porque é tão fácil recuperar manualmente.
Configuração de instância de documento / script (instalação / configuração de software) para que você possa reproduzi-lo a qualquer momento. Tire instantâneos regulares. Faça backups regulares de seus dados (além de instantâneos). Mantenha cópias de backups fora do local (fora do EC2).
Se você precisa de um tempo extra de disponibilidade, opte pelas arquiteturas replicadas, redundantes, failover e escalonamento automático mais complicadas, que a AWS também torna mais fácil do que com o hardware físico.
Isso é algo que pesquisei para um projeto da empresa e, infelizmente, não é realmente possível quantificá-lo. Como há um número tão grande de nós no EC2, e a computação em cluster é inerentemente instável devido ao grande número de máquinas em funcionamento, é realmente um fator do seguinte: a sua aplicação pode lidar com falhas?
Vale ressaltar que os maiores problemas parecem ser pontos únicos de falhas (obviamente). Não hospede seu único banco de dados na nuvem, um único armazenamento de arquivos, etc. As falhas de disco no EC2 não são exatamente comuns, mas eu já vi experiências de taxas de falha de disco de 0,0001% a 2%. Pesquisando (e verificando as placas do EC2) você terá mais evidências disso. Para armazenamento a longo prazo - ou armazenamento "mais confiável" - confira o Amazon S3.
Em geral, você não deve exibir instâncias do EC2 como substituições de servidores no seu próprio datacenter ou co-lo. Em vez disso, você deve vê-los como trabalhadores em meio-período - muitos aparecerão, a maioria fará um bom trabalho, mas de vez em quando, um deles vai ficar doente ou desistir. Quando isso acontece, seu aplicativo precisa ser capaz de lidar com a perda, seja com corrupção de dados ou com um servidor que esteja saindo da linha. Se puder (como você diz), a computação em nuvem é uma boa ideia.
Tags amazon-ec2