Clustering af RabbitMQ på CentOS 7

RabbitMQ er en open source-meddelelsesmægler, der understøtter AMQP, STOMP og andre kommunikationsteknologier. Det er meget udbredt i virksomhedsapplikationer og moderne mikroservicearkitekturer, hvor det fungerer som en asynkron meddelelseskanal mellem forskellige mikrotjenester. Denne vejledning vil beskrive, hvordan du kan gruppere RabbitMQ på flere CentOS 7-servere for at danne en meddelelsesmægler med høj tilgængelighed. I denne vejledning vil en server fungere som en masterserver, og de andre servere vil fungere som spejlservere, hvis masterserveren bliver utilgængelig.

Forudsætninger

• Mindst to nyligt implementerede og opdaterede CentOS 7-instanser i det samme undernet med privat netværk aktiveret
• RabbitMQ installeret med administrationskonsollen aktiveret på hver server (se Sådan installeres RabbitMQ på CentOS 7 )
• En ikke-administratorbruger med sudo-rettigheder (se Sådan bruges Sudo på Debian, CentOS og FreeBSD )

Konfigurer firewallen

CentOS-firewallen, ( firewalld), tillader som standard ingen indgående trafik. For at gøre RabbitMQ tilgængelig for andre systemer i og uden for netværket, og for at give os adgang til administrationskonsollen, skal vi først åbne nogle porte.

RabbitMQ's webgrænsefladestyringskonsol lytter som standard på port 15672. Vi vil gerne gøre administrationskonsollen offentligt tilgængelig, så vi kan få adgang til den fra vores computer. Vi vil derfor instruere firewalldom permanent at åbne porten 15672i den offentlige zone (som er standard og aktive zone på en Vultr-instans).

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

RabbitMQ-knuderne skal kunne kommunikere med hinanden. Vi vil gerne åbne de nødvendige porte, men kun over det interne netværk. Vi ønsker ikke, at nogen på internettet skal kunne administrere eller kontakte vores servere direkte. Følgende kommandoer antager, at vores servere er på 192.168.0.100/24undernettet.

Den første tjeneste er epmdpeer discovery-tjenesten, som lytter 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'

For internode- og CLI-kommunikation skal RabbitMQ være i stand til at kommunikere over 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-værktøjerne kommunikerer over portrækken 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'

Hvis dine applikationer har brug for AMQP-protokollen, skal du også åbne porte 5671og 5672. Hvis du har brug for at kunne kommunikere over en anden protokol, kan du finde de nødvendige oplysninger om netværkskravene for RabbitMQ i den officielle RabbitMQ-dokumentation .

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 firewallder konfigureret, skal vi instruere det i at genindlæse konfigurationen.

sudo firewall-cmd --reload

Gentag trinene fra dette afsnit på alle servere.

Installere rabbitmqadmin

Administrationsplugin'et kommer med et Python-værktøj kaldet, rabbitmqadminsom nemt kan installeres på systemet, når administrationspluginnet er aktiveret.

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

Konfigurer DNS

Du skal bruge serverens værtsnavne til at identificere serverne, når du klynger. Som standard har serverne ingen DNS-record tildelt, og forbindelsen vil mislykkes. For hurtigt at overvinde dette skal du tilføje master- og spejlværtsnavnet til /etc/hostsfilen ved hjælp af din yndlingseditor.

For eksempel kan din masters værtsfil se ud som følgende. Læg mærke til de sidste to poster, som gør det muligt for serverne at identificere hinanden ved deres værtsnavn. Sørg for at ændre IP-adresserne til dine egne.

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

Klynge knudepunkterne

En importforudsætning for at tillade noder at slutte sig til hinanden er, at Erlang-cookien for alle noder er identiske. Som standard vil hver node blive tildelt en unik Erlang-cookie, så du skal omkonfigurere den på alle noder.

Den følgende kommando vil sætte Erlang-cookien til " WE<3COOKIES", men du er velkommen til at ændre dette efter din smag. Gør dette på alle servere.

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

Genstart RabbitMQ på alle servere for at sikre, at Erlang-cookien genindlæses korrekt.

sudo systemctl restart rabbitmq-server.service

Udfør følgende kommandoer på alle servere undtagen på masterserveren. Dette vil lade noderne slutte sig til masterserveren og danne en klynge.

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

Bekræft, at noderne har sluttet sig til klyngen ved at køre følgende kommando.

sudo rabbitmqctl cluster_status

Alle dine noder vises i nodesog running_nodesdel af produktionen. Fra nu af behøver du ikke længere at gentage trin på hver server, konfigurationen vil automatisk blive spejlet til de andre noder.

Lav en høj tilgængelighedspolitik

Nu hvor vi har en klynge af RabbitMQ-noder, kan vi bruge dette til at lave højtilgængelige køer og udvekslinger ved at opsætte en ny politik. Denne politik kan tilføjes via RabbitMQ Management Console eller ved hjælp af kommandolinjegrænsefladen.

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

Den følgende liste vil forklare, hvad hver del af kommandoen betyder.

• -p "/": Brug denne politik på "/"vhost (standard efter installation)
• --priority 1: Den rækkefølge, som politikkerne skal anvendes i
• --apply-to "all": Kan være "queues", "exchanges"eller"all"
• ha: Det navn, vi giver vores politik
• ".*": Det regulære udtryk, som bruges til at bestemme, hvilke køer eller udvekslinger denne politik anvendes på. ".*"vil matche hvad som helst
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': JSON-repræsentationen af ​​politikken. Dette dokument beskriver, at vi ønsker - præcis 2 noder, hvorpå dataene automatisk synkroniseres

Kort sagt vil denne politik sikre, at vi altid vil have 2 kopier af dataene på en kø eller en central, så længe vi har mindst 2 noder oppe at køre. Hvis du har flere noder, kan du øge værdien af ha-params. Et kvorum, ( N/2 + 1), af noder tilrådes. At have flere kopier af dine data vil resultere i højere disk-, i/o- og netforbrug, hvilket kan resultere i en forringet ydeevne.

Hvis du gerne vil spejle dataene til alle noderne i klyngen, kan du bruge følgende JSON-dokument.

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

Hvis du kun vil spejle dataene til specifikke noder (for eksempel: node-1og node-2), kan du bruge følgende.

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

Du kan ændre det regulære udtryk for at tildele forskellige politikker til forskellige køer. Lad os sige, at vi har følgende tre noder:

• kanin@mester
• kanin@klient-ha
• kanin@produkt-ha

Vi kan derefter oprette to politikker, som vil resultere i, at køer med et navn, der starter med "klient", spejles til rabbit@client-hanoden, og alle køer, der har et navn, der starter med "produkt", spejles til 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 lille bemærkning her: eksklusive køer er aldrig spejlet eller holdbare i RabbitMQ, selvom denne politik ville matche sådanne køer. Eksklusive køer bliver automatisk ødelagt, når en klient afbryder forbindelsen, og som sådan ville det ikke nytte noget at replikere den til en anden server. Hvis serveren fejler, vil klienten afbryde forbindelsen fra den, og køen vil automatisk blive ødelagt. Spejlvendte forekomster ville også blive ødelagt.

Test af opsætningen

For at teste den klyngede opsætning kan vi oprette en ny kø ved hjælp af kommandolinjegrænsefladen gennem administrationskonsollen.

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

Dette vil skabe en holdbar kø på standard /vhost med navnet my-ha-queue.

Kør følgende kommando og bekræft i outputtet, at køen har vores 'ha'-politik tildelt og har pid'er på masteren og på en spejlknude.

sudo rabbitmqctl list_queues name policy state pid slave_pids

Vi kan nu publicere en besked til køen fra masterknuden og stoppe RabbitMQ på masterknuden.

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

Få det nu tilbage ved at oprette forbindelse til spejlknudepunktet.

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

Endelig kan vi genstarte vores masterknude.

sudo systemctl start rabbitmq-server.service

Slet gæstebrugeren

Som nævnt før opretter RabbitMQ automatisk en gæstebruger med en standard gæsteadgangskode. Det ville være dårlig praksis at efterlade denne standardbruger på et offentligt eksponeret system.

sudo rabbitmqctl delete_user guest