Guide étape par étape pour le déploiement d'un cluster RabbitMQ Actif-Passif

La mise en œuvre de la haute disponibilité (HA) pour les services de messagerie critiques nécessite une redondance robuste. Une configuration de cluster RabbitMQ Actif-Passif est une approche classique pour y parvenir, garantissant qu'en cas de défaillance du nœud actif, un nœud passif désigné peut rapidement prendre le relais, minimisant ainsi les temps d'arrêt. Ce guide fournit un processus complet et étape par étape pour configurer un tel déploiement, couvrant les prérequis, la configuration des nœuds et l'assurance de capacités de basculement transparentes.

Ce modèle de déploiement repose sur le clustering RabbitMQ standard combiné à un mécanisme externe (comme Pacemaker ou de simples scripts) pour gérer la reprise d'adresse IP en cas de défaillance. Pour ce guide, nous nous concentrons sur l'aspect clustering de RabbitMQ qui sous-tend la configuration HA.

Prérequis pour un cluster Actif-Passif

Avant de commencer la configuration, assurez-vous que les prérequis suivants sont remplis sur tous les nœuds du cluster envisagé (Nœud A - Actif, Nœud B - Passif) :

1. Versions logicielles identiques : Tous les nœuds doivent exécuter exactement la même version de RabbitMQ Server et d'Erlang/OTP.
2. Accessibilité réseau : Tous les nœuds doivent pouvoir communiquer entre eux via les ports nécessaires (par défaut 5672 pour AMQP, 25672 pour le clustering).
3. Résolution des hôtes : Configurez le fichier /etc/hosts (ou DNS) sur tous les nœuds afin que chaque nœud puisse résoudre de manière fiable le nom d'hôte de tous les autres nœuds.
4. Cohérence des cookies : Le 'magic cookie' Erlang doit être identique sur tous les nœuds. C'est crucial pour que les nœuds se fassent confiance pour le clustering.

Établir la cohérence des cookies

Le cookie Erlang détermine si les nœuds peuvent communiquer en toute sécurité. Il doit être copié du premier nœud initialisé vers tous les autres.

Sur le Nœud A (Le premier nœud) :

Localisez le fichier de cookie (généralement /var/lib/rabbitmq/.erlang.cookie ou ~/.erlang.cookie selon la méthode d'installation) et copiez son contenu.

Sur le Nœud B (et les nœuds suivants) :

1. Arrêtez le service RabbitMQ :
   bash sudo systemctl stop rabbitmq-server
2. Remplacez le fichier de cookie existant par le contenu copié du Nœud A, en vous assurant que les permissions sont correctes (généralement 400).
   bash # Exemple utilisant echo (remplacez le contenu si nécessaire) echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie
3. Démarrez le service sur le Nœud B :
   bash sudo systemctl start rabbitmq-server

Étape 1 : Configuration des noms d'hôte et du réseau

Assurez-vous que les fichiers hôtes sur les Nœuds A et B mappent correctement leurs noms d'hôte.

Exemple /etc/hosts (sur les deux serveurs) :

192.168.1.10   rabbitmq-node-a
192.168.1.11   rabbitmq-node-b

Étape 2 : Initialisation du premier nœud du cluster (Actif)

Le Nœud A sera le nœud primaire initial, où le cluster est d'abord établi.

1. Démarrez le service sur le Nœud A (s'il n'est pas déjà en cours d'exécution) :
   bash sudo systemctl start rabbitmq-server
2. Vérifiez le statut : Assurez-vous que le nœud fonctionne correctement.
   bash rabbitmqctl status

Étape 3 : Ajout du deuxième nœud (Passif) au cluster

Nous allons maintenant demander au Nœud B de rejoindre le cluster dirigé par le Nœud A.

1. Arrêtez le service sur le Nœud B (s'il est en cours d'exécution) :
   bash sudo systemctl stop rabbitmq-server

2. Commande de jonction : Exécutez la commande de jonction sur le Nœud B, en spécifiant le nom d'hôte du Nœud A comme pair.
   bash rabbitmqctl join_cluster rabbit@rabbitmq-node-a
   Conseil : Utilisez le nom d'hôte défini dans /etc/hosts.

3. Démarrez le service sur le Nœud B :
   bash sudo systemctl start rabbitmq-server

Étape 4 : Vérification de la formation du cluster

Connectez-vous au Nœud A et vérifiez que les deux nœuds se reconnaissent mutuellement.

rabbitmqctl cluster_status

Extrait de la sortie attendue :

Vous devriez voir rabbitmq-node-a et rabbitmq-node-b listés sous running_nodes.

Cluster status of node rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

Étape 5 : Configuration de la haute disponibilité (files d'attente en cluster)

Le clustering RabbitMQ standard permet aux nœuds de partager des métadonnées (utilisateurs, échanges), mais les messages résidant dans les files d'attente ne sont généralement pas répliqués automatiquement, sauf si des politiques HA spécifiques sont appliquées. Pour un véritable basculement Actif-Passif, des files d'attente miroir doivent être utilisées.

Définition de la politique

Une politique est appliquée aux files d'attente correspondant à des motifs spécifiques pour définir le nombre de copies de la file d'attente qui doivent exister dans le cluster et où elles doivent être promues.

Utilisez la commande rabbitmqctl set_policy sur n'importe quel nœud pour appliquer le mirroring à l'ensemble du cluster ("^").

```bash

Définissez une politique nommée 'ha-all' qui réplique les files d'attente correspondant à n'importe quel nom ('^')

sur tous les nœuds du cluster (3 nœuds au total), et définissez le comportement de 'promote'.

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"