Schritt-für-Schritt-Anleitung zur Bereitstellung eines RabbitMQ Active-Passive Clusters

Die Implementierung von Hochverfügbarkeit (HA) für geschäftskritische Messaging-Dienste erfordert robuste Redundanz. Ein RabbitMQ Active-Passive Cluster-Setup ist ein klassischer Ansatz, um dies zu erreichen. Er stellt sicher, dass bei einem Ausfall des aktiven Knotens ein bestimmter passiver Knoten schnell die Übernahme durchführen kann, wodurch Ausfallzeiten minimiert werden. Diese Anleitung bietet einen umfassenden, schrittweisen Prozess zur Konfiguration einer solchen Bereitstellung, der Voraussetzungen, die Knotenkonfiguration und die Gewährleistung nahtloser Failover-Fähigkeiten abdeckt.

Dieses Bereitstellungsmuster basiert auf der Standard-RabbitMQ-Clusterbildung in Kombination mit einem externen Mechanismus (wie Pacemaker oder einfachen Skripten) zur Verwaltung der IP-Adressübernahme im Fehlerfall. In dieser Anleitung konzentrieren wir uns auf den Aspekt der RabbitMQ-Clusterbildung, der die Grundlage für das HA-Setup bildet.

Voraussetzungen für einen Active-Passive Cluster

Bevor Sie mit der Konfiguration beginnen, stellen Sie sicher, dass die folgenden Voraussetzungen auf allen vorgesehenen Cluster-Knoten (Knoten A – Aktiv, Knoten B – Passiv) erfüllt sind:

1. Identische Softwareversionen: Alle Knoten müssen exakt dieselbe Version von RabbitMQ Server und Erlang/OTP ausführen.
2. Netzwerkzugänglichkeit: Alle Knoten müssen über die notwendigen Ports miteinander kommunizieren können (Standard 5672 für AMQP, 25672 für Clustering).
3. Host-Auflösung: Konfigurieren Sie die Datei /etc/hosts (oder DNS) auf allen Knoten so, dass jeder Knoten den Hostnamen aller anderen Knoten zuverlässig auflösen kann.
4. Cookie-Konsistenz: Das Erlang 'Magic Cookie' muss auf allen Knoten identisch sein. Dies ist entscheidend, damit die Knoten einander für das Clustering vertrauen.

Herstellung der Cookie-Konsistenz

Das Erlang-Cookie bestimmt, ob Knoten sicher kommunizieren können. Es muss vom zuerst initialisierten Knoten auf alle anderen kopiert werden.

Auf Knoten A (Der erste Knoten):

Suchen Sie die Cookie-Datei (normalerweise /var/lib/rabbitmq/.erlang.cookie oder ~/.erlang.cookie, abhängig von der Installationsmethode) und kopieren Sie deren Inhalt.

Auf Knoten B (und nachfolgenden Knoten):

1. Stoppen Sie den RabbitMQ-Dienst:
   bash sudo systemctl stop rabbitmq-server
2. Ersetzen Sie die vorhandene Cookie-Datei durch den von Knoten A kopierten Inhalt und stellen Sie die korrekten Berechtigungen sicher (normalerweise 400).
   bash # Beispiel mit echo (Inhalt bei Bedarf ersetzen) echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie
3. Starten Sie den Dienst auf Knoten B:
   bash sudo systemctl start rabbitmq-server

Schritt 1: Konfiguration von Hostnamen und Netzwerk

Stellen Sie sicher, dass die Host-Dateien auf beiden Knoten A und B ihre Hostnamen korrekt zuordnen.

Beispiel /etc/hosts (auf beiden Servern):

192.168.1.10   rabbitmq-node-a
192.168.1.11   rabbitmq-node-b

Schritt 2: Initialisierung des ersten Cluster-Knotens (Aktiv)

Knoten A ist der anfängliche primäre Knoten, auf dem der Cluster zuerst eingerichtet wird.

1. Starten Sie den Dienst auf Knoten A (falls er nicht bereits läuft):
   bash sudo systemctl start rabbitmq-server
2. Status überprüfen: Stellen Sie sicher, dass der Knoten korrekt läuft.
   bash rabbitmqctl status

Schritt 3: Beitreten des zweiten Knotens (Passiv) zum Cluster

Nun weisen wir Knoten B an, dem von Knoten A geführten Cluster beizutreten.

1. Stoppen Sie den Dienst auf Knoten B (falls er läuft):
   bash sudo systemctl stop rabbitmq-server

2. Beitrittsbefehl: Führen Sie den Beitrittsbefehl auf Knoten B aus und geben Sie den Hostnamen von Knoten A als Peer an.
   bash rabbitmqctl join_cluster rabbit@rabbitmq-node-a
   Tipp: Verwenden Sie den in /etc/hosts definierten Hostnamen.

3. Starten Sie den Dienst auf Knoten B:
   bash sudo systemctl start rabbitmq-server

Schritt 4: Überprüfung der Cluster-Bildung

Melden Sie sich bei Knoten A an und überprüfen Sie, ob beide Knoten einander erkennen.

rabbitmqctl cluster_status

Erwarteter Ausgabeausschnitt:

Sie sollten sowohl rabbitmq-node-a als auch rabbitmq-node-b unter running_nodes aufgelistet sehen.

Cluster status of node rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

Schritt 5: Konfigurieren der Hochverfügbarkeit (Clustering von Queues)

Die Standard-RabbitMQ-Clusterbildung ermöglicht es Knoten, Metadaten (Benutzer, Exchanges) auszutauschen, aber Nachrichten in Warteschlangen werden typischerweise nicht automatisch repliziert, es sei denn, es werden spezifische HA-Richtlinien erzwungen. Für ein echtes Active-Passive-Failover müssen gespiegelte Warteschlangen (mirrored queues) verwendet werden.

Definieren der Richtlinie

Eine Richtlinie wird auf Warteschlangen angewendet, die bestimmten Mustern entsprechen, um zu definieren, wie viele Kopien der Warteschlange im Cluster existieren sollen und wo sie promoted (befördert) werden sollen.

Verwenden Sie den Befehl rabbitmqctl set_policy auf einem der Knoten, um die Spiegelung über den gesamten Cluster ("^") zu erzwingen.

```bash

Legen Sie eine Richtlinie namens 'ha-all' fest, die Warteschlangen, die mit einem beliebigen Namen ('^') übereinstimmen,

auf allen Knoten im Cluster (insgesamt 3 Knoten) spiegelt und das 'promote'-Verhalten festlegt.

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"