RabbitMQ-Clustering: Einrichtung, Konfiguration und bewährte Verfahren

RabbitMQ-Clustering wird oft missverstanden. Ein Cluster bietet einen logischen Broker, der aus mehreren Erlang-Knoten besteht. Er teilt Benutzer, vhosts, Exchanges, Bindungen, Richtlinien und andere Metadaten über diese Knoten hinweg. Es stellt nicht automatisch sicher, dass die Nachrichten jeder Warteschlange überall verfügbar sind. Die Verfügbarkeit von Warteschlangen hängt vom Warteschlangentyp und seinen Replikationseinstellungen ab.

Dieser Unterschied ist in der Produktion wichtig. Ein Cluster kann die Verwaltung und das Routing erleichtern und hochverfügbare Warteschlangen unterstützen, ist jedoch kein magischer Leistungsschalter. Wenn Sie alle heißen Warteschlangen auf einen Knoten legen, erledigt dieser Knoten immer noch die Arbeit. Wenn Sie klassische Warteschlangen ohne Replikation verwenden und der Knoten des Warteschlangen-Leaders ausfällt, ist diese Warteschlange nicht verfügbar, bis der Knoten zurückkehrt. Gestalten Sie den Cluster um die Warteschlangen, die Sie tatsächlich betreiben.

Was ein Cluster teilt und was nicht

RabbitMQ-Cluster-Metadaten werden repliziert. Wenn Sie einen Exchange auf einem Knoten deklarieren, wissen die anderen Knoten davon. Wenn Sie einen Benutzer oder eine Richtlinie hinzufügen, speichert der Cluster diese Definition. Client-Anwendungen können eine Verbindung zu jedem Knoten herstellen und dieselbe Topologie verwenden.

Nachrichten sind anders. Eine Warteschlange hat einen Leader. Bei klassischen Warteschlangen leben die Nachrichten auf dem Knoten, der diese Warteschlange hostet, es sei denn, Sie verwenden ältere gespiegelte Warteschlangen. Bei Quorum-Warteschlangen repliziert RabbitMQ Warteschlangendaten über eine Gruppe von Knoten mithilfe eines Konsensprotokolls. Bei Streams werden Daten gemäß der Stream-Konfiguration repliziert. In modernen RabbitMQ-Bereitstellungen sind Quorum-Warteschlangen normalerweise die sicherere Wahl für replizierte, dauerhafte Arbeitswarteschlangen.

Ältere Artikel sprechen oft von "HA-Warteschlangen", als ob dies der moderne Standard wäre. In der RabbitMQ-Terminologie bedeutet dies normalerweise klassische gespiegelte Warteschlangen, die durch Richtlinien konfiguriert werden. Sie existieren in einigen Installationen noch, aber Quorum-Warteschlangen sind die Richtung, die die meisten neuen, dauerhaften replizierten Warteschlangen-Designs in Betracht ziehen sollten. Überprüfen Sie immer die RabbitMQ-Version und die betrieblichen Einschränkungen Ihrer Umgebung, bevor Sie eine vorhandene Arbeitslast migrieren.

Bevor Sie Knoten verbinden

Erledigen Sie zuerst die langweiligen Überprüfungen:

• Knoten müssen die Hostnamen der anderen konsistent auflösen können.
• Der Erlang-Verteilungsport und die RabbitMQ-Ports müssen zwischen den Knoten erreichbar sein.
• RabbitMQ- und Erlang-Versionen sollten im gesamten Cluster kompatibel sein.
• Alle Knoten müssen dasselbe Erlang-Cookie teilen.
• Die Zeitsynchronisation sollte vernünftig sein, insbesondere wenn Ihre Überwachung und TLS davon abhängen.

Das Erlang-Cookie ist ein gemeinsames Geheimnis, das von Erlang-Knoten verwendet wird. Auf vielen Linux-Paketen befindet es sich unter /var/lib/rabbitmq/.erlang.cookie, im Besitz des Benutzers rabbitmq und mit Modus 600.

sudo systemctl stop rabbitmq-server
sudo install -o rabbitmq -g rabbitmq -m 600 .erlang.cookie /var/lib/rabbitmq/.erlang.cookie
sudo systemctl start rabbitmq-server

Regenerieren Sie das Cookie nicht leichtfertig auf einem laufenden Cluster. Wenn ein Knoten ein anderes Cookie hat, kann er nicht mit den anderen kommunizieren, und die Fehlermeldung ist nicht immer freundlich.

Einen Knoten verbinden

Angenommen, rabbit@rmq-a läuft bereits und rabbit@rmq-b soll sich ihm anschließen. Auf rmq-b:

sudo rabbitmqctl stop_app
sudo rabbitmqctl reset
sudo rabbitmqctl join_cluster rabbit@rmq-a
sudo rabbitmqctl start_app

Überprüfen Sie dann von einem beliebigen Knoten:

rabbitmqctl cluster_status
rabbitmq-diagnostics cluster_status

reset entfernt die lokale RabbitMQ-Datenbank des Knotens, bevor er beitritt. Das ist normalerweise das, was Sie für einen neuen leeren Knoten möchten. Es ist nicht etwas, das Sie beiläufig auf einem Knoten ausführen sollten, der Warteschlangen besitzt, die Ihnen wichtig sind.

Wiederholen Sie für drei Knoten denselben Vorgang von rmq-c. Sie können sowohl rmq-b als auch rmq-c mit rmq-a verbinden; sobald sie verbunden sind, gibt es keinen permanenten "Master"-Knoten für Metadaten, wie manche Leute sich das vorstellen.

Clients hinter einen stabilen Endpunkt stellen

Anwendungen sollten keinen fest codierten Broker-Host haben, wenn Sie Knotenwartung erwarten. Verwenden Sie einen Load Balancer, eine DNS-Strategie oder eine Verbindungsliste der Client-Bibliothek. Der Load Balancer sollte überprüfen, ob die RabbitMQ-Anwendung läuft, nicht nur, ob Port 5672 geöffnet ist.

Eine einfache TCP-Überprüfung könnte Clients zu einem Knoten senden, der zwar lebt, aber durch Alarme blockiert oder nicht vollständig verbunden ist. In strengeren Umgebungen verwenden Sie Health Checks, die über das Management-Plugin verfügbar gemacht werden, oder eine kleine lokale Überprüfung, die rabbitmq-diagnostics -q ping ausführt.

Warteschlangentypen bewusst wählen

Für dauerhafte replizierte Arbeitslasten ist eine Quorum-Warteschlange oft eine gute Standardeinstellung:

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

Oder durch Anwendungsdeklaration:

channel.queue_declare(
    queue='orders.pending',
    durable=True,
    arguments={'x-queue-type': 'quorum'}
)

Quorum-Warteschlangen tauschen etwas Durchsatz und Latenz gegen stärkeres Replikationsverhalten. Sie sind kein kostenloses Upgrade für jede Warteschlange. Für temporäre Antwortwarteschlangen, kurzlebige Fanout-Abonnenten oder minderwertige transiente Arbeit können klassische Warteschlangen in Ordnung sein. Für Geschäftsereignisse, die einen Knotenausfall überleben müssen, verwenden Sie einen replizierten Warteschlangentyp und testen Sie das Failover.

Netzwerkpartitionen sind ein betriebliches Ereignis, kein Kontrollkästchen

Eine Netzwerkpartition bedeutet, dass Cluster-Knoten nicht alle miteinander kommunizieren können. RabbitMQ hat Strategien zur Partitionierung, aber keine davon verwandelt ein kaputtes Netzwerk in ein gesundes. Die richtige Antwort ist, den Cluster so zu gestalten, dass Partitionen selten, sichtbar und sorgfältig behoben werden.

Verwenden Sie für die meisten Produktionscluster eine ungerade Anzahl von Knoten für quorumbasierte Arbeitslasten und vermeiden Sie es, einen kleinen Cluster über unzuverlässige Verbindungen zu spannen. Drei Knoten über drei Verfügbarkeitszonen können gut funktionieren, wenn die Latenz akzeptabel ist. Zwei Knoten, die auf zwei Standorte verteilt sind, sind eine häufige Quelle schmerzhafter Entscheidungen, da es keine Mehrheit gibt, wenn die Verbindung unterbrochen wird.

Überprüfen Sie nach einer vermuteten Partition:

rabbitmqctl cluster_status
rabbitmq-diagnostics alarms
rabbitmq-diagnostics check_running
rabbitmqctl list_queues name type leader members online state

Wenn sich Warteschlangen-Leader verschoben haben oder Mitglieder offline gegangen sind, gehen Sie nicht davon aus, dass die Anwendung in Ordnung ist, nur weil die Verbindungen wiederhergestellt wurden. Beobachten Sie Publisher Confirms, Consumer-Fehlerraten und nicht bestätigte Nachrichten.

Wartungsgewohnheiten, die Cluster-Überraschungen verhindern

Trennen Sie nach Möglichkeit Verbindungen, bevor Sie einen Knoten stoppen. Wenn Sie Clients hinter einem Load Balancer haben, entfernen Sie den Knoten aus der Rotation, warten Sie, bis Clients sich anderswo verbinden, und starten Sie dann RabbitMQ neu.

Überprüfen Sie regelmäßig die Warteschlangenverteilung:

rabbitmqctl list_queues name type leader messages consumers

Wenn jeder heiße Warteschlangen-Leader auf einem Knoten sitzt, ist der Cluster für diese Arbeitslast nicht ausgeglichen. Möglicherweise müssen Sie Warteschlangen neu deklarieren, Richtlinien überprüfen oder für Ihre RabbitMQ-Version geeignete Einstellungen für den Warteschlangen-Leader-Locator verwenden.

Halten Sie Richtlinien unter Versionskontrolle. Eine Richtlinie, die den Warteschlangentyp, Dead-Lettering, maximale Länge oder Spiegelungsverhalten ändert, ist Produktionsinfrastruktur, keine UI-Anpassung.

Backups sind immer noch wichtig. Clustering ist kein Ersatz für den Export von Definitionen, Infrastrukturautomatisierung oder die Planung der Notfallwiederherstellung. Exportieren Sie Definitionen nach Topologieänderungen:

rabbitmqadmin export rabbitmq-definitions.json

Testen Sie schließlich den Ausfall, von dem Sie glauben, dass Sie ihn überleben können. Stoppen Sie einen Knoten, der einen Warteschlangen-Leader hält. Töten Sie einen Consumer, während er nicht bestätigte Nachrichten hat. Blockieren Sie einen Publisher während eines Datenträgeralarms in der Staging-Umgebung. Ein RabbitMQ-Cluster verdient Vertrauen durch langweilige Proben, nicht durch ein Diagramm mit drei Knoten darauf.