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

第 2 章 架构

director 使用原生 OpenStack API 来配置、部署和管理 OpenStack 环境本身。这意味着与 director 集成需要与这些原生 OpenStack API 集成和支持组件。使用此类 API 的主要优点是，它们被精心记录，在上游进行广泛的集成测试，并了解 director 如何更容易了解 OpenStack 的基本知识。这也意味着 director 会自动继承核心 OpenStack 功能增强、安全补丁和程序错误修复。

Red Hat OpenStack Platform director 是一个安装和管理完整的 OpenStack 环境的工具组，它主要基于 OpenStack 项目 - TripleO（"OpenStack-On-OpenStack" 的缩写）。它主要基于 OpenStack 项目 TripleO，这是"OpenStack-On-OpenStack"的缩写。此项目利用 OpenStack 组件来安装可全面运行的 OpenStack 环境。这包括用于置备和控制裸机系统的新 OpenStack 组件，以用作 OpenStack 节点。这为安装精益可靠的完整 Red Hat OpenStack Platform 环境提供了一种简单方法。

Red Hat OpenStack Platform director 使用两个主要概念：Undercloud 和 Overcloud。此 director 本身由组成单系统 OpenStack 环境（也称为 Undercloud）的 OpenStack 组件组成。Undercloud 充当管理系统，可为工作负载运行创建生产级云。此生产级云是 Overcloud。有关 Overcloud 和 Undercloud 的更多信息，请参阅 Director 安装和使用指南。

director 附带用于创建 Overcloud 配置的工具、实用程序和示例模板。director 会捕获配置数据、参数和网络拓扑信息，然后将此信息与 Ironic、Heat 和 Puppet 等组件一起使用，以编配 Overcloud 安装。

合作伙伴具有各种要求。了解 director 的架构有助于了解哪些组件对于给定的集成工作至关重要。

2.1. 核心组件
复制链接

本节阐述 Red Hat OpenStack Platform director 的一些核心组件，并描述它们如何对 Overcloud 创建贡献。

2.1.1. ironic
复制链接

Ironic 通过自助服务配置向最终用户提供专用的裸机主机。director 使用 Ironic 管理 Overcloud 中裸机硬件的生命周期。Ironic 具有自己的原生 API，用于定义裸机节点。管理员希望通过 director 调配 OpenStack 环境，必须使用特定的驱动程序通过 Ironic 注册其节点。主要支持的驱动程序是智能平台管理接口(IPMI)，因为大多数硬件包含对 IPMI 电源管理功能的一些支持。但是，ironic 还包含特定于厂商的等效项，如 HP iLO、Cisco UCS 或 Dell DRAC。Ironic 控制节点的电源管理，并使用发现机制收集硬件信息或 事实。director 使用从发现过程获取的信息，将节点与各种 OpenStack 环境角色（如 Controller 节点、计算节点和存储节点）匹配。例如，带有 10-disks 的发现节点可能会置备为存储节点。

希望获得硬件的 director 支持的合作伙伴需要在 Ironic 中具有驱动程序覆盖。

2.1.2. heat
复制链接

Heat 充当应用堆栈编排引擎。这允许组织在部署到云之前为给定应用程序定义元素。这包括创建堆栈模板，其中包含多个基础架构资源（如实例、网络、存储卷、弹性 IP 等）以及一组用于配置的参数。Heat 根据给定的依赖关系链创建这些资源，将它们监控以实现可用性，并在需要时对它们进行扩展。这些模板使应用程序堆栈变得可移植，并实现预期结果的可重复性。

director 使用原生 OpenStack Heat API 来调配和管理与部署 Overcloud 关联的资源。这包括精确的详细信息，如定义每个节点角色要调配的节点数量、要为每个节点配置的软件组件，以及 director 配置这些组件和节点类型的顺序。director 还使用 Heat 对部署进行故障排除，并便于部署后进行更改。

以下示例是 Heat 模板的片段，用于定义 Controller 节点的参数： 

NeutronExternalNetworkBridge:
    description: Name of bridge used for external network traffic.
    type: string
    default: 'br-ex'
NeutronBridgeMappings:
    description: >
      The OVS logical->physical bridge mappings to use. See the Neutron
      documentation for details. Defaults to mapping br-ex - the external
      bridge on hosts - to a physical name 'datacentre' which can be used
      to create provider networks (and we use this for the default floating
      network) - if changing this either use different post-install network
      scripts or be sure to keep 'datacentre' as a mapping network name.
    type: string
    default: "datacentre:br-ex"
Copy to Clipboard Toggle word wrap

Heat 使用 director 附带的模板来协助创建 Overcloud，其中包括调用 Ironic 来打开节点电源。我们可以使用标准的 Heat 工具查看 overcloud 中正在进行的 Overcloud 的资源（及其状态）。例如，您可以使用 Heat 工具将 Overcloud 显示为嵌套应用堆栈。

