[ 英语 | 印度尼西亚语 | 俄语 ]

故障排除¶

本章节旨在帮助您排查和解决 OpenStack-Ansible 部署中的操作问题。

网络¶

本节重点介绍 OpenStack 控制平面正常运行所需的通用主机间通信故障排除。

这不涵盖与实例连接性相关的任何网络问题。

这些说明假定使用 LXC 容器、ML2/OVS 的 VXLAN 覆盖网络以及 ML2/OVN 驱动程序的 Geneve 覆盖网络进行 OpenStack-Ansible 安装。

网络列表¶

HOST_NET（物理主机管理和互联网访问）
MANAGEMENT_NET（用于 OpenStack 服务的 LXC 容器网络）
OVERLAY_NET（OVS 的 VXLAN 覆盖网络，OVN 的 Geneve 覆盖网络）

有用的网络实用程序和命令

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

排查 HOST_NET 上的主机间流量¶

执行以下检查

检查主机到物理网络的物理连接
检查接口绑定（如果适用）
检查 VLAN 配置以及物理交换机上的边缘端口所需的任何中继
检查 VLAN 配置以及物理交换机上的上行端口所需的任何中继（如果适用）
检查主机是否在同一 IP 子网中，或者它们之间是否有适当的路由
检查是否有应用于主机的防火墙（firewalld、ufw 等）规则会阻止流量

应将 IP 地址应用于物理接口、绑定接口、标记子接口或在某些情况下是桥接接口

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

排查 MANAGEMENT_NET 上的主机间流量¶

执行以下检查

检查主机到物理网络的物理连接
检查接口绑定（如果适用）
检查 VLAN 配置以及物理交换机上的边缘端口所需的任何中继
检查 VLAN 配置以及物理交换机上的上行端口所需的任何中继（如果适用）
检查主机是否在同一子网中，或者它们之间是否有适当的路由
检查是否有应用于主机的防火墙（firewalld、ufw 等）规则会阻止流量
检查以验证物理接口是否在桥接中
检查以验证容器中的 veth-pair 端是否在 br-mgmt 中

应将 IP 地址应用于 br-mgmt

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

应将 IP 地址应用于 LXC 容器内的 eth1

# 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 应包含来自所有容器的 veth-pair 端和一个物理接口或标记子接口

# brctl show br-mgmt
bridge name bridge id          STP enabled  interfaces
br-mgmt     8000.abcdef12345   no           11111111_eth1
                                            22222222_eth1
                                            ...
                                            bond0.100
                                            99999999_eth1
                                            ...

您还可以使用 ip 命令来显示桥接

# ip link show master br-mgmt

12: bond0.100@bond0: ... master br-mgmt state UP mode DEFAULT group default qlen 1000
....
51: 11111111_eth1_eth1@if3: ... master br-mgmt state UP mode DEFAULT group default qlen 1000
....

排查 OVERLAY_NET 上的主机间流量¶

执行以下检查

检查主机到物理网络的物理连接
检查接口绑定（如果适用）
检查 VLAN 配置以及物理交换机上的边缘端口所需的任何中继
检查 VLAN 配置以及物理交换机上的上行端口所需的任何中继（如果适用）
检查主机是否在同一子网中，或者它们之间是否有适当的路由
检查是否有应用于主机的防火墙（firewalld、ufw 等）规则会阻止流量
检查以验证物理接口是否在桥接中
检查以验证容器中的 veth-pair 端是否在 br-vxlan 中

应将 IP 地址应用于 br-vxlan

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

检查服务¶

您可以通过访问每个控制器节点并运行 systemctl status <SERVICE_NAME> 来检查 OpenStack 服务的状态。

有关验证 OpenStack 服务的更多信息，请参阅以下链接

有关管理 LXC 的一些有用命令，请参阅命令行参考。

重启服务¶

通过访问每个控制器节点来重启您的 OpenStack 服务。某些 OpenStack 服务可能需要从您环境中的其他节点重启。

下表列出了重启 OpenStack 服务的命令。

