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

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.

Within OpenStack-Ansible, all data and states required for operation of the RabbitMQ cluster is replicated across all nodes including the message queues providing high availability. RabbitMQ nodes address each other using domain names. The hostnames of all cluster members must be resolvable from all cluster nodes, as well as any machines where CLI tools related to RabbitMQ might be used. There are alternatives that may work in more restrictive environments. For more details on that setup, see Inet Configuration.

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. Login to the 2nd and 3rd node and stop the RabbitMQ application.

  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 and 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.

For more information about Mnesia, see the Mnesia overview.

To view the locations of important RabbitMQ files, see File Locations.

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

Invariably due to something in your environment, you are likely to lose a node in your cluster. In this scenario, multiple LXC containers on the same host are running RabbitMQ and are in a single RabbitMQ 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. On the RabbitMQ second node, execute:

    # 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.

Migrate between HA and Quorum queues

In the 2024.1 (Caracal) release OpenStack-Ansible switches to use RabbitMQ Quorum Queues by default, rather than the legacy High Availability classic queues. Migration to Quorum Queues can be performed at upgrade time, but may result in extended control plane downtime as this requires all OpenStack services to be restarted with their new configuration.

In order to speed up the migration, the following playbooks can be run to migrate either to or from Quorum Queues, whilst skipping package install and other configuration tasks. These tasks are available from the 2024.1 release onwards.

$ openstack-ansible openstack.osa.rabbitmq_server --tags rabbitmq-config
$ openstack-ansible openstack.osa.setup_openstack --tags common-mq,post-install

In order to take advantage of these steps, we suggest setting oslomsg_rabbit_quorum_queues to False before upgrading to 2024.1. Then, once you have upgraded, set oslomsg_rabbit_quorum_queues back to the default of True and run the playbooks above.