Heat 为声明和创建生产 OpenStack 云提供了全面、强大的语法。但是，它需要了解和理解合作伙伴集成。每个合作伙伴集成用例都需要 Heat 模板。

2.1.3. puppet
复制链接

Puppet 是一种配置管理和实施工具。它用作描述计算机最终状态并保持其方式的机制。您可以在 Puppet 清单中定义此最终状态。Puppet 支持两种模型：

  • 在本地运行清单形式的独立模式
  • 服务器模式，从称为 Puppet Master 的中央服务器检索其清单。

管理员以两种方式进行更改：将新清单上传到节点并在本地执行它们，或者在客户端/服务器模型中进行修改。

在 director 的许多方面，我们使用 Puppet：

  • 我们在本地使用 Undercloud 主机上的 Puppet 来根据 undercloud.conf 中的配置布局安装和配置软件包。
  • 我们会将 openstack-puppet-modules 软件包注入到基础 Overcloud 镜像中。这些 Puppet 模块已准备好进行部署后配置。默认情况下，我们创建一个包含所有 OpenStack 服务的镜像，并将其用于每个节点。
  • 我们通过 Heat 向节点提供额外的 Puppet 清单和参数，并在 Overcloud 部署后应用配置。这包括要启用并启动的服务，以及要应用的 OpenStack 配置，这取决于节点类型。

  • 我们向节点提供 Puppet hieradata。Puppet 模块和清单可从站点或特定于节点的参数中自由，以便使清单保持一致。hieradata 充当参数化值的形式，您可以推送到 Puppet 模块并在其他区域中引用。例如，若要在清单内引用 MySQL 密码，请将此信息保存为 hieradata，并在清单中引用它。

    查看 hieradata: 

    [root@localhost ~]# grep mysql_root_password hieradata.yaml # View the data in the hieradata file
openstack::controller::mysql_root_password: ‘redhat123'
    Copy to Clipboard Toggle word wrap

    在 Puppet 清单中引用它： 

    [root@localhost ~]# grep mysql_root_password example.pp # Now referenced in the Puppet manifest
mysql_root_password  => hiera(‘openstack::controller::mysql_root_password')
    Copy to Clipboard Toggle word wrap

需要软件包安装和服务启用的合作伙伴集成服务应考虑创建 Puppet 模块以满足其要求。例如，有关如何获取当前 Openstack Puppet 模块的信息，请参阅 第 4.2 节 “获取 OpenStack Puppet 模块”。

2.1.4. tripleo 和 TripleO Heat 模板
复制链接

如前文所述，director 基于上游 TripleO 项目。此项目组合了一组 OpenStack 服务：

  • 存储 Overcloud 镜像(Glance)
  • 编排 Overcloud (Heat)
  • 置备裸机(Ironic)

tripleo 还包括一个 Heat 模板集合，用于定义红帽支持的 Overcloud 环境。director 使用 Heat 读取此模板集合并编排 Overcloud 堆栈。Heat 还在这些核心 Heat 模板中为某些资源启动软件配置。此软件配置通常是 Bash 脚本或 Puppet 清单。

典型的软件配置依赖于两个主要的 Heat 资源：

  • 用于定义配置的资源(OS::Heat::SoftwareConfig)
  • 要在节点上实施配置的资源(OS::Heat::SoftwareDeployment)

例如，在 Heat 模板集合中，Compute 节点的部署后模板(puppet/compute-post.yaml)包含以下部分： 

resources:

  ComputePuppetConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: puppet
      options:
        enable_debug: {get_param: ConfigDebug}
      outputs:
      - name: result
      config:
        get_file: manifests/overcloud_compute.pp

  ComputePuppetDeployment:
    type: OS::Heat::StructuredDeployments
    properties:
      servers:  {get_param: servers}
      config: {get_resource: ComputePuppetConfig}
      input_values:
        update_identifier: {get_param: NodeConfigIdentifiers}
Copy to Clipboard Toggle word wrap

ComputePuppetConfig 资源加载一个 Puppet 清单(puppet/manifests/overcloud_compute.pp)，其中包含 Compute 节点的配置。ComputePuppetDeployment 资源将 ComputePuppetConfig 中的配置应用到服务器列表(服务器：{get_param: servers})，其父 Heat 模板定义为计算节点。根据 Puppet 是否已成功应用完整的清单，节点会报告 ComputePuppetDeployment 是成功还是失败。

此软件配置数据流对于了解如何通过 director 集成第三方解决方案非常重要。本指南使用此数据流来演示如何在核心配置之前和之后将自定义配置包含在 Overcloud 上。有关实现自定义配置的软件配置数据流示例，请参阅：

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat