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-api
和openstack-ironic-conductor
。同样的,ironic-inspector
也使用两个单元:openstack-ironic-inspector
和openstack-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 的值是
error
或deploy 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 节点配置步骤
步骤 |
描述 |
|
初始负载均衡软件配置,包括 Pacemaker、RabbitMQ、Memcached、Redis 和 Galera。 |
|
初始集群配置,包括 Pacemaker 配置、HAProxy、MongoDB、Galera、Ceph Monitor,以及 OpenStack Platform 服务的数据库初始化。 |
|
初始构建 OpenStack 对象存储 ( |
|
在 Pacemaker 中配置服务启动设置,包括决定服务启动顺序的限制,以及服务启动的参数。 |
|
初始配置 OpenStack Identity ( |
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 的资源不匹配。检查以下内容:
确保內省可以成功完成。否则,检查每个节点都包括了需要的 ironic 节点属性。对于每个节点:
$ ironic node-show [NODE UUID]
检查
properties
JSON 项中的cpus
、cpu_arch
、memory_mb
和local_gb
都有有效的值。根据 ironic 节点属性检查使用的 nova flavor 没有超过特定数量:
$ nova flavor-show [FLAVOR NAME]
-
根据
ironic node-list
检查有足够状态为available
的节点。节点的状态为manageable
通常意味着內省操作失败。 使用
ironic node-list
检查没有处于维护模式的节点。当一个节点被自动变为维护模式时,通常意味着不正确的电源管理凭证。检查它们并删除维护模式:$ ironic node-set-maintenance [NODE UUID] off
-
如果您使用 AHC 工具程序来自动标记节点,请根据每个 flavor 和配置集来检查是否有足够的相关节点。检查
ironic node-show
输出中的properties
项的capabilities
值。例如,一个标记为 Compute 角色的节点应该包括profile:compute
。 在进行完內省操作后,从 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-engine
和openstack-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 日志 |
|
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 交互 |
|
表 11.3. overcloud 的重要日志
信息 | 日志位置 |
---|---|
Cloud-Init 日志 |
|
overcloud 配置(最后一次 Puppet 运行的概述) |
|
overcloud 配置(最后一次 Puppet 运行的报告) |
|
overcloud 配置(所有 Puppet 报告) |
|
overcloud 配置(来自每一次 Puppet 运行的 stdout) |
|
overcloud 配置(来自每一次 Puppet 运行的 stderr) |
|
高可用性日志 |
|