重启 OpenStack 服务¶
OpenStack 服务	命令
镜像服务	# systemctl restart glance-api
计算服务（控制器节点）	# systemctl restart nova-api-os-compute # systemctl restart nova-scheduler # systemctl restart nova-conductor # systemctl restart nova-api-metadata # systemctl restart nova-novncproxy (if using noVNC) # systemctl restart nova-spicehtml5proxy (if using SPICE)
计算服务（计算节点）	# systemctl restart nova-compute
网络服务（控制器节点，用于 OVS）	# systemctl restart neutron-server # systemctl restart neutron-dhcp-agent # systemctl restart neutron-l3-agent # systemctl restart neutron-metadata-agent # systemctl restart neutron-openvswitch-agent
网络服务（计算节点，用于 OVS）	# systemctl restart neutron-openvswitch-agent
网络服务（控制器节点，用于 OVN）	# systemctl restart neutron-server # systemctl restart neutron-ovn-maintenance-worker # systemctl restart neutron-periodic-workers
网络服务（计算节点，用于 OVN）	# systemctl restart neutron-ovn-metadata-agent
块存储服务	# systemctl restart cinder-api # systemctl restart cinder-backup # systemctl restart cinder-scheduler # systemctl restart cinder-volume
共享文件系统服务	# systemctl restart manila-api # systemctl restart manila-data # systemctl restart manila-share # systemctl restart manila-scheduler
对象存储服务	# systemctl restart swift-account-auditor # systemctl restart swift-account-server # systemctl restart swift-account-reaper # systemctl restart swift-account-replicator # systemctl restart swift-container-auditor # systemctl restart swift-container-server # systemctl restart swift-container-reconciler # systemctl restart swift-container-replicator # systemctl restart swift-container-sync # systemctl restart swift-container-updater # systemctl restart swift-object-auditor # systemctl restart swift-object-expirer # systemctl restart swift-object-server # systemctl restart swift-object-reconstructor # systemctl restart swift-object-replicator # systemctl restart swift-object-updater # systemctl restart swift-proxy-server

排查实例连接问题¶

本节将重点介绍通用实例连接通信的故障排除。这不涵盖与实例连接性相关的任何网络问题。假设使用 LXC 容器、ML2/OVS 的 VXLAN 覆盖网络以及 ML2/OVN 驱动程序的 OpenStack-Ansible 安装。

数据流示例（用于 OVS）

COMPUTE NODE
                                               +-------------+    +-------------+
                               +->"If VXLAN"+->+  *br vxlan  +--->+  bond0.#00  +---+
                               |               +-------------+    +-------------+   |
                +-------------+                                                      |   +-----------------+
Instance +--->  | qbr bridge  |++                                                    +-->| physical network|
                +-------------+                                                      |   +-----------------+
                               |               +-------------+    +-------------+   |
                               +->"If  VLAN"+->+   br vlan   +--->+    bond1    +---+
                                               +-------------+    +-------------+



NETWORK NODE
                                  +-------------+    +-------------+
                  +->"If VXLAN"+->+  *bond#.#00 +--->+ *br-vxlan   +-->
                  |               +-------------+    +-------------+  |
+----------------+                                                     |     +-------------+
|physical network|++                                                   +--->+|  qbr bridge |+--> Neutron DHCP/Router
+----------------+                                                     |     +-------------+
                  |               +-------------+    +-------------+  |
                  +->"If  VLAN"+->+   bond1     +--->+  br-vlan    +-->
                                  +-------------+    +-------------+

数据流示例（用于 OVN）

   COMPUTE NODE
                                                +-------------+    +-------------+
                               +->"If Geneve"+->+  *br-vxlan  +--->+  bond0.#00  +---+
                               |                +-------------+    +-------------+   |
                +-------------+                                                      |   +-----------------+
Instance +--->  |   br-int    |++                                                    +-->| physical network|
                +-------------+                                                      |   +-----------------+
                               |              +-------------+    +-------------+     |
                               +->"If VLAN"+->+   br-vlan   +--->+    bond1    +-----+
                                              +-------------+    +-------------+

初步故障排除问题¶

托管该实例的计算节点是哪个？
哪个接口用于提供程序网络流量？
哪个接口用于 VXLAN（Geneve）覆盖网络？
是否有进入实例的连接问题？
是否有从实例发出的连接问题？
流量的源地址是什么？
流量的目标地址是什么？
是否正在使用 Neutron 路由器？
路由器托管在哪个网络节点（容器）中？
项目网络类型是什么？

如果是 VLAN

物理接口是否显示链路，所有 VLAN 是否正确地中继到物理网络上的边缘端口？

否

检查电缆、安装、物理交换机端口配置、接口/绑定配置以及常规网络配置。请参阅常规网络故障排除文档。

是

很好！
继续！

重要提示

在正确配置物理网络之前不要继续。

实例的 IP 地址是否可以从网络的 DHCP 命名空间或其他位于同一网络中的实例 ping 通？

否

检查 nova 控制台日志，查看实例最初是否收到了其 IP 地址。
检查 security-group-rules，考虑添加允许 ICMP 规则进行测试。
检查计算和网络节点上的 OVS 桥接是否包含正确的接口。
检查 Neutron DHCP 代理日志。
检查系统日志。
检查 Neutron Open vSwitch 代理日志。

是

很好！这表明实例已收到其 IP 地址，并且可以访问本地网络资源。
继续！

重要提示

在实例具有 IP 地址并且可以访问 DHCP 等本地网络资源之前不要继续。

实例的 IP 地址是否可以从网关设备（Neutron 路由器命名空间或其他网关设备）ping 通？

否

检查 Neutron L3 代理日志（如果适用）。
检查 Neutron Open vSwitch 日志。
检查物理接口映射。
检查 Neutron 路由器端口（如果适用）。
检查计算和网络节点上的 OVS 桥接是否包含正确的接口。
检查 security-group-rules，考虑添加允许 ICMP 规则进行测试。如果使用 OVN，则另外检查
检查所有节点上的 ovn-controller。
验证 ovn-northd 是否正在运行且数据库是否正常。
确保 ovn-metadata-agent 处于活动状态。
查看 ovn-controller、ovn-northd 的日志。

是

很好！实例可以 ping 它的预期网关。问题可能在网关以北或与提供程序网络相关。
检查 Neutron 子网上的“网关”或主机路由。
检查 security-group-rules，考虑添加 ICMP 规则进行测试。
检查浮动 IP 关联（如果适用）。
检查 Neutron 路由器外部网关信息（如果适用）。
检查上游路由、NAT 或访问控制列表。

重要提示

在实例可以访问其网关之前不要继续。

如果是 VXLAN（Geneve）

物理接口是否显示链路，所有 VLAN 是否正确地中继到物理网络上的边缘端口？

否

检查电缆、安装、物理交换机端口配置、接口/绑定配置以及常规网络配置。请参阅常规网络故障排除文档。

是

很好！
继续！

重要提示

在正确配置物理网络之前不要继续。

VXLAN（Geneve）VTEP 地址是否可以相互 ping 通？

否

检查计算和网络节点上的 br-vxlan 接口。
检查容器和主机上的 Linux 桥接之间的 veth 对。
检查计算和网络节点上的 OVS 桥接是否包含正确的接口。

是

检查 ml2 配置文件中的本地 VXLAN（Geneve）IP 和其他 VXLAN（Geneve）配置设置。
检查 VTEP 学习方法（组播或 l2population）
- 如果是组播，请确保物理交换机正在正确地允许和分发组播流量。

重要提示

在 VXLAN（Geneve）端点之间具有可达性之前不要继续。

实例的 IP 地址是否可以从网络的 DHCP 命名空间或其他位于同一网络中的实例 ping 通？

否

检查 nova 控制台日志，查看实例最初是否收到了其 IP 地址。
检查 security-group-rules，考虑添加允许 ICMP 规则进行测试。
检查计算和网络节点上的 OVS 桥接是否包含正确的接口。
检查 Neutron DHCP 代理日志。
检查系统日志。
检查 Neutron Open vSwitch 代理日志。
检查计算和 Neutron 代理容器上的桥接转发数据库（fdb）是否包含正确的条目 (ovs-appctl fdb/show br-int)。

是

很好！这表明实例已收到其 IP 地址，并且可以访问本地网络资源。

重要提示

在实例具有 IP 地址并且可以访问本地网络资源之前不要继续。

实例的 IP 地址是否可以从网关设备（Neutron 路由器命名空间或其他网关设备）ping 通？

否

检查 Neutron L3 代理日志（如果适用）。
检查 Neutron Open vSwitch 代理日志。
检查物理接口映射。
检查 Neutron 路由器端口（如果适用）。
检查计算和网络节点上的 OVS 桥接是否包含正确的接口。
检查 security-group-rules，考虑添加允许 ICMP 规则进行测试。
检查计算和 Neutron 代理容器上的桥接转发数据库（fdb）是否包含正确的条目 (ovs-appctl fdb/show br-int)。如果使用 OVN，则另外检查
检查所有节点上的 ovn-controller。
验证 ovn-northd 是否正在运行且数据库是否正常。
确保 ovn-metadata-agent 处于活动状态。
查看 ovn-controller、ovn-northd 的日志。

是

很好！实例可以 ping 它的预期网关。
检查 Neutron 子网上的网关或主机路由。
检查 security-group-rules，考虑添加 ICMP 规则进行测试。
检查 Neutron 浮动 IP 关联（如果适用）。
检查 Neutron 路由器外部网关信息（如果适用）。
检查上游路由、NAT 或 access-control-lists。

诊断 Image 服务问题¶

glance-api 处理 API 交互和镜像存储。

要排查 Image 服务的任何问题或错误，请参阅 glance api 容器内的 /var/log/glance-api.log。

您还可以进行以下活动，这些活动可能会生成日志以帮助识别问题

下载镜像，以确保可以从存储中读取镜像。
上传镜像，以测试镜像是否正在注册并写入镜像存储。
运行 openstack image list 命令，以确保 API 和注册表正在工作。

有关示例和更多信息，请参阅验证操作和管理镜像。

缓存的 Ansible 事实问题¶

在 playbook 运行开始时，会收集有关每个主机的相关信息，例如

Linux 发行版
内核版本
网络接口

为了提高性能，尤其是在大型部署中，您可以缓存主机事实和信息。

OpenStack-Ansible 默认情况下启用事实缓存。事实缓存在 /etc/openstack_deploy/ansible_facts 中的 JSON 文件中。

可以通过运行 export ANSIBLE_CACHE_PLUGIN=memory 来禁用事实缓存。要永久设置此变量，请在 /usr/local/bin/openstack-ansible.rc 中设置此变量。有关更多详细信息，请参阅 Ansible 文档中的事实缓存。

强制重新生成缓存的事实¶

如果主机收到内核升级或新的网络接口，则缓存的事实可能不正确。新创建的桥接也会破坏缓存的事实。

这可能导致运行 playbook 时出现意外错误，并需要重新生成缓存的事实。

运行以下命令以删除所有主机当前缓存的事实

# rm /etc/openstack_deploy/ansible_facts/*

在下一次 playbook 运行时，将收集并缓存新的事实。

要清除单个主机的 facts，请在 /etc/openstack_deploy/ansible_facts/ 中找到其文件并将其删除。每个主机都有一个以其主机名命名的 JSON 文件。该主机的 facts 将在下一次 playbook 运行时重新生成。

重建 Python 虚拟环境¶

在某些情况下，您可能需要强制重建服务的 Python 虚拟环境。如果 python_venv_build 角色失败（例如，由于临时软件包冲突），或者您希望在手动修改后重置虚拟环境，则可能需要这样做。

有两个变量控制重建过程

venv_rebuild — 将虚拟环境重置为其预期状态，而无需重建 wheels。通常，如果服务版本未更改并且只需要恢复 venv 状态，则这就足够了。
venv_wheels_rebuild — 此外，强制重建 Python wheels。如果服务版本已更改或其 venv 要求已修改，则可能需要这样做。

要触发特定服务的重建，请使用以下环境变量重新运行其 playbook

# reset the venv state
openstack-ansible openstack.osa.nova -e venv_rebuild=true

# reset the venv state and rebuild wheels
openstack-ansible openstack.osa.nova -e venv_rebuild=true -e venv_wheels_rebuild=true

容器网络问题¶

主机上的所有 LXC 容器至少有两个虚拟以太网接口

eth0 在容器中连接到主机上的 lxcbr0
eth1 在容器中连接到主机上的 br-mgmt

注意

一些容器，例如 cinder、glance、neutron_agents 和 swift_proxy 具有多个接口来支持其功能。

可预测的接口命名¶

在主机上，所有虚拟以太网设备都根据其容器以及容器内的接口名称进行命名

${CONTAINER_UNIQUE_ID}_${NETWORK_DEVICE_NAME}

例如，一个一体化 (AIO) 构建可能会提供一个名为 aio1_utility_container-d13b7132 的实用容器。该容器将有两个网络接口：d13b7132_eth0 和 d13b7132_eth1。

另一种选择是使用 LXC 工具来检索有关实用容器的信息。例如

# 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

包含 Link: 的行将显示连接到实用容器的网络接口。

检查容器网络流量¶

要转储 br-mgmt 网桥上的流量，请使用 tcpdump 查看各种容器之间的所有通信。为了缩小范围，仅在容器所需网络接口上运行 tcpdump。

从备份恢复清单¶

OpenStack-Ansible 维护着运行中的清单存档。如果系统引入了破坏清单或导致其他意外问题的更改，可以将清单恢复到早期版本。备份文件 /etc/openstack_deploy/backup_openstack_inventory.tar 包含一组带有时间戳的清单，可以根据需要进行恢复。

示例清单恢复过程。

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

完成此操作后，清单将恢复到早期版本。

故障排除

故障排除¶

网络¶

网络列表¶

排查 HOST_NET 上的主机间流量¶

排查 MANAGEMENT_NET 上的主机间流量¶

排查 OVERLAY_NET 上的主机间流量¶

检查服务¶

重启服务¶

排查实例连接问题¶

初步故障排除问题¶

诊断 Image 服务问题¶

缓存的 Ansible 事实问题¶

强制重新生成缓存的事实¶

重建 Python 虚拟环境¶

容器网络问题¶

可预测的接口命名¶

检查容器网络流量¶

从备份恢复清单¶

openstack-ansible 32.0.0.0rc2.dev9

页面内容