Mise en œuvre sur Linux

Corosync est un programme de bas niveau de gestion du cluster, qui assure la synchronisation des nœuds, s’occupe de relancer les processus sur un nœud lors du basculement, gère la configuration distribuée, la notification entre les nœuds et la gestion du quorum.

Il s’agit d’une couche de messagerie qui permet de transmettre les informations entre les différents nœuds du cluster. Corosync s’occupe également du heartbeat, c’est-à-dire de la vérification régulière de la santé de chaque nœud.

Corosync gère les nœuds et leur appartenance au cluster. C’est lui qui s’occupe de la notification des nœuds qui rejoignent ou quittent le cluster.

Corosync gère le quorum, c’est-à-dire les vôtres entre les nœuds pour définir la santé du cluster.

Pacemaker et de plus haut niveau, il se base sur Corosync pour toute la partie physique du cluster, mais il va gérer les ressources qui appartiennent à des groupes de ressources, ce qu’on appelle les rôles, maintenant dans le cluster Windows. Sa responsabilité est de gérer les groupes de ressources, de démarrer ou d’arrêter les services est de surveiller les ressources pour déterminer si elles sont encore vivantes, et sinon de déclencher un basculement.

La responsabilité de pacemaker est donc principalement la gestion des ressources, il s’agit de ce qu’on appelle un CRM, ou Cluster Resource Manager. C’est lui qui s’occupe de déplacer les ressources en cas de basculement.

Pacemaker gère une adresse IP virtuelle pour la connexion des clients au cluster, ce qu’on appelle une VIP, ou Virtual IP. WSFC, le service de cluster de Windows, j’ai également un nom de réseau virtuel, un VNN. Ce n’est pas le cas de Pacemaker. Vous devez gérer vous-même une entrée DNS pour cela.

La mise en place et la gestion d’un cluster à l’aide de corps aussi de pacemaker est facilitée par un script nommé PCS, pour Pacemaker/Corosync Configuration System. Il s’agit bien entendu d’un projet libre qu’on peut trouver sur cette adresse Github : https://github.com/ClusterLabs/pcs. Le script peut être utilisé à travers une interface graphique Web.

Comme tout système de basculement automatique, Corosync doit gérer un quorum. Cela implique de pouvoir toujours définir une majorité. Il faut donc plus que deux nœuds ou deux acteurs dans le système, pour permettre d’atteindre une majorité lorsqu’un des nœuds est défaillant. Sur Windows, on peut définir un témoin, par exemple un témoin de partage de fichiers ou un disque de quorum. Corosync que ne supporte pas le concept de témoin. Il faut donc ajouter un nœud supplémentaire pour permettre un système fonctionnel.

Pour éviter les situations de Split Brain, c’est-à-dire de deux nœuds qui se considèrent l’un et l’autre comme les principaux, le cluster doit s’assurer qu’il ne peut pas y avoir deux nœuds principaux en même temps. Sur Windows, c’est le service de cluster qui s’assure de démarrer les services d’un côté et de les arrêter de l’autre. Le concept est différent sur Linux. Pour éviter une situation de Split Brain, Linux utilise le concept de fencing, pour créer une barrière. Il s’agit simplement de tuer le nœud. Le terme utilisé est un acronyme : STONITH, qui signifie Shoot The Other Node In The Head. Le fencing peut être réalisé de façon logicielle ou matérielle. Il y a des cartes intégrées qui permettent d’arrêter la machine, ou des interrupteurs de l’alimentation. Les solutions logicielles sont basées sur un disque partagé qui fait office de disque de quorum, ou de contact avec l’hyperviseur dans un système virtualisé.