Clustering RabbitMQ sur CentOS 7

• Conditions préalables
• Configurer le pare-feu
• Installer rabbitmqadmin
• Configurer DNS
• Cluster les nœuds
• Créer une politique de haute disponibilité
• Test de la configuration
• Supprimer l'utilisateur invité

RabbitMQ est un courtier de messages open source qui prend en charge AMQP, STOMP et d'autres technologies de communication. Il est largement utilisé dans les applications d'entreprise et les architectures de micro-services modernes où il agit comme un canal de message asynchrone entre différents micro-services. Ce guide décrira comment vous pouvez regrouper RabbitMQ sur plusieurs serveurs CentOS 7 pour former un courtier de messages à haute disponibilité. Dans ce didacticiel, un serveur agira comme serveur maître et les autres serveurs agiront comme serveurs miroir au cas où le serveur maître deviendrait indisponible.

Conditions préalables

• Au moins deux instances CentOS 7 fraîchement déployées et mises à jour dans le même sous-réseau avec mise en réseau privée activée
• RabbitMQ installé avec la console de gestion activée sur chaque serveur (voir Comment installer RabbitMQ sur CentOS 7 )
• Un utilisateur non administrateur avec des droits sudo (voir Comment utiliser Sudo sur Debian, CentOS et FreeBSD )

Configurer le pare-feu

Le pare-feu CentOS, ( firewalld), n'autorise aucun trafic entrant par défaut. Pour rendre RabbitMQ disponible pour d'autres systèmes à l'intérieur et à l'extérieur du réseau, et pour nous permettre d'accéder à la console de gestion, nous devons d'abord ouvrir certains ports.

La console de gestion de l'interface Web de RabbitMQ écoute par défaut sur le port 15672. Nous souhaitons rendre la console de gestion accessible au public afin de pouvoir y accéder depuis notre ordinateur. Nous allons donc demander firewalldd'ouvrir définitivement le port 15672dans la zone publique (qui est la zone par défaut et active sur une instance Vultr).

sudo firewall-cmd --zone=public --add-port=15672/tcp --permanent

Les nœuds RabbitMQ doivent pouvoir communiquer entre eux. Nous aimerions ouvrir les ports nécessaires, mais uniquement sur le réseau interne. Nous ne voulons pas que quiconque sur Internet puisse administrer ou contacter directement nos serveurs. Les commandes suivantes supposent que nos serveurs sont sur le 192.168.0.100/24sous - réseau.

Le premier service est le epmdservice de découverte d'homologue qui écoute par défaut sur le port 4369.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="4369" accept'

Pour les communications entre nœuds et CLI, RabbitMQ doit pouvoir communiquer sur le port 25672.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="25672" accept'

Les outils CLI communiquent sur la plage de ports 35672-35682.

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="35672-35682" accept'

Si vos applications ont besoin du protocole AMQP, vous devrez également ouvrir les ports 5671et 5672. Si vous devez pouvoir communiquer via un autre protocole, vous pouvez trouver les informations nécessaires sur les exigences de mise en réseau de RabbitMQ sur la documentation officielle de RabbitMQ .

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="5672" accept'

sudo firewall-cmd --permanent --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.0.100/24"
  port protocol="tcp" port="5671" accept'

Maintenant qu'il firewalldest configuré, nous devons lui demander de recharger la configuration.

sudo firewall-cmd --reload

Répétez les étapes de cette section sur tous les serveurs.

Installer rabbitmqadmin

Le plugin de gestion est livré avec un outil Python appelé rabbitmqadminqui peut être facilement installé sur le système une fois le plugin de gestion activé.

sudo wget http://localhost:15672/cli/rabbitmqadmin
sudo mv rabbitmqadmin /usr/local/bin/
sudo chmod +x /usr/local/bin/rabbitmqadmin

Configurer DNS

Vous devez utiliser les noms d'hôte du serveur pour identifier les serveurs lors du clustering. Par défaut, aucun enregistrement DNS n'est attribué aux serveurs et la connexion échoue. Pour surmonter rapidement cela, ajoutez le nom d'hôte maître et miroir au /etc/hostsfichier à l'aide de votre éditeur préféré.

Par exemple, le fichier d'hôtes de votre maître peut ressembler à ceci. Remarquez les deux derniers enregistrements, qui permettent aux serveurs de s'identifier par leur nom d'hôte. Assurez-vous de changer les adresses IP pour les vôtres.

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

127.0.0.1 guest
::1       guest

127.0.0.1 YOUR_MASTER_SERVER_HOST_NAME
::1       YOUR_MASTER_SERVER_HOST_NAME


192.168.0.101 YOUR_MASTER_SERVER_HOST_NAME
192.168.0.102 YOUR_MIRROR_SERVER_HOST_NAME

Cluster les nœuds

Une condition préalable à l'importation pour permettre aux nœuds de se rejoindre est que le cookie Erlang de tous les nœuds est identique. Par défaut, chaque nœud se verra attribuer un cookie Erlang unique, vous devez donc le reconfigurer sur tous les nœuds.

La commande suivante définira le cookie Erlang sur " WE<3COOKIES", mais n'hésitez pas à le modifier à votre guise. Faites cela sur tous les serveurs.

sudo sh -c "echo 'WE<3COOKIES' > /var/lib/rabbitmq/.erlang.cookie"

Redémarrez RabbitMQ sur tous les serveurs pour vous assurer que le cookie Erlang est correctement rechargé.

sudo systemctl restart rabbitmq-server.service

Exécutez les commandes suivantes sur tous les serveurs sauf sur le serveur maître. Cela permettra aux nœuds de rejoindre le serveur maître et de former un cluster.

