1
2
3
4
5
6
7
作者：李晓辉

联系方式：

1. 微信：Lxh_Chat

2. 邮箱：939958092@qq.com

故障排除概述

要是想排查 OpenStack 服务的故障，得先搞清楚请求是怎么在服务的各个组件之间流转的。就像侦探追踪线索一样，顺着这个流程，就能找到问题的根源。

下面这几个方法特别好用：

  1. 验证服务状态：先看看那些关键的服务是不是都正常运行着。要是服务都没启动，那问题可就很明显了。

  2. 开启调试模式：用 OpenStack 客户端的时候，切换到调试模式，这样就能看到更多细节，说不定就能发现隐藏的错误。

  3. 查看日志文件：日志就像是服务的“黑匣子”，里面记录了各种操作的痕迹和错误信息。仔细瞅瞅，说不定就能找到问题的线索。

一般性故障排除工具

说到排查OpenStack的问题，其实方法还挺多的。想搞定OpenStack服务的故障，关键是要搞清楚请求在服务各个组件之间流转的路径。下面这些方法对付OpenStack问题可太管用了。

先说说验证服务吧，得确保该跑的服务都正常运行着。然后可以用OpenStack客户端的调试模式，看看有没有报错。再就是瞅瞅日志文件，说不定能找到问题的蛛丝马迹。

pgrep

说到排查工具，OpenStack是在Linux环境下跑的，这可就方便了，Linux里那些常用的命令都能派上用场。比如ps、pgrep这些命令，能帮你看看进程的运行状态。要是用pgrep命令再带上-l选项，就能列出进程名和它们的PID了。比如，用pgrep -l nova命令，就能看到当前正在运行的nova进程，超方便的！

1
2
3
4
5
6
7
8
(overcloud) [stack@director ~]$ pgrep -l nova
3533 nova-compute
3567 nova-scheduler
5324 nova-conductor
5463 nova-conductor
5464 nova-conductor
5642 nova-scheduler
5643 nova-scheduler

watch

你知道 watch 命令吗？它特别厉害，能让你在指定的时间间隔内重复运行某个命令，就像定时器一样。比如，你可以用它来实时查看某个文件的变化，或者监控服务的状态，方便得很！

tail

还有 tail 命令，特别适合用来查看文件的最后几行内容。要是你想实时跟踪日志文件的更新，直接加上 -f 选项就行。比如：

1
tail -f /var/log/message

这样，日志文件一有更新，你就能第一时间看到，再也不用手动刷新了，超方便！

OpenStack 客户端的调试模式

说到调试，OpenStack 客户端自带的 --debug 选项简直是神器！默认情况下，它的日志级别是 INFO，信息比较有限。但你要是加上 --debug，日志级别就会变成 DEBUG，能显示超多细节，比如 API 请求的内容、返回的响应体等等。这些信息就像是一堆线索，帮你快速定位问题，特别适合排查那些棘手的故障。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
(overcloud) [stack@director ~]$ openstack project create demo --debug
START with options: project create demo --debug
options: Namespace(access_key='', access_secret='***', access_token='***', access_token_endpoint='', access_token_type='', aodh_endpoint='', application_credential_id='', application_credential_name='', application_credential_secret='***', auth_methods='', auth_type='password', auth_url='http://172.25.250.50:5000',
...
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description |                                  |
| domain_id   | default                          |
| enabled     | True                             |
| id          | 1eec2f498d2743ccb24d90a8017748d7 |
| is_domain   | False                            |
| name        | demo                             |
| options     | {}                               |
| parent_id   | default                          |
| tags        | []                               |
+-------------+----------------------------------+
clean_up CreateProject:
END return value: 0

有时候我们运行命令的时候，可能会不小心改了点啥，或者操作过程中出了点问题，这时候要是能有记录，那排查起来就轻松多了。

OpenStack 命令行客户端有个超实用的功能，可以用 --log-file 选项把操作记录下来。这样一来，所有执行的命令、操作过程，甚至是资源的变化，都会被保存到一个日志文件里。要是后续出了问题，直接翻日志就能找到线索，再也不用挠头回忆自己到底干了啥了。

比如，你想创建一个项目，同时把操作过程记录下来，就可以这样操作：

1
(overcloud) [stack@director ~]$ openstack project create demo --debug --log-file demo.log

这条命令不仅会创建一个叫 demo 的项目，还会把整个过程的详细信息（包括调试信息）记录到 demo.log 文件里。要是后续有问题，直接打开这个日志文件，就能看到所有关键信息，方便得很！

⽹络故障排除⼯具

验证物理主机之间的通信

OpenStack 的控制平面服务得靠各个节点之间的通信才能正常工作。所以，第一步就是得确保这些节点之间能正常“聊天”。你可以用 ip、tcpdump、arp 和 netstat 这些命令来检查网络连通性。

检查网络接口状态

用 ip addr 命令就能看到各个节点的网络接口状态。比如：

1
2
3
4
5
6
7
(overcloud) [stack@director ~]$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             172.25.250.200/24 fe80::1f21:2be6:7500:dfef/64
eth1             UP             fe80::5054:ff:fe00:f9c8/64
ovs-system       DOWN
br-int           DOWN
br-ctlplane      UNKNOWN        172.25.249.200/24 172.25.249.202/32 172.25.249.201/32 fe80::5054:ff:fe00:f9c8/64

SSH 连接调试

有时候连接到实例的时候会出问题，比如连不上，或者认证失败。这时候可以用 SSH 的 -v 选项开启调试模式。比如：

1
ssh stack@director -v

要是问题比较复杂，还可以多加几个 -v，最多可以加到 -vvv，这样就能看到超详细的调试信息，方便排查问题。

检查 OpenStack 网络服务通信

OpenStack 的计算服务（nova）和网络服务（neutron）之间得互相配合，才能给实例分配 IP 地址。要是通信出了问题，实例可能就拿不到 IP 地址了。这种情况下，可以用 tcpdump 来抓取实例网络端口的流量，看看数据包是不是正常传输。比如：

1
tcpdump -i eth0

这样就能实时看到经过 eth0 接口的网络流量，方便排查问题。

查看端口监听情况

有时候可能会有其他进程占用了某个端口，导致服务无法正常启动。可以用 lsof 命令来查看某个端口上监听的进程。比如：

1
[root@controller ~]# podman exec -ti nova_vnc_proxy lsof -i :6080

这条命令会告诉你哪个进程在监听 6080 端口。

OVN 中数据包追踪

OVN 是一个强大的网络虚拟化工具，它通过 OpenFlow 规则来管理流量，包括进出流量、安全组实现、DHCP 和 NAT 等功能。它通过 ovn-northd 管理覆盖网络（overlay network），并通过 OVN 网关将覆盖网络连接到物理网络。网关有两种类型：一种是二层的，用于将 OVN 逻辑交换机桥接到 VLAN；另一种是三层的，用于连接 OVN 路由器和物理网络。

OVN 定义了逻辑流（logical flows），这些流有优先级、匹配条件和动作，由 ovn-northd 生成。逻辑流描述了整个网络的详细行为，OVN 会将这些逻辑流分发到每个 hypervisor 上的 ovn-controller。每个 ovn-controller 会将逻辑流转换为 OpenFlow 流，从而告诉网络设备如何到达其他 hypervisor。

ovn-trace 是用来模拟 OVN 逻辑网络中包的转发路径的，特别适合用来排查网络连通性问题。比如，你想知道为什么某个包被丢弃了，就可以用它来追踪。

ovn-trace 命令需要两个参数：

  1. DATAPATH：指定样本包的来源，比如某个逻辑交换机或路由器。

  2. MICROFLOW：指定要模拟的样本包，比如它的源地址、目的地址、协议类型等。

运行这个命令后，它会输出包在逻辑网络中的详细路径，帮助你理解包是怎么被处理的。

OpenStack 部署限制的验证

绝对限制（Absolute Limits）

每个项目（Project）都有预设的资源使用限制，比如实例数量、CPU 核心数、内存大小等。这些限制是为了防止资源过度使用。

使用命令 openstack limits show --absolute --project <项目名> 可以查看某个项目的绝对限制。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
(overcloud) [stack@director ~]$ openstack limits show --absolute --project demo
+--------------------------+-------+
| Name                     | Value |
+--------------------------+-------+
| maxTotalInstances        |    10 |
| maxTotalCores            |    20 |
| maxTotalRAMSize          | 51200 |
| maxServerMeta            |   128 |
| maxTotalKeypairs         |   100 |
| maxServerGroups          |    10 |
| maxServerGroupMembers    |    10 |
| totalRAMUsed             |     0 |
| totalCoresUsed           |     0 |
| totalInstancesUsed       |     0 |
| totalServerGroupsUsed    |     0 |
| maxTotalVolumes          |    10 |
| maxTotalSnapshots        |    10 |
| maxTotalVolumeGigabytes  |  1000 |
| maxTotalBackups          |    10 |
| maxTotalBackupGigabytes  |  1000 |
| totalVolumesUsed         |     0 |
| totalGigabytesUsed       |     0 |
| totalSnapshotsUsed       |     0 |
| totalBackupsUsed         |     0 |
| totalBackupGigabytesUsed |     0 |
+--------------------------+-------+

速率限制（Rate Limits）

控制用户在特定时间内可以发出的 API 请求频率。

配额（Quotas）：为项目或用户账户设置资源使用阈值，可以管理计算、块存储和网络服务的配额。

使用命令 openstack quota show <项目名> 查看当前配额。

1
2
3
4
5
6
7
(overcloud) [stack@director ~]$ openstack quota show demo
+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field                 | Value                                                                                                                                                                                      |
+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| backup-gigabytes      | 1000                                                                                                                                                                                       |
| backups               | 10                                                                                                                                                                                         |
| cores                 | 20

OpenStack 服务状态验证

服务管理

在 Red Hat OpenStack Platform 中，大多数服务由 systemd 管理，但容器化的服务需要使用 podman 命令来检查。

  • 非高可用（Non-HA）容器由 paunch 创建和更新。

  • 高可用（HA）容器由 pacemaker 创建和监控，更新时使用 Ansible Playbooks。

检查容器状态：

使用 podman ps 查看运行中的容器状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
(overcloud) [stack@director ~]$ sudo podman ps --format="table {{.Names}} {{.Status}}"
Names                                                        Status
neutron-dnsmasq-qdhcp-eb293984-94fd-4ec1-8b03-d2379886855c   Up 5 hours ago
neutron-haproxy-qdhcp-eb293984-94fd-4ec1-8b03-d2379886855c   Up 5 hours ago
nova_compute                                                 Up 5 hours ago
ironic_neutron_agent                                         Up 5 hours ago
neutron_ovs_agent                                            Up 5 hours ago
neutron_l3_agent                                             Up 5 hours ago
neutron_dhcp                                                 Up 5 hours ago
ironic_api                                                   Up 5 hours ago
nova_api_cron                                                Up 5 hours ago
swift_proxy                                                  Up 5 hours ago
nova_api                                                     Up 5 hours ago
glance_api                                                   Up 5 hours ago
placement_api                                                Up 5 hours ago

查看容器日志

使用 podman logs <容器名> 查看容器的日志，帮助定位问题。

1
(overcloud) [stack@director ~]$ podman logs keystone

容器化服务的监控与修改

检查容器结构：

使用 podman inspect 查看容器的状态、标签、存储、网络等信息。

1
podman inspect keystone

在容器内执行命令：

使用 podman exec 在容器内运行命令，例如执行健康检查脚本。

1
2
3
4
5
[root@controller0 ~]# podman exec -ti keystone /openstack/healthcheck
++ : 10
++ : curl-healthcheck
++ : '\n%{http_code}' '%{remote_ip}:%{remote_port}' '%{time_total}' 'seconds\n'
++ : /dev/null

导出容器：

使用 podman export 将容器导出为 tar 归档文件，方便后续分析。

1
[root@controller ~]# podman export keystone -o keystone.tar

配置文件与日志

  • 配置文件：

容器的配置文件通常位于 /var/lib/config-data/puppet-generated/SERVICENAME/ 目录。

修改配置文件后，需要重启容器以应用更改。

1
[root@controller ~]# podman restart nova_scheduler
  • 日志文件：

容器的日志文件通常绑定到主机的 /var/log/containers/ 目录。

使用 podman logs 查看容器的标准输出和错误日志。

1
[root@controller ~]# podman logs nova_scheduler

高可用服务（HA）

Pacemaker 管理的服务：

  • HA 环境中，多个控制器节点运行 Pacemaker 和 Corosync，提供高可用性。

  • 使用 pcs 命令管理服务，而不是 podman 或 systemctl。

1
[root@controller ~]# pcs status

服务捆绑（Service Bundles）：

每个服务捆绑由多个容器组成，由 Pacemaker 管理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[root@controller0 ~]# pcs resource config haproxy-bundle

 Bundle: haproxy-bundle
  Podman: image=cluster.common.tag/gls-dle-dev-osp16-osp16_containers-openstack-haproxy:pcmklatest network=host options="--user=root --log-driver=k8s-file --log-opt path=/var/log/containers/stdouts/haproxy-bundle.log -e KOLLA_CONFIG_STRATEGY=COPY_ALWAYS" replicas=1 run-command="/bin/bash /usr/local/bin/kolla_start"
  Storage Mapping:
   options=ro source-dir=/var/lib/kolla/config_files/haproxy.json target-dir=/var/lib/kolla/config_files/config.json (haproxy-cfg-files)
   options=ro source-dir=/var/lib/config-data/puppet-generated/haproxy/ target-dir=/var/lib/kolla/config_files/src (haproxy-cfg-data)
   options=ro source-dir=/etc/hosts target-dir=/etc/hosts (haproxy-hosts)
   options=ro source-dir=/etc/localtime target-dir=/etc/localtime (haproxy-localtime)
   options=rw source-dir=/var/lib/haproxy target-dir=/var/lib/haproxy (haproxy-var-lib)
   options=ro source-dir=/etc/pki/ca-trust/extracted target-dir=/etc/pki/ca-trust/extracted (haproxy-pki-extracted)
   options=ro source-dir=/etc/pki/tls/certs/ca-bundle.crt target-dir=/etc/pki/tls/certs/ca-bundle.crt (haproxy-pki-ca-bundle-crt)
   options=ro source-dir=/etc/pki/tls/certs/ca-bundle.trust.crt target-dir=/etc/pki/tls/certs/ca-bundle.trust.crt (haproxy-pki-ca-bundle-trust-crt)
   options=ro source-dir=/etc/pki/tls/cert.pem target-dir=/etc/pki/tls/cert.pem (haproxy-pki-cert)
   options=rw source-dir=/dev/log target-dir=/dev/log (haproxy-dev-log)

消息代理（Messaging Broker）

RabbitMQ：

  • OpenStack 使用 RabbitMQ 作为消息代理，支持 AMQP 协议。

  • 用于 OpenStack 各组件之间的内部通信，例如 nova-api、nova-scheduler 和 nova-compute 通过 RPC 通信。

  • 日志和配置文件是排查问题的重要线索。