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

RabbitMQ-Hochverfügbarkeit erfordert mehr als zwei Server, die sich sehen können. Sie benötigen Clustering für gemeinsame Metadaten, replizierte Warteschlangen für Nachrichtenverfügbarkeit und einen klaren Failover-Pfad für Clients.

Diese Anleitung zeigt die RabbitMQ-Seite einer Active-Passive-Bereitstellung. Der Client-Failover erfolgt normalerweise über einen Load Balancer, DNS-Änderung, Service Discovery oder eine virtuelle IP, die außerhalb von RabbitMQ verwaltet wird.

Voraussetzungen für ein 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:

Kompatible Softwareversionen: Halten Sie die Versionen von RabbitMQ Server und Erlang/OTP auf allen Knoten konsistent. Verwenden Sie in der Praxis auf jedem Knoten die gleiche RabbitMQ-Version, es sei denn, Sie folgen RabbitMQs dokumentiertem Rolling-Upgrade-Pfad.
Netzwerkerreichbarkeit: Knoten müssen über AMQP-Ports (von Clients genutzt), den Verteilungsport (für Clustering) sowie alle von Ihnen aktivierten Management- oder TLS-Ports kommunizieren können.
Host-Auflösung: Konfigurieren Sie die /etc/hosts-Datei (oder DNS) auf allen Knoten, sodass jeder Knoten den Hostnamen aller anderen Knoten zuverlässig auflösen kann.
Cookie-Konsistenz: Das Erlang-„Magic Cookie“ muss auf allen Knoten identisch sein. Dies ist entscheidend, damit die Knoten einander für das Clustering vertrauen.

Cookie-Konsistenz herstellen

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

Auf Knoten A (dem ersten Knoten):

Suchen Sie die Cookie-Datei (normalerweise /var/lib/rabbitmq/.erlang.cookie oder ~/.erlang.cookie, je nach Installationsmethode) und kopieren Sie deren Inhalt.

Auf Knoten B (und weiteren Knoten):

Stoppen Sie den RabbitMQ-Dienst:
```
sudo systemctl stop rabbitmq-server
```

Ersetzen Sie die vorhandene Cookie-Datei durch den von Knoten A kopierten Inhalt und stellen Sie die korrekten Berechtigungen sicher (normalerweise 400).

# Beispiel mit echo (Inhalt entsprechend ersetzen)
echo "IHR_LANGER_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

Starten Sie den Dienst auf Knoten B:
```
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) die 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: Initialisieren des ersten Cluster-Knotens (Aktiv)

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

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

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

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

Stoppen Sie die RabbitMQ-Anwendung auf Knoten B, während der Erlang-Knoten verfügbar bleibt:
```
sudo rabbitmqctl stop_app
```
Setzen Sie den lokalen Zustand von Knoten B zurück, falls er bereits als eigenständiger Knoten initialisiert wurde:
```
sudo rabbitmqctl reset
```
Beitrittsbefehl: Führen Sie den Beitrittsbefehl auf Knoten B aus und geben Sie den Hostnamen von Knoten A als Peer an.
```
sudo rabbitmqctl join_cluster rabbit@rabbitmq-node-a
```
Tipp: Verwenden Sie den in /etc/hosts definierten Hostnamen.
Starten Sie die RabbitMQ-Anwendung auf Knoten B:
```
sudo rabbitmqctl start_app
```

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: Konfiguration der Hochverfügbarkeit für Warteschlangen

Standard-RabbitMQ-Clustering teilt Metadaten wie Benutzer, Exchanges, Bindungen und Richtlinien. Warteschlangeninhalte benötigen einen replizierten Warteschlangentyp, wenn Nachrichten einen Knotenausfall überleben sollen.

Verwenden Sie für moderne RabbitMQ-Bereitstellungen Quorum-Warteschlangen für replizierte dauerhafte Warteschlangen. Klassische gespiegelte Warteschlangen verwendeten ha-mode-Richtlinien in älteren RabbitMQ-Versionen, aber dieser Ansatz ist veraltet und aus neueren Hauptversionen entfernt.

Deklarieren einer Quorum-Warteschlange

Sie können Quorum-Warteschlangen aus Ihrer Anwendung oder mit rabbitmqadmin deklarieren. Dieses Beispiel erstellt eine dauerhafte Quorum-Warteschlange:

rabbitmqadmin declare queue name=orders durable=true arguments='{"x-queue-type":"quorum"}'

Für Labore mit zwei Knoten kann eine Quorum-Warteschlange laufen, aber sie kann den Verlust eines Knotens nicht tolerieren und dennoch eine Mehrheit behalten. Verwenden Sie für die Produktion mindestens drei RabbitMQ-Knoten für Quorum-Warteschlangen, damit ein Knoten ausfallen kann, während die Warteschlange noch eine Mehrheit hat.

Schritt 6: Failover testen

Bevor Sie das Cluster als bereit erklären, testen Sie den Pfad, den Ihre Clients verwenden werden:

Veröffentlichen Sie einige dauerhafte Testnachrichten in einer Quorum-Warteschlange.
Stoppen Sie die RabbitMQ-Anwendung des aktiven Knotens mit sudo rabbitmqctl stop_app.
Bestätigen Sie, dass Clients über Ihren Load Balancer, Ihr DNS-Ziel oder Ihr Service-Discovery-Setup erneut verbinden.
Konsumieren Sie die Testnachrichten vom überlebenden Knoten.
Starten Sie die gestoppte Anwendung erneut mit sudo rabbitmqctl start_app und überprüfen Sie rabbitmqctl cluster_status.

Abschließende Erkenntnis

RabbitMQ-Clustering bietet gemeinsame Broker-Metadaten, aber die Warteschlangenverfügbarkeit hängt vom Warteschlangentyp und dem Client-Failover-Design ab. Verwenden Sie Quorum-Warteschlangen für replizierte dauerhafte Warteschlangen, halten Sie mindestens drei Knoten für echte Fehlertoleranz vor und testen Sie den Failover mit dem gleichen Verbindungspfad, den Ihre Anwendungen verwenden.