[ English | English (United Kingdom) | Indonesia | Deutsch | español | русский ]

RabbitMQ-Cluster-Wartung

Ein RabbitMQ-Broker ist eine logische Gruppierung von einem oder mehreren Erlang-Knoten, wobei jeder Knoten die RabbitMQ-Anwendung ausführt und Benutzer, virtuelle Hosts, Warteschlangen, Austausch-, Bindungs- und Laufzeitparameter gemeinsam nutzt. Eine Sammlung von Knoten wird oft als ein cluster bezeichnet. Weitere Informationen zum RabbitMQ-Clustering finden Sie unter RabbitMQ-Cluster.

Innerhalb von OpenStack-Ansible werden alle Daten und Zustände, die für den Betrieb des RabbitMQ-Clusters erforderlich sind, über alle Knoten repliziert, einschließlich der Nachrichtenwarteschlangen, die eine hohe Verfügbarkeit bereitstellen. RabbitMQ-Knoten adressieren sich gegenseitig unter Verwendung von Domainnamen. Die Hostnamen aller Clustermitglieder müssen von allen Clusterknoten auflösbar sein, ebenso wie von allen Maschinen, auf denen CLI-Tools für RabbitMQ verwendet werden können. Es gibt Alternativen, die in restriktiveren Umgebungen funktionieren können. Weitere Informationen zu diesem Setup finden Sie unter Inet-Konfiguration.

Bemerkung

Zur Zeit gibt es einen Ansible Bug in Bezug auf HOSTNAME. Wenn die Host .bashrc eine Variable mit dem Namen HOSTNAME enthält, erbt der Container, an den das lxc_container- Modul angehängt wird, diese Variable und setzt möglicherweise den falschen $HOSTNAME. Siehe the Ansible fix wird in Ansible Version 2.3 veröffentlicht.

Erstellen Sie einen RabbitMQ-Cluster

RabbitMQ-Cluster können auf zwei Arten gebildet werden:

  • Manuell mit rabbitmqctl

  • Deklarativ (Liste der Cluster-Knoten in einer Konfiguration mit rabbitmq-autocluster oder rabbitmq-clusterer Plugins)

Bemerkung

RabbitMQ-Broker können den Ausfall einzelner Knoten innerhalb des Clusters tolerieren. Diese Knoten können beliebig starten und stoppen, solange sie zum Zeitpunkt des Herunterfahrens bereits bekannte Elemente erreichen können.

Es gibt zwei Arten von Knoten, die Sie konfigurieren können: Festplatten- und RAM-Knoten. In den meisten Fällen werden Sie Ihre Knoten als Festplattenknoten verwenden (bevorzugt). Während RAM-Knoten eher eine spezielle Konfiguration in Performance-Clustern sind.

RabbitMQ-Knoten und die CLI-Tools verwenden einen erlang cookie, um zu bestimmen, ob sie die Erlaubnis zur Kommunikation haben oder nicht. Der Cookie ist eine Zeichenfolge aus alphanumerischen Zeichen und kann so kurz oder so lang sein, wie Sie möchten.

Bemerkung

Der Cookie-Wert ist ein gemeinsames Geheimnis und sollte geschützt und privat gehalten werden.

Der Standardspeicherort des Cookies in *nix Umgebungen ist /var/lib/rabbitmq/.erlang.cookie oder in HOME/.erlang.cookie.

Tipp

Wenn Sie bei der Fehlerbehebung feststellen, dass ein Knoten sich weigert, dem Cluster beizutreten, sollten Sie unbedingt prüfen, ob das Erlang-Cookie mit den anderen Knoten übereinstimmt. Wenn der Cookie falsch konfiguriert ist (zum Beispiel nicht identisch ist), protokolliert RabbitMQ Fehler wie „Verbindungsversuch von nicht zugelassenem Knoten“ und „Konnte nicht automatisch clustern“. Siehe Clustering für weitere Informationen.

Um einen RabbitMQ-Cluster zu bilden, beginnen Sie mit unabhängigen RabbitMQ-Brokern und konfigurieren diese Knoten in einer Cluster-Konfiguration neu.

Bei Verwendung eines 3-Knoten-Beispiels würden Sie den Knoten 2 und 3 mitteilen, dass sie dem Cluster des ersten Knotens beitreten.

  1. Melden Sie sich am 2. und 3. Knoten an und stoppen Sie die Anwendung rabbitmq.

  2. Treten Sie dem Cluster bei und starten Sie die Anwendung neu:

    rabbit2$ rabbitmqctl stop_app
Stopping node rabbit@rabbit2 ...done.
rabbit2$ rabbitmqctl join_cluster rabbit@rabbit1
Clustering node rabbit@rabbit2 with [rabbit@rabbit1] ...done.
rabbit2$ rabbitmqctl start_app
Starting node rabbit@rabbit2 ...done.

Überprüfen Sie den RabbitMQ-Clusterstatus

  1. Führen Sie rabbitmqctl cluster_status von jedem Knoten aus.

Sie werden sehen, dass rabbit1 und rabbit2 beide laufen wie zuvor.

Der Unterschied besteht darin, dass der Clusterstatusabschnitt der Ausgabe beide Knoten jetzt zusammen gruppiert:

rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2]}]},
{running_nodes,[rabbit@rabbit2,rabbit@rabbit1]}]
...done.

