Alternatives à Heartbeat, Pacemaker et CoroSync?


26

Existe-t-il des alternatives majeures pour le basculement automatique sous Linux en plus des combinaisons typiques Heartbeat / Pacemaker / CoroSync? En particulier, je configure le basculement sur les instances EC2, qui ne prend en charge que la monodiffusion - pas de multidiffusion ni de diffusion. J'essaie spécifiquement de gérer les quelques logiciels que nous avons qui ne disposent pas déjà d'un basculement automatique et ne prennent pas en charge les environnements multi-maîtres. Cela inclut des outils comme HAProxy et Solr.

J'ai Heartbeat + Pacemaker qui fonctionne, mais je n'en suis pas ravi. Voici certains de mes problèmes:

  • Heartbeat - En soi, limité à deux nœuds. J'aimerais avoir 3+.
  • Pacemaker - Impossible de configurer automatiquement. Le cluster doit être exécuté avec un quorum, puis il nécessite toujours une configuration manuelle.
  • CoroSync - Ne prend pas en charge la monodiffusion.

Le stimulateur cardiaque fonctionne très bien, bien que sa puissance le rend difficile à configurer. Le vrai problème avec Pacemaker est qu'il n'y a pas de moyen facile d'automatiser la configuration. Je veux vraiment lancer une instance EC2, installer Chef / Puppet et faire lancer le cluster entier sans mon intervention.

Réponses:


17

Je préfère utiliser keepalived pour une haute disponibilité. Je trouve plus simple à installer (un démon et une configuration) que Heartbeat et Company. Le seul inconvénient que je rencontre, c'est que keepalived n'a pas d'option unicast par défaut, et utilise uniquement VRRP pour la communication (L'auteur de HAProxy a écrit un patch unicast pour keepalived cependant)


Unicast est un must, mais je vais jeter un œil au patch.
Organicveggie

4
+1 J'avais l'habitude d'utiliser le battement de cœur dans toutes les situations de «basculement», jusqu'à ce que je lise un article (quelque part) de l'auteur de haproxy expliquant pourquoi je l'avais mal fait (ou du moins inefficacement) et que je devrais utiliser keepalived à la place . Tout dépend si le plus important est de basculer sur un chemin réseau (par exemple, déplacer une adresse IP vers un autre serveur - keepalived), ou d'avoir besoin de garantir un seul accès à une ressource (par exemple, une connexion SAN - battement de cœur).
Coops

5
C'est le courrier auquel @Coops fait référence, je crois formilux.org/archives/haproxy/1003/3259.html
Henrik

4
Depuis la version 1.2.8 (05/08/2013) Keepalived prend en charge Unicast ( keepalived.org/changelog.html ).
Dynom


14

Je travaille actuellement sur quelque chose de très similaire à ce que vous avez décrit (un cluster de basculement sur EC2), et après avoir essayé Heartbeat, je me suis installé sur Corosync comme couche de messagerie. Corosync fonctionnera sur plusieurs serveurs et prend en charge Unicast (UDPU) à partir de la version 1.3.0 (à partir de novembre 2010). J'ai installé et testé Corosync sur le cloud EC2 d'Amazon (en utilisant l'AMI Linux d'Amazon) et je peux confirmer que cela fonctionne sans problème.

Un exemple de fichier udpu est installé dans / etc / corosync.

Ajoutez un bloc membre à la section d'interface pour chaque nœud et spécifiez le transport en tant que mise à jour. (J'ai utilisé le même port que Heartbeat dans l'exemple ci-dessous, mais vous pouvez le modifier à votre guise).

par exemple:

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 est censé prendre en charge plus de 3 clusters de nœuds dans les versions 1.2.3+, bien que je ne l'ai jamais essayé personnellement et je ne sais pas si cela fonctionnerait avec Unicast).


J'ai installé un cluster de 3 machines en utilisant udpu, et cela a bien fonctionné. Vous continuez simplement à leur ajouter des blocs membres.
devicenull

