Agrupació de RabbitMQ a CentOS 7

RabbitMQ és un corredor de missatges de codi obert que admet AMQP, STOMP i altres tecnologies de comunicació. S'utilitza àmpliament en aplicacions empresarials i arquitectures modernes de microserveis on actua com a canal de missatges asíncron entre diferents microserveis. Aquesta guia descriurà com podeu agrupar RabbitMQ en diversos servidors CentOS 7 per formar un corredor de missatges d'alta disponibilitat. En aquest tutorial, un servidor actuarà com a servidor mestre i els altres servidors actuaran com a servidors mirall en cas que el servidor principal no estigui disponible.

Requisits previs

• Almenys dues instàncies de CentOS 7 recentment implementades i actualitzades a la mateixa subxarxa amb la xarxa privada activada
• RabbitMQ instal·lat amb la consola de gestió activada a cada servidor (vegeu Com instal·lar RabbitMQ a CentOS 7 )
• Un usuari no administrador amb drets sudo (vegeu Com utilitzar Sudo a Debian, CentOS i FreeBSD )

Configura el tallafoc

El tallafoc de CentOS, ( firewalld), no permet cap trànsit d'entrada de manera predeterminada. Perquè RabbitMQ estigui disponible per a altres sistemes dins i fora de la xarxa, i que ens permeti accedir a la consola de gestió, primer hem d'obrir alguns ports.

La consola de gestió de la interfície web de RabbitMQ escolta per defecte al port 15672. Ens agradaria posar a disposició del públic la consola de gestió per poder-hi accedir des del nostre ordinador. Per tant, donarem instruccions firewalldper obrir permanentment el port 15672a la zona pública (que és la zona predeterminada i activa en una instància Vultr).

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

Els nodes RabbitMQ han de poder comunicar-se entre ells. Ens agradaria obrir els ports necessaris, però només a través de la xarxa interna. No volem que ningú a Internet pugui administrar o contactar directament amb els nostres servidors. Les ordres següents suposen que els nostres servidors estan a la 192.168.0.100/24subxarxa.

El primer servei és el epmdservei de descoberta d'iguals que escolta per defecte al 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'

Per a la comunicació entre nudes i CLI, RabbitMQ ha de poder comunicar-se a través del 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 eines CLI es comuniquen a través de l'interval 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 les vostres aplicacions necessiten el protocol AMQP, també haureu d'obrir ports 5671i 5672. Si necessiteu poder comunicar-vos mitjançant un altre protocol, podeu trobar la informació necessària sobre els requisits de xarxa de RabbitMQ a la documentació oficial 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'

Ara que firewalldestà configurat, hem de donar-li instruccions per tornar a carregar la configuració.

sudo firewall-cmd --reload

Repetiu els passos d'aquesta secció a tots els servidors.

Instal·lar rabbitmqadmin

El connector de gestió inclou una eina anomenada Python rabbitmqadminque es pot instal·lar fàcilment al sistema un cop s'hagi activat el connector de gestió.

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

Configura el DNS

Heu d'utilitzar els noms d'amfitrió del servidor per identificar els servidors en clúster. De manera predeterminada, els servidors no tenen assignat cap registre DNS i la connexió fallarà. Per superar-ho ràpidament, afegiu el nom d'amfitrió mestre i mirall al /etc/hostsfitxer amb el vostre editor preferit.

Per exemple, el fitxer hosts del vostre mestre pot semblar el següent. Observeu els dos últims registres, que permeten que els servidors s'identifiquin entre ells pel seu nom d'amfitrió. Assegureu-vos de canviar les adreces IP per les vostres.

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

Agrupeu els nodes

Un requisit previ d'importació per permetre que els nodes s'uneixin entre ells és que la galeta Erlang de tots els nodes sigui idèntica. De manera predeterminada, a cada node se li assignarà una galeta Erlang única, de manera que l'heu de reconfigurar a tots els nodes.

L'ordre següent establirà la galeta Erlang a " WE<3COOKIES", però no dubteu a canviar-ho al vostre gust. Feu-ho a tots els servidors.

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

Reinicieu RabbitMQ a tots els servidors per assegurar-vos que la galeta Erlang es recarrega correctament.

