Gruppering av RabbitMQ på CentOS 7

RabbitMQ er en åpen kildekode-meldingsmegler som støtter AMQP, STOMP og andre kommunikasjonsteknologier. Den er mye brukt i bedriftsapplikasjoner og moderne mikrotjenestearkitekturer der den fungerer som en asynkron meldingskanal mellom forskjellige mikrotjenester. Denne veiledningen vil beskrive hvordan du kan gruppere RabbitMQ på flere CentOS 7-servere for å danne en meldingsmegler med høy tilgjengelighet. I denne opplæringen vil en server fungere som en hovedserver og de andre serverne vil fungere som speilservere i tilfelle hovedserveren blir utilgjengelig.

Forutsetninger

• Minst to nylig distribuerte og oppdaterte CentOS 7-forekomster i samme undernett med privat nettverk aktivert
• RabbitMQ installert med administrasjonskonsollen aktivert på hver server (se Hvordan installere RabbitMQ på CentOS 7 )
• En ikke-administratorbruker med sudo-rettigheter (se Hvordan bruke Sudo på Debian, CentOS og FreeBSD )

Konfigurer brannmuren

CentOS-brannmuren, ( firewalld), tillater ikke innkommende trafikk som standard. For å gjøre RabbitMQ tilgjengelig for andre systemer i og utenfor nettverket, og for å gi oss tilgang til administrasjonskonsollen, må vi først åpne noen porter.

Nettgrensesnittadministrasjonskonsollen til RabbitMQ lytter som standard på port 15672. Vi ønsker å gjøre administrasjonskonsollen offentlig tilgjengelig slik at vi kan få tilgang til den fra datamaskinen vår. Vi vil derfor instruere om firewalldå permanent åpne port 15672i den offentlige sonen (som er standard og aktiv sone på en Vultr-forekomst).

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

RabbitMQ-nodene må kunne kommunisere med hverandre. Vi vil gjerne åpne de nødvendige portene, men kun over det interne nettverket. Vi ønsker ikke at noen på internett skal kunne administrere eller kontakte serverne våre direkte. Følgende kommandoer forutsetter at våre servere er på 192.168.0.100/24subnettet.

Den første tjenesten 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-kommunikasjon må RabbitMQ kunne kommunisere 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-verktøyene kommuniserer over portområdet 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 applikasjonene dine trenger AMQP-protokollen, må du også åpne porter 5671og 5672. Hvis du trenger å kunne kommunisere over en annen protokoll, kan du finne nødvendig informasjon om nettverkskravene til RabbitMQ i den offisielle RabbitMQ-dokumentasjonen .

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'

Nå som firewallder konfigurert, må vi instruere den om å laste inn konfigurasjonen på nytt.

sudo firewall-cmd --reload

Gjenta trinnene fra denne delen på alle servere.

Installere rabbitmqadmin

Administrasjonspluginen kommer med et Python-verktøy kalt rabbitmqadminsom enkelt kan installeres på systemet når administrasjonspluginen er aktivert.

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

Konfigurer DNS

Du må bruke serverens vertsnavn for å identifisere serverne ved klynging. Som standard har serverne ingen DNS-post tilordnet, og tilkoblingen vil mislykkes. For raskt å overvinne dette, legg til master- og speilvertsnavnet til /etc/hostsfilen ved å bruke favorittredigeringsprogrammet ditt.

For eksempel kan masterens vertsfil se slik ut. Legg merke til de to siste postene, som lar serverne identifisere hverandre ved hjelp av vertsnavnet. Sørg for å endre IP-adressene 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

Klynger nodene

En importforutsetning for å la noder slå seg sammen er at Erlang-informasjonskapselen til alle noder er identiske. Som standard vil hver node bli tildelt en unik Erlang-informasjonskapsel, så du må rekonfigurere den på alle noder.

Følgende kommando vil sette Erlang-informasjonskapselen til " WE<3COOKIES", men endre denne gjerne til din smak. Gjør dette på alle servere.

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