sudo rabbitmqctl stop_app
sudo rabbitmqctl join_cluster "rabbit@<YOUR_MASTER_SERVER_HOST_NAME>"
sudo rabbitmqctl start_app

Vérifiez que les nœuds ont rejoint le cluster en exécutant la commande suivante.

sudo rabbitmqctl cluster_status

Tous vos nœuds apparaîtront dans la section nodeset running_nodesde la sortie. Désormais, vous n'avez plus besoin de répéter les étapes sur chaque serveur, la configuration sera automatiquement mise en miroir sur les autres nœuds.

Créer une politique de haute disponibilité

Maintenant que nous avons un cluster de nœuds RabbitMQ, nous pouvons l'utiliser pour créer des files d'attente et des échanges à haute disponibilité en configurant une nouvelle stratégie. Cette stratégie peut être ajoutée via la console de gestion RabbitMQ ou à l'aide de l'interface de ligne de commande.

sudo rabbitmqctl set_policy -p "/" --priority 1 --apply-to "all" ha ".*" '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}'

La liste suivante explique ce que signifie chaque partie de la commande.

• -p "/": Utilisez cette stratégie sur le "/"vhost (la valeur par défaut après l'installation)
• --priority 1: L'ordre dans lequel appliquer les politiques
• --apply-to "all": Peut être "queues", "exchanges"ou"all"
• ha: Le nom que nous donnons à notre politique
• ".*": Expression régulière utilisée pour décider à quelles files d'attente ou échanges cette politique est appliquée. ".*"correspondra à tout
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': Représentation JSON de la stratégie. Ce document décrit ce que nous voulons - exactement 2 nœuds sur lesquels les données sont automatiquement synchronisées

En bref, cette politique garantira que nous aurons toujours 2 copies des données dans une file d'attente ou un échange tant que nous aurons au moins 2 nœuds opérationnels. Si vous avez plus de nœuds, vous pouvez augmenter la valeur de ha-params. Un quorum, ( N/2 + 1), de nœuds est conseillé. Avoir plus de copies de vos données entraînerait une augmentation de l'utilisation du disque, des E / S et du net, ce qui pourrait entraîner une dégradation des performances.

Si vous souhaitez mettre en miroir les données sur tous les nœuds du cluster, vous pouvez utiliser le document JSON suivant.

'{ "ha-mode": "all", "ha-sync-mode": "automatic"}'

Si vous souhaitez mettre en miroir les données uniquement sur des nœuds spécifiques (par exemple: node-1et node-2), vous pouvez utiliser ce qui suit.

'{ "ha-mode": "nodes", "ha-params" :["rabbit@node-1", "rabbit@node-2"], "ha-sync-mode": "automatic"}'

Vous pouvez modifier l'expression régulière pour affecter différentes stratégies à différentes files d'attente. Disons que nous avons les trois nœuds suivants:

• lapin @ maître
• lapin @ client-ha
• lapin @ produit-ha

Nous pouvons ensuite créer deux stratégies qui entraîneront la mise en miroir du rabbit@client-hanœud du nom des files d'attente commençant par "client" et la mise en miroir du nœud de toutes les files d'attente dont le nom commence par "produit" rabbit@product-ha.

sudo rabbitmqctl set_policy -p "/" --priority 1 --apply-to "queues" ha-client "client.*" '{ "ha-mode": "nodes", "ha-params": ["rabbit@master", "rabbit@client-ha"], "ha-sync-mode": "automatic"}
sudo rabbitmqctl set_policy -p "/" --priority 1 --apply-to "queues" ha-product "product.*" '{ "ha-mode": "nodes", "ha-params": ["rabbit@master", "rabbit@product-ha"], "ha-sync-mode": "automatic"}

Une petite remarque ici: les files d'attente exclusives ne sont jamais mises en miroir ou durables dans RabbitMQ, même si cette stratégie correspondrait à ces files d'attente. Les files d'attente exclusives sont automatiquement détruites une fois qu'un client se déconnecte et, en tant que tel, il serait inutile de le répliquer sur un autre serveur. Si le serveur venait à tomber en panne, le client s'en déconnecterait et la file d'attente serait automatiquement détruite. Les instances en miroir seraient également détruites.

Test de la configuration

Afin de tester la configuration en cluster, nous pouvons créer une nouvelle file d'attente à l'aide de l'interface de ligne de commande via la console de gestion.

sudo rabbitmqadmin declare queue --vhost "/" name=my-ha-queue durable=true

Cela créera une file d'attente durable sur le /vhost par défaut avec le nom my-ha-queue.

Exécutez la commande suivante et vérifiez dans la sortie que la file d'attente a notre stratégie «ha» affectée et a des pid sur le maître et sur un nœud miroir.

sudo rabbitmqctl list_queues name policy state pid slave_pids

Nous pouvons maintenant publier un message dans la file d'attente à partir du nœud maître et arrêter RabbitMQ sur le nœud maître.

sudo rabbitmqadmin -u user_name -p password  publish routing_key=my-ha-queue payload="hello world"
sudo systemctl rabbitmqctl shutdown

Maintenant, récupérez-le en vous connectant au nœud miroir.

 sudo rabbitmqadmin -H MIRROR_NODE_IP_OR_DNS -u user_name -p password get queue=my-ha-queue

Enfin, nous pouvons redémarrer notre nœud maître.

sudo systemctl start rabbitmq-server.service

Supprimer l'utilisateur invité

Comme mentionné précédemment, RabbitMQ crée automatiquement un utilisateur invité avec un mot de passe invité par défaut. Ce serait une mauvaise pratique de laisser cet utilisateur par défaut sur un système exposé publiquement.

sudo rabbitmqctl delete_user guest