sudo systemctl restart rabbitmq-server.service

Executeu les ordres següents a tots els servidors excepte al servidor mestre. Això permetrà que els nodes s'uneixin al servidor mestre i formen un clúster.

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

Verifiqueu que els nodes s'han unit al clúster executant l'ordre següent.

sudo rabbitmqctl cluster_status

Tots els vostres nodes apareixeran a la secció nodesi running_nodesde la sortida. A partir d'ara, ja no cal que repetiu els passos a cada servidor, la configuració es reflectirà automàticament als altres nodes.

Creeu una política d'alta disponibilitat

Ara que tenim un clúster de nodes RabbitMQ, ho podem utilitzar per fer cues i intercanvis d'alta disponibilitat mitjançant la configuració d'una política nova. Aquesta política es pot afegir mitjançant la consola de gestió de RabbitMQ o mitjançant la interfície de línia d'ordres.

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

La llista següent explicarà què significa cada part de l'ordre.

• -p "/": Utilitzeu aquesta política al "/"vhost (la predeterminada després de la instal·lació)
• --priority 1: L'ordre en què s'apliquen les polítiques
• --apply-to "all": Pot ser "queues", "exchanges"o"all"
• ha: El nom que donem a la nostra política
• ".*": l'expressió regular que s'utilitza per decidir a quines cues o intercanvis s'aplica aquesta política. ".*"coincidirà amb qualsevol cosa
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': la representació JSON de la política. Aquest document descriu el que volem: exactament 2 nodes en què les dades es sincronitzen automàticament

En resum, aquesta política garantirà que tindrem sempre 2 còpies de les dades en una cua o intercanvi sempre que tinguem almenys 2 nodes en funcionament. Si teniu més nodes, podeu augmentar el valor de ha-params. Es N/2 + 1recomana un quòrum, ( ), de nodes. Tenir més còpies de les vostres dades donaria lloc a un ús més gran del disc, d'E/S i de la xarxa que podria provocar un rendiment degradat.

Si voleu reflectir les dades a tots els nodes del clúster, podeu utilitzar el document JSON següent.

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

Si voleu reflectir les dades només a nodes específics, (per exemple: node-1i node-2), podeu utilitzar el següent.

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

Podeu canviar l'expressió regular per assignar polítiques diferents a diferents cues. Suposem que tenim els tres nodes següents:

• conill@mestre
• conill@client-ha
• conill@producte-ha

Aleshores podem crear dues polítiques que donaran com a resultat que les cues tinguin un nom que comenci per "client" per reflectir-se al rabbit@client-hanode i totes les cues que tinguin un nom que comenci per "producte" que es reflecteixin al rabbit@product-hanode.

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

Una petita observació aquí: les cues exclusives mai es reflecteixen ni són duradores a RabbitMQ, encara que aquesta política coincideixi amb aquestes cues. Les cues exclusives es destrueixen automàticament un cop un client es desconnecta i, com a tal, no serviria de res replicar-ho a un altre servidor. Si el servidor fallés, el client es desconnectaria d'ell i la cua es destruiria automàticament. Les instàncies reflectides també es destruirien.

Provant la configuració

Per provar la configuració en clúster podem crear una nova cua mitjançant la interfície de línia d'ordres a través de la consola de gestió.

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

Això crearà una cua duradora al /vhost predeterminat amb el nom my-ha-queue.

Executeu l'ordre següent i verifiqueu a la sortida que la cua té assignada la nostra política "ha" i té els pid al mestre i en un node mirall.

sudo rabbitmqctl list_queues name policy state pid slave_pids

Ara podem publicar un missatge a la cua des del node mestre i aturar RabbitMQ al node mestre.

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

Ara recupereu-lo connectant-vos al node mirall.

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

Finalment, podem reiniciar el nostre node mestre.

sudo systemctl start rabbitmq-server.service

Suprimeix l'usuari convidat

Com s'ha esmentat abans, RabbitMQ crea automàticament un usuari convidat amb una contrasenya de convidat predeterminada. Seria una mala pràctica deixar aquest usuari predeterminat en un sistema exposat públicament.

sudo rabbitmqctl delete_user guest