Cluster RabbitMQ på CentOS 7

RabbitMQ är en meddelandemäklare med öppen källkod som stöder AMQP, STOMP och andra kommunikationsteknologier. Det används ofta i företagsapplikationer och moderna mikrotjänstarkitekturer där det fungerar som en asynkron meddelandekanal mellan olika mikrotjänster. Den här guiden kommer att beskriva hur du kan klustera RabbitMQ på flera CentOS 7-servrar för att bilda en meddelandeförmedlare med hög tillgänglighet. I den här handledningen kommer en server att fungera som en huvudserver och de andra servrarna kommer att fungera som spegelservrar om huvudservern blir otillgänglig.

Förutsättningar

• Minst två nyligen distribuerade och uppdaterade CentOS 7-instanser i samma undernät med privat nätverk aktiverat
• RabbitMQ installerat med hanteringskonsolen aktiverad på varje server (se Hur man installerar RabbitMQ på CentOS 7 )
• En icke-adminanvändare med sudo-rättigheter (se Hur man använder Sudo på Debian, CentOS och FreeBSD )

Konfigurera brandväggen

CentOS-brandväggen, ( firewalld), tillåter inte någon inkommande trafik som standard. För att göra RabbitMQ tillgängligt för andra system i och utanför nätverket, och för att vi ska kunna komma åt hanteringskonsolen, måste vi först öppna några portar.

RabbitMQs webbgränssnittshanteringskonsol lyssnar som standard på port 15672. Vi vill göra hanteringskonsolen allmänt tillgänglig så att vi kan komma åt den från vår dator. Vi kommer därför att instruera firewalldatt permanent öppna porten 15672i den offentliga zonen (vilket är standardzonen och den aktiva zonen på en Vultr-instans).

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

RabbitMQ-noderna måste kunna kommunicera med varandra. Vi skulle vilja öppna de nödvändiga portarna, men bara över det interna nätverket. Vi vill inte att någon på internet ska kunna administrera eller direkt kontakta våra servrar. Följande kommandon förutsätter att våra servrar finns på 192.168.0.100/24undernätet.

Den första tjänsten är epmdpeer discovery-tjänsten som lyssnar som standard på 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'

För internod- och CLI-kommunikation måste RabbitMQ kunna kommunicera över 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'

CLI - verktygen kommunicerar över portarnas intervall 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'

Om dina applikationer behöver AMQP-protokollet måste du också öppna portar 5671och 5672. Om du behöver kunna kommunicera över ett annat protokoll kan du hitta nödvändig information om nätverkskraven för RabbitMQ i den officiella RabbitMQ-dokumentationen .

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 det firewalldär konfigurerat måste vi instruera det att ladda om konfigurationen.

sudo firewall-cmd --reload

Upprepa stegen från det här avsnittet på alla servrar.

Installera rabbitmqadmin

Hanteringspluginen kommer med ett Python-verktyg som heter rabbitmqadminsom enkelt kan installeras på systemet när hanteringspluginen är aktiverad.

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

Konfigurera DNS

Du måste använda serverns värdnamn för att identifiera servrarna vid klustring. Som standard har servrarna ingen DNS-post tilldelad och anslutningen kommer att misslyckas. För att snabbt övervinna detta, lägg till huvud- och spegelvärdnamnet till /etc/hostsfilen med din favoritredigerare.

Till exempel kan din master's hosts-fil se ut så här. Lägg märke till de två sista posterna, som tillåter servrarna att identifiera varandra med sitt värdnamn. Se till att ändra IP-adresserna till dina egna.

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

Klustra noderna

En importförutsättning för att tillåta noder att ansluta sig till varandra är att Erlang-cookien för alla noder är identisk. Som standard kommer varje nod att tilldelas en unik Erlang-cookie, så du måste konfigurera om den på alla noder.

Följande kommando kommer att ställa in Erlang-kakan till " WE<3COOKIES", men ändra gärna detta efter eget tycke. Gör detta på alla servrar.

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

Starta om RabbitMQ på alla servrar för att se till att Erlang-cookien laddas om ordentligt.

