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

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 Backup and restore your cloud für weitere Informationen.

  1. Add the node to the infra_hosts stanza of the /etc/openstack_deploy/openstack_user_config.yml:

    infra_hosts:
[...]
  infra<node-ID>:
    ip: 10.17.136.32

  2. Change to playbook folder on the deployment host:

    # cd /opt/openstack-ansible

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

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

  5. 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 verify 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

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

  1. Configure the host as a target host. See the target hosts configuration section of the deploy guide for more information.

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

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

  4. 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 OpenStack-Ansible 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

After creating a new node, test that the node runs correctly by launching an instance on the new node:

$ 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

The OpenStack-Ansible Operator Tooling repository contains a playbook for removing a compute host from an OpenStack-Ansible environment. To remove a compute host, follow the below procedure.

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.

  1. Disable all OpenStack services running on the compute node. This can include, but is not limited to, the nova-compute service and the neutron agent service:

    Bemerkung

    Ensure this step is performed first.

    # Run these commands on the compute node to be removed
# systemctl stop nova-compute
# systemctl stop neutron-openvswitch-agent

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

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

  3. 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>"

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

  1. Starten Sie alle Instanzen auf dem ausgefallenen Knoten neu.

  2. Invoke the MariaDB command line tool.

  3. 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;

  4. 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;

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

  6. Find the volumes to check the instance has successfully booted and is at the login:

    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}';

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

  8. 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:

  1. Deaktivieren Sie die nova-compute Binärdatei:

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

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

  3. Verwenden Sie SSH, um eine Verbindung mit dem Compute-Host herzustellen.

  4. Bestätigen Sie, dass alle Instanzen ausgefallen sind:

    # virsh list --all

  5. Fahren Sie den Compute-Host herunter:

    # shutdown -h now

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

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

  1. 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'

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

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

  3. Herunterfahren der Instanzen:

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

  4. Stellen Sie sicher, dass die Instanzen heruntergefahren werden:

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

  5. Fahren Sie den Blockspeicher-Host herunter:

    # shutdown -h now

  6. Ersetzen Sie die fehlerhafte Hardware und überprüfen Sie, ob die neue Hardware funktioniert.

  7. Aktivieren Sie den Dienst cinder-volume:

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

  8. Überprüfen Sie, dass die Dienste auf dem Host wieder mit der Umgebung verbunden sind:

    # cinder service-list --host CINDER SERVICE NAME INCLUDING @BACKEND

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

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

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