Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 10 章 对 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。以下是使用这个服务的示例： 

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

10.1. 对节点注册进行故障排除
复制链接

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

找到分配的端口 UUID： 

$ ironic node-port-list [NODE UUID]
Copy to Clipboard Toggle word wrap

更新 MAC 地址： 

$ ironic port-update [PORT UUID] replace address=[NEW MAC]
Copy to Clipboard Toggle word wrap

运行以下命令： 

$ ironic node-update [NODE UUID] replace driver_info/ipmi_address=[NEW IPMI ADDRESS]
Copy to Clipboard Toggle word wrap

10.2. 对硬件內省的故障排除
复制链接

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

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

启动节点內省操作错误

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

$ ironic node-set-provision-state [NODE UUID] manage
Copy to Clipboard Toggle word wrap

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

$ ironic node-set-provision-state [NODE UUID] provide
Copy to Clipboard Toggle word wrap

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

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

$ `sudo iptables -L`
Copy to Clipboard Toggle word wrap

这个命令的输出应该包括以下带有 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
Copy to Clipboard Toggle word wrap

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

$ sudo rm /var/lib/ironic-inspector/inspector.sqlite
Copy to Clipboard Toggle word wrap

再重新创建它： 

$ sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
$ sudo systemctl restart openstack-ironic-inspector
Copy to Clipboard Toggle word wrap

停止发现过程

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

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

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

$ ironic node-set-power-state [NODE UUID] off
Copy to Clipboard Toggle word wrap

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

$ rm /var/lib/ironic-inspector/inspector.sqlite
Copy to Clipboard Toggle word wrap

重新同步 ironic-inspector 缓存： 

$ sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
$ sudo systemctl restart openstack-ironic-inspector
Copy to Clipboard Toggle word wrap

访问内省 Ramdisk

内省 ramdisk 使用一个动态的登录元素。这意味着，在进行内省故障排除时您可以提供一个临时密码或一个 SSH 密钥来访问节点。使用以下方法来设置对 ramdisk 的访问：

  1. 为 openssl passwd -1 命令提供一个临时密码来产生一个 MD5 哈希。例如： 

    $ openssl passwd -1 mytestpassword
$1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/
    Copy to Clipboard Toggle word wrap

  2. 编辑 /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/"
    Copy to Clipboard Toggle word wrap

    或者，使用 sshkey 参数和您的公共 SSH 密钥。

    注意

    rootpwd 和 sshkey 参数都需要使用引号。

  3. 开始内省过程，通过 arp 命令或 DHCP 日志找到 IP 地址： 

    $ arp
$ sudo journalctl -u openstack-ironic-inspector-dnsmasq
    Copy to Clipboard Toggle word wrap

  4. 使用临时密码或 SSH 密钥，以 root 用户身份进行 SSH 连接。 

    $ ssh root@192.0.2.105
    Copy to Clipboard Toggle word wrap

检查内省存储

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

$ sudo systemctl list-units openstack-swift*
Copy to Clipboard Toggle word wrap

10.3. 对创建 Overcloud 进行故障排除
复制链接

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

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

如果 Overcloud 的实施在以上 3 个层面中出现问题，使用 OpenStack 客户端和服务日志文件来诊断相关的错误。

10.3.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 |
+-----------------------+------------+--------------------+----------------------+
Copy to Clipboard Toggle word wrap

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

10.3.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       |
+----------+------+---------------+-------------+-----------------+-------------+
Copy to Clipboard Toggle word wrap

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

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

    $ ironic node-show [NODE UUID]
    Copy to Clipboard Toggle word wrap

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

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

10.3.3. 实施后的配置
复制链接

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

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

$ heat resource-list overcloud
Copy to Clipboard Toggle word wrap

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

显示出问题的资源： 

$ heat resource-show overcloud [FAILED RESOURCE]
Copy to Clipboard Toggle word wrap

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

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

$ nova list
Copy to Clipboard Toggle word wrap

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

$ ssh heat-admin@192.0.2.14
Copy to Clipboard Toggle word wrap

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

