RabbitMQ on Zwindler's Reflection

RabbitMQ Summit 2021 - 101 ways to break your RabbitMQ

Fri, 09 Jul 2021 06:30:00 +0000

RabbitMQ Summit, ma première conférence internationale en tant que speaker ! 😱

[English speakers & RabbitMQ Summit attendees, the slides link is at the end of the article]

Vous le savez maintenant, j’aime bien partager ce qui se passe mal dans mon boulot. Quand c’est shiny, c’est cool, mais soyons honnête, une grosse partie de notre boulot consiste à dépatouiller des problèmes en prod, pas toujours simples.

Et clairement c’est ce que je trouve le plus intéressant. C’est aussi en se trompant qu’on apprend.

C’est pour ça que j’avais proposé un talk « 101 ways to break your RabbitMQ » en anglais au RabbitMQ Summit en 2020 (j’avais participé en présentiel au RabbitMQ Summit 2019 et j’avais adoré). Comme le titre le laisse penser, il s’agit d’un REX de toutes les erreurs qu’on avait pu faire dans ma boite de l’époque (et on en a fait beaucoup).

COVID oblige, la conférence en 2020 a été reportée et cette année, elle a lieu en ligne les 13 et 14 juillet (et mon talk, accepté 🎉).

Le pitch

3 years ago, the company I worked for decided to start again, from scratch. Instead of on-prem softwares, we started to develop dozens of cloud based microservices communicating with each other AND on-prem cutting equipments. And which tool better to do this than RabbitMQ? But of course, deploying highly available message brokers in a cloud based environment with no prior experience has brought its share of surprises. In this talk, I’ll share with you some of the rooky mistakes that we may or may not have made ;-)

Où est ce que ça se passe ?

Événement international oblige, l’horaire est un peu inhabituel. Je présenterai mon talk à 20h40 le 13 juillet. La conférence elle à lieu les 13 et 14 juillet, de 17h à minuit pour les 2 jours.

L’inscription est par contre payante, même si je dispose d’un code de promotion si jamais ça vous intéresse (donc n’hésitez pas à me demander).

Slides

As usual, slides are available just before the talk here:

Slides

Stay tuned

Récap’ du RabbitMQ Summit 2019

Tue, 05 Nov 2019 12:45:09 +0000

Des lapins partout, nous étions au RabbitMQ Summit !

Dimanche soir, je suis arrivé à Londres pour participer, avec deux de mes collègues, au RabbitMQ Summit 2019. Cette journée est dédiée à mon broker de messages préféré, RabbitMQ (et non ce n’est pas Kafka - ceci est un troll gratuit pour mes collègues).

Pour ceux qui n’auraient pas suivi, j’ai déjà écris quelques articles sur le sujet dont une introduction si vous débutez.

Cette journée a été l’occasion de pouvoir faire le plein de bonnes pratiques, REX, et autres protips pour optimiser nos clusters.

Keynote

Sans surprise, la keynote d’introduction était réalisée par des membres de la core team de RabbitMQ (Diana ParraCorbacho et Michael Klishin), qui ont parlé de l’actualité du Broker.

Une version majeure de RabbitMQ est sortie en octobre (la 3.8) et de nombreuses des features annoncées l’an dernier sont maintenant utilisables.

Je suis particulièrement enthousiaste à propos des quorum queues et des métriques Prometheus natives, qui sont clairement les deux stars de cette édition, avec plusieurs talks dédiés ou y faisant référence.

L’ajout de features flags pour faciliter les mises à jours (présents à partir de la 3.7.20+ ou 3.8+) est clairement un autre gros point positif. Michael Klishin a officiellement indiqué que le blue/green deployment n’était désormais plus la seule méthode supportée pour mettre un cluster à jour.

La 3.8 étant maintenant derrière nous (seulement des bugs fix sortiront à partir de maintenant), cap sur la 3.9 !

Dans les points importants, un travail va être réalisé pour rendre le core de chaque protocole identique. En effet, aujourd’hui, chaque protocole supporté par RabbitMQ est un module spécifique. Une refonte de l’UI est aussi prévue.

Dans les annonces, une version entreprise (RabbitMQ Entreprise Edition) devrait également voir le jour dans les mois qui viennent. Identique à la version communautaire dans les grandes lignes, elle intégrera des modifications supplémentaires pour faciliter l’hébergement de cluster RabbitMQ inter-connecté sur un WAN ou crossDC. Bien évidemment un support pro fera parti du package.

Le dernier point abordé, pour le futur, est le gros travail sur le “moteur de stockage” utilisé par RabbitMQ (pour la configuration et la persistance). Aujourd’hui, ce travail est réalisé par un projet annexe appelé Mnesia. Michael Klishin a insisté sur le fait que même si le code restait pertinent, la base de code était elle vieillissante.

Un nouveau projet Mnevis avait donc été lancé. Cette réécriture de 0 à pour but de mieux prendre en compte des problématiques multi DC et une meilleure reprise sur incident.

Même si Mnevis ne sera pas officiellement pas disponible pour tout de suite, (probablement pas avant la version 4) un prototype devrait être disponible avec une version modifiée de RabbitMQ. Les sources de Mnevis sont disponibles ici. On aura certainement plus d’infos au prochain RabbitMQ Summit !

Practical Advice for the Care & Feeding of RabbitMQ

La keynote passée, Gavin Roy a présenté un REX sur plus de 10 ans d’utilisation de RabbitMQ en production, avec les pièges dans lesquels lui et son équipes étaient tombés.

De soucis de code PHP qui ouvrait des connexions éphémères (coûteuses dans RabbitMQ), jusqu’à l’envoi de messages contenant des payloads (alors que AMQP propose d’ajouter des metadata), en passant par des lenteurs dues à des erreurs de configuration, le talk a été riche en bonnes pratiques (ou plutôt, mauvaises pratiques à éviter !).

Même si certaines erreurs peuvent sembler faciles à éviter (surtout avec le recul), c’est un de mes talks préférés de la journée, avec de nombreuses réflexions à venir, une fois rentré.

Prometheus Export

C’est le 2ème gros sujet de la journée. J’ai assisté à la présentation de l’ajout de métriques natives au format OpenMetrics directement dans RabbitMQ.

Un des gros soucis de l’interface de management actuelle et des métriques qu’elle expose est qu’il est nécessaire de disposer de privilèges important pour les consulter. Dans un contexte multi-équipes (ou multitenant), ce n’est pas pratique. Le second est un problème de performance. Actuellement l’interface de management (plugin de RabbitMQ) arrive parfois à saturation, nécessitant en cas de charge plusieurs dizaines de secondes à s’afficher.

Pour éviter ces soucis, certains d’entre vous utilisent peut être le rabbitmq-exporter, qui récupère les données de la management UI et les expose à Prometheus au format OpenMetrics. Cependant, ce client, tributaire de la management UI, est nécessairement également limité en cas de surcharge.

La vraie solution qui vient de sortir en 3.8 est donc l’exposition native de métriques au format OpenMetrics. Cet ajout a a priori déjà été énormément bénéfique à RabbitMQ et son écosystème, permettant de déceler plusieurs portions de code inefficientes dans le code de RabbitMQ et même dans le code de Erlang (bugs fixés depuis).

Après déjeuner, 2 talks… un peu décevant…

Les talks suivants (“Source oriented exchanges pattern to keep events in order” et “RabbitMQ MQTT versus EMQX”) ne sont pas simples à retranscrire.

Le premier était très générique, sur la façon de gérer correctement un processus nécessitant que les messages soient traités dans l’ordre.

Le second, un peu étonnant, comparait RabbitMQ avec un produit concurrent au travers du scope MQTT et sur un usecase très précis.

Quelques points que j’ai retenu :

j’ai raté un talk de Wework qui parle de sharding et qui est probablement intéressant à (re)voir (Wework’s “good enough” order guarantee, je mettrai à jour le lien)
il existe un outil appelé MZ Tool (???) qui permet de stress-tester vos infrastructures MQTT. Ce dernier peut être piloté par Ansible ou Terraform. J’ai trouvé un projet MZ-Tools qui n’a rien à voir… Je continue à chercher.

RabbitMQ at Scale

Partenaires principaux du RabbitMQ Summit, les gens de Code84 (CloudAMQP) étaient présents, en nombre ! La société est spécialisée dans l’hébergement de serveurs RabbitMQ, mais aussi de Kafka, PostgreSQL et Mosquitto en mode PaaS. La société est également connue sur son blog technique pléthorique.

Lovisa Johansson (qui a écrit la plupart des articles du blog, que je recommande chaudement) et Anders Bälter nous ont présenté le cheminement de leur société depuis 2012. En partant de simples API Heroku et de serveurs AWS, la plateforme hébergement maintenant les serveurs RabbitMQ de milliers de clients, tout en publiant des métriques, des logs, des alertes, vers la plupart des composants SaaS connus.

