[ English | русский | español | English (United Kingdom) | Deutsch | Indonesia ]
Wartungsaufgaben¶
Dieses Kapitel ist für OpenStack-spezifische Wartungsaufgaben gedacht.
[ English | русский | español | English (United Kingdom) | Deutsch | Indonesia ]
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 Wertseqno
in der Dateigrastate.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 alleseqno
-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 mitWSREP: 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.
[ English | русский | español | English (United Kingdom) | Deutsch | Indonesia ]
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
oderrabbitmq-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.
[ English | русский | español | English (United Kingdom) | Deutsch | Indonesia ]
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
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
[ English | русский | español | English (United Kingdom) | Deutsch | Indonesia ]
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 hatgalera_container
auf eins undrabbit_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.
[ English | русский | español | English (United Kingdom) | Deutsch | Indonesia ]
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.
[ English | русский | español | English (United Kingdom) | Deutsch | Indonesia ]
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