So richten Sie einen hochverfügbaren RabbitMQ-Cluster unter CentOS 7 ein

RabbitMQ ist ein weit verbreiteter Open-Source-Nachrichtenbroker, der AMQP, STOMP und weitere Protokolle unterstützt. In Unternehmensumgebungen und modernen Microservice-Architekturen übernimmt RabbitMQ eine zentrale Rolle als asynchrane Kommunikationsschnittstelle zwischen verschiedenen Diensten. Diese Anleitung beschreibt, wie Sie einen RabbitMQ-Cluster auf mehreren CentOS-7-Servern einrichten, um eine hohe Verfügbarkeit sicherzustellen. Dabei agiert ein Server als Hauptknoten, während zusätzliche Server als gespiegelte Knoten fungieren, um Ausfallsicherheit zu gewährleisten.

Systemvoraussetzungen

• Mindestens zwei frisch installierte und aktualisierte CentOS 7 Instanzen im selben privaten Subnetz
• RabbitMQ ist auf jedem Server installiert, inklusive aktivierter Webverwaltungsoberfläche (siehe Installationsanleitung für CentOS 7)
• Ein Benutzerkonto ohne Root-Rechte, das Sudo-Befehle ausführen darf (siehe Anleitung zur Sudo-Konfiguration für CentOS, Debian und FreeBSD)

Firewall einrichten

Standardmäßig blockiert das CentOS-Firewalltool firewalld sämtliche eingehenden Verbindungen. Um den Zugriff auf RabbitMQ und die Verwaltungsoberfläche von außen zu ermöglichen, müssen bestimmte Ports freigegeben werden.

Die Verwaltungsoberfläche von RabbitMQ läuft standardmäßig auf Port 15672. Um diesen Zugang von außen verfügbar zu machen, fügen Sie folgende Regel in der Public-Zone hinzu:

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

Damit sich die RabbitMQ-Knoten untereinander im internen Netzwerk austauschen können, müssen zusätzliche Ports ausschließlich für das Subnetz 192.168.0.100/24 geöffnet werden.

epmd-Erkennung aktivieren (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'

Kommunikation zwischen RabbitMQ-Knoten aktivieren (Port 25672)

Damit sich die RabbitMQ-Instanzen untereinander synchronisieren können, muss der Port 25672 innerhalb des internen Netzwerks geöffnet werden:

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-Kommunikation erlauben (Ports 35672–35682)

Die Kommandozeilen-Tools von RabbitMQ nutzen Ports im Bereich 35672 bis 35682. Diese Ports sollten ebenfalls für das interne Subnetz freigegeben werden:

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'

AMQP-Ports freigeben (5671 und 5672)

Wenn Ihre Anwendungen das AMQP-Protokoll verwenden, müssen Sie die folgenden Ports für interne Verbindungen öffnen:

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'

Weitere Informationen zu den Netzwerkanforderungen von RabbitMQ – insbesondere wenn Sie zusätzliche Protokolle verwenden – finden Sie in der offiziellen Dokumentation.

Firewall-Regeln neu laden

Nachdem alle notwendigen Ports freigegeben wurden, müssen Sie firewalld neu laden, um die Änderungen zu übernehmen:

sudo firewall-cmd --reload

Führen Sie diese Konfiguration auf allen Servern durch, die Teil des RabbitMQ-Clusters sein sollen.

Installation des CLI-Tools rabbitmqadmin

Die Verwaltungsoberfläche von RabbitMQ stellt ein Python-basiertes Tool namens rabbitmqadmin bereit, das verfügbar ist, sobald das Management-Plugin aktiviert wurde. Die Installation erfolgt mit den folgenden Befehlen:

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

DNS für Hostnamenauflösung konfigurieren

Für den Aufbau eines RabbitMQ-Clusters ist es erforderlich, dass die Server sich gegenseitig über Hostnamen erkennen. Da in der Regel keine DNS-Einträge vorhanden sind, müssen Sie die Datei /etc/hosts auf jedem Server bearbeiten und IP-Adressen entsprechenden Hostnamen zuordnen.

Nachfolgend ein Beispiel für die /etc/hosts-Datei eines Master-Servers. Passen Sie die IP-Adressen und Hostnamen an Ihre Umgebung an:

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

RabbitMQ-Server zu einem Cluster verbinden

Damit mehrere RabbitMQ-Server einem gemeinsamen Cluster beitreten können, müssen alle denselben Erlang-Cookie verwenden. Standardmäßig erstellt jede Instanz einen eigenen Cookie, daher muss dieser manuell auf allen Systemen gesetzt werden.

Der Cookie lässt sich mit folgendem Befehl setzen (Sie können einen beliebigen Wert verwenden):

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

Starten Sie anschließend den RabbitMQ-Dienst neu, damit die Änderung übernommen wird:

sudo systemctl restart rabbitmq-server.service

Führen Sie die folgenden Befehle auf allen Knoten außer dem Master aus, um sie dem Cluster hinzuzufügen:

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

Prüfen Sie den Clusterstatus anschließend mit diesem Befehl:

sudo rabbitmqctl cluster_status

Alle verbundenen Knoten werden im Abschnitt nodes und running_nodes aufgelistet. Ab diesem Moment werden alle Konfigurationen automatisch an die weiteren Knoten im Cluster übertragen.

Hochverfügbarkeit für Queues und Exchanges aktivieren

Erstellen Sie eine Hochverfügbarkeitsrichtlinie über die Verwaltungsoberfläche oder die Kommandozeile, um eine hohe Ausfallsicherheit und Datenbeständigkeit sicherzustellen. Das folgende Beispiel definiert eine Richtlinie für die Spiegelung von Daten auf zwei Knoten:

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

Erklärung der Parameter:

• -p "/": Gilt für den Standard-Virtual-Host
• --priority 1: Bestimmt die Priorität der Regel
• --apply-to "all": Gilt für Queues und Exchanges
• ha: Name der Richtlinie
• ".*": Regulärer Ausdruck für alle Ressourcen
• JSON-Objekt: Gibt an, dass exakt 2 Knoten synchronisiert werden und die Synchronisation automatisch erfolgt

Sie können den Wert von ha-params erhöhen, um weitere Replikate zu erzeugen. Für maximale Ausfallsicherheit empfiehlt sich eine Konfiguration mit Quorum (N/2 + 1). Bedenken Sie jedoch, dass eine größere Anzahl an Kopien die Performance durch erhöhten Netzwerk-, Speicher- und IO-Bedarf beeinträchtigen kann.

Alternative Strategien zur Spiegelung

Daten auf alle Cluster-Knoten spiegeln:

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

Daten gezielt nur auf bestimmte Knoten spiegeln (z. B. node-1 und node-2):

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

Es ist außerdem möglich, Richtlinien für bestimmte Queue-Namen zu definieren. Angenommen, Sie haben folgende Knoten:

• rabbit@master
• rabbit@client-ha
• rabbit@product-ha

Sie können dann separate Richtlinien für Queues mit dem Präfix client bzw. product erstellen:

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

Hinweis: Exklusive Queues, die automatisch gelöscht werden, sobald der Client die Verbindung trennt, können nicht gespiegelt werden. Auch wenn eine entsprechende Richtlinie existiert, werden solche Queues nicht repliziert – da ihre Kurzlebigkeit eine Spiegelung überflüssig macht.

Den RabbitMQ-Cluster testen

Um die Clusterkonfiguration zu überprüfen, legen Sie über die Kommandozeile mit Hilfe des Management-Plugins eine neue Queue an:

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

Dieser Befehl erstellt eine dauerhafte Queue mit dem Namen my-ha-queue im Standard-Virtual-Host /.

Überprüfen Sie anschließend, ob diese Queue der Hochverfügbarkeitsrichtlinie zugeordnet ist und auf mehrere Knoten gespiegelt wurde:

sudo rabbitmqctl list_queues name policy state pid slave_pids

Senden Sie nun von Ihrem Master-Knoten eine Testnachricht an die Queue:

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

Fahren Sie anschließend RabbitMQ auf dem Master-Knoten herunter, um ein Failover-Szenario zu simulieren:

sudo systemctl rabbitmqctl shutdown

Rufen Sie die Nachricht nun über den Spiegelknoten ab, indem Sie dessen IP-Adresse oder DNS-Namen verwenden:

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

Zum Schluss starten Sie den Master-Knoten wieder:

sudo systemctl start rabbitmq-server.service

Standardbenutzer „guest“ entfernen

RabbitMQ wird mit einem vordefinierten Benutzerkonto guest ausgeliefert. Dieses Konto sollte auf öffentlich erreichbaren Systemen aus Sicherheitsgründen entfernt werden.

Nutzen Sie folgenden Befehl, um den Gastbenutzer zu löschen:

sudo rabbitmqctl delete_user guest

Fazit

Mit dieser umfassenden Anleitung haben Sie erfolgreich einen stabilen und hochverfügbaren RabbitMQ-Cluster unter CentOS 7 eingerichtet. Durch die Kombination mehrerer Knoten, das Spiegeln von Queues und Exchanges sowie die Einrichtung automatischer Failover-Mechanismen ist Ihr Messaging-System gegen Ausfälle abgesichert. Die Konfiguration von Firewallregeln, DNS-Zuweisungen, Clustereinstellungen und Replikationsrichtlinien trägt zur Robustheit Ihrer Infrastruktur bei.

Überwachen Sie regelmäßig den Zustand Ihres Clusters, analysieren Sie Leistungskennzahlen und passen Sie Richtlinien an wachsende Anforderungen an. Bei korrekter Pflege stellt Ihr RabbitMQ-Cluster eine zuverlässige und sichere Nachrichtenübertragung für Ihre gesamte Microservice-Landschaft sicher.