Alternative a Heartbeat, Pacemaker e CoroSync?

Esistono alternative importanti per il failover automatico su Linux oltre alle tipiche combinazioni Heartbeat / Pacemaker / CoroSync? In particolare, sto configurando il failover su istanze EC2, che supporta solo unicast - no multicast o broadcast. Sto specificatamente cercando di gestire i pochi software in nostro possesso che non dispongono già di failover automatico e non supportano ambienti multi-master. Ciò include strumenti come HAProxy e Solr.

Ho Heartbeat + Pacemaker funzionante, ma non ne sono entusiasta. Ecco alcuni dei miei problemi:

• Battito cardiaco - Di per sé, limitato a due nodi. Mi piacerebbe avere 3+.
• Pacemaker: impossibile da configurare automaticamente. Il cluster deve essere in esecuzione con un quorum e quindi richiede ancora la configurazione manuale.
• CoroSync - Non supporta unicast.

Il pacemaker funziona molto bene, anche se la sua potenza rende difficile l'installazione. Il vero problema con Pacemaker è che non esiste un modo semplice per automatizzare la configurazione. Voglio davvero lanciare un'istanza EC2, installare Chef / Puppet e avviare l'intero cluster senza il mio intervento.

Preferisco usare keepalived per l'alta disponibilità. Trovo più semplice da installare (un demone e una configurazione) rispetto al battito cardiaco e alla compagnia. L'unico inconveniente in cui mi imbatto è che keepalived non ha un'opzione unicast per impostazione predefinita e usa solo VRRP per la comunicazione (l'autore di HAProxy ha comunque scritto una patch unicast per keepalived)

In realtà sto lavorando a qualcosa di molto simile a quello che hai descritto (un cluster di failover su EC2) e, dopo aver provato Heartbeat, ho optato per Corosync come livello di messaggistica. Corosync verrà eseguito su più server e supporta Unicast (UDPU) a partire dalla versione 1.3.0 (da novembre 2010). Ho installato e testato Corosync sul cloud EC2 di Amazon (utilizzando l'AMI Linux di Amazon) e posso confermare che funziona senza problemi.

Un file udpu di esempio è installato su / etc / corosync.

Aggiungere un blocco membro alla sezione dell'interfaccia per ciascun nodo e specificare il trasporto come updu. (Ho usato la stessa porta del battito cardiaco nell'esempio seguente, ma puoi cambiarlo come desiderato).

per esempio:

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
}

(Heartbeat dovrebbe supportare 3+ cluster di nodi nelle versioni 1.2.3+, anche se non l'ho mai provato personalmente e non so se funzionerebbe con Unicast).

Siamo spiacenti, ma la parte relativa a Pacemaker non è vera. I test di regressione e rilascio di Pacemaker fanno ampio uso dell'automazione.

Per configurare senza un cluster attivo, aggiungere il prefisso a tutti i comandi CIB_file=/var/lib/heartbeat/crm/cib.xmlo impostarlo nel proprio ambiente. Assicurati di rimuovere il file .sig prima di avviare il cluster.

Per i cluster senza quorum, la maggior parte se non tutti gli strumenti dovrebbero supportare -fo --forceche istruiranno comunque il cluster ad accettare la modifica. Se trovi uno strumento che non lo fa, ti preghiamo di presentare un bug.

Nel mondo open source, c'è RedHat Cluster Suite . Sono passati diversi anni da quando ho implementato RHCS, quindi non ho molte cose rilevanti da dire al riguardo oggi.

Commercialmente, c'è Veritas Cluster Server . Nessuna esperienza con esso.

Uno strumento HA molto più semplice e open source è UCARP . UCARP non fornisce quasi lo stesso tipo di "infrastruttura" di Heartbeat / Pacemaker / CoroSync, ma è possibile creare soluzioni HA attorno ad esso.

È inoltre possibile creare un'infrastruttura a disponibilità elevata con tecnologie di virtualizzazione, ma queste soluzioni tendono a concentrarsi sulla disponibilità a livello di host anziché sulla disponibilità a livello di applicazione.

Esiste Oracle Clusterware per Oracle Unbreakable Linux, anche se non l'ho usato.

Se stai già utilizzando EC2, perché non utilizzare il bilanciamento del carico elastico ? Ti consentirà di raggiungere la disponibilità a livello di applicazione senza dover configurare tu stesso il failover.

Veritas Cluster è eccezionale (rispetto a Linux-Heartbeat, AIX-hacmp, HP-Serviceguard e Sun cluster), ma costa molti soldi. L'ultima volta che l'ho visto, il suo prezzo era basato sui core della CPU. Il fornitore attuale è Symantec ...

Ho scritto un gestore cluster di failover nella shell posix: https://github.com/nackstein/back-to-work

date un'occhiata, sto cercando qualcuno che voglia provarlo e aiutarlo nello sviluppo.

opensvc ( https://www.opensvc.com ) supporta più driver heartbeat:

• unicast
• multicast
• disco condiviso
• Inoltro 3 ° sito

e hanno anche meccanismi di quorum in caso di cervello diviso.

Sono riuscito a configurare automaticamente un cluster a 4 nodi composto da 2 istanze cloud di Google + 2 istanze amazon con terraform + ansible.