Skalieren Sie Ihre Umgebung¶

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.

1. Fügen Sie den Knoten der Zeilengruppe infra_hosts der Datei /etc/openstack_deploy/openstack_user_config.yml hinzu

   infra_hosts:
   [...]
   NEW_infra<node-ID>:
     ip: 10.17.136.32
   NEW_infra<node-ID2>:
     ip: 10.17.136.33
   

2. Wechseln Sie in den Playbook-Ordner auf dem Bereitstellungshost.

   # cd /opt/openstack-ansible/playbooks
   

3. Aktualisieren Sie das Inventar, um neue Hosts hinzuzufügen. Stellen Sie sicher, dass neue rsyslog-Containernamen aktualisiert werden. Senden Sie die aktualisierten Ergebnisse an dev/null.

   # /opt/openstack-ansible/inventory/dynamic_inventory.py > /dev/null
   

4. Erstellen Sie die Datei /root/add_host.limit, die alle neuen Knoten-Hostnamen und ihre Container enthält. Fügen Sie localhost zur Liste der Hosts hinzu, um auf Bereitstellungshostfakten zugreifen zu können.

   localhost
   NEW_infra<node-ID>
   NEW_infra<node-ID2>
   NEW_infra<node-ID>_containers
   NEW_infra<node-ID2>_containers
   

5. Führen Sie das setup-everything.yml-Playbook mit dem limit-Argument aus.

   # openstack-ansible setup-everything.yml --limit @/root/add_host.limit
   

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. Konfigurieren Sie den Host als Zielhost. Siehe den Konfigurationsabschnitt Zielhosts des Bereitstellungsleitfadens für mehr Informationen.

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 setup-hosts.yml --limit localhost,NEW_HOST_NAME
   # ansible nova_all -m setup -a 'filter=ansible_local gather_subset="!all"'
   # openstack-ansible setup-openstack.yml --limit localhost,NEW_HOST_NAME
   

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¶

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

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

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.

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

2. Rufen Sie das MySQL-Befehlszeilentool auf

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

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.

Zerstören von Containern¶

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

# cd /opt/openstack-ansible/playbooks
# openstack-ansible lxc-containers-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.

1. Um die Container erneut zu erstellen, führen Sie Folgendes aus:

   # cd /opt/openstack-ansible/playbooks
   # openstack-ansible lxc-containers-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.

[ English | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

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.

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

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

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