Como você automatiza o failover no EC2?

Question

Das pessoas que gerenciam seus próprios clusters (ou seja, não usam / pagam para Amazon Autoscale, Rightscale, Scalr, etc.), como você está gerenciando suas instâncias no EC2 e lidando com (por exemplo) failover? Eu estou querendo saber se a maioria das pessoas acabam escrevendo seus próprios pacotes de scripts contra a API do EC2, como eu suspeito.

Essa é certamente a nossa abordagem: preparar nosso próprio daemon de monitoramento / reinicialização baseado em Boto do Python que roda fora do local, ouvindo as alas guardadas do UDP de nossas instâncias. Em caso de falha, capturamos volumes, registramos imagens, iniciamos novas instâncias, excluímos volumes antigos e assim por diante.

De vez em quando, quando hackeamos nossos scripts, eu acho que deve haver algumas ferramentas de código aberto que já lidam com esses problemas, e que não têm as restrições de (digamos) Scalr, mas eu sempre venho de volta do Google de mãos vazias. (Coisas como Scalr são bastante limitadas no conjunto / versões / configurações suportadas de software, e têm maneiras especializadas e incômodas de manipular essas configurações.)

Além disso, o ecossistema Linux-HA / Pacemaker (Heartbeat, ldirectord, etc.) soa como não é realmente adequado para o EC2 . (Mas então eu encontrei isso - embora eu não tenha certeza se isso é realmente de alta qualidade solução).

    

Answer 1

Bem, não quero dizer apenas o óbvio, mas a ideia geral é levar essa complexidade para os serviços gerenciados pela Amazon.

Então, no frontend, você usaria o ELB (Elastic Load Balancing) para fornecer balanceamento de carga altamente disponível. No final, você usa o Amazon Relational Database Service (MySQL hospedado), SimpleDB e S3 para armazenamento. Todos eles são gerenciados pela Amazon e contêm algum tipo de manipulação de alta disponibilidade / failover.

Isso normalmente deixa seus servidores de aplicativos da web e todos os tipos de servidores menos comuns que você pode estar usando (servidores de renderização, armazenamentos de dados NoSQL autoinstalados, etc).

Os servidores Webapp geralmente são bem administrados com as verificações de integridade incorporadas no ELB. Você pode aceitar uma pequena degradação de desempenho quando um servidor webapp estiver inativo ou provisionar consistentemente um servidor mais do que o necessário. Ou, se sua configuração for simples, quando um servidor webapp falhar, o ELB, junto com a Cloudwatch, poderá gerar automaticamente um novo servidor webapp para você.

Seus próprios servidores personalizados são outro assunto. Para eles, é verdade, você está sozinho e precisará se contentar com os métodos incorporados do aplicativo, ou colocar fita adesiva junto com scripts personalizados / ferramentas de alta disponibilidade de código aberto.

A solução da compra da Rightscale pode ser muito cara. Mas as ferramentas menos dispendiosas da Amazon, como o ELB, o alerta básico do CloudWatch (agora disponível para resolução de 5 minutos) ou o AutoScale, valem a pena se você precisar de alta disponibilidade.

    

Answer 2

RightScale tem alguns ótimos artigos sobre como automatizar o failover no EC2. Embora a maioria deles mostre como fazer isso usando o RightScale, os princípios são gerais e provavelmente úteis para qualquer um que esteja pensando em como configurar uma arquitetura de failover no EC2.

    

Answer 3

Os problemas que você descreve (HA, monitoramento de servidores personalizados, serviços de 'duto-gravação') geralmente são tratados por um provedor de PaaS. A Rightscale e a Scalr já foram mencionadas em uma resposta anterior e há outras boas opções (veja aqui algumas opções de PaaS:

link )

Você deve considerar qual dos provedores se ajusta melhor ao que você precisa.

Aviso: Eu trabalho para o cloudify, um provedor de PaaS de código aberto.

    

Answer 4

Recentemente, escrevi uma postagem em nosso blog de engenharia sobre como usar o ELB em conjunto com o Auto Scaling para obter failover automático para qualquer tipo de aplicativo. Ele aborda como as verificações de integridade do ELB podem ser usadas para executar o ping do status do seu aplicativo e acionar ações de dimensionamento automático.

    

Answer 5

Você instala o heartbeat em ambos os servidores Você anexa um Elastic IP ao servidor 'ativo' Você configura um script para fazer o failover iniciando uma solicitação de API para obter o IP elástico Assim que o servidor 'stand-by' tiver o IP elástico (demora cerca de 30 a 60 segundos), ele pode ser o mestre / ativo.

Eu não tenho os detalhes para fornecer aqui.

    

Answer 6

A Amazon já oferece Balanceamento Elástico de Carga ... Por que reinventar a roda?