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

大型部署的建议

Red Hat OpenStack Platform 16.2

大规模部署 Red Hat OpenStack Platform 的硬件要求和配置

OpenStack Documentation Team

摘要

本指南包含大规模部署 Red Hat OpenStack Platform 的几个建议。这些建议包括硬件建议、undercloud 调整和 overcloud 配置。

对红帽文档提供反馈
复制链接

我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。

在 JIRA 中提供文档反馈

使用 Create Issue 表单对文档提供反馈。JIRA 问题将在 Red Hat OpenStack Platform Jira 项目中创建，您可以在其中跟踪您的反馈进度。

  1. 确保您已登录到 JIRA。如果您没有 JIRA 帐户，请创建一个帐户来提交反馈。
  2. 点击以下链接打开 Create Issue 页面： Create Issue
  3. 完成 Summary 和 Description 字段。在 Description 字段中，包含文档 URL、章节或章节号以及问题的详细描述。不要修改表单中的任何其他字段。
  4. 点 Create。

第 1 章 大型部署的建议
复制链接

使用以下 undercloud 和 overcloud 建议、规格和配置来部署大型 Red Hat OpenStack Platform (RHOSP)环境。包括 100 个 overcloud 节点的 RHOSP 16.2 部署被视为大型环境。红帽已使用 RHOSP 16.2 在大规模 700 overcloud 节点上测试并验证了最佳性能，而无需使用 minion。

对于基于 DCN 的部署，来自中央和边缘站点的节点数量可能非常高。有关 DCN 部署的建议，请联系红帽支持服务。

第 3 章 Red Hat OpenStack 部署最佳实践
复制链接

在规划和准备部署 OpenStack 时，请考虑以下最佳实践。您可以在自己的环境中应用这些实践中的一个或多个。

3.1. Red Hat OpenStack 部署准备
复制链接

在部署 Red Hat OpenStack Platform (RHOSP)前，请查看以下部署准备任务列表。您可以在环境中应用一个或多个部署准备任务：

为内省设置子网范围，以适应您要一次执行内省的最大 overcloud 节点
当使用 director 部署和配置 RHOSP 时，使用 control plane 网络的 CIDR 标记来容纳您现在或未来添加的所有 overcloud 节点。
在 overcloud 镜像上设置 root 密码，以允许控制台访问 overcloud 镜像

在网络设置错误时，使用控制台对失败的部署进行故障排除。如需更多信息，请参阅 合作伙伴集成指南中的 将 virt-customize 安装到 director 和设置 Root 密码。在实施此建议时，遵循您所在机构的信息安全策略进行密码管理。

另外，您可以使用 userdata_root_password.yaml 模板来使用 NodeUserData 参数配置 root 密码。您可以在 /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml 中找到模板。

以下示例使用模板来配置 NodeUserData 参数： 

resource_registry:
  OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml
parameter_defaults:
  NodeRootPassword: '<password>'
Copy to Clipboard Toggle word wrap
使用调度程序提示将硬件分配给角色
  • 使用调度程序提示将硬件分配到角色，如 Controller、Compute、CephStorage 等。调度程序提示提供了更容易地识别影响特定硬件的部署问题。
  • 使用调度程序提示时不要使用配置集标记。
  • 在性能测试中，为特定角色使用相同的硬件，以减少测试和性能结果的差异。
  • 有关更多信息，请参阅高级 Overcloud 自定义指南中的分配特定节点 ID。
将 World Wide Name (WWN)设置为每个节点的根磁盘提示，以防止节点在部署和引导过程中使用错误的磁盘
当节点包含多个磁盘时，使用内省数据将 WWN 设置为每个节点的根磁盘提示。这可防止节点在部署和引导过程中使用错误的磁盘。如需更多信息，请参阅 Director 安装和使用指南中的 为多磁盘集群定义根磁盘。
在有多个磁盘的节点上启用 Bare Metal 服务(ironic)自动清理

使用 Bare Metal 服务自动清理，在有多个磁盘的节点上清除元数据，并可能有多个引导装载程序。由于磁盘上存在多个引导装载程序，节点可能会与引导磁盘不一致，这会导致在尝试拉取使用错误 URL 的元数据时造成节点部署失败。

要在 undercloud 节点上启用 Bare Metal 服务自动清理，请编辑 undercloud.conf 文件并添加以下行： 

clean_nodes = true
Copy to Clipboard Toggle word wrap
限制裸机(ironic)内省的节点数量

