CL210OpenStack操作的故障排除--诊断OpenStack问题
个人简介：大家好，我是 金鱼哥，CSDN运维领域新星创作者，华为云·云享专家，阿里云社区·专家博主
个人资质：CCNA、HCNP、CSNA（网络分析师），软考初级、中级网络工程师、RHCSA、RHCE、RHCA、RHCI、ITIL
格言：努力不一定成功，但要想成功就必须努力支持我：可点赞、可收藏⭐️、可留言
文章目录
-
-
- 基本的故障排除方法和工具
-
- 故障排除的通用工具
- 使用OpenStack客户机进行调试
- 网络故障排除工具
- 在OVN中跟踪数据包
-
- 验证OpenStack部署限制
- 验证OPENSTACK服务状态
-
- Non-HA容器
- HA容器
- 监视容器服务
- 修改容器化的服务配置文件
- 查看和分析OpenStack服务日志
- 高可用的容器化服务
- 用于消息传递代理的故障排除工具
- 课本练习
-
- 1. 检查在controller0上运行的容器化计算服务。
- 2. 检查在compute0上运行的容器化计算服务。
- 3. 在compute0上，使用docker inspect命令来确定nova_compute服务的配置和日志文件位置。
- 4. 在compute0上，为nova_compute服务启用调试级日志记录。
- 5. 在controller0上，通过杀死适当的pacemaker_remoted进程来强制RabbitMQ失败。
- 6. 在compute0上，检查/var/log/containers/nova/nova-compute与RabbitMQ容器崩溃相关的活动的日志文件。
- 7. 在controller0上，确定RabbitMQ的状态。
- 8. 识别在端口8775、8774和6080上监听的计算服务进程。
- 9. 在workstation中，列出计算服务。
- 10. 在workstation上，启动一个实例来验证所有服务是否正常。
- 清除实验
- 总结
-
基本的故障排除方法和工具
OpenStack操作和管理员可以使用多种方法来诊断问题。你需要找到一种方法，能够在你所处的环境中很好地解决问题。要对OpenStack服务的问题进行故障排除，理解请求在服务的不同组件之间移动时所遵循的工作流是很重要的。以下方法可以很好地解决OpenStack服务的问题：
-
验证服务：确保所需的服务已经启动并运行。
-
验证端口：确保服务在正确的端口和IP地址上侦听。
-
OpenStack客户端调试：以调试模式运行OpenStack客户端以查找错误。
-
查看日志：查看日志文件中的跟踪或错误。
故障排除的通用工具
OpenStack部署在Linux环境中，这意味着管理员在故障排除时可以使用流行的Linux工具。您可以使用ps、pgrep和许多其他命令来帮助验证进程的状态。
带有-l选项的pgrep命令列出了进程名称及其pid。例如，可以使用pgrep -1 nova命令列出当前正在运行的nova进程。
watch命令提供了一种方便的方式来在给定的时间间隔执行命令。使用tail命令输出文件的最后几行。可以使用-f选项和tail命令跟踪更新的日志文件。
使用OpenStack客户机进行调试
OpenStack命令行客户端支持–debug选项来查看错误的更多细节。此选项将日志级别设置为DEBUG，而不是默认的信息级别。这个调试信息包括OpenStack CLI发送的APl请求的详细信息和APl端点发回的响应体详细信息。此信息包含有用的指针，可以帮助您解决问题。
当用户运行命令时，可以记录操作以识别资源更改并提供有用的故障诊断信息。使用命令中的–log-file选项将信息存储在日志文件中
网络故障排除工具
对于与网络相关的问题，您需要验证所有节点之间的物理主机对主机通信，以确保OpenStack控制平面服务正常工作，操作员和管理员还必须验证覆盖网络是否按照预期进行通信。您可以使用ip、tcpdump、arp、netstat和许多其他命令来验证网络连接。
使用Isof命令查找在特定端口上监听的进程。这有助于确定是否有其他进程在网络端口上运行。下面的输出显示了在端口6080上侦听的noVNC计算服务。
在OVN中跟踪数据包
通过使用OVN实现ML2, OpenFlow规则管理传出和传入流量、安全组实现、DHCP和NAT，这些变化在故障排除过程中尤为重要。网络命名空间不再用于DHCP代理和路由器。OVN网关连接覆盖网络，由OVN-northd管理，到物理网络。这有两种类型：第二层连接OVN逻辑交换机到VLAN，第三层提供OVN路由器和物理网络之间的连接。
OVN定义了具有优先级、匹配和操作的逻辑流，由ovn-northd逻辑流生成，还描述了整个网络的详细行为。OVN以逻辑流创建整个网络，这些逻辑流分布到每个虚拟机监控程序上的ovn-controller。每个ovn-controller将逻辑流转换为OpenFlow流，详细说明如何到达其他管理程序。使用ovn-trace命令在OVN正常网络中刺激数据包转发。ovn-trace命令有两个分支：DATAPATH，它指定示例包的起源；MICROFLOW，它指定了要模拟的样本包，该命令的输出可以有不同细节级别的多种格式。
在调试网络连接问题以查看数据包被丢弃的原因时，使用ovn-trace命令来获得数据包从逻辑端口发送到目的地时发生的情况的详细跟踪。下面的输出显示了一个DHCP请求通过逻辑网络的模拟。数据包起源于实例端口，并广播到DHCP端口。
验证OpenStack部署限制
在启动实例时，您可能会看到错误，因为设置了阈值来管理容量并防止基于项目的资源过度利用。项目可能有绝对的限制，并且在每个OpenStack部署中可能有所不同。作为管理员，使用openstack limit show --absolute命令列出特定项目的限制。
速率限制控制用户发出特定API请求的频率。管理员可以使用速率限制来配置特定时间间隔内可以进行的API调用的类型和数量的限制。
配额还提供了在OpenStack资源上设置阈值的方法。可以对项目和用户帐户执行配额。您可以管理计算服务、块存储服务和OpenStack网络服务的配额。使用openstack quota show命令来显示项目的当前配额值。
验证OPENSTACK服务状态
在红帽OpenStack平台的当前版本中，大部分的OpenStack服务不再由systemd实用程序管理。这些服务中的大多数在容器中自己的执行环境中运行，这些被容器化的服务通常称为服务容器。但是，需要注意的是，每个服务容器并不一对一地映射到特定的容器。相反，这些服务容器由多个离散的容器化流程组成。在Red Hat OpenStack平台部署中，有两种类型的服务容器：
Non-HA容器
使用docker守护进程来管理和监视这些容器。所有的非ha容器都由Paunch创建和更新。例如，用于计算、标识、对象存储的容器和许多其他非ha OpenStack服务。
HA容器
使用Pacemaker创建和监控这些容器。在overcloud部署期间，HA容器使用可执行剧本进行更新。例如,galera-bundle-docker-0，rabbitmg-bundle-docker-0, redis-bundle-docker-0。以及其他高可用性的OpenStack服务。
监视容器服务
若要对云上的故障服务容器进行故障诊断，首先要检查主机上正在运行的容器。这些docker命令必须从overcloud节点执行。使用docker ps命令来确定服务的状态。
使用docker子命令(如ps、history和logs)来分析和检查服务容器。例如，使用docker logs keystone命令查看kesytone容器的日志，以确定在容器运行期间实际失败了什么。
要进一步排除故障，可以使用docker inspect命令检查容器结构。您可以使用此命令检查以下容器特征：
-
容器的不同状态，如status、exitcodes、restartcount。
-
容器标签，以获得更多信息，比如version、build data和config_id。
-
容器使用的存储、挂载和网络。
-
容器用于报告运行状况状态的运行状况检查命令。
使用以下命令列出keystone容器的运行状况检查命令。
在某些情况下，要检查容器，可能需要在正在运行的容器中执行命令，以便进行进一步的故障排除。例如，每个容器都有一个运行状况检查脚本来验证服务连接。使用docker exec命令从容器内运行运行状况检查脚本。
当一个容器失败时，该容器的本地文件系统上的许多文件将丢失，因为并不是所有目录都绑定挂载在overcloud的主机文件系统上。使用docker export命令将容器导出为tar存档文件，以便将来进行分析
修改容器化的服务配置文件
Red Hat OpenStack平台部署使用的容器镜像来自Kolla镜像。Kolla是一个OpenStack项目，提供用于操作OpenStack云的生产就绪的容器和部署工具。每个容器由基本镜像组成，该基本镜像经过进一步定制以添加运行状况检查脚本。RHEL特定的包，和TripleO包来创建配置文件使用Ansible和Puppet。所有Kolla镜像都包含一个Kolla start引导程序脚本，该脚本将配置文件从主机操作系统复制到容器中。kolla_start脚本在容器内初始化服务时执行。由Kolla管理的容器化服务配置可以采取两种形式，一个JSON文件或一个目录树。
JSON文件包含诸如要在容器中运行的命令、包含服务配置和日志的目录以及日志目录中应该设置的所有者等信息。使用的JSON文件位于主机上的/var/lib/kolla/config_file目录中。这个文件绑定在容器中的/var/lib/kolla/config_files/config.json。
在下面的输出中，nova_scheduler容器绑定挂载/var/lib/kolla/config_files/nova_scheduler.json容器中的文件。config.json文件设置/var/log/nova目录的权限，执行nova_scheduler命令，并将/var/lib/kolla/config_files/src/*的内容复制到容器内的根目录。
目录树包含与服务配置和日志相关的文件层次结构。它包含/etc和/var目录。特定于服务的目录位于主机上的/var/lib/config-data/puppet-generated/SERVICENAME/目录中。该目录绑定为/var/lib/kolla/config_files/src挂载在容器中。来自主机的绑定挂载存储为容器的配置和日志文件提供持久存储。kolla启动脚本将/var/lib/kolla/config_files/src/中的内容复制到容器内的根目录(/)。
若要修改由Kolla管理的容器化服务中的配置，需要更新位于/var/lib/config-data/puppet-generated/SERVICENAME/ 目录中的配置文件。这些变化没有立即反映出来;您必须重新启动容器，以重新运行kolla_start脚本，以应用更改。使用docker restart命令重新启动容器
查看和分析OpenStack服务日志
与配置文件类似，容器中的日志也绑定挂载在主机操作系统上。大多数容器将其日志存储在/var/log/ containers中的特定目录下。使用httpd服务的容器将日志存储在/var/log/Containers中的httpd子目录中。
使用docker logs命令检查与特定容器相关的日志文件。命令输出是容器的标准输出和标准错误，而不是与服务相关的日志。
OpenStack服务使用标准的logging级别，其严重性不断增加：调试（DEBUG）、信息（INFO）、审计（AUDIT）、警告（WARNING）、错误（ERROR）、关键（CRITICAL）和跟踪（TRACE）。只有当这些日志消息比特定的日志级别更严重时，才会出现在日志中，DEBUG允许在日志文件中写入所有log语句。
查找错误源的第一步通常是从日志文件的底部开始，在日志中搜索CRITICAL、TRACE或ERROR消息。
例如，当实例创建失败时，您必须跨各种计算服务的日志文件、跨控制器和计算跟踪与实例关联的活动节点。典型的方法是跨服务日志跟踪与实例关联的实例ID。在处理OpenStack故障排除问题时，您需要记住，由于相同的底层问题，各种OpenStack组件会跨多个日志文件写入日志项。
高可用的容器化服务
在传统的高可用性部署中，有多个控制器节点。每个控制器节点运行Pacemaker和Corosync来提供高可用性服务。每个节点都包含由Pacemaker管理的组件，如RabbitMQ、HAProxy、Galera和Redis。这些组件是包含的核心服务，支持OpenStack的主要组件。在每个容器中都运行一个pacemaker_remote守护进程，它为集群资源和大多数命令行工具提供本地资源管理。这个守护进程允许在不运行整个集群堆栈的情况下将主机用作Pacemaker节点。
每个运行特定服务并属于集群中不同控制器节点的容器与Pacemaker资源一起构成一个服务包。您不能使用docker或systemctl命令来管理这些服务包。由Pacemaker管理的服务必须始终使用pc命令来启动或停止这些服务包。
使用pcs status命令来确定服务包的状态。失败的集群资源被报告在输出的Failed Actions标题下。
由Pacemaker控制的容器将RestartPolicy变量设置为no，以确保Pacemaker控制容器的启动或停止操作。使用以下命令查看haproxy-bundle-docker-0容器的重启策略:
运行pcs resource show命令以查看资源包的更多信息。
用于消息传递代理的故障排除工具
OpenStack服务的主要组件之一是消息传递代理，它允许各种OpenStack组件使用AMQP进行内部通信。任何支持AMQP的消息代理解决方案都可以用作后端。Red Hat在其OpenStack产品中包括RabbitMQ作为消息代理，因为它提供用于设置高级配置有用的企业级特性。消息代理允许在生产者和消费者应用程序之间发送和接收消息。在内部，该通信由RabbitMQ使用交换器、队列以及它们之间的绑定来执行。例如，对于计算服务，使用nova-api，nova-scheduler和nova-compute服务使用远程过程调用(rpc)来使用消息代理相互通信。
因此，在诊断OpenStack组件的问题时，搜索故障诊断线索通常很有用。有关使用RabbitMQ对服务通信进行故障诊断的更多信息，请参阅“通过消息传递进行服务通信的故障排查”一节。
课本练习
- 能够定位和查看日志文件、检查服务并启用调试级日志记录。
[student@workstation ~]$ lab troubleshooting-diagnose setup
Setting up workstation for lab exercise work:
• Verifying project: finance.................................. SUCCESS
• Creating user env file: developer1-finance-rc............... SUCCESS
• Creating user env file: architect1-finance-rc............... SUCCESS
• Creating keypair: example-keypair........................... SUCCESS
. Creating flavor: default.................................... SUCCESS
. Creating image: rhel7....................................... SUCCESS
. Creating internal network: finance-network1................. SUCCESS
. Creating subnet: finance-subnet1............................ SUCCESS
. Creating external network: provider-datacentre.............. SUCCESS
. Creating router: finance-router1............................ SUCCESS
1. 检查在controller0上运行的容器化计算服务。
[root@controller0 ~]# docker ps --all --filter "name=nova"
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
340500c7cd3b 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "/usr/bin/bootstra..." 2 years ago Exited (0) 2 years ago nova_api_discover_hosts
5bfcf5bbf99b 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "kolla_start" 2 years ago Up 5 days nova_metadata
457d4ace92a0 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "kolla_start" 2 years ago Up 3 days (healthy) nova_api
3a98c43a04f7 172.25.249.200:8787/rhosp13/openstack-nova-scheduler:latest "kolla_start" 2 years ago Up 3 days (healthy) nova_scheduler
35f522ad5783 172.25.249.200:8787/rhosp13/openstack-nova-novncproxy:latest "kolla_start" 2 years ago Up 5 days (healthy) nova_vnc_proxy
eb5d4133cd70 172.25.249.200:8787/rhosp13/openstack-nova-consoleauth:latest "kolla_start" 2 years ago Up 5 days (healthy) nova_consoleauth
a39f81aa4a8b 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "kolla_start" 2 years ago Up 5 days nova_api_cron
8ffb511c9318 172.25.249.200:8787/rhosp13/openstack-nova-conductor:latest "kolla_start" 2 years ago Up 5 days (healthy) nova_conductor
2178875e7453 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "/usr/bin/bootstra..." 2 years ago Exited (0) 2 years ago nova_db_sync
ee0b27e7e257 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "/usr/bin/bootstra..." 2 years ago Exited (0) 2 years ago nova_api_ensure_default_cell
b4eae39f8f50 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "/usr/bin/bootstra..." 2 years ago Exited (0) 2 years ago nova_api_map_cell0
53d487974cc1 172.25.249.200:8787/rhosp13/openstack-nova-placement-api:latest "kolla_start" 2 years ago Up 5 days nova_placement
e77b4a296f8f 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "/usr/bin/bootstra..." 2 years ago Exited (0) 2 years ago nova_api_db_sync
d42de26be1af 172.25.249.200:8787/rhosp13/openstack-nova-placement-api:latest "/bin/bash -c 'cho..." 2 years ago Exited (0) 2 years ago nova_placement_init_log
166d1e71b4f3 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "/bin/bash -c 'cho..." 2 years ago Exited (0) 2 years ago nova_metadata_init_log
26874e77508d 172.25.249.200:8787/rhosp13/openstack-nova-api:latest "/bin/bash -c 'cho..." 2 years ago Exited (0) 2 years ago nova_api_init_logs
2. 检查在compute0上运行的容器化计算服务。
[root@compute0 ~]# docker ps --all --filter "name=nova*"
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6b487f0500b4 172.25.249.200:8787/rhosp13/openstack-nova-compute:latest "kolla_start" 2 years ago Up 3 days (healthy) nova_compute
9e0eeaf96ccd 172.25.249.200:8787/rhosp13/openstack-nova-compute:latest "kolla_start" 2 years ago Up 3 days nova_migration_target
3ff3bf523624 172.25.249.200:8787/rhosp13/openstack-nova-libvirt:latest "/bin/bash -c '/us..." 2 years ago Exited (0) 2 years ago nova_libvirt_init_secret
635e1c629602 172.25.249.200:8787/rhosp13/openstack-nova-libvirt:latest "kolla_start" 2 years ago Up 3 days nova_libvirt
1eea921b6ea1 172.25.249.200:8787/rhosp13/openstack-nova-libvirt:latest "kolla_start" 2 years ago Up 3 days nova_virtlogd
3. 在compute0上，使用docker inspect命令来确定nova_compute服务的配置和日志文件位置。
列出配置和日志文件。
[root@compute0 ~]# docker inspect nova_compute | grep HostConfig -A 25
"HostConfig": {
"Binds": [
"/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro",
"/dev/log:/dev/log",
"/dev:/dev",
"/lib/modules:/lib/modules:ro",
"/var/lib/libvirt:/var/lib/libvirt",
"/etc/localtime:/etc/localtime:ro",
"/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro",
"/run:/run",
"/sys/class/net:/sys/class/net",
"/etc/hosts:/etc/hosts:ro",
"/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro",
"/etc/ssh/ssh_known_hosts:/etc/ssh/ssh_known_hosts:ro",
"/etc/puppet:/etc/puppet:ro",
"/etc/ceph:/var/lib/kolla/config_files/src-ceph:ro",
"/var/lib/nova:/var/lib/nova:shared",
"/sys/bus/pci:/sys/bus/pci",
"/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro",
"/var/log/containers/nova:/var/log/nova",
"/var/lib/kolla/config_files/nova_compute.json:/var/lib/kolla/config_files/config.json:ro",
"/var/lib/config-data/puppet-generated/nova_libvirt/:/var/lib/kolla/config_files/src:ro",
"/etc/iscsi:/var/lib/kolla/config_files/src-iscsid:ro"
],
"ContainerIDFile": "",
"LogConfig": {
[root@compute0 ~]# find /var/lib/config-data/puppet-generated/nova_libvirt/
/var/lib/config-data/puppet-generated/nova_libvirt/
/var/lib/config-data/puppet-generated/nova_libvirt/etc
/var/lib/config-data/puppet-generated/nova_libvirt/etc/libvirt
/var/lib/config-data/puppet-generated/nova_libvirt/etc/libvirt/libvirtd.conf
/var/lib/config-data/puppet-generated/nova_libvirt/etc/libvirt/passwd.db
/var/lib/config-data/puppet-generated/nova_libvirt/etc/libvirt/qemu.conf
/var/lib/config-data/puppet-generated/nova_libvirt/etc/my.cnf.d
/var/lib/config-data/puppet-generated/nova_libvirt/etc/my.cnf.d/tripleo.cnf
/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova
/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/migration
/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/migration/authorized_keys
/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/migration/identity
/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/secret.xml
/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf
/var/lib/config-data/puppet-generated/nova_libvirt/etc/sasl2
/var/lib/config-data/puppet-generated/nova_libvirt/etc/sasl2/libvirt.conf
/var/lib/config-data/puppet-generated/nova_libvirt/etc/ssh
/var/lib/config-data/puppet-generated/nova_libvirt/etc/ssh/sshd_config
/var/lib/config-data/puppet-generated/nova_libvirt/var
/var/lib/config-data/puppet-generated/nova_libvirt/var/lib
/var/lib/config-data/puppet-generated/nova_libvirt/var/lib/nova
/var/lib/config-data/puppet-generated/nova_libvirt/var/lib/nova/.ssh
/var/lib/config-data/puppet-generated/nova_libvirt/var/lib/nova/.ssh/config
[root@compute0 ~]# find /var/log/containers/nova/
/var/log/containers/nova/
/var/log/containers/nova/privsep-helper.log
/var/log/containers/nova/nova-compute.log.5.gz
/var/log/containers/nova/nova-compute.log.4.gz
/var/log/containers/nova/nova-compute.log.3.gz
/var/log/containers/nova/nova-compute.log.2.gz
/var/log/containers/nova/nova-compute.log.1
/var/log/containers/nova/nova-compute.log
4. 在compute0上，为nova_compute服务启用调试级日志记录。
[root@compute0 ~]# crudini --set /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf DEFAULT debug True
[root@compute0 ~]# crudini --get /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf DEFAULT debug
True
[root@compute0 ~]# docker restart nova_compute
nova_compute
[root@compute0 ~]# tail -f /var/log/containers/nova/nova-compute.log
2020-11-04 01:56:12.178 1 DEBUG oslo_concurrency.lockutils [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] Lock "placement_client" released by "nova.scheduler.client.report._create_client" :: held 0.008s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:285
2020-11-04 01:56:12.816 1 DEBUG nova.scheduler.client.report [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] Refreshing aggregate associations for resource provider 09161a58-2c62-49d6-bf45-14f34611eee0, aggregates: None _refresh_associations /usr/lib/python2.7/site-packages/nova/scheduler/client/report.py:781
2020-11-04 01:56:12.829 1 DEBUG nova.scheduler.client.report [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] Refreshing trait associations for resource provider 09161a58-2c62-49d6-bf45-14f34611eee0, traits: None _refresh_associations /usr/lib/python2.7/site-packages/nova/scheduler/client/report.py:792
2020-11-04 01:56:12.887 1 DEBUG nova.compute.resource_tracker [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] Total usable vcpus: 4, total allocated vcpus: 0 _report_final_resource_view /usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py:824
2020-11-04 01:56:12.888 1 INFO nova.compute.resource_tracker [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] Final resource view: name=compute0.overcloud.example.com phys_ram=6143MB used_ram=4096MB phys_disk=39GB used_disk=0GB total_vcpus=4 used_vcpus=0 pci_stats=[]
2020-11-04 01:56:12.925 1 DEBUG nova.compute.resource_tracker [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] Compute_service record updated for compute0.overcloud.example.com:compute0.overcloud.example.com _update_available_resource /usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py:764
2020-11-04 01:56:12.925 1 DEBUG oslo_concurrency.lockutils [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] Lock "compute_resources" released by "nova.compute.resource_tracker._update_available_resource" :: held 0.805s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:285
2020-11-04 01:56:12.926 1 DEBUG nova.service [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] Creating RPC server for service compute start /usr/lib/python2.7/site-packages/nova/service.py:184
2020-11-04 01:56:12.948 1 DEBUG nova.service [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] Join ServiceGroup membership for this service compute start /usr/lib/python2.7/site-packages/nova/service.py:202
2020-11-04 01:56:12.949 1 DEBUG nova.servicegroup.drivers.db [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] DB_Driver: join new ServiceGroup member compute0.overcloud.example.com to the compute group, service = <Service: host=compute0.overcloud.example.com, binary=nova-compute, manager_class_name=nova.compute.manager.ComputeManager> join /usr/lib/python2.7/site-packages/nova/servicegroup/drivers/db.py:47
5. 在controller0上，通过杀死适当的pacemaker_remoted进程来强制RabbitMQ失败。
[root@controller0 ~]# docker ps --filter 'name=rabbit'
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
93a115e773de 172.25.249.200:8787/rhosp13/openstack-rabbitmq:pcmklatest "/bin/bash /usr/lo..." 5 days ago Up 5 days rabbitmq-bundle-docker-0
[root@controller0 ~]# docker exec -it rabbitmq-bundle-docker-0 /bin/bash
()[root@controller0 /]# ps -ef | grep pacemaker
root 13 1 0 Oct30 ? 00:04:42 /usr/sbin/pacemaker_remoted
root 236172 235860 0 05:34 ? 00:00:00 grep --color=auto pacemaker
()[root@controller0 /]# kill -9 13
()[root@controller0 /]#
6. 在compute0上，检查/var/log/containers/nova/nova-compute与RabbitMQ容器崩溃相关的活动的日志文件。
[root@compute0 ~]# grep ERROR /var/log/containers/nova/nova-compute.log
2020-11-04 05:35:27.710 1 ERROR oslo.messaging._drivers.impl_rabbit [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] [419d0e71-c86e-49f5-9566-481d7213b9c8] AMQP server controller0.internalapi.overcloud.example.com:5672 closed the connection. Check login credentials: Socket closed: IOError: Socket closed
2020-11-04 05:35:27.717 1 ERROR oslo.messaging._drivers.impl_rabbit [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] [af185c26-1334-4dbb-9e66-b2a234b53d37] AMQP server controller0.internalapi.overcloud.example.com:5672 closed the connection. Check login credentials: Socket closed: IOError: Socket closed
2020-11-04 05:35:27.873 1 ERROR oslo.messaging._drivers.impl_rabbit [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] [caf725ac-f4b4-43ff-9903-9fa7ce9d2726] AMQP server on controller0.internalapi.overcloud.example.com:5672 is unreachable: [Errno 104] Connection reset by peer. Trying again in 1 seconds. Client port: None: error: [Errno 104] Connection reset by peer
2020-11-04 05:35:28.725 1 ERROR oslo.messaging._drivers.impl_rabbit [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] [419d0e71-c86e-49f5-9566-481d7213b9c8] AMQP server on controller0.internalapi.overcloud.example.com:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 2 seconds. Client port: None: error: [Errno 111] ECONNREFUSED
2020-11-04 05:35:28.727 1 ERROR oslo.messaging._drivers.impl_rabbit [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] [af185c26-1334-4dbb-9e66-b2a234b53d37] AMQP server on controller0.internalapi.overcloud.example.com:5672 is unreachable: <AMQPError: unknown error>. Trying again in 1 seconds. Client port: None: RecoverableConnectionError: <AMQPError: unknown error>
2020-11-04 05:35:28.880 1 ERROR oslo.messaging._drivers.impl_rabbit [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] [caf725ac-f4b4-43ff-9903-9fa7ce9d2726] AMQP server on controller0.internalapi.overcloud.example.com:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 2 seconds. Client port: None: error: [Errno 111] ECONNREFUSED
2020-11-04 05:35:29.734 1 ERROR oslo.messaging._drivers.impl_rabbit [req-556ad964-1c2f-499a-8457-6b8d333bdf1b - - - - -] [af185c26-1334-4dbb-9e66-b2a234b53d37] AMQP server on controller0.internalapi.overcloud.example.com:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 2 seconds. Client port: None: error: [Errno 111] ECONNREFUSED
7. 在controller0上，确定RabbitMQ的状态。
[root@controller0 ~]# pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: controller0 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Wed Nov 4 05:40:15 2020
Last change: Thu Jan 30 10:15:03 2020 by root via cibadmin on controller0
5 nodes configured
21 resources configured
Online: [ controller0 ]
GuestOnline: [ galera-bundle-0@controller0 ovn-dbs-bundle-0@controller0 rabbitmq-bundle-0@controller0 redis-bundle-0@controller0 ]
Full list of resources:
…………
Failed Actions:
* rabbitmq-bundle-docker-0_monitor_0 on controller0 'unknown error' (1): call=5, status=complete, exitreason='',
last-rc-change='Fri Oct 30 01:25:56 2020', queued=0ms, exec=63ms
* galera-bundle-docker-0_monitor_0 on controller0 'unknown error' (1): call=9, status=complete, exitreason='',
last-rc-change='Fri Oct 30 01:25:56 2020', queued=0ms, exec=64ms
* redis-bundle-docker-0_monitor_0 on controller0 'unknown error' (1): call=13, status=complete, exitreason='',
last-rc-change='Fri Oct 30 01:25:56 2020', queued=0ms, exec=49ms
* rabbitmq-bundle-0_monitor_60000 on controller0 'unknown error' (1): call=3, status=Error, exitreason='',
8. 识别在端口8775、8774和6080上监听的计算服务进程。
[root@controller0 ~]# ss -lntup | egrep '8775|8774|6080'
tcp LISTEN 0 128 172.25.250.50:6080 *:* users:(("haproxy",pid=16110,fd=31))
tcp LISTEN 0 128 172.24.1.50:6080 *:* users:(("haproxy",pid=16110,fd=30))
tcp LISTEN 0 100 172.24.1.1:6080 *:* users:(("nova-novncproxy",pid=5197,fd=4))
tcp LISTEN 0 128 172.24.1.1:8774 *:* users:(("httpd",pid=711491,fd=3),("httpd",pid=307086,fd=3),("httpd",pid=307085,fd=3),("httpd",pid=307084,fd=3),("httpd",pid=307083,fd=3),("httpd",pid=306995,fd=3),("httpd",pid=306994,fd=3),("httpd",pid=306865,fd=3),("httpd",pid=305825,fd=3),("httpd",pid=262908,fd=3),("httpd",pid=262906,fd=3),("httpd",pid=262735,fd=3),("httpd",pid=251663,fd=3))
tcp LISTEN 0 128 172.25.250.50:8774 *:* users:(("haproxy",pid=16110,fd=33))
tcp LISTEN 0 128 172.24.1.50:8774 *:* users:(("haproxy",pid=16110,fd=32))
tcp LISTEN 0 128 172.24.1.1:8775 *:* users:(("nova-api-metada",pid=24628,fd=4))
tcp LISTEN 0 128 172.24.1.50:8775 *:* users:(("haproxy",pid=16110,fd=29))
9. 在workstation中，列出计算服务。
[student@workstation ~]$ source architect1-finance-rc
[student@workstation ~(architect1-finance)]$ openstack compute service list
+----+------------------+-----------------------------------+----------+---------+-------+----------------------------+
| ID | Binary | Host | Zone | Status | State | Updated At |
+----+------------------+-----------------------------------+----------+---------+-------+----------------------------+
| 1 | nova-conductor | controller0.overcloud.example.com | internal | enabled | up | 2020-11-04T05:46:29.000000 |
| 2 | nova-compute | compute1.overcloud.example.com | nova | enabled | up | 2020-11-04T05:46:31.000000 |
| 3 | nova-compute | computehci0.overcloud.example.com | nova | enabled | up | 2020-11-04T05:46:26.000000 |
| 4 | nova-compute | compute0.overcloud.example.com | nova | enabled | up | 2020-11-04T05:46:30.000000 |
| 5 | nova-consoleauth | controller0.overcloud.example.com | internal | enabled | up | 2020-11-04T05:46:35.000000 |
| 6 | nova-scheduler | controller0.overcloud.example.com | internal | enabled | up | 2020-11-04T05:46:30.000000 |
+----+------------------+-----------------------------------+----------+---------+-------+----------------------------+
10. 在workstation上，启动一个实例来验证所有服务是否正常。
[student@workstation ~(developer1-finance)]$ openstack server create --image rhel7 --flavor default --security-group default --key-name example-keypair --nic net-id=finance-network1 --wait --debug finance-server1
调试输出提供了关于启动实例所涉及的所有进程和组件的丰富信息。在下面的示例中，您可以看到调用是对compute服务、调用的URL、产生的请求ID和请求的详细信息。
GET call to compute for http://172.25.250.50:8774/v2.1/servers/7ad9b2f1-db74-4c7e-909b-ff1e805830d2 used request id req-0c3285d7-1ed8-480a-82c7-88a63a670028
REQ: curl -g -i -X GET http://172.25.250.50:8774/v2.1/servers/7ad9b2f1-db74-4c7e-909b-ff1e805830d2 -H "User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}1c9409b55c1ee4189cc6245d62696364bc801ea7"
清除实验
[student@workstation ~]$ lab troubleshooting-diagnose cleanup
总结
RHCA认证需要经历5门的学习与考试，还是需要花不少时间去学习与备考的，好好加油，可以噶。
以上就是【金鱼哥】对 第九章 OpenStack操作的故障排除–诊断OpenStack问题 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。
红帽认证专栏系列：
RHCSA专栏：戏说 RHCSA 认证
RHCE专栏：戏说 RHCE 认证
此文章收录在RHCA专栏：RHCA 回忆录
如果这篇【文章】有帮助到你，希望可以给【金鱼哥】点个赞，创作不易，相比官方的陈述，我更喜欢用【通俗易懂】的文笔去讲解每一个知识点。
如果有对【运维技术】感兴趣，也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】！
