Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第 11 章 对 director 进行故障排除

在进行 director 操作时可能会在特定阶段出现问题。本节提供了对常见问题进行诊断的信息。

查看 director 组件的日志文件:

  • /var/log 目录包括了许多常见 OpenStack Platform 组件的日志文件,以及标准 Red Hat Enterprise Linux 应用的日志文件。
  • journald 服务为多个组件提供日志功能。ironic 使用两个单元:openstack-ironic-apiopenstack-ironic-conductor。同样的,ironic-inspector 也使用两个单元:openstack-ironic-inspectoropenstack-ironic-inspector-dnsmasq。以下是使用这个服务的示例:

    $ sudo journalctl -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq
  • ironic-inspector 还把 ramdisk 的日志保存在 /var/log/ironic-inspector/ramdisk/ 中(gz 压缩的 tar 文件)。它们的文件名中包括日期、时间和节点的 IPMI 地址。使用这些日志来对相关的服务进行诊断。

11.1. 对节点注册进行故障排除

与节点注册相关的问题通常是因为不正确的节点详情造成的。在这种情况下,使用带有正确节点数据的 ironic 来解决相关的问题。以下是几个示例:

找到分配的端口 UUID:

$ ironic node-port-list [NODE UUID]

更新 MAC 地址:

$ ironic port-update [PORT UUID] replace address=[NEW MAC]

运行以下命令:

$ ironic node-update [NODE UUID] replace driver_info/ipmi_address=[NEW IPMI ADDRESS]

11.2. 对硬件內省的故障排除

內省(introspection)过程需要被正确完成。但是,如果发现 ramdisk 没有响应,ironic 的发现守护进程(ironic-inspector)会默认在一个小时后出现超时。在一些时候,这意味着发现 ramdisk 有问题,但通常情况下是因为不正确的环境配置,特别是 BIOS 引导设置。

以下是一些常见的不正确的环境配置情况,以及如果诊断和解决它们的建议。

启动节点內省操作错误

通常,內省操作会使用 baremetal introspection 命令,它是一个安全调用 Ironic 服务的命令。但是,如果直接使用 ironic-inspector,它可能在发现状态是 AVAILABLE 的节点过程中出现问题。在进行发现操作前,把节点的状态改为 MANAGEABLE:

$ ironic node-set-provision-state [NODE UUID] manage

当发现操作完成后,在进行部署前把状态改回到 AVAILABLE:

$ ironic node-set-provision-state [NODE UUID] provide

内省的节点没有在 PXE 中引导

在重新引导节点前,ironic-inspector 会把节点的 MAC 地址添加到 undercloud 防火墙的 ironic-inspector 链中。这将允许节点通过 PXE 进行引导。运行以下命令可以验证配置是否正确:

$ `sudo iptables -L`

这个命令的输出应该包括以下带有 MAC 地址的链列表:

Chain ironic-inspector (1 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             MAC xx:xx:xx:xx:xx:xx
ACCEPT     all  --  anywhere             anywhere

如果没有 MAC 地址,最常见的可能是 ironic-inspector 缓存数据(位于 SQLite 数据库中)被破坏。要解决这个问题,删除 SQLite 文件:

$ sudo rm /var/lib/ironic-inspector/inspector.sqlite

再重新创建它:

$ sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
$ sudo systemctl restart openstack-ironic-inspector

停止发现过程

当前,ironic-inspector 没有提供一个直接停止发现过程的方法。我们推荐的方法是等待发现过程的超时发生。如果需要,可以修改 /etc/ironic-inspector/inspector.conf 中的 timeout 设置来设定一个新的超时时间(以分钟为单位)。

在最坏的情况下,您可以使用以下步骤停止所有节点的发现操作:

把每个节点的电源状态改为 off:

$ ironic node-set-power-state [NODE UUID] off

删除 ironic-inspector 的缓存数据并重启它:

$ rm /var/lib/ironic-inspector/inspector.sqlite

重新同步 ironic-inspector 缓存:

$ sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
$ sudo systemctl restart openstack-ironic-inspector

检查内省存储

director 使用 OpenStack Object Storage(swift)保存在内省过程中获得的硬件数据。如果这个服务没有运行,内省将失败。检查并确定所有与 OpenStack Object Storage 相关的服务都在运行:

$ sudo systemctl list-units openstack-swift*

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

第二个工作流启动 overcloud 部署:

Deploying templates in the directory /tmp/tripleoclient-LhRlHX/tripleo-heat-templates
Started Mistral Workflow. Execution ID: 97b64abe-d8fc-414a-837a-1380631c764d
2016-11-28 06:29:26Z [overcloud]: CREATE_IN_PROGRESS  Stack CREATE started
2016-11-28 06:29:26Z [overcloud.Networks]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.HeatAuthEncryptionKey]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.ServiceNetMap]: CREATE_IN_PROGRESS  state changed
...

工作流对象

OpenStack Workflow 使用以下对象来跟踪工作流:

Actions
相关的任务运行时,OpenStack 会执行特定的指令。例如,运行 shell 脚本或执行 HTTP 请求。一些 OpenStack 组件内置有可供 OpenStack Workflow 使用的操作。
任务
定义要运行的操作以及运行该操作的结果。这些任务通常关联有操作或其他工作流。完成一项任务时,工作流会定向到另一任务,这通常取决于前一任务的成败状况。
工作流
分组在一起并以特定顺序执行的一组任务。
执行
定义特定操作、任务或工作流的运行。

工作流错误诊断

OpenStack Workflow 还提供了强大的执行日志记录,帮助您辨别与特定命令失败相关的问题。例如,如果某一工作流执行失败,您可以确定其故障点。列出具有已失败状态 ERROR 的工作流执行记录:

$ mistral execution-list | grep "ERROR"

获取已失败工作流执行记录的 UUID(如 3c87a885-0d37-4af8-a471-1b392264a7f5),查看执行情况及其输出:

$ mistral execution-get 3c87a885-0d37-4af8-a471-1b392264a7f5
$ mistral execution-get-output 3c87a885-0d37-4af8-a471-1b392264a7f5

这可提供执行中已失败任务的相关信息。mistral execution-get 也会显示用于该执行的工作流(例如, tripleo.plan_management.v1.update_deployment_plan)。您可以使用以下命令查看完整的工作流定义:

$ mistral execution-get-definition tripleo.plan_management.v1.update_deployment_plan

这可用于辨别特定任务在工作流中的位置。

您也可以使用类似的命令语法查看操作执行及其结果:

$ mistral action-execution-list
$ mistral action-execution-get b59245bf-7183-4fcf-9508-c83ec1a26908
$ mistral action-execution-get-output b59245bf-7183-4fcf-9508-c83ec1a26908

这可用于辨别导致问题的具体操作。

11.4. 对创建 overcloud 进行故障排除

实施的过程可能会在 3 个层面出现问题:

  • 编配(heat 和 nova 服务)
  • 裸机部署(ironic 服务)
  • 实施后的配置(Puppet)

如果 overcloud 的部署在以上任何层面中出现问题,可使用 OpenStack 客户端和服务日志文件来诊断失败的部署。

11.4.1. 编配

在多数情况下,Heat 会在 overcloud 创建失败后显示出现问题的 overcloud 栈:

$ heat stack-list
+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+

如果栈列表为空,这意味着出现的问题与初始的 Heat 设置相关。检查您的 Heat 模板和配置选项,并检查在运行 openstack overcloud deploy 后的错误信息。

11.4.2. 裸机部署

使用 ironic 查看所有注册的节点和它们当前的状态:

$ ironic node-list

+----------+------+---------------+-------------+-----------------+-------------+
| UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
+----------+------+---------------+-------------+-----------------+-------------+
| f1e261...| None | None          | power off   | available       | False       |
| f0b8c1...| None | None          | power off   | available       | False       |
+----------+------+---------------+-------------+-----------------+-------------+

以下是一些在部署过程中常见的问题。

  • 在结果列表中检查 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 的值是 errordeploy failed,则意味着对这个节点的裸机部署失败。检查裸机节点的详情:

    $ ironic node-show [NODE UUID]

    查看包括错误描述信息的 last_error 项。如果错误信息不明确,您可以查看相应的日志:

    $ sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-api
  • 如果您看到 wait timeout error 信息,节点的 Power State 值是 power on,连接到出现问题的节点的虚拟控制台上检查相关的输出。