Um den dritten RabbitMQ-Knoten dem Cluster hinzuzufügen, wiederholen Sie den obigen Vorgang, indem Sie die Anwendung rabbitmq auf dem dritten Knoten stoppen.

  1. Treten Sie dem Cluster bei und starten Sie die Anwendung auf dem dritten Knoten neu.

  2. Führen Sie rabbitmq cluster_status aus, um alle 3 Knoten zu sehen:

    rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2,rabbit@rabbit3]}]},
 {running_nodes,[rabbit@rabbit3,rabbit@rabbit2,rabbit@rabbit1]}]
...done.

Stoppen und starten Sie einen RabbitMQ-Cluster neu

Beachten Sie die Reihenfolge, in der Sie die Knoten heruntergefahren haben, um den Cluster zu stoppen und zu starten. Der letzte Knoten, den Sie stoppen, muss der erste Knoten sein, den Sie starten. Dieser Knoten ist der master.

Wenn Sie die Knoten in der falschen Reihenfolge starten, könnten Sie auf ein Problem stoßen, bei dem der aktuelle master nicht der Master ist und die Nachrichten ablegt, um sicherzustellen, dass keine neuen Nachrichten in die Warteschlange gestellt werden, während der echte Master ausgefallen ist.

RabbitMQ und Mnesia

Mnesia ist eine verteilte Datenbank, in der RabbitMQ Informationen zu Benutzern, Austauschknoten, Warteschlangen und Bindungen speichert. Nachrichten werden jedoch nicht in der Datenbank gespeichert.

Weitere Informationen zu Mnesia finden Sie in der Übersicht Mnesia.

Um die Positionen wichtiger Rabbit-Dateien anzuzeigen, siehe Dateispeicherorte.

Reparieren Sie einen partitionierten RabbitMQ-Cluster für einen einzelnen Knoten

Aus irgendeinem Grund in Ihrer Umgebung verlieren Sie wahrscheinlich einen Knoten in Ihrem Cluster. In diesem Szenario führen mehrere LXC-Container auf demselben Host Rabbit aus und befinden sich in einem einzelnen Rabbit-Cluster.

Wenn der Host weiterhin als Teil des Clusters angezeigt wird, aber nicht ausgeführt wird, führen Sie Folgendes aus:

# rabbitmqctl start_app

Möglicherweise stellen Sie jedoch einige Probleme mit Ihrer Anwendung fest, da Clients möglicherweise versuchen, Nachrichten an den nicht reagierenden Knoten zu senden. Um dies zu beheben, vergessen Sie den Knoten aus dem Cluster, indem Sie Folgendes ausführen:

  1. Stellen Sie sicher, dass RabbitMQ nicht auf dem Knoten ausgeführt wird:

    # rabbitmqctl stop_app

  2. Führen Sie auf dem Rabbit2-Knoten Folgendes aus:

    # rabbitmqctl forget_cluster_node rabbit@rabbit1

Dadurch kann der Cluster weiterhin effektiv ausgeführt werden, und Sie können den fehlerhaften Knoten reparieren.

Wichtig

Achten Sie darauf, wenn Sie den Knoten neu starten, er wird immer noch denken, dass er Teil des Clusters ist, und Sie müssen den Knoten zurücksetzen. Nach dem Zurücksetzen sollten Sie in der Lage sein, sich bei Bedarf an andere Knoten anzuschließen.

rabbit1$ rabbitmqctl start_app
Starting node rabbit@rabbit1 ...

Error: inconsistent_cluster: Node rabbit@rabbit1 thinks it's clustered
       with node rabbit@rabbit2, but rabbit@rabbit2 disagrees

rabbit1$ rabbitmqctl reset
Resetting node rabbit@rabbit1 ...done.
rabbit1$ rabbitmqctl start_app
Starting node rabbit@mcnulty ...
...done.

Reparieren Sie einen partitionierten RabbitMQ-Cluster für einen Cluster mit mehreren Knoten

Die gleichen Konzepte gelten für einen Cluster mit mehreren Knoten, der in einem Cluster mit einem einzelnen Knoten vorhanden ist. Der einzige Unterschied besteht darin, dass die verschiedenen Knoten tatsächlich auf verschiedenen Hosts ausgeführt werden. Die wichtigsten Punkte, die Sie bei einem Multi-Node-Cluster beachten sollten, sind:

  • Wenn der gesamte Cluster heruntergefahren wird, muss der letzte Knoten, der heruntergefahren werden soll, der erste Knoten sein, der online geschaltet werden soll. Wenn dies nicht geschieht, warten die Knoten 30 Sekunden, bis der letzte Plattenknoten wieder online ist, und scheitern danach.

    Wenn der letzte Knoten, der offline gehen soll, nicht wiederhergestellt werden kann, kann er mit dem Kommando forget_cluster_node aus dem Cluster entfernt werden.

  • Wenn alle Clusterknoten gleichzeitig und unkontrolliert anhalten (z. B. bei einem Stromausfall), können Sie eine Situation erhalten, in der alle Knoten denken, dass ein anderer Knoten nach ihnen gestoppt wurde. In diesem Fall können Sie den Befehl force_boot auf einem Knoten verwenden, um ihn wieder bootfähig zu machen.

Weitere Informationen finden Sie in der Manpage rabbitmqctl.