Start RabbitMQ på nytt på alle servere for å sikre at Erlang-informasjonskapselen er riktig lastet inn på nytt.

sudo systemctl restart rabbitmq-server.service

Utfør følgende kommandoer på alle servere bortsett fra på hovedserveren. Dette vil la nodene bli med hovedserveren og danne en klynge.

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

Bekreft at nodene har sluttet seg til klyngen ved å kjøre følgende kommando.

sudo rabbitmqctl cluster_status

Alle nodene dine vises i nodesog- running_nodesdelen av utdataene. Fra nå av trenger du ikke lenger å gjenta trinnene på hver server, konfigurasjonen vil automatisk speiles til de andre nodene.

Lag en policy for høy tilgjengelighet

Nå som vi har en klynge av RabbitMQ-noder, kan vi bruke dette til å lage høytilgjengelige køer og utvekslinger ved å sette opp en ny policy. Denne policyen kan legges til gjennom RabbitMQ Management Console eller ved å bruke kommandolinjegrensesnittet.

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

Følgende liste vil forklare hva hver del av kommandoen betyr.

• -p "/": Bruk denne policyen på "/"vhost (standard etter installasjon)
• --priority 1: Rekkefølgen for å bruke retningslinjene
• --apply-to "all": Kan være "queues", "exchanges"eller"all"
• ha: Navnet vi gir til vår policy
• ".*": Det regulære uttrykket som brukes til å bestemme hvilke køer eller børser denne policyen skal brukes på. ".*"vil matche hva som helst
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': JSON-representasjonen av policyen. Dette dokumentet beskriver at vi ønsker - nøyaktig 2 noder som dataene automatisk synkroniseres på

Kort fortalt vil denne policyen sikre at vi alltid vil ha 2 kopier av dataene på en kø eller sentral så lenge vi har minst 2 noder oppe og kjører. Hvis du har flere noder kan du øke verdien av ha-params. Et quorum, ( N/2 + 1), av noder anbefales. Å ha flere kopier av dataene dine vil føre til høyere disk-, i/o- og nettbruk, noe som kan føre til dårligere ytelse.

Hvis du ønsker å speile dataene til alle nodene i klyngen, kan du bruke følgende JSON-dokument.

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

Hvis du vil speile dataene kun til spesifikke noder (for eksempel: node-1og node-2), kan du bruke følgende.

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

Du kan endre det regulære uttrykket for å tilordne forskjellige policyer til forskjellige køer. La oss si at vi har følgende tre noder:

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

Vi kan da lage to policyer som vil resultere i at køer har et navn som starter med "klient" som skal speiles til rabbit@client-hanoden og at alle køer som har et navn som starter med "produkt" speiles 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 liten bemerkning her: eksklusive køer er aldri speilvendt eller holdbare i RabbitMQ, selv om denne policyen ville samsvare med slike køer. Eksklusive køer blir automatisk ødelagt når en klient kobler fra, og som sådan ville det ikke være til nytte å replikere den til en annen server. Hvis serveren skulle svikte, ville klienten koble seg fra den og køen vil bli ødelagt automatisk. Speilvendte forekomster vil også bli ødelagt.

Tester oppsettet

For å teste det grupperte oppsettet kan vi opprette en ny kø ved å bruke kommandolinjegrensesnittet gjennom administrasjonskonsollen.

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

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

Kjør følgende kommando og kontroller i utdataene at køen har vår 'ha'-policy tildelt og har pid-er på masteren og på en speilnode.

sudo rabbitmqctl list_queues name policy state pid slave_pids

Vi kan nå publisere en melding til køen fra masternoden og stoppe RabbitMQ på masternoden.

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

Få den nå tilbake ved å koble til speilnoden.

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

Til slutt kan vi starte masternoden vår på nytt.

sudo systemctl start rabbitmq-server.service

Slett gjestebrukeren

Som nevnt før oppretter RabbitMQ automatisk en gjestebruker med et standard gjestepassord. Det ville være dårlig praksis å la denne standardbrukeren være på et offentlig eksponert system.

sudo rabbitmqctl delete_user guest