Existem alternativas importantes para o failover automático no Linux, além das típicas combinações de Heartbeat / Pacemaker / CoroSync? Em particular, estou configurando o failover em instâncias do EC2, que suporta apenas unicast - sem multicast ou broadcast. Eu estou especificamente tentando lidar com os poucos softwares que temos que não possuem failover automático e não suportam ambientes multi-master. Isso inclui ferramentas como o HAProxy e o Solr.
Eu tenho Heartbeat + Pacemaker funcionando, mas não estou muito feliz com isso. Aqui estão alguns dos meus problemas:
O marcapasso funciona muito bem, embora seu poder dificulte a configuração. O verdadeiro problema com o Pacemaker é que não há uma maneira fácil de automatizar a configuração. Eu realmente quero lançar uma instância do EC2, instalar o Chef / Puppet e ter o lançamento do cluster inteiro sem a minha intervenção.
Eu prefiro usar keepalived para alta disponibilidade. Acho mais simples configurar (um daemon e config) do que heartbeat e company. A única desvantagem que eu corro, é que keepalived não tem uma opção unicast por padrão, e só usa VRRP para comunicação (O autor do HAProxy escreveu um patch unicast para manter o serviço 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, estabeleci 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 (a partir de novembro de 2010). Eu configurei e testei o Corosync na nuvem EC2 da Amazon (usando o Linux AMI da Amazon) e posso confirmar que ele funciona sem problemas.
Um arquivo udpu de amostra está instalado em / etc / corosync.
Adicione um bloco de membro à seção de interface para cada nó e especifique o transporte como updu. (Eu usei a mesma porta que o heartbeat no exemplo abaixo, mas você pode alterá-lo 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
}
(Supõe-se que o Heartbeat suporte 3+ clusters de nós nas versões 1.2.3+, embora eu nunca tenha tentado isso pessoalmente e não sei se funcionaria com Unicast).
Desculpe, mas a parte sobre o Pacemaker não é verdadeira. Os testes de regressão e liberação do marcapasso fazem amplo uso da automação.
Para configurar sem um cluster ativo, prefixar todos os comandos com CIB_file=/var/lib/heartbeat/crm/cib.xml ou configurá-lo em seu ambiente. Apenas certifique-se de remover o arquivo .sig antes de iniciar o cluster.
Para clusters sem quorum, a maioria, se não todas, as ferramentas devem suportar -f ou --force , o que instruirá o cluster a aceitar a alteração mesmo assim. Se você encontrar uma ferramenta que não seja - por favor arquive um bug.
No mundo do código aberto, há RedHat Cluster Suite . Já faz vários anos desde que eu implementei o RHCS, então eu não tenho muitas coisas relevantes para dizer sobre isso hoje.
Comercialmente, há Servidor de Cluster Veritas . Nenhuma experiência com isso.
Uma ferramenta de HA de código aberto muito mais simples é UCARP . O UCARP não fornece quase o mesmo tipo de "infraestrutura" que o Heartbeat / Pacemaker / CoroSync faz, mas você pode construir 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 tenha usado.
Se você já usa o EC2, por que não usar o Balanceamento Elástico de Carga ? Ele permitirá que você alcance a disponibilidade em nível de aplicativo sem ter que configurar o failover por conta própria.
O Veritas Cluster é ótimo (comparado ao Linux-Heartbeat, AIX-hacmp, HP-Serviceguard e Sun cluster), mas custa muito dinheiro. A última vez que eu olhei para ele, seu preço foi baseado em núcleos de cpu do cluster. Fornecedor atual ist Symantec ...
Eu escrevi um gerenciador de cluster de failover no shell posix: link
dê uma olhada, estou procurando alguém que queira experimentá-lo e ajudar no desenvolvimento.
O opensvc ( link ) oferece suporte a vários drivers de pulsação:
e também tem mecanismos de quórum em caso de divisão cerebral.
Consegui configurar automaticamente um cluster de 4 nós feito de 2 instâncias do google cloud + 2 instâncias do amazon com terraform + ansible.