Clustering RabbitMQ op CentOS 7

• Vereisten
• Configureer de firewall
• Installeer rabbitmqadmin
• Configureer DNS
• Bundel de knooppunten
• Maak een beleid met hoge beschikbaarheid
• De setup testen
• Verwijder de gastgebruiker

RabbitMQ is een open-source berichtenmakelaar die AMQP, STOMP en andere communicatietechnologieën ondersteunt. Het wordt veel gebruikt in bedrijfstoepassingen en moderne microservice-architecturen, waar het fungeert als een asynchroon berichtkanaal tussen verschillende microservices. In deze handleiding wordt beschreven hoe u RabbitMQ op meerdere CentOS 7-servers kunt clusteren om een ​​berichtmakelaar met hoge beschikbaarheid te vormen. In deze zelfstudie fungeert één server als masterserver en de andere servers als spiegelservers voor het geval de masterserver niet meer beschikbaar is.

Vereisten

• Ten minste twee pas geïmplementeerde en bijgewerkte CentOS 7-instanties in hetzelfde subnet met privénetwerken ingeschakeld
• RabbitMQ geïnstalleerd met de beheerconsole ingeschakeld op elke server (zie How to Install RabbitMQ on CentOS 7 )
• Een niet-admin-gebruiker met sudo-rechten (zie Sudo gebruiken op Debian, CentOS en FreeBSD )

Configureer de firewall

De CentOS-firewall, ( firewalld), staat standaard geen inkomend verkeer toe. Om RabbitMQ beschikbaar te maken voor andere systemen binnen en buiten het netwerk en om ons toegang te geven tot de beheerconsole, moeten we eerst enkele poorten openen.

De beheerinterface van de webinterface van RabbitMQ luistert standaard op poort 15672. We willen de beheerconsole openbaar maken zodat we er vanaf onze computer toegang toe hebben. We zullen daarom de instructie geven firewalldom de poort permanent te openen 15672in de openbare zone (wat de standaard en actieve zone is op een Vultr-instantie).

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

De RabbitMQ-knooppunten moeten met elkaar kunnen communiceren. We willen graag de nodige poorten openen, maar alleen via het interne netwerk. We willen niet dat iemand op internet onze servers kan beheren of rechtstreeks contact kan opnemen. Bij de volgende opdrachten wordt ervan uitgegaan dat onze servers zich op het 192.168.0.100/24subnet bevinden.

De eerste service is de epmdpeer-discovery-service die standaard luistert op poort 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'

Voor internode- en CLI-communicatie moet RabbitMQ via de poort kunnen communiceren 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'

De CLI-tools communiceren over het poortenbereik 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'

Als uw toepassingen het AMQP-protocol nodig hebben, moet u ook poorten 5671en openen 5672. Als u moet kunnen communiceren via een ander protocol, kunt u de nodige informatie over de netwerkvereisten van RabbitMQ vinden in de officiële RabbitMQ-documentatie .

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'

Nu dat firewalldis geconfigureerd, moeten we het instrueren om de configuratie opnieuw te laden.

sudo firewall-cmd --reload

Herhaal de stappen uit dit gedeelte op alle servers.

Installeren rabbitmqadmin

De beheerplug-in wordt geleverd met een Python-tool rabbitmqadmindie eenvoudig op het systeem kan worden geïnstalleerd zodra de beheerplug-in is ingeschakeld.

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

Configureer DNS

U moet de hostnamen van de server gebruiken om de servers te identificeren tijdens clustering. De servers hebben standaard geen DNS-record toegewezen en de verbinding zal mislukken. Om dit snel te verhelpen, voegt u de master- en mirror-hostnaam toe aan het /etc/hostsbestand met uw favoriete editor.

Het hosts-bestand van uw master kan er bijvoorbeeld als volgt uitzien. Let op de laatste twee records, waarmee de servers elkaar kunnen identificeren aan de hand van hun hostnaam. Zorg ervoor dat u de IP-adressen in uw eigen verandert.

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

Bundel de knooppunten

Een importvoorwaarde om knooppunten met elkaar te laten verbinden, is dat de Erlang-cookie van alle knooppunten identiek is. Standaard krijgt elk knooppunt een unieke Erlang-cookie toegewezen, dus u moet het op alle knooppunten opnieuw configureren.

Met de volgende opdracht wordt de Erlang-cookie ingesteld op " WE<3COOKIES", maar u kunt deze naar wens wijzigen. Doe dit op alle servers.

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

Start RabbitMQ opnieuw op alle servers om ervoor te zorgen dat de Erlang-cookie correct wordt geladen.

sudo systemctl restart rabbitmq-server.service

