Wartungsaufgaben¶

Dieses Kapitel ist für OpenStack-spezifische Wartungsaufgaben gedacht.

Galera-Cluster-Wartung¶

Die routinemäßige Wartung umfasst das Hinzufügen oder Entfernen von Knoten aus dem Cluster ohne Auswirkungen auf den Betrieb und das Starten eines Clusters nach dem ordnungsgemäßen Herunterfahren aller Knoten.

MySQL-Instanzen werden beim Erstellen eines Clusters neu gestartet, wenn ein Knoten hinzugefügt wird, wenn der Dienst nicht ausgeführt wird oder wenn Änderungen an der Konfigurationsdatei /etc/mysql/my.cnf vorgenommen werden.

Überprüfen Sie den Clusterstatus¶

Vergleichen Sie die Ausgabe des folgenden Befehls mit der folgenden Ausgabe. Es sollte Ihnen Informationen über den Status Ihres Clusters geben.

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (2)

node2_galera_container-49a47d25 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (2)

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     7
wsrep_cluster_size        1
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

In diesem Beispiel hat nur ein Knoten geantwortet.

Wenn der MariaDB-Dienst auf allen außer einem Knoten ordnungsgemäß heruntergefahren wird, kann der verbleibende operative Knoten SQL-Anforderungen weiter verarbeiten. Wenn Sie mehrere Knoten ordnungsgemäß herunterfahren, führen Sie die Aktionen nacheinander aus, um den Vorgang beizubehalten.

Starten Sie einen Cluster¶

Wenn Sie alle Knoten ordnungsgemäß herunterfahren, wird der Cluster zerstört. Das Starten oder Neustarten eines Clusters von null Knoten erfordert das Erstellen eines neuen Clusters auf einem der Knoten.

Starten Sie einen neuen Cluster auf dem am weitesten fortgeschrittenen Knoten. Wechseln Sie in das Verzeichnis playbooks und überprüfen Sie den Wert seqno in der Datei grastate.dat auf allen Knoten:

# ansible galera_container -m shell -a "cat /var/lib/mysql/grastate.dat"
node2_galera_container-49a47d25 | success | rc=0 >>
# GALERA saved state version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   31
cert_index:

node3_galera_container-3ea2cbd3 | success | rc=0 >>
# GALERA saved state version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   31
cert_index:

node4_galera_container-76275635 | success | rc=0 >>
# GALERA saved state version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   31
cert_index:

In diesem Beispiel enthalten alle Knoten im Cluster die gleichen positiven seqno-Werte wie sie vor dem ordnungsgemäßen Herunterfahren synchronisiert wurden. Wenn alle seqno-Werte gleich sind, kann jeder Knoten den neuen Cluster starten.

## for init
# /etc/init.d/mysql start --wsrep-new-cluster
## for systemd
# systemctl set-environment _WSREP_NEW_CLUSTER='--wsrep-new-cluster'
# systemctl start mysql
# systemctl set-environment _WSREP_NEW_CLUSTER=''

Bitte sehen Sie sich auch Upstream Starten einer Clusterseite

Dies kann auch mit Hilfe von ansible mit dem Shell-Modul erfolgen:

# ansible galera_container -m shell -a "/etc/init.d/mysql start --wsrep-new-cluster" --limit galera_container[0]

Dieser Befehl führt zu einem Cluster, das einen einzelnen Knoten enthält. Der Wert wsrep_cluster_size gibt die Anzahl der Knoten im Cluster an.

node2_galera_container-49a47d25 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (2)

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     1
wsrep_cluster_size        1
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Starten Sie MariaDB auf den anderen Knoten neu (ersetzen Sie [0] von dem vorherigen Befehl ansible mit [1:]), und vergewissern Sie sich, dass sie dem Cluster wieder beitreten.

node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     3
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node3_galera_container-3ea2cbd3 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     3
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     3
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Galera-Cluster-Wiederherstellung¶

Run the openstack.osa.galera_server playbook using the galera_force_bootstrap variable to automatically recover a node or an entire environment.

Führen Sie den folgenden Ansible-Befehl aus, um die ausgefallenen Knoten anzuzeigen:

# openstack-ansible openstack.osa.galera_server -e galera_force_bootstrap=True --tags galera_server-config

You can additionally define a different bootstrap node through galera_server_bootstrap_node variable, in case current bootstrap node is in desynced/broken state. You can check what node is currently selected for bootstrap using this ad-hoc:

root@aio1:/opt/openstack-ansible# ansible -m debug -a var="groups['galera_all'][0]" localhost

Der Cluster kommt zurück nach Ausführung dieses Kommandos. Wenn es fehlschlägt, schauen Sie restarting the cluster und recovering the primary component in der Galera Dokumentation, denn sie ist zur Wiederherstellung eines Clusters von unschätzbarem Wert.

Wiederherstellen eines Einzelknotenfehlers¶

Wenn ein einzelner Knoten fehlschlägt, behalten die anderen Knoten das Quorum und verarbeiten weiterhin SQL-Anforderungen.

Wechseln Sie in das Verzeichnis playbooks und führen Sie den folgenden Ansible-Befehl aus, um den ausgefallenen Knoten zu bestimmen:

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server through
socket '/var/run/mysqld/mysqld.sock' (111)

node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

In diesem Beispiel ist Knoten 3 fehlgeschlagen.

Starten Sie MariaDB auf dem fehlgeschlagenen Knoten neu, und vergewissern Sie sich, dass es erneut dem Cluster beitritt.
Wenn MariaDB nicht gestartet werden kann, führen Sie den Befehl mysqld aus und führen Sie eine weitere Analyse der Ausgabe durch. Als letzten Ausweg erstellen Sie den Container für den Knoten neu.

Stellen Sie einen Fehler mit mehreren Knoten wieder her¶

Wenn alle Knoten bis auf einen Knoten fehlschlagen, kann der verbleibende Knoten das Quorum nicht erreichen und die Verarbeitung von SQL-Anfragen beendet werden. In diesem Fall können ausgefallene Knoten, die wiederhergestellt werden, dem Cluster nicht beitreten, da er nicht mehr vorhanden ist.

Führen Sie den folgenden Ansible-Befehl aus, um die ausgefallenen Knoten anzuzeigen:

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node2_galera_container-49a47d25 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     18446744073709551615
wsrep_cluster_size        1
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      non-Primary

In diesem Beispiel sind die Knoten 2 und 3 fehlerhaft. Der verbleibende betriebsfähige Server zeigt non-Primary an, da er das Quorum nicht erreichen kann.

Führen Sie den folgenden Befehl aus, zur Wiederaufnahme der operative Knoten in den Cluster:

# mysql -e "SET GLOBAL wsrep_provider_options='pc.bootstrap=yes';"
node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     15
wsrep_cluster_size        1
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

node2_galera_container-49a47d25 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

Der verbleibende operative Knoten wird zum primären Knoten und beginnt mit der Verarbeitung von SQL-Anfragen.

Starten Sie MariaDB auf den ausgefallenen Knoten neu und vergewissern Sie sich, dass sie dem Cluster wieder beitreten:

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node3_galera_container-3ea2cbd3 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Wenn MariaDB auf einem der ausgefallenen Knoten nicht gestartet werden kann, führen Sie den Befehl mysqld aus und führen Sie eine weitere Analyse der Ausgabe durch. Als letzten Ausweg erstellen Sie den Container für den Knoten neu.

Wiederherstellen eines vollständigen Umgebungsfehlers¶

Von der Sicherung wiederherstellen, wenn alle Knoten in einem Galera-Cluster fehlschlagen (nicht ordnungsgemäß herunterfahren). Wechseln Sie in das Verzeichnis playbook und führen Sie den folgenden Befehl aus, um festzustellen, ob alle Knoten im Cluster ausgefallen sind:

# ansible galera_container -m shell -a "cat /var/lib/mysql/grastate.dat"
node3_galera_container-3ea2cbd3 | success | rc=0 >>
# GALERA saved state
version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   -1
cert_index:

node2_galera_container-49a47d25 | success | rc=0 >>
# GALERA saved state
version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   -1
cert_index:

node4_galera_container-76275635 | success | rc=0 >>
# GALERA saved state
version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   -1
cert_index:

Alle Knoten sind fehlgeschlagen, wenn mysqld auf keinem der Knoten läuft und alle Knoten einen seqno Wert von -1 enthalten.

Wenn ein einzelner Knoten einen positiven Wert seqno hat, kann dieser Knoten zum Neustarten des Clusters verwendet werden. Da jedoch nicht garantiert werden kann, dass jeder Knoten über eine identische Kopie der Daten verfügt, wird nicht empfohlen, den Cluster mit dem Befehl --wsrep-new-cluster auf einem Knoten neu zu starten.

