¿Alternativas a Heartbeat, Pacemaker y CoroSync?

¿Hay alguna alternativa importante para la conmutación por error automática en Linux además de las combinaciones típicas Heartbeat / Pacemaker / CoroSync? En particular, estoy configurando la conmutación por error en instancias EC2, que solo admite unidifusión, no multidifusión o difusión. Estoy tratando específicamente de manejar las pocas piezas de software que tenemos que aún no tienen conmutación por error automática y no admiten entornos de múltiples maestros. Esto incluye herramientas como HAProxy y Solr.

Tengo Heartbeat + Pacemaker funcionando, pero no estoy entusiasmado con eso. Estos son algunos de mis problemas:

• Heartbeat - Por sí mismo, limitado a dos nodos. Me gustaría tener 3+.
• Marcapasos: imposible de configurar automáticamente. El clúster debe ejecutarse con un quórum y luego aún requiere configuración manual.
• CoroSync: no admite unidifusión.

El marcapasos funciona muy bien, aunque su potencia dificulta la configuración. El verdadero problema con Pacemaker es que no hay una manera fácil de automatizar la configuración. Realmente quiero lanzar una instancia de EC2, instalar Chef / Puppet y hacer que todo el clúster se inicie sin mi intervención.

Prefiero usar keepalived para alta disponibilidad. Me resulta más sencillo de configurar (un demonio y una configuración) que heartbeat y company. El único inconveniente con el que me encuentro es que keepalived no tiene una opción de unidifusión por defecto, y solo usa VRRP para la comunicación ( sin embargo, el autor de HAProxy ha escrito un parche de unidifusión para keepalived)

De hecho, estoy trabajando en algo muy similar a lo que describiste (un clúster de conmutación por error en EC2), y después de probar Heartbeat, me decidí por Corosync como mi capa de mensajería. Corosync se ejecutará en varios servidores y es compatible con Unicast (UDPU) a partir de la versión 1.3.0 (de noviembre de 2010). He configurado y probado Corosync en la nube EC2 de Amazon (usando Linux AMI de Amazon) y puedo confirmar que funciona sin problemas.

Se instala un archivo udpu de muestra en / etc / corosync.

Agregue un bloque miembro a la sección de interfaz para cada nodo y especifique el transporte como updu. (He usado el mismo puerto que heartbeat en el ejemplo a continuación, pero puede cambiarlo como desee).

p.ej:

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
}

(Se supone que Heartbeat admite clústeres de nodos 3+ en las versiones 1.2.3+, aunque nunca lo he probado personalmente y no sé si funcionaría con Unicast).

Lo sentimos, pero la parte sobre Pacemaker no es cierta. Las pruebas de regresión y lanzamiento de Pacemaker hacen un uso extensivo de la automatización.

Para configurar sin un clúster activo, prefije todos los comandos con CIB_file=/var/lib/heartbeat/crm/cib.xmlo configúrelo en su entorno. Solo asegúrese de eliminar el archivo .sig antes de iniciar el clúster.

Para los clústeres sin quórum, la mayoría de las herramientas, si no todas, deberían ser compatibles -fo lo --forceque indicará al clúster que acepte el cambio de todos modos. Si encuentra una herramienta que no funciona, presente un error.

En el mundo de código abierto, está RedHat Cluster Suite . Han pasado varios años desde que implementé RHCS, así que no tengo muchas cosas relevantes que decir al respecto hoy.

Comercialmente, hay Veritas Cluster Server . No hay experiencia con eso.

Una herramienta HA mucho más simple y de código abierto es UCARP . UCARP no proporciona casi el mismo tipo de "infraestructura" que Heartbeat / Pacemaker / CoroSync, pero puede crear soluciones de HA a su alrededor.

También puede construir una infraestructura de alta disponibilidad con tecnologías de virtualización, pero estas soluciones tienden a centrarse en la disponibilidad a nivel de host en lugar de la disponibilidad a nivel de aplicación.

Existe Oracle Clusterware para Oracle Unbreakable Linux, aunque no lo he usado.

Si ya está utilizando EC2, ¿por qué no utilizar Elastic Load Balancing ? Le permitirá alcanzar la disponibilidad a nivel de aplicación sin tener que configurar la conmutación por error usted mismo.

Veritas Cluster es excelente (en comparación con Linux-Heartbeat, AIX-hacmp, HP-Serviceguard y Sun cluster), pero cuesta mucho dinero. La última vez que lo vi, su precio se basó en los núcleos de CPU del clúster. El vendedor actual es Symantec ...

Escribí un administrador de clúster de conmutación por error en el shell posix: https://github.com/nackstein/back-to-work

échale un vistazo, estoy buscando a alguien que quiera probarlo y ayudar en el desarrollo.

opensvc ( https://www.opensvc.com ) admite múltiples controladores de latido:

• unicast
• multicast
• disco compartido
• 3er sitio de retransmisión

y también tienen mecanismos de quórum en caso de fractura cerebral.

Logré configurar automáticamente un clúster de 4 nodos compuesto por 2 instancias de Google Cloud + 2 instancias de Amazon con terraform + ansible.