如果您同时在所有节点上执行内省，则可能会因为网络约束导致失败。一次在最多 50 个节点上执行内省。

确保 undercloud.conf 文件中的 dhcp_start 和 dhcp_end 范围足够大，供您期望在环境中具有的节点数量。

如果可用 IP 不足，请不要超过范围的大小。这限制了同时内省操作的数量。要允许内省 DHCP 租期到期，请不要在内省完成后几分钟内发布更多 IP 地址。

为 Ceph 准备不同类型的配置

以下列表是不同类型的配置的一组建议：

  • all-flash OSD 配置

    每个 OSD 根据设备类型的 IOPS 容量需要额外的 CPU，因此 Ceph IOPS 限制为较低数量的 OSD。对于 NVM SSD，这是 true，它比传统的 HDD 有两个顺序的 IOPS 容量。对于 SATA/SAS SSD，预期一个顺序的 magnitude 大于 HDD，但只有两个到连续 IOPS 增加的四倍。对于 OSD 设备，您可以提供比 Ceph 要求少的 CPU 资源。

  • Hyper Converged Infrastructure (HCI)

    建议为 OpenStack Compute (nova)客户机至少保留一半的 CPU 容量、内存和网络。确保有足够的 CPU 容量和内存来支持 OpenStack Compute (nova)客户机和 Ceph 存储。观察内存消耗，因为 Ceph Storage 内存消耗没有弹性。在多 CPU 套接字系统上，将 NUMA 功能 Ceph 的 Ceph CPU 消耗限制为单个套接字。例如，使用 numactl -N 0 -p 0 命令。不要将 Ceph 内存消耗硬编码为 1 个插槽。

  • 对延迟敏感的应用程序，如 NFV

    将 Ceph 放置到与 Ceph 使用和限制 CPU 套接字相同的 CPU 套接字上（如果可能），将网卡中断到该 CPU 套接字，并在不同的 NUMA 套接字和网卡上运行的网络应用。

    如果使用双引导装载程序，请为 OSD map 使用 disk-by-path。这为用户提供一致的部署，这与使用设备名称不同。以下片段是用于 disk-by-path 映射的 CephAnsibleDisksConfig 示例。 

    CephAnsibleDisksConfig:
  osd_scenario: non-collocated
  devices:
    - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:0:0
    - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:1:0
  dedicated_devices:
    - /dev/nvme0n1
    - /dev/nvme0n1
  journal_size: 512
    Copy to Clipboard Toggle word wrap

3.2. Red Hat OpenStack 部署配置
复制链接

查看以下 Red Hat OpenStack Platform (RHOSP)部署配置的建议列表：

使用较小的部署验证 heat 模板
部署由至少三个 Controller、一个计算备注和三个 Ceph Storage 节点组成的小型环境。您可以使用此配置来确保所有 heat 模板都正确。
禁用 undercloud 上的遥测通知

您可以在 undercloud 上禁用遥测通知，以便以下 OpenStack 服务减少 RabbitMQ 队列：

  • Compute (nova)
  • Networking (neutron)
  • Orchestration (heat)
  • 身份(keystone)

要禁用通知，在 /usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml 模板中，将通知驱动程序设置为 noop。

限制同时置备的节点数

fifty 是可在平均企业级机架单元内的典型服务器数量，因此您可以一次部署一个机架的节点。

要最小化诊断部署问题所需的调试，请一次部署超过 50 个节点。但是，如果您想要部署更多节点，红帽已成功测试最多 100 个节点。

要批量扩展 Compute 节点，请使用 openstack overcloud deploy 命令和 --limit 选项。这可能会导致 undercloud 上花费的时间和较低的资源消耗。

注意

--limit 选项只是一个技术预览。

将此选项与 config-download playbook 中的以逗号分隔的标签列表一起使用，以使用特定的 config-download 任务运行部署。

禁用未使用的 NIC

如果 overcloud 在部署期间有任何未使用的 NIC，您必须在 NIC 配置模板中定义未使用的接口，并将接口设置为 use_dhcp: false 和 defroute: false。

如果您没有定义未使用的接口，在内省和扩展操作过程中可能会出现路由问题和 IP 分配问题。默认情况下，NIC 设置 BOOTPROTO=dhcp，这意味着未使用的 overcloud NIC 使用 PXE 置备所需的 IP 地址。这可减少节点的可用 IP 地址池。

关闭未使用的裸机置备(ironic)节点
确保您以维护模式关闭任何未使用的裸机置备(ironic)节点。红帽已找出，之前部署的节点处于维护模式，处于开机状态。在裸机自动清理中可能会发生这种情况，其中清理的节点被设置为维护模式。裸机置备不会跟踪处于维护模式的节点的电源状态，并错误地报告电源状态为 off。这可能导致持续部署出现问题。当您在部署后重新部署时，请确保关闭使用节点的电源管理设备的所有未使用的节点。

3.3. 调整 undercloud
复制链接

计划扩展 RHOSP 部署并对默认 undercloud 设置应用调整时，请查看本节。

如果使用 Telemetry 服务(ceilometer)，请提高服务的性能

因为 Telemetry 服务是 CPU 密集型的，所以 RHOSP 16.2 中不默认启用遥测。如果要使用 Telemetry，您可以提高服务的性能。

如需更多信息，请参阅 Deployment Recommendations for Specific Red Hat OpenStack Platform Services Guide 中的 Configuration recommendations for the Telemetry service i部分。

分隔置备和配置过程
  • 要只创建堆栈和相关 RHOSP 资源，您可以使用 --stack-only 选项运行部署命令。
  • 红帽建议在部署超过 100 个节点时分离 stack 和 config-download 步骤。

包括 overcloud 所需的任何环境文件： 

$ openstack overcloud deploy \
  --templates \
  -e <environment-file1.yaml> \
  -e <environment-file2.yaml> \
  ...
  --stack-only
Copy to Clipboard Toggle word wrap

  • 置备堆栈后，您可以启用从 undercloud 到 overcloud 的 tripleo-admin 用户的 SSH 访问。config-download 进程使用 tripleo-admin 用户来执行基于 Ansible 的配置： 

    $ openstack overcloud admin authorize
    Copy to Clipboard Toggle word wrap

  • 要禁用 overcloud 堆栈创建并仅运行 config-download 工作流以应用软件配置，您可以使用 --config-download-only 选项运行部署命令。包括 overcloud 所需的任何环境文件： 

    $ openstack overcloud deploy \
 --templates \
 -e <environment-file1.yaml> \
 -e <environment-file2.yaml> \
  ...
 --config-download-only
    Copy to Clipboard Toggle word wrap
  • 要将 config-download playbook 执行限制为特定节点或一组节点，您可以使用 --limit 选项。

  • --limit 选项可用于将节点划分为不同的角色，以限制要部署的节点数，或使用特定硬件类型分隔节点。对于扩展操作，当只想在新节点上应用软件配置时，请使用 --limit 选项和 --config-download-only 选项。 

    $ openstack overcloud deploy \
--templates \
-e <environment-file1.yaml> \
-e <environment-file2.yaml> \
...
--config-download-only --config-download-timeout --limit <Undercloud>,<Controller>,<Compute-1>,<Compute-2>
    Copy to Clipboard Toggle word wrap

    如果使用 --limit 选项，则始终在列表中包括 &lt ;Controller&gt; 和 <Undercloud >。只有在选项列表中包含 < Undercloud > 时，使用 external_deploy_steps 接口（如所有 Ceph 配置）的任务才会被执行。所有 external_deploy_steps 任务都在 undercloud 上运行。

    例如，如果您运行一个扩展任务来添加需要连接到 Ceph 的计算节点，且您在列表中不包含 &lt ;Undercloud >，则缺少 Ceph 配置和 cephx 密钥文件，任务会失败。不要使用 --skip-tags external_deploy_steps 选项，否则任务会失败。

3.4. 调整 overcloud
复制链接

在计划扩展 Red Hat OpenStack Platform (RHOSP)部署并对默认 overcloud 设置应用调整时，请查看以下部分：

增加 OVN OVSDB 客户端探测间隔以防止故障转移

为大型 RHOSP 部署增加 OVSDB 客户端探测间隔。当 Pacemaker 在配置的超时内没有从 OVN 获得响应时，Pacemaker 会触发 ovn-dbs-bundle 的故障切换。要将 OVN OVSDB 客户端探测间隔增加到 360 秒，请编辑 heat 模板中的 OVNDBSPacemakerTimeout 参数： 

OVNDBSPacemakerTimeout: 360
Copy to Clipboard Toggle word wrap

在每个 Compute 和 Controller 节点上，OVN 控制器定期探测 OVN SBDB，如果这些请求超时，OVN 控制器会重新同步。当使用创建资源的请求时加载多个 Compute 和 Controller 节点时，默认的 60 秒超时值不足。要将 OVN SBDB 客户端探测间隔增加到 180 秒，请编辑 heat 模板中的 OVNOpenflowProbeInterval 参数： 

ControllerParameters:
  OVNRemoteProbeInterval: 180000
  OVNOpenflowProbeInterval: 180
Copy to Clipboard Toggle word wrap
注意

在 RHOSP 用户和服务触发的操作过程中，因为资源限制（如 CPU 或内存资源限制），多个组件可能会达到配置的超时值。这可能会导致对 haproxy 前端或后端、消息传递超时、db 查询相关的故障、集群不稳定等的超时请求失败。在初始部署后对 overcloud 环境进行基准测试，以帮助识别与超时相关的瓶颈。

在实例网络信息缓存更新之间设置高间隔

实例网络信息缓存更新之间的默认间隔为 60 秒： heal_instance_info_cache_interval = 60。为确保系统可以管理实例缓存修复在 neutron 服务器上的负载，请修改环境的 heal_instance_info_cache_interval 参数的值。例如：

  • 对于每十分钟，设置 heal_instance_info_cache_interval = 600。
  • 对于每小时，设置 heal_instance_info_cache_interval = 3600。
警告

有些第三方插件会在负载过重时返回不一致的 API 数据库响应。ML2/OVS 和 ML2/OVN 后端不会遇到不一致的 API 数据库响应问题。如果您的部署使用 ML2/OVS 或 ML2/OVN，您可以通过将值设为 -1 来禁用 heal_instance_info_cache_interval 参数。

有关参数的更多信息，请参阅配置 参考指南 中的 nova。

第 4 章 调试建议和已知问题
复制链接

查看以下部分以了解可帮助您对部署进行故障排除的建议。

4.1. 已知问题
复制链接

以下列表概述了现有的限制。

BZ1141857451 - Ansible fork 值应具有上限，并需要更改 Current Calculation
默认情况下，mistral 中的 Ansible playbook 配置为在 ansible.cfg 文件中使用 1039） CPU_COUNT fork。如果不使用 --limit 选项将 Ansible 执行限制到特定节点或一组节点，并将 Ansible 执行设置为在所有现有节点上运行，Ansible 几乎消耗了 100% 内存利用率。

4.2. 内省调试
复制链接

在调试内省时，请查看以下建议列表。

在 undercloud.conf 文件中检查您的内省 DHCP 范围和 NIC
如果有任何这些值不正确，请修复它们，然后重新运行 openstack undercloud install 命令。
确保您不会尝试内省超过 DHCP 范围的节点范围
每个节点的 DHCP 租期在内省完成后持续活跃大约两分钟。
确保目标节点响应
如果所有节点都内省失败，请确保可以使用配置的 NIC 和带外接口凭证和地址通过原生 VLAN ping 目标节点。
在控制台中检查内省命令
要调试特定节点，请在节点引导时监控控制台，并观察节点的内省命令。如果节点在完成 PXE 过程前停止，请检查连接、IP 分配和网络负载。当节点退出 BIOS 并引导内省镜像时，故障很少且与连接问题几乎相关。确保内省镜像中的心跳不会因 undercloud 中断。

4.3. 部署调试
复制链接

在调试部署时使用以下建议。

检查在 provisioning 网络中提供地址的 DHCP 服务器

在置备网络上提供地址的任何其他 DHCP 服务器都可能会阻止 Red Hat OpenStack Platform director 检查和置备机器。

  • 对于 DHCP 或 PXE 内省问题，请输入以下命令： 

    $ sudo tcpdump -i any port 67 or port 68 or port 69
    Copy to Clipboard Toggle word wrap

  • 对于 DHCP 或 PXE 部署问题，请输入以下命令： 

    $ sudo ip netns exec qdhcp tcpdump -i <interface> port 67 or port 68 or port 69
    Copy to Clipboard Toggle word wrap
检查失败或外磁盘的状态
对于失败或外磁盘，请检查磁盘的状态以确保根据机器的带外管理，失败或外磁盘的状态被设置为 Up。磁盘可以在部署周期期间退出 Up 状态，并更改磁盘在基础操作系统中显示的顺序。
使用以下命令调试失败的 overcloud 部署
  • OpenStack 堆栈失败列表 overcloud
  • heat resource-list -n5 overcloud | grep -i fail
  • less /var/lib/mistral/config-download-latest/ansible.log

要查看命令的输出，请登录发生故障的节点，并查看 /var/log/ 和 /var/log/containers/ 中的日志文件。

法律通告
复制链接

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat