DevOps Wissensdatenbank
DevOps Wissensdatenbank

RabbitMQ Clustering: Einrichtung, Konfiguration und Best Practices

Nutzen Sie die Leistungsfähigkeit skalierbarer und widerstandsfähiger Nachrichtenübermittlung durch RabbitMQ Clustering. Dieser Leitfaden behandelt wesentliche Konzepte wie Knotentypen, Netzwerkpartitionen und Datensynchronisation. Erfahren Sie Schritt für Schritt, wie Sie einen RabbitMQ-Cluster einrichten, Hochverfügbarkeits- (HA)-Warteschlangen mithilfe von Richtlinien (Policies) konfigurieren und Best Practices für eine robuste Bereitstellung und Verwaltung implementieren. Perfekt für Entwickler und Betreiber, die fehlertolerante, nachrichtengesteuerte Anwendungen erstellen möchten.

29 Aufrufe

RabbitMQ-Clustering: Einrichtung, Konfiguration und Best Practices

RabbitMQ ist ein leistungsstarker und flexibler Message Broker, der die asynchrone Kommunikation zwischen Anwendungen ermöglicht. Während eine einzelne RabbitMQ-Instanz viele Anwendungsfälle abdecken kann, profitieren komplexe Systeme oder Systeme mit hoher Verfügbarkeit oft erheblich von Clustering. Das Clustern von RabbitMQ ermöglicht Lastverteilung, verbesserte Fehlertoleranz und erweiterte Skalierbarkeit, indem mehrere RabbitMQ-Knoten zu einer einzigen logischen Einheit zusammengefasst werden.

Dieser Artikel führt Sie durch die grundlegenden Konzepte des RabbitMQ-Clustering, einschließlich verschiedener Knotentypen, der Handhabung von Netzwerkpartitionen und der Mechanismen zur Datensynchronisierung. Anschließend erhalten Sie eine schrittweise Anleitung zur Einrichtung und Konfiguration einer robusten Cluster-Umgebung, gefolgt von wesentlichen Best Practices zur Gewährleistung von Stabilität und Leistung.

Das RabbitMQ-Clustering verstehen

Ein RabbitMQ-Cluster ist eine Ansammlung von einem oder mehreren RabbitMQ-Knoten, die zusammenarbeiten. Diese Knoten teilen Informationen, sodass sie als ein einziger, einheitlicher Message Broker fungieren können. Das Verständnis der Kernkomponenten und des Verhaltens eines Clusters ist für eine effektive Einrichtung und Verwaltung von entscheidender Bedeutung.

Knotentypen

RabbitMQ-Knoten in einem Cluster lassen sich in zwei Haupttypen einteilen:

  • Gespiegelte Warteschlangen (Classic) / Hochverfügbarkeitswarteschlangen (HA-Warteschlangen) (Policy-basiert): Dies ist der primäre Mechanismus zur Erreichung von Fehlertoleranz. Wenn eine Warteschlange gespiegelt oder hochverfügbar gemacht wird, werden ihre Inhalte über mehrere Knoten im Cluster repliziert. Fällt ein Knoten aus, kann ein anderer Knoten, der eine Replik der Warteschlange enthält, die Verwaltung übernehmen und so die Nachrichtenverfügbarkeit sicherstellen. HA-Warteschlangen werden über Richtlinien (Policies) konfiguriert und stellen den modernen Ansatz dar, der mehr Flexibilität bietet als klassische gespiegelte Warteschlangen.
  • Nicht gespiegelte Warteschlangen: Diese Warteschlangen existieren nur auf dem Knoten, auf dem sie deklariert werden. Wenn dieser Knoten nicht verfügbar wird, gehen die Nachrichten in dieser Warteschlange verloren, es sei denn, es sind andere Maßnahmen getroffen worden (z. B. Producer-Bestätigungen und Wiederholungsversuche, persistente Nachrichten mit sorgfältigem Consumer-Design).

Netzwerkpartitionen

Netzwerkpartitionen treten auf, wenn Knoten in einem Cluster aufgrund von Netzwerkproblemen nicht mehr miteinander kommunizieren können. Dies kann zu Situationen führen, in denen eine Gruppe von Knoten glaubt, dass der Rest des Clusters ausgefallen ist. RabbitMQ behandelt Partitionen je nach Warteschlangentyp unterschiedlich:

  • HA-Warteschlangen: Wenn eine Partition auftritt, arbeiten der oder die Knoten mit der führenden Replik für eine HA-Warteschlange weiter. Andere Knoten in der Minderheitspartition hören auf, Verbindungen für diese Warteschlange anzunehmen, bis die Partition behoben ist. Dies verhindert Split-Brain-Szenarien, bei denen Nachrichten unabhängig voneinander auf verschiedene Seiten der Partition geschrieben werden könnten.
  • Klassische gespiegelte Warteschlangen: Ähnlich wie bei HA-Warteschlangen stellen die Minderheitspartitionen klassischer gespiegelter Warteschlangen den Betrieb ein.

Datensynchronisierung und Konsistenz

In einem RabbitMQ-Cluster werden bestimmte Metadaten (wie Austausch- und Warteschlangendefinitionen, Benutzeranmeldeinformationen und virtuelle Host-Konfigurationen) über alle Knoten repliziert. Der Nachrichteninhalt wird jedoch hauptsächlich durch Mirroring- oder HA-Richtlinien für Warteschlangen verwaltet.

  • Metadatensynchronisierung: Wenn Sie einen Austausch oder eine Warteschlange auf einem beliebigen Knoten deklarieren, wird diese Definition an alle anderen Knoten im Cluster weitergegeben. Dies stellt sicher, dass alle Knoten eine konsistente Sicht auf die Topologie haben.
  • Nachrichtensynchronisierung (über Mirroring/HA): Für gespiegelte oder HA-Warteschlangen stellt RabbitMQ sicher, dass Nachrichten, die an solche Warteschlangen veröffentlicht werden, an ihre Spiegelknoten repliziert werden. Die führende Replik verarbeitet das Veröffentlichen und Konsumieren, und ihr Zustand wird mit ihren Spiegeln synchronisiert.

Ein RabbitMQ-Cluster einrichten

Die Einrichtung eines RabbitMQ-Clusters beinhaltet die Konfiguration mehrerer RabbitMQ-Instanzen, damit diese sich gegenseitig erkennen und kommunizieren können. Die gebräuchlichste Methode ist die Verwendung der erlang.cookie-Datei.

Voraussetzungen:

  • Mehrere Server oder virtuelle Maschinen, auf denen RabbitMQ installiert werden soll.
  • Netzwerkkonnektivität zwischen allen Servern.
  • RabbitMQ ist auf allen Knoten installiert (stellen Sie sicher, dass die Versionen kompatibel sind).

Schritte:

  1. RabbitMQ auf allen Knoten installieren: Befolgen Sie auf jedem Server die offizielle Installationsanleitung für RabbitMQ für Ihr Betriebssystem.

  2. Das Erlang Cookie konfigurieren:
    Das Erlang Cookie ist ein geheimer Schlüssel, den alle Knoten in einem Cluster teilen müssen, um kommunizieren zu können. Es wird in einer Datei namens .erlang.cookie im Home-Verzeichnis des Benutzers gespeichert, der den RabbitMQ-Prozess ausführt (normalerweise rabbitmq oder root).

    • Auf dem ersten Knoten (Knoten A):
      Generieren Sie ein starkes, zufälliges Cookie. Sie können Befehle wie uuidgen oder openssl rand -hex 16 verwenden.
      bash # Beispiel mit openssl openssl rand -hex 16 | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie sudo chmod 600 /var/lib/rabbitmq/.erlang.cookie
      Ersetzen Sie /var/lib/rabbitmq/ durch Ihr RabbitMQ-Datenverzeichnis, falls es abweicht.

    • Auf den nachfolgenden Knoten (Knoten B, Knoten C usw.):
      Stoppen Sie den RabbitMQ-Dienst.
      bash sudo systemctl stop rabbitmq-server
      Kopieren Sie die Datei .erlang.cookie von Knoten A an die entsprechende Stelle auf Knoten B (und Knoten C usw.). Stellen Sie sicher, dass Eigentümer und Berechtigungen identisch sind.
      bash # Auf Knoten B, nach dem Kopieren der Datei sudo chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie sudo chmod 600 /var/lib/rabbitmq/.erlang.cookie

  3. RabbitMQ auf allen Knoten starten:
    Starten Sie den RabbitMQ-Dienst auf allen Knoten. Es ist ratsam, den ersten Knoten, der als Cluster-Beitrittsknoten fungiert, zuletzt zu starten.
    bash sudo systemctl start rabbitmq-server

  4. Knoten dem Cluster beitreten lassen:
    Wählen Sie einen Knoten (z. B. Knoten A) als Anfangsknoten. Lassen Sie dann jeden nachfolgenden Knoten (z. B. Knoten B) diesem Knoten A beitreten.

    • Auf Knoten B:
      bash sudo rabbitmqctl join_cluster rabbit@node-a
      Ersetzen Sie node-a durch den Hostnamen von Knoten A. Stellen Sie sicher, dass der Hostname von Knoten B aufgelöst werden kann. Möglicherweise müssen Sie den vollständigen Netzwerknamen angeben, wenn DNS nicht zuverlässig ist, z. B. [email protected].

    • Auf Knoten C:
      bash sudo rabbitmqctl join_cluster rabbit@node-a

    • Wichtiger Hinweis: Standardmäßig fügt join_cluster den Knoten dem Cluster hinzu, behält aber seine Warteschlangen und Exchanges bei. Um einen „