11

Désolé, mais la partie sur Pacemaker n'est pas vraie. Les tests de régression et de libération de Pacemaker utilisent largement l'automatisation.

Pour configurer sans cluster actif, préfixez toutes les commandes avec CIB_file=/var/lib/heartbeat/crm/cib.xmlou définissez-le dans votre environnement. Assurez-vous simplement de supprimer le fichier .sig avant de démarrer le cluster.

Pour les clusters sans quorum, la plupart des outils, sinon tous, devraient prendre en charge -fou --forcequi demanderont au cluster d'accepter le changement de toute façon. Si vous trouvez un outil qui ne fonctionne pas - veuillez signaler un bogue.


Désolé, mon opinion était basée sur les commentaires que j'ai reçus de la liste de diffusion Pacemaker. Je vais essayer votre suggestion.
Organicveggie le

3

Dans le monde open source, il y a RedHat Cluster Suite . Cela fait plusieurs années que j'ai mis en œuvre RHCS, je n'ai donc pas beaucoup de choses pertinentes à dire à ce sujet aujourd'hui.

Commercialement, il y a Veritas Cluster Server . Aucune expérience avec cela.

Un outil HA beaucoup plus simple et open source est UCARP . UCARP ne fournit pas à peu près le même type d '"infrastructure" que Heartbeat / Pacemaker / CoroSync, mais vous pouvez créer des solutions HA autour de lui.

Vous pouvez également créer une infrastructure hautement disponible avec des technologies de virtualisation, mais ces solutions ont tendance à se concentrer sur la disponibilité au niveau de l'hôte plutôt que sur la disponibilité au niveau de l'application.


Merci. Je vais jeter un œil à RHcS, VCS et UCARP. J'ai mis à jour ma question pour refléter le fait que j'utilise Amazon EC2, donc la disponibilité au niveau de l'hôte n'est pas quelque chose que je contrôle beaucoup ... d'où la raison pour laquelle je regarde la disponibilité au niveau de l'application.
Organicveggie

1

Il existe Oracle Clusterware pour Oracle Unbreakable Linux, mais je ne l'ai pas utilisé.


1

Si vous utilisez déjà EC2, pourquoi ne pas utiliser Elastic Load Balancing ? Il vous permettra d'atteindre la disponibilité au niveau de l'application sans avoir à configurer le basculement vous-même.


Il y a plusieurs raisons pour lesquelles ELB ne convient pas. Tout d'abord, ELB ne fonctionne que pour les demandes provenant d'Internet public - il ne peut pas être utilisé pour les demandes internes, sauf si vous acheminez vos demandes vers l'adresse publique de l'ELB et que vous payez ensuite tout le trafic. Deuxièmement, ELB est un équilibreur très simple - vous ne pouvez pas appliquer de règles ou de modèles à son fonctionnement et vous ne pouvez pas avoir de serveurs de secours. Par exemple, vous ne voulez pas que deux instances HAProxy distinctes pointent activement vers le même serveur Web car elles n'auront aucune idée de la charge réelle sur le serveur Web cible.
Organicveggie le

1

Veritas Cluster est génial (par rapport à Linux-Heartbeat, AIX-hacmp, HP-Serviceguard et Sun cluster), mais il coûte beaucoup d'argent. La dernière fois que je l'ai regardé, son prix était basé sur les cpu-cores du cluster. Fournisseur actuel ist Symantec ...



0

opensvc ( https://www.opensvc.com ) prend en charge plusieurs pilotes de pulsation:

  • monodiffusion
  • multidiffusion
  • disque partagé
  • Relais 3ème site

et ont également des mécanismes de quorum en cas de cerveau divisé.

J'ai réussi à configurer automatiquement un cluster à 4 nœuds composé de 2 instances Google Cloud + 2 instances Amazon avec Terraform + Ansible.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.