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

Die IP-Adresse sollte in den erforderlichen LXC-Containern auf eth10 angewendet werden:

# ip address show dev eth10
67: eth10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 150...UP...
link/ether b1:b1:b1:b1:b1:02 brd ff:ff:ff:ff:ff:ff
inet 172.29.240.55/22 brd 172.29.243.255 scope global eth10
   valid_lft forever preferred_lft forever
   ...

br-vxlan sollte veth-pair-Enden von erforderlichen LXC-Containern und einer physischen Schnittstelle oder getagged-subinterface enthalten:

# brctl show br-vxlan
bridge name     bridge id          STP enabled  interfaces
br-vxlan        8000.ghijkl123456  no           bond1.100
                                                3333333_eth10

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.

Neustart der OpenStack-Dienste¶
OpenStack-Dienst	Befehle
Abbildservice	# service glance-registry restart # 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   +-->+*Container eth10 +
                  |               +-------------+    +-------------+   +-----------------+
+----------------+                                                                         |       +-------------+
|physical network|++                                                                       +--->+ |  brq bridge  |+--> Neutron DHCP/Router
+----------------+                                                                         |       +-------------+
                  |               +-------------+    +-------------+   +-----------------+
                  +->"If  VLAN"+->+   bond1     +--->+  br vlan    +-->+ Container eth11 +
                                  +-------------+    +-------------+   +-----------------+

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!

Wichtig

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!

Wichtig

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.

Wichtig

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!

Wichtig

Fahren Sie nicht fort, bis das physische Netzwerk ordnungsgemäß konfiguriert wurde.

Können sich VXLAN VTEP-Adressen gegenseitig pingen?

Nein:

Überprüfen Sie die br-vxlan-Schnittstelle in Compute und eth10 im Neutron-Netzwerkagent-Container.
Ü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.

Wichtig

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.

Wichtig

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¶

Die glance-registry behandelt die Datenbankoperationen zum Verwalten des Speichers des Abbildindex und der Eigenschaften. Die glance-api behandelt die API-Interaktionen und den Abbildspeicher.

Um Probleme oder Fehler mit dem Image-Dienst zu beheben, finden Sie unter /var/log/glance-api.log und /var/log/glance-registry.log im glossy 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

Bemerkung

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.

Fehlerbehebung

Fehlerbehebung¶

Vernetzung¶

Netzwerkliste¶

Fehlerbehebung für Host-zu-Host-Datenverkehr in HOST_NET¶

Fehlerbehebung für Host-zu-Host-Datenverkehr in CONTAINER_NET¶

Fehlerbehebung für Host-zu-Host-Datenverkehr auf OVERLAY_NET¶

Dienste überprüfen¶

Dienste neu starten¶

Fehlerbehebung bei Problemen mit der Instanzienkonnektivität¶

Vorläufige Fragen zur Fehlerbehebung:¶

Diagnose Image-Probleme¶

RabbitMQ Probleme¶

Analysieren Sie RabbitMQ-Warteschlangen¶

Analysieren Sie OpenStack-Dienstprotokolle und RabbitMQ-Protokolle¶

Fehlgeschlagene Sicherheitsverhärtung nach Host-Kernel-Upgrade ab Version 3.13¶

Gespeicherte Ansible-Fakten¶

Regenerierung von zwischengespeicherten Fakten erzwingen¶

Fehlerhafte Ansible-Playbooks während eines Upgrades¶

Container-Netzwerkprobleme¶

Vorhersagbare Schnittstellenbenennung¶

Überprüfen Sie den Netzwerkverkehr des Containers¶

Inventar von der Sicherung wiederherstellen¶

openstack-ansible

Page Contents