OpenStack haute-disponibilité #3 RabbitMQ

Posted on Sun 22 November 2015 in misc

RabbitMQ LogoLes composants des APIs de OpenStack ont recours à un serveur AMQP pour traiter les demandes de manière asynchrone, un message est posté sur la file de message et les services qui exécutes réellement le travail prennent les tickets et exécutent la tâche (tient, ça ressemble à mon job).

Ce service est extrèmement important, la majorité des tâches sont exécutées de cette manière (création de VM, destruction, création d'un réseau...).

Nous allons donc renforcer le serveur AMQP RabbitMQ en le configurant en mode cluster, par chance, RabbitMQ est nativement prévu pour cela. La documentation officielle propose un guide sympatique dont ce billet n'est qu'une pâle adaptation.

Comme précédement lors de la configuration de Keepalived et l'installation de HAProxy, nous disposons de trois noeuds ( 9lpo192, 9lpo134, 9lpo135) qui se connaissent bien depuis le temps (résolution DNS ou /etc/hosts).

Installation de RabbitMQ

Simplement, sur chacun des noeuds :

aptitude install rabbitmq-server

On peut vérifier que le serveur est seul dans son cluster via :

$ rabbitmqctl cluster_statusCluster status of node rabbit@9lpo192 ...[{nodes,[{disc,[rabbit@9lpo192]}]}, {running_nodes,[rabbit@9lpo192]}, {partitions,[]}]...done.

Histoire de cookies

Pour dialoguer entre eux, les noeuds d'un cluster RabbitMQ doivent partager quelque chose, un cookie. Moi quand je dois partager un cookie, ça ne m'ouvre pas au dialogue, mais bon... Sous Linux, ce cookie est placé dans le fichier /var/lib/rabbitmq/.erlang.cookie.

Ce cookie est créé lors de l'installation du service rabbitmq-server. Nous allons prendre le cookie de 9lpo192 :

$ cat /var/lib/rabbitmq/.erlang.cookie
UEOMRUIRMVISFTILGZW

Puis le diffuser sur tous les noeuds :

$ echo "UEOMRUIRMVISFTILGZWU" > /var/lib/rabbitmq/.erlang.cookie

Mise en place du cluster

Les noeuds disposent du cookie et font tourner leurs propres instances. Nous allons paramétrer les serveurs RabbitMQ afin de les faire fonctionner en mode cluster.

Sur 9lpo134 et 9lpo135, nous allons :

  1. Stopper le serveur
  2. Ajouter l'hôte au serveur cluster
  3. Démarrer le serveur
$ rabbitmqctl stop_app
$ rabbitmqctl join_cluster rabbit@9lpo192
$ rabbitmqctl start_app

A la suite de quoi, nous pouvons vérifier que les serveurs RabbitMQ se sont bien mis en cluster avec la commande (sur n'importe quel hôte) :

$ rabbitmqctl cluster_status
Cluster status of node rabbit@9lpo134 ...
[{nodes,[{disc,[rabbit@9lpo134,rabbit@9lpo135,rabbit@9lpo192]}]}]
...done.

Par défaut, une file est hébergée sur un seul des hôtes du cluster (mais accessible de tous). RabbitMQ permet de créer des files hautement disponibles, ces files sont mise en mirroir sur les noeuds du cluster.

Pour activer les files de message hautement disponible (Highly Available Queues), il faut signaler au cluster que toutes les files seront de type mirroir :

$ rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{"ha-mode": "all"}'

Cette commande place toutes les files de message (amq.*) dans le ha-mode all, ce mode duplique la file sur chacun des noeuds.

Nous avons maintenant trois serveurs AMPQ qui fonctionnent en mode cluster. Nous référencerons ces 3 serveurs sur les fichiers de configuration afin que Oslo (composant OpenStack qui gère les fonctions communes comme AMPQ) trouve toujours un endroit pour publier ou consommer un message.

OpenStack RabbitMQ