[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia | español | français ]
Fehlerbehebung¶
Dieses Kapitel soll zur Untersuchung und Behebung von Betriebsproblemen in einer OpenStack-Ansible-Bereitstellung beitragen.
Vernetzung¶
In diesem Abschnitt wird die allgemeine Host-zu-Host-Kommunikation behandelt, die für die ordnungsgemäße Funktion der OpenStack-Steuerungsebene erforderlich ist.
Dies gilt nicht für die Vernetzung von Instanzkonnektivität.
Diese Anweisungen gehen von einer OpenStack-Ansible-Installation mit LXC-Containern, VXLAN-Overlay und dem Linuxbridge ml2-Treiber aus.
Netzwerkliste¶
HOST_NET
(Physische Host-Verwaltung und Zugang zum Internet)CONTAINER_NET
(LXC-Container-Netzwerk verwendet Openstack Services)OVERLAY_NET
(VXLAN-Overlay-Netzwerk)
Nützliche Netzwerkdienstprogramme und Befehle:
# ip link show [dev INTERFACE_NAME]
# arp -n [-i INTERFACE_NAME]
# ip [-4 | -6] address show [dev INTERFACE_NAME]
# ping <TARGET_IP_ADDRESS>
# tcpdump [-n -nn] < -i INTERFACE_NAME > [host SOURCE_IP_ADDRESS]
# brctl show [BRIDGE_ID]
# iptables -nL
# arping [-c NUMBER] [-d] <TARGET_IP_ADDRESS>
Fehlerbehebung für Host-zu-Host-Datenverkehr in HOST_NET¶
Führen Sie die folgenden Prüfungen durch:
Überprüfen Sie die physische Verbindung von Hosts zum physischen Netzwerk
Überprüfen Sie die Schnittstellenverbindung (falls zutreffend)
Überprüfen Sie die VLAN-Konfigurationen und alle erforderlichen Trunking-Verbindungen zu den Edge-Ports des physischen Switches
Überprüfen Sie VLAN-Konfigurationen und alle erforderlichen Trunking-Verbindungen für Uplink-Ports auf physischen Switches (falls zutreffend)
Überprüfen Sie, ob sich die Hosts im selben IP-Subnetz befinden oder ob zwischen ihnen ein ordnungsgemäßes Routing stattfindet
Stellen Sie sicher, dass keine iptables auf die Hosts angewendet werden, die den Datenverkehr verweigern würden
IP-Adressen sollten auf die physische Schnittstelle, die Verbindungsschnittstelle, die markierte Unterschnittstelle oder in einigen Fällen auf die Brückenschnittstelle angewendet werden:
# ip address show dev bond0
14: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500..UP...
link/ether a0:a0:a0:a0:a0:01 brd ff:ff:ff:ff:ff:ff
inet 10.240.0.44/22 brd 10.240.3.255 scope global bond0
valid_lft forever preferred_lft forever
...
Fehlerbehebung für Host-zu-Host-Datenverkehr in CONTAINER_NET¶
Führen Sie die folgenden Prüfungen durch:
Überprüfen Sie die physische Verbindung von Hosts zum physischen Netzwerk
Überprüfen Sie die Schnittstellenverbindung (falls zutreffend)
Überprüfen Sie die VLAN-Konfigurationen und alle erforderlichen Trunking-Verbindungen zu den Edge-Ports des physischen Switches
Überprüfen Sie VLAN-Konfigurationen und alle erforderlichen Trunking-Verbindungen für Uplink-Ports auf physischen Switches (falls zutreffend)
Überprüfen Sie, ob sich die Hosts im selben Subnetz befinden oder ob zwischen ihnen ein ordnungsgemäßes Routing stattfindet
Stellen Sie sicher, dass keine iptables auf die Hosts angewendet werden, die den Datenverkehr verweigern würden
Überprüfen Sie, ob sich die physische Schnittstelle in der Bridge befindet
Überprüfen Sie, ob das Veth-Pair-Ende des Containers in
br-mgmt
steht
IP-Adresse sollte auf br-mgmt
angewendet werden:
# ip address show dev br-mgmt
18: br-mgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...UP...
link/ether a0:a0:a0:a0:a0:01 brd ff:ff:ff:ff:ff:ff
inet 172.29.236.44/22 brd 172.29.239.255 scope global br-mgmt
valid_lft forever preferred_lft forever
...
Die IP-Adresse sollte innerhalb des LXC-Containers auf eth1
angewendet werden:
# ip address show dev eth1
59: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...UP...
link/ether b1:b1:b1:b1:b1:01 brd ff:ff:ff:ff:ff:ff
inet 172.29.236.55/22 brd 172.29.239.255 scope global eth1
valid_lft forever preferred_lft forever
...
`` br-mgmt`` sollte veth-pair Enden von allen Containern und einer physikalischen Schnittstelle oder getagged-subinterface enthalten:
# brctl show br-mgmt
bridge name bridge id STP enabled interfaces
br-mgmt 8000.abcdef12345 no 11111111_eth1
22222222_eth1
...
bond0.100
99999999_eth1
...
Fehlerbehebung für Host-zu-Host-Datenverkehr auf OVERLAY_NET¶
Führen Sie die folgenden Prüfungen durch:
Überprüfen Sie die physische Verbindung von Hosts zum physischen Netzwerk
Überprüfen Sie die Schnittstellenverbindung (falls zutreffend)
Überprüfen Sie die VLAN-Konfigurationen und alle erforderlichen Trunking-Verbindungen zu den Edge-Ports des physischen Switches
Überprüfen Sie VLAN-Konfigurationen und alle erforderlichen Trunking-Verbindungen für Uplink-Ports auf physischen Switches (falls zutreffend)
Überprüfen Sie, ob sich die Hosts im selben Subnetz befinden oder ob zwischen ihnen ein ordnungsgemäßes Routing stattfindet
Stellen Sie sicher, dass keine iptables auf die Hosts angewendet werden, die den Datenverkehr verweigern würden
Überprüfen Sie, ob sich die physische Schnittstelle in der Bridge befindet
Überprüfen Sie, ob das Veth-Pair-Ende des Containers in
br-vxlan
steht
Die IP-Adresse sollte auf br-vxlan
angewendet werden:
# ip address show dev br-vxlan
21: br-vxlan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500...UP...
link/ether a0:a0:a0:a0:a0:02 brd ff:ff:ff:ff:ff:ff
inet 172.29.240.44/22 brd 172.29.243.255 scope global br-vxlan
valid_lft forever preferred_lft forever
...
Dienste überprüfen¶
Sie können den Status eines OpenStack-Dienstes überprüfen, indem Sie auf jeden Controller-Knoten zugreifen und den Befehl: service <SERVICE_NAME> status ausführen.
Weitere Informationen zum Überprüfen der OpenStack-Dienste finden Sie in den folgenden Links:
Dienste neu starten¶
Starten Sie Ihre OpenStack-Dienste neu, indem Sie auf jeden Controller-Knoten zugreifen. Einige OpenStack-Dienste erfordern einen Neustart von anderen Knoten in Ihrer Umgebung.
In der folgenden Tabelle sind die Befehle zum Neustart eines OpenStack-Dienstes aufgeführt.
OpenStack-Dienst |
Befehle |
---|---|
Abbildservice |
# service glance-api restart
|
Compute Service (Steuerungsknoten) |
# service nova-api-os-compute restart
# service nova-consoleauth restart
# service nova-scheduler restart
# service nova-conductor restart
# service nova-api-metadata restart
# service nova-novncproxy restart (if using novnc)
# service nova-spicehtml5proxy restart (if using spice)
|
Compute-Service (Rechenknoten) |
# service nova-compute restart
|
Netzwerkdienst |
# service neutron-server restart
# service neutron-dhcp-agent restart
# service neutron-l3-agent restart
# service neutron-metadata-agent restart
# service neutron-linuxbridge-agent restart
|
Netzwerkdienst (Rechenknoten) |
# service neutron-linuxbridge-agent restart
|
Blockspeicherdienst |
# service cinder-api restart
# service cinder-backup restart
# service cinder-scheduler restart
# service cinder-volume restart
|
Blockspeicherdienst |
# service manila-api restart
# service manila-data restart
# service manila-share restart
# service manila-scheduler restart
|
Objektspeicherdienst |
# service swift-account-auditor restart
# service swift-account-server restart
# service swift-account-reaper restart
# service swift-account-replicator restart
# service swift-container-auditor restart
# service swift-container-server restart
# service swift-container-reconciler restart
# service swift-container-replicator restart
# service swift-container-sync restart
# service swift-container-updater restart
# service swift-object-auditor restart
# service swift-object-expirer restart
# service swift-object-server restart
# service swift-object-reconstructor restart
# service swift-object-replicator restart
# service swift-object-updater restart
# service swift-proxy-server restart
|
Fehlerbehebung bei Problemen mit der Instanzienkonnektivität¶
In diesem Abschnitt wird die Fehlerbehebung für die Kommunikation mit der allgemeinen Instanz (VM) -Konnektivität behandelt. Dies gilt nicht für die Vernetzung von Instanzkonnektivität. Dies setzt eine OpenStack-Ansible-Installation unter Verwendung von LXC-Containern, VXLAN-Overlay und dem Linuxbridge ml2-Treiber voraus.
Datenflussbeispiel
COMPUTE NODE
+-------------+ +-------------+
+->"If VXLAN"+->+ *br vxlan +--->+ bond#.#00 +---+
| +-------------+ +-------------+ |
+-------------+ | +-----------------+
Instance +---> | brq bridge |++ +-->| physical network|
+-------------+ | +-----------------+
| +-------------+ +-------------+ |
+->"If VLAN"+->+ br vlan +--->+ bond1 +---+
+-------------+ +-------------+
NETWORK NODE
+-------------+ +-------------+
+->"If VXLAN"+->+ *bond#.#00 +--->+ *br vxlan +-->
| +-------------+ +-------------+ |
+----------------+ | +-------------+
|physical network|++ +--->+| brq bridge |+--> Neutron DHCP/Router
+----------------+ | +-------------+
| +-------------+ +-------------+ |
+->"If VLAN"+->+ bond1 +--->+ br vlan +-->
+-------------+ +-------------+
Vorläufige Fragen zur Fehlerbehebung:¶
Welcher Rechenknoten hostet die fragliche VM?
Welche Schnittstelle wird für den Netzwerkverkehr des Providers verwendet?
Welche Schnittstelle wird für VXLAN-Overlay verwendet?
Tritt das Konnektivitätsproblem bei der Instanz ein?
Tritt das Verbindungsproblem aus der Instanz aus?
Wie lautet die Absenderadresse des Datenverkehrs?
Wie lautet die Zieladresse des Datenverkehrs?
Gibt es einen Neutron Router im Spiel?
Welcher Netzwerkknoten (Container) wird vom Router gehostet?
Was ist der Tenant-Netzwerktyp?
Wenn VLAN:
Zeigt die physische Schnittstelle die Verbindung und alle VLANs ordnungsgemäß über das physische Netzwerk geleitet?
- Nein:
Überprüfen Sie Kabel, Steckplätze, physische Switchport-Konfiguration, Schnittstellen-/Bonding-Konfiguration und allgemeine Netzwerkkonfiguration. Siehe allgemeine Dokumentation zur Fehlerbehebung im Netzwerk.
- Ja:
Gut!
Fortsetzen!
Fahren Sie nicht fort, bis das physische Netzwerk ordnungsgemäß konfiguriert wurde.
Wird die IP-Adresse der Instanz vom DHCP-Namespace des Netzwerks oder anderen Instanzen im selben Netzwerk gepingt?
- Nein:
Überprüfen Sie die Protokolle der nova-Konsole, um festzustellen, ob die Instanz ihre IP-Adresse zu Beginn erhalten hat.
Prüfe Neutron
security-group-rules
, denken Sie darüber nach, eine ICMP-Regel zum Testen hinzuzufügen.Überprüfen Sie, ob Linux-Bridges die richtigen Schnittstellen enthalten. auf Rechen- und Netzwerkknoten.
Überprüfen Sie die Protokolle des Neutronen-DHCP-Agenten.
Überprüfen Sie Syslogs.
Überprüfen Sie die Protokolle der Neutron-Linux-Bridge.
- Ja:
Gut! Dies deutet darauf hin, dass die Instanz ihre IP-Adresse erhalten hat und lokale Netzwerkressourcen erreichen kann.
Fortsetzen!
Fahren Sie nicht fort, bis die Instanz eine IP-Adresse hat und lokale Netzwerkressourcen wie DHCP erreichen kann.
Wird die IP-Adresse der Instanz vom Gateway-Gerät (Neutron-Router-Namespace oder ein anderes Gateway-Gerät) gepingt?
- Nein:
Überprüfen Sie die Protokolle des Neutronen L3-Agenten (falls zutreffend).
Überprüfen Sie die Protokolle von Neutron linuxbridge.
Überprüfen Sie die Zuordnung der physischen Schnittstelle.
Überprüfen Sie die Neutron Router-Ports (falls zutreffend).
Überprüfen Sie, ob die Linux-Bridges die richtigen Schnittstellen für Rechner- und Netzwerkknoten enthalten.
Prüfe Neutron
security-group-rules
, denken Sie darüber nach, eine ICMP-Regel zum Testen hinzuzufügen.
- Ja:
Gut! Die Instanz kann ihr beabsichtigtes Gateway anpingen. Das Problem kann sich nördlich des Gateways oder im Zusammenhang mit dem Provider-Netzwerk befinden.
Überprüfen Sie
gateway
oder Host-Routen auf dem Neutron-Subnetz.Überprüfen Sie Neutron
security-group-rules
, überlegen Sie, ICMP-Regeln zum Testen hinzuzufügen.Überprüfen Sie die Neutron FloatingIP-Verbindungen (falls zutreffend).
Überprüfen Sie die Informationen zum externen Gateway des Neutron Routers (falls zutreffend).
Überprüfen Sie Upstream-Routen, NATs oder Access-Control-Listen.
Fahren Sie nicht fort, bis die Instanz das Gateway erreichen kann.
Wenn VXLAN:
Zeigt die physische Schnittstelle die Verbindung und alle VLANs ordnungsgemäß über das physische Netzwerk geleitet?
- Nein:
Überprüfen Sie Kabel, Steckplätze, physische Switchport-Konfiguration, Schnittstellen-/Bonding-Konfiguration und allgemeine Netzwerkkonfiguration. Siehe allgemeine Dokumentation zur Fehlerbehebung im Netzwerk.
- Ja:
Gut!
Fortsetzen!
Fahren Sie nicht fort, bis das physische Netzwerk ordnungsgemäß konfiguriert wurde.
Können sich VXLAN VTEP-Adressen gegenseitig pingen?
- Nein:
Check
br-vxlan
interface on Compute and Network nodesÜberprüfen Sie veth-Paare zwischen Containern und Linux-Bridges auf dem Host.
Überprüfen Sie, ob die Linux-Bridges die richtigen Schnittstellen für Rechner- und Netzwerkknoten enthalten.
- Ja:
Überprüfen Sie die ml2-Konfigurationsdatei auf lokale VXLAN-IP- und andere VXLAN-Konfigurationseinstellungen.
- Überprüfen Sie die VTEP Lernmethode (Multicast oder L2Population):
Stellen Sie bei Multicast sicher, dass die physischen Switches Multicast-Datenverkehr ordnungsgemäß zulassen und verteilen.
Fahren Sie nicht fort, bis VXLAN-Endpunkte zueinander erreichbar sind.
Wird die IP-Adresse der Instanz vom DHCP-Namespace des Netzwerks oder anderen Instanzen im selben Netzwerk gepingt?
- Nein:
Überprüfen Sie die Nova-Konsolenprotokolle, um festzustellen, ob die Instanz ihre IP-Adresse zu Beginn erhalten hat.
Prüfe Neutron
security-group-rules
, denken Sie darüber nach, eine ICMP-Regel zum Testen hinzuzufügen.Überprüfen Sie, ob die Linux-Bridges die richtigen Schnittstellen für Rechner- und Netzwerkknoten enthalten.
Überprüfen Sie die Protokolle des Neutronen-DHCP-Agenten.
Überprüfen Sie Syslogs.
Überprüfen Sie die Protokolle der Neutron-Linux-Bridge.
Überprüfen Sie, ob die Bridge Forwarding Database (fdb) die richtigen Einträge sowohl im Compute- als auch im Neutron-Agent-Container enthält.
- Ja:
Gut! Dies deutet darauf hin, dass die Instanz ihre IP-Adresse erhalten hat und lokale Netzwerkressourcen erreichen kann.
Fahren Sie nicht fort, bis die Instanz eine IP-Adresse hat und lokale Netzwerkressourcen erreichen kann.
Wird die IP-Adresse der Instanz vom Gateway-Gerät (Neutron-Router-Namespace oder ein anderes Gateway-Gerät) gepingt?
- Nein:
Überprüfen Sie die Protokolle des Neutronen L3-Agenten (falls zutreffend).
Überprüfen Sie die Protokolle der Neutron-Linux-Bridge.
Überprüfen Sie die Zuordnung der physischen Schnittstelle.
Überprüfen Sie die Neutron-Router-Ports (falls zutreffend).
Überprüfen Sie, ob die Linux-Bridges die richtigen Schnittstellen für Rechner- und Netzwerkknoten enthalten.
Prüfe Neutron
security-group-rules
, denken Sie darüber nach, eine ICMP-Regel zum Testen hinzuzufügen.Überprüfen Sie, ob die Bridge Forwarding Database (fdb) die richtigen Einträge sowohl im Compute- als auch im Neutron-Agent-Container enthält.
- Ja:
Gut! Die Instanz kann ihr beabsichtigtes Gateway anpingen.
Überprüfen Sie Gateway- oder Host-Routen im Neutron-Subnetz.
Überprüfen Sie Neutron
security-group-rules
, überlegen Sie, ICMP-Regeln zum Testen hinzuzufügen.Überprüfen Sie die Neutron FloatingIP-Verbindungen (falls zutreffend).
Überprüfen Sie die Informationen zum externen Gateway des Neutron Routers (falls zutreffend).
Überprüfen Sie vorgelagerte Routen, NATs oder
access-control-list
.
Diagnose Image-Probleme¶
The glance-api
handles the API interactions and image store.
To troubleshoot problems or errors with the Image service, refer to
/var/log/glance-api.log
inside the glance api container.
Sie können auch die folgenden Aktivitäten ausführen, die Protokolle generieren können, um Identitätsprobleme zu beheben:
Laden Sie ein Abbild herunter, um sicherzustellen, dass ein Abbild aus dem Speicher gelesen werden kann.
Laden Sie ein Abbild hoch, um zu testen, ob das Abbild registriert und in den Abbildspeicher geschrieben wird.
Führen Sie den Befehl
openstack image list
aus, um sicherzustellen, dass die API und die Registrierung funktionieren.
Für ein Beispiel und mehr Informationen, schauen Sie Verify operation <https://docs.openstack.org/glance/latest/install/verify.html>_. und Manage Images <https://docs.openstack.org/glance/latest/admin/manage-images.html>_
RabbitMQ Probleme¶
Analysieren Sie RabbitMQ-Warteschlangen¶
Analysieren Sie OpenStack-Dienstprotokolle und RabbitMQ-Protokolle¶
Fehlgeschlagene Sicherheitsverhärtung nach Host-Kernel-Upgrade ab Version 3.13¶
Ubuntu-Kernel-Pakete, die neuer als Version 3.13 sind, enthalten eine Änderung in der Modulbenennung von nf_conntrack
nach br_netfilter
. Führen Sie nach dem Upgrade des Kernels das Playbook openstack-hosts-setup.yml
für diese Hosts aus. Weitere Informationen finden Sie unter OSA-Fehler 157996.
Gespeicherte Ansible-Fakten¶
Zu Beginn eines Playbook-Laufs werden Informationen zu jedem Host gesammelt, wie zum Beispiel:
Linux-Verteilung
Kernelversion
Netzwerk Schnittstellen
Um die Leistung insbesondere in großen Bereitstellungen zu verbessern, können Sie Host-Fakten und -Informationen zwischenspeichern.
OpenStack-Ansible aktiviert standardmäßig das Faktcachen. Die Fakten werden in JSON-Dateien in /etc/openstack_deploy/ansible_facts
zwischengespeichert.
Das Fact-Caching kann durch Ausführen von export ANSIBLE_CACHE_PLUGIN=memory
deaktiviert werden. Um dies dauerhaft einzustellen, setzen Sie diese Variable in /usr/local/bin/openstack-ansible.rc
. Weitere Informationen finden Sie in der Ansible-Dokumentation zum fact caching.
Regenerierung von zwischengespeicherten Fakten erzwingen¶
Cache-Fakten sind möglicherweise falsch, wenn der Host ein Kernel-Upgrade oder neue Netzwerkschnittstellen erhält. Neu erstellte Bridges stören auch Cache-Fakten.
Dies kann zu unerwarteten Fehlern beim Ausführen von Playbooks führen und erfordert, dass zwischengespeicherte Fakten neu generiert werden.
Führen Sie den folgenden Befehl aus, um alle aktuell zwischengespeicherten Fakten für alle Hosts zu entfernen:
# rm /etc/openstack_deploy/ansible_facts/*
Beim nächsten Playbook-Lauf werden neue Fakten gesammelt und zwischengespeichert.
Um die Fakten für einen einzelnen Host zu löschen, suchen Sie seine Datei in /etc/openstack_deploy/ansible_facts/
und entfernen Sie sie. Jeder Host verfügt über eine JSON-Datei, die nach ihrem Hostnamen benannt ist. Die Fakten für diesen Host werden beim nächsten Playbook-Lauf neu generiert.
Fehlerhafte Ansible-Playbooks während eines Upgrades¶
Container-Netzwerkprobleme¶
Alle LXC-Container auf dem Host verfügen über mindestens zwei virtuelle Ethernet-Schnittstellen:
eth0 im Container verbindet sich mit` lxcbr0` auf dem Host
eth1 im Container verbindet sich mit` br-mgmt` auf dem Host
Einige Container wie cinder
, glance
,``neutron_agents`` und swift_proxy
haben mehr als zwei Schnittstellen, um ihre Funktionen zu unterstützen.
Vorhersagbare Schnittstellenbenennung¶
Auf dem Host werden alle virtuellen Ethernet-Geräte anhand ihres Containers sowie des Namens der Schnittstelle im Container benannt:
${CONTAINER_UNIQUE_ID}_${NETWORK_DEVICE_NAME}
Ein All-in-One-Build (AIO) könnte beispielsweise einen Utility-Container namens aio1_utility_container-d13b7132 bereitstellen. Dieser Container wird zwei Netzwerkschnittstellen haben: d13b7132_eth0 und` d13b7132_eth1`.
Eine andere Option wäre, die LXC-Tools zum Abrufen von Informationen über den Dienstprogrammcontainer zu verwenden. Beispielsweise:
# lxc-info -n aio1_utility_container-d13b7132
Name: aio1_utility_container-d13b7132
State: RUNNING
PID: 8245
IP: 10.0.3.201
IP: 172.29.237.204
CPU use: 79.18 seconds
BlkIO use: 678.26 MiB
Memory use: 613.33 MiB
KMem use: 0 bytes
Link: d13b7132_eth0
TX bytes: 743.48 KiB
RX bytes: 88.78 MiB
Total bytes: 89.51 MiB
Link: d13b7132_eth1
TX bytes: 412.42 KiB
RX bytes: 17.32 MiB
Total bytes: 17.73 MiB
Die Link:
-Zeilen zeigen die Netzwerkschnittstellen, die an den Utility-Container angehängt sind.
Überprüfen Sie den Netzwerkverkehr des Containers¶
Um den Datenverkehr auf der br-mgmt
-Bridge zu dumpen, verwenden Sie `` tcpdump``, um die gesamte Kommunikation zwischen den verschiedenen Containern anzuzeigen. Um den Fokus einzugrenzen, führen Sie `` tcpdump`` nur auf der gewünschten Netzwerkschnittstelle der Container aus.
Inventar von der Sicherung wiederherstellen¶
OpenStack-Ansible verwaltet ein laufendes Inventararchiv. Wenn eine Änderung in das System eingeführt wurde, die das Inventar beschädigt hat oder auf andere Weise ein unvorhergesehenes Problem verursacht hat, kann das Inventar auf eine frühere Version zurückgesetzt werden. Die Sicherungsdatei /etc/openstack_deploy/backup_openstack_inventory.tar
enthält eine Reihe von zeitgestempelten Inventaren, die bei Bedarf wiederhergestellt werden können.
Beispiel für die Wiederherstellung eines Inventars
mkdir /tmp/inventory_restore
cp /etc/openstack_deploy/backup_openstack_inventory.tar /tmp/inventory_restore/backup_openstack_inventory.tar
cd /tmp/inventory_restore
tar xf backup_openstack_inventory.tar
# Identify the inventory you wish to restore as the running inventory
cp openstack_inventory.json-YYYYMMDD_SSSSSS.json /etc/openstack_deploy/openstack_inventory.json
cd -
rm -rf /tmp/inventory_restore
Nach Abschluss dieser Operation wird das Inventar auf die frühere Version zurückgesetzt.