Ce talk a aussi été l’occasion de présenter quelques statistiques d’utilisation, notamment sur les moyennes/maximums de métriques comme le nombre de messages par secondes, le nombre de vhosts ou de policy, etc.

Feature complete: uncovering the true cost of different rabbitmq features and configurations

Le dernier talk auquel que nous avons vu a été donné par Jack Vanlightly, qui travaille maintenant chez Pivotal (l’éditeur de RabbitMQ).

Ce talk a été extrêmement riche et mérite d’être revu, à tête reposée.

Jack Vanlightly a fait une série de bench sur plusieurs types de serveurs, avec diverses compositions de producers/consumers, types d’exchanges et d’autres paramètres moins connus.

Les cas étaient parfois extrêmes, mais je pense que les différents cas qu’ils illustrent s’avéreront utiles pour tuner des comportements d’apparence anormaux dans des cas réels (quel paramètre tuner en fonction du nombre de consumers ou de la latence du réseau par exemple).

Conclusion

Malgré notre envie de rester jusqu’au bout, nous devions partir pour arriver à l’heure pour notre vol retour.

Ce RabbitMQ Summit a été l’occasion de discuter avec d’autres utilisateurs de RabbitMQ et de revoir les bonnes pratiques avec des professionnels qui en hébergent des milliers (600000 connexions actives chez CloudAMQP tout de même !).

Ça a aussi été l’occasion de voir que nous n’étions pas aussi “petits” que nous pensions dans notre usage de RabbitMQ, même si nous sommes très loin des limites de l’application dans nos cas d’usage !

Les joies du Dual Tracks ont fait que nous avons forcément raté certains talks que nous aurions voulu voir… Heureusement qu’il y aura les vidéos sur YouTube dans quelques jours/semaines !

A refaire, donc !

Suivez le lapin Orange – Intro et bonnes pratiques d’infra RabbitMQ

Tue, 16 Apr 2019 11:45:07 +0000

C’est quoi RabbitMQ ?

RabbitMQ® est un logiciel open source, développé par Pivotal. Il s’agit d’un message broker (bus/agent de messages), très simple à mettre en place, multiplateforme et multiprotocole (AMQP, MQTT, STOMP).

RabbitMQ est donc particulièrement adapté pour monter rapidement une architecture microservice, voire même IoT, nécessitant un bus de message pour garantir les communications entre les différentes briques de cette architecture.

C’est justement dans mon contexte pro : nous disposons d’une architecture logicielle aux composantes très différentes (microservices, machines outils connectées, …). Nous avons donc besoin de cette agilité, qu’on ne retrouve pas forcément dans les autres messages brokers, mais aussi de garanties et des contrôles sur les transports des messages que nous n’aurions pas forcément avec des API REST.

Architecture et bonnes pratiques

Voici à quoi ressemble l’architecture RabbitMQ que nous utilisons :

A première vue, c’est assez simple. Mais si vous vous demandez si nous n’aurions pas pu faire encore plus simple, alors cet article est fait pour vous ;).

AMQPS / WebMQTTS

Les plus observateurs d’entre vous auront peut être remarqués le « S » à la fin des deux protocoles que nous utilisons pour faire communiquer nos services entre eux :

AMQP / AMQPS
WebMQTT / WebMQTTS

Vous l’aurez sûrement deviné, il s’agit de la déclinaison non-sécurisée/sécurisée (chiffrée) de chacun de ces protocoles.

Par défaut dans RabbitMQ, les échanges ne sont pas chiffrés. Bien qu’il n’y ait pas de réponse universelle à la question « dois-je chiffrer l’ensemble de mes flux ? », l’Ops que je suis ne peux pas s’empêcher de répondre un grand OUI.

C’est particulièrement vrai dans notre cas, où une partie des flux transite par Internet, et l’autre transite à l’intérieur du réseau de notre cloud provider. L’ajout du chiffrement est obligatoire. Le risque d’espionnage, de détournement d’information, de Man in the Middle, sont suffisamment sérieux pour qu’on prenne le temps de configurer un chiffrement TLS.
Cependant, l’impact sur les performances globales de la plateforme est réel et devra être pris en compte lors du choix de l’architecture.

Comment activer le chiffrement TLS sur mes interfaces RabbitMQ ?

Tout se passe dans les fichiers de configuration. Il faudra déposer les fichiers de certificats (CA, certificat public et clé privée) et rajouter les lignes suivantes dans votre configuration :

[
{rabbit, [{ssl_options, [{cacertfile, /path/to/testca/cacert.pem"},
{certfile, /path/to/server_certificate.pem"},
{keyfile, /path/to/server_key.pem"},
{verify, verify_peer},
{fail_if_no_peer_cert, true}]}]}
].

Cependant, là aussi par défaut, il n’y a pas de restrictions sur les protocoles disponibles. Or, les failles sur SSL et TLS 1.0 de ces dernières années nous obligent à désactiver ces protocoles obsolètes (voire même TLS 1.1 aussi), ainsi que tous les ciphers non sécurisés, ce qui va nettement complexifier notre configuration :

%% -*- mode: erlang -*-
[
{ssl, [
{versions, ['tlsv1.2']}
]},
{rabbit, [
{ssl_listeners, [5672]},
{ssl_options, [
{cacertfile, /etc/rabbitmq/certs/cacert.pem"},
{certfile, /etc/rabbitmq/certs/cert.pem"},
{keyfile, /etc/rabbitmq/certs/key.pem"},
{versions, ['tlsv1.2']},
{ciphers, [
{ecdhe_ecdsa,aes_256_gcm,null,sha384},
{ecdhe_rsa,aes_256_gcm,null,sha384},
{ecdhe_ecdsa,aes_256_cbc,sha384,sha384},
{ecdhe_rsa,aes_256_cbc,sha384,sha384},
{ecdh_ecdsa,aes_256_gcm,null,sha384},
{ecdh_rsa,aes_256_gcm,null,sha384},
{ecdh_ecdsa,aes_256_cbc,sha384,sha384},
{ecdh_rsa,aes_256_cbc,sha384,sha384},
{dhe_rsa,aes_256_gcm,null,sha384},
{dhe_dss,aes_256_gcm,null,sha384},
{dhe_rsa,aes_256_cbc,sha256},
{dhe_dss,aes_256_cbc,sha256}
]},
{verify, verify_peer},
{fail_if_no_peer_cert, false}]}
]}
].

A noter, depuis la version 3.7 de RabbitMQ (dernière version en date, la 3.8 sort bientôt), le format de la configuration a changé (erlang => sysctl) pour être plus lisible et plus simple à automatiser. Cependant, à ma connaissance, il n’est pas possible de configurer l’ensemble des limitations de ciphers/protocoles.

« While the new config format is more convenient for humans to edit and machines to generate, it is also relatively limited compared to the classic config format used prior to RabbitMQ 3.7.0. »

Et pourquoi 3 nœuds et pas juste un, au milieu ?

Cette question est volontairement provocatrice ;-p.

Comme tout service informatique, les objectifs en terme d’indisponibilités tendent forcément vers 0. Un moyen classique d’approcher cet objectif est de redonder les composants informatiques, pour éviter tout Single Point of Failure.

Ça tombe très bien, puisque RabbitMQ propose nativement un mécanisme de clustering. Et comme dans tout cluster disposant d’un mécanisme de vote/d’élection, il est fortement conseillé d’avoir un nombre impair de nodes pour résoudre les cas de split brain (la majorité l’emporte en cas de partition réseau). D’où les 3 nœuds (mais on peut en avoir 5, 7, …).

Le clustering dans RabbitMQ, comment ça marche ?

Pour simplifier notre vie, le cluster RabbitMQ agit de telle sorte que tous les objets logiques (utilisateurs, queues, …), où qu’ils soient, sont connus et adressables depuis tous les membres (attention, je n’ai pas dis répliqués, on y reviendra).

Ça, c’est super pratique. Quel que soit le nœud qu’on va contacter, si la queue est présente sur un autre serveur RabbitMQ, le message sera redistribué de manière transparente vers le nœud qui possède la queue.

Pour « masquer » la complexité induite par l’ajout de serveurs RabbitMQ supplémentaires, on a donc juste à ajouter un loadbalancer en amont du cluster. Le développeur envoie simplement le message au loadbalancer. Peu importe le nœud sur lequel le message sera réellement envoyé ensuite, il sera transféré instantanément.

Comment démarrer un cluster ?

Sans rentrer dans le détail de toutes les opérations nécessaires pour bootstrapper un cluster, ce qu’il faut savoir c’est que tous les nœuds doivent évidemment pouvoir se contacter et si possible être relativement proches (en terme de latence).

Les serveurs RabbitMQ doivent être configurés de manière à partager une même passphrase dans le fichier /var/lib/rabbitmq/.erlang.cookie, et on doit ensuite joindre un des noeuds depuis les deux autres avec la commande suivante :

#sur le node rabbit2, puis rabbit3
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@rabbit1

la documentation qui est très bien écrite.

Maintenant, on est hautement disponibles ?

Vous vous dites : « Chouette ! J’ai un cluster ! Je suis hautement disponible ! »

Et bien… non.

Un point pouvant induire une grande confusion dans RabbitMQ est la terminologie « cluster RabbitMQ ». Le fait de monter un cluster laisse penser que tout devient automatiquement hautement disponible.

Or, en réalité, comme je l’ai écris plus haut, il s’agit uniquement de rendre accessible et addressable l’ensemble des objets logiques depuis tous les nœuds. En revanche, les queues, et a fortiori leur contenu, ne sont physiquement présentes que sur un nœud et un seul.

Ainsi, si un nœud du cluster disparaît, toutes les queues qu’il possède seront détruites (si elles sont Transient), ou bloquées jusqu’à ce que le nœud soit de nouveau disponible (si elles sont Durable).

Dans tous les cas, il y aura interruption de service et éventuellement perte de messages, malgré le fait qu’on ait un cluster !

Haute disponibilité des queues

Heureusement, il est également possible de répliquer les queues et leur contenu sur une partie ou la totalité des nœuds disponibles dans le cluster. On dispose alors d’une queue principale et de miroirs qui pourront prendre le relai en cas de défaillance d’un nœud.

Ceci est configurable, par queue ou par policy (applicable à toutes les queues correspondant au pattern), avec les options ha-mode, ha-params et ha-sync-mode.

ha-mode
- all : synchronisera votre queue sur des miroirs présents sur tous les nœuds du cluster
- exactly : permettra d’indiquer, en positionnant également un nombre sur ha-params, le nombre exact de nœuds sur lesquels les queues sont répliquées
- nodes : synchronisera des miroirs sur une liste de nœuds explicitement nommés
ha-sync-mode
- automatic : en cas d’apparition d’un nouveau miroir, tous les messages sont synchronisés immédiatement
- manual : en cas d’ajout d’un nouveau miroir, seul les nouveaux messages sont synchronisés

Attention au mode automatic, surtout en conjugaison avec le ha-mode à all. En effet, si ce mode est plus sécurisé puisqu’il garantie que tous les nœuds ont bien la totalité des messages, il a aussi l’inconvénient de bloquer les queues « à synchroniser » (tant que l’ensemble des messages ne sont pas répliqués partout).
Dernier point d’attention, au même titre que le chiffrement, l’ajout de la haute disponibilité (et du clustering, dans une moindre mesure) a un impact sur les performances globales de la plateforme.

Conclusion

RabbitMQ est un outil puissant et extrêmement simple à mettre en place. On peut le lancer et obtenir un broker de message robuste avec une simple commande « docker run ».

docker run -d --hostname my-rabbit --name some-rabbit rabbitmq:3

Pour autant, dans un environnement de production avec des objectifs en terme de haute disponibilité, il n’est pas si trivial de trouver les bons paramètres. Certains nécessiteront un peu de recherche et de configuration erlang, d’autres nécessiteront un peu de benchmarking et de tuning, si les performances commencent à devenir un problème.

Pour cette seconde catégorie, j’y reviendrai dans un autre article. Cependant, sachez quand même qu’on peut traiter sans trop de difficulté des milliers de messages par secondes, même avec des machines disposant de peu de CPU. Vous aurez surement le temps de voir venir ;).

Répartir les queues équitablement entre vos nœuds RabbitMQ

Wed, 04 Apr 2018 17:00:02 +0000

RabbitMQ quoi?

Je vais être honnête, il y a 2 mois je ne connaissais pas grand chose aux messages brokers. Et depuis j’ai découvert RabbitMQ.

Messaging that just works

Quoi de mieux pour mettre le pied à l’étriller que ce genre de logiciel qui vous explique d’emblée que ça va être simple ? Bon en réalité ça n’a pas été si simple que ça ;-)

RabbitMQ est un message broker open source écrit en erlang (er-quoi ?? oui, moi non plus…). Il est développé par les équipes Pivotal, qui a repris le projet en mai 2013.

C’est donc une sorte de bus central de communication pour faire transiter des messages d’applications vers applications ([1:n]-to-[1:n]) sans qu’elles se parlent en direct. C’est particulièrement pratique dans le cas de microservices dont on veut découpler et donc sécuriser les échanges (plutôt que de faire du HTTP en best effort).

Pourquoi RabbitMQ ?

L’avantage vraiment mis en avant par RabbitMQ, c’est qu’il est simple. Mais il est aussi puissant et relativement complet.

Il a l’avantage de supporter plusieurs protocoles (ce que les messages broker ne font pas tous), d’apporter une couche d’abstraction utile avec la notion d’exchange et de permettre sans effort la création du clusters via une simple ligne de commandes. J’aurai probablement l’occasion de revenir sur les « clusters » de RabbitMQ (notez les guillemets).

Source : Tutoriel helloworld de RabbitMQ // https://www.rabbitmq.com/tutorials/amqp-concepts.html

Au delà de ça, je ne vais pas vous insister, car d’une part la documentation est plutôt bien faite et comporte plusieurs tutoriels bien sympa, et d’autre part, j’ai vu passer d’autres tutos sur les réseaux récemment. Je vous colle quelques liens sympa pour commencer :

Racontes nous une histoire

Pour simplifier notre vie, le cluster agit de telle sorte que tous les objets logiques (utilisateur, queue, exchange), où qu’ils soient, sont connus et adressables depuis tous les membres du cluster. Cependant, une notion importante à comprendre quand on parle de cluster sur RabbitMQ est qu’à un moment donné, une queue n’est physiquement présente que sur un serveur, même en cluster.

J’explique : si on adresse une requête au serveur B pour la queue/file 1 qui est sur le serveur A, celui ci redirigera gentiment la requête vers le serveur 1.

Pour l’utilisateur / développeur, ça sera transparent, mais pour le sysadmin c’est une autre paire de manches.

Supposons que pour une raison ou pour une autre, toutes les queues soient hébergées sur un même nœud. Dans ce cas là, toute la charge sera portée par ce serveur et les autres ne feront que passe plat.

Dans quels cas ça arrive ?

Alors vous allez me dire : pfff ya aucune raison que toutes les queues soient sur le même nœud…

Et ben si, yen a même plusieurs ;-)

Sans vous spoiler un article futur, on peut très rapidement se retrouver avec ce genre de blague lorsqu’on met à jour les serveurs du cluster uns par uns, jusqu’à ce que le dernier serveur se retrouve à supporter l’ensemble de la charge.

Et là, vous êtes bien embêtés, car vous n’avez pas de moyen de transférer les queues sur plusieurs autres serveurs. On peut toujours les supprimer puis les recréer une par une sur des serveurs distincts, mais niveau répartition de charge, on a vu mieux…

Et alors comment on fait ?

Il est possible d’indiquer à RabbitMQ qu’il doit répliquer certaines queues sur un nœud en particulier, puis, une fois le contenu de la queue synchronisée, de retirer le serveur initial de la liste des nœuds de cette queue.

Je vous sens encore sceptiques. « On est pas plus avancés » me direz vous ?

En effet, il faut encore prendre les queues unes par unes et les déplacer sur un autre nœud puis les supprimer du nœud initial. Oui, sauf que les développeurs de RabbitMQ, conscients du problème, ont créés un plugin pour automatiser tout ça. On en arrive à l’objet de cet article : rabbitmq-queue-master-balancer

RabbitMQ Queue Master Balancer is a tool used for attaining queue master equilibrium across a RabbitMQ cluster installation. The plugin achieves this by computing queue master counts on nodes and engaging in shuffling procedures, with the ultimate goal of evenly distributing queue masters across RabbitMQ cluster nodes.

Traduction : ça permet de répartir nos queues de manière à peu près équitable entre les nœuds (en partant du principe généralement erroné que la charge est proportionnelle au nombre de queues hébergées par le nœud).

Installation

RabbitMQ, en plus de tout ce qu’on a dit de chouette à son propos, permet aussi d’être étendu à l’aide de plugins. On peut aller télécharger celui qui nous intéresse sur Github.

wget https://github.com/Ayanda-D/rabbitmq-queue-master-balancer/releases/download/v0.0.3/rabbitmq_queue_master_balancer-0.0.3.ez

Point qui n’est pas forcément mis en avant dans le projet rabbitmq_queue_master_balancer, les plugins peuvent être déposés dans 2 dossiers différents. Un commun à toutes nos versions, et un qui change à chaque mise à jour.

/usr/lib/rabbitmq/plugins
/usr/lib/rabbitmq/lib/rabbitmq_server-[version]/plugins/

Vous trouverez plus d’information sur les plugins RabbitMQ et leur fonctionnement au niveau de la page dédiée à leur sujet.

Dans notre cas, le plugin n’est pas dépendant de votre version. On créé donc le dossier pour le contenir, puis on l’y dépose.

sudo mkdir /usr/lib/rabbitmq/plugins
sudo mv rabbitmq_queue_master_balancer-0.0.3.ez /usr/lib/rabbitmq/plugins/

Comme n’importe quel autre plugin « built-in », on peut maintenant l’activer depuis la ligne de commande habituelle rabbitmq-plugins

sudo rabbitmq-plugins enable rabbitmq_queue_master_balancer

Utilisation

Voici maintenant un exemple d’utilisation qui va vous permettre de vous familiariser avec l’outil. Tout se passe en ligne de commandes (c’est un peu spartiate). On va demander à rabbitmqctl d’exécuter des fonctions provenant de notre plugins.

On commence par afficher la répartition actuelle dans notre cluster avec la fonction report()

sudo rabbitmqctl eval 'rabbit_queue_master_balancer:report().'
{ok,[{'rabbit@rabbitmq2',{queues,0}},
{'rabbit@rabbitmq3',{queues,30}},
{'rabbit@rabbitmq1',{queues,0}}]}

Ici, on voit que toutes les queues se sont retrouvées sur le rabbitmq3 suite à un rolling upgrade.

On lance donc le processus de répartition des queues avec la fonction go()

sudo rabbitmqctl eval 'rabbit_queue_master_balancer:go().'
ok

A partir de là, si vous êtes simultanément connecté sur votre console web d’administration de RabbitMQ, vous verrez en live qu’il s’y passe des choses. En ligne de commande, vous pourrez aussi voir où ça en est avec la fonction status()

sudo rabbitmqctl eval 'rabbit_queue_master_balancer:status().'
[{process_id,<9157.8313.0>},
{queues_pending_balance,18},
{memory_utilization,284640}]

Ici il reste encore 18 queues à re-répartir. Au final, tout devrait rentrer dans l’ordre :

sudo rabbitmqctl eval 'rabbit_queue_master_balancer:report().'
{ok,[{'rabbit@rabbitmq2',{queues,10}},
{'rabbit@rabbitmq3',{queues,9}},
{'rabbit@rabbitmq1',{queues,11}}]}

Les plus tatillons d’entre vous auront sûrement remarqué que nous n’avons pas eu une répartition parfaite de nos 30 queues (10*3). Ceci est voulu, pour une raison de formule mathématique obscure, explicitée sur le dépôt Github du plugin :

https://github.com/Ayanda-D/rabbitmq-queue-master-balancer

Et tu voudrais pas faire un playbook Ansible pour ça ?

Ahah la bonne blague. BIEN SUR que j’en ai fais un playbook Ansible (parce que je suis fan d’Ansible).

---
- hosts: all
vars:
- queue_master_balancer_version: "0.0.3"
tasks:
- name: "Create /usr/lib/rabbitmq/plugins directory for queue balancer plugin"
file:
path: /usr/lib/rabbitmq/plugins
state: directory
mode: 0755
- name: "Download rabbitmq-queue-master-balancer plugin"
get_url:
url: "https://github.com/Ayanda-D/rabbitmq-queue-master-balancer/releases/download/v{{queue_master_balancer_version}}/rabbitmq_queue_master_balancer-{{queue_master_balancer_version}}.ez"
dest: "/usr/lib/rabbitmq/plugins/rabbitmq_queue_master_balancer-{{queue_master_balancer_version}}.ez"
- name: "Add rabbitmq_queue_master_balancer to the list of enabled plugins"
rabbitmq_plugin:
names: rabbitmq_queue_master_balancer
new_only: yes
state: enabled

A noter, j’utilise l’option new_only du module rabbitmq_plugin pour éviter de désactiver bêtement les plugins déjà actifs.

Protip gratuite ;) ça serait balo de désactiver tout le reste.