La gestion des clusters applicatifs sous Linux

Un cluster pourquoi faire?

La mise en place d’un cluster applicatif répond à un besoin de haute disponibilité et/ou d’équilibrage de charge pour servir un grand nombre de demandes simultanées.

Pour répondre à ces besoins, il existe de multiples solutions possibles dont voici quelques exemples :

  • DNS round robin : Cette méthode est la plus simple à mettre en œuvre mais elle ne répond pas à la problématique de haute disponibilité. Si l’un des serveurs ne répond plus, le DNS continuera de délivrer des requêtes sur son adresse IP.
  • Cluster physique : Une ferme de serveurs physiques hébergeant des machines virtuelles peut répondre aux 2 besoins. SI l’un des serveurs physiques ne répond plus, la ferme redistribuera les machines virtuelles sur les autres serveurs et le service sera toujours rendu. Le point négatif de ce genre de solution, c’est qu’il ne prend pas en charge la défaillance du service, mais seulement la défaillance du serveur hébergeant la machine virtuelle.
  • Cluster applicatif : Le cluster applicatif répond au 2 besoins et il peut se déployer sur une ferme de serveurs, ou sur des serveurs physiques non clusterisés.

 

Éventail de solution de clustering applicatif

Dans l’éventail des solutions de clustering applicatif, nous allons nous limiter à la solution Pacemaker/Corosync. Cette solution est disponible sur plusieurs distributions Linux, le produit est open source (GPL v2 & LGPL v2) et permet de gérer le basculement.

Parmi les autres solutions existantes, on peut citer :

 

Présentation de Pacemaker et Corosync

Pacemaker est un gestionnaire de cluster qui peut être associé à Corosync ou à HeartBeat. Pacemaker propose une interface de gestion du cluster et permet de définir, démarrer ou arrêter les ressources. Il propose aussi une IHM de gestion du cluster.

Corosync est la couche de communication du cluster. C’est Corosync qui se chargera de transmettre l’état des nœuds et d’exécuter les opérations transmises par Pacemaker.

L’avantage de cette solution est qu’elle gère nativement un grand nombre d’applications que l’on peut trouver sur un serveur Linux. L’installation de pacemaker permettra d’utiliser ces agents de ressources permettant ainsi de gérer :

Au besoin, on pourra développer son propre agent de ressources, ou modifier un agent existant.

 

Configuration en mode actif/actif

On peut configurer le cluster pacemaker en actif/passif ou même avec seulement 2 nœuds, vous trouverez ici une description des autres possibilités de configuration pour un cluster pacemaker.

Pour la configuration suivante de pacemaker, nous allons configurer un cluster de 3 serveurs frontaux apache. Dans cette configuration, les serveurs sont en disponibilité actif/actif, c’est à dire que tous les nœuds du cluster répondront aux requêtes, et que la perte d’1 ou 2 serveurs ne perturbera pas le service rendu.

Pour la configuration suivante, nous avons 3 VM Centos version 7.5 configurées avec une IP statique sur un sous réseau /24. Le service NTP est activé pour s’assurer que les différents nœuds sont synchronisés sur la même horloge.

Dans notre cas, nous n’avons pas de serveur DNS, il faut donc inscrire tous les nœuds et l’adresse VIP dans le fichier hosts des chacun des nœuds :

Nous installons ensuite les paquets pacemaker et pcs :

Puis on configure apache en changeant la page par défaut, on indique le numéro du nœud pour permettre plus tard de savoir quel nœud nous répondra :

On configure le démon pcs pour démarrer automatiquement, et on règle ensuite le mot de passe du compte hacluster (créé automatiquement pendant l’installation du paquet pacemaker). Il faudra impérativement positionner le même mot de passe pour tous les nœuds :

Après avoir réalisé les actions précédentes sur les 3 nœuds, nous allons commencer la configuration de notre cluster. Les commandes suivantes sont à jouer sur un seul des nœuds. Il faudra compléter le champ username avec le nom du compte hacluster et le password, avec celui renseigné sur tous les nœuds :

Les 3 nœuds apparaissent bien dans le résultat de la commande, donc notre cluster est maintenant créé. Tous les nœuds communiquent et les configurations que nous ferons par la suite seront dupliquées sur tous les nœuds.

