[ English | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]
Dieses Kapitel soll zur Untersuchung und Behebung von Betriebsproblemen in einer OpenStack-Ansible-Bereitstellung beitragen.
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.
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>
Führen Sie die folgenden Prüfungen durch:
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
...
Führen Sie die folgenden Prüfungen durch:
br-mgmt
stehtIP-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
...
Führen Sie die folgenden Prüfungen durch:
br-vxlan
stehtDie 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
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:
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-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
|
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 +
+-------------+ +-------------+ +-----------------+
Wenn VLAN:
Zeigt die physische Schnittstelle die Verbindung und alle VLANs ordnungsgemäß über das physische Netzwerk geleitet?
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?
security-group-rules
, denken Sie darüber nach, eine ICMP-Regel zum Testen hinzuzufügen.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?
security-group-rules
, denken Sie darüber nach, eine ICMP-Regel zum Testen hinzuzufügen.gateway
oder Host-Routen auf dem Neutron-Subnetz.security-group-rules
, überlegen Sie, ICMP-Regeln zum Testen hinzuzufügen.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?
Wichtig
Fahren Sie nicht fort, bis das physische Netzwerk ordnungsgemäß konfiguriert wurde.
Können sich VXLAN VTEP-Adressen gegenseitig pingen?
br-vxlan
-Schnittstelle in Compute und eth10
im Neutron-Netzwerkagent-Container.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?
security-group-rules
, denken Sie darüber nach, eine ICMP-Regel zum Testen hinzuzufügen.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?
security-group-rules
, denken Sie darüber nach, eine ICMP-Regel zum Testen hinzuzufügen.security-group-rules
, überlegen Sie, ICMP-Regeln zum Testen hinzuzufügen.access-control-list
.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:
openstack image list
aus, um sicherzustellen, dass die API und die Registrierung funktionieren.For an example and more information, see Verify operation <https://docs.openstack.org/glance/stein/install/verify.html>_. and Manage Images <https://docs.openstack.org/glance/stein/admin/manage-images.html>_
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.
Zu Beginn eines Playbook-Laufs werden Informationen zu jedem Host gesammelt, wie zum Beispiel:
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.
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.
Alle LXC-Container auf dem Host verfügen über mindestens zwei virtuelle Ethernet-Schnittstellen:
Bemerkung
Einige Container wie cinder
, glance
,``neutron_agents`` und swift_proxy
haben mehr als zwei Schnittstellen, um ihre Funktionen zu unterstützen.
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.
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.
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.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.