[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

Verwalten Sie Ihre Cloud

In diesem Kapitel werden OpenStack-Vorgangsaufgaben dokumentiert, die für die Operationsunterstützung in einer OpenStack-Ansible-Bereitstellung von wesentlicher Bedeutung sind.

Es erläutert Vorgänge wie die Verwaltung von Abbildern, Instanzen oder Netzwerken.

[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

Abbilder verwalten

Ein Abbild stellt das Betriebssystem, die Software und alle Einstellungen dar, die Instanzen abhängig von den Projektzielen benötigen. Erstellen Sie zuerst Abbilder, bevor Sie Instanzen erstellen.

Das Hinzufügen von Abbildern kann über das Dashboard oder die Befehlszeile erfolgen. Eine andere verfügbare Option ist das Tool python-openstackclient, das auf dem Controller-Knoten oder auf einer Workstation installiert werden kann.

Hinzufügen eines Abbildes mit dem Dashboard

Um ein Abbild über das Dashboard hinzuzufügen, bereiten Sie eine Image-Binärdatei vor, auf die über HTTP mit einer gültigen und direkten URL zugegriffen werden muss. Abbilder können mit .zip oder .tar.gz komprimiert werden.

Bemerkung

Das Hochladen von Abbildern über das Dashboard steht Benutzern mit Administratorrechten zur Verfügung. Bediener können Benutzerzugriffsrechte festlegen.

  1. Melden Sie sich am Dashboard an.

  2. Wählen Sie im Navigationsbereich die Registerkarte Admin und klicken Sie auf Abbilder.

  3. Klicken Sie auf die Schaltfläche Abbild erstellen. Das Dialogfeld Abbild erstellen wird angezeigt.

  4. Geben Sie die Details des Abbildes ein, einschließlich Abbildort, wo der URL-Ort des Abbildes benötigt wird.

  5. Klicken Sie auf die Schaltfläche Abbild erstellen. Das neu erstellte Abbild kann einige Zeit dauern, bis es vollständig hochgeladen wurde, da das Abbild in einer Abbildwarteschlange eintrifft.

Hinzufügen eines Abbildes über die Befehlszeile

Der Dienstprogrammcontainer stellt eine CLI-Umgebung für zusätzliche Konfiguration und Verwaltung bereit.

  1. Zugriff auf den Dienstprogrammcontainer:

    $ lxc-attach -n `lxc-ls -1 | grep utility | head -n 1`
    

Verwenden Sie den Openstack-Client im Dienstprogrammcontainer, um alle flüchtigen Abbilder zu verwalten. Lesen Sie die offizielle Dokumentation des Openstack-Clients zum Verwalten von Abbildern.

[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

Instanzen verwalten

In diesem Kapitel wird beschrieben, wie Sie Instanzen erstellen und darauf zugreifen.

Erstellen einer Instanz mithilfe des Dashboards

Erstellen Sie mithilfe eines Abbildes eine neue Instanz über die Dashboard-Optionen.

  1. Melden Sie sich am Dashboard an und wählen Sie das Projekt Compute aus der Dropdown-Liste aus.

  2. Klicken Sie auf die Option Abbilder.

  3. Suchen Sie das Abbild, das als Instanzbasis dienen soll, aus der Tabelle Abbilder.

  4. Klicken Sie in der Spalte Aktionen auf Starten.

  5. Überprüfen Sie das Dialogfeld Instanzen starten und finden Sie die Registerkarte Details. Geben Sie die entsprechenden Werte für die Instanz ein.

    1. Klicken Sie im Dialogfeld Instanz starten auf die Registerkarte Access & Security. Wählen Sie das Schlüsselpaar aus. Legen Sie die Sicherheitsgruppe als „default“ fest.

    2. Klicken Sie auf den Tab Netzwerk. Diese Registerkarte ist nicht verfügbar, wenn das OpenStack-Netzwerk (Neutron) nicht aktiviert wurde. Wenn das Netzwerk aktiviert ist, wählen Sie die Netzwerke aus, in denen sich die Instanz befinden soll.

    3. Klicken Sie auf die Registerkarte Datenträger-Optionen. Diese Registerkarte ist nur verfügbar, wenn ein Blockspeicherdatenträger für die Instanz vorhanden ist. Wählen Sie jetzt Nicht von einem Datenträger booten.

      Weitere Informationen zum Anhängen von Blockspeicher-Datenträger an Instanzen für dauerhaftes Speichern finden Sie im Abschnitt Managing volumes for persistent storage weiter unten.

    4. Fügen Sie bei Bedarf benutzerdefinierte Skripts hinzu, indem Sie auf die Registerkarte Post-Creation klicken. Diese werden ausgeführt, nachdem die Instanz erstellt wurde. Einige Instanzen unterstützen Benutzerdaten, z.B. Root-Kennwörter oder Admin-Benutzer. Geben Sie hier gegebenenfalls die für die Instanz spezifischen Informationen ein.

    5. Klicken Sie auf Erweiterte Optionen. Geben Sie an, ob die Instanz ein Konfigurationslaufwerk zum Speichern von Metadaten verwendet, indem Sie einen Festplattenpartitionstyp auswählen.

  6. Klicken Sie auf Starten, um die Instanz zu erstellen. Die Instanz wird auf einem Rechenknoten gestartet. Die Seite Instanz wird geöffnet und beginnt mit dem Erstellen einer neuen Instanz. Die geöffnete Seite Instance listet den Instanznamen, die Größe, den Status und die Aufgabe auf. Energiezustand und öffentliche und private IP-Adressen sind hier ebenfalls aufgeführt.

    Der Vorgang dauert weniger als eine Minute. Die Instanzerstellung ist abgeschlossen, wenn der Status als aktiv aufgeführt ist. Aktualisieren Sie die Seite, um die neue aktive Instanz zu sehen.

    Starten einer Instanz Optionen

    Feldname

    Erforderlich

    Einzelheiten

    Verfügbarkeitszone

    Wahlweise

    Die Verfügbarkeitszone, in der der Abbild-Dienst die Instanz erstellt. Wenn keine Verfügbarkeitszonen definiert sind, werden keine Instanzen gefunden. Der Cloud-Anbieter legt die Verfügbarkeitszone auf einen bestimmten Wert fest.

    Instanzname

    Erforderlich

    Der Name der neuen Instanz, die zum anfänglichen Hostnamen des Servers wird. Wenn der Servername in der API geändert oder direkt geändert wird, bleiben die Dashboard-Namen unverändert

    Abbild

    Erforderlich

    Die Art des Containerformats, eines von ami, ari, aki, blank oder ovf

    Variante

    Erforderlich

    Die vCPU-, Speicher- und Festplattenkonfiguration. Beachten Sie, dass die Erstellung größerer Varianten lange dauern kann. Wenn Sie eine Instanz zum ersten Mal erstellen und etwas Kleines zum Testen möchten, wählen Sie m1.small.

    Instanzanzahl

    Erforderlich

    Wenn Sie mehrere Instanzen mit dieser Konfiguration erstellen, geben Sie eine ganze Zahl ein, die der Quote entspricht, die durch das Kontingent zulässig ist (standardmäßig 10).

    Instanzstartquelle

    Erforderlich

    Geben Sie an, ob die Instanz auf einem Abbild oder einem Snapshot basieren soll. Wenn Sie zum ersten Mal eine Instanz erstellen, sind noch keine Snapshots verfügbar.

    Abbildname

    Erforderlich

    Die Instanz startet von dem ausgewählten Abbild. Diese Option wird mit der aus der Tabelle ausgewählten Instanz vorbelegt. Wählen Sie jedoch Boot from Snapshot in Instance Boot Source und stattdessen Snapshot.

    Sicherheitsgruppen

    Wahlweise

    Diese Option weist Sicherheitsgruppen einer Instanz zu. Die Standardsicherheitsgruppe wird aktiviert, wenn hier keine benutzerdefinierte Gruppe angegeben wird. Sicherheitsgruppen definieren ähnlich wie eine Cloud-Firewall, welcher eingehende Netzwerkverkehr an Instanzen weitergeleitet wird.

    Schlüsselpaar

    Wahlweise

    Geben Sie ein Schlüsselpaar mit dieser Option an. Wenn das Abbild einen statischen Schlüsselsatz verwendet (nicht empfohlen), wird kein Schlüsselpaar benötigt.

    Ausgewählte Netzwerke

    Wahlweise

    Um ein Netzwerk zu einer Instanz hinzuzufügen, klicken Sie auf + im Feld Netzwerke.

    Anpassungs-Skript

    Wahlweise

    Geben Sie ein Anpassungsskript an. Dieses Skript wird ausgeführt, nachdem die Instanz gestartet wurde und aktiv wird.

Erstellen einer Instanz über die Befehlszeile

In der Befehlszeile wird die Instanzerstellung mit dem Befehl openstack server create verwaltet. Bevor Sie eine Instanz starten, bestimmen Sie mithilfe der Befehle openstack image list und openstack flavour list, welche Abbilder und Varianten verfügbar sind, um eine neue Instanz zu erstellen.

  1. Melden Sie sich bei einem beliebigen Dienstprogrammcontainer an.

  2. Geben Sie den Befehl openstack server create mit einem Namen für die Instanz zusammen mit dem Namen des zu verwendenden Abbilds und Variante ein:

    $ openstack server create --image precise-image --flavor 2 --key-name example-key example-instance
    +-------------------------------------+--------------------------------------+
    |               Property              |                Value                 |
    +-------------------------------------+--------------------------------------+
    |          OS-DCF:diskConfig          |                MANUAL                |
    |         OS-EXT-SRV-ATTR:host        |                 None                 |
    | OS-EXT-SRV-ATTR:hypervisor_hostname |                 None                 |
    |    OS-EXT-SRV-ATTR:instance_name    |          instance-0000000d           |
    |        OS-EXT-STS:power_state       |                  0                   |
    |        OS-EXT-STS:task_state        |              scheduling              |
    |         OS-EXT-STS:vm_state         |               building               |
    |              accessIPv4             |                                      |
    |              accessIPv6             |                                      |
    |              adminPass              |             ATSEfRY9fZPx             |
    |             config_drive            |                                      |
    |               created               |         2012-08-02T15:43:46Z         |
    |                flavor               |               m1.small               |
    |                hostId               |                                      |
    |                  id                 | 5bf46a3b-084c-4ce1-b06f-e460e875075b |
    |                image                |             precise-image            |
    |               key_name              |              example-key             |
    |               metadata              |                  {}                  |
    |                 name                |           example-instance           |
    |               progress              |                  0                   |
    |                status               |                BUILD                 |
    |              tenant_id              |   b4769145977045e2a9279c842b09be6a   |
    |               updated               |         2012-08-02T15:43:46Z         |
    |               user_id               |   5f2f2c28bdc844f9845251290b524e80   |
    +-------------------------------------+--------------------------------------+
    
  3. Um zu überprüfen, ob die Instanz erfolgreich erstellt wurde, geben Sie den Befehl openstack server list ein:

    $ openstack server list
    +------------------+------------------+--------+-------------------+---------------+
    |        ID        |       Name       | Status |      Networks     |   Image Name  |
    +------------------+------------------+--------+-------------------+---------------+
    | [ID truncated]   | example-instance | ACTIVE |  public=192.0.2.0 | precise-image |
    +------------------+------------------+--------+-------------------+---------------+
    

Verwalten einer Instanz

  1. Melden Sie sich am Dashboard an. Wählen Sie eines der Projekte und klicken Sie auf Instanzen.

  2. Wählen Sie eine Instanz aus der Liste der verfügbaren Instanzen.

  3. Überprüfen Sie die Spalte Aktionen und klicken Sie auf die Option Mehr. Wählen Sie den Instanzstatus aus.

Die Spalte Aktionen enthält die folgenden Optionen:

  • Ändern Sie die Größe einer Instanz oder erstellen Sie sie neu

  • Zeigen Sie das Protokoll der Instanzkonsole an

  • Bearbeiten Sie die Instanz

  • Ändern Sie Sicherheitsgruppen

  • Die Instanz pausieren, fortsetzen oder anhalten

  • Weiches oder hartes Zurücksetzen der Instanz

Bemerkung

Beenden Sie die Instanz in der Spalte Aktionen.

Managing volumes for persistent storage

Datenträger werden an Instanzen angehängt, wodurch dauerhafter Speicher aktiviert wird. Der Datenträgerspeicher stellt eine Speicherquelle für Instanzen bereit. Administratoren können Datenträger einer laufenden Instanz anhängen oder ein von einer Instanz zu einer anderen verschieben.

Nova-Instanzen Live-Migration

Nova ist in der Lage, Live-Migrationsinstanzen von einem Host zu einem anderen Host zu unterstützen, um verschiedene operative Aufgaben zu unterstützen, darunter:

  • Host-Wartung

  • Host-Kapazitätsverwaltung

  • Ändern der Größe und Verschieben von Instanzen zu besserer Hardware

Nova Konfigurations-Laufwerk Implikation

Abhängig von der verwendeten OpenStack-Ansible-Version kann Nova so konfiguriert werden, dass Konfigurationslaufwerk-Anhänge für Instanzen erzwungen werden. In diesem Fall wird ein ISO9660-CD-ROM-Image für die Instanz über den Einhängepunkt /mnt bereitgestellt. Dies kann von Tools wie cloud-init verwendet werden, um auf Instanzmetadaten zuzugreifen. Dies ist eine alternative Möglichkeit, auf die Metadaten im Nova EC2-Stil zuzugreifen.

Um eine Live-Migration von Nova-Instanzen zu ermöglichen, muss diese erzwungene Bereitstellung des CD-ROM-Laufwerks entweder deaktiviert werden oder das Format des Konfigurationslaufwerks muss in ein Datenträgerformat wie vfat geändert werden, ein Format, das sowohl Linux als auch Windows-Instanzen können darauf zugreifen.

Diese Umgehung ist für alle Libvirt-Versionen vor 1.2.17 erforderlich.

Um die erzwungene Bereitstellung des Konfigurations-Laufwerks zu deaktivieren, fügen Sie der Datei /etc/openstack_deploy/user_variables.yml folgende Überschreibung hinzu:

nova_force_config_drive: False

Um das Format des Konfigurationslaufwerks in ein Festplattenstilformat zu ändern, verwenden Sie die folgende Konfiguration innerhalb der Datei /etc/openstack_deploy/user_variables.yml:

nova_nova_conf_overrides:
  DEFAULT:
    config_drive_format: vfat
    force_config_drive: false

Tunnelling gegen direkten Transport

In der Standardkonfiguration ermittelt Nova die korrekte Transport-URL für die Übertragung der Daten von einem Host zum anderen. Abhängig von der nova_virt_type Überschreibung werden folgende Konfigurationen verwendet:

  • kvm verwendet standardmäßig qemu+tcp://%s/system

  • qemu verwendet standardmäßig `` qemu+tcp://%s/system``

  • xen verwendet standardmäßig xenmigr://%s/system

Libvirt TCP-Port zum Übertragen der zu migrierenden Daten.

OpenStack-Ansible ändert die Standardeinstellung und verwendet eine verschlüsselte SSH-Verbindung, um die Instanzdaten zu übertragen.

live_migration_uri = "qemu+ssh://nova@%s/system?no_verify=1&keyfile={{ nova_system_home_folder }}/.ssh/id_rsa"

Andere Konfigurationen können in der /etc/openstack_deploy/user_variables.yml Datei konfiguriert werden:

nova_nova_conf_overrides:
  libvirt:
    live_migration_completion_timeout: 0
    live_migration_progress_timeout: 0
    live_migration_uri: "qemu+ssh://nova@%s/system?keyfile=/var/lib/nova/.ssh/id_rsa&no_verify=1"

Lokaler oder gemeinsam genutzter Speicher

Live-Migration setzt standardmäßig voraus, dass Ihre Nova-Instanzen auf gemeinsam genutztem Speicher gespeichert sind und KVM/Libvirt nur den Speicher und das Basis-Image der Nova-Instanz mit dem neuen Host synchronisieren müssen. Live-Migrationen auf lokalem Speicher werden als Ergebnis dieser Annahme fehlschlagen. Migrationen mit lokalem Speicher können durchgeführt werden, indem Sie Plattenmigrationen mit der Option block-migrate zulassen.

Zusätzliche Nova-Funktionen wie ephemere Speicherung oder Austausch wirken sich auf die Leistung und den Erfolg von Live-Migrationen aus.

An Cinder angehängte Datenträger erfordern ebenfalls eine Libvirt-Version größer oder gleich 1.2.17.

Ausführen der Migration

Die Livemigration ist über den nova-Client zugänglich.

nova live-migration [--block-migrate] [--force] <uuid> [<host>]

Beispielhafte Live Migration auf einem lokalen Speicher:

nova live-migration --block-migrate <uuid of the instance> <nova host>

Überwachung des Status

Sobald die Live-Migrationsanfrage angenommen wurde, kann der Status mit dem Novaclient überwacht werden:

nova migration-list

+-----+------------+-----------+----------------+--------------+-----------+-----------+---------------+------------+------------+------------+------------+-----------------+
| Id | Source Node | Dest Node | Source Compute | Dest Compute | Dest Host | Status    | Instance UUID | Old Flavor | New Flavor | Created At | Updated At | Type            |
+----+-------------+-----------+----------------+--------------+-----------+-----------+---------------+------------+------------+------------+------------+-----------------+
| 6  | -           | -         | compute01      | compute02    | -         | preparing | f95ee17a-d09c | 7          | 7          | date       | date       | live-migration  |
+----+-------------+-----------+----------------+--------------+-----------+-----------+---------------+------------+------------+------------+------------+-----------------+

Um die Liste zu filtern, können die Optionen --host oder --status verwendet werden:

nova migration-list --status error

In Fällen, in denen die Live-Migration fehlschlägt, müssen sowohl der Quell- als auch der Zielcomputerknoten auf Fehler überprüft werden. In der Regel reicht es aus, nur nach der UUID der Instanz zu suchen, um Fehler im Zusammenhang mit der Livemigration zu finden.

Andere Formen der Instanzmigration

Neben der Live-Migration bietet Nova die Möglichkeit, ganze Hosts in einer Online- (Live) oder Offline- (Cold-) Migration zu migrieren.

Die folgenden nova-Client-Befehle werden bereitgestellt:

  • host-evacuate-live

    Live migriert alle Instanzen des angegebenen Hosts auf andere Hosts, wenn die Ressourcennutzung dies zulässt. Es empfiehlt sich, gemeinsam genutzten Speicher wie Ceph oder NFS für die Host-Evakuierung zu verwenden.

  • host-servers-migrate

    Dieser Befehl ähnelt der Host-Evakuierung, migriert jedoch alle Instanzen vom angegebenen Host, während sie heruntergefahren werden.

  • resize

    Ändert der Variante einer Nova-Instanz (erhöhen) während des Neustarts und migriert (kalt) die Instanz auf einen neuen Host, um den neuen Ressourcenanforderungen gerecht zu werden. Dieser Vorgang kann je nach Größe des Disk-Images sehr viel Zeit in Anspruch nehmen.

[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

Netzwerke verwalten

Betriebsüberlegungen wie Compliance können die Verwaltung von Netzwerken erforderlich machen. Zum Beispiel das Hinzufügen neuer Provider-Netzwerke zur OpenStack-Ansible Managed Cloud. Die folgenden Abschnitte sind die häufigsten administrativen Aufgaben, die zum Ausführen dieser Aufgaben beschrieben werden.

Weitere allgemeine Informationen zur Fehlerbehebung in Ihrem Netzwerk finden Sie im Kapitel Netzwerk-Fehlerbehebung im Betriebshandbuch.

Weitere Informationen zum Netzwerk finden Sie im Netzwerkhandbuch.

Hinzufügen von Provider-Bridges mithilfe neuer Netzwerkschnittstellen

Fügen Sie jedes Provider-Netzwerk zu Ihrer Cloud hinzu, um es OpenStack-Ansible und dem Betriebssystem mitzuteilen, bevor Sie die erforderlichen Playbooks ausführen können, um die Konfiguration abzuschließen.

OpenStack-Ansible-Konfiguration

Alle Provider-Netzwerke müssen der OpenStack-Ansible-Konfiguration hinzugefügt werden.

Editieren Sie die Datei /etc/openstack_deploy/openstack_user_config.yml und fügen Sie einen neuen Block unter dem Abschnitt provider_networks hinzu:

The container_bridge setting defines the physical network bridge used to connect the veth pair from the physical host to the container. Inside the container, the container_interface setting defines the name at which the physical network will be made available. The container_interface setting is not required when Neutron agents are deployed on bare metal. Make sure that both settings are uniquely defined across their provider networks and that the network interface is correctly configured inside your operating system. group_binds define where this network need to attached to, to either containers or physical hosts and is ultimately dependent on the network stack in use. For example, Linuxbridge versus OVS. The configuration range defines Neutron physical segmentation IDs which are automatically used by end users when creating networks via mainly horizon and the Neutron API. Similar is true for the net_name configuration which defines the addressable name inside the Neutron configuration. This configuration also need to be unique across other provider networks.

Weitere Informationen finden Sie unter Konfigurieren Sie die Bereitstellung im OpenStack-Ansible-Bereitstellungshandbuch.

Aktualisieren des Knotens mit der neuen Konfiguration

Führen Sie die entsprechenden Playbooks aus, abhängig vom Abschnitt group_binds.

Wenn Sie zum Beispiel die Netzwerke aktualisieren, die eine Änderung an allen Knoten mit einem Linux-Bridge-Agenten erfordern, führen Sie Folgendes aus: Wenn Sie Infra-Knoten mit den Namen infra01, infra02 und infra03 haben, führen Sie Folgendes aus:

# openstack-ansible containers-deploy.yml --limit localhost,infra01,infra01-host_containers
# openstack-ansible containers-deploy.yml --limit localhost,infra02,infra02-host_containers
# openstack-ansible containers-deploy.yml --limit localhost,infra03,infra03-host_containers

Aktualisieren Sie dann die Neutron-Konfiguration.

# openstack-ansible os-neutron-install.yml --limit localhost,infra01,infra01-host_containers
# openstack-ansible os-neutron-install.yml --limit localhost,infra02,infra02-host_containers
# openstack-ansible os-neutron-install.yml --limit localhost,infra03,infra03-host_containers

Aktualisieren Sie dann ggf. Ihre Compute-Knoten.

Entfernen Sie Anbieterbrücken von OpenStack

Ähnlich wie beim Hinzufügen eines Provider-Netzwerks wird beim Entfernen derselbe Vorgang verwendet, jedoch in umgekehrter Reihenfolge. Die Neutron-Ports müssen vor dem Entfernen der OpenStack-Ansible-Konfiguration entfernt werden.

  1. Zuweisung aller neutron floating IPs aufheben:

    Bemerkung

    Exportieren Sie das Neutron-Netzwerk, das als einzelne UUID entfernt werden soll.

    export NETWORK_UUID=<uuid>
    for p in $( neutron port-list -c id --device_owner compute:nova --network_id=${NETWORK_UUID}| awk '/([A-Fa-f0-9]+-){3}/ {print $2}' ); do
      floatid=$( neutron floatingip-list -c id --port_id=$p | awk '/([A-Fa-z0-9]+-){3}/ { print $2 }' )
      if [ -n "$floatid" ]; then
        echo "Disassociating floating IP $floatid from port $p"
        neutron floatingip-disassociate $floatid
      fi
    done
    
  2. Entfernen Sie alle Neutron-Ports von den Instanzen:

    export NETWORK_UUID=<uuid>
    for p in $( neutron port-list -c id -c device_id --device_owner compute:nova --network_id=${NETWORK_UUID}| awk '/([A-Fa-f0-9]+-){3}/ {print $2}' ); do
      echo "Removing Neutron compute port $p"
      neutron port-delete $p
    done
    
  3. Entfernen Sie die Router-Ports und DHCP-Agenten von Neutron:

    export NETWORK_UUID=<uuid>
    for line in $( neutron port-list -c id -c device_id --device_owner network:router_interface --network_id=${NETWORK_UUID}| awk '/([A-Fa-f0-9]+-){3}/ {print $2 "+" $4}' ); do
      p=$( echo "$line"| cut -d'+' -f1 ); r=$( echo "$line"| cut -d'+' -f2 )
      echo "Removing Neutron router port $p from $r"
      neutron router-interface-delete $r port=$p
    done
    
    for agent in $( neutron agent-list -c id --agent_type='DHCP Agent' --network_id=${NETWORK_UUID}| awk '/([A-Fa-f0-9]+-){3}/ {print $2}' ); do
      echo "Remove network $NETWORK_UUID from Neutron DHCP Agent $agent"
      neutron dhcp-agent-network-remove "${agent}" $NETWORK_UUID
    done
    
  4. Entferne das Neutron-Netzwerk:

    export NETWORK_UUID=<uuid>
    neutron net-delete $NETWORK_UUID
    
  5. Entfernen Sie das Provider-Netzwerk aus der Konfiguration provider_networks der OpenStack-Ansible-Konfiguration /etc/openstack_deploy/openstack_user_config.yml und führen Sie die folgenden Playbooks erneut aus:

    # openstack-ansible lxc-containers-create.yml --limit infra01:infra01-host_containers
    # openstack-ansible lxc-containers-create.yml --limit infra02:infra02-host_containers
    # openstack-ansible lxc-containers-create.yml --limit infra03:infra03-host_containers
    # openstack-ansible os-neutron-install.yml --tags neutron-config
    

Starten Sie einen Container für den Netzwerkagenten neu

Unter bestimmten Umständen, bei der Konfiguration oder bei temporären Problemen, muss ein bestimmter oder alle Neutronenagenten-Container neu gestartet werden.

Dies kann mit mehreren Befehlen erreicht werden:

  1. Beispiel für das Neustarten von noch zugänglichen Containern.

    In diesem Beispiel wird der Container mit dem Namen neutron_agents_container_hostname_name von innen gestartet:

    # ansible -m shell neutron_agents_container_hostname_name -a 'reboot'
    
  2. Beispiel für das Neustarten eines einzelnen Containers im Abstand von 60 Sekunden:

    # ansible -m shell neutron_agents_container -a 'sleep 60; reboot' --forks 1
    
  3. Wenn der Container nicht antwortet, kann er vom physischen Netzwerkhost neu gestartet werden:

    # ansible -m shell network_hosts -a 'for c in $(lxc-ls -1 |grep neutron_agents_container); do lxc-stop -n $c && lxc-start -d -n $c; done' --forks 1