Clustering von RabbitMQ unter CentOS 7

• Voraussetzungen
• Konfigurieren Sie die Firewall
• Installieren Sie rabbitmqadmin
• DNS konfigurieren
• Cluster die Knoten
• Erstellen Sie eine Hochverfügbarkeitsrichtlinie
• Setup testen
• Löschen Sie den Gastbenutzer

RabbitMQ ist ein Open-Source-Nachrichtenbroker, der AMQP, STOMP und andere Kommunikationstechnologien unterstützt. Es wird häufig in Unternehmensanwendungen und modernen Mikrodienstarchitekturen verwendet, wo es als asynchroner Nachrichtenkanal zwischen verschiedenen Mikrodiensten fungiert. In diesem Handbuch wird beschrieben, wie Sie RabbitMQ auf mehreren CentOS 7-Servern zu einem hochverfügbaren Nachrichtenbroker zusammenfassen können. In diesem Lernprogramm fungiert ein Server als Master-Server und die anderen Server als Spiegelserver, falls der Master-Server nicht mehr verfügbar ist.

Voraussetzungen

• Mindestens zwei neu bereitgestellte und aktualisierte CentOS 7-Instanzen im selben Subnetz mit aktiviertem privaten Netzwerk
• RabbitMQ wird mit aktivierter Verwaltungskonsole auf jedem Server installiert (siehe Installieren von RabbitMQ unter CentOS 7 ).
• Ein Benutzer ohne Administratorrechte mit Sudo- Rechten (siehe Verwendung von Sudo unter Debian, CentOS und FreeBSD )

Konfigurieren Sie die Firewall

Die CentOS-Firewall ( firewalld) lässt standardmäßig keinen eingehenden Datenverkehr zu. Um RabbitMQ für andere Systeme innerhalb und außerhalb des Netzwerks verfügbar zu machen und um auf die Verwaltungskonsole zugreifen zu können, müssen zunächst einige Ports geöffnet werden.

Die Webschnittstellen-Verwaltungskonsole von RabbitMQ überwacht standardmäßig den Port 15672. Wir möchten die Verwaltungskonsole öffentlich zugänglich machen, damit wir von unserem Computer aus darauf zugreifen können. Wir werden daher anweisen firewalld, den Port 15672in der öffentlichen Zone (der Standard- und aktiven Zone einer Vultr-Instanz) dauerhaft zu öffnen .

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

Die RabbitMQ-Knoten müssen miteinander kommunizieren können. Wir möchten die notwendigen Ports öffnen, aber nur über das interne Netzwerk. Wir möchten nicht, dass jemand im Internet unsere Server verwalten oder direkt kontaktieren kann. Die folgenden Befehle setzen voraus, dass sich unsere Server im 192.168.0.100/24Subnetz befinden.

Der erste Dienst ist der epmdPeer-Erkennungsdienst, der standardmäßig den Port überwacht 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 die Internode- und CLI-Kommunikation muss RabbitMQ über den Port kommunizieren können 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'

Die CLI-Tools kommunizieren über den Portbereich 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'

Wenn Ihre Anwendungen das AMQP-Protokoll benötigen, müssen Sie auch Ports 5671und öffnen 5672. Wenn Sie über ein anderes Protokoll kommunizieren können müssen, finden Sie die erforderlichen Informationen zu den Netzwerkanforderungen von RabbitMQ in der offiziellen 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'

Nachdem dies firewalldkonfiguriert ist, müssen wir es anweisen, die Konfiguration neu zu laden.

sudo firewall-cmd --reload

Wiederholen Sie die Schritte aus diesem Abschnitt auf allen Servern.

Installieren rabbitmqadmin

Das Management-Plugin enthält ein Python-Tool namens, rabbitmqadmindas einfach auf dem System installiert werden kann, sobald das Management-Plugin aktiviert ist.

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

DNS konfigurieren

Sie müssen die Hostnamen des Servers verwenden, um die Server beim Clustering zu identifizieren. Standardmäßig ist den Servern kein DNS-Eintrag zugewiesen, und die Verbindung schlägt fehl. Um dies schnell zu beheben, fügen Sie den Master- und Mirror-Hostnamen /etc/hostsmit Ihrem bevorzugten Editor zur Datei hinzu.

Beispielsweise könnte die Hosts-Datei Ihres Masters wie folgt aussehen. Beachten Sie die letzten beiden Datensätze, mit denen sich die Server anhand ihres Hostnamens identifizieren können. Stellen Sie sicher, dass Sie die IP-Adressen in Ihre eigenen ändern.

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

Cluster die Knoten

Eine Importvoraussetzung, damit Knoten miteinander verbunden werden können, ist, dass das Erlang-Cookie aller Knoten identisch ist. Standardmäßig wird jedem Knoten ein eindeutiges Erlang-Cookie zugewiesen, sodass Sie es auf allen Knoten neu konfigurieren müssen.

Mit dem folgenden Befehl wird das Erlang-Cookie auf " WE<3COOKIES" gesetzt. Sie können dies jedoch nach Ihren Wünschen ändern. Tun Sie dies auf allen Servern.

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

Starten Sie RabbitMQ auf allen Servern neu, um sicherzustellen, dass das Erlang-Cookie ordnungsgemäß neu geladen wird.

sudo systemctl restart rabbitmq-server.service

Führen Sie die folgenden Befehle auf allen Servern außer auf dem Master-Server aus. Dadurch können die Knoten dem Master-Server beitreten und einen Cluster bilden.

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

Stellen Sie sicher, dass die Knoten dem Cluster beigetreten sind, indem Sie den folgenden Befehl ausführen.

sudo rabbitmqctl cluster_status

Alle Ihre Knoten werden im Abschnitt nodesund running_nodesder Ausgabe angezeigt. Von nun an müssen Sie die Schritte auf jedem Server nicht mehr wiederholen. Die Konfiguration wird automatisch auf die anderen Knoten gespiegelt.

Erstellen Sie eine Hochverfügbarkeitsrichtlinie

Jetzt, da wir einen Cluster von RabbitMQ-Knoten haben, können wir damit Warteschlangen und Austausch mit hoher Verfügbarkeit erstellen, indem wir eine neue Richtlinie einrichten. Diese Richtlinie kann über die RabbitMQ-Verwaltungskonsole oder über die Befehlszeilenschnittstelle hinzugefügt werden.

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

In der folgenden Liste wird erläutert, was jeder Teil des Befehls bedeutet.

• -p "/": Verwenden Sie diese Richtlinie auf dem "/"vhost (die Standardeinstellung nach der Installation).
• --priority 1: Die Reihenfolge, in der Richtlinien angewendet werden sollen
• --apply-to "all": Kann sein "queues", "exchanges"oder"all"
• ha: Der Name, den wir unserer Politik geben
• ".*": Der reguläre Ausdruck, mit dem entschieden wird, auf welche Warteschlangen oder Austausche diese Richtlinie angewendet wird. ".*"wird alles passen
• '{ "ha-mode": "exactly", "ha-params": 2, "ha-sync-mode": "automatic"}': Die JSON-Darstellung der Richtlinie. Dieses Dokument beschreibt, dass wir wollen - genau 2 Knoten, auf denen die Daten automatisch synchronisiert werden

Kurz gesagt, diese Richtlinie stellt sicher, dass wir immer 2 Kopien der Daten in einer Warteschlange oder einem Austausch haben, solange mindestens 2 Knoten in Betrieb sind. Wenn Sie mehr Knoten haben, können Sie den Wert von erhöhen ha-params. Ein Quorum ( N/2 + 1) von Knoten wird empfohlen. Wenn Sie mehr Kopien Ihrer Daten haben, führt dies zu einer höheren Festplatten-, E / A- und Netznutzung, was zu einer Leistungsminderung führen kann.

Wenn Sie die Daten auf alle Knoten im Cluster spiegeln möchten, können Sie das folgende JSON-Dokument verwenden.

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

Wenn Sie die Daten nur auf bestimmte Knoten spiegeln möchten (z. B. node-1und node-2), können Sie Folgendes verwenden.

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

Sie können den regulären Ausdruck ändern, um verschiedenen Warteschlangen unterschiedliche Richtlinien zuzuweisen. Angenommen, wir haben die folgenden drei Knoten:

• Kaninchen @ Meister
• rabbit @ client-ha
• Kaninchen @ Produkt-ha

Wir können dann zwei Richtlinien erstellen, die dazu führen, dass Warteschlangen mit einem Namen, der mit "client" beginnt, auf den rabbit@client-haKnoten gespiegelt werden, und alle Warteschlangen mit einem Namen, der mit "product" beginnt, auf den rabbit@product-haKnoten gespiegelt werden.

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

Eine kleine Bemerkung hier: Exklusive Warteschlangen werden in RabbitMQ niemals gespiegelt oder dauerhaft, selbst wenn diese Richtlinie mit solchen Warteschlangen übereinstimmen würde. Exklusive Warteschlangen werden automatisch zerstört, sobald ein Client die Verbindung trennt. Daher ist es nicht sinnvoll, sie auf einen anderen Server zu replizieren. Wenn der Server ausfallen würde, würde der Client die Verbindung trennen und die Warteschlange würde automatisch zerstört. Gespiegelte Instanzen würden ebenfalls zerstört.

Setup testen

Um das Cluster-Setup zu testen, können wir über die Befehlszeilenschnittstelle über die Verwaltungskonsole eine neue Warteschlange erstellen.

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

Dadurch wird eine dauerhafte Warteschlange auf dem Standard- /vhost mit dem Namen erstellt my-ha-queue.

Führen Sie den folgenden Befehl aus und überprüfen Sie in der Ausgabe, ob der Warteschlange unsere 'ha'-Richtlinie zugewiesen ist und PIDs auf dem Master und auf einem Spiegelknoten vorhanden sind.

sudo rabbitmqctl list_queues name policy state pid slave_pids

Wir können jetzt eine Nachricht vom Masterknoten in der Warteschlange veröffentlichen und RabbitMQ auf dem Masterknoten stoppen.

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

Holen Sie es sich jetzt zurück, indem Sie eine Verbindung zum Spiegelknoten herstellen.

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

Schließlich können wir unseren Masterknoten neu starten.

sudo systemctl start rabbitmq-server.service

Löschen Sie den Gastbenutzer

Wie bereits erwähnt, erstellt RabbitMQ automatisch einen Gastbenutzer mit einem Standard-Gastkennwort. Es wäre eine schlechte Praxis, diesen Standardbenutzer auf einem öffentlich zugänglichen System zu belassen.

sudo rabbitmqctl delete_user guest