Red Hat Training

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

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

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

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

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

找到分配的端口 UUID:

$ source ~/stackrc
(undercloud) $ openstack baremetal port list --node [NODE UUID]

更新 MAC 地址:

(undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT 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
(undercloud) $ openstack baremetal node manage [NODE UUID]

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

(undercloud) $ openstack baremetal node provide [NODE UUID]

停止发现过程

停止内省过程:

$ source ~/stackrc
(undercloud) $ openstack baremetal introspection abort [NODE UUID]

您也可以等待操作过程超时。如有必要,将 /etc/ironic-inspector/inspector.conf 中的 timeout 设置更改为另一个时长(以分钟为单位)。

访问内省的 Ramdisk

内省虚拟内存盘使用动态登录功能。这意味着在内省调试过程中,可以提供临时密码或 SSH 密钥来访问节点。按以下流程设置虚拟内存盘访问方式:

  1. openssl passwd -1 命令提供临时密码来生成 MD5 哈希。例如:

    $ openssl passwd -1 mytestpassword
    $1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/
  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/" selinux=0

    或者,也可以附加 sshkey 参数和您的 SSH 公钥。

    注意

    rootpwdsshkey 参数都需要加上引号。

  3. 启动内省并通过 arp 命令或 DHCP 日志找到 IP 地址:

    $ arp
    $ sudo journalctl -u openstack-ironic-inspector-dnsmasq
  4. 作为根用户,使用临时密码或 SSH 密钥进行 SSH 连接。

    $ ssh root@192.168.24.105

检查内省存储

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

$ 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

第二个工作流启动 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 的工作流执行记录:

$ 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

通过这些可了解执行中失败的任务的相关信息。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 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 栈:

$ source ~/stackrc
(undercloud) $ openstack stack list --nested --property status=FAILED
+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+

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

13.4.2. 裸机部署

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

$ source ~/stackrc
(undercloud) $ openstack baremetal 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,则意味着对这个节点的裸机部署失败。检查裸机节点的详情:

    (undercloud) $ openstack baremetal node show [NODE UUID]

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

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

13.4.3. 实施后的配置

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

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

$ source ~/stackrc
(undercloud) $ openstack stack resource list overcloud --filter status=FAILED

这会显示所有出问题的资源的列表。

显示出问题的资源:

(undercloud) $ openstack stack resource show overcloud [FAILED RESOURCE]

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

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

(undercloud) $ openstack server list

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

(undercloud) $ ssh heat-admin@192.168.24.14

检查 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]

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

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

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

表 13.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) 中的项目、角色和用户。

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

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

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

安装 nmap:

$ sudo yum install nmap

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

$ sudo nmap -sn 192.168.24.0/24

检查 nmap 扫描的结果输出:

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

$ sudo 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

13.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 节点属性。对于每个节点:

    $ source ~/stackrc
    (undercloud) $ openstack baremetal node show [NODE UUID]

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

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

    (undercloud) $ openstack flavor show [FLAVOR NAME]
  3. 根据 openstack baremetal node list 检查是否有足够的节点处于 available 状态。节点处于 manageable 状态通常表示内省失败。
  4. 使用 openstack baremetal node list 检查没有处于维护模式的节点。当一个节点自动变为维护模式时,通常意味着电源凭证不正确。检查凭证并取消维护模式:

    (undercloud) $ openstack baremetal node maintenance unset [NODE UUID]
  5. 如果您使用自动健康状态检查 (AHC) 工具来自动标记节点,请检查是否有足够的节点对应于每种类型/配置文件。检查 openstack baremetal node showproperties 字段中的 capabilities 键值。例如,标记为 Compute 角色的节点应包含 profile:compute 这样的信息。
  6. 內省操作后,从 ironic 向 nova 传递节点信息可能需要一些时间。director 的工具通常会把这个时间考虑进去。但是,如果您手工进行了一些操作,节点可能会短时间内对 nova 不可用。使用以下命令检查系统中的总体资源:

    (undercloud) $ openstack hypervisor stats show

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

在大多数情况下,该日志可指明容器出现故障的原因。

检查容器

在某些情况下,您可能需要验证容器的相关信息。例如,请使用以下命令来查看 keystone 容器的相关数据:

$ sudo docker inspect keystone

这会提供一个包含低级别配置数据的 JSON 对象。您可以通过管道将这些输出内容传递给 jq 命令,以对特定数据进行解析。例如,要查看 keystone 容器的加载情况,请运行以下命令:

$ 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
注意

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

在容器中运行命令

在某些情况下,您可能需要通过特定的 Bash 命令从容器中获取信息。此时,请使用以下 docker 命令,以便在正在运行的容器中执行相关命令。例如,要在 keystone 容器中运行某个命令,请使用以下命令:

$ sudo docker exec -ti keystone <COMMAND>
注意

-ti 选项会通过交互式伪终端来运行命令。

请将 <COMMAND> 替换成您所需的命令。例如,每个容器都有一个健康检查脚本,用于验证服务的连接状况。您可以使用以下命令为 keystone 运行这个健康检查脚本:

$ sudo docker exec -ti keystone /openstack/healthcheck

要访问容器的 shell,请使用 /bin/bash 运行 docker exec(如以下命令所示):

$ sudo docker exec -ti keystone /bin/bash

导出容器

当容器出现故障时,您可能需要调查文件中包含的所有内容。在这种情况下,您可以将容器的整个文件系统导出为 tar 归档。例如,要导出 keystone 容器的文件系统,请运行以下命令:

$ sudo docker export keystone -o keystone.tar

这个命令会创建 keystone.tar 归档,以供您提取和研究。

13.7.4. Compute 服务失败

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

  • 查看容器状态:

    $ sudo docker ps -f name=nova_compute
  • 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
  • 在一些时候,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

13.9. 创建 sosreport

如果您需要与红帽联系获得 OpenStack Platform 的产品支持,可能需要生成一份 sosreport。如需了解有关如何创建 sosreport 的更多信息,请参阅以下知识库文章:

13.10. undercloud 和 overcloud 的重要日志

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

表 13.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

表 13.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