Erstellen Sie einen Container neu¶

Das Wiederherstellen bestimmter Fehler erfordert die Neuerstellung eines oder mehrerer Container.

Deaktivieren Sie den ausgefallenen Knoten im Lastenausgleichsmodul.

Bemerkung

Verlassen Sie sich nicht auf die Systemüberprüfungen für den Lastenausgleich, um den Knoten zu deaktivieren. Wenn der Knoten nicht inaktiviert ist, sendet der Load Balancer SQL-Anforderungen an ihn, bevor er dem Cluster wieder beitritt und Dateninkonsistenzen verursacht.
Zerstören Sie den Container und entfernen Sie MariaDB-Daten, die außerhalb des Containers gespeichert sind:
```
# openstack-ansible openstack.osa.containers_lxc_destroy \
-l node3_galera_container-3ea2cbd3
```
In diesem Beispiel ist Knoten 3 fehlgeschlagen.
Führen Sie das Host-Setup-Playbook aus, um den Container auf Knoten 3 neu zu erstellen:
```
# openstack-ansible oopenstack.osa.containers_lxc_create -l node3 \
-l node3_galera_container-3ea2cbd3
```
Das Playbook startet alle anderen Container auf dem Knoten neu.

Führen Sie das Infrastruktur-Playbook aus, um den Container speziell auf Knoten 3 zu konfigurieren:

# openstack-ansible openstack.osa.setup_infrastructure \
--limit node3_galera_container-3ea2cbd3

Warnung

Der neue Container führt einen Galera-Cluster mit einem einzelnen Knoten aus. Dies ist ein gefährlicher Zustand, da die Umgebung mehr als eine aktive Datenbank mit möglicherweise unterschiedlichen Daten enthält.

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node3_galera_container-3ea2cbd3 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     1
wsrep_cluster_size        1
wsrep_cluster_state_uuid  da078d01-29e5-11e4-a051-03d896dbdb2d
wsrep_cluster_status      Primary

node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     4
wsrep_cluster_size        2
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     4
wsrep_cluster_size        2
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Starten Sie MariaDB in dem neuen Container neu, und vergewissern Sie sich, dass es erneut dem Cluster beitritt.

Bemerkung

In größeren Bereitstellungen kann es einige Zeit dauern, bis der MariaDB-Daemon im neuen Container gestartet wird. Während dieser Zeit werden die Daten von den anderen MariaDB-Servern synchronisiert. Sie können den Status während dieses Vorgangs überwachen, indem Sie die Protokolldatei /var/log/mysql_logs/galera_server_error.log protokollieren.

Zeilen, die mit WSREP_SST beginnen, werden während des Synchronisationsprozesses angezeigt und Sie sollten eine Zeile mit WSREP: SST complete, seqno: <NUMBER> sehen, wenn die Synchronisierung erfolgreich war.

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     5
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node3_galera_container-3ea2cbd3 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     5
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     5
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Aktivieren Sie den zuvor fehlgeschlagenen Knoten im Lastenausgleich.

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.

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

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¶

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.

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

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:

Stellen Sie sicher, dass RabbitMQ nicht auf dem Knoten ausgeführt wird:
```
# rabbitmqctl stop_app
```

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.

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.

Lauf Ad-hoc Ansible spielt¶

Being familiar with running ad-hoc Ansible commands is helpful when operating your OpenStack-Ansible deployment. For a review, we can look at the structure of the following ansible command:

$ ansible example_group -m shell -a 'hostname'

This command calls on Ansible to run the example_group using the -m shell module with the -a argument which is the hostname command. You can substitute example_group for any groups you may have defined. For example, if you had compute_hosts in one group and infra_hosts in another, supply either group name and run the command. You can also use the * wild card if you only know the first part of the group name, for instance if you know the group name starts with compute you would use compute_h*. The -m argument is for module.

Modules can be used to control system resources or handle the execution of system commands. For more information about modules, see Module Index and About Modules.

If you need to run a particular command against a subset of a group, you could use the limit flag -l. For example, if a compute_hosts group contained compute1, compute2, compute3, and compute4, and you only needed to execute a command on compute1 and compute4 you could limit the command as follows:

$ ansible example_group -m shell -a 'hostname' -l compute1,compute4

Bemerkung

Jeder Host ist durch Kommas getrennt ohne Leerzeichen.

Bemerkung

Führen Sie die Ad-hoc-Ansible-Befehle aus dem Verzeichnis openstack-ansible/playbooks aus.

Weitere Informationen finden Sie unter Inventar und Muster.

Das Shell-Modul ausführen¶

Die zwei am häufigsten verwendeten Module sind die shell und copy-Module. Das shell-Modul übernimmt den Befehlsnamen, gefolgt von einer Liste von durch Leerzeichen getrennten Argumenten. Es ist fast wie das Befehlsmodul, aber führt den Befehl durch eine Shell (/bin/sh) auf dem Remote-Knoten.

Mit dem Shell-Modul können Sie beispielsweise den Speicherplatz auf einer Gruppe von Compute-Hosts prüfen:

$ ansible compute_hosts -m shell -a 'df -h'

So überprüfen Sie den Status Ihres Galera-Clusters:

$ ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"

Wenn ein Modul als ad-hoc Kommando verwendet wird, werden ein paar Parameter nicht benötigt. Zum Beispiel, für das chdir Kommando ist kein chdir=/home/user ls notwendig, wenn Ansible von CLI aufgerufen wird:

$ ansible compute_hosts -m shell -a 'ls -la /home/user'

Weitere Informationen finden Sie unter Shell - Befehle in Knoten ausführen.

Das Kopiermodul ausführen¶

The copy module copies a file on a local machine to remote locations. To copy files from remote locations to the local machine you would use the fetch module. If you need variable interpolation in copied files, use the template module. For more information, see copy - Copies files to remote locations.

Das folgende Beispiel zeigt, wie Sie eine Datei von Ihrem Deployment-Host in das Verzeichnis /tmp auf einer Gruppe entfernter Maschinen verschieben:

$ ansible remote_machines -m copy -a 'src=/root/FILE '\
'dest=/tmp/FILE'

The fetch module gathers files from remote machines and stores the files locally in a file tree, organized by the hostname from remote machines and stores them locally in a file tree, organized by hostname.

Bemerkung

Dieses Modul überträgt Protokolldateien, die möglicherweise nicht vorhanden sind, so dass eine fehlende Remote-Datei kein Fehler ist, es sei denn, fail_on_missing ist auf yes gesetzt.

Die folgenden Beispiele zeigen die Datei nova-compute.log, die von einem einzelnen Compute-Host abgerufen wird:

root@libertylab:/opt/rpc-openstack/openstack-ansible/playbooks# ansible compute_hosts -m fetch -a 'src=/var/log/nova/nova-compute.log dest=/tmp'
aio1 | success >> {
    "changed": true,
    "checksum": "865211db6285dca06829eb2215ee6a897416fe02",
    "dest": "/tmp/aio1/var/log/nova/nova-compute.log",
    "md5sum": "dbd52b5fd65ea23cb255d2617e36729c",
    "remote_checksum": "865211db6285dca06829eb2215ee6a897416fe02",
    "remote_md5sum": null
}

root@libertylab:/opt/rpc-openstack/openstack-ansible/playbooks# ls -la /tmp/aio1/var/log/nova/nova-compute.log
-rw-r--r-- 1 root root 2428624 Dec 15 01:23 /tmp/aio1/var/log/nova/nova-compute.log

Verwenden von Tags¶

Tags are similar to the limit flag for groups, except tags are used to only run specific tasks within a playbook. For more information on tags, see Tags and Understanding ansible tags.

Ansible Forks¶

Die Standardeinstellung für MaxSessions für den OpenSSH-Daemon ist 10. Jeder Ansible-Fork verwendet eine Sitzung. Standardmäßig legt Ansible die Anzahl der Forks auf 5 fest. Sie können jedoch die Anzahl der verwendeten Forks erhöhen, um die Bereitstellungsleistung in großen Umgebungen zu verbessern.

Beachten Sie, dass mehr als 10 Forks Probleme bei allen Playbooks verursachen, die delegate_to oder local_action in den Aufgaben verwenden. Es wird empfohlen, die Anzahl der Forks bei der Ausführung in der Steuerungsebene nicht zu erhöhen, da hier die Delegierung am häufigsten verwendet wird.

Die Anzahl der verwendeten Forks kann permanent geändert werden, indem die entsprechende Änderung an den ANSIBLE_FORKS in Ihrer Datei .bashrc vorgenommen wird. Alternativ kann es für eine bestimmte Playbook-Ausführung geändert werden, indem der CLI-Parameter --forks verwendet wird. Das folgende Beispiel führt das Nova-Playbook gegen die Kontrollebene mit 10 Forks und dann gegen die Rechenknoten mit 50 Forks aus.

# openstack-ansible --forks 10 os-nova-install.yml --limit compute_containers
# openstack-ansible --forks 50 os-nova-install.yml --limit compute_hosts

Weitere Informationen zu Forks finden Sie in den folgenden Referenzen:

OpenStack-Ansible Bug 1479812
Ansible forks Eintrag für ansible.cfg
Ansible Performance Tuning

Container-Verwaltung¶

With Ansible, the OpenStack installation process is entirely automated using playbooks written in YAML. After installation, the settings configured by the playbooks can be changed and modified. Services and containers can shift to accommodate certain environment requirements. Scaling services are achieved by adjusting services within containers, or adding new deployment groups. It is also possible to destroy containers, if needed, after changes and modifications are complete.

Skalieren Sie einzelne Dienste¶

Einzelne OpenStack-Dienste und andere Open-Source-Projektdienste werden in Containern ausgeführt. Es ist möglich, diese Dienste zu skalieren, indem Sie die Datei /etc/openstack_deploy/openstack_user_config.yml modifizieren.

Navigieren Sie in die Datei /etc/openstack_deploy/openstack_user_config.yml.
Greifen Sie auf den Deployment-Gruppen-Abschnitt der Konfigurationsdatei zu. Fügen Sie unter dem Namen der Bereitstellungsgruppe eine Affinity-Wertlinie zu OpenSack-Services für Container-Maßstäbe hinzu:
```
infra_hosts:
  infra1:
    ip: 10.10.236.100
    # Rabbitmq
    affinity:
      galera_container: 1
      rabbit_mq_container: 2
```
In diesem Beispiel hat galera_container einen Container-Wert von eins. In der Praxis können alle Container, die keine Anpassung benötigen, auf dem Standardwert von eins bleiben und sollten nicht über oder unter den Wert eins gesetzt werden.

Der Affinitätswert für jeden Container ist standardmäßig auf eins festgelegt. Passen Sie den Affinitätswert für Situationen auf Null an, in denen die OpenStack-Dienste in einem bestimmten Container beim Skalieren anderer erforderlicher Dienste nicht benötigt werden.
Aktualisieren Sie die Containernummer, die unter der Konfiguration affinity aufgeführt ist, auf die gewünschte Nummer. Das obige Beispiel hat galera_container auf eins und rabbit_mq_container auf zwei gesetzt, was die RabbitMQ-Dienste skaliert, aber die Galera-Dienste nicht verändert.
Führen Sie die entsprechenden Playbook-Befehle aus, nachdem Sie die Konfiguration geändert haben, um die neuen Container zu erstellen, und installieren Sie die entsprechenden Dienste.

Führen Sie beispielsweise die Befehle openstack-ansible lxc-containers-create.yml rabbitmq-install.yml aus dem Repository openstack-ansible/playbooks aus, um den im obigen Beispiel beschriebenen Skalierungsprozess abzuschließen:
```
$ cd openstack-ansible/playbooks
$ openstack-ansible lxc-containers-create.yml rabbitmq-install.yml
```

Zerstören und Neuerstellen von Containern¶

Das Beheben einiger Probleme erfordert möglicherweise das Zerstören eines Containers und das erneute Erstellen des Containers von Anfang an. Mit den Befehlen lxc-containers-destroy.yml und lxc-containers-create.yml kann ein Container gelöscht und neu erstellt werden. Diese Ansible-Skripte befinden sich im Repository openstack-ansible/playbooks.

Navigieren Sie zum Verzeichnis openstack-ansible.

Führen Sie die Befehle openstack-ansible lxc-containers-destroy.yml aus und geben Sie die Zielcontainer und den zu zerstörenden Container an.

$ openstack-ansible lxc-containers-destroy.yml --limit "CONTAINER_NAME"
$ openstack-ansible lxc-containers-create.yml --limit "CONTAINER_NAME"

Ersetzen Sie ``CONTAINER_NAME`` mit dem Zielcontainer.

Firewalls¶

OpenStack-Ansible does not configure firewalls for its infrastructure. It is up to the deployer to define the perimeter and its firewall configuration.

Standardmäßig stützt sich OpenStack-Ansible auf Ansible-SSH-Verbindungen und benötigt den TCP-Port 22, um intern auf allen Hosts geöffnet zu werden.

For more information on generic OpenStack firewall configuration, see the Firewalls and default ports

In each of the role’s respective documentatione you can find the default variables for the ports used within the scope of the role. Reviewing the documentation allow you to find the variable names if you want to use a different port.

Bemerkung

Die OpenStack-Ansible Group Vars stellt die Variablen außerhalb von Rollenziel für den Fall, dass Sie auf die OpenStack-Ansible-Gruppen angewiesen sind, um Ihre Firewall zu konfigurieren.

Suchen nach Ports für Ihren externen Load Balancer¶

As explained in the previous section, you can find (in each roles documentation) the default variables used for the public interface endpoint ports.

Zum Beispiel die os_glance documentation listet die Variable glance_service_publicuri. Diese beinhaltet den Port zur Erreichung des Dienstes extern. In diesem Beispiel ist es gleich dem glance_service_port, welcher den Wert 9292 hat.

As a hint, you could find the list of all public URI defaults by executing the following:

cd /etc/ansible/roles
grep -R -e publicuri -e port *

Bemerkung

Haproxy kann mit OpenStack-Ansible konfiguriert werden. Die automatisch erzeugte Datei /etc/haproxy/haproxy.cfg verfügt über genügend Informationen über die Ports, die Sie für Ihre Umgebung öffnen können.

Inventar-Backup-Archiv bereinigen¶

Das Inventar-Backup-Archiv muss über einen ausreichend langen Zeitraum gewartet werden.

Massenschnitt¶

It is possible to do mass pruning of the inventory backup. The following example will prune all but the last 15 inventories from the running archive.

ARCHIVE="/etc/openstack_deploy/backup_openstack_inventory.tar"
tar -tvf ${ARCHIVE} | \
  head -n -15 | awk '{print $6}' | \
  xargs -n 1 tar -vf ${ARCHIVE} --delete

Selektives Beschneiden¶

To prune the inventory archive selectively, first identify the files you wish to remove by listing them out.

tar -tvf /etc/openstack_deploy/backup_openstack_inventory.tar

-rw-r--r-- root/root    110096 2018-05-03 10:11 openstack_inventory.json-20180503_151147.json
-rw-r--r-- root/root    110090 2018-05-03 10:11 openstack_inventory.json-20180503_151205.json
-rw-r--r-- root/root    110098 2018-05-03 10:12 openstack_inventory.json-20180503_151217.json

Löschen Sie jetzt das Zielinventararchiv.

tar -vf /etc/openstack_deploy/backup_openstack_inventory.tar --delete openstack_inventory.json-20180503_151205.json

Wartungsaufgaben

Wartungsaufgaben¶

Galera-Cluster-Wartung¶

Überprüfen Sie den Clusterstatus¶

Starten Sie einen Cluster¶

Galera-Cluster-Wiederherstellung¶

Wiederherstellen eines Einzelknotenfehlers¶

Stellen Sie einen Fehler mit mehreren Knoten wieder her¶

Wiederherstellen eines vollständigen Umgebungsfehlers¶

Erstellen Sie einen Container neu¶

RabbitMQ-Cluster-Wartung¶

Erstellen Sie einen RabbitMQ-Cluster¶

Überprüfen Sie den RabbitMQ-Clusterstatus¶

Stoppen und starten Sie einen RabbitMQ-Cluster neu¶

RabbitMQ und Mnesia¶

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

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

Migrate between HA and Quorum queues¶

Lauf Ad-hoc Ansible spielt¶

Das Shell-Modul ausführen¶

Das Kopiermodul ausführen¶

Verwenden von Tags¶

Ansible Forks¶

Container-Verwaltung¶

Skalieren Sie einzelne Dienste¶

Zerstören und Neuerstellen von Containern¶

Firewalls¶

Suchen nach Ports für Ihren externen Load Balancer¶

Inventar-Backup-Archiv bereinigen¶

Massenschnitt¶

Selektives Beschneiden¶

openstack-ansible 30.0.0.0rc2.dev5

Page Contents