Skalieren Sie Ihre Umgebung¶

Dies ist eine Entwurfsumgebungsskalierungsseite für den vorgeschlagenen OpenStack-Ansible-Betriebshandbuch.

Fügen Sie einen neuen Infrastrukturhost hinzu¶

Obwohl drei Infrastrukturhosts empfohlen werden, können weitere Knoten erstellt werden, wenn weitere Hosts in einer Umgebung benötigt werden.

Warnung

Stellen Sie sicher, dass Sie Ihre aktuelle OpenStack-Umgebung sichern, bevor Sie neue Knoten hinzufügen. Siehe Sichern und Wiederherstellen Ihrer Cloud für weitere Informationen.

Fügen Sie den Knoten der Zeilengruppe infra_hosts der Datei /etc/openstack_deploy/openstack_user_config.yml hinzu
```
infra_hosts:
[...]
  infra<node-ID>:
    ip: 10.17.136.32
```
Wechseln Sie in den Playbook-Ordner auf dem Bereitstellungshost.
```
# cd /opt/openstack-ansible
```

To prepare new hosts and deploy containers on them run setup-hosts.yml playbook with the limit argument.

# openstack-ansible openstack.osa.setup_hosts --limit localhost,infra<node-ID>,infra<node-ID>-host_containers

In case you’re relying on /etc/hosts content, you should also update it for all hosts

# openstack-ansible openstack.osa.openstack_hosts_setup -e openstack_hosts_group=all --tags openstack_hosts-file

Next we need to expand galera/rabbitmq clusters, which is done during setup-infrastructure.yml. So we will run this playbook without limits.
Warnung

Make sure that containers from new infra host does not appear in inventory as first one for groups galera_all, rabbitmq_all and repo_all. You can varify that with ad-hoc commands:
```
# ansible -m debug -a "var=groups['galera_all'][0]" localhost
# ansible -m debug -a "var=groups['rabbitmq_all'][0]" localhost
# ansible -m debug -a "var=groups['repo_all'][0]" localhost
```
```
# openstack-ansible openstack.osa.setup_infrastructure -e galera_force_bootstrap=true
```
Once infrastructure playboks are done, it’s turn of openstack services to be deployed. Most of the services are fine to be ran with limits, but some, like keystone, are not. So we run keystone playbook separately from all others:
```
# openstack-ansible openstack.osa.keystone
# openstack-ansible openstack.osa.setup_openstack --limit '!keystone_all',localhost,infra<node-ID>,infra<node-ID>-host_containers
```

Testen Sie neue Infra-Knoten¶

Überprüfen Sie nach dem Erstellen eines neuen Infra-Knotens, ob der Knoten ordnungsgemäß ausgeführt wird, indem Sie eine neue Instanz starten. Stellen Sie sicher, dass der neue Knoten auf einen Netzwerkverbindungstest mit dem Befehl ping reagieren kann. Melden Sie sich bei Ihrem Überwachungssystem an und vergewissern Sie sich, dass die Monitore ein grünes Signal für den neuen Knoten zurückgeben.

Fügen Sie einen Computer-Host hinzu¶

Verwenden Sie das folgende Verfahren, um einen Compute-Host einem funktionsfähigen Cluster hinzuzufügen.

Konfigurieren Sie den Host als Zielhost. Siehe den Konfigurationsabschnitt Zielhosts des Bereitstellungsleitfadens für mehr Informationen.
Bearbeiten Sie die Datei /etc/openstack_deploy/openstack_user_config.yml und fügen Sie den Host der Zeilengruppe compute_hosts hinzu.

Ändern Sie bei Bedarf auch die Zeilengruppe used_ips.
Wenn der Cluster Telemetrie/Metering (Ceilometer) verwendet, bearbeiten Sie die Datei /etc/openstack_deploy/conf.d/ceilometer.yml und fügen Sie den Host der Zeilengruppe metering-compute_hosts hinzu.

Führen Sie die folgenden Befehle aus, um den Host hinzuzufügen. Ersetzen Sie NEW_HOST_NAME durch den Namen des neuen Hosts.

# cd /opt/openstack-ansible/playbooks
# openstack-ansible openstack.osa.setup_hosts --limit localhost,NEW_HOST_NAME
# openstack-ansible openstack.osa.openstack_hosts_setup -e openstack_hosts_group=nova_compute --tags openstack_hosts-file
# openstack-ansible openstack.osa.setup_openstack --limit localhost,NEW_HOST_NAME

Alternatively you can try using new compute nodes deployment script /opt/openstack-ansible/scripts/add-compute.sh.

You can provide this script with extra tasks that will be executed before or right after OSA roles. To do so you should set environment variables PRE_OSA_TASKS or POST_OSA_TASKS with plays to run devided with semicolon:

# export POST_OSA_TASKS="/opt/custom/setup.yml --limit HOST_NAME;/opt/custom/tasks.yml --tags deploy"
# /opt/openstack-ansible/scripts/add-compute.sh HOST_NAME,HOST_NAME_2

Testen Sie neue Compute-Knoten¶

Überprüfen Sie nach dem Erstellen eines neuen Knotens, dass der Knoten ordnungsgemäß ausgeführt wird, indem Sie eine Instanz auf dem neuen Knoten starten.

$ openstack server create --image IMAGE --flavor m1.tiny \
--key-name KEY --availability-zone ZONE:HOST:NODE \
--nic net-id=UUID SERVER

Stellen Sie sicher, dass die neue Instanz auf einen Netzwerkverbindungstest mit dem Befehl ping reagieren kann. Melden Sie sich bei Ihrem Überwachungssystem an und vergewissern Sie sich, dass die Monitore ein grünes Signal für den neuen Knoten zurückgeben.

Entfernen Sie einen Computer-Host¶

Die openstack-ansible-ops repository enthält ein Playbook zum Entfernen eines Compute-Hosts aus einer OpenStack-Ansible-Umgebung. Gehen Sie folgendermaßen vor, um einen Computerhost zu entfernen.

Bemerkung

In diesem Handbuch wird beschrieben, wie ein Rechenknoten vollständig aus einer OpenStack-Ansible-Umgebung entfernt wird. Führen Sie diese Schritte mit Vorsicht durch, da der Rechenknoten nach Abschluss der Schritte nicht mehr in Betrieb ist. In diesem Handbuch wird davon ausgegangen, dass alle Daten und Instanzen ordnungsgemäß migriert wurden.

Deaktivieren Sie alle OpenStack-Dienste, die auf dem Rechenknoten ausgeführt werden. Dies kann den nova-compute -Dienst und den Neutronenagentendienst umfassen, ist aber nicht darauf beschränkt.

Bemerkung

Stellen Sie sicher, dass dieser Schritt zuerst ausgeführt wird
```
# Run these commands on the compute node to be removed
# stop nova-compute
# stop neutron-linuxbridge-agent
```

Klonen Sie das Repository openstack-ansible-ops auf Ihren Bereitstellungshost:

$ git clone https://opendev.org/openstack/openstack-ansible-ops \
  /opt/openstack-ansible-ops

Führen Sie das remove_compute_node.yml Ansible-Playbook mit der host_to_be_removed-Benutzervariablen aus:

$ cd /opt/openstack-ansible-ops/ansible_tools/playbooks
openstack-ansible remove_compute_node.yml \
-e host_to_be_removed="<name-of-compute-host>"

Nachdem das Playbook abgeschlossen ist, entfernen Sie den Compute-Knoten aus der OpenStack-Ansible-Konfigurationsdatei in /etc/openstack_deploy/openstack_user_config.yml.

Recover einen Computer-Host-Fehler¶

Die folgende Prozedur behandelt Compute-Knotenfehler, wenn gemeinsam genutzter Speicher verwendet wird.

Bemerkung

Wenn kein gemeinsam genutzter Speicher verwendet wird, können Daten aus dem Verzeichnis /var/lib/nova/instances auf dem fehlerhaften Compute-Knoten ${FAILED_NODE} auf einen anderen Knoten ${RECEIVING_NODE}vor dem Ausführen der folgenden Prozedur kopiertwerden. Bitte beachten Sie, dass diese Methode nicht unterstützt wird.

Starten Sie alle Instanzen auf dem ausgefallenen Knoten neu.
Rufen Sie das MySQL-Befehlszeilentool auf

Generieren Sie eine Liste der Instanz-UUIDs, die auf dem ausgefallenen Knoten gehostet werden:

mysql> select uuid from instances where host = '${FAILED_NODE}' and deleted = 0;

Legen Sie Instanzen auf dem ausgefallenen Knoten fest, die auf einem anderen Knoten gehostet werden sollen:

mysql> update instances set host ='${RECEIVING_NODE}' where host = '${FAILED_NODE}' \
and deleted = 0;

Starten Sie jede Instanz für den fehlgeschlagenen Knoten neu, der in der vorherigen Abfrage aufgelistet wurde, um die XML-Dateien neu zu generieren:
```
# nova reboot —hard $INSTANCE_UUID
```

Suchen Sie nach den Datenträgern, die überprüft werden sollen, ob die Instanz erfolgreich gestartet wurde und sich bei der Anmeldung befindet:

mysql> select nova.instances.uuid as instance_uuid, cinder.volumes.id \
as voume_uuid, cinder.volumes.status, cinder.volumes.attach_status, \
cinder.volumes.mountpoint, cinder.volumes,display_name from \
cinder.volumes inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid \
where nova.instances.host = '${FAILED_NODE}';

Wenn Zeilen gefunden werden, trennen Sie die Datenträger, und hängen Sie sie erneut an, indem Sie die in der vorherigen Abfrage aufgeführten Werte verwenden:
```
# nova volume-detach $INSTANCE_UUID $VOLUME_UUID && \
# nova volume-attach $INSTANCE_UUID $VOLUME_UUID $VOLUME_MOUNTPOINT
```
Erneutes Erstellen oder Ersetzen des ausgefallenen Knotens wie in add-compute-host beschrieben.

Ersetzen von fehlgeschlagener Hardware¶

Es ist wichtig zu planen und zu wissen, wie Sie fehlerhafte Hardware in Ihrem Cluster ersetzen können, ohne Ihre Cloud-Umgebung zu gefährden.

Berücksichtigen Sie Folgendes, um einen Hardware-Ersatzplan zu erstellen:

Bei welcher Art von Knoten ersetze ich die Hardware?
Kann der Hardware-Austausch durchgeführt werden, ohne dass der Host ausfällt? Zum Beispiel eine einzelne Festplatte in einem RAID-10.
Wenn der Host zum Hardware-Austausch heruntergefahren werden muss, wie sollten die Ressourcen auf diesem Host gehandhabt werden?

Wenn Sie einen Compute-Host (nova) mit einem Festplattenfehler auf einem RAID-10-System haben, können Sie den ausgefallenen Datenträger austauschen, ohne den Host herunterzufahren. Auf der anderen Seite, wenn der RAM fehlgeschlagen ist, müssten Sie den Host herunterfahren. Einen Plan für die Verwaltung dieser Ereignistypen zu erstellen, ist ein wichtiger Teil der Wartung Ihrer OpenStack-Umgebung.

Beenden Sie für einen Compute-Host die Instanz auf dem Host, bevor sie heruntergefahren wird. Löschen Sie für einen Blockspeicher (Cinder) -Host, der nicht redundanten Speicher verwendet, alle Instanzen mit angehängten Datenträgern, für die dieser Bereitstellungspunkt erforderlich ist. Hängen Sie das Laufwerk innerhalb Ihres Betriebssystems aus und mounten Sie das Laufwerk erneut, sobald der Blockspeicher-Host wieder online ist.

Herunterfahren des Compute-Hosts¶

Wenn ein Compute-Host heruntergefahren werden muss:

Deaktivieren Sie die nova-compute Binärdatei:

# nova service-disable --reason "Hardware replacement" HOSTNAME nova-compute

Listet alle laufenden Instanzen auf dem Compute-Host auf:

# nova list --all-t --host <compute_name> | awk '/ACTIVE/ {print $2}' > \
/home/user/running_instances && for i in `cat /home/user/running_instances`; do nova stop $i ; done

Verwenden Sie SSH, um eine Verbindung mit dem Compute-Host herzustellen.
Bestätigen Sie, dass alle Instanzen ausgefallen sind:
```
# virsh list --all
```
Fahren Sie den Compute-Host herunter:
```
# shutdown -h now
```
Sobald der Compute-Host wieder online ist, bestätigen Sie, dass alles in Ordnung ist und starten Sie die Instanzen auf dem Host. Beispielsweise:
```
# cat /home/user/running_instances
# do nova start $instance
  done
```
Aktivieren Sie den Dienst nova-compute in der Umgebung:
```
# nova service-enable HOSTNAME nova-compute
```

Den Blockspeicher-Host herunterfahren¶

Wenn ein von LVM unterstützter Block Storage-Host heruntergefahren werden muss:

Deaktivieren Sie den Dienst cinder-volume:

# cinder service-list --host CINDER SERVICE NAME INCLUDING @BACKEND
# cinder service-disable CINDER SERVICE NAME INCLUDING @BACKEND \
cinder-volume --reason 'RAM maintenance'

Auflisten aller Instanzen mit angehängten Blockspeicher-Datenträgern:

# mysql cinder -BNe 'select instance_uuid from volumes where deleted=0 '\
'and host like "%<cinder host>%"' | tee /home/user/running_instances

Herunterfahren der Instanzen:

# cat /home/user/running_instances | xargs -n1 nova stop

Stellen Sie sicher, dass die Instanzen heruntergefahren werden:

# cat /home/user/running_instances | xargs -n1 nova show | fgrep vm_state

Fahren Sie den Blockspeicher-Host herunter:
```
# shutdown -h now
```
Ersetzen Sie die fehlerhafte Hardware und überprüfen Sie, ob die neue Hardware funktioniert.

Aktivieren Sie den Dienst cinder-volume:

# cinder service-enable CINDER SERVICE NAME INCLUDING @BACKEND cinder-volume

Überprüfen Sie, dass die Dienste auf dem Host wieder mit der Umgebung verbunden sind:
```
# cinder service-list --host CINDER SERVICE NAME INCLUDING @BACKEND
```

Starten Sie Ihre Instanzen und bestätigen Sie, dass alle Instanzen gestartet wurden:

# cat /home/user/running_instances | xargs -n1 nova start
# cat /home/user/running_instances | xargs -n1 nova show | fgrep vm_state

Zerstören von Containern¶

Um einen Container zu zerstören, führen Sie Folgendes aus:

# openstack-ansible openstack.osa.containers_lxc_destroy --limit localhost,<container name|container group>
Bemerkung

Sie werden zwei Fragen gestellt bekommen:

Are you sure you want to destroy the LXC containers? Are you sure you want to destroy the LXC container data?

Die erste wird nur den Container entfernen, aber die Daten in den Bind-Mounts und -Logs belassen. Die zweite wird die Daten in den Bind-Mounts und -Logs ebenfalls entfernen.

Warnung

Wenn Sie die Container und Daten für die gesamte Containergruppe galera_server entfernen, verlieren Sie alle Ihre Datenbanken! Wenn Sie den ersten Container in vielen Host-Gruppen zerstören, verlieren Sie auch andere wichtige Elemente wie Zertifikate, Schlüssel usw. Achten Sie darauf, dass Sie verstehen, was Sie tun, wenn Sie dieses Tool verwenden.

