Alternativas ao Heartbeat, Pacemaker e CoroSync?

Existem alternativas importantes para failover automático no Linux, além das combinações típicas de Heartbeat / Pacemaker / CoroSync? Em particular, estou configurando failover em instâncias do EC2, que suportam apenas unicast - sem multicast ou broadcast. Estou especificamente tentando lidar com os poucos softwares que temos, que ainda não possuem failover automático e não oferecem suporte a ambientes multimestre. Isso inclui ferramentas como HAProxy e Solr.

Eu tenho o Heartbeat + Pacemaker funcionando, mas não estou feliz com isso. Aqui estão alguns dos meus problemas:

• Pulsação do coração - Por si só, limitada a dois nós. Eu gostaria de ter mais de 3 anos.
• Marcapasso - Impossível configurar automaticamente. O cluster precisa estar em execução com um quorum e ainda requer configuração manual.
• CoroSync - Não suporta unicast.

O pacemaker funciona muito bem, embora o seu poder dificulte a configuração. O verdadeiro problema do Pacemaker é que não há uma maneira fácil de automatizar a configuração. Eu realmente quero iniciar uma instância do EC2, instalar o Chef / Puppet e executar o cluster inteiro sem a minha intervenção.

Prefiro usar keepalived para alta disponibilidade. Acho mais simples de configurar (um daemon e config) do que a pulsação e a empresa. A única desvantagem que me deparo é que keepalived não possui uma opção unicast por padrão e usa apenas VRRP para comunicação (o autor do HAProxy escreveu um patch unicast para keepalived, no entanto)

Na verdade, estou trabalhando em algo muito semelhante ao que você descreveu (um cluster de failover no EC2) e, depois de experimentar o Heartbeat, resolvi usar o Corosync como minha camada de mensagens. O Corosync será executado em vários servidores e suporta Unicast (UDPU) a partir da versão 1.3.0 (de novembro de 2010). Eu configurei e testei o Corosync na nuvem EC2 da Amazon (usando a Linux AMI da Amazon) e posso confirmar que funciona sem problemas.

Um arquivo udpu de amostra é instalado no / etc / corosync.

Inclua um bloco de membro na seção de interface para cada nó e especifique o transporte como updu. (Eu usei a mesma porta que a pulsação no exemplo abaixo, mas você pode alterá-la conforme desejado).

por exemplo:

totem {
        version: 2
        secauth: off
        interface {
                member {
                        memberaddr: 10.xxx.xxx.xxx
                }
                member {
                        memberaddr: 10.xxx.xxx.xxx
                }
                ringnumber: 0
                bindnetaddr: 10.xxx.xxx.xxx
                mcastport: 694
        }
        transport: udpu
}

(O Heartbeat deve suportar clusters de 3 ou mais nós nas versões 1.2.3 ou mais, embora eu nunca tenha tentado pessoalmente e não sei se funcionaria com o Unicast).

Desculpe, mas a parte sobre Pacemaker não é verdadeira. Os testes de regressão e liberação do marcapasso fazem uso extensivo da automação.

Para configurar sem um cluster ativo, prefixe todos os comandos CIB_file=/var/lib/heartbeat/crm/cib.xmlou defina-o em seu ambiente. Apenas certifique-se de remover o arquivo .sig antes de iniciar o cluster.

Para clusters sem quorum, a maioria, senão todas as ferramentas, deve oferecer suporte -fou --forceque instruirá o cluster a aceitar a alteração de qualquer maneira. Se você encontrar uma ferramenta que não encontra - por favor, registre um bug.

No mundo do código aberto, há o RedHat Cluster Suite . Faz vários anos desde que implementei o RHCS, então não tenho muitas coisas relevantes a dizer sobre isso hoje.

Comercialmente, existe o Veritas Cluster Server . Nenhuma experiência com isso.

Uma ferramenta de HA de código-fonte muito mais simples e aberta é o UCARP . O UCARP não fornece quase o mesmo tipo de "infraestrutura" que o Heartbeat / Pacemaker / CoroSync fornece, mas você pode criar soluções de alta disponibilidade em torno dele.

Você também pode criar uma infraestrutura altamente disponível com tecnologias de virtualização, mas essas soluções tendem a se concentrar na disponibilidade no nível do host, em oposição à disponibilidade no nível do aplicativo.

Existe o Oracle Clusterware para Oracle Unbreakable Linux, embora eu não o tenha usado.

Se você já usa o EC2, por que não usar o Elastic Load Balancing ? Isso permitirá que você atinja a disponibilidade no nível do aplicativo sem precisar configurar o failover.

O Veritas Cluster é excelente (comparado ao Linux-Heartbeat, AIX-hacmp, HP-Serviceguard e cluster Sun), mas custa muito dinheiro. A última vez que o vi, seu preço foi baseado nos núcleos da CPU do cluster. O fornecedor atual é a Symantec ...

Eu escrevi um gerenciador de cluster de failover no posix shell: https://github.com/nackstein/back-to-work

dê uma olhada, estou procurando alguém que queira experimentar e ajudar no desenvolvimento.

O opensvc ( https://www.opensvc.com ) suporta vários drivers de pulsação:

• unicast
• multicast
• disco compartilhado
• 3ª retransmissão do site

e também possui mecanismos de quorum em caso de divisão do cérebro.

Eu consegui configurar automaticamente um cluster de 4 nós composto por 2 instâncias do Google Cloud + 2 instâncias da Amazon com terraform + ansible.