Voer de volgende opdrachten uit op alle servers behalve op de masterserver. Hierdoor worden de knooppunten lid van de masterserver en vormen ze een cluster.

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

Controleer of de knooppunten deel uitmaken van het cluster door de volgende opdracht uit te voeren.

sudo rabbitmqctl cluster_status

Al uw knooppunten verschijnt in het nodesen het running_nodesgedeelte van de output. Vanaf nu hoeft u de stappen op elke server niet meer te herhalen, de configuratie wordt automatisch gespiegeld naar de andere knooppunten.

Maak een beleid met hoge beschikbaarheid

Nu we een cluster van RabbitMQ-knooppunten hebben, kunnen we dit gebruiken om wachtrijen en uitwisselingen met hoge beschikbaarheid te maken door een nieuw beleid op te stellen. Dit beleid kan worden toegevoegd via de RabbitMQ Management Console of via de opdrachtregelinterface.

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

In de volgende lijst wordt uitgelegd wat elk onderdeel van de opdracht betekent.

• -p "/": Gebruik dit beleid op de "/"vhost (de standaard na installatie)
• --priority 1: De volgorde waarin het beleid moet worden toegepast
• --apply-to "all": Kan zijn "queues", "exchanges"of"all"
• ha: De naam die we aan ons beleid geven
• ".*": De reguliere expressie die wordt gebruikt om te beslissen in welke wachtrijen of uitwisselingen dit beleid wordt toegepast. ".*"komt overeen met alles
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': De JSON-weergave van het beleid. Dit document beschrijft wat we willen - precies 2 knooppunten waarop de gegevens automatisch worden gesynchroniseerd

Kortom, dit beleid zorgt ervoor dat we altijd 2 kopieën van de gegevens in een wachtrij of uitwisseling hebben, zolang we minimaal 2 knooppunten in gebruik hebben. Als u meer knooppunten heeft, kunt u de waarde van verhogen ha-params. Een quorum ( N/2 + 1) van knooppunten wordt geadviseerd. Als u meer kopieën van uw gegevens heeft, resulteert dit in een hoger schijf-, i / o- en netto-gebruik, wat kan leiden tot verminderde prestaties.

Als u de gegevens naar alle knooppunten in het cluster wilt spiegelen, kunt u het volgende JSON-document gebruiken.

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

Als u de gegevens alleen naar specifieke knooppunten wilt spiegelen (bijvoorbeeld: node-1en node-2), kunt u het volgende gebruiken.

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

U kunt de reguliere expressie wijzigen om verschillende beleidsregels toe te wijzen aan verschillende wachtrijen. Stel dat we de volgende drie knooppunten hebben:

• konijn @ meester
• konijn @ klant-ha
• konijn @ product-ha

We kunnen dan twee beleidsregels maken die resulteren in wachtrijen met een naam die begint met "client" om te worden gespiegeld naar het rabbit@client-haknooppunt en alle wachtrijen die een naam hebben die begint met "product" om te worden gespiegeld naar het rabbit@product-haknooppunt.

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"}

Een kleine opmerking hier: exclusieve wachtrijen worden nooit gespiegeld of duurzaam in RabbitMQ, ook al zou dit beleid overeenkomen met dergelijke wachtrijen. Exclusieve wachtrijen worden automatisch vernietigd zodra een client de verbinding verbreekt, en als zodanig heeft het geen zin om deze naar een andere server te repliceren. Als de server zou falen, zou de client de verbinding verbreken en zou de wachtrij automatisch worden vernietigd. Gespiegelde instanties zouden ook worden vernietigd.

De setup testen

Om de geclusterde setup te testen, kunnen we een nieuwe wachtrij maken met behulp van de opdrachtregelinterface via de beheerconsole.

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

Dit zal een duurzame wachtrij creëren op de standaard /vhost met de naam my-ha-queue.

Voer de volgende opdracht uit en controleer in de uitvoer of de wachtrij ons 'ha'-beleid heeft toegewezen en pid's heeft op de master en op een mirror node.

sudo rabbitmqctl list_queues name policy state pid slave_pids

We kunnen nu een bericht naar de wachtrij publiceren vanaf het masterknooppunt en RabbitMQ stoppen op het masterknooppunt.

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

Haal het nu terug door verbinding te maken met het spiegelknooppunt.

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

Eindelijk kunnen we ons hoofdknooppunt opnieuw opstarten.

sudo systemctl start rabbitmq-server.service

Verwijder de gastgebruiker

Zoals eerder vermeld, creëert RabbitMQ automatisch een gastgebruiker met een standaard gastwachtwoord. Het zou een slechte gewoonte zijn om deze standaardgebruiker op een openbaar systeem te laten staan.

sudo rabbitmqctl delete_user guest