Um die Container erneut zu erstellen, führen Sie Folgendes aus:
```
# cd /opt/openstack-ansible/playbooks
# openstack-ansible openstack.osa.containers_lxc_create --limit localhost,lxc_hosts,<container name|container
  group>
```
Die Hostgruppe lxc_hosts muss als Playbook enthalten sein, und die ausgeführten Rollen erfordern die Verwendung von Fakten von den Hosts.

Zugänglichkeit für den Multi-Region-Objektspeicher¶

Bei der Objektspeicherung in mehreren Regionen mit separaten Datenbank-Back-Ends können Objekte von einem alternativen Speicherort abgerufen werden, wenn die default_project_id für einen Benutzer in der Keystone-Datenbank in jedem Datenbank-Backend identisch ist.

Wichtig

Es wird empfohlen, die folgenden Schritte auszuführen, bevor ein Fehler auftritt, um zu vermeiden, dass die Datenbank gesichert und wiederhergestellt werden muss.

Wenn ein Fehler auftritt, führen Sie die folgenden Schritte aus, um die Datenbank aus der primären (fehlgeschlagenen) Region wiederherzustellen:

Zeichnen Sie die primäre Region-Ausgabe der default_project_id für den angegebenen Benutzer aus der Benutzertabelle in der Keystone-Datenbank auf:

Bemerkung

Der Benutzer ist in diesem Beispiel admin.

# mysql -e "SELECT default_project_id from keystone.user WHERE \
  name='admin';"

+----------------------------------+
| default_project_id               |
+----------------------------------+
| 76ef6df109744a03b64ffaad2a7cf504 |
+-----------------—————————————————+

Zeichnen Sie die Ausgabe der sekundären Region der default_project_id für den angegebenen Benutzer aus der Benutzertabelle in der Keystone-Datenbank auf:

# mysql -e "SELECT default_project_id from keystone.user WHERE \
  name='admin';"

+----------------------------------+
| default_project_id               |
+----------------------------------+
| 69c46f8ad1cf4a058aa76640985c     |
+----------------------------------+

Aktualisieren Sie im sekundären Bereich die Verweise auf project_id so, dass sie mit der ID aus dem primären Bereich übereinstimmen:

# export PRIMARY_REGION_TENANT_ID="76ef6df109744a03b64ffaad2a7cf504"
# export SECONDARY_REGION_TENANT_ID="69c46f8ad1cf4a058aa76640985c"

# mysql -e "UPDATE keystone.assignment set \
target_id='${PRIMARY_REGION_TENANT_ID}' \
WHERE target_id='${SECONDARY_REGION_TENANT_ID}';"

# mysql -e "UPDATE keystone.user set \
default_project_id='${PRIMARY_REGION_TENANT_ID}' WHERE \
default_project_id='${SECONDARY_REGION_TENANT_ID}';"

# mysql -e "UPDATE keystone.project set \
id='${PRIMARY_REGION_TENANT_ID}' WHERE \
id='${SECONDARY_REGION_TENANT_ID}';"

Der Benutzer in der sekundären Region hat nun Zugriff auf Objekte PUT in der primären Region. Die sekundäre Region kann Objekte, auf die der Benutzer in der primären Region zugreifen kann, auf PUT stellen.

Skalieren Sie Ihre Umgebung

Skalieren Sie Ihre Umgebung¶

Fügen Sie einen neuen Infrastrukturhost hinzu¶

Testen Sie neue Infra-Knoten¶

Fügen Sie einen Computer-Host hinzu¶

Testen Sie neue Compute-Knoten¶

Entfernen Sie einen Computer-Host¶

Recover einen Computer-Host-Fehler¶

Ersetzen von fehlgeschlagener Hardware¶

Herunterfahren des Compute-Hosts¶

Den Blockspeicher-Host herunterfahren¶

Zerstören von Containern¶

Zugänglichkeit für den Multi-Region-Objektspeicher¶

openstack-ansible 30.0.0.0b2.dev2

Page Contents