11.4.3. 实施后的配置

在配置阶段会发生许多事情。例如,特定的 Puppet 模块可能会因为设置的问题出错。本小节提供了诊断相关问题的方法。

列出 overcloud 栈中的所有资源来找出哪个出现了问题:

$ heat resource-list overcloud

这会显示一个包括所有资源以及它们的状态的列表。查看带有 CREATE_FAILED 的资源。

显示出问题的资源:

$ heat resource-show overcloud [FAILED RESOURCE]

查看 resource_status_reason 项中的内容来帮助进行诊断。

使用 nova 命令查看 overcloud 节点的 IP 地址。

$ nova list

heat-admin 用户身份登录到一个实施的节点上。例如,栈资源列表显示一个 Controller 节点出现问题,您可以登录到那个 Controller 节点。heat-admin 用户有 sudo 访问权限。

$ ssh heat-admin@192.168.24.14

检查 os-collect-config 日志找出可能造成故障的原因。

$ sudo journalctl -u os-collect-config

在某些情况下,会出现 nova 未完整部署节点的情况。在这种情况下,一个 overcloud 角色类型的 OS::Heat::ResourceGroup 会出错。这时,可使用 nova 来查看问题。

$ nova list
$ nova show [SERVER ID]

多数常见错误会显示 No valid host was found 错误信息,请参阅 第 11.6 节 “对 "No Valid Host Found" 错误进行故障排除” 来获得更多与排除这类错误相关的信息。在其它情况下,查看以下日志文件来进行进一步的故障排除:

  • /var/log/nova/*
  • /var/log/heat/*
  • /var/log/ironic/*

使用 SOS 工具包来收集系统硬件和配置的信息。这些信息可用于进行故障排除和调试。SOS 受到技术支持和开发人员的广泛采用。SOS 在 undercloud 和 overcloud 中都有用。安装 sos 软件包:

$ sudo yum install sos

产生一个报告

$ sudo sosreport --all-logs

控制器节点部署后的过程由 5 个主要部署步骤组成:

表 11.1. Controller 节点配置步骤

步骤

描述

ControllerDeployment_Step1

初始负载均衡软件配置,包括 Pacemaker、RabbitMQ、Memcached、Redis 和 Galera。

ControllerDeployment_Step2

初始集群配置,包括 Pacemaker 配置、HAProxy、MongoDB、Galera、Ceph Monitor,以及 OpenStack Platform 服务的数据库初始化。

ControllerDeployment_Step3

初始构建 OpenStack 对象存储 (swift) 的 ring。配置所有 OpenStack Platform 服务(novaneutroncindersaharaceilometerheathorizonaodhgnocchi)。

ControllerDeployment_Step4

在 Pacemaker 中配置服务启动设置,包括决定服务启动顺序的限制,以及服务启动的参数。

ControllerDeployment_Step5

初始配置 OpenStack Identity (keystone) 中的项目、角色和用户。

11.5. 排除 Provisioning Network 中出现的 IP 地址冲突的问题

当目标主机被分配了一个已在使用的 IP 地址时,发现和部署任务将会失败。为了避免这个问题,可以对 Provisioning 网络进行一个端口扫描,从而决定发现的 IP 范围和主机的 IP 范围是否可用。

在 undercloud 主机上执行以下步骤:

安装 nmap:

# yum install nmap

使用 nmap 命令扫描 IP 地址范围中的活动地址。这个示例会扫描 192.168.24.0/24 这个范围,使用 Provisioning 网络的 IP 子网值(使用 CIDR 位掩码符号 )替换它:

# nmap -sn 192.168.24.0/24

检查 nmap 扫描的结果输出:

例如,您应该看到 undercloud 的 IP 地址,以及该子网中的任何其他主机。如果这些活跃的 IP 地址和 undercloud.conf 中指定的 IP 地址范围有冲突,则需要在内省或部署overcloud 节点前修改 IP 地址范围或释放一些 IP 地址。

# nmap -sn 192.168.24.0/24

Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
Nmap scan report for 192.168.24.1
Host is up (0.00057s latency).
Nmap scan report for 192.168.24.2
Host is up (0.00048s latency).
Nmap scan report for 192.168.24.3
Host is up (0.00045s latency).
Nmap scan report for 192.168.24.5
Host is up (0.00040s latency).
Nmap scan report for 192.168.24.9
Host is up (0.00019s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds

11.6. 对 "No Valid Host Found" 错误进行故障排除

在一些情况下,/var/log/nova/nova-conductor.log 包括了以下错误:

NoValidHost: No valid host was found. There are not enough hosts available.

这意味着 nova Scheduler 无法找到合适的裸机节点来引导新的实例。造成这个问题的原因通常是 nova 所期望的资源和 Ironic 通知给 Nova 的资源不匹配。检查以下内容:

  1. 确保內省可以成功完成。否则,检查每个节点都包括了需要的 ironic 节点属性。对于每个节点:

    $ ironic node-show [NODE UUID]

    检查 properties JSON 项中的 cpuscpu_archmemory_mblocal_gb 都有有效的值。

  2. 根据 ironic 节点属性检查使用的 nova flavor 没有超过特定数量:

    $ nova flavor-show [FLAVOR NAME]
  3. 根据 ironic node-list 检查有足够状态为 available 的节点。节点的状态为 manageable 通常意味着內省操作失败。
  4. 使用 ironic node-list 检查没有处于维护模式的节点。当一个节点被自动变为维护模式时,通常意味着不正确的电源管理凭证。检查它们并删除维护模式:

    $ ironic node-set-maintenance [NODE UUID] off
  5. 如果您使用 AHC 工具程序来自动标记节点,请根据每个 flavor 和配置集来检查是否有足够的相关节点。检查 ironic node-show 输出中的 properties 项的 capabilities 值。例如,一个标记为 Compute 角色的节点应该包括 profile:compute
  6. 在进行完內省操作后,从 ironic 为 nova 生成节点信息可能会需要一些时间来完成。director 的工具程序通常会把这个时间考虑进去。但是,如果您手工进行了一些操作,节点可能会在一个短时间内对 nova 无效。使用以下命令检查系统中的总资源:

    $ nova hypervisor-stats

11.7. 在创建后对 overcloud 进行故障排除

在创建完 overcloud 后,可能还会需要在以后执行特定的 overcloud 操作。例如,可能会需要扩展可用节点,或替换出现故障的节点。在执行这些操作时,可能会出现某些问题。本节就如何对出现失败的创建后操作进行诊断和故障排除提供一些建议。

11.7.1. overcloud 栈的修改

当通过 director 修改 overcloud 栈时可能会出现问题。对栈进行修改可能包括:

  • 扩展节点
  • 删除节点
  • 替换节点

修改栈的过程和创建栈的过程相似,director 会检查请求的节点数是否有效,部署额外的节点或删除存在的节点,然后应用 Puppet 配置。在修改 overcloud 栈时需要遵循以下的一些建议。

在初始设置时,遵循 第 11.4.3 节 “实施后的配置” 中的建议。这些相同的步骤可以帮助排除更新 overcloud heat 栈时出现的问题。特别是,使用以下命令帮助查找有问题的资源:

heat stack-list --show-nested
列出所有栈。--show-nested 会显示所有子栈以及它们的父栈。这可以帮助判断栈在什么地方出现问题。
heat resource-list overcloud
列出 overcloud 栈中的所有资源,以及它们当前的状态。这可以帮助找出哪些资源造成了栈出现问题。您可以通过这些失败的资源追踪到 heat 模板集合和 Puppet 模块中的相关参数和配置。
heat event-list overcloud
以发生的时间顺序列出与 overcloud 栈相关的所有事件。这包括初始化事件、操作完成事件以及栈中所有失败的资源。这些信息可以帮助找出造成资源失败的原因。

下面的几个小节介绍了针对特定节点类型的故障诊断建议。

11.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/ 中查看相关的组件日志文件。

11.7.3. Compute 服务失败

Compute 节点使用 Compute 服务来执行基于虚拟机监控程序的操作。这意味着,对 Compute 节点进行故障排除可以解决与这个服务相关的问题。例如:

  • 使用 systemd 的以下功能查看服务的状态:

    $ sudo systemctl status openstack-nova-compute.service

    同样,使用以下命令查看服务的 systemd 日志:

    $ sudo journalctl -u openstack-nova-compute.service
  • Compute 节点的主日志文件是 /var/log/nova/nova-compute.log。如果到 Compute 节点的通讯出现问题,从这个文件开始进行故障排除会是一个好的方法。
  • 如果需要在 Compute 节点上进行维护工作,把主机上存在的实例迁移到另外一个可以正常工作的 Compute 节点上,然后禁用需要进行维护的节点。如需了解更多节点迁移的信息,请参阅 ???

11.7.4. Ceph Storage 服务故障

如果 Red Hat Ceph Storage 集群出现故障,参阅“Red Hat Ceph Storage 配置指南”中的 第 10 章:日志和调试。本小节提供与所有 Ceph 存储服务的日志诊断相关的信息。

11.8. 对 undercloud 进行性能微调

本节中提供的建议旨在帮助提高 undercloud 的性能。您可以根据自己的需要实施相关的建议。

  • OpenStack Authentication 服务(keystone)使用一个基于令牌(token)的系统控制对其它 OpenStack 服务的访问。在运行了一定时间后,数据库中会积累大量不再使用的令牌。我们推荐创建一个 cronjob 来定期删除数据库中的令牌表。例如,在每天早上 4 点删除令牌表:

    0 04 * * * /bin/keystone-manage token_flush
  • 在每次运行 openstack overcloud deploy 命令时,Heat 会把所有模板文件复制到它的数据库中的 raw_template 表中。raw_template 表会包括过去所有的模板,并随着时间的推移变得非常大。您可以创建一个每日运行的 cronjob 来删除 raw_templates 表中那些不再使用的、存在时间超过一天的模板:

    0 04 * * * /bin/heat-manage purge_deleted -g days 1
  • 在一些时候,openstack-heat-engineopenstack-heat-api 服务可能会消耗大量资源。如果这个情况发生了,在 /etc/heat/heat.conf 中设置 max_resources_per_stack=-1,然后重启 heat 服务:

    $ sudo systemctl restart openstack-heat-engine openstack-heat-api
  • 在一些时候,director 可能没有足够的资源来执行并行的节点设置(默认是可以同时并行设置 10 个节点)。为了减少并行节点的数量,把 /etc/nova/nova.conf 中的 max_concurrent_builds 参数设置为一个小于 10 的值,然后重启 nova 服务:

    $ sudo systemctl restart openstack-nova-api openstack-nova-scheduler
  • 编辑 /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

11.9. undercloud 和 overcloud 的重要日志

在故障排除时,使用以下日志查找 undercloud 和 overcloud 的信息。

表 11.2. undercloud 的重要日志

信息日志位置

OpenStack Compute 日志

/var/log/nova/nova-compute.log

OpenStack Compute API 交互

/var/log/nova/nova-api.log

OpenStack Compute Conductor 日志

/var/log/nova/nova-conductor.log

OpenStack Orchestration 日志

heat-engine.log

OpenStack Orchestration API 交互

heat-api.log

OpenStack Orchestration CloudFormations 日志

/var/log/heat/heat-api-cfn.log

OpenStack Bare Metal Conductor 日志

ironic-conductor.log

OpenStack Bare Metal API 交互

ironic-api.log

内省(Introspection)

/var/log/ironic-inspector/ironic-inspector.log

OpenStack Workflow Engine 日志

/var/log/mistral/engine.log

OpenStack Workflow Executor 日志

/var/log/mistral/executor.log

OpenStack Workflow API 交互

/var/log/mistral/api.log

表 11.3. overcloud 的重要日志

信息日志位置

Cloud-Init 日志

/var/log/cloud-init.log

overcloud 配置(最后一次 Puppet 运行的概述)

/var/lib/puppet/state/last_run_summary.yaml

overcloud 配置(最后一次 Puppet 运行的报告)

/var/lib/puppet/state/last_run_report.yaml

overcloud 配置(所有 Puppet 报告)

/var/lib/puppet/reports/overcloud-*/*

overcloud 配置(来自每一次 Puppet 运行的 stdout)

/var/run/heat-config/deployed/*-stdout.log

overcloud 配置(来自每一次 Puppet 运行的 stderr)

/var/run/heat-config/deployed/*-stderr.log

高可用性日志

/var/log/pacemaker.log