Fazer Marcapasso, Batimento Cardíaco, etc. faz sentido para o EC2?

Question

O ecossistema do pacemaker (Corosync etc.) faz sentido no contexto do EC2? Até certo ponto, o Corosync exigia multicast IP (não disponível no EC2), mas acho que já foi transmitido. Ainda assim, são Pacemaker et. al. a ferramenta certa para um cluster gerenciar-se no EC2, por ex. monitorar um ao outro quanto a falhas e, assim, acionar novas instâncias para substituir as falhas?

Acho que parte do problema é que passei um bom tempo apenas corrigindo todos os jogadores aqui (Heartbeat, Corosync, OpenAIS, etc.), e ainda estou tentando descobrir o que é isso. as coisas realmente são (além de termos nebulosos, por exemplo, que o Pacemaker é um "gerenciador de recursos de cluster" e que o Corosync fornece "infra-estrutura confiável de mensagens e associação").

Por isso, peço desculpas se minha pergunta em si é um pouco trapalhão ou não faz completamente sentido. Qualquer introspecção seria muito bem recebida. Obrigado.

    

Answer 1

O EC2 monitora a integridade dos serviços dentro dos convidados?

Se não, e isso é algo que você quer, o Pacemaker seria relevante aqui. O Corosync provavelmente ainda não é uma opção, já que só faz mcast e bcast, então seria um cenário de marca-passo + heartbeat.

Aqui está um guia de como as pessoas fazem isso com as instâncias do linode, muito do que provavelmente também é relevante no EC2: link

Para responder à pergunta sobre quais são as peças, o Pacemaker é o que inicia e interrompe os serviços e contém lógica para garantir que eles estão sendo executados e que estão sendo executados em apenas um local (para evitar corrupção de dados) .

Mas ele não pode fazer isso sem a capacidade de falar com ele mesmo nos outros nós, que é onde a pulsação e / ou o corosync entram.

Pense em heartbeat e corosync como um barramento no qual qualquer nó pode enviar mensagens e saber que elas serão recebidas por todos os seus pares. O ônibus também garante que todos concordem com quem está (e não está) conectado ao ônibus e informa quando a lista muda.

Para dois nós, o Pacemaker poderia facilmente usar soquetes, mas além disso, a complexidade cresce rapidamente e é muito difícil de acertar - então, faz sentido usar componentes existentes que se mostraram confiáveis.

    

Answer 2

Meu instinto de nível é dizer não, essas não são realmente as ferramentas certas para o gerenciamento de cluster no EC2. Eu os usei em hardware independente e descobri que você tem que ter um conjunto muito específico de necessidades / casos de falhas para que eles realmente façam sentido. Eu não posso inventar um caso de uso em minha mente que exigiria essas ferramentas sobre sistemas e ferramentas de monitoramento de nuvem mais específicos, como mensagens desenvolvidas com a plataforma em mente.

Dito isso, não considero minha resposta autoritativa aqui, estou realmente esperando que alguém concorde com um pouco mais de experiência com essa ferramenta definida na nuvem ec2.

    

Answer 3

As instâncias do EC2 são muito semelhantes ao hardware real para fins de gerenciamento. Se desce, desce (ou se o host físico fica inativo). Não há mecanismo intrínseco para failover no EC2. Você recebe o benefício para reiniciar a instância e ela reaparecerá "magicamente", sem qualquer intervenção física ou manutenção, mas você ainda terá que fazê-lo, manual ou automaticamente (talvez o EC2 o reinicie para você, eu não agora isso). Isso pode significar uma interrupção de vários minutos.

Se você quiser uma solução de HA, ela provavelmente será mais rápida em termos de recuperação, mas você terá que manter 2 instâncias do EC2 ativas o tempo todo.

Mas a arquitetura ideal para o EC2 é ter várias instâncias para o serviço que você deseja, todas executando em paralelo e atendendo a solicitações, e se uma delas morrer, as outras irão obter a folga.