$ sudo journalctl -u os-collect-config
Copy to Clipboard Toggle word wrap

在某些情况下，会出现 nova 的整个节点实施过程失败的问题。在这种情况下，一个 Overcloud 角色类型的 OS::Heat::ResourceGroup 会出错。使用 nova 来查看问题。 

$ nova list
$ nova show [SERVER ID]
Copy to Clipboard Toggle word wrap

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

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

使用 SOS 工具包来收集系统硬件和配置的信息。这些信息可被用于进行故障诊断和故障排除。技术支持和开发人员也可以通过 SOS 获得有用的信息。SOS 在 Undercloud 和 Overcloud 中都有用。运行以下命令安装 sos 软件包： 

$ sudo yum install sos
Copy to Clipboard Toggle word wrap

产生一个报告 

$ sudo sosreport --all-logs
Copy to Clipboard Toggle word wrap

Controller 节点部署后的过程包括 6 个主要的部署步骤。它包括：

Expand
表 10.1. Controller 节点配置步骤

步骤

描述

ControllerLoadBalancerDeployment_Step1

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

ControllerServicesBaseDeployment_Step2

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

ControllerRingbuilderDeployment_Step3

OpenStack Object Storage (swift) 的初始 ring 构建。

ControllerOvercloudServicesDeployment_Step4

配置所有的 OpenStack Platform 服务（nova、neutron、cinder、sahara、ceilometer、heat、horizon、aodh、gnocchi）。

ControllerOvercloudServicesDeployment_Step5

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

ControllerOvercloudServicesDeployment_Step6

Overcloud 的最终配置。

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

在 Undercloud 主机上执行以下步骤：

安装 nmap: 

# yum install nmap
Copy to Clipboard Toggle word wrap

使用 nmap 命令扫描活跃的 IP 地址范围。这个示例会扫描 192.0.2.0/24 这个范围，使用 Provisioning 网络的 IP 子网值（CIDR 格式）替换它： 

# nmap -sn 192.0.2.0/24
Copy to Clipboard Toggle word wrap

检查 nmap 扫描的结果输出：

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

# nmap -sn 192.0.2.0/24

Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
Nmap scan report for 192.0.2.1
Host is up (0.00057s latency).
Nmap scan report for 192.0.2.2
Host is up (0.00048s latency).
Nmap scan report for 192.0.2.3
Host is up (0.00045s latency).
Nmap scan report for 192.0.2.5
Host is up (0.00040s latency).
Nmap scan report for 192.0.2.9
Host is up (0.00019s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds
Copy to Clipboard Toggle word wrap

10.5. 对 "No Valid Host Found" 错误进行故障排除
复制链接

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

NoValidHost: No valid host was found. There are not enough hosts available.
Copy to Clipboard Toggle word wrap

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

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

    $ ironic node-show [NODE UUID]
    Copy to Clipboard Toggle word wrap

    检查 properties JSON 项中的 cpus、cpu_arch、memory_mb 和 local_gb 都有有效的值。

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

    $ nova flavor-show [FLAVOR NAME]
    Copy to Clipboard Toggle word wrap
  3. 根据 ironic node-list 检查有足够状态为 available 的节点。节点的状态为 manageable 通常意味着內省操作失败。

  4. 使用 ironic node-list 检查没有处于维护模式的节点。当一个节点被自动变为维护模式时，通常意味着不正确的电源管理凭证。检查它们并删除维护模式： 

    $ ironic node-set-maintenance [NODE UUID] off
    Copy to Clipboard Toggle word wrap
  5. 如果您使用 AHC 工具程序来自动标记节点，请根据每个 flavor 和配置集来检查是否有足够的相关节点。检查 ironic node-show 输出中的 properties 项的 capabilities 值。例如，一个标记为 Compute 角色的节点应该包括 profile:compute。

  6. 在进行完內省操作后，从 ironic 为 nova 生成节点信息可能会需要一些时间来完成。director 的工具程序通常会把这个时间考虑进去。但是，如果您手工进行了一些操作，节点可能会在一个短时间内对 nova 无效。使用以下命令检查系统中的总资源： 

    $ nova hypervisor-stats
    Copy to Clipboard Toggle word wrap

10.6. 在创建后对 Overcloud 进行故障排除
复制链接

在创建完 Overcloud 后，可能还会需要在以后执行特定的 Overcloud 操作。例如，可能会需要扩展可用节点，或替换出现故障的节点。在执行这些操作时，可能会出现某些问题。本节介绍了对这些可能出现的问题进行故障排除的方法。

10.6.1. Overcloud 栈的修改
复制链接

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

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

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

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

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

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

10.6.2. Controller 服务失败
复制链接

Overcloud Controller 节点包括大量 Red Hat OpenStack Platform 服务，您也可能在一个高可用性的集群中使用多个 Controller 节点。如果一个节点上的特定服务出现问题，高可用性集群会提供一定程度的故障转移功能。但是，您需要对出现问题的节点进行故障诊断，以便 Overcloud 可以以最大能力运行。

在高可用性集群中，Controller 节点使用 Pacemaker 管理资源和服务。Pacemaker Configuration System（pcs）是一个用来管理 Pacemaker 集群的工具程序。在集群的 Controller 节点上运行这个命令来执行配置和监控操作。在一个高可用性集群中，可以使用以下命令帮助对 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/ 中查看相关的组件日志文件。

10.6.3. Compute 服务失败
复制链接

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

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

    $ sudo systemctl status openstack-nova-compute.service
    Copy to Clipboard Toggle word wrap

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

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

10.6.4. Ceph Storage 服务故障
复制链接

如果 Red Hat Ceph Storage 集群出现故障，参阅 Red Hat Ceph Storage Configuration Guide 中的 Part 10. Logging and Debugging。

10.7. 对 Undercloud 进行性能微调
复制链接

本节中提供的建议针对于提高 Undercloud 的性能。您可以根据自己的需要实施相关的建议。

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

    0 04 * * * /bin/keystone-manage token_flush
    Copy to Clipboard Toggle word wrap

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

    0 04 * * * /bin/heat-manage purge_deleted -g days 1
    Copy to Clipboard Toggle word wrap

  • 在一些时候，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
    Copy to Clipboard Toggle word wrap

  • 在一些时候，director 可能没有足够的资源来执行并行的节点设置（默认是可以同时并行设置 10 个节点）。为了减少并行节点的数量，把 /etc/nova/nova.conf 中的 max_concurrent_builds 参数设置为一个小于 10 的值，然后重启 nova 服务： 

    $ sudo systemctl restart openstack-nova-api openstack-nova-scheduler
    Copy to Clipboard Toggle word wrap

  • 编辑 /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
    Copy to Clipboard Toggle word wrap

10.8. Undercloud 和 Overcloud 的重要日志
复制链接

在出现问题时，使用以下日志查找 Undercloud 和 Overcloud 的信息。

Expand
表 10.2. Undercloud 和 Overcloud 的重要日志

信息

Undercloud 或 Overcloud

日志位置

一般的 director 服务

Undercloud

/var/log/nova/*

/var/log/heat/*

/var/log/ironic/*

内省（Introspection）

Undercloud

/var/log/ironic/*

/var/log/ironic-inspector/*

Provisioning

Undercloud

/var/log/ironic/*

Cloud-Init 日志

Overcloud

/var/log/cloud-init.log

Overcloud 配置（最后一次 Puppet 运行的概述）

Overcloud

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

Overcloud 配置（最后一次 Puppet 运行的报告）

Overcloud

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

Overcloud 配置（所有 Puppet 报告）

Overcloud

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

一般的 Overcloud 服务

Overcloud

/var/log/ceilometer/*

/var/log/ceph/*

/var/log/cinder/*

/var/log/glance/*

/var/log/heat/*

/var/log/horizon/*

/var/log/httpd/*

/var/log/keystone/*

/var/log/libvirt/*

/var/log/neutron/*

/var/log/nova/*

/var/log/openvswitch/*

/var/log/rabbitmq/*

/var/log/redis/*

/var/log/swift/*

高可用性日志

Overcloud

/var/log/pacemaker.log

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat