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.
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.
rabbitmqadminEl 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
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
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.
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àticamentEn 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:
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.
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
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
La Intel·ligència Artificial no està en el futur, és aquí mateix en el present. En aquest bloc Llegiu com les aplicacions d'Intel·ligència Artificial han afectat diversos sectors.
També ets víctima d'atacs DDOS i estàs confós sobre els mètodes de prevenció? Llegiu aquest article per resoldre les vostres consultes.
Potser haureu sentit que els pirates informàtics guanyen molts diners, però us heu preguntat mai com guanyen aquest tipus de diners? anem a discutir.
Vols veure els invents revolucionaris de Google i com aquests invents van canviar la vida de tots els éssers humans actuals? A continuació, llegiu al bloc per veure els invents de Google.
El concepte de cotxes autònoms per sortir a les carreteres amb l'ajuda de la intel·ligència artificial és un somni que tenim des de fa temps. Però malgrat les diverses promeses, no es veuen enlloc. Llegeix aquest blog per saber-ne més...
A mesura que la ciència evoluciona a un ritme ràpid, fent-se càrrec de molts dels nostres esforços, també augmenten els riscos de sotmetre'ns a una singularitat inexplicable. Llegeix, què pot significar per a nosaltres la singularitat.
Llegeix el blog per conèixer de la manera més senzilla les diferents capes de l'Arquitectura Big Data i les seves funcionalitats.
Els mètodes d'emmagatzematge de les dades que han anat evolucionant poden ser des del naixement de les dades. Aquest bloc tracta l'evolució de l'emmagatzematge de dades a partir d'una infografia.
En aquest món digital, els dispositius domèstics intel·ligents s'han convertit en una part crucial de les vides. A continuació, es mostren alguns avantatges sorprenents dels dispositius domèstics intel·ligents sobre com fan que la nostra vida valgui la pena i sigui més senzilla.
Recentment, Apple va llançar macOS Catalina 10.15.4, una actualització de suplements per solucionar problemes, però sembla que l'actualització està causant més problemes que provoquen el bloqueig de les màquines Mac. Llegiu aquest article per obtenir més informació
