Guide étape par étape pour déployer un cluster actif-passif RabbitMQ

La haute disponibilité de RabbitMQ nécessite plus que deux serveurs capables de se voir. Vous avez besoin de clustering pour les métadonnées partagées, de files d'attente répliquées pour la disponibilité des messages, et d'un chemin de basculement clair pour les clients.

Ce guide montre le côté RabbitMQ d'un déploiement de style actif-passif. Le basculement client provient généralement d'un équilibreur de charge, d'un changement DNS, de la découverte de services ou d'une IP virtuelle gérée en dehors de RabbitMQ.

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 prévus (Nœud A - Actif, Nœud B - Passif) :

Versions logicielles compatibles : Maintenez les versions de RabbitMQ Server et Erlang/OTP alignées sur les nœuds. En pratique, exécutez la même version de RabbitMQ sur chaque nœud, sauf si vous suivez le processus de mise à niveau progressive documenté par RabbitMQ.
Accessibilité réseau : Les nœuds doivent communiquer sur les ports AMQP utilisés par les clients, le port de distribution utilisé pour le clustering, et tout port de gestion ou TLS que vous activez.
Résolution d'hôte : 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.
Cohérence du cookie : Le 'cookie magique' Erlang doit être identique sur tous les nœuds. Ceci est crucial pour que les nœuds se fassent confiance pour le clustering.

Établir la cohérence du cookie

Le cookie Erlang détermine si les nœuds peuvent communiquer de manière sécurisée. Il doit être copié du premier nœud initialisé à tous les autres.

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

Localisez le fichier 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) :

Arrêtez le service RabbitMQ :
```
sudo systemctl stop rabbitmq-server
```

Remplacez le fichier cookie existant par le contenu copié depuis le nœud A, en vous assurant des permissions correctes (généralement 400).

# Exemple utilisant echo (remplacez le contenu si nécessaire)
echo "VOTRE_LONGUE_CHAÎNE_COOKIE" | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

Démarrez le service sur le nœud B :
```
sudo systemctl start rabbitmq-server
```

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

Assurez-vous que les fichiers d'hôte 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 principal initial, où le cluster est d'abord établi.

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

Étape 3 : Joindre le deuxième nœud (Passif) au cluster

Maintenant, nous demandons au nœud B de rejoindre le cluster dirigé par le nœud A.

Arrêtez l'application RabbitMQ sur le nœud B tout en gardant le nœud Erlang disponible :
```
sudo rabbitmqctl stop_app
```
Réinitialisez l'état local du nœud B s'il a déjà été initialisé en tant que nœud autonome :
```
sudo rabbitmqctl reset
```
Commande de jointure : Exécutez la commande de jointure sur le nœud B, en spécifiant le nom d'hôte du nœud A comme pair.
```
sudo rabbitmqctl join_cluster rabbit@rabbitmq-node-a
```
Astuce : Utilisez le nom d'hôte défini dans /etc/hosts.
Démarrez l'application RabbitMQ sur le nœud B :
```
sudo rabbitmqctl start_app
```

É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 sortie attendu :

Vous devriez voir à la fois 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é pour les files d'attente

Le clustering standard de RabbitMQ partage les métadonnées telles que les utilisateurs, les échanges, les liaisons et les politiques. Le contenu des files d'attente nécessite un type de file d'attente répliqué si vous voulez que les messages survivent à une panne de nœud.

Pour les déploiements modernes de RabbitMQ, utilisez des files d'attente quorum pour les files d'attente durables répliquées. Les files d'attente miroir classiques utilisaient des politiques ha-mode dans les anciennes versions de RabbitMQ, mais cette approche est dépréciée et supprimée des versions majeures plus récentes.

Déclarer une file d'attente quorum

Vous pouvez déclarer des files d'attente quorum depuis votre application ou avec rabbitmqadmin. Cet exemple crée une file d'attente quorum durable :

rabbitmqadmin declare queue name=orders durable=true arguments='{"x-queue-type":"quorum"}'

Pour les laboratoires à deux nœuds, une file d'attente quorum peut fonctionner, mais elle ne peut pas tolérer la perte d'un nœud tout en conservant une majorité. En production, utilisez au moins trois nœuds RabbitMQ pour les files d'attente quorum afin qu'un nœud puisse tomber en panne tandis que la file d'attente conserve une majorité.

Étape 6 : Tester le basculement

Avant de déclarer le cluster prêt, testez le chemin que vos clients utiliseront :

Publiez quelques messages de test persistants dans une file d'attente quorum.
Arrêtez l'application RabbitMQ du nœud actif avec sudo rabbitmqctl stop_app.
Confirmez que les clients se reconnectent via votre équilibreur de charge, cible DNS ou configuration de découverte de services.
Consommez les messages de test depuis le nœud survivant.
Démarrez à nouveau l'application arrêtée avec sudo rabbitmqctl start_app et vérifiez rabbitmqctl cluster_status.

Conclusion finale

Le clustering RabbitMQ vous donne des métadonnées de courtier partagées, mais la disponibilité des files d'attente dépend du type de file d'attente et de la conception du basculement client. Utilisez des files d'attente quorum pour les files d'attente durables répliquées, gardez au moins trois nœuds pour une véritable tolérance aux pannes, et testez le basculement avec le même chemin de connexion que celui utilisé par vos applications.