红帽全球峰会第 13 章 对 director 进行故障排除
在进行 director 操作时可能会在特定阶段出现问题。本节提供了对常见问题进行诊断的信息。
查看 director 组件的日志文件：
-
/var/log目录包括了许多常见 OpenStack Platform 组件的日志文件，以及标准 Red Hat Enterprise Linux 应用的日志文件。 journald服务为多个组件提供日志功能。ironic 使用两个单元：openstack-ironic-api和openstack-ironic-conductor。同样的，ironic-inspector也使用两个单元：openstack-ironic-inspector和openstack-ironic-inspector-dnsmasq。以下是使用这个服务的示例：source ~/stackrc
$ source ~/stackrc (undercloud) $ sudo journalctl -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasqCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
ironic-inspector还把 ramdisk 的日志保存在/var/log/ironic-inspector/ramdisk/中（gz 压缩的 tar 文件）。它们的文件名中包括日期、时间和节点的 IPMI 地址。使用这些日志来对相关的服务进行诊断。
13.1. 对节点注册进行故障排除
与节点注册相关的问题通常是因为不正确的节点详情造成的。在这种情况下，使用带有正确节点数据的 ironic 来解决相关的问题。以下是几个示例：
找到分配的端口 UUID：
source ~/stackrc
$ source ~/stackrc
(undercloud) $ openstack baremetal port list --node [NODE UUID]更新 MAC 地址：
(undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT UUID]
(undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT UUID]运行以下命令：
(undercloud) $ openstack baremetal node set --driver-info ipmi_address=[NEW IPMI ADDRESS] [NODE UUID]
(undercloud) $ openstack baremetal node set --driver-info ipmi_address=[NEW IPMI ADDRESS] [NODE UUID]13.2. 对硬件內省的故障排除
內省（introspection）过程需要被正确完成。但是，如果发现 ramdisk 没有响应，ironic 的发现守护进程（ironic-inspector）会默认在一个小时后出现超时。在一些时候，这意味着发现 ramdisk 有问题，但通常情况下是因为不正确的环境配置，特别是 BIOS 引导设置。
以下是一些常见的不正确的环境配置情况，以及如果诊断和解决它们的建议。
启动节点內省操作错误
通常，內省操作会使用 openstack overcloud node introspect 命令。但是，如果直接使用 ironic-inspector 运行内省，在对状态为 AVAILABLE 的节点进行发现时可能会出现问题，因为该状态表明可以进行部署而无需进行发现。在进行发现操作前，需要将这种节点的状态改为 MANAGEABLE：
source ~/stackrc
$ source ~/stackrc
(undercloud) $ openstack baremetal node manage [NODE UUID]当发现操作完成后，在进行部署前把状态改回到 AVAILABLE：
(undercloud) $ openstack baremetal node provide [NODE UUID]
(undercloud) $ openstack baremetal node provide [NODE UUID]停止发现过程
停止内省过程：
source ~/stackrc
$ source ~/stackrc
(undercloud) $ openstack baremetal introspection abort [NODE UUID]
您也可以等待操作过程超时。如有必要，将 /etc/ironic-inspector/inspector.conf 中的 timeout 设置更改为另一个时长（以分钟为单位）。
访问内省的 Ramdisk
内省虚拟内存盘使用动态登录功能。这意味着在内省调试过程中，可以提供临时密码或 SSH 密钥来访问节点。按以下流程设置虚拟内存盘访问方式：
为
openssl passwd -1命令提供临时密码来生成 MD5 哈希。例如：openssl passwd -1 mytestpassword
$ openssl passwd -1 mytestpassword $1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑
/httpboot/inspector.ipxe文件，找到以kernel开头的行，为其附加上rootpwd参数和 MD5 哈希。例如：kernel http://192.2.0.1:8088/agent.kernel ipa-inspection-callback-url=http://192.168.0.1:5050/v1/continue ipa-inspection-collectors=default,extra-hardware,logs systemd.journald.forward_to_console=yes BOOTIF=${mac} ipa-debug=1 ipa-inspection-benchmarks=cpu,mem,disk rootpwd="$1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/" selinux=0kernel http://192.2.0.1:8088/agent.kernel ipa-inspection-callback-url=http://192.168.0.1:5050/v1/continue ipa-inspection-collectors=default,extra-hardware,logs systemd.journald.forward_to_console=yes BOOTIF=${mac} ipa-debug=1 ipa-inspection-benchmarks=cpu,mem,disk rootpwd="$1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/" selinux=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 或者，也可以附加
sshkey参数和您的 SSH 公钥。注意rootpwd和sshkey参数都需要加上引号。启动内省并通过
arp命令或 DHCP 日志找到 IP 地址：arp sudo journalctl -u openstack-ironic-inspector-dnsmasq
$ arp $ sudo journalctl -u openstack-ironic-inspector-dnsmasqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 作为根用户，使用临时密码或 SSH 密钥进行 SSH 连接。
ssh root@192.168.24.105
$ ssh root@192.168.24.105Copy to Clipboard Copied! Toggle word wrap Toggle overflow
检查内省存储
director 使用 OpenStack Object Storage（swift）保存在内省过程中获得的硬件数据。如果这个服务没有运行，内省将失败。检查并确定所有与 OpenStack Object Storage 相关的服务都在运行：
sudo systemctl list-units openstack-swift*
$ sudo systemctl list-units openstack-swift*13.3. 故障排除工作流和执行
OpenStack Workflow（mistral）服务将多项 OpenStack 任务组合成工作流。Red Hat OpenStack Platform 使用一套这样的工作流来执行 CLI 和 Web UI 中的常见功能。其中包括裸机节点控制、验证、计划管理和 overcloud 部署。
例如，在运行 openstack overcloud deploy 命令时，OpenStack Workflow 服务执行两个工作流。第一个工作流上传部署计划：
Removing the current plan files Uploading new plan files Started Mistral Workflow. Execution ID: aef1e8c6-a862-42de-8bce-073744ed5e6b Plan updated
Removing the current plan files
Uploading new plan files
Started Mistral Workflow. Execution ID: aef1e8c6-a862-42de-8bce-073744ed5e6b
Plan updated第二个工作流启动 overcloud 部署：
工作流对象
OpenStack Workflow 使用以下对象来跟踪工作流：
- Actions
- 相关的任务运行时，OpenStack 会执行特定的指令。例如，运行 shell 脚本或执行 HTTP 请求。一些 OpenStack 组件内置有可供 OpenStack Workflow 使用的操作。
- 任务
- 定义要运行的操作以及运行该操作的结果。这些任务通常关联有操作或其他工作流。完成一项任务时，工作流会定向到另一任务，这通常取决于前一任务的成败状况。
- 工作流
- 分组在一起并以特定顺序执行的一组任务。
- 执行
- 定义特定操作、任务或工作流的运行。
工作流错误诊断
OpenStack Workflow 还提供了强大的执行日志记录，帮助您辨别与特定命令失败相关的问题。例如，如果某一工作流执行失败，您可以确定其故障点。列出具有已失败状态 ERROR 的工作流执行记录：
source ~/stackrc
$ source ~/stackrc
(undercloud) $ openstack workflow execution list | grep "ERROR"获取已失败的工作流执行的 UUID（例如，dffa96b0-f679-4cd2-a490-4769a3825262）并查看执行信息及输出结果：
(undercloud) $ openstack workflow execution show dffa96b0-f679-4cd2-a490-4769a3825262 (undercloud) $ openstack workflow execution output show dffa96b0-f679-4cd2-a490-4769a3825262
(undercloud) $ openstack workflow execution show dffa96b0-f679-4cd2-a490-4769a3825262
(undercloud) $ openstack workflow execution output show dffa96b0-f679-4cd2-a490-4769a3825262
通过这些可了解执行中失败的任务的相关信息。openstack workflow execution show 还显示执行时所用的工作流（例如，tripleo.plan_management.v1.publish_ui_logs_to_swift）。您可以使用以下命令查看完整的工作流定义：
(undercloud) $ openstack workflow definition show tripleo.plan_management.v1.publish_ui_logs_to_swift
(undercloud) $ openstack workflow definition show tripleo.plan_management.v1.publish_ui_logs_to_swift这可用于辨别特定任务在工作流中的位置。
您也可以使用类似的命令语法查看操作执行及其结果：
(undercloud) $ openstack action execution list (undercloud) $ openstack action execution show 8a68eba3-0fec-4b2a-adc9-5561b007e886 (undercloud) $ openstack action execution output show 8a68eba3-0fec-4b2a-adc9-5561b007e886
(undercloud) $ openstack action execution list
(undercloud) $ openstack action execution show 8a68eba3-0fec-4b2a-adc9-5561b007e886
(undercloud) $ openstack action execution output show 8a68eba3-0fec-4b2a-adc9-5561b007e886这可用于辨别导致问题的具体操作。
13.4. 对创建 overcloud 进行故障排除
实施的过程可能会在 3 个层面出现问题：
- 编配（heat 和 nova 服务）
- 裸机部署（ironic 服务）
- 实施后的配置（Puppet）
如果 overcloud 的部署在以上任何层面中出现问题，可使用 OpenStack 客户端和服务日志文件来诊断失败的部署。
13.4.1. 编配
在多数情况下，Heat 会在 overcloud 创建失败后显示出现问题的 overcloud 栈：
如果栈列表为空，这意味着出现的问题与初始的 Heat 设置相关。检查您的 Heat 模板和配置选项，并检查在运行 openstack overcloud deploy 后的错误信息。
13.4.2. 裸机部署
使用 ironic 查看所有注册的节点和它们当前的状态：
以下是一些在部署过程中常见的问题。
在结果列表中检查 Provision State 和 Maintenance 栏中的数据。检查以下情况：
- 结果列表为空，或比期望的节点要少
- Maintenance 被设置为 True
-
Provision State 被设置为
manageable。这通常意味着问题是由注册或发现过程造成的。例如，如果 Maintenance 被自动设置为 True，这通常是因为节点使用了错误的电源管理凭证。
-
如果 Provision State 的值是
available，这意味着问题发生在裸机部署开始前。 -
如果 Provision State 的值是
active，Power State 的值是power on，这意味着裸机部署已成功完成，所出现的问题发生在实施后的配置阶段。 -
如果一个节点的 Provision State 值是
wait call-back，这意味着对这个节点的裸机部署还没有完成。等待这个状态改变；或连接到出现问题的节点的虚拟控制台上检查相关的输出。 如果 Provision State 的值是
error或deploy failed，则意味着对这个节点的裸机部署失败。检查裸机节点的详情：(undercloud) $ openstack baremetal node show [NODE UUID]
(undercloud) $ openstack baremetal node show [NODE UUID]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 查看包括错误描述信息的
last_error项。如果错误信息不明确，您可以查看相应的日志：(undercloud) $ sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-api
(undercloud) $ sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
如果您看到
wait timeout error信息，节点的 Power State 值是power on，连接到出现问题的节点的虚拟控制台上检查相关的输出。
13.4.3. 实施后的配置
在配置阶段会发生许多事情。例如，特定的 Puppet 模块可能会因为设置的问题出错。本节提供了诊断相关问题的方法。
列出 overcloud 栈中的所有资源来找出哪个出现了问题：
source ~/stackrc
$ source ~/stackrc
(undercloud) $ openstack stack resource list overcloud --filter status=FAILED这会显示所有出问题的资源的列表。
显示出问题的资源：
(undercloud) $ openstack stack resource show overcloud [FAILED RESOURCE]
(undercloud) $ openstack stack resource show overcloud [FAILED RESOURCE]
查看 resource_status_reason 项中的内容来帮助进行诊断。
使用 nova 命令查看 overcloud 节点的 IP 地址。
(undercloud) $ openstack server list
(undercloud) $ openstack server list
以 heat-admin 用户身份登录到一个实施的节点上。例如，栈资源列表显示一个 Controller 节点出现问题，您可以登录到那个 Controller 节点。heat-admin 用户有 sudo 访问权限。
(undercloud) $ ssh heat-admin@192.168.24.14
(undercloud) $ ssh heat-admin@192.168.24.14
检查 os-collect-config 日志找出可能造成故障的原因。
sudo journalctl -u os-collect-config
[heat-admin@overcloud-controller-0 ~]$ sudo journalctl -u os-collect-config
在某些情况下，会出现 nova 未完整部署节点的情况。在这种情况下，一个 overcloud 角色类型的 OS::Heat::ResourceGroup 会出错。这时，可使用 nova 来查看问题。
(undercloud) $ openstack server list (undercloud) $ openstack server show [SERVER ID]
(undercloud) $ openstack server list
(undercloud) $ openstack server show [SERVER ID]
多数常见错误会显示 No valid host was found 错误信息，请参阅 第 13.6 节 “对 "No Valid Host Found" 错误进行故障排除” 来获得更多与排除这类错误相关的信息。在其它情况下，查看以下日志文件来进行进一步的故障排除：
-
/var/log/nova/* -
/var/log/heat/* -
/var/log/ironic/*
控制器节点部署后的过程由 5 个主要部署步骤组成：
|
步骤 |
描述 |
|
|
初始负载均衡软件配置，包括 Pacemaker、RabbitMQ、Memcached、Redis 和 Galera。 |
|
|
初始集群配置，包括 Pacemaker 配置、HAProxy、MongoDB、Galera、Ceph Monitor，以及 OpenStack Platform 服务的数据库初始化。 |
|
|
初始构建 OpenStack 对象存储 ( |
|
|
在 Pacemaker 中配置服务启动设置，包括决定服务启动顺序的限制，以及服务启动的参数。 |
|
|
初始配置 OpenStack Identity ( |
13.5. 排除 Provisioning Network 中出现的 IP 地址冲突的问题
当目标主机被分配了一个已在使用的 IP 地址时，发现和部署任务将会失败。为了避免这个问题，可以对 Provisioning 网络进行一个端口扫描，从而决定发现的 IP 范围和主机的 IP 范围是否可用。
在 undercloud 主机上执行以下步骤：
安装 nmap:
sudo yum install nmap
$ sudo yum install nmap
使用 nmap 命令扫描 IP 地址范围中的活动地址。这个示例会扫描 192.168.24.0/24 这个范围，使用 Provisioning 网络的 IP 子网值（使用 CIDR 位掩码符号 ）替换它：
sudo nmap -sn 192.168.24.0/24
$ sudo nmap -sn 192.168.24.0/24
检查 nmap 扫描的结果输出：
例如，您应该看到 undercloud 的 IP 地址，以及该子网中的任何其他主机。如果这些活跃的 IP 地址和 undercloud.conf 中指定的 IP 地址范围有冲突，则需要在内省或部署overcloud 节点前修改 IP 地址范围或释放一些 IP 地址。
13.6. 对 "No Valid Host Found" 错误进行故障排除
在一些情况下，/var/log/nova/nova-conductor.log 包括了以下错误：
NoValidHost: No valid host was found. There are not enough hosts available.
NoValidHost: No valid host was found. There are not enough hosts available.这意味着 nova Scheduler 无法找到合适的裸机节点来引导新的实例。造成这个问题的原因通常是 nova 所期望的资源和 Ironic 通知给 Nova 的资源不匹配。检查以下内容：
确保內省可以成功完成。否则，检查每个节点都包括了需要的 ironic 节点属性。对于每个节点：
source ~/stackrc
$ source ~/stackrc (undercloud) $ openstack baremetal node show [NODE UUID]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
propertiesJSON 项中的cpus、cpu_arch、memory_mb和local_gb都有有效的值。根据 ironic 节点属性检查使用的 nova flavor 没有超过特定数量：
(undercloud) $ openstack flavor show [FLAVOR NAME]
(undercloud) $ openstack flavor show [FLAVOR NAME]Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
根据
openstack baremetal node list检查是否有足够的节点处于available状态。节点处于manageable状态通常表示内省失败。 使用
openstack baremetal node list检查没有处于维护模式的节点。当一个节点自动变为维护模式时，通常意味着电源凭证不正确。检查凭证并取消维护模式：(undercloud) $ openstack baremetal node maintenance unset [NODE UUID]
(undercloud) $ openstack baremetal node maintenance unset [NODE UUID]Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
如果您使用自动健康状态检查 (AHC) 工具来自动标记节点，请检查是否有足够的节点对应于每种类型/配置文件。检查
openstack baremetal node show的properties字段中的capabilities键值。例如，标记为 Compute 角色的节点应包含profile:compute这样的信息。 內省操作后，从 ironic 向 nova 传递节点信息可能需要一些时间。director 的工具通常会把这个时间考虑进去。但是，如果您手工进行了一些操作，节点可能会短时间内对 nova 不可用。使用以下命令检查系统中的总体资源：
(undercloud) $ openstack hypervisor stats show
(undercloud) $ openstack hypervisor stats showCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.7. 在创建后对 overcloud 进行故障排除
在创建完 overcloud 后，可能还会需要在以后执行特定的 overcloud 操作。例如，可能会需要扩展可用节点，或替换出现故障的节点。在执行这些操作时，可能会出现某些问题。本节就如何对出现失败的创建后操作进行诊断和故障排除提供一些建议。
13.7.1. overcloud 栈的修改
当通过 director 修改 overcloud 栈时可能会出现问题。对栈进行修改可能包括：
- 扩展节点
- 删除节点
- 替换节点
修改栈的过程和创建栈的过程相似，director 会检查请求的节点数是否有效，部署额外的节点或删除存在的节点，然后应用 Puppet 配置。在修改 overcloud 栈时需要遵循以下的一些建议。
在初始设置时，遵循 第 13.4.3 节 “实施后的配置” 中的建议。这些相同的步骤可以帮助排除更新 overcloud heat 栈时出现的问题。特别是，使用以下命令帮助查找有问题的资源：
openstack stack list --show-nested-
列出所有栈。
--show-nested会显示所有子栈以及它们的父栈。这可以帮助判断栈在什么地方出现问题。 openstack stack resource list overcloud-
列出
overcloud栈中的所有资源，以及它们当前的状态。这可以帮助找出哪些资源造成了栈出现问题。您可以通过这些失败的资源追踪到 heat 模板集合和 Puppet 模块中的相关参数和配置。 openstack stack event list overcloud-
以发生的时间顺序列出与
overcloud栈相关的所有事件。这包括初始化事件、操作完成事件以及栈中所有失败的资源。这些信息可以帮助找出造成资源失败的原因。
下面几节介绍了针对特定节点类型的故障诊断建议。
13.7.2. Controller 服务失败
overcloud 控制器节点包括大量 Red Hat OpenStack Platform 服务，您也可能在一个高可用性的集群中使用多个控制器节点。如果一个节点上的特定服务出现问题，高可用性集群会提供一定程度的故障转移功能。但是，您需要对出现问题的服务进行诊断，从而确保 overcloud 能以最大能力运行。
在高可用性集群中，控制器节点使用 Pacemaker 管理资源和服务。Pacemaker Configuration System（pcs）命令是一个用来管理 Pacemaker 集群的工具。在集群的控制器节点上运行这个命令来执行配置和监控功能。在高可用性集群中，可以使用以下命令帮助对 overcloud 服务进行故障排除：
pcs status- 当前整个集群的状态概况信息，包括启用的资源、失败的资源和在线节点信息。
pcs resource show- 显示资源列表，以及与它们相关的节点。
pcs resource disable [resource]- 停止一个特定的资源。
pcs resource enable [resource]- 启动一个特定的资源。
pcs cluster standby [node]- 把节点设置为待机（standby）模式，使这个节点在集群中不再可用。这可以被用来在不影响集群运行的情况下对特定节点进行维护操作。
pcs cluster unstandby [node]- 取消一个节点的待机模式。这个节点将可以重新在集群中使用。
使用这些 Pacemaker 命令来找出有问题的组件和节点。当找到有问题的组件时，在 /var/log/ 中查看相关的组件日志文件。
13.7.3. 容器化服务故障
如果容器化服务在 overcloud 部署期间或之后出现故障，请按照以下建议确定故障的根本原因：
在运行这些命令之前，请先检查您是否已登录 overcloud 节点且未在 undercloud 上运行这些命令。
查看容器日志
每个容器都会保留其主进程的标准输出内容。这些输出内容会被用作日志，以帮助确定容器运行期间发生的具体情况。例如，要查看 keystone 容器的日志，请使用以下命令：
sudo docker logs keystone
$ sudo docker logs keystone在大多数情况下，该日志可指明容器出现故障的原因。
检查容器
在某些情况下，您可能需要验证容器的相关信息。例如，请使用以下命令来查看 keystone 容器的相关数据：
sudo docker inspect keystone
$ sudo docker inspect keystone
这会提供一个包含低级别配置数据的 JSON 对象。您可以通过管道将这些输出内容传递给 jq 命令，以对特定数据进行解析。例如，要查看 keystone 容器的加载情况，请运行以下命令：
sudo docker inspect keystone | jq .[0].Mounts
$ sudo docker inspect keystone | jq .[0].Mounts
您还可以使用 --format 选项将数据解析到一行中，这在针对一组容器数据运行命令时非常有用。例如，要重建用于运行 keystone 容器的选项，请使用包含 --format 选项的以下 inspect 命令：
sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone
$ sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone
--format 选项会按照 Go 语法来创建查询。
请在 docker run 命令中使用以下选项来重建容器，以便进行故障诊断：
OPTIONS=$( sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
sudo docker run --rm $OPTIONS /bin/bash
$ OPTIONS=$( sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo docker run --rm $OPTIONS /bin/bash在容器中运行命令
在某些情况下，您可能需要通过特定的 Bash 命令从容器中获取信息。此时，请使用以下 docker 命令，以便在正在运行的容器中执行相关命令。例如，要在 keystone 容器中运行某个命令，请使用以下命令：
sudo docker exec -ti keystone <COMMAND>
$ sudo docker exec -ti keystone <COMMAND>
-ti 选项会通过交互式伪终端来运行命令。
请将 <COMMAND> 替换成您所需的命令。例如，每个容器都有一个健康检查脚本，用于验证服务的连接状况。您可以使用以下命令为 keystone 运行这个健康检查脚本：
sudo docker exec -ti keystone /openstack/healthcheck
$ sudo docker exec -ti keystone /openstack/healthcheck
要访问容器的 shell，请使用 /bin/bash 运行 docker exec（如以下命令所示）：
sudo docker exec -ti keystone /bin/bash
$ sudo docker exec -ti keystone /bin/bash导出容器
当容器出现故障时，您可能需要调查文件中包含的所有内容。在这种情况下，您可以将容器的整个文件系统导出为 tar 归档。例如，要导出 keystone 容器的文件系统，请运行以下命令：
sudo docker export keystone -o keystone.tar
$ sudo docker export keystone -o keystone.tar
这个命令会创建 keystone.tar 归档，以供您提取和研究。
13.7.4. Compute 服务失败
Compute 节点使用 Compute 服务来执行基于虚拟机监控程序的操作。这意味着，对 Compute 节点进行故障排除可以解决与这个服务相关的问题。例如：
查看容器状态：
sudo docker ps -f name=nova_compute
$ sudo docker ps -f name=nova_computeCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Compute 节点的主日志文件为
/var/log/containers/nova/nova-compute.log。如果与 Compute 节点的通信出现问题，从这个日志文件开始诊断是个好办法。 - 如果需要在 Compute 节点上进行维护工作，把主机上存在的实例迁移到另外一个可以正常工作的 Compute 节点上，然后禁用需要进行维护的节点。如需了解更多节点迁移的信息，请参阅 第 9.10 节 “从 Compute 节点中迁移实例”。
13.7.5. Ceph Storage 服务故障
如果 Red Hat Ceph Storage 集群出现任何问题，请参阅 Red Hat Ceph Storage Configuration Guide 中的“Logging Configuration Reference”。本节提供了与所有 Ceph Storage 服务的日志诊断相关的信息。
13.8. 对 undercloud 进行性能微调
本节中提供的建议旨在帮助提高 undercloud 的性能。您可以根据自己的需要实施相关的建议。
-
Identity 服务 (keystone) 使用一个基于令牌的系统来控制对其它 OpenStack 服务的访问。在运行了一定时间后，数据库中会积累大量未使用的令牌，默认的 cronjob 作业会每天刷新令牌表。建议您对自己的环境进行监控并按需调整令牌刷新间隔。对于 undercloud，可以使用
crontab -u keystone -e调整间隔。需要注意，这只是一种临时更改，openstack undercloud update会重置 cronjob 作业，恢复其默认值。 在每次运行
openstack overcloud deploy命令时，Heat 会把所有模板文件复制到它的数据库中的raw_template表中。raw_template表会包括过去所有的模板，并随着时间的推移变得非常大。您可以创建一个每日运行的 cronjob 来删除raw_templates表中那些不再使用的、存在时间超过一天的模板：0 04 * * * /bin/heat-manage purge_deleted -g days 1
0 04 * * * /bin/heat-manage purge_deleted -g days 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在一些时候，
openstack-heat-engine和openstack-heat-api服务可能会消耗大量资源。如果这个情况发生了，在/etc/heat/heat.conf中设置max_resources_per_stack=-1，然后重启 heat 服务：sudo systemctl restart openstack-heat-engine openstack-heat-api
$ sudo systemctl restart openstack-heat-engine openstack-heat-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在一些时候，director 可能没有足够的资源来执行并行的节点设置（默认是可以同时并行设置 10 个节点）。为了减少并行节点的数量，把
/etc/nova/nova.conf中的max_concurrent_builds参数设置为一个小于 10 的值，然后重启 nova 服务：sudo systemctl restart openstack-nova-api openstack-nova-scheduler
$ sudo systemctl restart openstack-nova-api openstack-nova-schedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑
/etc/my.cnf.d/server.cnf文件。可以用来微调的值包括：- max_connections
- 可以同时连接到数据库的连接数量。推荐的值是 4096。
- innodb_additional_mem_pool_size
- 数据库用来存储数据字典信息和其他内部数据结构的内存池大小（以字节为单位）。默认值是 8M，undercloud 的理想值是 20M。
- innodb_buffer_pool_size
- 数据库用来缓存表和索引数据的内存区域（即缓冲池）的大小（以字节为单位）。默认值是 128M，undercloud 的理想值是 1000M。
- innodb_flush_log_at_trx_commit
- commit 操作对 ACID 原则的遵守，与高性能间的平衡控制。把它设置为 1。
- innodb_lock_wait_timeout
- 数据库交易在放弃等待行锁定前等待的时间长度（以秒为单位）。把它设置为 50。
- innodb_max_purge_lag
- 在 purge 操作滞后时，如何延迟 INSERT、UPDATE 和 DELETE 操作。把它设为 10000。
- innodb_thread_concurrency
- 并行操作系统线程的限制。理想情况下，为每个 CPU 和磁盘资源最少提供 2 个线程。例如，具有一个 4 核 CPU 和一个磁盘，则提供 10 个线程。
确保 heat 有足够的 worker 来执行 overcloud 创建。通常情况下，这取决于 undercloud 有多少个 CPU。若要手动设置 worker 的数量，可编辑
/etc/heat/heat.conf文件，把num_engine_workers参数的值设置为所需的 worker 数量（理想值是 4），然后重启 heat 引擎：sudo systemctl restart openstack-heat-engine
$ sudo systemctl restart openstack-heat-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.9. 创建 sosreport
如果您需要与红帽联系获得 OpenStack Platform 的产品支持，可能需要生成一份 sosreport。如需了解有关如何创建 sosreport 的更多信息，请参阅以下知识库文章：
13.10. undercloud 和 overcloud 的重要日志
在故障排除时，使用以下日志查找 undercloud 和 overcloud 的信息。
| 信息 | 日志位置 |
|---|---|
|
OpenStack Compute 日志 |
|
|
OpenStack Compute API 交互 |
|
|
OpenStack Compute Conductor 日志 |
|
|
OpenStack Orchestration 日志 |
|
|
OpenStack Orchestration API 交互 |
|
|
OpenStack Orchestration CloudFormations 日志 |
|
|
OpenStack Bare Metal Conductor 日志 |
|
|
OpenStack Bare Metal API 交互 |
|
|
内省（Introspection） |
|
|
OpenStack Workflow Engine 日志 |
|
|
OpenStack Workflow Executor 日志 |
|
|
OpenStack Workflow API 交互 |
|
| 信息 | 日志位置 |
|---|---|
|
Cloud-Init 日志 |
|
|
overcloud 配置（最后一次 Puppet 运行的概述） |
|
|
overcloud 配置（最后一次 Puppet 运行的报告） |
|
|
overcloud 配置（所有 Puppet 报告） |
|
|
overcloud 配置（来自每一次 Puppet 运行的 stdout） |
|
|
overcloud 配置（来自每一次 Puppet 运行的 stderr） |
|
|
高可用性日志 |
|
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}