sudo systemctl restart rabbitmq-server.service

Utför följande kommandon på alla servrar utom på huvudservern. Detta kommer att låta noderna gå med i huvudservern och bilda ett kluster.

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

Verifiera att noderna har anslutit sig till klustret genom att köra följande kommando.

sudo rabbitmqctl cluster_status

Alla dina noder visas i nodesoch running_nodesdelen av produktionen. Från och med nu behöver du inte längre upprepa steg på varje server, konfigurationen kommer automatiskt att speglas till de andra noderna.

Skapa en policy för hög tillgänglighet

Nu när vi har ett kluster av RabbitMQ-noder kan vi använda detta för att skapa köer och utbyten med hög tillgänglighet genom att sätta upp en ny policy. Denna policy kan läggas till via RabbitMQ Management Console eller med hjälp av kommandoradsgränssnittet.

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

Följande lista kommer att förklara vad varje del av kommandot betyder.

• -p "/": Använd denna policy på "/"vhost (standard efter installation)
• --priority 1: Ordningen i vilken policyer ska tillämpas
• --apply-to "all": Kan vara "queues", "exchanges"eller"all"
• ha: Namnet vi ger vår policy
• ".*": Det reguljära uttrycket som används för att bestämma vilka köer eller utbyten denna policy ska tillämpas på. ".*"kommer att matcha vad som helst
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': JSON-representationen av policyn. Detta dokument beskriver att vi vill ha - exakt 2 noder på vilka data automatiskt synkroniseras

Kort sagt kommer denna policy att säkerställa att vi alltid kommer att ha 2 kopior av data på en kö eller växel så länge vi har minst 2 noder igång. Om du har fler noder kan du öka värdet på ha-params. Ett kvorum, ( N/2 + 1), av noder rekommenderas. Att ha fler kopior av dina data skulle resultera i högre disk-, i/o- och nätanvändning vilket kan resultera i försämrad prestanda.

Om du vill spegla data till alla noder i klustret kan du använda följande JSON-dokument.

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

Om du bara vill spegla data till specifika noder (till exempel: node-1och node-2), kan du använda följande.

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

Du kan ändra det reguljära uttrycket för att tilldela olika principer till olika köer. Säg att vi har följande tre noder:

• kanin@mästare
• kanin@klient-ha
• kanin@produkt-ha

Vi kan sedan skapa två policyer som kommer att resultera i att köer som har ett namn som börjar med "klient" speglas till rabbit@client-hanoden och att alla köer som har ett namn som börjar med "produkt" speglas till rabbit@product-hanoden.

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

En liten anmärkning här: exklusiva köer är aldrig speglade eller hållbara i RabbitMQ, även om denna policy skulle matcha sådana köer. Exklusiva köer förstörs automatiskt när en klient kopplar från och som sådan skulle det inte vara till någon nytta att replikera den till en annan server. Om servern skulle misslyckas, skulle klienten koppla från den och kön skulle förstöras automatiskt. Speglade instanser skulle också förstöras.

Testar inställningen

För att testa den klustrade inställningen kan vi skapa en ny kö med hjälp av kommandoradsgränssnittet via hanteringskonsolen.

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

Detta kommer att skapa en varaktig kö på standard /vhost med namnet my-ha-queue.

Kör följande kommando och verifiera i utgången att kön har vår 'ha'-policy tilldelad och har pid's på mastern och på en spegelnod.

sudo rabbitmqctl list_queues name policy state pid slave_pids

Vi kan nu publicera ett meddelande till kön från masternoden och stoppa RabbitMQ på masternoden.

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

Få det nu tillbaka genom att ansluta till spegelnoden.

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

Slutligen kan vi starta om vår huvudnod.

sudo systemctl start rabbitmq-server.service

Ta bort gästanvändaren

Som nämnts tidigare skapar RabbitMQ automatiskt en gästanvändare med ett standard gästlösenord. Det skulle vara dålig praxis att lämna denna standardanvändare på ett offentligt exponerat system.

sudo rabbitmqctl delete_user guest