Comprendre la haute disponibilité (HA) sur SUSE Linux
La haute disponibilité et la continuité des activités sont cruciales pour que les applications et les services restent opérationnels.
Les clusters à haute disponibilité permettent aux services essentiels de continuer à fonctionner, même si les serveurs ou les composants matériels tombent en panne.
SUSE Linux offre un ensemble d’outils robustes pour créer et gérer ces clusters.
Dans cet article, nous explorons l’état actuel de la mise en cluster dans SUSE Linux, en nous concentrant sur les technologies clés telles que Pacemaker, Corosync, DRBD et d’autres.
Celles-ci, à quelques différences près, sont disponibles sur x86 et ppc64le. 
Pacemaker : le cerveau du cluster
Pacemaker est le moteur qui gère les clusters à haute disponibilité dans SUSE Linux.
Sa fonction principale est de gérer les ressources des clusters, en veillant à ce que les services critiques soient opérationnels et se rétablissent rapidement en cas de défaillance. Pacemaker surveille en permanence les ressources (bases de données, services Web, systèmes de fichiers, etc.) et, s’il détecte un problème, migre ces ressources vers d’autres nœuds du cluster pour les maintenir en état de marche.
Pacemaker se distingue par sa flexibilité et sa capacité à gérer une grande variété de ressources.
Des simples services aux systèmes distribués plus complexes, il est capable de gérer la plupart des scénarios de haute disponibilité dont une entreprise peut avoir besoin. 
Corosync : le système nerveux du cluster
Corosync est responsable de la communication entre les nœuds du cluster.
Il veille à ce que tous les nœuds aient à tout moment la même vision de l’état du cluster, ce qui est essentiel pour une prise de décision coordonnée.
Il gère également le quorum, qui détermine s’il y a suffisamment de nœuds actifs pour que le cluster fonctionne en toute sécurité.
Si le quorum est perdu, des mesures peuvent être prises pour éviter la perte de données ou même l’arrêt du service.
DRBD : l’épine dorsale des données
DRBD (Distributed Replicated Block Device) est une solution de réplication de stockage au niveau des blocs qui réplique les données entre les nœuds en temps réel.
Avec DRBD, les données d’un serveur sont répliquées sur un autre serveur presque instantanément, créant ainsi une copie exacte.
Ceci est particulièrement utile dans les scénarios où il est crucial que les données critiques soient toujours disponibles, même si un nœud tombe en panne.
Combiné à Pacemaker, DRBD permet aux services de continuer à fonctionner en ayant accès aux mêmes données, même s’ils se trouvent sur des nœuds différents.
Autres technologies clés dans les clusters SUSE Linux
En plus de Pacemaker, Corosync et DRBD, il existe d’autres technologies essentielles pour construire des clusters robustes sur SUSE Linux :
- SBD (STONITH Block Device) : SBD est un outil de clôture qui permet d’isoler un nœud qui se comporte mal et de l’empêcher de causer des problèmes dans le cluster.
Pour ce faire, on utilise un dispositif de stockage partagé que les nœuds utilisent pour communiquer leur état. - OCF (Open Cluster Framework) : les scripts OCF constituent la base des ressources gérées par Pacemaker.
Ils définissent comment démarrer, arrêter et vérifier l’état d’une ressource, offrant ainsi la flexibilité nécessaire pour intégrer un large éventail de services dans le cluster. - Csync2 : Un outil pour synchroniser les fichiers entre les nœuds d’un cluster.
Il permet de s’assurer que les fichiers de configuration et autres données critiques sont toujours à jour sur tous les nœuds.
Situation actuelle et tendances futures
Les clusters dans SUSE Linux ont mûri et s’adaptent aux nouvelles demandes des entreprises.
Avec l’adoption croissante des environnements de conteneurs et avec des parties dans différents clouds, les clusters dans SUSE Linux évoluent pour mieux s’y intégrer.
Cela inclut une meilleure prise en charge de l’orchestration des conteneurs et des applications distribuées qui nécessitent une haute disponibilité au-delà de la réplication de deux disques par DRBD et du maintien en vie d’une IP virtuelle :). Toujours est-il qu’aujourd’hui, la combinaison de Pacemaker, Corosync, DRBD et d’autres outils constitue une base solide pour créer des clusters à haute disponibilité qui peuvent évoluer et s’adapter aux besoins de SAP HANA et d’autres solutions qui nécessitent une disponibilité élevée, voire totale. Si tu as besoin d’aide, SIXE peut t’aider.
Aide-mémoire pour créer et gérer des clusters avec Pacemaker sur SUSE Linux
Voici les commandes les plus courantes pour créer et gérer des clusters avec Pacemaker sur SUSE Linux.
| Tâche | Commande / Description |
|---|---|
| Installation des paquets | |
| Installer Pacemaker et Corosync | zypper install -y pacemaker corosync crmsh |
| Configuration de base | |
| Configurer Corosync | Modifie /etc/corosync/corosync.conf pour définir le transport, les interfaces et le réseau. |
| Démarrer les services | systemctl start corosync && systemctl start pacemaker |
| Activer les services au démarrage | systemctl enable corosync && systemctl enable pacemaker |
| Gestion du cluster | |
| Voir l’état du cluster | crm status |
| Lister les nœuds | crm_node -l |
| Ajouter un nœud (à lancer sur le nouveau nœud) | crm cluster join -c <noeud_existant> |
| Retirer un nœud | crm cluster remove <nom_noeud> |
| Consulter les journaux du cluster | journalctl -u pacemaker -u corosync |
| Configuration des ressources | |
| Créer une ressource | crm configure primitive <nom_ressource> <agent> params <parametres> |
| Supprimer une ressource | crm configure delete <nom_ressource> |
| Modifier une ressource | crm configure edit <nom_ressource> |
| Afficher la configuration complète du cluster | crm configure show |
| Groupes et ordre de démarrage | |
| Créer un groupe de ressources | crm configure group <nom_groupe> <ressource1> <ressource2> ... |
| Définir l’ordre de démarrage | crm configure order <nom_ordre> Mandatory: <ressource1> <ressource2> |
| Contraintes | |
| Garder deux ressources sur le même nœud | crm configure colocation <nom_contrainte> inf: <ressource1> <ressource2> |
| Préférer un nœud pour une ressource | crm configure location <nom_contrainte> <ressource> <score>: <noeud> |
| Basculement et reprise | |
| Déplacer une ressource vers un autre nœud | crm resource move <nom_ressource> <noeud> |
| Supprimer la contrainte laissée par le déplacement | crm resource clear <nom_ressource> |
| Effacer les échecs d’une ressource | crm resource cleanup <nom_ressource> |
| Ne plus gérer une ressource (maintenance) | crm resource unmanage <nom_ressource> |
| Gérer de nouveau une ressource | crm resource manage <nom_ressource> |
| Configuration avancée | |
| Que faire en cas de perte du quorum | crm configure property no-quorum-policy=<stop|freeze|ignore> |
| Configurer le fencing avec SBD | crm configure primitive stonith-sbd stonith:external/sbd params pcmk_delay_max=<delai> |
| Configurer les délais et la surveillance d’une ressource | crm configure primitive <nom_ressource> <agent> op start timeout=<delai> op monitor interval=<intervalle> timeout=<delai> |
| Validation et tests | |
| Valider la configuration du cluster | crm_verify --live-check |
| Simuler la prochaine transition du cluster | crm_simulate --live-check --simulate |
| Politiques | |
| Définir la stickiness par défaut | crm configure rsc_defaults resource-stickiness=<valeur> |
| Définir la priorité d’une ressource | crm resource meta <nom_ressource> set priority <valeur> |
| Arrêt et démarrage du cluster | |
| Arrêter tout le cluster | crm cluster stop --all |
| Démarrer tout le cluster | crm cluster start --all |
Si tu dois mettre en place ou auditer un cluster de ce type, nous le faisons dans le cadre de notre service d’implémentation et support de Pacemaker. S’il est déjà tombé en production, notre assistance d’urgence 24h/24 te contacte en moins de 15 minutes.