Création du cluster

Nous allons donc créer une configuration qui sera répliquée sur les nœuds du cluster :

Le résultat de la commande doit être le suivant :

Notre cluster est maintenant correctement configuré. La configuration de corosync a été générée puis appliquée sur tous les nœuds. Nous pouvons donc démarrer le cluster :

Ensuite, nous vérifions l’état du cluster avec la commande :

Le résultat de la commande doit indiquer que tous les nœuds sont en ligne, et que les démons sont actifs et activés :

Ajout des ressources

Créons maintenant notre première ressource, une adresse VIP :

Créons ensuite notre ressource apache :

Nous pouvons ensuite vérifier l’état de notre cluster et des ressources que nous venons de créer :

Le résultat nous montre que le cluster est toujours actif. Les ressources sont bien clonées sur tous les nœuds mais elles sont arrêtées.

Les ressources ne démarrent pas à cause du paramétrage du stonith. Ce paramètre permet de configurer le cluster en ajoutant un équipement hors du cluster, qui agit comme témoin. Dans le cas de défaillance d’un nœud, cet équipement permettra de faire la différence entre un nœud qui ne fonctionne plus et une coupure réseau entre les nœuds. Cette documentation présente les différents paramètres de stonith.

Dans notre cas, nous n’allons pas choisir d’équipement externe, et donc la commande suivante permet de désactiver le stontih :

On peut voir que la ressource IP démarre correctement sur tous les nœuds, mais la ressource apache, elle, ne démarre pas correctement :

En fait, pacemaker doit pouvoir démarrer et arrêter lui même le process, il faut donc désactiver le démarrage automatique d’apache et arrêter le process sur tous les nœuds du cluster :

En vérifiant de nouveau les ressources, nous pouvons voir que toutes les ressources sont correctement démarrées sur tous les nœuds :

A partir de maintenant, notre cluster est monté et toutes les ressources sont actives, nous pouvons commencer une série de tests sur le cluster.

Load-balancing

On peut voir que l’adresse VIP est correctement montée sur tous les noeuds :

Ensuite nous pouvons voir quel nœud répond, en lançant la commande à partir d’une vm ne faisant pas partie du cluster, et en interrogeant l’adresse VIP :

Le test nous montre que chacun des nœuds réponds tour à tour. L’équilibrage des charges est donc bien en place. Il dépend directement de la création de la ressource IPAdrr2, en spécifiant la primitive clone, cette ressource a été répartie sur les 3 nœuds. Pacemaker a automatiquement créé une règle iptables permettant de réaliser un équilibrage entre tous les nœuds en round robin :

Le hashmode par défaut est sourceip-sourceport, ce qui implique que le hash sera calculé sur l’adresse du client ainsi que sur son port source. C’est pourquoi à partir de la même machine, on va accéder à tous les nœuds de façon cyclique. les différents paramétrages possible du hashmode sont :

  • sourceip
  • sourceip-sourceport
  • sourceip-sourceport-destport

 

Failover

Pour le test suivant, on ouvre une fenêtre Firefox en autorefresh sur l’ordinateur hébergeant les VM. Dans cette configuration, le sourceport ne change pas, on reste donc systématiquement sur le même nœud.

En forçant un reboot du nœud, on peut voir que c’est le nœud 1 qui nous répond, pendant le temps de reboot du nœud 3 :

Interface Web

Pacemaker et corosync proposent aussi la gestion du cluster, au travers d’une interface web qui est installée nativement. Elle est accessible en se connectant sur le port 2224, sur l’adresse du cluster. Il faudra ensuite se logger avec le compte provisionné lors de la création du cluster.

Au travers de cette interface, nous pourrons réaliser les mêmes actes de maintenance que ceux proposés par l’interface en ligne de commande :

 

Conclusion

Avec une configuration relativement aisée, on peut mettre en place un cluster stable qui répondra aux problématiques de haute disponibilité. Dans notre cas, on constate que le failover est automatisé par pacemaker et que l’équilibrage de charge est également assuré.

Pacemaker dispose d’autres fonctionnalités permettant d’assurer l’exploitation du cluster, comme une mise en maintenance d’un nœud, l’ajout ou le retrait d’un noeud, la gestion des ressources, etc.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *