高级 Overcloud 自定义

Red Hat OpenStack Platform 16.1

使用 Red Hat OpenStack Platform director 配置高级功能的方法

摘要

使用 Red Hat OpenStack Platform director 为 Red Hat OpenStack Platform (RHOSP)企业环境配置某些高级功能。这包括网络隔离、存储配置、SSL 通信和常规配置方法等功能。

前言

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息

对红帽文档提供反馈

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

使用直接文档反馈(DDF)功能

使用 添加反馈 DDF 功能,用于特定句子、段落或代码块上的直接注释。

  1. Multi-page HTML 格式查看文档。
  2. 请确定您看到文档右上角的 反馈 按钮。
  3. 用鼠标指针高亮显示您想评论的文本部分。
  4. 添加反馈
  5. 添加反馈项中输入您的意见。
  6. 可选:添加您的电子邮件地址,以便文档团队可以联系您以讨论您的问题。
  7. Submit

第 1 章 overcloud 配置简介

Red Hat OpenStack Platform (RHOSP) director 提供了一组工具,可用于置备和创建功能齐全的 OpenStack 环境,也称为 overcloud。Director 安装和使用指南 涵盖了基本 overcloud 的准备和配置。但是,生产级 overcloud 可能需要额外的配置:

  • 将 overcloud 集成到现有的网络基础架构中的基本网络配置。
  • 网络流量隔离在单独的 VLAN 上,用于某些 OpenStack 网络流量类型。
  • 用于保护公共端点上的通信的 SSL 配置
  • 存储选项,如 NFS、iSCSI、红帽 Ceph 存储以及多个第三方存储设备。
  • Red Hat Content Delivery Network 节点注册,或与您的内部 Red Hat Satellite 5 或 6 服务器注册。
  • 各种系统级别选项。
  • 各种 OpenStack 服务选项。
注意

本指南中的示例是配置 overcloud 的可选步骤。只有在您要提供 overcloud 时需要执行下列步骤时,才需要这些步骤。使用适用于您环境要求的步骤。

第 2 章 了解 heat 模板

本指南中的自定义配置使用 heat 模板和环境文件来定义 overcloud 的某些方面。本章介绍了 heat 模板,以便您可以在 Red Hat OpenStack Platform director 的上下文了解这些模板的结构和格式。

2.1. Heat 模板

director 使用 Heat 编配模板(HOT)作为 overcloud 部署计划的模板格式。HOT 格式的模板通常以 YAML 格式表示。模板的目的是定义和创建堆栈,它是 OpenStack Orchestration (heat)创建的资源集合,以及资源的配置。资源是 Red Hat OpenStack Platform (RHOSP)中的对象,可以包含计算资源、网络配置、安全组、扩展规则和自定义资源。

heat 模板有三个主要部分:

parameters
这些是传递给 heat 的设置,它提供了一种自定义堆栈的方法,以及没有传递值的参数的任何默认值。这些设置在模板的 parameter 部分中定义。
资源
使用 resources 部分定义资源,如计算实例、网络和存储卷,您可以使用此模板部署堆栈时创建它们。Red Hat OpenStack Platform (RHOSP)包含跨越所有组件的一组核心资源。这些是作为堆栈一部分创建和配置的具体对象。RHOSP 包含跨越所有组件的一组核心资源。它们在模板的 resources 部分中定义。
输出
使用 outputs 部分声明云用户在创建堆栈后可以访问的输出参数。您的云用户可以使用这些参数来请求有关堆栈的详细信息,如所部署实例的 IP 地址,或部署为堆栈一部分的 Web 应用的 URL。

基本 heat 模板示例:

heat_template_version: 2013-05-23

description: > A very basic Heat template.

parameters:
  key_name:
    type: string
    default: lars
    description: Name of an existing key pair to use for the instance
  flavor:
    type: string
    description: Instance type for the instance to be created
    default: m1.small
  image:
    type: string
    default: cirros
    description: ID or name of the image to use for the instance

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: My Cirros Instance
      image: { get_param: image }
      flavor: { get_param: flavor }
      key_name: { get_param: key_name }

output:
  instance_name:
    description: Get the instance's name
    value: { get_attr: [ my_instance, name ] }

此模板使用 资源类型:OS::Nova::Server 创建名为 my_instance 的实例,其具有云用户指定的特定类别、镜像和密钥。堆栈可以返回 instance_name 的值,它名为 My Cirros Instance

当 heat 处理模板时,它会为模板创建一个堆栈,并为资源模板创建一组子堆栈。这会创建一个堆栈的层次结构,该堆栈从您与模板定义的主堆栈中分离。您可以使用以下命令查看堆栈层次结构:

$ openstack stack list --nested

2.2. 环境文件

环境文件是可用来自定义 heat 模板的特殊模板。除了核心 heat 模板外,您还可以在部署命令中包含环境文件。环境文件包含三个主要部分:

resource_registry
本节定义与其他 heat 模板关联的自定义资源名称。这提供了一种方法,可以创建在核心资源集合中不存在的自定义资源。
parameters
这些是适用于顶级模板参数的通用设置。例如,如果您有一个部署嵌套堆栈(如资源 registry 映射)的模板,这些参数仅适用于顶级模板,而不应用到嵌套资源的模板。
parameter_defaults
这些参数为所有模板中的参数修改默认值。例如,如果您有一个部署嵌套堆栈的 heat 模板,如资源 registry 映射,则参数默认为所有模板。
重要

在为 overcloud 创建自定义环境文件时,使用 parameter_defaults 而不是 parameters,以便您的参数应用到 overcloud 的所有堆栈模板。

基本环境文件示例:

resource_registry:
  OS::Nova::Server::MyServer: myserver.yaml

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1

从特定 heat 模板(my_template.yaml)创建堆栈时,可能会包含此环境文件(my_env.yaml)。my_env.yaml 文件会创建一个名为 OS::Nova::Server::MyServer 的新资源类型。myserver.yaml 文件是一个 heat 模板文件,为这个资源类型提供实现,可覆盖任何内置文件。您可以在 my_template.yaml 文件中包含 OS::Nova::Server::MyServer 资源。

MyIP 仅将参数应用于使用此环境文件部署的主要 heat 模板。在本例中,MyIP 仅适用于 my_template.yaml 中的参数。

networkName 应用到主 heat 模板 my_template.yaml 以及与主模板中包含的资源关联的模板,如 OS::Nova::Server::MyServer 资源及其 myserver.yaml 模板。

注意

要使 RHOSP 使用 heat 模板文件作为自定义模板资源,文件扩展必须是 .yaml 或 .template。

2.3. 核心 overcloud heat 模板

director 包含 overcloud 的核心 heat 模板集合和环境文件集合。此集合保存在 /usr/share/openstack-tripleo-heat-templates 中。

这个模板集合中的主要文件和目录是:

overcloud.j2.yaml
这是 director 用来创建 overcloud 环境的主要模板文件。此文件使用 Jinja2 语法来迭代模板中的某些部分,以创建自定义角色。在 overcloud 部署过程中将呈现 Jinja2 格式到 YAML 中。
overcloud-resource-registry-puppet.j2.yaml
这是 director 用来创建 overcloud 环境的主要环境文件。它为存储在 overcloud 镜像上的 Puppet 模块提供了一组配置。在 director 将 overcloud 镜像写入每个节点后,heat 会使用此环境文件中注册的资源启动每个节点的 Puppet 配置。此文件使用 Jinja2 语法来迭代模板中的某些部分,以创建自定义角色。在 overcloud 部署过程中将呈现 Jinja2 格式到 YAML 中。
roles_data.yaml
此文件包含 overcloud 中角色的定义,以及将服务映射到各个角色。
network_data.yaml
此文件包含 overcloud 中网络的定义,以及它们的属性,如子网、分配池和 VIP 状态。默认 network_data.yaml 文件包含默认网络: External、In Internal Api、Storage、Storage Management、Tenant 和 Management。您可以创建自定义 network_data.yaml 文件,并使用 -n 选项将其添加到 openstack overcloud deploy 命令中。
plan-environment.yaml
此文件包含 overcloud 计划的元数据定义。这包括要使用的计划名称、要使用的主要模板,以及应用到 overcloud 的环境文件。
capabilities-map.yaml
此文件包含 overcloud 计划的环境文件映射。
部署
此目录包含 heat 模板。overcloud-resource-registry-puppet.j2.yaml 环境文件使用此目录中的文件来驱动每个节点上的 Puppet 配置应用。
environments
此目录包含额外的 heat 环境文件,可用于创建 overcloud。这些环境文件为生成的 Red Hat OpenStack Platform (RHOSP)环境启用额外的功能。例如,目录包含一个环境文件,用于启用 Cinder NetApp 后端存储(cinder-netapp-config.yaml)。
network
此目录包含一组 heat 模板,可用于创建隔离的网络和端口。
puppet
此目录包含控制 Puppet 配置的模板。overcloud-resource-registry-puppet.j2.yaml 环境文件使用此目录中的文件来驱动每个节点上的 Puppet 配置应用。
Puppet/服务
此目录包含所有服务配置的旧 heat 模板。部署 目录中的模板替换 puppet/services 目录中的大部分模板。
extraconfig
此目录包含可用于启用额外功能的模板。
firstboot
此目录包含 director 在最初创建节点时使用 的第一个_boot 脚本示例。

2.4. 规划环境元数据

您可以在计划环境元数据文件中为 overcloud 计划定义元数据。director 在 overcloud 创建过程中应用元数据,并在导入和导出 overcloud 计划时应用元数据。

使用计划环境文件来定义 director 可以通过 OpenStack Workflow (Mistral)服务执行的工作流。计划环境元数据文件包括以下参数:

version
模板的版本。
name
要用于存储计划文件的 OpenStack Object Storage (swift)中的 overcloud 计划和容器的名称。
模板
要用于 overcloud 部署的核心父模板。这通常是 overcloud.yaml,这是 overcloud.yaml.j2 模板的呈现版本。
environments
定义要使用的环境文件列表。使用 路径 子参数指定每个环境文件的名称和相对位置。
parameter_defaults
要在 overcloud 中使用的一组参数。这个功能的方式与标准环境文件中的 parameter_defaults 部分相同。
密码
要用于 overcloud 密码的一组参数。这个功能的方式与标准环境文件中的 parameter_defaults 部分相同。通常,director 使用随机生成的密码自动填充这个部分。
workflow_parameters
使用此参数为 OpenStack Workflow (mistral)命名空间提供一组参数。您可以使用它来计算和自动生成某些 overcloud 参数。

以下片段是计划环境文件的语法示例:

version: 1.0
name: myovercloud
description: 'My Overcloud Plan'
template: overcloud.yaml
environments:
- path: overcloud-resource-registry-puppet.yaml
- path: environments/containers-default-parameters.yaml
- path: user-environment.yaml
parameter_defaults:
  ControllerCount: 1
  ComputeCount: 1
  OvercloudComputeFlavor: compute
  OvercloudControllerFlavor: control
workflow_parameters:
  tripleo.derive_params.v1.derive_parameters:
    num_phy_cores_per_numa_node_for_pmd: 2

您可以使用 openstack overcloud deploy 命令包含计划环境文件,并带有 -p 选项:

(undercloud) $ openstack overcloud deploy --templates \
  -p /my-plan-environment.yaml \
  [OTHER OPTIONS]

您可以使用以下命令查看现有 overcloud 计划的计划元数据:

(undercloud) $ openstack object save overcloud plan-environment.yaml --file -

2.5. 在 overcloud 创建中包含环境文件

在部署命令中包含带有 -e 选项的环境文件。您可以根据需要纳入多个环境文件。但是,环境文件的顺序非常重要,因为后续环境文件中定义的参数和资源更为优先。例如,有两个包含常见资源类型 OS::TripleO::NodeExtraConfigPost 的环境文件,以及一个 common parameter TimeZone

environment-file-1.yaml

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-1.yaml

parameter_defaults:
  RabbitFDLimit: 65536
  TimeZone: 'Japan'

environment-file-2.yaml

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-2.yaml

parameter_defaults:
  TimeZone: 'Hongkong'

在部署命令中包括这两个环境文件:

$ openstack overcloud deploy --templates -e environment-file-1.yaml -e environment-file-2.yaml

openstack overcloud deploy 命令通过以下进程运行:

  1. 从核心 heat 模板集合中加载默认配置。
  2. environment-file-1.yaml 应用配置,这将覆盖默认配置中的任何常见设置。
  3. 应用 environment-file-2.yaml 的配置,它会覆盖默认配置和 environment-file-1.yaml 中的任何常见设置。

这会对 overcloud 的默认配置进行以下更改:

  • OS::TripleO::NodeExtraConfigPost 资源被设置为 /home/stack/templates/template-2.yaml,如 environment-file-2.yaml 中的定义。
  • timezone 参数设为 Hongkong,如 environment-file-2.yaml 中定义的。
  • RabbitFDLimit 参数设置为 65536,如 environment-file-1.yaml 中的定义。environment-file-2.yaml 不会更改此值。

您可以使用此机制为您的 overcloud 定义自定义配置,而无需来自多个环境文件的值冲突。

2.6. 使用自定义核心 heat 模板

在创建 overcloud 时,director 使用位于 /usr/share/openstack-tripleo-heat-templates 中的一组核心 heat 模板。如果要自定义此核心模板集合,请使用以下 Git 工作流来管理自定义模板集合:

流程

  • 创建包含 heat 模板集合的初始 Git 存储库:

    1. 将模板集合复制到 /home/stack/templates 目录中:

      $ cd ~/templates
      $ cp -r /usr/share/openstack-tripleo-heat-templates .
    2. 进入自定义模板目录并初始化 Git 存储库:

      $ cd ~/templates/openstack-tripleo-heat-templates
      $ git init .
    3. 配置您的 Git 用户名和电子邮件地址:

      $ git config --global user.name "<USER_NAME>"
      $ git config --global user.email "<EMAIL_ADDRESS>"

      <USER_NAME > 替换为您要使用的用户名。将 <EMAIL_ADDRESS > 替换为您的电子邮件地址。

    4. 为初始提交暂存所有模板:

      $ git add *
    5. 创建初始提交:

      $ git commit -m "Initial creation of custom core heat templates"

      这会创建一个包含最新核心模板集合的初始 master 分支。使用此分支作为自定义分支的基础,并将新模板版本合并到此分支。

  • 使用自定义分支将您的更改存储到核心模板集合中。使用以下步骤创建 my-customizations 分支并添加自定义:

    1. 创建 my-customizations 分支并切换到它:

      $ git checkout -b my-customizations
    2. 编辑自定义分支中的文件。
    3. 在 git 中暂存更改:

      $ git add [edited files]
    4. 将更改提交到自定义分支:

      $ git commit -m "[Commit message for custom changes]"

      这会将您的更改作为提交添加到 my-customizations 分支。当 master 分支更新时,您可以 rebase my-customizations off master,这会导致 git 把这些提交添加到更新的模板集合中。这有助于跟踪您的自定义信息,并在将来的模板更新中重新显示它们。

  • 更新 undercloud 时,openstack-tripleo-heat-templates 软件包可能会接收更新。发生这种情况时,还必须更新自定义模板集合:

    1. openstack-tripleo-heat-templates 软件包版本保存为环境变量:

      $ export PACKAGE=$(rpm -qv openstack-tripleo-heat-templates)
    2. 进入模板集合目录并为更新的模板创建新分支:

      $ cd ~/templates/openstack-tripleo-heat-templates
      $ git checkout -b $PACKAGE
    3. 删除分支中的所有文件,并将其替换为新版本:

      $ git rm -rf *
      $ cp -r /usr/share/openstack-tripleo-heat-templates/* .
    4. 为初始提交添加所有模板:

      $ git add *
    5. 为软件包更新创建提交:

      $ git commit -m "Updates for $PACKAGE"
    6. 将分支合并到 master 中。如果使用 Git 管理系统(如 GitLab),请使用管理工作流。如果在本地使用 git,请切换到 master 分支并运行 git merge 命令:

      $ git checkout master
      $ git merge $PACKAGE

master 分支现在包含核心模板集合的最新版本。现在,您可以从这个更新的集合中 rebase my-customization 分支。

  • 更新 my-customization 分支,:

    1. 进入 my-customizations 分支:

      $ git checkout my-customizations
    2. 将分支重基为 master

      $ git rebase master

      这会更新 my-customizations 分支,并重播向此分支发出的自定义提交。

  • 解决 rebase 中出现的任何冲突:

    1. 检查哪些文件包含冲突:

      $ git status
    2. 解决标识的模板文件冲突。
    3. 添加解析的文件:

      $ git add [resolved files]
    4. 继续 rebase:

      $ git rebase --continue
  • 部署自定义模板集合:

    1. 确保已切换到 my-customization 分支:

      git checkout my-customizations
    2. 使用 --templates 选项运行 openstack overcloud deploy 命令,以指定您的本地模板目录:

      $ openstack overcloud deploy --templates /home/stack/templates/openstack-tripleo-heat-templates [OTHER OPTIONS]
注意

如果您指定没有目录的 --templates 选项,director 将使用默认模板目录(/usr/share/openstack-tripleo-heat-templates)。

重要

红帽建议使用 第 4 章 配置 hook 中的方法而不是修改 heat 模板集合。

2.7. Jinja2 渲染

/usr/share/openstack-tripleo-heat-templates 中的核心 heat 模板包含很多具有 j2.yaml 文件扩展名的文件。这些文件包含 Jinja2 模板语法,director 会把这些文件呈现给其具有 .yaml 扩展名的静态 heat 模板。例如,主 overcloud.j2.yaml 文件呈现到 overcloud.yaml 中。director 使用生成的 overcloud.yaml 文件。

Jinja2-enabled heat 模板使用 Jinja2 语法为迭代值创建参数和资源。例如,overcloud.j2.yaml 文件包含以下代码片段:

parameters:
...
{% for role in roles %}
  ...
  {{role.name}}Count:
    description: Number of {{role.name}} nodes to deploy
    type: number
    default: {{role.CountDefault|default(0)}}
  ...
{% endfor %}

当 director 呈现 Jinja2 语法时,director 会迭代 roles_data.yaml 文件中定义的角色,并使用角色名称填充 {{role.name}}Count 参数。默认 roles_data.yaml 文件包含五个角色,并生成以下示例中的以下参数:

  • ControllerCount
  • ComputeCount
  • BlockStorageCount
  • ObjectStorageCount
  • CephStorageCount

参数渲染版本示例如下:

parameters:
  ...
  ControllerCount:
    description: Number of Controller nodes to deploy
    type: number
    default: 1
  ...

director 仅为核心 heat 模板的 目录中呈现 Jinja2enabled 模板和环境文件。以下用例演示了呈现 Jinja2 模板的正确方法。

使用案例 1:默认核心模板

模板目录: /usr/share/openstack-tripleo-heat-templates/

环境文件: /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.j2.yaml

director 使用默认核心模板位置(--templates),并将 network-isolation.j2.yaml 文件呈现为 network-isolation.yaml。运行 openstack overcloud deploy 命令时,使用 -e 选项包括 rendered network-isolation.yaml 文件的名称。

$ openstack overcloud deploy --templates \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
    ...

使用案例 2:自定义核心模板

模板目录: /home/stack/tripleo-heat-templates

环境文件: /home/stack/tripleo-heat-templates/environments/network-isolation.j2.yaml

director 使用自定义核心模板位置(--templates /home/stack/tripleo-heat-templates)和 director 在自定义核心模板中的 network-isolation.j2.yaml 文件呈现到 network-isolation.yaml 中。运行 openstack overcloud deploy 命令时,使用 -e 选项包括 rendered network-isolation.yaml 文件的名称。

$ openstack overcloud deploy --templates /home/stack/tripleo-heat-templates \
    -e /home/stack/tripleo-heat-templates/environments/network-isolation.yaml
    ...

使用案例 3:增加使用量

模板目录: /usr/share/openstack-tripleo-heat-templates/

环境文件: /home/stack/tripleo-heat-templates/environments/network-isolation.j2.yaml

director 使用自定义核心模板位置(--templates /home/stack/tripleo-heat-templates)。但是,所选的 network-isolation.j2.yaml 不在自定义核心模板中,因此不会呈现给 network-isolation.yaml。这会导致部署失败。

将 Jinja2 语法处理到静态模板中

使用 process-templates.py 脚本将 openstack-tripleo-heat-templates 的 Jinja2 语法呈现到一组静态模板。要使用 process-templates.py 脚本呈现 openstack-tripleo-heat-templates 集合的副本,请改为 openstack-tripleo-heat-templates 目录:

$ cd /usr/share/openstack-tripleo-heat-templates

运行位于 工具 目录中的 process-templates.py 脚本以及 -o 选项,以定义保存静态副本的自定义目录:

$ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered

这会将所有 Jinja2 模板转换为其呈现的 YAML 版本,并将结果保存到 ~/openstack-tripleo-heat-templates-rendered 中。

第 3 章 Heat 参数

director 模板集合中的每个 heat 模板都包含一个 parameters 部分。本节包含特定于特定 overcloud 服务的所有参数的定义。这包括以下内容:

  • overcloud.j2.yaml - 默认基本参数
  • roles_data.yaml - 可组合角色的默认参数
  • deployment/*.yaml - 特定服务的默认参数

您可以使用以下方法修改这些参数的值:

  1. 为您的自定义参数创建环境文件。
  2. 在环境文件的 parameter_defaults 部分中包含您的自定义参数。
  3. 使用 openstack overcloud deploy 命令包含环境文件。

3.1. 示例 1:配置时区

用于设置时区的 Heat 模板(puppet/services/time/timezone.yaml)包含 TimeZone 参数。如果将 TimeZone 参数留空,则 overcloud 会将时间设置为 UTC 作为默认值。

要获取时区列表,请运行 timedatectl list-timezones 命令。以下示例命令检索 Asia 的时区:

$ sudo timedatectl list-timezones|grep "Asia"

在识别时区后,在环境文件中设置 TimeZone 参数。以下示例环境文件将 TimeZone 的值设置为 Asia/Tokyo

parameter_defaults:
  TimeZone: 'Asia/Tokyo'

3.2. 示例 2:配置 RabbitMQ 文件描述符限制

对于某些配置,您可能需要提高 RabbitMQ 服务器的文件描述符限制。使用 deployment/rabbitmq/rabbitmq-container-puppet.yaml heat 模板在 RabbitFDLimit 参数中设置一个新的限制。在环境文件中添加以下条目:

parameter_defaults:
  RabbitFDLimit: 65536

3.3. 示例 3:启用和禁用参数

您可能需要在部署期间先设置参数,然后为将来的部署操作禁用 参数,如更新或扩展操作。例如,要在 overcloud 创建过程中包括自定义 RPM,请在环境文件中包括以下条目:

parameter_defaults:
  DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]

要从未来的部署中禁用此参数,不要足以删除该参数。相反,您必须将参数设置为空值:

parameter_defaults:
  DeployArtifactURLs: []

这可确保不再为后续部署操作设置该参数。

3.4. 示例 4:基于角色的参数

使用 [ROLE]Parameters 参数,将 [ROLE] 替换为可组合角色,为特定角色设置参数。

例如,director 在 Controller 和 Compute 节点上配置 sshd。要为 Controller 和 Compute 节点设置不同的 sshd 参数,请创建一个环境文件,其中包含 ControllerParameterscomputeParameters 参数,并为每个特定角色设置 sshd 参数:

parameter_defaults:
  ControllerParameters:
    BannerText: "This is a Controller node"
  ComputeParameters:
    BannerText: "This is a Compute node"

3.5. 识别您要修改的参数

Red Hat OpenStack Platform director 为配置提供了多个参数。在某些情况下,您可能需要识别要配置的特定选项以及对应的 director 参数。如果您要使用 director 配置的选项,请使用以下工作流来识别并将选项映射到特定的 overcloud 参数:

  1. 确定您要配置的选项。记录使用 选项的服务。
  2. 为此选项检查对应的 Puppet 模块。Red Hat OpenStack Platform 的 Puppet 模块位于 director 节点上的 /etc/puppet/modules 下。每个模块对应于特定的服务。例如,keystone 模块对应于 OpenStack Identity (keystone)。

    • 如果 Puppet 模块包含控制所选选项的变量,请转到下一步。
    • 如果 Puppet 模块不包含控制所选选项的变量,则此选项没有 hieradata。若有可能,您可以在 overcloud 完成部署后手动设置选项。
  3. 以 hieradata 的形式检查 Puppet 变量的核心 heat 模板集合。deployment/* 中的模板通常对应于同一服务的 Puppet 模块。例如,deploy /keystone/keystone-container-puppet.yaml 模板为 keystone 模块提供 hieradata。

    • 如果 heat 模板为 Puppet 变量设置 hieradata,则模板也应披露您可以修改的基于 director 的参数。
    • 如果 heat 模板没有为 Puppet 变量设置 hieradata,请使用配置 hook 使用环境文件传递 hieradata。有关自定义 hieradata 的更多信息,请参阅 第 4.5 节 “Puppet:自定义角色的 hieradata”

流程

  1. 要更改 OpenStack Identity (keystone)的通知格式,请使用工作流并完成以下步骤:

    1. 识别您要配置的 OpenStack 参数(notification_format)。
    2. keystone Puppet 模块中搜索 notification_format 设置:

      $ grep notification_format /etc/puppet/modules/keystone/manifests/*

      在本例中,keystone 模块使用 keystone::notification_format 变量管理此选项。

    3. 为这个变量搜索 keystone 服务模板:

      $ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/deployment/keystone/keystone-container-puppet.yaml

      输出显示 director 使用 KeystoneNotificationFormat 参数来设置 keystone::notification_format hieradata。

下表显示了最终映射:

director 参数Puppet hieradataOpenStack Identity (keystone)选项

KeystoneNotificationFormat

keystone::notification_format

notification_format

您可以在 overcloud 环境文件中设置 KeystoneNotificationFormat,然后在 overcloud 配置过程中设置 keystone.conf 文件中的 notification_format 选项。

第 4 章 配置 hook

使用配置 hook 将您自己的自定义配置功能注入到 overcloud 部署过程中。您可以创建 hook 以在主 overcloud 服务配置前后注入自定义配置,以及用于修改和包含基于 Puppet 的配置的 hook。

4.1. 第一次引导:自定义第一次引导配置

director 使用 cloud-init 在初始创建 overcloud 后在所有节点上执行配置。您可以使用 NodeUserData 资源类型调用 cloud-init

OS::TripleO::NodeUserData
用于应用到所有节点的 cloud-init 配置。
OS::TripleO::Controller::NodeUserData
应用到 Controller 节点的 cloud-init 配置。
OS::TripleO::Compute::NodeUserData
用于应用到 Compute 节点的 cloud-init 配置。
OS::TripleO::CephStorage::NodeUserData
适用于 Ceph Storage 节点的 cloud-init 配置。
OS::TripleO::ObjectStorage::NodeUserData
适用于 Object Storage 节点的 cloud-init 配置。
OS::TripleO::BlockStorage::NodeUserData
适用于块存储节点的 cloud-init 配置。
OS::TripleO::[ROLE]::NodeUserData
用于应用到自定义节点的 cloud-init 配置。用可组合角色名称替换 [ROLE]

在本例中,使用所有节点上的自定义 IP 地址更新名称服务器:

流程

  1. 创建一个基本的 heat 模板 ~/templates/nameserver.yaml,它将运行一个脚本,将每个节点上的 resolv.conf 文件附加具有特定名称服务器。您可以使用 OS::TripleO::MultipartMime 资源类型来发送配置脚本。

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    resources:
      userdata:
        type: OS::Heat::MultipartMime
        properties:
          parts:
          - config: {get_resource: nameserver_config}
    
      nameserver_config:
        type: OS::Heat::SoftwareConfig
        properties:
          config: |
            #!/bin/bash
            echo "nameserver 192.168.1.1" >> /etc/resolv.conf
    
    outputs:
      OS::stack_id:
        value: {get_resource: userdata}
  2. 创建一个环境文件 ~/templates/firstboot.yaml,将 heat 模板注册为 OS::TripleO::NodeUserData 资源类型。

    resource_registry:
      OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml
  3. 要将第一次引导配置添加到 overcloud 中,请将环境文件添加到堆栈中,以及其他环境文件:

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/firstboot.yaml \
        ...

    这会在所有节点首次创建并首次引导时将配置添加到所有节点。这些模板的后续包含(如更新 overcloud 堆栈)不会运行这些脚本。

重要

您只能将 NodeUserData 资源注册到每个资源的一个 heat 模板。后续用法会覆盖要使用的 heat 模板。

4.2. 预配置:自定义特定的 overcloud 角色

overcloud 使用 Puppet 作为 OpenStack 组件的核心配置。director 提供一组 hook,您可以在第一次引导完成并开始核心配置后为特定节点角色执行自定义配置。这些 hook 包括:

重要

本文档的早期版本使用 OS::TripleO::Tasks::*PreConfig 资源来为每个角色提供预配置 hook。heat 模板集合需要专用的 hook,这意味着您不应该将它们用于自定义用途。反之,请使用此处概述的 OS::TripleO::*ExtraConfigPre hook。

OS::TripleO::ControllerExtraConfigPre
在核心 Puppet 配置前,应用到 Controller 节点的额外配置。
OS::TripleO::ComputeExtraConfigPre
在 Puppet 核心配置之前,应用到 Compute 节点的额外配置。
OS::TripleO::CephStorageExtraConfigPre
在核心 Puppet 配置之前,应用到 Ceph Storage 节点的额外配置。
OS::TripleO::ObjectStorageExtraConfigPre
在 Puppet 核心配置之前,应用到 Object Storage 节点的额外配置。
OS::TripleO::BlockStorageExtraConfigPre
在 Puppet 核心配置之前,应用到块存储节点的附加配置。
OS::TripleO::[ROLE]ExtraConfigPre
在 Puppet 核心配置之前,应用到自定义节点的额外配置。用可组合角色名称替换 [ROLE]

在本例中,将 resolv.conf 文件附加到特定角色的所有节点上,并带有变量名称服务器:

流程

  1. 创建基本的 heat 模板 ~/templates/nameserver.yaml,该脚本将变量名称服务器写入节点的 resolv.conf 文件:

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    parameters:
      server:
        type: string
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
    
    resources:
      CustomExtraConfigPre:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/sh
                echo "nameserver _NAMESERVER_IP_" > /etc/resolv.conf
              params:
                _NAMESERVER_IP_: {get_param: nameserver_ip}
    
      CustomExtraDeploymentPre:
        type: OS::Heat::SoftwareDeployment
        properties:
          server: {get_param: server}
          config: {get_resource: CustomExtraConfigPre}
          actions: ['CREATE','UPDATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}
    
    outputs:
      deploy_stdout:
        description: Deployment reference, used to trigger pre-deploy on changes
        value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

    在本例中,resource 部分包含以下参数:

    CustomExtraConfigPre
    这定义了软件配置。在本例中,我们定义了 Bash 脚本和 heat,并将 _NAMESERVER_IP_ 替换为存储在 nameserver_ip 参数中的值。
    CustomExtraDeploymentPre

    这会执行软件配置,这是来自 CustomExtraConfigPre 资源的软件配置。注意以下几点:

    • config 参数会引用 CustomExtraConfigPre 资源,以便 heat 知道要应用的配置。
    • server 参数检索 overcloud 节点的 map。此参数由父模板提供,是此 hook 模板中的强制要求。
    • actions 参数定义何时应用配置。在这种情况下,您希望在创建 overcloud 时应用配置。可能的操作包括 CREATEUPDATEDELETESUSPENDRESUME
    • input_values 包含一个名为 deploy_identifier 的参数,它存储来自父模板中的 DeployIdentifier。此参数为每个部署更新提供资源时间戳,以确保在后续的 overcloud 更新中重置资源。
  2. 创建一个环境文件 ~/templates/pre_config.yaml,将 heat 模板注册到基于角色的资源类型。例如,要将配置应用到 Controller 节点,请使用 ControllerExtraConfigPre hook:

    resource_registry:
      OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml
    
    parameter_defaults:
      nameserver_ip: 192.168.1.1
  3. 将环境文件添加到堆栈中,以及其他环境文件:

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/pre_config.yaml \
        ...

    这会在核心配置开始初始 overcloud 创建或后续更新时,将配置应用到所有 Controller 节点。

重要

每个资源可以为每个 hook 只注册一个 heat 模板。后续用法会覆盖要使用的 heat 模板。

4.3. 预配置:自定义所有 overcloud 角色

overcloud 使用 Puppet 作为 OpenStack 组件的核心配置。director 提供了一个 hook,您可以在第一次引导完成后以及启动核心配置前配置所有节点类型:

OS::TripleO::NodeExtraConfig
在核心 Puppet 配置之前,将额外的配置应用到所有节点角色。

在本例中,将每个节点上的 resolv.conf 文件附加到一个可变名称服务器:

流程

  1. 创建基本的 heat 模板 ~/templates/nameserver.yaml,它将运行一个脚本,以将每个节点的 resolv.conf 文件附加有变量名称服务器:

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    parameters:
      server:
        type: string
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
    
    resources:
      CustomExtraConfigPre:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/sh
                echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
              params:
                _NAMESERVER_IP_: {get_param: nameserver_ip}
    
      CustomExtraDeploymentPre:
        type: OS::Heat::SoftwareDeployment
        properties:
          server: {get_param: server}
          config: {get_resource: CustomExtraConfigPre}
          actions: ['CREATE','UPDATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}
    
    outputs:
      deploy_stdout:
        description: Deployment reference, used to trigger pre-deploy on changes
        value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

    在本例中,resource 部分包含以下参数:

    CustomExtraConfigPre
    此参数定义一个软件配置。在本例中,您定义一个 Bash 脚本,heat 将 _NAMESERVER_IP_ 替换为存储在 nameserver_ip 参数中的值。
    CustomExtraDeploymentPre

    此参数执行软件配置,这是来自 CustomExtraConfigPre 资源的软件配置。注意以下几点:

    • config 参数会引用 CustomExtraConfigPre 资源,以便 heat 知道要应用的配置。
    • server 参数检索 overcloud 节点的 map。此参数由父模板提供,是此 hook 模板中的强制要求。
    • actions 参数定义何时应用配置。在这种情况下,您只能在创建 overcloud 时应用配置。可能的操作包括 CREATEUPDATEDELETESUSPENDRESUME
    • input_values 参数包含名为 deploy_identifier 的子参数,用于存储父模板中的 DeployIdentifier。此参数为每个部署更新提供资源时间戳,以确保在后续的 overcloud 更新中重置资源。
  2. 创建一个环境文件 ~/templates/pre_config.yaml,将 heat 模板注册为 OS::TripleO::NodeExtraConfig 资源类型。

    resource_registry:
      OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml
    
    parameter_defaults:
      nameserver_ip: 192.168.1.1
  3. 将环境文件添加到堆栈中,以及其他环境文件:

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/pre_config.yaml \
        ...

    这会在核心配置开始初始 overcloud 创建或后续更新时,将配置应用到所有节点。

重要

您可以将 OS::TripleO::NodeExtraConfig 注册到一个 heat 模板。后续用法会覆盖要使用的 heat 模板。

4.4. post-configuration:自定义所有 overcloud 角色

重要

本文档的早期版本使用 OS::TripleO::Tasks::*PostConfig 资源来为每个角色提供安装后 hook。heat 模板集合需要专用的 hook,这意味着您不应该将它们用于自定义用途。反之,请使用此处概述的 OS::TripleO::NodeExtraConfigPost hook。

当您完成 overcloud 创建但希望在初始创建或后续 overcloud 更新时,可以为所有角色添加额外的配置,会出现这种情况。在这种情况下,使用以下后配置 hook:

OS::TripleO::NodeExtraConfigPost
在核心 Puppet 配置后,应用到所有节点角色的额外配置。

在本例中,将每个节点上的 resolv.conf 文件附加到一个可变名称服务器:

流程

  1. 创建基本的 heat 模板 ~/templates/nameserver.yaml,它将运行一个脚本,以将每个节点的 resolv.conf 文件附加有变量名称服务器:

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    parameters:
      servers:
        type: json
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
      EndpointMap:
        default: {}
        type: json
    
    resources:
      CustomExtraConfig:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/sh
                echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
              params:
                _NAMESERVER_IP_: {get_param: nameserver_ip}
    
      CustomExtraDeployments:
        type: OS::Heat::SoftwareDeploymentGroup
        properties:
          servers:  {get_param: servers}
          config: {get_resource: CustomExtraConfig}
          actions: ['CREATE','UPDATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}

    在本例中,resource 部分包含以下参数:

    CustomExtraConfig
    这定义了软件配置。在本例中,您定义一个 Bash 脚本,heat 将 _NAMESERVER_IP_ 替换为存储在 nameserver_ip 参数中的值。
    CustomExtraDeployments

    这会执行软件配置,这是来自 CustomExtraConfig 资源的软件配置。注意以下几点:

    • config 参数会引用 CustomExtraConfig 资源,以便 heat 知道要应用的配置。
    • servers 参数检索 overcloud 节点的 map。此参数由父模板提供,是此 hook 模板中的强制要求。
    • actions 参数定义何时应用配置。在这种情况下,您希望在创建 overcloud 时应用配置。可能的操作包括 CREATEUPDATEDELETESUSPENDRESUME
    • input_values 包含一个名为 deploy_identifier 的参数,它存储来自父模板中的 DeployIdentifier。此参数为每个部署更新提供资源时间戳,以确保在后续的 overcloud 更新中重置资源。
  2. 创建一个环境文件 ~/templates/post_config.yaml,将 heat 模板注册为 OS::TripleO::NodeExtraConfigPost: 资源类型。

    resource_registry:
      OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml
    
    parameter_defaults:
      nameserver_ip: 192.168.1.1
  3. 将环境文件添加到堆栈中,以及其他环境文件:

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/post_config.yaml \
        ...

    在初始 overcloud 创建或后续更新上完成核心配置后,这会将配置应用到所有节点。

重要

您可以将 OS::TripleO::NodeExtraConfigPost 注册到一个 heat 模板。后续用法会覆盖要使用的 heat 模板。

4.5. Puppet:自定义角色的 hieradata

heat 模板集合包含一组参数,可用于将额外的配置传递给特定的节点类型。这些参数将配置保存为节点上 Puppet 配置的 hieradata:

ControllerExtraConfig
添加至所有 Controller 节点的配置。
ComputeExtraConfig
添加至所有 Compute 节点的配置。
BlockStorageExtraConfig
添加至所有块存储节点的配置。
ObjectStorageExtraConfig
添加至所有 Object Storage 节点的配置。
CephStorageExtraConfig
添加至所有 Ceph Storage 节点的配置。
[ROLE]ExtraConfig
要添加到可组合角色的配置。用可组合角色名称替换 [ROLE]
ExtraConfig
要添加到所有节点的配置。

流程

  1. 要在部署后配置过程中添加额外的配置,请在 parameter_defaults 部分中创建一个包含这些参数的环境文件。例如,要将 Compute 主机保留的内存增加到 1024 MB,并将 VNC keymap 设置为 Japanese,请使用 ComputeExtraConfig 参数中的以下条目:

    parameter_defaults:
      ComputeExtraConfig:
        nova::compute::reserved_host_memory: 1024
        nova::compute::vnc_keymap: ja
  2. 将此环境文件包含在 openstack overcloud deploy 命令中,以及与部署相关的任何其他环境文件。
重要

您只能定义一个参数一次。后续使用会覆盖之前的值。

4.6. Puppet:为单个节点自定义 hieradata

您可以使用 heat 模板集合为各个节点设置 Puppet hieradata:

流程

  1. 从节点的内省数据识别系统 UUID:

    $ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid

    这个命令会返回系统 UUID。例如:

    "f5055c6c-477f-47fb-afe5-95c6928c407f"
  2. 创建一个环境文件来定义特定于节点的 hieradata,并将 per_node.yaml 模板注册到预配置 hook。在 NodeDataLookup 参数中包括您要配置的节点的系统 UUID:

    resource_registry:
      OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml
    parameter_defaults:
      NodeDataLookup: '{"f5055c6c-477f-47fb-afe5-95c6928c407f": {"nova::compute::vcpu_pin_set": [ "2", "3" ]}}'
  3. 将此环境文件包含在 openstack overcloud deploy 命令中,以及与部署相关的任何其他环境文件。

per_node.yaml 模板在节点上生成一组 hieradata 文件,对应于每个系统 UUID,并包含您定义的 hieradata。如果没有定义 UUID,则生成的 hieradata 文件为空。在本例中,per_node.yaml 模板在所有 Compute 节点上运行,如 OS::TripleO::ComputeExtraConfigPre hook,但只有有系统 UUID f5055c6c-477f-47fb-afe5-95c6928c407f 的 Compute 节点接收 hieradata。

您可以根据具体要求使用此机制来定制每个节点。

有关 NodeDataLookup 的更多信息,请参阅 Deploying an overcloud with containerized Red Hat Ceph 指南中的 Altering the disk layout in Ceph Storage nodes

4.7. Puppet:应用自定义清单

在某些情况下,您可能想要在 overcloud 节点上安装和配置一些额外的组件。您可以通过自定义 Puppet 清单来实现此目的,此清单在主配置完成后应用到节点。作为基本示例,您可能想要在每个节点上安装 motd

流程

  1. 创建启动 Puppet 配置的 heat 模板 ~/templates/custom_puppet_config.yaml

    heat_template_version: 2014-10-16
    
    description: >
      Run Puppet extra configuration to set new MOTD
    
    parameters:
      servers:
        type: json
      DeployIdentifier:
        type: string
      EndpointMap:
        default: {}
        type: json
    
    resources:
      ExtraPuppetConfig:
        type: OS::Heat::SoftwareConfig
        properties:
          config: {get_file: motd.pp}
          group: puppet
          options:
            enable_hiera: True
            enable_facter: False
    
      ExtraPuppetDeployments:
        type: OS::Heat::SoftwareDeploymentGroup
        properties:
          config: {get_resource: ExtraPuppetConfig}
          servers: {get_param: servers}

    本例包括模板中的 /home/stack/templates/motd.pp,并将其传递给节点以进行配置。motd.pp 文件包含安装和配置 motd 所需的 Puppet 类。

  2. 创建一个环境文件 ~templates/puppet_post_config.yaml,将 heat 模板注册为 OS::TripleO::NodeExtraConfigPost: 资源类型。

    resource_registry:
      OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml
  3. 将此环境文件包含在 openstack overcloud deploy 命令中,以及与部署相关的任何其他环境文件。

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/puppet_post_config.yaml \
        ...

    这会将 motd.pp 的配置应用到 overcloud 中的所有节点。

第 5 章 基于 Ansible 的 overcloud 注册

director 使用基于 Ansible 的方法将 overcloud 节点注册到红帽客户门户网站或红帽卫星服务器。

如果使用了之前 Red Hat OpenStack Platform 版本中的 rhel 注册方法,则必须禁用它并切换到基于 Ansible 的方法。如需更多信息,请参阅 第 5.6 节 “切换到 rhsm 可组合服务”第 5.7 节 “rhel-regration 到 rhsm 映射”

除了基于 director 的注册方法外,您还可以在部署后手动注册。如需更多信息,请参阅 第 5.9 节 “手动运行基于 Ansible 的注册”

5.1. Red Hat Subscription Manager (RHSM)可组合服务

您可以使用 rhsm 可组合服务通过 Ansible 注册 overcloud 节点。默认 roles_data 文件中的每个角色都包含一个 OS::TripleO::Services::Rhsm 资源,它默认为禁用。要启用该服务,将资源注册到 rhsm 可组合服务文件中:

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

rhsm 可组合服务接受一个 RhsmVars 参数,可用于定义与注册相关的多个子参数:

parameter_defaults:
  RhsmVars:
    rhsm_repos:
      - rhel-8-for-x86_64-baseos-eus-rpms
      - rhel-8-for-x86_64-appstream-eus-rpms
      - rhel-8-for-x86_64-highavailability-eus-rpms
      …​
    rhsm_username: "myusername"
    rhsm_password: "p@55w0rd!"
    rhsm_org_id: "1234567"
    rhsm_release: 8.2

您还可以将 RhsmVars 参数与特定于角色的参数结合使用,如 ControllerParameters,以便在为不同的节点类型启用特定软件仓库时提供灵活性。

5.2. RhsmVars sub-parameters

在配置 rhsm composable 服务时,使用以下子参数作为 RhsmVars 参数的一部分。有关可用的 Ansible 参数的更多信息,请参阅 角色文档

rhsm描述

rhsm_method

选择注册方法。门户卫星 或禁用

rhsm_org_id

要用于注册的组织。要找到此 ID,请从 undercloud 节点运行 sudo subscription-manager orgs。在提示符处输入您的红帽凭据,并使用生成的 密钥值。有关您的机构 ID 的更多信息,请参阅了解 Red Hat Subscription Management Organization ID

rhsm_pool_ids

要使用的订阅池 ID。如果您不想自动附加订阅,请使用此参数。要找到此 ID,请运行 sudo subscription-manager list --available --all --matches="*Red OpenStack*" from the undercloud 节点,并使用生成的 池 ID 值。使用列表格式将多个 ID 传递给这个参数。

rhsm_activation_key

要用于注册的激活码。

rhsm_autosubscribe

使用这个参数自动将兼容订阅附加到此系统。将值设为 true 以启用此功能。

rhsm_baseurl

获取内容的基本 URL。默认 URL 是 Red Hat Content Delivery Network。如果使用 Satellite 服务器,请将此值改为 Satellite 服务器内容存储库的基本 URL。

rhsm_server_hostname

用于注册的订阅管理服务的主机名。默认为 Red Hat Subscription Management 主机名。如果使用 Satellite 服务器,请将此值改为 Satellite 服务器主机名。

rhsm_repos

要启用的软件仓库列表。

rhsm_username

注册的用户名。如果可能,请使用激活码注册。

rhsm_password

注册的密码。如果可能,请使用激活码注册。

rhsm_release

用于固定存储库的 Red Hat Enterprise Linux 版本。对于 Red Hat OpenStack Platform,这被设置为 8.2

rhsm_rhsm_proxy_hostname

HTTP 代理的主机名。例如: proxy.example.com

rhsm_rhsm_proxy_port

HTTP 代理通信的端口。例如:8080

rhsm_rhsm_proxy_user

用于访问 HTTP 代理的用户名。

rhsm_rhsm_proxy_password

用于访问 HTTP 代理的密码。

重要

只有在 rhsm_method 设置为 portal 时,才可使用 rhsm_activation_keyrhsm_repos。如果将 rhsm_method 设置为 satellite,则只能使用 rhsm_activation_keyrhsm_repos

5.3. 使用 rhsm 可组合服务注册 overcloud

创建可启用和配置 rhsm 可组合服务的环境文件。director 使用此环境文件注册和订阅您的节点。

流程

  1. 创建名为 templates/rhsm.yml 的环境文件,以存储配置。
  2. 在环境文件中包含您的配置。例如:

    resource_registry:
      OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
    parameter_defaults:
      RhsmVars:
        rhsm_repos:
          - rhel-8-for-x86_64-baseos-eus-rpms
          - rhel-8-for-x86_64-appstream-eus-rpms
          - rhel-8-for-x86_64-highavailability-eus-rpms
          …​
        rhsm_username: "myusername"
        rhsm_password: "p@55w0rd!"
        rhsm_org_id: "1234567"
        rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
        rhsm_method: "portal"
        rhsm_release: 8.2
    • resource_registry 部分将 rhsm 可组合服务与 OS::TripleO::Services::Rhsm 资源关联,每个角色都可用。
    • RhsmVars 变量将参数传递给 Ansible,以配置您的红帽注册。
  3. 保存环境文件。

5.4. 将 rhsm 可组合服务应用到不同的角色

您可以以每个角色为基础应用 rhsm 可组合服务。例如,您可以将不同类型的配置应用到 Controller 节点、Compute 节点和 Ceph Storage 节点。

流程

  1. 创建名为 templates/rhsm.yml 的环境文件,以存储配置。
  2. 在环境文件中包含您的配置。例如:

    resource_registry:
      OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
    parameter_defaults:
      ControllerParameters:
        RhsmVars:
          rhsm_repos:
            - rhel-8-for-x86_64-baseos-eus-rpms
            - rhel-8-for-x86_64-appstream-eus-rpms
            - rhel-8-for-x86_64-highavailability-eus-rpms
            - ansible-2.9-for-rhel-8-x86_64-rpms
            - advanced-virt-for-rhel-8-x86_64-rpms
            - openstack-16.1-for-rhel-8-x86_64-rpms
            - fast-datapath-for-rhel-8-x86_64-rpms
          rhsm_username: "myusername"
          rhsm_password: "p@55w0rd!"
          rhsm_org_id: "1234567"
          rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
          rhsm_method: "portal"
          rhsm_release: 8.2
      ComputeParameters:
        RhsmVars:
          rhsm_repos:
            - rhel-8-for-x86_64-baseos-eus-rpms
            - rhel-8-for-x86_64-appstream-eus-rpms
            - rhel-8-for-x86_64-highavailability-eus-rpms
            - ansible-2.9-for-rhel-8-x86_64-rpms
            - advanced-virt-for-rhel-8-x86_64-rpms
            - openstack-16.1-for-rhel-8-x86_64-rpms
            - fast-datapath-for-rhel-8-x86_64-rpms
          rhsm_username: "myusername"
          rhsm_password: "p@55w0rd!"
          rhsm_org_id: "1234567"
          rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
          rhsm_method: "portal"
          rhsm_release: 8.2
      CephStorageParameters:
        RhsmVars:
          rhsm_repos:
            - rhel-8-for-x86_64-baseos-rpms
            - rhel-8-for-x86_64-appstream-rpms
            - rhel-8-for-x86_64-highavailability-rpms
            - ansible-2.9-for-rhel-8-x86_64-rpms
            - openstack-16.1-deployment-tools-for-rhel-8-x86_64-rpms
          rhsm_username: "myusername"
          rhsm_password: "p@55w0rd!"
          rhsm_org_id: "1234567"
          rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d"
          rhsm_method: "portal"
          rhsm_release: 8.2

    resource_registryrhsm 可组合服务与 OS::TripleO::Services::Rhsm 资源关联,每个角色都可用。

    ControllerParametersComputeParametersCephStorageParameters 参数各自使用单独的 RhsmVars 参数将订阅详情传递给对应的角色。

    注意

    设置 CephStorageParameters 参数中的 RhsmVars 参数,以使用特定于 Ceph Storage 的 Red Hat Ceph Storage 订阅和存储库。确保 rhsm_repos 参数包含标准 Red Hat Enterprise Linux 软件仓库,而不是控制器和 Compute 节点所需的扩展更新支持(EUS)软件仓库。

  3. 保存环境文件。

5.5. 将 overcloud 注册到红帽卫星服务器

创建一个环境文件,它将启用和配置 rhsm 可组合服务,以将节点注册到 Red Hat Satellite 而不是红帽客户门户网站。

流程

  1. 创建名为 templates/rhsm.yml 的环境文件,以存储配置。
  2. 在环境文件中包含您的配置。例如:

    resource_registry:
      OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
    parameter_defaults:
      RhsmVars:
        rhsm_activation_key: "myactivationkey"
        rhsm_method: "satellite"
        rhsm_org_id: "ACME"
        rhsm_server_hostname: "satellite.example.com"
        rhsm_baseurl: "https://satellite.example.com/pulp/repos"
        rhsm_release: 8.2

    resource_registryrhsm 可组合服务与 OS::TripleO::Services::Rhsm 资源关联,每个角色都可用。

    RhsmVars 变量将参数传递给 Ansible,以配置您的红帽注册。

  3. 保存环境文件。

5.6. 切换到 rhsm 可组合服务

之前的 rhel-registration 方法运行一个 bash 脚本来处理 overcloud 注册。此方法的脚本和环境文件位于 /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/ 的核心 heat 模板集合中。

完成以下步骤,从 rhel-registration 方法切换到 rhsm 可组合服务。

流程

  1. 在以后的部署操作中排除 rhel-registration 环境文件。在大多数情况下,排除以下文件:

    • rhel-registration/environment-rhel-registration.yaml
    • rhel-registration/rhel-registration-resource-registry.yaml
  2. 如果您使用自定义 roles_data 文件,请确保 roles_data 文件中的每个角色都包含 OS::TripleO::Services::Rhsm 可组合服务。例如:

    - name: Controller
      description: |
        Controller role that has all the controller services loaded and handles
        Database, Messaging and Network functions.
      CountDefault: 1
      ...
      ServicesDefault:
        ...
        - OS::TripleO::Services::Rhsm
        ...
  3. 为将来的部署操作添加 rhsm 可组合服务参数的环境文件。

此方法将 rhel-registration 参数替换为 rhsm 服务参数,并更改启用服务的 heat 资源:

resource_registry:
  OS::TripleO::NodeExtraConfig: rhel-registration.yaml

改为:

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

您还可以在部署中包含 /usr/share/openstack-tripleo-heat-templates/environments/rhsm.yaml 环境文件来启用该服务。

5.7. rhel-regration 到 rhsm 映射

为了帮助将您的详细信息从 rhel-registration 方法转换为 rhsm 方法,请使用下表来映射您的参数和值。

rhel-registrationrhsm / RhsmVars

rhel_reg_method

rhsm_method

rhel_reg_org

rhsm_org_id

rhel_reg_pool_id

rhsm_pool_ids

rhel_reg_activation_key

rhsm_activation_key

rhel_reg_auto_attach

rhsm_autosubscribe

rhel_reg_sat_url

rhsm_satellite_url

rhel_reg_repos

rhsm_repos

rhel_reg_user

rhsm_username

rhel_reg_password

rhsm_password

rhel_reg_release

rhsm_release

rhel_reg_http_proxy_host

rhsm_rhsm_proxy_hostname

rhel_reg_http_proxy_port

rhsm_rhsm_proxy_port

rhel_reg_http_proxy_username

rhsm_rhsm_proxy_user

rhel_reg_http_proxy_password

rhsm_rhsm_proxy_password

5.8. 使用 rhsm 可组合服务部署 overcloud

使用 rhsm 可组合服务部署 overcloud,以便 Ansible 控制 overcloud 节点的注册过程。

流程

  1. 使用 openstack overcloud deploy 命令包括 rhsm.yml 环境文件:

    openstack overcloud deploy \
        <other cli args> \
        -e ~/templates/rhsm.yaml

    这将启用 overcloud 和基于 Ansible 的注册的 Ansible 配置。

  2. 等待 overcloud 部署完成。
  3. 检查 overcloud 节点上的订阅详情。例如,登录到 Controller 节点并运行以下命令:

    $ sudo subscription-manager status
    $ sudo subscription-manager list --consumed

5.9. 手动运行基于 Ansible 的注册

您可以使用 director 节点上的动态清单脚本在部署的 overcloud 上执行基于 Ansible 的手动注册。使用此脚本将节点角色定义为主机组,然后使用 ansible-playbook 针对它们运行 playbook。使用以下示例 playbook 来手动注册 Controller 节点。

流程

  1. 创建一个 playbook,它使用 redhat_subscription 模块注册您的节点。例如,以下 playbook 适用于 Controller 节点:

    ---
    - name: Register Controller nodes
      hosts: Controller
      become: yes
      vars:
        repos:
          - rhel-8-for-x86_64-baseos-eus-rpms
          - rhel-8-for-x86_64-appstream-eus-rpms
          - rhel-8-for-x86_64-highavailability-eus-rpms
          - ansible-2.9-for-rhel-8-x86_64-rpms
          - openstack-beta-for-rhel-8-x86_64-rpms
          - fast-datapath-for-rhel-8-x86_64-rpms
      tasks:
        - name: Register system
          redhat_subscription:
            username: myusername
            password: p@55w0rd!
            org_id: 1234567
            release: 8.2
            pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
        - name: Disable all repos
          command: "subscription-manager repos --disable *"
        - name: Enable Controller node repos
          command: "subscription-manager repos --enable {{ item }}"
          with_items: "{{ repos }}"
    • 此 play 包含三个任务:

      • 注册节点。
      • 禁用任何启用的软件仓库。
      • 仅启用与 Controller 节点关联的存储库。存储库使用 repos 变量列出。
  2. 部署 overcloud 后,您可以运行以下命令,以便 Ansible 为您的 overcloud 执行 playbook (ansible-osp-registration.yml):

    $ ansible-playbook -i /usr/bin/tripleo-ansible-inventory ansible-osp-registration.yml

    这个命令执行以下操作:

    • 运行动态清单脚本来获取主机及其组的列表。
    • 将 playbook 任务应用到 playbook 的 hosts 参数中定义的节点,本例中为 Controller 组。

第 6 章 可组合服务和自定义角色

overcloud 通常由预定义角色的节点组成,如 Controller 节点、计算节点和不同的存储节点类型。这些默认角色各自包含 director 节点上的核心 heat 模板集合中定义的一组服务。但是,您还可以创建包含特定服务集合的自定义角色。

您可以使用此灵活性在不同的角色上创建不同的服务组合。本章将探讨自定义角色的架构、可组合服务以及使用它们的方法。

6.1. 支持的角色架构

在使用自定义角色和可组合服务时,可以使用以下架构:

默认构架
使用默认的 roles_data 文件。所有控制器服务都包含在一个 Controller 角色中。
支持的独立角色
使用 /usr/share/openstack-tripleo-heat-templates/roles 中的预定义文件来生成自定义 roles_data 文件。更多信息请参阅 第 6.4 节 “支持的自定义角色”
自定义可组合服务
创建自己的角色并使用它们来生成自定义 roles_data 文件。请注意,只有有限的可组合服务组合已被测试并验证,红帽无法支持所有可组合的服务组合。

6.2. 检查 roles_data 文件

roles_data 文件包含 director 部署到节点上的角色的 YAML 格式列表。每个角色都包含构成该角色的所有服务的定义。使用以下示例片段来了解 roles_data 语法:

- name: Controller
  description: |
    Controller role that has all the controller services loaded and handles
    Database, Messaging and Network functions.
  ServicesDefault:
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    ...
- name: Compute
  description: |
    Basic Compute Node role
  ServicesDefault:
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    ...

核心 heat 模板集合包括一个默认的 roles_data 文件,位于 /usr/share/openstack-tripleo-heat-templates/roles_data.yaml。默认文件包含以下角色类型的定义:

  • Controller
  • Compute
  • BlockStorage
  • ObjectStorage
  • Ceph 存储.

在部署过程中,openstack overcloud deploy 命令包含默认的 roles_data.yaml 文件。但是,您可以使用 -r 参数使用自定义 roles_data 文件覆盖此文件:

$ openstack overcloud deploy --templates -r ~/templates/roles_data-custom.yaml

6.3. 创建 roles_data 文件

虽然您可以手动创建自定义 roles_data 文件,但您也可以使用单独的角色模板自动生成 文件。director 提供了几个命令来管理角色模板,并自动生成自定义 roles_data 文件。

流程

  1. 列出默认角色模板:

    $ openstack overcloud roles list
    BlockStorage
    CephStorage
    Compute
    ComputeHCI
    ComputeOvsDpdk
    Controller
    ...
  2. 使用 openstack overcloud roles show 命令查看 YAML 格式的角色定义:

    $ openstack overcloud roles show Compute
  3. 生成自定义 roles_data 文件。使用 openstack overcloud 角色 generate 命令将多个预定义角色加入到一个文件中。例如,运行以下命令生成 roles_data.yaml 文件,该文件包含 Controller, Compute, 和 Networker 角色:

    $ openstack overcloud roles generate -o ~/roles_data.yaml Controller Compute Networker

    使用 -o 选项定义输出文件的名称。

    此命令创建自定义 roles_data 文件。但是,上例使用 ControllerNetworker 角色,这些角色都包含相同的网络代理。这意味着网络服务从 Controller 角色扩展到 Networker 角色,overcloud 在 ControllerNetworker 节点之间平衡网络服务的负载。

    要使这个 Networker 角色独立,您可以创建自己的自定义 Controller 角色,以及您需要的任何其他角色。这样,您可以从自己的自定义角色生成 roles_data 文件。

  4. 将核心 heat 模板集合中的目录复制到 stack 用户的主目录:

    $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
  5. 在此目录中添加或修改自定义角色文件。将 --roles-path 选项与任何角色子命令一起使用,以将此目录用作自定义角色的源:

    $ openstack overcloud roles generate -o my_roles_data.yaml \
      --roles-path ~/roles \
      Controller Compute Networker

    此命令从 ~/roles 目录中的各个角色生成单个 my_roles_data.yaml 文件。

注意

默认角色集合还包含 ControllerOpenStack 角色,该角色不包括 Networker, Messaging, 和 Database 角色的服务。您可以将 ControllerOpenStack 与独立 Networker, Messaging, and Database 角色结合使用。

6.4. 支持的自定义角色

下表包含有关可用自定义角色的信息。您可以在 /usr/share/openstack-tripleo-heat-templates/roles 目录中找到自定义角色模板。

角色描述File

BlockStorage

OpenStack Block Storage (cinder)节点.

BlockStorage.yaml

CephAll

完整的单机 Ceph Storage 节点。包括 OSD、MON、对象网关(RGW)、对象操作(MDS)、管理器(MGR)和 RBD 镜像功能。

CephAll.yaml

CephFile

单机横向扩展 Ceph 存储文件角色.包括 OSD 和对象操作(MDS)。

CephFile.yaml

CephObject

独立横向扩展 Ceph 存储对象角色。包括 OSD 和对象网关(RGW)。

CephObject.yaml

CephStorage

Ceph Storage OSD 节点角色.

CephStorage.yaml

ComputeAlt

备用 Compute 节点角色.

ComputeAlt.yaml

ComputeDVR

DVR 启用 Compute 节点角色。

ComputeDVR.yaml

ComputeHCI

带有超融合基础架构的计算节点。包括计算和 Ceph OSD 服务。

ComputeHCI.yaml

ComputeInstanceHA

计算实例 HA 节点角色.搭配 environments/compute-instanceha.yaml 的环境文件 使用。

ComputeInstanceHA.yaml

ComputeLiquidio

带有 Cavium Liquidio 智能 NIC 的计算节点.

ComputeLiquidio.yaml

ComputeOvsDpdkRT

计算 OVS DPDK RealTime 角色。

ComputeOvsDpdkRT.yaml

ComputeOvsDpdk

计算 OVS DPDK 角色。

ComputeOvsDpdk.yaml

ComputePPC64LE

ppc64le 服务器的计算角色。

ComputePPC64LE.yaml

ComputeRealTime

针对实时行为优化的计算角色。使用此角色时,强制使用 overcloud-realtime-compute 镜像以及特定角色参数 IsolCpusList,NovaComputeCpuDedicatedSetNovaComputeCpuSharedSet 根据实时计算节点的硬件进行设置。

ComputeRealTime.yaml

ComputeSriovRT

计算 SR-IOV RealTime 角色。

ComputeSriovRT.yaml

ComputeSriov

计算 SR-IOV 角色。

ComputeSriov.yaml

Compute

标准 Compute 节点角色.

Compute.yaml

ControllerAllNovaStandalone

没有包含数据库、消息传递、网络和 OpenStack Compute (nova)控制组件的控制器角色。使用 Database, Messaging, Networker, 和Novacontrol 角色的组合。

ControllerAllNovaStandalone.yaml

ControllerNoCeph

载入核心 Controller 服务的控制器角色,但没有 Ceph Storage (MON) 组件。此角色处理数据库、消息传递和网络功能,但不处理任何 Ceph 存储功能。

ControllerNoCeph.yaml

ControllerNovaStandalone

没有包含 OpenStack Compute (nova)控制组件的控制器角色。使用 和 Novacontrol 角色。

ControllerNovaStandalone.yaml

ControllerOpenstack

没有包含数据库、消息传递和网络组件的控制器角色。与 Database, Messaging, 和 Networker 角色结合使用。

ControllerOpenstack.yaml

ControllerStorageNfs

Controller 角色加载了所有核心服务并使用 Ceph NFS。此角色处理数据库、消息传递和网络功能。

ControllerStorageNfs.yaml

Controller

加载所有核心服务的控制器角色。此角色处理数据库、消息传递和网络功能。

Controller.yaml

ControllerSriov (ML2/OVN)

与常规 Controller 角色相同,但部署了 OVN 元数据代理。

ControllerSriov.yaml

数据库

独立数据库角色.使用 Pacemaker 作为 Galera 集群管理的数据库。

database.yaml

HciCephAll

具有超融合基础架构和所有 Ceph Storage 服务的计算节点。包括 OSD、MON、对象网关(RGW)、对象操作(MDS)、管理器(MGR)和 RBD 镜像功能。

HciCephAll.yaml

HciCephFile

具有超融合基础架构和 Ceph Storage 文件服务的计算节点。包括 OSD 和对象操作(MDS)。

HciCephFile.yaml

HciCephMon

具有超融合基础架构和 Ceph Storage 块存储服务的计算节点。包括 OSD、MON 和 Manager。

HciCephMon.yaml

HciCephObject

具有超融合基础架构和 Ceph Storage 对象存储服务的计算节点。包括 OSD 和对象网关(RGW)。

HciCephObject.yaml

IronicConductor

ironic Conductor 节点角色。

IronicConductor.yaml

消息传递

独立消息传递角色.使用 Pacemaker 管理的 RabbitMQ。

messaging.yaml

Networker

独立网络角色.自行运行 OpenStack 网络(neutron)代理。如果您的部署使用了 ML2/OVN 机制驱动程序,请参阅使用 ML2/OVN 部署自定义角色 中的附加步骤。

Networker.yaml

NetworkerSriov

与普通的 Networker 角色相同,但部署了 OVN 元数据代理。请参阅使用 ML2/OVN 部署自定义角色 中的其他步骤。

NetworkerSriov.yaml

Novacontrol

独立 nova-control 角色,用来自行运行 OpenStack Compute (nova)控制代理。

novacontrol.yaml

ObjectStorage

Swift 对象存储节点角色.

ObjectStorage.yaml

Telemetry

具有所有指标和警报服务的 Telemetry 角色。

Telemetry.yaml

6.5. 检查角色参数

每个角色都包含以下参数:

name
(必需) 角色的名称,它是没有空格或特殊字符的纯文本名称。检查所选名称不会导致与其他资源冲突。例如,使用 Networker 作为名称,而不是 Network
description
(可选) 角色纯文本描述。
tags

(可选) 定义角色属性的标签的 YAML 列表。使用此参数定义主角色,带有 controllerprimary 标签:

- name: Controller
  ...
  tags:
    - primary
    - controller
  ...
重要

如果没有标记主要角色,则您定义的第一个角色将成为主要角色。确保此角色是 Controller 角色。

网络

要在角色上配置的网络的 YAML 列表或字典。如果使用 YAML 列表,请列出每个可组合网络:

  networks:
    - External
    - InternalApi
    - Storage
    - StorageMgmt
    - Tenant

如果您使用一个字典,请将每个网络映射到可组合网络中的一个特定的子网

  networks:
    External:
      subnet: external_subnet
    InternalApi:
      subnet: internal_api_subnet
    Storage:
      subnet: storage_subnet
    StorageMgmt:
      subnet: storage_mgmt_subnet
    Tenant:
      subnet: tenant_subnet

默认网络包括 External, InternalApi, Storage, StorageMgmt, Tenant, 和 Management

CountDefault
(可选) 定义您要为此角色部署的默认节点数量。
HostnameFormatDefault

(可选) 定义角色的默认主机名格式。默认命名规则使用以下格式:

[STACK NAME]-[ROLE NAME]-[NODE ID]

例如,默认的 Controller 节点被命名:

overcloud-controller-0
overcloud-controller-1
overcloud-controller-2
...
disable_constraints
(可选) 定义在使用 director 部署时是否禁用 OpenStack Compute (nova)和 OpenStack Image Storage (glance)约束。使用预置备节点部署 overcloud 时请使用此参数。有关更多信息,请参阅 Director 安装和使用 指南中的使用预置备节点配置 基础 Overcloud
update_serial

(可选) 定义在 OpenStack 更新选项中同时要更新的节点数量。在默认的 roles_data.yaml 文件中:

  • 默认为 Controller、Object Storage 和 Ceph Storage 节点的 1
  • Compute 和 Block Storage 节点的默认值为 25

如果从自定义角色省略此参数,则默认为 1

ServicesDefault
(可选) 定义要在节点上包括的服务的默认列表。更多信息请参阅 第 6.8 节 “检查可组合的服务架构”

您可以使用这些参数创建新角色,并定义要包含在您的角色中的服务。

openstack overcloud deploy 命令将 roles_data 文件中的参数集成到一些基于 Jinja2 的模板中。例如,在某些点上,overcloud.j2.yaml heat 模板会迭代 roles_data.yaml 中的角色列表,并创建特定于各个角色的参数和资源。

例如,以下代码片段包含 overcloud.j2.yaml heat 模板中的每个角色的资源定义:

  {{role.name}}:
    type: OS::Heat::ResourceGroup
    depends_on: Networks
    properties:
      count: {get_param: {{role.name}}Count}
      removal_policies: {get_param: {{role.name}}RemovalPolicies}
      resource_def:
        type: OS::TripleO::{{role.name}}
        properties:
          CloudDomain: {get_param: CloudDomain}
          ServiceNetMap: {get_attr: [ServiceNetMap, service_net_map]}
          EndpointMap: {get_attr: [EndpointMap, endpoint_map]}
...

此片段显示基于 Jinja2 的模板如何融合 {{role.name}} 变量,将每个角色的名称定义为 OS::Heat::ResourceGroup 资源。反过来,使用 roles_data 文件中的每个 name 参数来命名每个对应的 OS::Heat::ResourceGroup 资源。

6.6. 创建新角色

您可以使用可组合服务架构,根据部署的要求创建新角色。例如,您可能希望仅创建一个新的 Horizon 角色,以仅托管 OpenStack 控制面板(horizon)。

注意

角色名称必须以字母或数字开头,以字母或数字结尾,仅包含字母、数字和连字符。角色名称不得使用下划线。

流程

  1. 创建 默认角色 目录的自定义副本:

    $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
  2. 创建一个名为 ~/roles/Horizon.yaml 的新文件,并创建一个名为 base 和 core OpenStack Dashboard 服务的新 Horizon 角色:

    - name: Horizon
      CountDefault: 1
      HostnameFormatDefault: '%stackname%-horizon-%index%'
      ServicesDefault:
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::Kernel
        - OS::TripleO::Services::Ntp
        - OS::TripleO::Services::Snmp
        - OS::TripleO::Services::Sshd
        - OS::TripleO::Services::Timezone
        - OS::TripleO::Services::TripleoPackages
        - OS::TripleO::Services::TripleoFirewall
        - OS::TripleO::Services::SensuClient
        - OS::TripleO::Services::FluentdClient
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::Collectd
        - OS::TripleO::Services::MySQLClient
        - OS::TripleO::Services::Apache
        - OS::TripleO::Services::Horizon

    CountDefault 设置为 1,以便默认 overcloud 始终包含 Horizon 节点。

  3. 可选:如果要扩展现有 overcloud 中的服务,请保留 Controller 角色上的现有服务。如果要创建新 overcloud,并且希望 OpenStack 控制面板保持独立角色,请从 Controller 角色定义中删除 OpenStack 控制面板组件:

    - name: Controller
      CountDefault: 1
      ServicesDefault:
        ...
        - OS::TripleO::Services::GnocchiMetricd
        - OS::TripleO::Services::GnocchiStatsd
        - OS::TripleO::Services::HAproxy
        - OS::TripleO::Services::HeatApi
        - OS::TripleO::Services::HeatApiCfn
        - OS::TripleO::Services::HeatApiCloudwatch
        - OS::TripleO::Services::HeatEngine
        # - OS::TripleO::Services::Horizon                # Remove this service
        - OS::TripleO::Services::IronicApi
        - OS::TripleO::Services::IronicConductor
        - OS::TripleO::Services::Iscsid
        - OS::TripleO::Services::Keepalived
        ...
  4. 使用 ~/roles 目录作为源生成新的 roles_data-horizon.yaml 文件:

    $ openstack overcloud roles generate -o roles_data-horizon.yaml \
      --roles-path ~/roles \
      Controller Compute Horizon
  5. 为此角色定义一个新类别,以便您可以标记特定的节点。在本例中,使用以下命令来创建 horizon 类别:

    1. 创建 horizon 类别:

      (undercloud)$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon
      注意

      这些属性不用于调度实例,但计算调度程序将使用磁盘大小来确定根分区大小。

    2. 使用自定义资源类标记您要为 Dashboard 服务(horizon)指定的每个裸机节点:

      (undercloud)$ openstack baremetal node set --resource-class baremetal.HORIZON <NODE>

      <NODE> 替换为裸机节点的 ID。

    3. horizon 类别与自定义资源类关联:

      (undercloud)$ openstack flavor set --property resources:CUSTOM_BAREMETAL_HORIZON=1 horizon

      要确定与裸机节点的资源类对应的自定义资源类的名称,请将资源类转换为大写,将 punctuation 替换为下划线,并为值添加 CUSTOM_

      注意

      类别只能请求一个裸机资源类实例。

    4. 设置以下类别属性,以防止计算调度程序使用裸机类别属性来调度实例:

      (undercloud)$ openstack flavor set --property resources:VCPU=0 --property resources:MEMORY_MB=0 --property resources:DISK_GB=0 horizon
  6. 使用以下环境文件片段定义 Horizon 节点数和类别:

    parameter_defaults:
      OvercloudHorizonFlavor: horizon
      HorizonCount: 1
  7. openstack overcloud deploy 命令中包含新的 roles_data-horizon.yaml 文件和环境文件,以及与部署相关的任何其他环境文件:

    $ openstack overcloud deploy --templates -r ~/templates/roles_data-horizon.yaml -e ~/templates/node-count-flavor.yaml

    此配置会创建一个三节点 overcloud,它由一个 Controller 节点、一个 Compute 节点和一个 Networker 节点组成。要查看 overcloud 中的节点列表,请运行以下命令:

    $ openstack server list

6.7. 指南和限制

请注意可组合角色架构的以下指南和限制。

对于不由 Pacemaker 管理的服务:

  • 您可以将服务分配给独立自定义角色。
  • 您可以在初始部署后创建额外的自定义角色,并将它们部署以扩展现有服务。

对于由 Pacemaker 管理的服务:

  • 您可以将 Pacemaker 管理的服务分配给独立的自定义角色。
  • Pacemaker 有 16 个节点的限制。如果将 Pacemaker 服务(OS::TripleO::Services::Pacemaker)分配给 16 个节点,则后续节点必须使用 Pacemaker 远程服务(OS::TripleO::Services::PacemakerRemote)。您不能在同一角色中使用 Pacemaker 服务和 Pacemaker 远程服务。
  • 在不包含 Pacemaker 管理的服务的角色中,不要将 Pacemaker 服务(OS::TripleO::Services::Pacemaker)包含。
  • 您无法扩展或缩减包含 OS::TripleO::Services::PacemakerOS::TripleO::Services::PacemakerRemote 服务的自定义角色。

常规限制:

  • 您不能在主版本升级过程中更改自定义角色和可组合服务。
  • 在部署 overcloud 后,您无法修改任何角色的服务列表。在 Overcloud 部署后修改服务列表可能会导致部署错误并离开节点上的孤立服务。

6.8. 检查可组合的服务架构

核心 heat 模板集合包含两组可组合服务模板:

  • deployment 包含关键 OpenStack 服务的模板。
  • puppet/services 包含用于配置可组合服务的传统模板。在某些情况下,可组合的服务使用该目录中的模板的兼容性。在大多数情况下,可组合的服务使用 部署 目录中的模板。

每个模板都包含一个标识其用途的描述。例如,Deployment /time/ntp-baremetal-puppet.yaml 服务模板包含以下描述:

description: >
  NTP service deployment using puppet, this YAML file
  creates the interface between the HOT template
  and the puppet manifest that actually installs
  and configure NTP.

这些服务模板是作为特定于 Red Hat OpenStack Platform 部署的资源注册的。这意味着,您可以使用 overcloud-resource-registry-puppet.j2.yaml 文件中定义的唯一 heat 资源命名空间调用各个资源。所有服务都将 OS::TripleO::Services 命名空间用作其资源类型。

有些资源直接使用基本可组合服务模板:

resource_registry:
  ...
  OS::TripleO::Services::Ntp: deployment/time/ntp-baremetal-puppet.yaml
  ...

但是,核心服务需要容器并使用容器化服务模板。例如,keystone 容器化服务使用以下资源:

resource_registry:
  ...
  OS::TripleO::Services::Keystone: deployment/keystone/keystone-container-puppet.yaml
  ...

这些容器化模板通常引用其他模板以包含依赖项。例如,deploy /keystone/keystone-container-puppet.yaml 模板会将基本模板的输出存储在 ContainersCommon 资源中:

resources:
  ContainersCommon:
    type: ../containers-common.yaml

然后,容器化模板可以包含 container -common.yaml 模板中的功能和数据。

overcloud.j2.yaml heat 模板包含 Jinja2 的代码部分,用于在 roles_data.yaml 文件中为每个自定义角色定义一个服务列表:

{{role.name}}Services:
  description: A list of service resources (configured in the heat
               resource_registry) which represent nested stacks
               for each service that should get installed on the {{role.name}} role.
  type: comma_delimited_list
  default: {{role.ServicesDefault|default([])}}

对于默认角色,这将创建以下服务列表参数: ControllerServicesComputeServicesBlockStorageServicesObjectStorageServices、CephStorageServices 和 CephStorageServices

您可以在 roles_data.yaml 文件中为每个自定义角色定义默认服务。例如,默认的 Controller 角色包含以下内容:

- name: Controller
  CountDefault: 1
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Core
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
...

这些服务随后被定义为 ControllerServices 参数的默认列表。

注意

您还可以使用环境文件覆盖服务参数的默认列表。例如,您可以在环境文件中将 ControllerServices 定义为 parameter_default,以覆盖 roles_data.yaml 文件中的服务列表。

6.9. 从角色添加或删除服务

添加或删除服务的基本方法涉及为节点角色创建默认服务列表的副本,然后添加或删除服务。例如,您可能想要从 Controller 节点中删除 OpenStack Orchestration (heat)。

流程

  1. 创建 默认角色 目录的自定义副本:

    $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
  2. 编辑 ~/roles/Controller.yaml 文件并修改 ServicesDefault 参数的服务列表。滚动到 OpenStack 编排服务并删除它们:

        - OS::TripleO::Services::GlanceApi
        - OS::TripleO::Services::GlanceRegistry
        - OS::TripleO::Services::HeatApi            # Remove this service
        - OS::TripleO::Services::HeatApiCfn         # Remove this service
        - OS::TripleO::Services::HeatApiCloudwatch  # Remove this service
        - OS::TripleO::Services::HeatEngine         # Remove this service
        - OS::TripleO::Services::MySQL
        - OS::TripleO::Services::NeutronDhcpAgent
  3. 生成新的 roles_data 文件:

    $ openstack overcloud roles generate -o roles_data-no_heat.yaml \
      --roles-path ~/roles \
      Controller Compute Networker
  4. 在运行 openstack overcloud deploy 命令时包括这个新的 roles_data 文件:

    $ openstack overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml

    此命令在 Controller 节点上安装了 OpenStack Orchestration 服务即可部署 overcloud。

注意

您还可以使用自定义环境文件禁用 roles_data 文件中的服务。重定向服务,以禁用 OS::Heat::None 资源。例如:

resource_registry:
  OS::TripleO::Services::HeatApi: OS::Heat::None
  OS::TripleO::Services::HeatApiCfn: OS::Heat::None
  OS::TripleO::Services::HeatApiCloudwatch: OS::Heat::None
  OS::TripleO::Services::HeatEngine: OS::Heat::None

6.10. 启用禁用的服务

一些服务会被默认禁用。这些服务在 overcloud-resource-registry-puppet.j2.yaml 文件中注册为 null 操作(OS::Heat::None)。例如,块存储备份服务(cinder-backup)被禁用:

  OS::TripleO::Services::CinderBackup: OS::Heat::None

若要启用此服务,可包含一个环境文件,用于将资源链接到 puppet/services 目录中对应的 heat 模板。有些服务在 environment 目录中有预定义的环境文件。例如,块存储备份服务使用 environments/cinder-backup.yaml 文件,该文件包含以下条目:

流程

  1. 在环境文件中添加一个条目,将 CinderBackup 服务链接到包含 cinder-backup 配置的 heat 模板:

    resource_registry:
      OS::TripleO::Services::CinderBackup: ../podman/services/pacemaker/cinder-backup.yaml
    ...

    此条目覆盖默认的 null 操作资源并启用服务。

  2. 在运行 openstack overcloud deploy 命令时包括此环境文件:

    $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml

6.11. 创建没有服务的通用节点

您可以在不配置任何 OpenStack 服务的情况下创建通用 Red Hat Enterprise Linux 8.2 节点。当您需要托管核心 Red Hat OpenStack Platform (RHOSP)环境之外的软件时,这非常有用。例如,RHOSP 提供与 Kibana 和 Sensu 等监控工具的集成。如需更多信息,请参阅《 监控工具配置指南》。虽然红帽不提供对监控工具本身的支持,但 director 可以创建通用 Red Hat Enterprise Linux 8.2 节点来托管这些工具。

注意

通用节点仍然使用基本 overcloud-full 镜像,而不是基本 Red Hat Enterprise Linux 8 镜像。这意味着该节点已安装一些 Red Hat OpenStack Platform 软件,但没有启用或配置。

流程

  1. 在自定义 roles_data.yaml 文件中创建一个通用角色,它不包含 ServicesDefault 列表:

    - name: Generic
    - name: Controller
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephClient
        ...
    - name: Compute
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephClient
        ...

    确保保留现有的 ControllerCompute 角色。

  2. 创建环境文件 generic-node-params.yaml,以指定在选择要置备节点时所需的通用 Red Hat Enterprise Linux 8 节点数量:

    parameter_defaults:
      OvercloudGenericFlavor: baremetal
      GenericCount: 1
  3. 在运行 openstack overcloud deploy 命令时同时包含角色文件和环境文件:

    $ openstack overcloud deploy --templates \
    -r ~/templates/roles_data_with_generic.yaml \
    -e ~/templates/generic-node-params.yaml

    此配置部署一个包含一个 Controller 节点、一个 Compute 节点和一个通用 Red Hat Enterprise Linux 8 节点的三节点环境。

第 7 章 容器化服务

director 将核心 OpenStack Platform 服务安装为 overcloud 上的容器。本节提供了一些有关容器化服务如何工作的背景信息。

7.1. 容器化服务架构

director 将核心 OpenStack Platform 服务安装为 overcloud 上的容器。容器化服务的模板位于 /usr/share/openstack-tripleo-heat-templates/deployment/ 中。

您必须在角色中为使用容器化服务的所有节点启用 OS::TripleO::Services::Podman 服务。当您为自定义角色配置创建 roles_data.yaml 文件时,请将 OS::TripleO::Services::Podman 服务与基本可组合服务一起包含。例如,IronicConductor 角色使用以下角色定义:

- name: IronicConductor
  description: |
    Ironic Conductor node role
  networks:
    InternalApi:
      subnet: internal_api_subnet
    Storage:
      subnet: storage_subnet
  HostnameFormatDefault: '%stackname%-ironic-%index%'
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::BootParams
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CertmongerUser
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Fluentd
    - OS::TripleO::Services::IpaClient
    - OS::TripleO::Services::Ipsec
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::IronicPxe
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::MetricsQdr
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::Podman
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timesync
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Tuned

7.2. 容器化服务参数

每个容器化服务模板包含一个 outputs 部分,用于定义传递给 OpenStack Orchestration (heat)服务的数据集。除了标准可组合服务参数外,模板还包含一组特定于容器配置的参数。第 6.5 节 “检查角色参数”

puppet_config

配置服务时要传递给 Puppet 的数据。在初始 overcloud 部署步骤中,director 会创建一组容器,用于在实际的容器化服务运行之前配置该服务。此参数包括以下子参数:

  • config_volume - 存储配置的挂载卷。
  • puppet_tags - 在配置期间传递给 Puppet 的标签。OpenStack 使用这些标签将 Puppet 运行限制为特定服务的配置资源。例如,OpenStack Identity (keystone)容器化服务使用 keystone_config 标签来确保所有需要 keystone_config Puppet 资源在配置容器上运行。
  • step_config - 传递给 Puppet 的配置数据。这通常继承自引用的可组合服务。
  • config_image - 用于配置该服务的容器镜像。
kolla_config
组特定于容器的数据,用于定义配置文件位置、目录权限以及要在容器上运行的 命令来启动服务。
docker_config

为该服务在配置容器上运行的任务。所有任务都分组为以下步骤,以帮助 director 执行暂存部署:

  • 第 1 步 - 负载均衡器配置
  • 第 2 步 - 核心服务(Database、Redis)
  • 第 3 步 - OpenStack Platform 服务的初始配置
  • 第 4 步 - 通用 OpenStack Platform 服务配置
  • 第 5 步 - 服务激活
host_prep_tasks
为裸机节点准备任务以容纳容器化服务。

7.3. 准备容器镜像

overcloud 安装需要一个环境文件来确定获取容器镜像的位置以及如何存储它们。生成并自定义此环境文件,您可以使用这个文件准备容器镜像。

注意

如果需要为 overcloud 配置特定的容器镜像版本,您必须将镜像固定到特定的版本。如需更多信息,请参阅获取 overcloud 的容器镜像

流程

  1. stack 用户身份登录 undercloud 主机。
  2. 生成默认的容器镜像准备文件:

    $ sudo openstack tripleo container image prepare default \
      --local-push-destination \
      --output-env-file containers-prepare-parameter.yaml

    此命令包括以下附加选项:

    • --local-push-destination,在 undercloud 上设置 registry 作为存储容器镜像的位置。这意味着 director 从 Red Hat Container Catalog 拉取必要的镜像并将其推送到 undercloud 上的 registry 中。director 将该 registry 用作容器镜像源。如果直接从 Red Hat Container Catalog 拉取镜像,请忽略这个选项。
    • --output-env-file 是环境文件名称。此文件的内容包括用于准备您的容器镜像的参数。在本例中,文件的名称是 containers-prepare-parameter.yaml

      注意

      您可以使用相同的 containers-prepare-parameter.yaml 文件为 undercloud 和 overcloud 定义容器镜像源。

  3. 修改 containers-prepare-parameter.yaml 以符合您的需求。

7.4. 容器镜像准备参数

用于准备您的容器的默认文件 (containers-prepare-parameter.yaml) 包含 ContainerImagePrepare heat 参数。此参数定义一个用于准备一系列镜像的策略列表:

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ...

每一策略接受一组子参数,它们定义要使用哪些镜像以及对这些镜像执行哪些操作。下表包含有关您可与每个 ContainerImagePrepare 策略配合使用的子参数的信息:

参数描述

excludes

用于从策略中排除镜像名称的正则表达式列表。

includes

用于在策略中包含的正则表达式列表。至少一个镜像名称必须与现有镜像匹配。如果指定了 includes,将忽略所有 excludes

modify_append_tag

要附加到目标镜像标签的字符串。例如,如果使用标签 16.1.3-5.161 拉取镜像并将 modify_append_tag 设置为 -hotfix,director 会将最终镜像标记为 16.1.3-5.161-hotfix。

modify_only_with_labels

过滤想要修改的镜像的镜像标签字典。如果镜像与定义的标签匹配,则 director 将该镜像包括在修改过程中。

modify_role

在上传期间但在将镜像推送到目标 registry 之前运行的 ansible 角色名称字符串。

modify_vars

要传递给 modify_role 的变量的字典。

push_destination

定义用于在上传过程中要将镜像推送到的 registry 的命名空间。

  • 如果设为 true,则使用主机名将 push_destination 设置为 undercloud registry 命名空间,这是建议的方法。
  • 如果设置为 false,则不会推送到本地 registry,节点直接从源拉取镜像。
  • 如果设置为自定义值,则 director 将镜像推送到外部本地 registry。

当直接从 Red Hat Container Catalog 拉取镜像时,如果在生产环境中将此参数设置为 false,则所有 overcloud 节点都将通过外部连接同时从 Red Hat Container Catalog 拉取镜像,这可能会导致出现带宽问题。仅使用 false 直接从托管容器镜像的 Red Hat Satellite Server 拉取。

如果 push_destination 参数设置为 false 或未定义,且远程 registry 需要身份验证,请将 ContainerImageRegistryLogin 参数设置为 true,并使用 ContainerImageRegistryCredentials 参数包含凭据。

pull_source

从中拉取原始容器镜像的源 registry 。

set

用于定义从何处获取初始镜像的 key: value 定义的字典。

tag_from_label

使用指定容器镜像元数据标签的值为每个镜像创建标签,并拉取该标记的镜像。例如,如果设置了 tag_from_label: {version}-{release},则 director 会使用 versionrelease 标签来构造新标签。对于一个容器,版本 可能被设置为 16.1.3,发行版本 可能被设置为 5.161,这会导致标签 16.1.3-5.161。仅当未在 set 字典中定义 tag 时,director 才使用此参数。

重要

将镜像推送到 undercloud 时,请使用 push_destination: true 而不是 push_destination: UNDERCLOUD_IP:PORTpush_destination: true 方法在 IPv4 和 IPv6 地址之间提供了一定程度的一致性。

set 参数接受一组 key: value 定义:

描述

ceph_image

Ceph Storage 容器镜像的名称。

ceph_namespace

Ceph Storage 容器镜像的命名空间。

ceph_tag

Ceph Storage 容器镜像的标签。

ceph_alertmanager_image

ceph_alertmanager_namespace

ceph_alertmanager_tag

Ceph Storage Alert Manager 容器镜像的名称、命名空间和标签。

ceph_grafana_image

ceph_grafana_namespace

ceph_grafana_tag

Ceph Storage Grafana 容器镜像的名称、命名空间和标签。

ceph_node_exporter_image

ceph_node_exporter_namespace

ceph_node_exporter_tag

Ceph Storage 节点导出器容器镜像的名称、命名空间和标签。

ceph_prometheus_image

ceph_prometheus_namespace

ceph_prometheus_tag

Ceph Storage Prometheus 容器镜像的名称、命名空间和标签。

name_prefix

各个 OpenStack 服务镜像的前缀。

name_suffix

各个 OpenStack 服务镜像的后缀。

namespace

各个 OpenStack 服务镜像的命名空间。

neutron_driver

用于确定要使用的 OpenStack Networking (neutron) 容器的驱动程序。null 值代表使用标准的 neutron-server 容器。设为 ovn 可使用基于 OVN 的容器。

tag

为来自源的所有镜像设置特定的标签。如果没有定义,director 将 Red Hat OpenStack Platform 版本号用作默认值。此参数优先于 tag_from_label 值。

注意

容器镜像使用基于 Red Hat OpenStack Platform 版本的多流标签。这意味着不再有 latest 标签。

7.5. 容器镜像标记准则

Red Hat Container Registry 使用特定的版本格式来标记所有 Red Hat OpenStack Platform 容器镜像。此格式遵循每个容器的标签元数据,即 version-release

version
对应于 Red Hat OpenStack Platform 的主要和次要版本。这些版本充当包含一个或多个发行版本的流。
release
对应于版本流中特定容器镜像版本的发行版本。

例如,如果 Red Hat OpenStack Platform 的最新版本为 16.1.3,且容器镜像的发行版本为 5.161,则生成的容器镜像标签为 16.1.3-5.161。

Red Hat Container Registry 还使用一组主要和次要 version 标签,链接到该容器镜像版本的最新发行版本。例如,16.1 和 16.1.3 链接到 16.1.3 容器流中的最新 版本。如果出现 16.1 的新次要发行版本,16.1 标签链接到新次要发行版本流的最新 release,而 16.1.3 标签则继续链接到 16.1.3 流中的最新 release

ContainerImagePrepare 参数包含两个子参数,可用于确定要下载的容器镜像。这些子参数是 set 字典中的 tag 参数,以及 tag_from_label 参数。使用以下准则来确定要使用 tag 还是 tag_from_label

  • tag 的默认值是您的 OpenStack Platform 版本的主要版本。对于此版本,它是 16.1。这始终对应于最新的次要版本和发行版本。

    parameter_defaults:
      ContainerImagePrepare:
      - set:
          ...
          tag: 16.1
          ...
  • 要更改为 OpenStack Platform 容器镜像的特定次要版本,请将标签设置为次要版本。例如,要更改为 16.1.2,将 tag 设置为 16.1.2。

    parameter_defaults:
      ContainerImagePrepare:
      - set:
          ...
          tag: 16.1.2
          ...
  • 在设置 tag 时,director 始终会在安装和更新期间下载 tag 中设置的版本的最新容器镜像 release
  • 如果没有设置 tag,则 director 会结合使用 tag_from_label 的值和最新的主要版本。

    parameter_defaults:
      ContainerImagePrepare:
      - set:
          ...
          # tag: 16.1
          ...
        tag_from_label: '{version}-{release}'
  • tag_from_label 参数根据其从 Red Hat Container Registry 中检查到的最新容器镜像发行版本的标签元数据生成标签。例如,特定容器的标签可能会使用以下 versionrelease 元数据:

      "Labels": {
        "release": "5.161",
        "version": "16.1.3",
        ...
      }
  • tag_from_label 的默认值为 {version}-{release},对应于每个容器镜像的版本和发行版本元数据标签。例如,如果容器镜像 在版本 设置了 16.1.3,为 版本 设置了 5.161,则生成的容器镜像标签为 16.1.3-5.161。
  • tag 参数始终优先于 tag_from_label 参数。要使用 tag_from_label,在容器准备配置中省略 tag 参数。
  • tagtag_from_label 之间的一个关键区别是:director 仅基于主要或次要版本标签使用 tag 拉取镜像,Red Hat Container Registry 将这些标签链接到版本流中的最新镜像发行版本,而 director 使用 tag_from_label 对每个容器镜像执行元数据检查,以便 director 生成标签并拉取对应的镜像。

7.6. 从私有 registry 获取容器镜像

registry.redhat.io registry 需要身份验证才能访问和拉取镜像。要通过 registry.redhat.io 和其他私有 registry 进行身份验证,请在 containers-prepare-parameter.yaml 文件中包括 ContainerImageRegistryCredentialsContainerImageRegistryLogin 参数。

ContainerImageRegistryCredentials

有些容器镜像 registry 需要进行身份验证才能访问镜像。在这种情况下,请使用您的 containers-prepare-parameter.yaml 环境文件中的 ContainerImageRegistryCredentials 参数。ContainerImageRegistryCredentials 参数使用一组基于私有 registry URL 的键。每个私有 registry URL 使用其自己的键和值对定义用户名(键)和密码(值)。这提供了一种为多个私有 registry 指定凭据的方法。

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      my_username: my_password

在示例中,用身份验证凭据替换 my_usernamemy_password。红帽建议创建一个 registry 服务帐户并使用这些凭据访问 registry.redhat.io 内容,而不使用您的个人用户凭据。

要指定多个 registry 的身份验证详情,请在 ContainerImageRegistryCredentials 中为每个 registry 设置多个键对值:

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  - push_destination: true
    set:
      namespace: registry.internalsite.com/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
    registry.internalsite.com:
      myuser2: '0th3rp@55w0rd!'
    '192.0.2.1:8787':
      myuser3: '@n0th3rp@55w0rd!'
重要

默认 ContainerImagePrepare 参数从需要进行身份验证的 registry.redhat.io 拉取容器镜像。

如需更多信息,请参阅 Red Hat Container Registry 身份验证

ContainerImageRegistryLogin

ContainerImageRegistryLogin 参数用于控制 overcloud 节点系统是否需要登录到远程 registry 来获取容器镜像。当您想让 overcloud 节点直接拉取镜像,而不是使用 undercloud 托管镜像时,会出现这种情况。

如果 push_destination 设置为 false 或未用于给定策略,则必须将 ContainerImageRegistryLogin 设置为 true

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: false
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: true

但是,如果 overcloud 节点没有与 ContainerImageRegistryCredentials 中定义的 registry 主机的网络连接,并将此 ContainerImageRegistryLogin 设置为 true,则尝试进行登录时部署可能会失败。如果 overcloud 节点没有与 ContainerImageRegistryCredentials 中定义的 registry 主机的网络连接,请将 push_destination 设置为 true,将 ContainerImageRegistryLogin 设置为 false,以便 overcloud 节点从 undercloud 拉取镜像。

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: false

7.7. 分层镜像准备条目

ContainerImagePrepare 参数的值是一个 YAML 列表。这意味着您可以指定多个条目。以下示例演示了两个条目,director 使用所有镜像的最新版本,nova-api 镜像除外,该镜像使用标记为 16.2-44 的版本:

ContainerImagePrepare:
- tag_from_label: "{version}-{release}"
  push_destination: true
  excludes:
  - nova-api
  set:
    namespace: registry.redhat.io/rhosp-rhel8
    name_prefix: openstack-
    name_suffix: ''
- push_destination: true
  includes:
  - nova-api
  set:
    namespace: registry.redhat.io/rhosp-rhel8
    tag: 16.2-44

includesexcludes 参数使用正则表达式来控制每个条目的镜像筛选。匹配 includes 策略的镜像的优先级高于 excludes 匹配项。镜像名称必须包括 includesexcludes 正则表达式值才被认为匹配。

7.8. 准备期间修改镜像

可在准备镜像期间修改镜像,然后立即使用修改的镜像部署 overcloud。

注意

Red Hat OpenStack Platform (RHOSP) Director 支持在准备 RHOSP 容器(而非 Ceph 容器)期间修改镜像。

修改镜像的情况包括:

  • 作为连续集成管道的一个部分,在部署之前使用要测试的更改修改镜像。
  • 作为开发工作流的一个部分,必须部署本地更改以进行测试和开发。
  • 必须部署更改,但更改没有通过镜像构建管道提供。例如,添加专有附加组件或紧急修复。

要在准备期间修改镜像,可在您要修改的每个镜像上调用 Ansible 角色。该角色提取源镜像,进行请求的更改,并标记结果。准备命令可将镜像推送到目标 registry,并设置 heat 参数以引用修改的镜像。

Ansible 角色 tripleo-modify-image 与所需的角色接口相一致,并提供修改用例必需的行为。使用 ContainerImagePrepare 参数中与修改相关的键控制修改:

  • modify_role 指定要为每个镜像调用的 Ansible 角色进行修改。
  • modify_append_tag 将字符串附加到源镜像标签的末尾。这可以标明生成的镜像已被修改过。如果 push_destination registry 已包含修改的镜像,则使用此参数跳过修改。在每次修改镜像时都更改 modify_append_tag
  • modify_vars 是要传递给角色的 Ansible 变量的字典。

要选择 tripleo-modify-image 角色处理的用例,将 tasks_from 变量设置为该角色中所需的文件。

在开发和测试修改镜像的 ContainerImagePrepare 条目时,运行镜像准备命令(无需任何其他选项),以确认镜像已如期修改:

sudo openstack tripleo container image prepare \
  -e ~/containers-prepare-parameter.yaml
重要

要使用 openstack tripleo container image prepare 命令,您的 undercloud 必须包含一个正在运行的 image-serve registry。这样,在新的 undercloud 安装之前您将无法运行此命令,因为 image-serve registry 将不会被安装。您可以在成功安装 undercloud 后运行此命令。

7.9. 更新容器镜像的现有软件包

注意

Red Hat OpenStack Platform (RHOSP) director 支持更新 RHOSP 容器的容器镜像上的现有软件包,不适用于 Ceph 容器。

步骤

  • 以下示例 ContainerImagePrepare 条目使用 undercloud 主机的 dnf 软件仓库配置在容器镜像的所有软件包中更新:

    ContainerImagePrepare:
    - push_destination: true
      ...
      modify_role: tripleo-modify-image
      modify_append_tag: "-updated"
      modify_vars:
        tasks_from: yum_update.yml
        compare_host_packages: true
        yum_repos_dir_path: /etc/yum.repos.d
      ...

7.10. 将额外的 RPM 文件安装到容器镜像中

您可以在容器镜像中安装 RPM 文件的目录。这对安装修补程序、本地软件包内部版本或任何通过软件包仓库无法获取的软件包都非常有用。

注意

Red Hat OpenStack Platform (RHOSP) Director 支持将额外的 RPM 文件安装到 RHOSP 容器的容器镜像,而不是 Ceph 容器。

步骤

  • 以下示例 ContainerImagePrepare 条目仅在 nova-compute 镜像上安装一些热修复软件包:

    ContainerImagePrepare:
    - push_destination: true
      ...
      includes:
      - nova-compute
      modify_role: tripleo-modify-image
      modify_append_tag: "-hotfix"
      modify_vars:
        tasks_from: rpm_install.yml
        rpms_path: /home/stack/nova-hotfix-pkgs
      ...

7.11. 通过自定义 Dockerfile 修改容器镜像

您可以指定包含 Dockerfile 的目录,以进行必要的更改。调用 tripleo-modify-image 角色时,该角色生成 Dockerfile.modified 文件,而该文件更改 FROM 指令并添加额外的 LABEL 指令。

注意

Red Hat OpenStack Platform (RHOSP) Director 支持使用 RHOSP 容器(而非 Ceph 容器)的自定义 Dockerfile 修改容器镜像。

步骤

  1. 以下示例在 nova-compute 镜像上运行自定义 Dockerfile:

    ContainerImagePrepare:
    - push_destination: true
      ...
      includes:
      - nova-compute
      modify_role: tripleo-modify-image
      modify_append_tag: "-hotfix"
      modify_vars:
        tasks_from: modify_image.yml
        modify_dir_path: /home/stack/nova-custom
      ...
  2. 以下示例显示了 /home/stack/nova-custom/Dockerfile 文件。运行任何 USER 根指令后,必须切换回原始镜像默认用户:

    FROM registry.redhat.io/rhosp-rhel8/openstack-nova-compute:latest
    
    USER "root"
    
    COPY customize.sh /tmp/
    RUN /tmp/customize.sh
    
    USER "nova"

7.12. 部署供应商插件

要将某些第三方硬件用作块存储后端,您必须部署供应商插件。以下示例演示了如何部署供应商插件以使用 Dell EMC 硬件作为块存储后端。

有关支持的后端设备和驱动程序的更多信息,请参阅 存储指南中的第三方存储提供程序

流程

  1. 为您的 overcloud 创建新的容器镜像文件:

    $ sudo openstack tripleo container image prepare default \
        --local-push-destination \
        --output-env-file containers-prepare-parameter-dellemc.yaml
  2. 编辑 containers-prepare-parameter-dellemc.yaml 文件。
  3. 为主 Red Hat OpenStack Platform 容器镜像的策略添加 exclude 参数。使用此参数排除供应商容器镜像要替换的容器镜像。在示例中,容器镜像是 cinder-volume 镜像:

    parameter_defaults:
      ContainerImagePrepare:
        - push_destination: true
          excludes:
      	   - cinder-volume
          set:
            namespace: registry.redhat.io/rhosp-rhel8
            name_prefix: openstack-
            name_suffix: ''
            tag: 16.1
            ...
          tag_from_label: "{version}-{release}"
  4. ContainerImagePrepare 参数中添加包含 vendor 插件替换容器镜像的新策略:

    parameter_defaults:
      ContainerImagePrepare:
        ...
        - push_destination: true
          includes:
            - cinder-volume
          set:
            namespace: registry.connect.redhat.com/dellemc
            name_prefix: openstack-
            name_suffix: -dellemc-rhosp16
            tag: 16.1-2
            ...
  5. 将 registry.connect.redhat.com registry 的身份验证详情添加到 ContainerImageRegistryCredentials 参数中:

    parameter_defaults:
      ContainerImageRegistryCredentials:
        registry.redhat.io:
          [service account username]: [service account password]
        registry.connect.redhat.com:
          [service account username]: [service account password]
  6. 保存 containers-prepare-parameter-dellemc.yaml 文件。
  7. 使用任何部署命令(如 openstack overcloud deploy )包含 containers-prepare-parameter-dellemc.yaml 文件:

    $ openstack overcloud deploy --templates
        ...
        -e containers-prepare-parameter-dellemc.yaml
        ...

    当 director 部署 overcloud 时,overcloud 使用厂商容器镜像而不是标准容器镜像。

    重要
    containers-prepare-parameter-dellemc.yaml 文件替换了 overcloud 部署中的标准 containers-prepare-parameter.yaml 文件。不要在 overcloud 部署中包含标准 containers-prepare-parameter.yaml 文件。为您的 undercloud 安装和更新保留标准 containers-prepare-parameter.yaml 文件。

第 8 章 基本网络隔离

将 overcloud 配置为使用隔离的网络,以便您可以隔离托管特定类型的网络流量。Red Hat OpenStack Platform (RHOSP)包括一组可用于配置此网络隔离的环境文件。您可能还需要额外的环境文件来进一步自定义网络参数:

  • 此环境文件可用于启用网络隔离(/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml)。

    注意

    在使用 director 部署 RHOSP 之前,network-isolation.yamlnetwork-environment.yaml 文件只适用于 Jinja2 格式,并具有 .j2.yaml 扩展。director 会在部署过程中为 .yaml 版本呈现这些文件。

  • 可用于配置网络默认值(/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml的环境文件。
  • 您可以使用 network_data 文件来定义网络设置,如 IP 范围、子网和虚拟 IP。本例演示了如何创建默认副本并编辑它以适应您自己的网络。
  • 可以用来为每个节点定义 NIC 布局的模板。overcloud 核心模板集合包含一组用于不同用例的默认值。
  • 用于启用 NIC 的环境文件。本例使用位于 环境 目录中的默认 文件。

8.1. 网络隔离

overcloud 默认为 provisioning 网络分配服务。但是,director 可以将 overcloud 网络流量划分为隔离的网络。要使用隔离的网络,overcloud 包含可启用此功能的环境文件。核心 heat 模板中的 environments/network-isolation.j2.yaml 文件是一个 Jinja2 文件,该文件在可组合网络文件中为每个网络定义所有端口和 VIP。在呈现时,它会使用完整资源 registry 在同一位置生成一个 network-isolation.yaml 文件:

resource_registry:
  # networks as defined in network_data.yaml
  OS::TripleO::Network::Storage: ../network/storage.yaml
  OS::TripleO::Network::StorageMgmt: ../network/storage_mgmt.yaml
  OS::TripleO::Network::InternalApi: ../network/internal_api.yaml
  OS::TripleO::Network::Tenant: ../network/tenant.yaml
  OS::TripleO::Network::External: ../network/external.yaml

  # Port assignments for the VIPs
  OS::TripleO::Network::Ports::StorageVipPort: ../network/ports/storage.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: ../network/ports/storage_mgmt.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: ../network/ports/internal_api.yaml
  OS::TripleO::Network::Ports::ExternalVipPort: ../network/ports/external.yaml
  OS::TripleO::Network::Ports::RedisVipPort: ../network/ports/vip.yaml

  # Port assignments by role, edit role definition to assign networks to roles.
  # Port assignments for the Controller
  OS::TripleO::Controller::Ports::StoragePort: ../network/ports/storage.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: ../network/ports/storage_mgmt.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: ../network/ports/internal_api.yaml
  OS::TripleO::Controller::Ports::TenantPort: ../network/ports/tenant.yaml
  OS::TripleO::Controller::Ports::ExternalPort: ../network/ports/external.yaml

  # Port assignments for the Compute
  OS::TripleO::Compute::Ports::StoragePort: ../network/ports/storage.yaml
  OS::TripleO::Compute::Ports::InternalApiPort: ../network/ports/internal_api.yaml
  OS::TripleO::Compute::Ports::TenantPort: ../network/ports/tenant.yaml

  # Port assignments for the CephStorage
  OS::TripleO::CephStorage::Ports::StoragePort: ../network/ports/storage.yaml
  OS::TripleO::CephStorage::Ports::StorageMgmtPort: ../network/ports/storage_mgmt.yaml

此文件的第一部分具有 OS::TripleO::Network::* 资源的资源 registry 声明。默认情况下,这些资源使用 OS::Heat::None 资源类型,这不会创建任何网络。通过将这些资源重定向到每个网络的 YAML 文件,您可以启用创建这些网络。

接下来的几个部分为每个角色中的节点创建 IP 地址。控制器节点在每个网络上都有 IP。计算和存储节点,各自在网络子集中都有 IP。

overcloud 网络的其他功能,如 第 9 章 自定义可组合网络第 10 章 自定义网络接口模板 依赖于 network-isolation.yaml 环境文件。因此,您必须在部署命令中包括渲染的环境文件:

$ openstack overcloud deploy --templates \
    ...
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    ...

8.2. 修改隔离的网络配置

复制默认 network_data.yaml 文件,并修改副本来配置默认隔离网络。

流程

  1. 复制默认 network_data.yaml 文件:

    $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
  2. 编辑 network_data.yaml 文件的本地副本,并修改参数以符合您的网络要求。例如,内部 API 网络包含以下默认网络详情:

    - name: InternalApi
      name_lower: internal_api
      vip: true
      vlan: 201
      ip_subnet: '172.16.2.0/24'
      allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}]

编辑每个网络的以下值:

  • vlan 定义这个网络要使用的 VLAN ID。
  • ip_subnetip_allocation_pools 为网络设置默认子网和 IP 范围。
  • 网关 设置网络的网关。使用这个值为外部网络定义默认路由,或根据需要为其他网络定义默认路由。

使用 -n 选项,将自定义 network_data.yaml 文件包含在您的部署中。如果没有 -n 选项,部署命令将使用默认网络详细信息。

8.3. 网络接口模板

overcloud 网络配置需要一组网络接口模板。这些模板是采用 YAML 格式的标准 heat 模板。每个角色都需要一个 NIC 模板,以便 director 能够正确配置该角色内的每个节点。

所有 NIC 模板都包含与标准 heat 模板相同的部分:

heat_template_version
要使用的语法版本。
description
模板的字符串描述。
parameters
要在模板中包括的网络参数。
资源
取参数中定义的 参数 并将其应用到网络配置脚本。
输出
呈现用于配置的最终脚本。

/usr/share/openstack-tripleo-heat-templates/network/config 中的默认 NIC 模板使用 Jinja2 语法渲染模板。例如,以下片段来自 single-nic-vlans 配置中为每个网络呈现一组 VLAN:

{%- for network in networks if network.enabled|default(true) and network.name in role.networks %}
- type: vlan
  vlan_id:
    get_param: {{network.name}}NetworkVlanID
  addresses:
  - ip_netmask:
      get_param: {{network.name}}IpSubnet
{%- if network.name in role.default_route_networks %}

对于默认 Compute 节点,这只呈现存储、内部 API 和租户网络的网络信息:

- type: vlan
  vlan_id:
    get_param: StorageNetworkVlanID
  device: bridge_name
  addresses:
  - ip_netmask:
      get_param: StorageIpSubnet
- type: vlan
  vlan_id:
    get_param: InternalApiNetworkVlanID
  device: bridge_name
  addresses:
  - ip_netmask:
      get_param: InternalApiIpSubnet
- type: vlan
  vlan_id:
    get_param: TenantNetworkVlanID
  device: bridge_name
  addresses:
  - ip_netmask:
      get_param: TenantIpSubnet

第 10 章 自定义网络接口模板 探索如何将默认 Jinja2 的模板呈现为标准 YAML 版本,您可以用作自定义基础。

8.4. 默认网络接口模板

director 包含 /usr/share/openstack-tripleo-heat-templates/network/config/ 中的模板,以适应最常见的网络场景。下表概述了每个 NIC 模板集以及您必须用来启用模板所需的相应环境文件。

注意

启用 NIC 模板的每个环境文件都使用后缀 .j2.yaml。这是未发送的 Jinja2 版本。确保在部署中包括使用 .yaml 后缀的 rendered 文件名。

NIC 目录Description环境文件

single-nic-vlans

带有附加到默认 Open vSwitch 网桥的 control plane 和 VLAN 的单个 NIC (nic1)。

environments/net-single-nic-with-vlans.j2.yaml

single-nic-linux-bridge-vlans

带有附加到默认 Linux 网桥的 control plane 和 VLAN 的单个 NIC (nic1)。

environments/net-single-nic-linux-bridge-with-vlans

bond-with-vlans

附加至 nic1 的 control plane。默认 Open vSwitch 网桥带有绑定的 NIC 配置(nic2nic3)并附加了 VLAN。

environments/net-bond-with-vlans.yaml

multiple-nics

附加至 nic1 的 control plane。将每个后续 NIC 分配给 network_data.yaml 文件中定义的每个网络。默认情况下,Storage 到 nic2, Storage Management 到 nic3, Internal API 到 nic4, Tenant 到 br-tenant 网桥上的 nic5,External 到默认 Open vSwitch 网桥上的 nic6

environments/net-multiple-nics.yaml

注意

在没有外部网络的情况下部署 overcloud 的环境文件,如 net-bond-with-vlans-no-external.yaml,对于 IPv6 部署,如 net-bond-with-vlans-v6.yaml。它们可用于向后兼容,且无法与可组合网络运行。

每个默认 NIC 模板集都包含 role.role.j2.yaml 模板。此文件使用 Jinja2 为每一个可组合角色呈现其他文件。例如,如果您的 overcloud 使用 Compute、Controller 和 Ceph Storage 角色,则部署会根据 role.role.j2.yaml 呈现新的模板,如以下模板:

  • compute.yaml
  • controller.yaml
  • ceph-storage.yaml

8.5. 启用基本网络隔离

director 包括可用于启用基本网络隔离的模板。这些文件位于 /usr/share/openstack-tripleo-heat-templates/environments directoy 中。例如,您可以使用模板在具有基本网络隔离的 VLAN 的单一 NIC 上部署 overcloud。在这种情况下,使用 net-single-nic-with-vlans 模板。

流程

  1. 运行 openstack overcloud deploy 命令时,请确保包含以下渲染的环境文件:

    • 自定义 network_data.yaml 文件。
    • 默认网络隔离文件的呈现文件名。
    • 默认网络环境文件的呈现文件名。
    • 默认网络接口配置文件的呈现文件名。
    • 任何与您配置相关的额外环境文件。

例如:

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
    ...

第 9 章 自定义可组合网络

如果要在不同网络上托管特定网络流量,您可以创建自定义可组合网络。要使用额外可组合网络配置 overcloud,您必须配置以下文件和模板:

  • 启用网络隔离的环境文件(/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml)。
  • 用于配置网络默认值的环境文件(/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml)。
  • 自定义 network_data 文件,可在默认值外创建额外网络。
  • 个自定义 roles_data 文件,用于将自定义网络分配给角色。
  • 为各个节点定义 NIC 布局的模板。overcloud 核心模板集合包含一组用于不同用例的默认值。
  • 启用 NIC 的环境文件。这个示例使用位于 环境 目录中的默认 文件。
  • 自定义您的网络参数的任何其他环境文件。这个示例使用环境文件来自定义 OpenStack 服务映射到可组合网络。
注意

以上列表中的某些文件是 Jinja2 格式文件,并具有 .j2.yaml 扩展名。director 会在部署过程中为 .yaml 版本呈现这些文件。

9.1. 可组合网络

overcloud 默认使用以下预定义网络片段集合:

  • Control Plane
  • 内部 API
  • 存储
  • 存储管理
  • 租户
  • 外部
  • 管理(可选)

您可以使用可组合网络为各种服务添加网络。例如,如果您有一个专用于 NFS 流量的网络,可以将它提供给多个角色。

director 支持在部署和更新阶段创建自定义网络。您可以将这些额外网络用于 ironic 裸机节点、系统管理或为不同的角色创建单独的网络。您还可以使用它们创建多个网络集合,以用于在网络间路由流量的分割部署。

单个数据文件(network_data.yaml)管理您要部署的网络列表。使用 -n 选项将此文件与您的部署命令包含。若无此选项,部署将使用默认的 /usr/share/openstack-tripleo-heat-templates/network_data.yaml 文件。

9.2. 添加可组合网络

使用可组合网络为各种服务添加网络。例如,如果您有一个专用于存储备份流量的网络,您可以将网络呈现给多个角色。

流程

  1. 复制默认 network_data.yaml 文件:

    $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
  2. 编辑 network_data.yaml 文件的本地副本,并为您的新网络添加一个部分:

    - name: StorageBackup
      name_lower: storage_backup
      vlan: 21
      vip: true
      ip_subnet: '172.21.1.0/24'
      allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
      gateway_ip: '172.21.1.1'

您可以使用 network_data.yaml 文件中的以下参数:

name
设置网络的人类可读名称。这个参数是唯一强制参数。您还可以使用 name_lower 来规范名称来提高可读性。例如,将 InternalApi 改为 internal_api
name_lower
设置名称的小写版本,director 映射到分配给 roles_data.yaml 文件中角色的相应网络。
vlan
设置要用于此网络的 VLAN。
VIP: true
在新网络中创建一个虚拟 IP 地址(VIP)。此 IP 用作 service-to-network 映射参数中列出的服务的目标 IP (ServiceNetMap)。请注意,VIP 仅供使用 Pacemaker 的角色使用。overcloud 负载均衡服务将来自这些 IP 的流量重定向到对应的服务端点。
ip_subnet
以 CIDR 格式设置默认 IPv4 子网。
allocation_pools
设置 IPv4 子网的 IP 范围
gateway_ip
设置网络的网关。
Routes

为网络添加额外的路由。使用包含每个额外路由的 JSON 列表。每个列表项包含一个字典值映射。使用以下示例语法:

  routes: [{'destination':'10.0.0.0/16', 'nexthop':'10.0.2.254'}]
subnets

可创建属于这个网络中的其他路由子网。此参数接受 dict 值,其中包含路由子网的小写名称作为键,而 vlanip_subnetallocation_poolsgateway_ip 参数作为映射到子网的值。以下示例演示了这个布局:

- name: StorageBackup
  name_lower: storage_backup
  vlan: 200
  vip: true
  ip_subnet: '172.21.0.0/24'
  allocation_pools: [{'start': '171.21.0.4', 'end': '172.21.0.250'}]
  gateway_ip: '172.21.0.1'
  subnets:
    storage_backup_leaf1:
      vlan: 201
      ip_subnet: '172.21.1.0/24'
      allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
      gateway_ip: '172.19.1.254'

这个映射在 spine leaf deployments 中很常见。如需更多信息,请参阅 Spine Leaf Networking 指南。

使用 -n 选项在部署命令中包含自定义 network_data.yaml 文件。如果没有 -n 选项,部署命令将使用默认网络集合。

9.3. 在角色中包含可组合网络

您可以将可组合网络分配给环境中定义的 overcloud 角色。例如,您可以使用 Ceph Storage 节点包含自定义 StorageBackup 网络。

流程

  1. 如果您还没有自定义 roles_data.yaml 文件,请将默认复制到您的主目录:

    $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.
  2. 编辑自定义 roles_data.yaml 文件。
  3. 在您要向其添加 网络 的角色的网络列表中包含网络名称。例如,要将 StorageBackup 网络添加到 Ceph Storage 角色,请使用以下示例片断:

    - name: CephStorage
      description: |
        Ceph OSD Storage node role
      networks:
        - Storage
        - StorageMgmt
        - StorageBackup
  4. 将自定义网络添加到其各自角色后,保存文件。

运行 openstack overcloud deploy 命令时,使用 -r 选项包括自定义 roles_data.yaml 文件。如果没有 -r 选项,部署命令将使用默认角色集合以及对应的网络。

9.4. 为可组合网络分配 OpenStack 服务

每个 OpenStack 服务都会分配到资源注册表中的镜像默认网络类型。这些服务被绑定到在网络类型分配的网络中的 IP 地址。尽管 OpenStack 服务在这些网络之间划分,但实际物理网络的数量可能与网络环境文件中所定义的不同。您可以通过在环境文件中定义新的网络映射,将 OpenStack 服务重新分配给不同的网络类型,如 /home/stack/templates/service-reassignments.yamlServiceNetMap 参数决定要用于每个服务的网络类型。

例如,您可以通过修改突出显示的部分将 Storage Management 网络服务重新分配给 Storage Backup Network:

parameter_defaults:
  ServiceNetMap:
    SwiftMgmtNetwork: storage_backup
    CephClusterNetwork: storage_backup

将这些参数改为 storage_backup 将这些服务放在 Storage Backup 网络中,而不是存储管理网络。这意味着,您必须只为 Storage Backup 网络定义一组 parameter_defaults,而不是存储管理网络。

director 将您的自定义 ServiceNetMap 参数定义合并到一个预定义默认值列表中,它从 ServiceNetMapDefaults 获取并覆盖默认值。director 将完整列表(包括自定义)返回到 ServiceNetMap,用于配置不同服务的网络分配。

对于使用 Pacemaker 的节点,服务映射适用于在 network_data.yaml 文件中使用 vip: true 的网络。overcloud 负载均衡器将来自 VIP 的流量重定向到特定的服务端点。

注意

您可以在 /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml 文件中的 ServiceNetMapDefaults 参数中找到默认服务的完整列表。

9.5. 启用自定义可组合网络

使用其中一个默认 NIC 模板启用自定义可组合网络。在本例中,使用 Single NIC with VLAN 模板(net-single-nic-with-vlans)。

流程

  1. 运行 openstack overcloud deploy 命令时,请确保包含以下文件:

    • 自定义 network_data.yaml 文件。
    • 带有 network-to-role 分配的自定义 roles_data.yaml 文件。
    • 默认网络隔离的呈现文件名。
    • 默认网络环境文件的呈现文件名。
    • 默认网络接口配置的呈现文件名。
    • 与网络相关的任何其他环境文件,如服务重新分配。

例如:

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -r /home/stack/roles_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
    -e /home/stack/templates/service-reassignments.yaml \
    ...

本例命令可在 overcloud 中的节点之间部署可组合网络,包括其他自定义网络。

重要

请记住,如果介绍新的自定义网络,如管理网络,您必须再次显示模板。只需将网络名称添加到 roles_data.yaml 文件即可。

9.6. 重命名默认网络

您可以使用 network_data.yaml 文件修改默认网络的用户可见名称:

  • InternalApi
  • 外部
  • 存储
  • StorageMgmt
  • 租户

要更改这些名称,不要修改 name 字段。相反,将 name_lower 字段更改为网络的新名称,再使用新名称更新 ServiceNetMap。

流程

  1. network_data.yaml 文件中,为您要重命名的每个网络在 name_lower 参数中输入新名称:

    - name: InternalApi
      name_lower: MyCustomInternalApi
  2. service_net_map_replace 参数中包括 name_lower 参数的默认值:

    - name: InternalApi
      name_lower: MyCustomInternalApi
      service_net_map_replace: internal_api

第 10 章 自定义网络接口模板

配置 第 8 章 基本网络隔离 后,您可以创建一组自定义网络接口模板以适合您环境中的节点。例如,您可以包含以下文件:

  • 启用网络隔离的环境文件(/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml)。
  • 用于配置网络默认值的环境文件(/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml)。
  • 为各个节点定义 NIC 布局的模板。overcloud 核心模板集合包含一组用于不同用例的默认值。要创建自定义 NIC 模板,请将默认的 Jinja2 模板作为自定义模板的基础。
  • 启用 NIC 的自定义环境文件。本例使用自定义环境文件(/home/stack/templates/custom-network-configuration.yaml)来引用您的自定义接口模板。
  • 自定义您的网络参数的任何其他环境文件。
  • 如果自定义网络,则自定义 network_data.yaml 文件。
  • 如果创建额外的或自定义可组合网络,则自定义 network_data.yaml 文件和自定义 roles_data.yaml 文件。
注意

以上列表中的某些文件是 Jinja2 格式文件,并具有 .j2.yaml 扩展名。director 会在部署过程中为 .yaml 版本呈现这些文件。

10.1. 自定义网络架构

默认 NIC 模板可能不适用于特定的网络配置。例如,您可能想要创建自己的适合特定网络布局的自定义 NIC 模板。您可能想要将 上的控制服务和数据服务分隔到单独的 NIC。在这种情况下,您可以通过以下方式将服务映射到 NIC 分配:

  • NIC1 (Provisioning)

    • 置备/Control Plane
  • NIC2 (Control Group)

    • 内部 API
    • 存储管理
    • 外部(公共 API)
  • NIC3 (Data Group)

    • 租户网络(VXLAN 隧道)
    • 租户 VLAN/提供程序 VLAN
    • 存储
    • 外部 VLAN (浮动 IP/SNAT)
  • NIC4 (管理)

    • 管理

10.2. 为自定义呈现默认网络接口模板

为简化自定义模板的配置,请呈现默认 NIC 模板的 Jinja2 语法,并使用渲染的模板作为自定义配置的基础。

流程

  1. 使用 process-templates.py 脚本呈现 openstack-tripleo-heat-templates 集合的副本:

    $ cd /usr/share/openstack-tripleo-heat-templates
    $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered

    这会将所有 Jinja2 模板转换为其呈现的 YAML 版本,并将结果保存到 ~/openstack-tripleo-heat-templates-rendered 中。

    如果您使用自定义网络文件系统或自定义角色文件,您可以使用 -n-r 选项分别包含这些文件:

    $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered -n /home/stack/network_data.yaml -r /home/stack/roles_data.yaml
  2. 复制多个 NIC 示例:

    $ cp -r ~/openstack-tripleo-heat-templates-rendered/network/config/multiple-nics/ ~/templates/custom-nics/
  3. 编辑 custom-nics 中设置的模板,以适应您自己的网络配置。

10.3. 网络接口架构

您在 第 10.2 节 “为自定义呈现默认网络接口模板” 中呈现的自定义 NIC 模板包含 parametersresources 部分。

参数

parameters 部分包含网络接口的所有网络配置参数。这包括子网范围和 VLAN ID 等信息。本节应该保持不变,因为 heat 模板会继承其父模板的值。但是,您可以使用网络环境文件来修改某些参数的值。

Resources

resources 部分是主网络接口配置的位置。在大多数情况下,resource 部分是唯一需要修改的。每个 resources 部分都以以下标头开始:

resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:

此片段运行一个脚本(run-os-net-config.sh),它为 os-net-config 创建配置文件,以用于配置节点上的网络属性。network_config 部分包含发送到 run-os-net-config.sh 脚本的自定义网络接口数据。根据设备类型,您可以按顺序排列该自定义接口数据。

重要

如果创建自定义 NIC 模板,您必须将 run-os-net-config.sh 脚本位置设置为每个 NIC 模板的绝对路径。该脚本位于 undercloud 上的 /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh

10.4. 网络接口参考

网络接口配置包括以下参数:

interface

定义单个网络接口。配置使用实际接口名称("eth0", "eth1", "enp0s25")或一组数字接口 ("nic1", "nic2", "nic3") 定义各个接口:

  - type: interface
    name: nic2

表 10.1. 接口选项

选项默认值描述

name

 

接口的名称。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给接口的 IP 地址列表。

Routes

 

分配给接口的路由列表。更多信息请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

primary

False

将接口定义为主接口。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时才适用。

persist_mapping

False

编写设备别名配置,而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

要用作接口的 DNS 服务器列表。

ethtool_opts

 

将这个选项设置为 "rx-flow-hash udp4 sdfn",以便在某些 NIC 上使用 VXLAN 时提高吞吐量。

vlan

一个 VLAN。使用从 parameters 部分传递的 VLAN ID 和子网。

例如:

  - type: vlan
    vlan_id:{get_param: ExternalNetworkVlanID}
    addresses:
      - ip_netmask: {get_param: ExternalIpSubnet}

表 10.2. VLAN 选项

选项默认值描述

vlan_id

 

VLAN ID。

device

 

附加 VLAN 的父设备。当 VLAN 不是 OVS 网桥的成员时,请使用此参数。例如,使用此参数将 VLAN 附加到绑定接口设备。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给 VLAN 的 IP 地址列表。

Routes

 

分配给 VLAN 的路由列表。更多信息请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

primary

False

将 VLAN 定义为主接口。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时才适用。

persist_mapping

False

编写设备别名配置,而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

要用于 VLAN 的 DNS 服务器列表。

ovs_bond

在 Open vSwitch 中定义一个绑定,将两个或多个 接口 一起加入。这有助于冗余和增加带宽。

例如:

          - type: ovs_bond
            name: bond1
            members:
            - type: interface
              name: nic2
            - type: interface
              name: nic3

表 10.3. ovs_bond options

选项默认值描述

name

 

绑定的名称。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给绑定的 IP 地址列表。

Routes

 

分配给绑定的路由列表。更多信息请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

primary

False

将接口定义为主接口。

成员

 

要在绑定中使用的一系列接口对象。

ovs_options

 

在创建绑定时要传递给 OVS 的一组选项。

ovs_extra

 

在绑定网络配置文件中设置为 OVS_EXTRA 参数的一组选项。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时才适用。

persist_mapping

False

编写设备别名配置,而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

要用于绑定的 DNS 服务器列表。

ovs_bridge

在 Open vSwitch 中定义一个网桥,将多个 interface, ovs_bond, 和 vlan 对象连接在一起。

网络接口类型 ovs_bridge 取一个参数 名称

注意

如果有多个网桥,则必须使用除接受 bridge_name 的默认名称以外的不同网桥名称。如果不使用不同的名称,则在聚合阶段,将两个网络绑定放置在同一网桥中。

如果您要为外部 tripleo 网络定义 OVS 网桥,则保留值 bridge_nameinterface_name,因为您的部署框架会自动将这些值替换为外部网桥名称和外部接口名称。

例如:

      - type: ovs_bridge
        name: bridge_name
        addresses:
        - ip_netmask:
            list_join:
            - /
            - - {get_param: ControlPlaneIp}
              - {get_param: ControlPlaneSubnetCidr}
        members:
          - type: interface
            name: interface_name
      - type: vlan
        device: bridge_name
        vlan_id:
          {get_param: ExternalNetworkVlanID}
        addresses:
          - ip_netmask:
              {get_param: ExternalIpSubnet}
注意

OVS 网桥连接到网络服务(neutron)服务器,以获取配置数据。如果 OpenStack 控制流量(通常是 Control Plane 和 Internal API 网络)放置在 OVS 网桥上,那么到 neutron 服务器的连接会在升级 OVS 时丢失,或者 OVS 网桥由 admin 用户或进程重启。这会导致一些停机时间。如果在这些情况下无法接受停机时间,您必须将 Control 组网络放在单独的接口或绑定中,而不是在 OVS 网桥上:

  • 在置备接口和 OVS 网桥上的 VLAN 上放置内部 API 网络时,您可以实现最小的设置。
  • 要实现绑定,您需要至少两个绑定(four 网络接口)。将控制组放在 Linux 绑定(Linux 网桥)上。如果交换机不支持 LACP 回退到单一接口进行 PXE 引导,那么这个解决方案至少需要 5 个 NIC。

表 10.4. ovs_bridge options

选项默认值描述

name

 

网桥的名称。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给该网桥的 IP 地址列表。

Routes

 

分配给网桥的路由列表。更多信息请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

成员

 

您要在网桥中使用的一系列接口、VLAN 和绑定对象。

ovs_options

 

创建网桥时要传递给 OVS 的一组选项。

ovs_extra

 

网桥的网络配置文件中设置为 OVS_EXTRA 参数的一组选项。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时才适用。

persist_mapping

False

编写设备别名配置,而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

您要用于桥接的 DNS 服务器列表。

linux_bond

定义一个将两个或者多个 接口 接合在一起的 Linux 绑定。这有助于冗余和增加带宽。确保您在 bonding_options 参数中包含基于内核的绑定选项。

例如:

      - type: linux_bond
        name: bond1
        members:
        - type: interface
          name: nic2
          primary: true
        - type: interface
          name: nic3
        bonding_options: "mode=802.3ad"

请注意,nic2 使用 primary: true 来确保绑定将 MAC 地址用于 nic2

表 10.5. linux_bond options

选项默认值描述

name

 

绑定的名称。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给绑定的 IP 地址列表。

Routes

 

分配给绑定的路由列表。请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

primary

False

将接口定义为主接口。

成员

 

要在绑定中使用的一系列接口对象。

bonding_options

 

创建绑定时一组选项。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时才适用。

persist_mapping

False

编写设备别名配置,而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

要用于绑定的 DNS 服务器列表。

linux_bridge

定义一个 Linux 网桥,它将多个 interface, linux_bond, 和 vlan 对象连接在一起。外部网桥也对参数使用两个特殊值:

  • bridge_name,它替换为外部网桥名称。
  • interface_name,它被替换为外部接口。

例如:

      - type: linux_bridge
        name: bridge_name
        addresses:
          - ip_netmask:
              list_join:
                - /
                - - {get_param: ControlPlaneIp}
                  - {get_param: ControlPlaneSubnetCidr}
        members:
          - type: interface
            name: interface_name
      - type: vlan
        device: bridge_name
        vlan_id:
          {get_param: ExternalNetworkVlanID}
        addresses:
          - ip_netmask:
              {get_param: ExternalIpSubnet}

表 10.6. linux_bridge options

选项默认值描述

name

 

网桥的名称。

use_dhcp

False

使用 DHCP 获取 IP 地址。

use_dhcpv6

False

使用 DHCP 获取 v6 IP 地址。

addresses

 

分配给该网桥的 IP 地址列表。

Routes

 

分配给网桥的路由列表。更多信息请参阅 Routes

mtu

1500

连接的最大传输单元(MTU)。

成员

 

您要在网桥中使用的一系列接口、VLAN 和绑定对象。

defroute

True

使用 DHCP 服务提供的默认路由。仅在启用 use_dhcpuse_dhcpv6 时才适用。

persist_mapping

False

编写设备别名配置,而不是系统名称。

dhclient_args

要传递给 DHCP 客户端的参数。

dns_servers

您要用于桥接的 DNS 服务器列表。

Routes

定义应用到网络接口、VLAN、网桥或绑定的路由列表。

例如:

  - type: interface
    name: nic2
    ...
    routes:
      - ip_netmask: 10.1.2.0/24
        gateway_ip: 10.1.2.1
选项默认值描述

ip_netmask

目标网络的 IP 和子网掩码。

default

False

将此路由设置为默认路由。等同于设置 ip_netmask: 0.0.0.0/0

next_hop

用于访问目的地网络的路由器的 IP 地址。

10.5. 网络接口布局示例

以下示例 Controller 节点 NIC 模板片断如何配置自定义网络场景,使其保持控制组与 OVS 网桥独立:

resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:
              - type: interface
                name: nic1
                mtu:
                 get_param: ControlPlaneMtu
                use_dhcp: false
                addresses:
                - ip_netmask:
                    list_join:
                    - /
                    - - get_param: ControlPlaneIp
                      - get_param: ControlPlaneSubnetCidr
                routes:
                  list_concat_unique:
                    - get_param: ControlPlaneStaticRoutes
              - type: ovs_bridge
                name: bridge_name
                dns_servers:
                  get_param: DnsServers
                domain:
                  get_param: DnsSearchDomains
                members:
                - type: ovs_bond
                  name: bond1
                  mtu:
                    get_attr: [MinViableMtu, value]
                  ovs_options:
                    get_param: BondInterfaceOvsOptions
                  members:
                    - type: interface
                      name: nic2
                      mtu:
                        get_attr: [MinViableMtu, value]
                      primary: true
                    - type: interface
                      name: nic3
                      mtu:
                        get_attr: [MinViableMtu, value]
                - type: vlan
                  mtu:
                    get_param: StorageMtu
                  vlan_id:
                    get_param: StorageNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: StorageIpSubnet
                  routes:
                    list_concat_unique:
                      - get_param: StorageInterfaceRoutes
                - type: vlan
                  mtu:
                    get_param: StorageMgmtMtu
                  vlan_id:
                    get_param: StorageMgmtNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: StorageMgmtIpSubnet
                  routes:
                    list_concat_unique:
                      - get_param: StorageMgmtInterfaceRoutes
                - type: vlan
                  mtu:
                   get_param: InternalApiMtu
                  vlan_id:
                    get_param: InternalApiNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: InternalApiIpSubnet
                  routes:
                    list_concat_unique:
                      - get_param: InternalApiInterfaceRoutes
                 - type: vlan
                   mtu:
                     get_param: TenantMtu
                   vlan_id:
                     get_param: TenantNetworkVlanID
                   addresses:
                   - ip_netmask:
                      get_param: TenantIpSubnet
                  routes:
                    list_concat_unique:
                      - get_param: TenantInterfaceRoutes
                 - type: vlan
                   mtu:
                     get_param: ExternalMtu
                   vlan_id:
                     get_param: ExternalNetworkVlanID
                   addresses:
                   - ip_netmask:
                      get_param: ExternalIpSubnet
                  routes:
                    list_concat_unique:
                      - get_param: ExternalInterfaceRoutes
                      - - default: true
                          next_hop:
                            get_param: ExternalInterfaceDefaultRoute

此模板使用三个网络接口,并将多个标记的 VLAN 设备分配给编号的接口 nic1nic3。在 nic2nic3 上,此模板创建托管 Storage、Tenant 和 External 网络的 OVS 网桥。因此,它会创建以下布局:

  • NIC1 (Provisioning)

    • 置备/Control Plane
  • NIC2 和 NIC3 (管理)

    • 内部 API
    • 存储
    • 存储管理
    • 租户网络(VXLAN 隧道)
    • 租户 VLAN/提供程序 VLAN
    • 外部(公共 API)
    • 外部 VLAN (浮动 IP/SNAT)

10.6. 自定义网络的网络接口注意事项

当您使用可组合网络时,process-templates.py 脚本会呈现静态模板,使其包含您在 network_data.yamlroles_data.yaml 文件中定义的网络和角色。确保您的渲染的 NIC 模板包含以下项目:

  • 每个角色(包括自定义可组合网络)的静态文件。
  • 每个角色的静态文件中的正确的网络定义。

每个静态文件都需要任何自定义网络的所有参数定义,即使网络没有在角色中使用。确保渲染的模板包含这些参数。例如,如果您只向 Ceph 节点添加 StorageBackup 网络,还必须将该定义包含在所有角色的 NIC 配置模板中的 parameter 部分:

parameters:
  ...
  StorageBackupIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  ...

如果需要,您还可以包括 VLAN ID 和/或网关 IP 的 parameters 定义:

parameters:
  ...
  StorageBackupNetworkVlanID:
    default: 60
    description: Vlan ID for the management network traffic.
    type: number
  StorageBackupDefaultRoute:
	  description: The default route of the storage backup network.
	  type: string
  ...

自定义网络的 IpSubnet 参数会出现在每个角色的参数定义中。但是,因为 Ceph 角色可能是唯一使用 StorageBackup 网络的角色,所以只有 Ceph 角色的 NIC 配置模板使用模板的 network_config 部分中的 StorageBackup 参数。

      $network_config:
        network_config:
        - type: interface
          name: nic1
          use_dhcp: false
          addresses:
          - ip_netmask:
              get_param: StorageBackupIpSubnet

10.7. 自定义网络环境文件

自定义网络环境文件(本例中为 /home/stack/templates/custom-network-configuration.yaml)是一个 heat 环境文件,它描述 overcloud 网络环境并指向自定义网络接口配置模板。您可以为网络定义子网和 VLAN,以及 IP 地址范围。然后,您可以为本地环境自定义这些值。

resource_registry 部分包含对各个节点角色自定义网络接口模板的引用。每个注册的资源都使用以下格式:

  • OS::TripleO::[ROLE]::Net::SoftwareConfig: [FILE]

[ROLE] 是角色名称,[FILE] 是该特定角色对应的网络接口模板。例如:

resource_registry:
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/custom-nics/controller.yaml

parameter_defaults 部分包含定义每种网络类型的网络选项的参数列表。

10.8. 网络环境参数

下表是网络环境文件的 parameter_defaults 部分中可以使用的参数列表,以覆盖 NIC 模板中的默认参数值。

参数描述类型

ControlPlaneDefaultRoute

Control Plane 上的路由器 IP 地址,用作 Controller 节点以外的角色的默认路由。如果使用 IP 伪装而不是路由器,则将此值设置为 undercloud IP。

字符串

ControlPlaneSubnetCidr

Control Plane 上使用 IP 网络的 CIDR 子网掩码。如果 Control Plane 网络使用 192.168.24.0/24,则 CIDR 为 24

字符串(尽管始终是一个数字)

*NetCidr

特定网络的完整网络和 CIDR 子网掩码。默认值自动设置为 network_data.yaml 文件中的网络 ip_subnet 设置。例如,InternalApiNetCidr: 172.16.0.0/24

字符串

*AllocationPools

特定网络的 IP 分配范围。默认值自动设置为 network_data.yaml 文件中的网络 allocation_pools 设置。例如,InternalApiAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}].

hash

*NetworkVlanID

特定网络上节点的 VLAN ID。默认会自动设置为 network_data.yaml 文件中的 network vlan 设置。例如,InternalApiNetworkVlanID: 201

number

*InterfaceDefaultRoute

特定网络的路由器地址,您可以将这些地址用作角色或路由到其他网络的默认路由。默认值自动设置为 network_data.yaml 文件中的网络 gateway_ip 设置。例如,InternalApiInterfaceDefaultRoute: 172.16.0.1

字符串

DnsServers

添加到 resolv.conf 的 DNS 服务器列表。通常允许最多 2 个服务器。

以逗号分隔的列表

EC2MetadataIp

用于置备 overcloud 节点的元数据服务器的 IP 地址。将此值设置为 Control Plane 上 undercloud 的 IP 地址。

字符串

BondInterfaceOvsOptions

绑定接口的选项。例如: BondInterfaceOvsOptions: "bond_mode=balance-slb"

字符串

NeutronExternalNetworkBridge

要用于 OpenStack Networking (neutron)的外部网桥名称旧值。默认情况下,这个值为空,这意味着您可以在 NeutronBridgeMappings 中定义多个物理网桥。在正常情况下,请勿覆盖这个值。

字符串

NeutronFlatNetworks

定义要在 neutron 插件中配置的扁平网络。默认值为 datacentre,以允许外部网络创建。例如,NeutronFlatNetworks: "datacentre"

字符串

NeutronBridgeMappings

要使用的物理网桥映射的逻辑。默认值将主机上的外部网桥(br-ex)映射到物理名称(datacentre)。在创建 OpenStack Networking (neutron)提供商网络或浮动 IP 网络时,请参考逻辑名称。例如,NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"

字符串

NeutronPublicInterface

定义您要为网络节点桥接的 br-ex 接口,不使用网络隔离。通常,除了具有两个网络的小型部署中,不使用。例如: NeutronPublicInterface: "eth0"

字符串

NeutronNetworkType

OpenStack Networking(neutron)的租户网络类型。要指定多个值,请使用逗号分隔列表。在所有可用网络用尽前,系统会使用您指定的第一种类型,然后会使用下一个类型。例如,NeutronNetworkType: "vxlan"。请注意,ML2/OVN 机制驱动程序不支持 vxlan,这是默认的 ML2 机制驱动程序。

字符串

NeutronTunnelTypes

neutron 租户网络的隧道类型。要指定多个值,使用以逗号分开的字符串。例如,NeutronTunnelTypes: 'gre,vxlan'。请注意,ML2/OVN 机制驱动程序不支持 vxlan,这是默认的 ML2 机制驱动程序。

字符串/用逗号分开的列表

NeutronTunnelIdRanges

要用于租户网络分配的 GRE 隧道 ID 范围。例如,NeutronTunnelIdRanges "1:1000"

字符串

NeutronVniRanges

要用于租户网络分配的 VXLAN VNI ID 范围。例如,NeutronVniRanges: "1:1000"

字符串

NeutronEnableTunnelling

定义是启用还是彻底禁用所有隧道网络。除非您要在以后创建调整的网络,否则请保留此项功能。默认值为 true

布尔值

NeutronNetworkVLANRanges

您要支持的 ML2 和 Open vSwitch VLAN 映射范围。默认为允许 datacentre 物理网络中的任何 VLAN。要指定多个值,请使用逗号分隔列表。例如,NeutronNetworkVLANRanges: "datacentre:1:1000,tenant:100:299,tenant:310:399"

字符串

NeutronMechanismDrivers

neutron 租户网络的机制驱动程序。默认值为 ovn。要指定多个值,请使用逗号分隔的字符串。例如,NeutronMechanismDrivers: 'openvswitch,l2population'

字符串/用逗号分开的列表

10.9. 自定义网络环境文件示例

以下片段是一个环境文件的示例,您可以使用该文件来启用 NIC 模板并设置自定义参数。

resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/ceph-storage.yaml

parameter_defaults:
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.0.2.254
  # The IP address of the EC2 metadata server. Generally the IP of the Undercloud
  EC2MetadataIp: 192.0.2.1
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["8.8.8.8","8.8.4.4"]
  NeutronExternalNetworkBridge: "''"

10.10. 使用自定义 NIC 启用网络隔离

要使用网络隔离和自定义 NIC 模板部署 overcloud,请在 overcloud 部署命令中包括所有相关的网络环境文件。

流程

  1. 运行 openstack overcloud deploy 命令时,包含以下文件:

    • 自定义 network_data.yaml 文件。
    • 默认网络隔离的呈现文件名。
    • 默认网络环境文件的呈现文件名。
    • 包含自定义 NIC 模板资源引用的自定义环境网络配置。
    • 任何与您配置相关的额外环境文件。

例如:

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /home/stack/templates/custom-network-configuration.yaml \
    ...
  • 首先包含 network-isolation.yaml 文件,然后是 network-environment.yaml 文件。后续的 custom-network-configuration.yaml 覆盖了来自前两个文件中的 OS::TripleO::[ROLE]::Net::SoftwareConfig 资源。
  • 如果使用可组合网络,则使用以下命令包含 network_data.yamlroles_data.yaml 文件。

第 11 章 额外网络配置

本章介绍了 第 10 章 自定义网络接口模板 中介绍的概念和步骤,并提供了一些附加信息来帮助配置 overcloud 网络的部分。

11.1. 配置自定义接口

单个接口可能需要修改。以下示例显示了使用第二个 NIC 连接到基础架构网络所需的修改,并使用 DHCP 地址连接到基础架构网络,并使用第三和第四个 NIC 作为绑定:

network_config:
  # Add a DHCP infrastructure network to nic2
  - type: interface
    name: nic2
    use_dhcp: true
  - type: ovs_bridge
    name: br-bond
    members:
      - type: ovs_bond
        name: bond1
        ovs_options:
          get_param: BondInterfaceOvsOptions
        members:
          # Modify bond NICs to use nic3 and nic4
          - type: interface
            name: nic3
            primary: true
          - type: interface
            name: nic4

网络接口模板使用实际接口名称(eth0, eth1, enp0s25)或一组编号的接口(nic1, nic2, nic3)。当使用编号接口(nic1, nic2 等)而不是命名接口(eth0, eno2 等)时,角色中的主机的网络接口不必完全相同。例如,一个主机可能具有 em1em2 的接口,而另一个主机具有 eno1eno2,但您可以将两个主机的 NIC 指代为 nic1nic2

数字接口的顺序与命名网络接口类型的顺序对应:

  • ethX 接口,如 eth 0、eth1 等。它们通常是板载的接口。
  • enoX 接口,如 eno 0、eno1 等。它们通常是板载的接口。
  • enX 接口,按数字顺序排序,如 enp3s 0、enp3s1、 ens3 等。它们通常是附加组件接口。

numbered NIC 方案只包括实时接口,例如,如果接口已将电缆附加到交换机。如果您有一些主机有四个接口以及一些六个接口,请使用 nic1nic4,并只附加每个主机四个电缆。

您可以将物理接口硬编码到特定别名,以便您可以预先确定哪个物理 NIC 映射到 nic1nic2 等。您还可以将 MAC 地址映射到指定的别名。

注意

通常,OS-net-config 只注册处于 UP 状态的接口。但是,如果您使用自定义映射文件硬编码接口,即使接口处于 DOWN 状态,也会注册该接口。

使用环境文件将接口映射到别名。在本例中,每个节点都有 nic1nic2 预定义条目。

注意

如果要使用 NetConfigDataLookup 配置,在 NodeUserData 资源 registry 中还必须包含 os-net-config-mappings.yaml 文件。

resource_registry:
  OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/os-net-config-mappings.yaml
parameter_defaults:
  NetConfigDataLookup:
    node1:
      nic1: "em1"
      nic2: "em2"
    node2:
      nic1: "00:50:56:2F:9F:2E"
      nic2: "em2"

生成的配置由 os-net-config 应用。在每个节点上,您可以在 /etc/os-net-config/mapping.yaml 文件的 interface_mapping 部分看到应用的配置。

注意

在部署到预置备节点时,不会应用 NetConfigDataLookup 参数。如果要将自定义接口映射与预置备节点搭配使用,您必须在部署前在每个节点上创建 /etc/os-net-net-config/mapping.yaml 文件。使用 /etc/os-net-config/mapping.yaml 文件中的以下示例接口映射:

interface_mapping:
  nic1: em1
  nic2: em2

11.2. 配置路由和默认路由

您可以通过以下两种方式之一设置主机的默认路由:如果接口使用 DHCP,且 DHCP 服务器提供网关地址,系统为该网关使用默认路由。否则,您可以使用静态 IP 在接口上设置默认路由。

虽然 Linux 内核支持多个默认网关,但它只使用具有最低指标的网关。如果有多个 DHCP 接口,这可能会导致无法预计的默认网关。在这种情况下,建议为使用默认路由的接口以外的接口设置 defroute: false

例如,您可能希望 DHCP 接口(nic3)是默认路由。使用以下 YAML 片断禁用另一个 DHCP 接口上的默认路由(nic2):

# No default route on this DHCP interface
- type: interface
  name: nic2
  use_dhcp: true
  defroute: false
# Instead use this DHCP interface as the default route
- type: interface
  name: nic3
  use_dhcp: true
注意

defroute 参数仅适用于通过 DHCP 获取的路由。

要在带有静态 IP 的接口上设置静态路由,请指定到子网的路由。例如,您可以通过内部 API 网络上的 172.17.0.1 网关设置到 10.1.2.0/24 子网的路由:

    - type: vlan
      device: bond1
      vlan_id:
        get_param: InternalApiNetworkVlanID
      addresses:
      - ip_netmask:
          get_param: InternalApiIpSubnet
      routes:
      - ip_netmask: 10.1.2.0/24
        next_hop: 172.17.0.1

11.3. 配置基于策略的路由

在 Controller 节点上,配置来自不同网络的无限访问,配置基于策略的路由。基于策略的路由使用路由表,在带有多个接口的主机上,您可以根据源地址通过特定接口发送流量。您可以将来自不同源的数据包路由到不同的网络,即使目的地是相同的。

例如,您可以将路由配置为根据数据包的源地址将流量发送到内部 API 网络,即使默认路由是外部网络的。您还可以为每个接口定义特定的路由规则。

Red Hat OpenStack Platform 使用 os-net-config 工具为您的 overcloud 节点配置网络属性。os-net-config 工具在 Controller 节点上管理以下网络路由:

  • /etc/iproute2/rt_tables 文件中的路由表
  • /etc/sysconfig/network-scripts/rule-{ifname} 文件中的 IPv4 规则
  • /etc/sysconfig/network-scripts/rule6-{ifname} 文件中的 IPv6 规则
  • 路由表在 /etc/sysconfig/network-scripts/route-{ifname}中的特定路由

先决条件

流程

  1. ~/templates/custom-nics 目录创建一个自定义 NIC 模板中的 route_tableinterface 条目,定义与部署相关的规则:

    $network_config:
      network_config:
    
      - type: route_table
        name: custom
        table_id: 200
    
      - type: interface
        name: em1
        use_dhcp: false
        addresses:
          - ip_netmask: 192.0.2.1/24
    
        routes:
          - ip_netmask: 10.1.3.0/24
            next_hop: 192.0.2.5
            route_options: "metric 10"
            table: 200
        rules:
          - rule: "iif em1 table 200"
            comment: "Route incoming traffic to em1 with table 200"
          - rule: "from 192.0.2.0/24 table 200"
            comment: "Route all traffic from 192.0.2.0/24 with table 200"
          - rule: "add blackhole from 172.19.40.0/24 table 200"
          - rule: "add unreachable iif em1 from 192.168.1.0/24"
  2. run-os-net-config.sh 脚本位置设置为您创建的每个自定义 NIC 模板中的绝对路径。该脚本位于 undercloud 的 /usr/share/openstack-tripleo-heat-templates/network/scripts/ 目录中:

    resources:
      OsNetConfigImpl:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template:
                get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
  3. 在部署命令中包括您的自定义 NIC 配置和网络环境文件,以及与部署相关的任何其他环境文件:

    $ openstack overcloud deploy --templates \
    -e ~/templates/<custom-nic-template>
    -e <OTHER_ENVIRONMENT_FILES>

验证

  • 在 Controller 节点上输入以下命令来验证路由配置是否正常工作:

    $ cat /etc/iproute2/rt_tables
    $ ip route
    $ ip rule

11.4. 配置巨型帧

最大传输单元(MTU)设置决定了通过单一以太网帧传输的最大数据量。使用较大的值会导致开销更少,因为每个帧以标头的形式添加数据。默认值为 1500,使用更高的值需要配置交换机端口来支持巨型帧。大多数交换机支持至少 9000 的 MTU,但很多交换机默认配置为 1500。

VLAN 的 MTU 不能超过物理接口的 MTU。确保在绑定或接口上包含 MTU 值。

存储、存储管理、内部 API 和租户网络都受益于巨型帧。

警告

路由器通常无法在第 3 层边界之间转发巨型帧。为避免连接问题,请不要更改 Provisioning 接口、外部接口和任何浮动 IP 接口的默认 MTU。

- type: ovs_bond
  name: bond1
  mtu:
    get_param: [MaxViableMtu, value]
  ovs_options:
    get_param: BondInterfaceOvsOptions
  members:
    - type: interface
      name: nic2
      mtu: 9000
      primary: true
    - type: interface
      name: nic3
      mtu: 9000

# The external interface should stay at default
- type: vlan
  device: bond1
  vlan_id:
    get_param: ExternalNetworkVlanID
  addresses:
    - ip_netmask:
        get_param: ExternalIpSubnet
  routes:
    list_concat_unique
      - get_param: ExternalInterfaceRoutes
      - - default: true
          next_hop:
            get_param: ExternalInterfaceDefaultRoute

# MTU 9000 for Internal API, Storage, and Storage Management
- type: vlan
  device: bond1
  mtu: 9000
  vlan_id:
    get_param: InternalApiNetworkVlanID
  addresses:
  - ip_netmask:
      get_param: InternalApiIpSubnet

11.5. 配置 ML2/OVN 北向路径 MTU 发现,以实现巨型帧碎片

如果您的内部网络上的虚拟机发送巨型帧到外部网络,且内部网络的最大传输单元(MTU)超过外部网络的 MTU,北向帧可轻松超过外部网络的容量。

ML2/OVS 会自动处理这个数据包问题,ML2/OVN 会自动处理 TCP 数据包。

但要确保在使用 ML2/OVN 机制驱动程序的部署中正确处理北向 UDP 数据包,您需要执行额外的配置步骤。

这些步骤将 ML2/OVN 路由器将 ICMP"协调所需的"数据包返回到发送虚拟机,其中发送应用会将有效负载拆分为较小的数据包。

注意

在 east/west 流量中,RHOSP ML2/OVN 部署不支持在 east/west 路径上大于最小 MTU 的数据包。例如:

  • VM1 在 Network1 上,MTU 为 1300。
  • VM2 位于网络2,MTU 为 1200。
  • 对 VM1 和 VM2 的方向进行 ping,大小为 1171 或更少的成功。大小大于 1171 的 ping 会导致数据包的 100% 丢失。

    由于没有客户的具体要求,红帽还没有计划提供对它的支持。

先决条件

  • 带有 kernel-4.18.0-193.20.1.el8_2 或更高版本的RHEL 8.2.0.4 或更高版本。

流程

  1. 检查内核版本。

    ovs-appctl -t ovs-vswitchd dpif/show-dp-features br-int
  2. 如果输出中包含 Check pkt length action: No,或者输出中没有 Check pkt length action 字符串,升级到 RHEL 8.2.0.4 或更高版本,或者不要将巨型帧发送到具有较小的 MTU 的外部网络。
  3. 如果输出包含 Check pkt length action: Yes,在 ml2_conf.ini 的 [ovn] 部分中设置以下值。

    ovn_emit_need_to_frag = True

11.6. 在中继接口上配置原生 VLAN

如果中继接口或绑定在原生 VLAN 上有一个网络,则 IP 地址会直接分配给网桥,且没有 VLAN 接口。

例如,如果外部网络位于原生 VLAN 上,则绑定的配置类似如下:

network_config:
  - type: ovs_bridge
    name: bridge_name
    dns_servers:
      get_param: DnsServers
    addresses:
      - ip_netmask:
          get_param: ExternalIpSubnet
    routes:
      list_concat_unique:
        - get_param: ExternalInterfaceRoutes
        - - default: true
            next_hop:
              get_param: ExternalInterfaceDefaultRoute
    members:
      - type: ovs_bond
        name: bond1
        ovs_options:
          get_param: BondInterfaceOvsOptions
        members:
          - type: interface
            name: nic3
            primary: true
          - type: interface
            name: nic4
注意

当您将地址或路由语句移到网桥时,从网桥中删除对应的 VLAN 接口。对所有适用的角色进行更改。外部网络仅依赖于控制器,因此只有控制器模板需要更改。Storage 网络附加到所有角色,因此如果存储网络位于默认 VLAN,则所有角色都需要修改。

11.7. 增加 netfilter 跟踪的最大连接数

Red Hat OpenStack Platform (RHOSP)网络服务(neutron)使用 netfilter 连接跟踪来构建有状态的防火墙,并在虚拟网络中提供网络地址转换(NAT)。有些情况下可能会导致内核空间达到最大连接限制,并导致错误(如 nf_conntrack: table full, drop 数据包)。您可以增加连接跟踪(conntrack)的限值,并避免这些类型的错误。您可以为 RHOSP 部署中的一个或多个角色增加 conntrack 限制。

先决条件

  • 成功安装 RHOSP undercloud。

流程

  1. stack 用户身份登录 undercloud 主机。
  2. 提供 undercloud 凭据文件:

    $ source ~/stackrc
  3. 创建自定义 YAML 环境文件。

    示例

    $ vi /home/stack/templates/my-environment.yaml

  4. 您的环境文件必须包含关键字 参数_defaultsExtraSysctlSettings。输入新值,表示 netfilter 可在变量 net.nf_conntrack_max 中跟踪的最大连接数。

    示例

    在本例中,您可以在 RHOSP 部署中的所有主机中设置 conntrack 限制:

    parameter_defaults:
      ExtraSysctlSettings:
        net.nf_conntrack_max:
          value: 500000

    使用 & lt;role>Parameter 参数为特定角色设置 conntrack 限制:

    parameter_defaults:
      <role>Parameters:
        ExtraSysctlSettings:
          net.nf_conntrack_max:
            value: <simultaneous_connections>
    • <role > 替换为角色的名称。

      例如,使用 ControllerParameters 为 Controller 角色设置 conntrack 限值,或者为 Compute 角色设置 conntrack 限值。

    • 将 < simultaneous_connections > 替换为您要允许的同时连接数量。

      示例

      在本例中,您只能在 RHOSP 部署中为 Controller 角色设置 conntrack 限制:

      parameter_defaults:
        ControllerParameters:
          ExtraSysctlSettings:
            net.nf_conntrack_max:
              value: 500000
      注意

      net.nf_conntrack_max 的默认值为 500000 连接。最大值为: 4294967295.

  5. 运行部署命令,包括核心 heat 模板、环境文件和新的自定义环境文件。

    重要

    环境文件的顺序非常重要,因为后续环境文件中定义的参数和资源更为优先。

    示例

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/my-environment.yaml

第 12 章 网络接口绑定

您可以在自定义网络配置中使用各种绑定选项。

12.1. overcloud 节点的网络接口绑定

您可以将多个物理 NIC 捆绑到一起组成一个逻辑频道,称为绑定。您可以配置绑定来为高可用性系统或增加吞吐量提供冗余。

Red Hat OpenStack Platform 支持 Open vSwitch (OVS)内核绑定、OVS-DPDK 绑定和 Linux 内核绑定。

表 12.1. 支持的接口绑定类型

绑定类型类型值允许的网桥类型允许的成员

OVS 内核绑定

ovs_bond

ovs_bridge

interface

OVS-DPDK 绑定

ovs_dpdk_bond

ovs_user_bridge

ovs_dpdk_port

Linux 内核绑定

linux_bond

ovs_bridgelinux_bridge

interface

重要

不要在同一节点上组合 ovs_bridgeovs_user_bridge

12.2. 创建 Open vSwitch (OVS)绑定

您可以在网络接口模板中创建 OVS 绑定。例如,您可以创建一个绑定作为 OVS 用户空间网桥的一部分:

...
          params:
            $network_config:
              network_config:
              - type: ovs_user_bridge
                name: br-ex
                use_dhcp: false
                members:
                - type: ovs_dpdk_bond
                  name: dpdkbond0
                  mtu: 2140
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  rx_queue:
                    get_param: NumDpdkInterfaceRxQueues
                  members:
                  - type: ovs_dpdk_port
                    name: dpdk0
                    mtu: 2140
                    members:
                    - type: interface
                      name: p1p1
                  - type: ovs_dpdk_port
                    name: dpdk1
                    mtu: 2140
                    members:
                    - type: interface
                      name: p1p2

在本例中,您要从两个 DPDK 端口创建绑定。

ovs_options 参数包含绑定选项。您可以使用 BondInterfaceOvsOptions 参数在网络环境文件中配置绑定选项:

parameter_defaults:
  BondInterfaceOvsOptions: "bond_mode=balance-slb"

12.3. Open vSwitch (OVS)绑定选项

您可以使用 NIC 模板文件中的 ovs_options heat 参数设置各种 Open vSwitch (OVS)绑定选项。

bond_mode=balance-slb
源负载均衡(slb)根据源 MAC 地址和输出 VLAN 平衡流,以及定期重新平衡作为流量模式变化。当您使用 balance-slb 绑定选项配置绑定时,远程交换机不需要配置。Networking 服务(neutron)将每个源 MAC 和 VLAN 对分配给链接,并通过该链接传输来自该 MAC 和 VLAN 的所有数据包。使用基于源 MAC 地址和 VLAN 号码的简单哈希算法,并在流量特征改变时定期重新平衡。balance-slb 模式与 Linux 绑定驱动程序使用的模式 2 绑定类似。您可以使用此模式来提供负载平衡,即使交换机没有配置为使用 LACP。
bond_mode=active-backup
当您使用 active-backup 绑定模式配置绑定时,网络服务会将一个 NIC 处于待机状态。当活跃连接失败时,待机 NIC 会恢复网络操作。物理交换机仅显示一个 MAC 地址。这个模式不需要切换配置,当链接连接到独立的交换机时可以正常工作。这个模式不提供负载均衡。
lacp=[active | passive | off]
控制链路聚合控制协议(LACP)行为。只有某些交换机支持 LACP。如果您的交换机不支持 LACP,请使用 bond_mode=balance-slbbond_mode=active-backup
other-config:lacp-fallback-ab=true
如果 LACP 失败,将 active-backup 设置为绑定模式。
other_config:lacp-time=[fast | slow]
将 LACP heartbeat 设置为 1 秒 (fast) 或 30 秒 (slow)。默认设置会较慢。
other_config:bond-detect-mode=[miimon | carrier]
将链路检测设置为使用 miimon heartbeats (miimon)或监控载波(错误)。默认值为载体。
other_config:bond-miimon-interval=100
如果使用 miimon,请设置 heartbeat 间隔(毫秒)。
bond_updelay=1000
设置必须激活链接的时间间隔(毫秒),以防止出现问题。
other_config:bond-rebalance-interval=10000
设置流在绑定成员之间重新平衡的时间间隔(毫秒)。将此值设置为 0,以禁用绑定成员之间的流重新平衡。

12.5. 创建 Linux 绑定

您可以在网络接口模板中创建 linux 绑定。例如,您可以创建一个绑定两个接口的 linux 绑定:

...
          params:
            $network_config:
              network_config:
              - type: linux_bond
                name: bond1
                members:
                - type: interface
                  name: nic2
                - type: interface
                  name: nic3
                bonding_options: "mode=802.3ad lacp_rate=[fast|slow] updelay=1000 miimon=100"

bonding_options 参数为 Linux 绑定设置特定的绑定选项。

模式
设置绑定模式,示例中是 802.3ad 或 LACP 模式。有关 Linux 绑定模式的更多信息,请参阅 Red Hat Enterprise Linux 8 配置和管理网络指南中的 "流交换配置取决于绑定模式 "。
lacp_rate
定义 LACP 数据包是否每 1 秒发送,或者每 30 秒发送一次。
updelay
定义接口必须在用于流量前必须激活的最短时间。这种最低配置有助于缓解端口中断。
miimon
使用驱动程序的 MIIMON 功能监控端口状态的时间间隔(毫秒)。

使用以下附加示例作为配置您自己的 Linux 绑定的指南:

  • Linux 绑定设置为带有一个 VLAN 的 active-backup 模式:

    ....
              params:
                $network_config:
                  network_config:
                  - type: linux_bond
                    name: bond_api
                    bonding_options: "mode=active-backup"
                    use_dhcp: false
                    dns_servers:
                      get_param: DnsServers
                    members:
                    - type: interface
                      name: nic3
                      primary: true
                    - type: interface
                      name: nic4
    
                  - type: vlan
                    vlan_id:
                      get_param: InternalApiNetworkVlanID
                    device: bond_api
                    addresses:
                    - ip_netmask:
                        get_param: InternalApiIpSubnet
  • Linux 绑定设置为 802.3ad LACP 模式,带有一个 VLAN:

    ...
              params:
                $network_config:
                  network_config:
                -  type: ovs_bridge
                    name: br-tenant
                    use_dhcp: false
                    mtu: 9000
                    members:
                      - type: linux_bond
                        name: bond_tenant
                        bonding_options: "mode=802.3ad updelay=1000 miimon=100"
                        use_dhcp: false
                        dns_servers:
                          get_param: DnsServers
                        members:
                        - type: interface
                          name: p1p1
                          primary: true
                        - type: interface
                          name: p1p2
                      - type: vlan
                        device: bond_tenant
                        vlan_id: {get_param: TenantNetworkVlanID}
                        addresses:
                          -
                            ip_netmask: {get_param: TenantIpSubnet}

第 13 章 控制节点放置

默认情况下,director 会随机为每个角色选择节点,通常是根据节点的 profile 标签进行选择。但是,您还可以定义特定的节点放置。这在以下情况中很有用:

  • 分配特定的节点 ID,如 controller-0controller-1
  • 分配自定义主机名
  • 分配特定的 IP 地址
  • 分配特定的虚拟 IP 地址
注意

手动设置可预测 IP 地址、虚拟 IP 地址和端口,可以减轻分配池的需求。但是,建议为每个网络保留分配池,以便轻松扩展新节点。确保任何静态定义的 IP 地址不在分配池之外。

13.1. 分配特定节点 ID

您可以将节点 ID 分配给特定的节点,如 controller-0controller-1compute-0compute-1

流程

  1. 将 ID 分配为计算调度程序在部署时匹配的每个节点功能:

    openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <id>

    此命令将功能 node:controller-0 分配给节点。为所有节点使用唯一连续索引(从 0 开始)重复此模式。确保给定角色(Controller、Compute 或每个存储角色)的所有节点都相同,或者计算调度程序无法正确匹配功能。

  2. 创建 heat 环境文件(如 scheduler_hints_env.yaml),它使用调度程序提示与每个节点的功能匹配:

    parameter_defaults:
      ControllerSchedulerHints:
        'capabilities:node': 'controller-%index%'

    使用以下参数为其他角色类型配置调度程序提示:

    • Controller 节点的 ControllerSchedulerHints
    • ComputeSchedulerHints 用于 Compute 节点。
    • Block Storage 节点的 BlockStorageSchedulerHints
    • Object Storage 节点的 ObjectStorageSchedulerHints
    • Ceph Storage 节点的 CephStorageSchedulerHints
    • [ROLE]SchedulerHints,用于自定义角色。用角色名称替换 [ROLE]
  3. overcloud deploy 命令中包含 scheduler_hints_env.yaml 环境文件。
注意

节点放置优先于配置集匹配。为避免调度失败,请使用默认的 baremetal 类别进行部署,而不是为配置文件匹配的类别(计算控制):在环境文件中将对应的 flavor 参数设置为 baremetal:

parameter_defaults:
  OvercloudControllerFlavor: baremetal
  OvercloudComputeFlavor: baremetal

13.2. 分配自定义主机名

第 13.1 节 “分配特定节点 ID” 中的节点 ID 配置相结合,director 还可以为每个节点分配特定的自定义主机名。当您需要定义系统所在的位置(如 rack2-row12),匹配清单标识符或其他需要自定义主机名的情况时,这非常有用。

重要

不要在节点部署后重命名节点。在部署后重命名节点会导致实例管理问题。

流程

  • 在环境文件中使用 HostnameMap 参数,如来自 第 13.1 节 “分配特定节点 ID”scheduler_hints_env.yaml 文件:

    parameter_defaults:
      ControllerSchedulerHints:
        'capabilities:node': 'controller-%index%'
      ComputeSchedulerHints:
        'capabilities:node': 'compute-%index%'
      HostnameMap:
        overcloud-controller-0: overcloud-controller-prod-123-0
        overcloud-controller-1: overcloud-controller-prod-456-0
        overcloud-controller-2: overcloud-controller-prod-789-0
        overcloud-novacompute-0: overcloud-compute-prod-abc-0

    parameter_defaults 部分中定义 HostnameMap,并将每个映射设置为 heat 使用 HostnameFormat 参数(如 overcloud-controller-0)定义的原始主机名,第二个值是该节点所需的自定义主机名(overcloud-controller-prod-123-0)。

使用此方法和节点 ID 放置,以确保每个节点都有自定义主机名。

13.3. 分配可预测的 IP

为进一步控制生成的环境,director 可以使用每个网络上的特定 IP 地址分配 overcloud 节点。

流程

  1. 创建环境文件来定义预测 IP 寻址:

    $ touch ~/templates/predictive_ips.yaml
  2. ~/templates/predictive_ips.yaml 文件中创建一个 parameter_defaults 部分,并使用以下语法为每个节点定义预测 IP 寻址:

    parameter_defaults:
      <role_name>IPs:
        <network>:
        - <IP_address>
        <network>:
        - <IP_address>

    每个节点角色具有唯一参数。将 <role_name>IPs 替换为相关参数:

    • Controller 节点的 ControllerIP。
    • Compute 节点的 ComputeIP。
    • Ceph Storage 节点的 CephStorageIP
    • BlockStorageIPs 用于块存储节点。
    • 对象存储 节点的 SwiftStorageIP
    • [ROLE]IP 用于自定义角色。用角色名称替换 [ROLE]

      每个参数都是一个到地址列表的网络名称映射。每种网络类型必须至少包含与该网络上节点相同的地址。director 会按顺序分配地址。每种类型的第一个节点接收各自列表中的第一个地址,第二个节点接收各个各个列表中的第二个地址,依此类推。

      例如,如果要使用预测 IP 地址在 overcloud 中部署三个 Ceph Storage 节点,请使用以下示例语法:

      parameter_defaults:
        CephStorageIPs:
          storage:
          - 172.16.1.100
          - 172.16.1.101
          - 172.16.1.102
          storage_mgmt:
          - 172.16.3.100
          - 172.16.3.101
          - 172.16.3.102

      第一个 Ceph Storage 节点接收两个地址: 172.16.1.100 和 172.16.3.100。第二个地址接收 172.16.1.101 和 172.16.3.101,第三个则接收 172.16.1.102 和 172.16.3.102。相同的模式也适用于其他节点类型。

      要在 control plane 上配置可预测的 IP 地址,请将 /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml 文件复制到 stack 用户的 templates 目录中:

      $ cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml ~/templates/.

      使用以下参数,配置新的 ips-from-pool-ctlplane.yaml 文件。您可以将 control plane IP 地址声明与其他网络的 IP 地址声明组合,并仅使用一个文件来声明所有角色上所有网络的 IP 地址。您还可以使用可预测的 IP 地址进行 spine/leaf。每个节点必须有来自正确子网的 IP 地址。

      parameter_defaults:
        ControllerIPs:
          ctlplane:
          - 192.168.24.10
          - 192.168.24.11
          - 192.168.24.12
          internal_api:
          - 172.16.1.20
          - 172.16.1.21
          - 172.16.1.22
          external:
          - 10.0.0.40
          - 10.0.0.57
          - 10.0.0.104
        ComputeLeaf1IPs:
          ctlplane:
          - 192.168.25.100
          - 192.168.25.101
          internal_api:
          - 172.16.2.100
          - 172.16.2.101
        ComputeLeaf2IPs:
          ctlplane:
          - 192.168.26.100
          - 192.168.26.101
          internal_api:
          - 172.16.3.100
          - 172.16.3.101

      确定您选择的 IP 地址不在您在网络环境文件中定义的每个网络的分配池之外。例如,请确保 internal_api 分配在 InternalApiAllocationPools 范围之外,以避免自动与所选 IP 冲突。另外,确保 IP 分配不会与 VIP 配置冲突,对于标准的可预测 VIP 放置(请参阅 第 13.4 节 “分配可预测的虚拟 IP”)或外部负载均衡(请参阅 第 21.4 节 “配置外部负载均衡”)。

      重要

      如果删除了 overcloud 节点,请不要删除 IP 列表中的条目。IP 列表基于底层 heat 索引,即使删除节点也是如此。要指定列表中给定条目不再被使用,请将 IP 值替换为 DELETEDUNUSED 等值。不应从 IP 列表中删除条目,只应更改或添加。

  3. 要在部署期间应用此配置,请使用 openstack overcloud deploy 命令包括 predictive_ips.yaml 环境文件。

    重要

    如果使用网络隔离,请在 network-isolation.yaml 文件后包括 predictive_ips.yaml 文件:

    $ openstack overcloud deploy --templates \
      -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
      -e ~/templates/predictive_ips.yaml \
      [OTHER OPTIONS]

13.4. 分配可预测的虚拟 IP

除了为每个节点定义可预测的 IP 地址外,您还可以为集群服务定义可预测的虚拟 IP (VIP)。

流程

  • 编辑网络环境文件,并在 parameter_defaults 部分中添加 VIP 参数:

    parameter_defaults:
      ...
      # Predictable VIPs
      ControlFixedIPs: [{'ip_address':'192.168.201.101'}]
      InternalApiVirtualFixedIPs: [{'ip_address':'172.16.0.9'}]
      PublicVirtualFixedIPs: [{'ip_address':'10.1.1.9'}]
      StorageVirtualFixedIPs: [{'ip_address':'172.18.0.9'}]
      StorageMgmtVirtualFixedIPs: [{'ip_address':'172.19.0.9'}]
      RedisVirtualFixedIPs: [{'ip_address':'172.16.0.8'}]
      OVNDBsVirtualFixedIPs: [{'ip_address':'172.16.0.7'}]

    从对应的分配池范围之外,选择这些 IP。例如,为 InternalApiVirtualFixedIPs 选择一个 IP 地址,该地址没有在 InternalApiAllocationPools 范围内。

注意

此步骤只适用于使用默认内部负载均衡配置的 overcloud。如果要使用外部负载均衡器分配 VIP,请使用 Overcloud 指南中的专用外部负载平衡 中的步骤。

第 14 章 在 overcloud 公共端点中启用 SSL/TLS

默认情况下,overcloud 对 overcloud 服务使用未加密的端点。要在 overcloud 中启用 SSL/TLS,您必须配置 SSL/TLS 证书,并将它包含在 overcloud 部署命令中。

当您使用证书颁发机构(CA)解决方案时,您已有生产就绪的解决方案,如证书续订、证书撤销列表(CRL)和行业接受加密。有关使用 Red Hat Identity Manager (IdM)作为 CA 的信息,请参阅使用 Ansible 实施 TLS

您可以使用以下流程为公共 API 端点启用 SSL/TLS,内部和管理员 API 会保持未加密的状态。另外,如果您不使用 CA,则需要手动更新 SSL/TLS 证书。如需更多信息,请参阅 手动更新 SSL/TLS 证书

先决条件

14.1. 初始化签名主机

签名主机是使用证书颁发机构生成并签名新证书的主机。如果您从未在所选签名主机上创建 SSL 证书,您可能需要初始化该主机,让它能够为新证书签名。

步骤

  1. /etc/pki/CA/index.txt 文件包含所有签名证书的记录。请确定文件系统路径和 index.txt 文件已存在:

    $ sudo mkdir -p /etc/pki/CA
    $ sudo touch /etc/pki/CA/index.txt
  2. /etc/pki/CA/serial 文件标识下一个序列号,以用于下一个要签名的证书。检查是否存在此文件。如果此文件不存在,则使用新启动值创建新文件:

    $ echo '1000' | sudo tee /etc/pki/CA/serial

14.2. 创建证书颁发机构

一般情况下,您需要使用一个外部的证书认证机构来签发您的 SSL/TLS 证书。在某些情况下,您可能想使用自己的证书颁发机构。例如,您可能想拥有仅限内部使用的证书颁发机构。

步骤

  1. 生成密钥和证书对以充当证书颁发机构:

    $ openssl genrsa -out ca.key.pem 4096
    $ openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
  2. openssl req 命令会要求输入认证机构的详细信息。根据提示输入相关信息。这些命令创建一个称为 ca.crt.pem 的证书颁发机构文件。
  3. 将证书位置设置为 enable-tls.yaml 文件中的 PublicTLSCAFile 参数的值。当您将证书位置设置为 PublicTLSCAFile 参数的值时,请确保将 CA 证书路径添加到 clouds.yaml 身份验证文件中。

    parameter_defaults:
        PublicTLSCAFile: /etc/pki/ca-trust/source/anchors/cacert.pem

14.3. 将此证书颁发机构添加到客户端

对于旨在使用 SSL/TLS 通信的所有外部客户端,将证书颁发机构文件复制到需要访问 Red Hat OpenStack Platform 环境的每个客户端。

步骤

  1. 将证书颁发机构复制到客户端系统:

    $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
  2. 将证书颁发机构文件复制到每个客户端后,在每个客户端上运行以下命令,将证书添加到证书颁发机构信任捆绑包中:

    $ sudo update-ca-trust extract

14.4. 创建 SSL/TLS 密钥

在 OpenStack 环境中启用 SSL/TLS 需要一个 SSL/TLS 密钥来生成证书。

步骤

  1. 运行以下命令以生成 SSL/TLS 密钥 (server.key.pem):

    $ openssl genrsa -out server.key.pem 2048

14.5. 创建 SSL/TLS 证书签名请求

完成以下步骤以创建证书签名请求。

步骤

  1. 复制默认 OpenSSL 配置文件:

    $ cp /etc/pki/tls/openssl.cnf .
  2. 编辑新的 openssl.cnf 文件并配置要用于 director 的 SSL 参数。一个要修改的参数类型的示例包括:

    [req]
    distinguished_name = req_distinguished_name
    req_extensions = v3_req
    
    [req_distinguished_name]
    countryName = Country Name (2 letter code)
    countryName_default = AU
    stateOrProvinceName = State or Province Name (full name)
    stateOrProvinceName_default = Queensland
    localityName = Locality Name (eg, city)
    localityName_default = Brisbane
    organizationalUnitName = Organizational Unit Name (eg, section)
    organizationalUnitName_default = Red Hat
    commonName = Common Name
    commonName_default = 192.168.0.1
    commonName_max = 64
    
    [ v3_req ]
    # Extensions to add to a certificate request
    basicConstraints = CA:FALSE
    keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    subjectAltName = @alt_names
    
    [alt_names]
    IP.1 = 192.168.0.1
    DNS.1 = instack.localdomain
    DNS.2 = vip.localdomain
    DNS.3 = 192.168.0.1

    commonName_default 设置为以下条目之一:

    • 如果使用 IP 地址通过 SSL/TLS 访问 director,则使用 undercloud.conf 文件中的 undercloud_public_host 参数。
    • 如果使用完全限定域名通过 SSL/TLS 访问 director,则使用此域名。

    编辑 alt_names 部分,使其包含以下条目:

    • IP - 客户端用于通过 SSL 访问 director 的 IP 地址列表。
    • DNS - 客户端用于通过 SSL 访问 director 的域名列表。其中也包含公共 API IP 地址作为在 alt_names 部分末尾的 DNS 条目。
    注意

    有关 openssl.cnf 的更多信息,请运行 man openssl.cnf 命令。

  3. 运行以下命令以生成证书签名请求 (server.csr.pem):

    $ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

    确保使用 -key 选项包括 OpenStack SSL/TLS 密钥。

此命令生成 server.csr.pem 文件,这是证书签名请求。使用此文件创建 OpenStack SSL/TLS 证书。

14.6. 创建 SSL/TLS 证书

要为 OpenStack 环境生成 SSL/TLS 证书,必须存在以下文件:

openssl.cnf
指定 v3 扩展的自定义配置文件。
server.csr.pem
生成证书并使用 CA 对证书进行签名的证书签名请求。
ca.crt.pem
对证书进行签名的证书颁发机构。
ca.key.pem
证书颁发机构私钥。

步骤

  1. 运行以下命令,为 undercloud 或 overcloud 创建证书:

    $ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem

    这个命令使用以下选项:

    -config
    使用一个自定义配置文件,它是带有 v3 扩展的 openssl.cnf 文件。
    -extensions v3_req
    已启用的 v3 扩展。
    -days
    定义证书到期前的天数。
    -in'
    证书签名请求。
    -out
    生成的签名证书。
    -cert
    证书颁发机构文件。
    -keyfile
    证书颁发机构私钥。

此命令创建名为 server.crt.pem 的新证书。将此证书与 OpenStack SSL/TLS 密钥一起使用

14.7. 启用 SSL/TLS

要在 overcloud 中启用 SSL/TLS,您必须创建一个环境文件,其中包含 SSL/TLS 证书和私钥的参数。

流程

  1. 从 heat 模板集合中复制 enable-tls.yaml 环境文件:

    $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.
  2. 编辑此文件并对这些参数进行以下更改:

    SSLCertificate

    将证书文件的内容(server.crt.pem)复制到 SSLCertificate 参数:

    parameter_defaults:
      SSLCertificate: |
        -----BEGIN CERTIFICATE-----
        MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGS
        ...
        sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQ
        -----END CERTIFICATE-----
    重要

    证书内容为所有新行需要相同的缩进级别。

    SSLIntermediateCertificate

    如果您有中间证书,请将中间证书的内容复制到 SSLIntermediateCertificate 参数中:

    parameter_defaults:
      SSLIntermediateCertificate: |
        -----BEGIN CERTIFICATE-----
        sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvpBCwUAMFgxCzAJB
        ...
        MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQE
        -----END CERTIFICATE-----
    重要

    证书内容为所有新行需要相同的缩进级别。

    SSLKey

    将私钥(server.key.pem)的内容复制到 SSLKey 参数:

    parameter_defaults:
      ...
      SSLKey: |
        -----BEGIN RSA PRIVATE KEY-----
        MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO
        ...
        ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4X
        -----END RSA PRIVATE KEY-----
    重要

    私钥内容需要对所有新行的缩进级别相同。

14.8. 注入 root 证书

如果证书 signer 没有包括在 overcloud 镜像的默认信任存储中,您必须将证书颁发机构注入 overcloud 镜像。

流程

  1. 从 heat 模板集合中复制 inject-trust-anchor-hiera.yaml 环境文件:

    $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor-hiera.yaml ~/templates/.

编辑此文件并对这些参数进行以下更改:

CAMap

列出要注入 overcloud 的每个证书颁发机构内容(CA)。overcloud 需要用于为 undercloud 和 overcloud 签名的证书的 CA 文件。将 root 证书颁发机构文件(ca.crt.pem)的内容复制到一个条目。例如,您的 CAMap 参数可能类似如下:

parameter_defaults:
  CAMap:
    ...
    undercloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCS
        BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBw
        UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBA
        -----END CERTIFICATE-----
    overcloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        MIIDBzCCAe+gAwIBAgIJAIc75A7FD++DMA0GCS
        BAMMD3d3dy5leGFtcGxlLmNvbTAeFw0xOTAxMz
        Um54yGCARyp3LpkxvyfMXX1DokpS1uKi7s6CkF
        -----END CERTIFICATE-----
重要

证书颁发机构内容为所有新行都需要相同的缩进级别。

您还可以使用 CAMap 参数注入其他 CA。

14.9. 配置 DNS 端点

如果您使用 DNS 主机名通过 SSL/TLS 访问 overcloud,请将 /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml 文件复制到 /home/stack/templates 目录中。

注意

如果初始部署中不包含此环境文件,则无法使用 TLS-everywhere 架构重新部署。

为所有字段配置主机和域名,如果需要,为自定义网络添加参数:

CloudDomain
主机的 DNS 域。
CloudName
overcloud 端点的 DNS 主机名。
CloudNameCtlplane
provisioning 网络端点的 DNS 名称。
CloudNameInternal
内部 API 端点的 DNS 名称。
CloudNameStorage
存储端点的 DNS 名称。
CloudNameStorageManagement
存储管理端点的 DNS 名称。
DnsServers
要使用的 DNS 服务器列表。配置的 DNS 服务器必须包含配置 CloudName 的条目,它与公共 API 的 IP 地址匹配。

流程

  • 在新的或现有环境文件中,添加用于参数默认值的 DNS 服务器列表:

    parameter_defaults:
      DnsServers: ["10.0.0.254"]
      ....

14.10. 在创建 overcloud 的过程中添加环境文件

使用 -e 选项和部署命令 openstack overcloud deploy 在部署过程中包含环境文件。按照以下顺序添加本节中的环境文件:

  • 启用 SSL/TLS 的环境文件(enable-tls.yaml)
  • 设置 DNS 主机名的环境文件(custom-domain.yaml)
  • 注入 root 证书颁发机构(inject-trust-anchor-hiera.yaml的环境文件)
  • 设置公共端点映射的环境文件:

    • 如果使用 DNS 名称来访问公共端点,请使用 /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
    • 如果使用 IP 地址来访问公共端点,请使用 /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-ip.yaml

流程

  • 使用以下部署命令片断作为如何包含 SSL/TLS 环境文件的示例:
$ openstack overcloud deploy --templates \
[...]
-e /home/stack/templates/enable-tls.yaml \
-e ~/templates/custom-domain.yaml \
-e ~/templates/inject-trust-anchor-hiera.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml

14.11. 手动更新 SSL/TLS 证书

如果您使用自己的 SSL/TLS 证书(并非从 TLS-e)进程中自动生成的 SSL/TLS 证书,请完成以下步骤。

流程

  1. 使用以下内容编辑 heat 模板:

    • 编辑 enable-tls.yaml 文件并更新 SSLCertificateSSLKeySSLIntermediateCertificate 参数。
    • 如果您的证书颁发机构已更改,请编辑 inject-trust-anchor-hiera.yaml 文件并更新 CAMap 参数。
  2. 再次运行部署命令:

    $ openstack overcloud deploy --templates \
    [...]
    -e /home/stack/templates/enable-tls.yaml \
    -e ~/templates/custom-domain.yaml \
    -e ~/templates/inject-trust-anchor-hiera.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
  3. 在 director 上,为每个 Controller 运行以下命令:

    ssh heat-admin@<controller> sudo podman \
    restart $(podman ps --format="{{.Names}}" | grep -w -E 'haproxy(-bundle-.*-[0-9]+)?')

第 15 章 使用身份管理在内部和公共端点中启用 SSL/TLS

您可以在某些 overcloud 端点中启用 SSL/TLS。由于需要证书数量,director 可与 Red Hat Identity Management (IdM)服务器集成,以充当证书颁发机构并管理 overcloud 证书。

要检查 OpenStack 组件中 TLS 支持的状态,请参阅 TLS 启用状态列表

15.1. OpenStack 的身份管理(IdM)服务器建议

红帽提供了以下信息来帮助您集成 IdM 服务器和 OpenStack 环境。

有关为 IdM 安装准备 Red Hat Enterprise Linux 的详情,请参考 安装身份管理

运行 ipa-server-install 命令来安装和配置 IdM。您可以使用命令参数跳过交互式提示。使用以下建议,以便您的 IdM 服务器可以与 Red Hat OpenStack Platform 环境集成:

表 15.1. 参数建议

选项建议

--admin-password

请注意您提供的值。在配置 Red Hat OpenStack Platform 以使用 IdM 时,您需要这个密码。

--ip-address

请注意您提供的值。undercloud 和 overcloud 节点需要网络访问此 IP 地址。

--setup-dns

使用这个选项在 IdM 服务器中安装集成的 DNS 服务。undercloud 和 overcloud 节点使用 IdM 服务器进行域名解析。

--auto-forwarders

使用这个选项将 /etc/resolv.conf 中的地址用作 DNS 转发器。

--auto-reverse

使用这个选项解析 IdM 服务器 IP 地址的反向记录和区。如果没有可解析反向记录或区域,IdM 会创建反向区域。这简化了 IdM 部署。

--ntp-server, --ntp-pool

您可以使用这些选项或其中任何一个选项来配置 NTP 源。IdM 服务器和 OpenStack 环境必须具有正确的和同步时间。

您必须打开 IdM 所需的防火墙端口,以便与 Red Hat OpenStack Platform 节点通信。如需更多信息,请参阅打开 IdM 所需的端口

15.2. 使用 Ansible 实施 TLS-e

您可以使用新的 tripleo-ipa 方法在 overcloud 端点上启用 SSL/TLS,名称随处(TLS-e)。由于所需的证书数量,Red Hat OpenStack Platform 与 Red Hat Identity Management (IdM)集成。当您使用 tripleo-ipa 来配置 TLS-e 时,IdM 为证书颁发机构。

先决条件

确保 undercloud 的所有配置步骤(如创建 stack 用户)均已完成。如需了解更多详细信息,请参阅 Director 安装和使用

流程

使用以下步骤在新的 Red Hat OpenStack Platform 安装或您要使用 TLS-e 配置的现有部署中实施 TLS-e。如果您在预置备节点上部署带有 TLS-e 的 Red Hat OpenStack Platform,则必须使用此方法。

注意

如果您要为现有环境实施 TLS-e,则需要运行命令,如 openstack undercloud install,以及 openstack overcloud deploy。这些过程是幂等的,仅调整现有的部署配置以匹配更新的模板和配置文件。

  1. 配置 /etc/resolv.conf 文件:

    /etc/resolv.conf 中,在 undercloud 上设置适当的搜索域和名称服务器。例如,如果部署域是 example.com,并且 FreeIPA 服务器的域为 bigcorp.com,则将以下行添加到 /etc/resolv.conf:

    search example.com bigcorp.com
    nameserver $IDM_SERVER_IP_ADDR
  2. 安装所需的软件:

    sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel
  3. 使用特定于您的环境的值导出环境变量:

    export IPA_DOMAIN=bigcorp.com
    export IPA_REALM=BIGCORP.COM
    export IPA_ADMIN_USER=$IPA_USER
    export IPA_ADMIN_PASSWORD=$IPA_PASSWORD
    export IPA_SERVER_HOSTNAME=ipa.bigcorp.com
    export UNDERCLOUD_FQDN=undercloud.example.com
    export USER=stack
    export CLOUD_DOMAIN=example.com
    注意

    IdM 用户凭证必须是可以添加新主机和服务的管理员用户。

  4. 在 undercloud 上运行 undercloud-ipa-install.yaml ansible playbook:

    ansible-playbook \
    --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \
    /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml
  5. 将以下参数添加到 undercloud.conf

    undercloud_nameservers = $IDM_SERVER_IP_ADDR
    overcloud_domain_name = example.com
  6. 部署 undercloud:

    openstack undercloud install

验证

通过完成以下步骤验证 undercloud 是否已正确注册:

  1. 列出 IdM 中的主机:

    $ kinit admin
    $ ipa host-find
  2. 确认 undercloud 上存在 /etc/novajoin/krb5.keytab

    ls /etc/novajoin/krb5.keytab
注意

novajoin 目录名仅用于旧的命名目的。

在 overcloud 上配置 TLS-e

当您使用 TLS-e 部署 overcloud 时,来自 Undercloud 和 Overcloud 的 IP 地址将自动使用 IdM 注册。

注意

要禁用自动 IP 地址注册,将 IDMModifyDNS heat 参数设置为 false:

parameter_defaults:
    ....
    IdMModifyDNS: false
  1. 在部署 overcloud 之前,创建一个 YAML 文件 tls-parameters.yaml,其内容类似于下方所示:您选择的值将适合您的环境:

    parameter_defaults:
        DnsSearchDomains: ["example.com"]
        DnsServers: ["192.168.1.13"]
        CloudDomain: example.com
        CloudName: overcloud.example.com
        CloudNameInternal: overcloud.internalapi.example.com
        CloudNameStorage: overcloud.storage.example.com
        CloudNameStorageManagement: overcloud.storagemgmt.example.com
        CloudNameCtlplane: overcloud.ctlplane.example.com
        IdMServer: freeipa-0.redhat.local
        IdMDomain: redhat.local
        IdMInstallClientPackages: False
    
    resource_registry:
          OS::TripleO::Services::IpaClient: /usr/share/openstack-tripleo-heat-templates/deployment/ipa/ipaservices-baremetal-ansible.yaml
    • DnsServers 参数应该有一个值来反映 IdM 服务器的 IP 地址。
    • 如果 IdM 服务器的域与云域不同,请将它包括在 DnsSearchDomains 参数中。例如: DnsSearchDomains: ["example.com", "bigcorp.com"]
    • 如果预置备的节点,请将 IDMInstallClientPackages 参数的值设置为 true,以在 overcloud 节点上安装必要的软件包。
    • 当使用复制的 IdM 环境时,您可以为 IdmServer 参数设置多个以逗号分隔的值。如需有关 IdM 副本的更多信息,请参阅安装 IdM 副本
    • OS::TripleO::Services::IpaClient 参数的显示值会覆盖 enable-internal-tls.yaml 文件中的默认设置。您必须确保 tls-parameters.yaml 文件在 openstack overcloud deploy 命令中遵循 enable-internal-tls.yaml 文件。
    • 如果您正在运行一个带有 cinder 配置为 active-active 的分布式计算节点(DCN)架构,您必须将 EnableEtcdInternalTLS 参数设置为 true
  2. 部署 overcloud。您需要在部署命令中包含 tls-parameters.yaml:

    DEFAULT_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/
    CUSTOM_TEMPLATES=/home/stack/templates
    
    openstack overcloud deploy \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/tls-everywhere-endpoints-dns.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/services/haproxy-public-tls-certmonger.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/enable-internal-tls.yaml \
    -e ${CUSTOM_TEMPLATES}/tls-parameters.yaml \
    ...
  3. 通过查询 keystone 以获取端点列表确认每个端点都在使用 HTTPS:

    openstack endpoint list

15.3. 使用 novajoin 在 Red Hat Identity Manager (IdM)中注册节点

novajoin 是用来将节点注册到 Red Hat Identity Manager (IdM)的默认工具,作为部署过程的一部分。红帽建议在默认 novajoin 解决方案中使用基于 ansible -ipa 的新解决方案,使用 TLS-e 配置 undercloud 和 overcloud。如需更多信息,请参阅使用 Ansible 实施 TLS

在继续进行其余 IdM 集成前,您必须执行注册过程。注册过程包括以下步骤:

  1. 将 undercloud 节点添加到证书颁发机构(CA)
  2. 将 undercloud 节点添加到 IdM
  3. 可选:将 IdM 服务器设置为 overcloud 的 DNS 服务器
  4. 准备环境文件并部署 overcloud
  5. 测试 IdM 和 RHOSP 中的 overcloud 注册
  6. 可选:在 IdM 中为 novajoin 添加 DNS 条目
注意

使用 novajoin 的 IdM 注册目前仅适用于 undercloud 和 overcloud 节点。overcloud 实例的 novajoin 集成应该在以后的版本中被支持。

15.4. 将 undercloud 节点添加到证书颁发机构

在部署 overcloud 之前,通过在 undercloud 节点上安装 python3-novajoin 软件包并运行 novajoin-ipa-setup 脚本,将 undercloud 添加到证书颁发机构(CA)中。

流程

  1. 在 undercloud 节点上,安装 python3-novajoin 软件包:

    $ sudo dnf install python3-novajoin
  2. 在 undercloud 节点上,运行 novajoin-ipa-setup 脚本,并调整值以适合您的部署:

    $ sudo /usr/libexec/novajoin-ipa-setup \
        --principal admin \
        --password <IdM admin password> \
        --server <IdM server hostname> \
        --realm <realm> \
        --domain <overcloud cloud domain> \
        --hostname <undercloud hostname> \
        --precreate

    使用生成的一次性密码(OTP)注册 undercloud。

15.5. 将 undercloud 节点添加到 Red Hat Identity Manager (IdM)

将 undercloud 节点添加到证书颁发机构(CA)后,使用 IdM 注册 undercloud 并配置 novajoin。在 undercloud.conf 文件的 [DEFAULT] 部分中配置下列设置。

流程

  1. 启用 novajoin 服务:

    [DEFAULT]
    enable_novajoin = true
  2. 设置一次性密码(OTP),以便您可以使用 IdM 注册 undercloud 节点:

    ipa_otp = <otp>
  3. 将 overcloud 的域名设置为由 neutron 的 DHCP 服务器提供:

    overcloud_domain_name = <domain>
  4. 设置 undercloud 的主机名:

    undercloud_hostname = <undercloud FQDN>
  5. 将 IdM 设置为 undercloud 的名称服务器:

    undercloud_nameservers = <IdM IP>
  6. 对于较大的环境,请查看 novajoin 连接超时值。在 undercloud.conf 文件中,添加对名为 undercloud-timeout.yaml 的新文件的引用:

    hieradata_override = /home/stack/undercloud-timeout.yaml

    undercloud-timeout.yaml 中添加以下选项。您可以指定超时值(以秒为单位),例如 5

    nova::api::vendordata_dynamic_connect_timeout: <timeout value>
    nova::api::vendordata_dynamic_read_timeout: <timeout value>
  7. 可选: 如果您希望本地 openSSL 证书颁发机构为 director 中的公共端点生成 SSL 证书,请将 generate_service_certificate 参数设置为 true

    generate_service_certificate = true
  8. 保存 undercloud.conf 文件。
  9. 运行 undercloud 部署命令,将更改应用到现有的 undercloud:

    $ openstack undercloud install

验证

通过完成以下步骤验证 undercloud 是否已正确注册:

  1. 列出 IdM 中的主机:

    $ kinit admin
    $ ipa host-find
  2. 确认 undercloud 上存在 /etc/novajoin/krb5.keytab

    ls /etc/novajoin/krb5.keytab

15.6. 将 Red Hat Identity Manager (IdM)设置为 overcloud 的 DNS 服务器

要启用 IdM 环境的自动检测并更容易注册,将 IdM 设置为您的 DNS 服务器。这个过程是可选的,但推荐使用。

流程

  1. 连接到 undercloud:

    $ source ~/stackrc
  2. 将 control plane 子网配置为使用 IdM 作为 DNS 名称服务器:

    $ openstack subnet set ctlplane-subnet --dns-nameserver  <idm_server_address>
  3. 在环境文件中设置 DnsServers 参数以使用您的 IdM 服务器:

    parameter_defaults:
      DnsServers: ["<idm_server_address>"]

    此参数通常在自定义 network-environment.yaml 文件中定义。

15.7. 准备环境文件并使用 novajoin 注册部署 overcloud

要使用 IdM 集成部署 overcloud,您需要创建和编辑环境文件,将 overcloud 配置为根据 overcloud 中定义的域参数 CloudDomainCloudName 使用自定义域参数 CloudName。然后,您可以使用所有环境文件和部署所需的额外环境文件部署 overcloud。

流程

  1. 创建 /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml 环境文件的副本:

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml \
      /home/stack/templates/custom-domain.yaml
  2. 编辑 /home/stack/templates/custom-domain.yaml 环境文件,并将 CloudDomainCloudName* 值设置为适合您的部署:

    parameter_defaults:
      CloudDomain: lab.local
      CloudName: overcloud.lab.local
      CloudNameInternal: overcloud.internalapi.lab.local
      CloudNameStorage: overcloud.storage.lab.local
      CloudNameStorageManagement: overcloud.storagemgmt.lab.local
      CloudNameCtlplane: overcloud.ctlplane.lab.local
  3. 选择适合您的环境的 TLS 的实施:

    • 使用 enable-tls.yaml 环境文件来保护使用自定义证书的外部端点:

      1. /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml 复制到 /home/stack/templates
      2. 修改 /home/stack/enable-tls.yaml 环境文件,使其包含您的自定义证书和密钥。
      3. 在您的部署中包含以下环境文件,以保护内部和外部端点:

        • enable-internal-tls.yaml
        • tls-every-endpoints-dns.yaml
        • custom-domain.yaml
        • enable-tls.yaml

          openstack overcloud deploy \
            --templates \
            -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
            -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
            -e /home/stack/templates/custom-domain.yaml \
            -e /home/stack/templates/enable-tls.yaml
    • 使用 haproxy-public-tls-certmonger.yaml 环境文件使用 IdM 发布的证书保护外部端点。对于这个实现,您必须为 novajoin 使用的 VIP 端点创建 DNS 条目:

      1. 您必须为 novajoin 使用的 VIP 端点创建 DNS 条目。识别位于自定义 network-environment.yaml 文件中的 overcloud 网络,它位于 '/home/stack/templates 中

        parameter_defaults:
            ControlPlaneDefaultRoute: 192.168.24.1
            ExternalAllocationPools:
            -   end: 10.0.0.149
                start: 10.0.0.101
            InternalApiAllocationPools:
            -   end: 172.17.1.149
                start: 172.17.1.10
            StorageAllocationPools:
            -   end: 172.17.3.149
                start: 172.17.3.10
            StorageMgmtAllocationPools:
            -   end: 172.17.4.149
                start: 172.17.4.10
      2. 在 heat 模板中为每个 overcloud 网络创建虚拟 IP 地址列表,如 /home/stack/public_vib.yaml

        parameter_defaults:
            ControlFixedIPs: [{'ip_address':'192.168.24.101'}]
            PublicVirtualFixedIPs: [{'ip_address':'10.0.0.101'}]
            InternalApiVirtualFixedIPs: [{'ip_address':'172.17.1.101'}]
            StorageVirtualFixedIPs: [{'ip_address':'172.17.3.101'}]
            StorageMgmtVirtualFixedIPs: [{'ip_address':'172.17.4.101'}]
            RedisVirtualFixedIPs: [{'ip_address':'172.17.1.102'}]
      3. 在 IdM 中为每个 VIP 添加 DNS 条目,根据需要在 IdM 中添加区域:

        ipa dnsrecord-add lab.local overcloud --a-rec 10.0.0.101
        ipa dnszone-add ctlplane.lab.local
        ipa dnsrecord-add ctlplane.lab.local overcloud --a-rec 192.168.24.101
        ipa dnszone-add internalapi.lab.local
        ipa dnsrecord-add internalapi.lab.local overcloud --a-rec 172.17.1.101
        ipa dnszone-add storage.lab.local
        ipa dnsrecord-add storage.lab.local overcloud --a-rec 172.17.3.101
        ipa dnszone-add storagemgmt.lab.local
        ipa dnsrecord-add storagemgmt.lab.local overcloud --a-rec 172.17.4.101
      4. 在您的部署中包含以下环境文件,以保护内部和外部端点:

        • enable-internal-tls.yaml
        • tls-everywhere-endpoints-dns.yaml
        • haproxy-public-tls-certmonger.yaml
        • custom-domain.yaml
        • public_vib.yaml

          openstack overcloud deploy \
            --templates \
             -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
             -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
             -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml \
             -e /home/stack/templates/custom-domain.yaml \
             -e /home/stack/templates/public-vip.yaml
注意

您不能使用 novajoin 在预先存在的部署中实施 TLS (TLS-e)。

第 16 章 配置镜像导入方法和共享暂存区域

OpenStack Image 服务(glance)的默认设置由安装 Red Hat OpenStack Platform 时使用的 heat 模板决定。镜像服务 heat 模板是 deployment/glance/glance-api-container-puppet.yaml

您可以使用以下方法导入镜像:

web-download
使用 web-download 方法从 URL 导入镜像。
glance-direct
使用 glance-direct 方法从本地卷导入镜像。

16.1. 创建并部署 glance-settings.yaml 文件

使用自定义环境文件配置导入参数。这些参数覆盖核心 heat 模板集合中存在的默认值。示例环境内容包含可互操作镜像导入的参数。

parameter_defaults:
  # Configure NFS backend
  GlanceBackend: file
  GlanceNfsEnabled: true
  GlanceNfsShare: 192.168.122.1:/export/glance

  # Enable glance-direct import method
  GlanceEnabledImportMethods: glance-direct,web-download

  # Configure NFS staging area (required for glance-direct import method)
  GlanceStagingNfsShare: 192.168.122.1:/export/glance-staging

GlanceBackendGlanceNfsEnabledGlanceNfsShare 参数在 高级 Overcloud 自定义指南中的存储配置部分中定义

使用两个新参数实现可互操作镜像导入,以定义导入方法和共享 NFS 暂存区域。

GlanceEnabledImportMethods
定义可用的导入方法、web-download (默认)和 glance-direct。只有在您想要启用 web-download 以外的其他方法时才需要这个参数。
GlanceStagingNfsShare
配置 glance-direct 导入方法使用的 NFS 暂存区域。此空间可以在高可用性群集配置中的节点之间共享。如果要使用此参数,还必须将 GlanceNfsEnabled 参数设置为 true

流程

  1. 创建一个新文件,如 glance-settings.yaml。使用示例中的语法来填充此文件。
  2. openstack overcloud deploy 命令中包含 glance-settings.yaml 文件,以及与部署相关的任何其他环境文件:

    $ openstack overcloud deploy --templates -e glance-settings.yaml

有关使用环境文件的更多信息,请参阅高级 Overcloud 自定义指南中的 Overcloud 中包含的环境文件部分。

16.2. 控制 web-import 源

您可以通过在可选 glance-image-import.conf 文件中添加 URI blocklist 和 allowlists 来限制 web-import 镜像下载的来源。

您可以在三个级别允许或阻止镜像源 URI:

  • 方案(allowed_schemes、allowed_schemes)
  • 主机(allowed_hosts,allowed_hosts)
  • 端口(allowed_ports,allowed_ports)

如果您在任何级别上同时指定 allowlist 和 blocklist,则允许列表将实现,并忽略 blocklist。

Image 服务(glance)应用以下决策逻辑来验证镜像源 URI:

  1. 检查方案。

    1. 缺少方案: reject
    2. 如果存在允许列表,且该方案没有包括在 allowlist: reject 中。否则,跳过 C 并继续到 2。
    3. 如果存在 blocklist,且该方案存在于 blocklist 中: reject.
  2. 检查主机名。

    1. 缺少主机名: reject
    2. 如果存在 allowlist,且 allowlist: reject 中没有主机名。否则,跳过 C 并继续到 3。
    3. 如果存在 blocklist,且主机名位于 blocklist: reject 中。
  3. 如果 URI 中存在端口,则检查端口。

    1. 如果存在 allowlist,且 allowlist: reject 中不存在该端口。否则,跳过 B 并继续至 4。
    2. 如果存在 blocklist,且该端口位于 blocklist: reject 中。
  4. URI 被接受为有效。

如果您允许某一方案,只需将其添加到 allowlist 中,或者不要将其添加到 blocklist 中,则允许任何使用该方案的默认端口的 URI (在 URI 中包括端口)。如果 URI 中包含端口,则 URI 会根据默认的决策逻辑进行验证。

16.3. 镜像导入示例

例如,FTP 的默认端口为 21。因为 ftp 是一个允许列表,所以允许 URL ftp://example.org/some/resource,但由于 21 不在端口允许列表中,到同一资源的 URL ftp://example.org:21/some/resource 会被拒绝。

allowed_schemes = [http,https,ftp]
disallowed_schemes = []
allowed_hosts = []
disallowed_hosts = []
allowed_ports = [80,443]
disallowed_ports = []

16.4. 默认镜像导入 blocklist 和 allowlist 设置

glance-image-import.conf 文件是一个可选文件,包含以下默认选项:

  • allowed_schemes - [http, https]
  • disallowed_schemes - empty list
  • allowed_hosts - 空列表
  • disallowed_hosts - empty list
  • allowed_ports - [80, 443]
  • disallowed_ports - empty list

如果使用默认值,最终用户只能使用 httphttps 方案访问 URI。用户可以指定的唯一端口是 80443。用户不必指定端口,但是如果端口,则必须是 80443。

您可以在镜像服务源代码树中的 etc/ 子目录中找到 glance-image-import.conf 文件。确保您正处于 Red Hat OpenStack Platform 发行版本的正确分支中。

16.5. 在镜像导入时注入元数据来控制虚拟机启动的位置

最终用户可以将镜像上传到镜像服务,并使用这些镜像启动虚拟机。这些用户提供的(非管理员)镜像必须在特定的一组计算节点上启动。实例分配给计算节点的分配由镜像元数据属性控制。

Image Property Injection 插件在导入过程中将元数据属性注入镜像。通过编辑 glance-image-import.conf 文件的 [image_import_opts] 和 [inject_metadata_properties] 部分来指定属性。

要启用 Image Property Injection 插件,请将以下行添加到 [image_import_opts] 部分:

[image_import_opts]
image_import_plugins = [inject_image_metadata]

要将元数据注入限制到特定用户提供的镜像,请设置 ignore_user_roles 参数。例如,使用以下配置将 property1 的值和 property2 的两个值注入任何非 admin 用户下载的镜像中。

[DEFAULT]
[image_conversion]
[image_import_opts]
image_import_plugins = [inject_image_metadata]
[import_filtering_opts]
[inject_metadata_properties]
ignore_user_roles = admin
inject = PROPERTY1:value,PROPERTY2:value;another value

参数 ignore_user_roles 是插件忽略的身份服务(keystone)角色的逗号分隔列表。这意味着,如果进行镜像导入调用的用户具有这些角色,则插件不会将任何属性注入到镜像中。

参数 注入 是一个以逗号分隔的属性和值列表,它们被注入到导入的镜像的镜像记录中。每个属性和值都必须用冒号 (':') 分开。

您可以在镜像服务源代码树中的 etc/ 子目录中找到 glance-image-import.conf 文件。确保您正处于 Red Hat OpenStack Platform 发行版本的正确分支中。

第 17 章 存储配置

本章概述了可用于配置 overcloud 存储选项的几种方法。

重要

overcloud 将本地和 LVM 存储用于默认存储选项。由于企业级 overcloud 不支持这些选项,所以您必须将 overcloud 配置为使用本章中详述的其中一个存储选项。

17.1. 配置 NFS 存储

您可以将 overcloud 配置为使用共享 NFS 存储。

17.1.1. 支持的配置和限制

支持的 NFS 存储

  • 红帽建议您使用经过认证的存储后端和驱动程序。红帽不推荐使用来自通用 NFS 后端的 NFS 存储,因为它的功能仅限于经过认证的存储后端和驱动程序。例如,通用 NFS 后端不支持卷加密和卷 multi-attach 等功能。有关支持的驱动程序的详情,请查看 红帽生态系统目录
  • 对于 Block Storage (cinder)和计算(nova)服务,必须使用 NFS 版本 4.0 或更高版本。Red Hat OpenStack Platform (RHOSP)不支持较早版本的 NFS。

不支持的 NFS 配置

  • RHOSP 不支持 NetApp 功能 NAS 安全,因为它会干扰正常卷操作。director 默认禁用该功能。因此,不要编辑以下 heat 参数来控制 NFS 后端还是 NetApp NFS Block Storage 后端是否支持 NAS 安全:

    • CinderNetappNasSecureFileOperations
    • CinderNetappNasSecureFilePermissions
    • CinderNasSecureFileOperations
    • CinderNasSecureFilePermissions

使用 NFS 共享时的限制

  • 如果后端是 NFS 共享,则无法调整大小或重新构建具有交换磁盘的实例。

17.1.2. 配置 NFS 存储

您可以将 overcloud 配置为使用共享 NFS 存储。

流程

  1. 创建环境文件来配置 NFS 存储,如 nfs_storage.yaml
  2. 在新环境文件中添加以下参数来配置 NFS 存储:

    parameter_defaults:
      CinderEnableIscsiBackend: false
      CinderEnableNfsBackend: true
      GlanceBackend: file
      CinderNfsServers: 192.0.2.230:/cinder
      GlanceNfsEnabled: true
      GlanceNfsShare: 192.0.2.230:/glance
    注意

    不要配置 CinderNfsMountOptionsGlanceNfsOptions 参数,因为其默认值启用了适合大多数 Red Hat OpenStack Platform (RHOSP)环境的 NFS 挂载选项。您可以在 environments/storage/glance-nfs.yaml 文件中看到 GlanceNfsOptions 参数的值。如果您在配置多个服务共享同一个 NFS 服务器时遇到问题,请联系红帽支持团队。

  3. 使用其他环境文件,将您的 NFS 存储环境文件添加到堆栈中,并部署 overcloud:

    (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -e /home/stack/templates/nfs_storage.yaml

17.1.3. 配置外部 NFS 共享进行转换

当块存储服务(cinder)在 overcloud Controller 节点上执行镜像格式转换时,且空间有限,大型镜像服务(glance)镜像转换可能会导致完全使用节点 root 磁盘空间。您可以使用外部 NFS 共享来转换,以防止完全填写节点上的空间。

控制外部 NFS 共享配置的两个 director heat 参数:

  • CinderImageConversionNfsShare
  • CinderImageConversionNfsOptions

流程

  1. stack 用户身份登录 undercloud,再提供 stackrc 凭据文件。

    $ source ~/stackrc
  2. 在新的或现有存储相关的环境文件中,添加关于外部 NFS 共享的信息。

    parameter_defaults:
      CinderImageConversionNfsShare: 192.168.10.1:/convert
    注意

    控制 NFS 挂载选项的 CinderImageConversionNfsOptions 参数的默认值足以满足大多数环境。

  3. 在 openstack overcloud deploy 命令中包含新配置的环境文件,以及与您环境相关的任何其他环境文件。

    $ openstack overcloud deploy \
    --templates \
    …
    -e <existing_overcloud_environment_files> \
    -e <new_environment_file> \
    …
    • 使用 <existing_overcloud_environment_files> 属于现有部署一部分的环境文件列表替换。
    • <new_environment_file > 替换为包含 NFS 共享配置的新的或编辑的环境文件。

17.2. 配置 Ceph Storage

使用以下方法之一将 Red Hat Ceph Storage 集成到 Red Hat OpenStack Platform overcloud 中。

使用自己的 Ceph Storage 集群创建 overcloud
您可以在 overcloud 创建过程中创建 Ceph Storage 集群。director 可以创建一组使用 Ceph OSD 存储数据的 Ceph Storage 节点。director 还会在 overcloud Controller 节点上安装 Ceph Monitor 服务。这意味着,如果组织创建具有三个高可用性 Controller 节点的 overcloud,Ceph Monitor 也会变成高度可用的服务。有关更多信息,请参阅使用容器化 Red Hat Ceph 部署 Overcloud
将现有的 Ceph Storage 集群集成到 overcloud 中
如果您有一个现有的 Ceph Storage 集群,可以在部署期间将此集群整合到 Red Hat OpenStack Platform overcloud 中。这意味着您可以在 overcloud 配置之外管理并扩展集群。有关更多信息,请参阅将 Overcloud 与现有 Red Hat Ceph 集群集成

17.3. 使用外部对象存储集群

您可以通过禁用 Controller 节点上的默认对象存储服务部署来重复使用外部 OpenStack Object Storage (swift)集群。这将禁用对象存储的代理和存储服务,并将 haproxy 和 OpenStack Identify (keystone)配置为使用给定的外部对象存储端点。

注意

您必须手动管理外部 Object Storage (swift)集群上的用户帐户。

先决条件

  • 您需要外部 Object Storage 集群的端点 IP 地址和外部 Object Storage proxy-server.conf 文件中的 authtoken 密码。您可以使用 openstack endpoint list 命令查找此信息。

流程

  1. 创建包含以下内容的新文件 swift-external-params.yaml

    • 使用外部代理的 IP 地址和端口替换 EXTERNAL.IP:PORT
    • 使用 SwiftPassword 行上的外部代理的 authtoken 密码替换 AUTHTOKEN

      parameter_defaults:
        ExternalPublicUrl: 'https://EXTERNAL.IP:PORT/v1/AUTH_%(tenant_id)s'
        ExternalInternalUrl: 'http://192.168.24.9:8080/v1/AUTH_%(tenant_id)s'
        ExternalAdminUrl: 'http://192.168.24.9:8080'
        ExternalSwiftUserTenant: 'service'
        SwiftPassword: AUTHTOKEN
  2. 将此文件保存为 swift-external-params.yaml
  3. 使用以下外部对象存储服务环境文件以及与部署相关的任何其他环境文件,部署 overcloud:

    openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml \
    -e swift-external-params.yaml

17.4. 配置 Ceph 对象存储以使用外部 Ceph 对象网关

Red Hat OpenStack Platform (RHOSP) Director 支持将外部 Ceph 对象网关(RGW)配置为对象存储服务。要使用外部 RGW 服务进行身份验证,您必须配置 RGW 以验证 Identity 服务(keystone)中的用户及其角色。

有关如何配置外部 Ceph 对象网关的更多信息,请参阅 Using Keystone with the Ceph Object Gateway Guide 中的 Configuring the Ceph Object Gateway to use Keystone authentication

流程

  1. 以下参数_defaults 添加到自定义环境文件,如 swift-external-params.yaml,并调整值以适合您的部署:

    parameter_defaults:
       ExternalSwiftPublicUrl: 'http://<Public RGW endpoint or loadbalancer>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftInternalUrl: 'http://<Internal RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftAdminUrl: 'http://<Admin RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftUserTenant: 'service'
       SwiftPassword: 'choose_a_random_password'
    注意

    示例代码片段包含的参数值,可能与您在环境中使用的值不同:

    • 远程 RGW 实例侦听的默认端口为 8080。端口可能会因配置外部 RGW 的配置而有所不同。
    • overcloud 中创建的 swift 用户使用 SwiftPassword 参数所定义的密码。您必须将外部 RGW 实例配置为使用同密码相同的密码,以便使用 rgw_keystone_admin_password 进行身份服务进行身份验证。
  2. 将以下代码添加到 Ceph 配置文件中,将 RGW 配置为使用 Identity 服务。替换变量值以适合您的环境:

        rgw_keystone_api_version = 3
        rgw_keystone_url = http://<public Keystone endpoint>:5000/
        rgw_keystone_accepted_roles = member, Member, admin
        rgw_keystone_accepted_admin_roles = ResellerAdmin, swiftoperator
        rgw_keystone_admin_domain = default
        rgw_keystone_admin_project = service
        rgw_keystone_admin_user = swift
        rgw_keystone_admin_password = <password_as_defined_in_the_environment_parameters>
        rgw_keystone_implicit_tenants = true
        rgw_keystone_revocation_interval = 0
        rgw_s3_auth_use_keystone = true
        rgw_swift_versioning_enabled = true
        rgw_swift_account_in_url = true
    注意

    director 默认在身份服务中创建以下角色和用户:

    • rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
    • rgw_keystone_admin_domain: default
    • rgw_keystone_admin_project: service
    • rgw_keystone_admin_user: swift
  3. 使用与部署相关的任何其他环境文件部署 overcloud:

    openstack overcloud deploy --templates \
    -e <your_environment_files>
    -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml
    -e swift-external-params.yaml

验证

  1. stack 用户的身份登录 undercloud。
  2. 获取 overcloudrc 文件:

    $ source ~/stackrc
  3. 验证身份服务(keystone)中是否存在端点:

    $ openstack endpoint list --service object-store
    
    +---------+-----------+-------+-------+---------+-----------+---------------+
    | ID | Region    | Service Name | Service Type | Enabled | Interface | URL |
    +---------+-----------+-------+-------+---------+-----------+---------------+
    | 233b7ea32aaf40c1ad782c696128aa0e | regionOne | swift | object-store | True    | admin     | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
    | 4ccde35ac76444d7bb82c5816a97abd8 | regionOne | swift | object-store | True    | public    | https://192.168.24.2:13808/v1/AUTH_%(project_id)s |
    | b4ff283f445348639864f560aa2b2b41 | regionOne | swift | object-store | True    | internal  | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
    +---------+-----------+-------+-------+---------+-----------+---------------+
  4. 创建测试容器:

    $ openstack container create <testcontainer>
    +----------------+---------------+------------------------------------+
    | account | container | x-trans-id |
    +----------------+---------------+------------------------------------+
    | AUTH_2852da3cf2fc490081114c434d1fc157 | testcontainer | tx6f5253e710a2449b8ef7e-005f2d29e8 |
    +----------------+---------------+------------------------------------+
  5. 创建配置文件以确认您可以将数据上传到容器中:

    $ openstack object create testcontainer undercloud.conf
    +-----------------+---------------+----------------------------------+
    | object          | container     | etag                             |
    +-----------------+---------------+----------------------------------+
    | undercloud.conf | testcontainer | 09fcffe126cac1dbac7b89b8fd7a3e4b |
    +-----------------+---------------+----------------------------------+
  6. 删除测试容器:

    $ openstack container delete -r <testcontainer>

17.5. 为镜像服务配置 cinder 后端

使用 GlanceBackend 参数设置镜像服务用来存储镜像的后端。

重要

您可以为项目创建的默认最大数量为 10。

流程

  1. 要将 cinder 配置为镜像服务后端,请在环境文件中添加以下行:

    parameter_defaults:
      GlanceBackend: cinder
  2. 如果启用了 cinder 后端,则默认设置以下参数和值:

    cinder_store_auth_address = http://172.17.1.19:5000/v3
    cinder_store_project_name = service
    cinder_store_user_name = glance
    cinder_store_password = ****secret****
  3. 要使用自定义用户名,或者 cinder_store_ 参数的任何自定义值,请将 ExtraConfig 参数添加到 parameter_defaults 中,并包含您的自定义值:

    ExtraConfig:
        glance::config::api_config:
          glance_store/cinder_store_auth_address:
            value: "%{hiera('glance::api::authtoken::auth_url')}/v3"
          glance_store/cinder_store_user_name:
            value: <user-name>
          glance_store/cinder_store_password:
            value: "%{hiera('glance::api::authtoken::password')}"
          glance_store/cinder_store_project_name:
            value: "%{hiera('glance::api::authtoken::project_name')}"

17.6. 配置附加到一个实例的存储设备的最大数量

默认情况下,您可以将无限数量的存储设备附加到单个实例。要限制最大设备数量,请在 Compute 环境文件中添加 max_disk_devices_to_attach 参数。使用以下示例将 max_disk_devices_to_attach 的值改为 "30:

parameter_defaults:
   ComputeExtraConfig:
          nova::config::nova_config:
            compute/max_disk_devices_to_attach:
                value: '30'

指南和注意事项

  • 实例支持的存储磁盘数量取决于磁盘使用的总线。例如,IDE 磁盘总线仅限于 4 个附加的设备。
  • 在带有活跃实例的 Compute 节点上更改 max_disk_devices_to_attach 时,如果最大数量低于已连接到实例的设备数,则可能会导致重建失败。例如,如果实例 A 关联了 26 个设备,并且您将 max_disk_devices_to_attach 更改为 20,则重建实例 A 的请求将失败。
  • 在冷迁移过程中,只有您要迁移的实例在源上强制配置的存储设备数。移动之前不会检查目的地。这意味着,如果 Compute 节点 A 具有 26 个附加磁盘设备,并且 Compute 节点 B 配置最多 20 个附加磁盘设备,则带有 26 个连接的实例的冷迁移(从 Compute 节点 A 到 Compute 节点 B)的冷迁移会成功。但是,后续请求在 Compute 节点 B 中重建实例会失败,因为已经附加了 26 个设备,超过配置的最大值 20。
  • 在 shelved 已卸载的实例中不会强制配置的最大值,因为它们没有 Compute 节点。
  • 将大量磁盘设备附加到实例可能会降低实例的性能。根据您的环境支持的边界调整最大数量。
  • 具有机器类型 Q35 的实例可以最多附加 500 个磁盘设备。

17.7. 使用镜像服务缓存提高可扩展性

使用 glance-api 缓存机制将镜像副本存储在镜像服务(glance) API 服务器上,并检索它们以改进可扩展性。借助镜像服务缓存,glance-api 可以在多个主机上运行。这意味着不需要多次从后端存储中检索同一镜像。镜像服务缓存不会影响任何镜像服务操作。

使用 Red Hat OpenStack Platform director (tripleo) heat 模板配置镜像服务缓存:

流程

  1. 在环境文件中,将 GlanceCacheEnabled 参数的值设置为 true,它将 glance-api.conf heat 模板中的 flavor 值自动设置为 keystone+cachemanagement

    parameter_defaults:
        GlanceCacheEnabled: true
  2. 在重新部署 overcloud 时,将环境文件包括在 openstack overcloud deploy 命令中。
  3. 可选:重新部署 overcloud 时将 glance_cache_pruner 调整为替代频率。以下示例显示了 5 分钟的频率:

    parameter_defaults:
      ControllerExtraConfig:
        glance::cache::pruner::minute: '*/5'

    根据您的需求调整频率,以避免文件系统完整情况。选择备选频率时包括以下元素:

    • 要在环境中缓存的文件大小。
    • 可用空间量。
    • 环境缓存镜像的频率。

17.8. 配置第三方存储

以下环境文件存在于核心 heat 模板集合 /usr/share/openstack-tripleo-heat-templates 中。

Dell EMC Storage Center

为 Block Storage (cinder)服务部署单个 Dell EMC Storage Center 后端。

该环境文件位于 /usr/share/openstack-tripleo-heat-templates/environments/cinder-dellsc-config.yaml

有关完整配置信息,请参阅 Dell Storage Center 后端指南

Dell EMC PS 系列

为 Block Storage (cinder)服务部署单个 Dell EMC PS 系列后端。

该环境文件位于 /usr/share/openstack-tripleo-heat-templates/environments/cinder-dellps-config.yaml

有关完整配置信息,请参阅 Dell EMC PS 系列后端指南

NetApp Block Storage

将 NetApp 存储设备部署为 Block Storage (cinder)服务的后端。

该环境文件位于 /usr/share/openstack-tripleo-heat-templates/environments/storage/cinder-netapp-config.yaml

有关完整配置信息,请参阅 NetApp Block Storage 后端指南

第 18 章 安全增强

以下小节提供了增强 overcloud 安全性的一些建议。

18.1. 使用安全的 root 用户访问

overcloud 镜像自动包含 root 用户的强化安全性。例如,每个部署的 overcloud 节点都会自动禁用对 root 用户的直接 SSH 访问。您仍然可以访问 overcloud 节点上的 root 用户。

流程

  1. stack 用户身份登录 undercloud 节点。
  2. 每个 overcloud 节点都有一个 heat-admin 用户帐户。此用户帐户包含 undercloud 公共 SSH 密钥,它在不从 undercloud 到 overcloud 节点的情况下提供 SSH 访问。在 undercloud 节点上,以 heat-admin 用户身份通过 SSH 登录 overcloud 节点。
  3. 通过 sudo -i 切换到 root 用户。

18.2. 管理 overcloud 防火墙

每个核心 OpenStack 平台服务都在其相应的可组合服务模板中包含防火墙规则。这会为每个 overcloud 节点自动创建一组默认防火墙规则。

overcloud heat 模板包含一组参数,它们可以帮助提供额外的防火墙管理:

ManageFirewall
定义是否自动管理防火墙规则。将此参数设为 true,以允许 Puppet 在每个节点上自动配置防火墙。如果要手动管理防火墙,则设置为 false。默认值是 true
PurgeFirewallRules
定义在配置新防火墙规则前是否清除默认 Linux 防火墙规则。默认值为 false

如果将 ManageFirewall 参数设置为 true,则可以在部署时创建额外的防火墙规则。使用配置 hook 设置 tripleo::firewall::firewall_rules hieradata (请参阅 overcloud 环境文件中的 第 4.5 节 “Puppet:自定义角色的 hieradata”)。此 hieradata 是一个哈希,包含防火墙规则名称及其对应的参数作为键,它们都是可选的:

port
与该规则关联的端口。
dport
与该规则关联的目的地端口。
SPORT
与该规则关联的源端口。
proto
与该规则关联的协议。默认为 tcp
action
与该规则关联的操作策略。默认为 接受
跳过
要跳至的链。如果存在,它会覆盖 操作
state
与该规则关联的状态阵列。默认为 ['NEW']
source
与该规则关联的源 IP 地址。
iniface
与该规则关联的网络接口。
与该规则关联的链。默认为 INPUT
目的地
与该规则关联的目标 CIDR。

以下示例演示了防火墙规则格式的语法:

ExtraConfig:
  tripleo::firewall::firewall_rules:
    '300 allow custom application 1':
      port: 999
      proto: udp
      action: accept
    '301 allow custom application 2':
      port: 8081
      proto: tcp
      action: accept

这通过 ExtraConfig 将两个额外的防火墙规则应用于所有节点。

注意

每个规则名称都会成为对应 iptables 规则的注释。每一规则名称以三位前缀开头,帮助 Puppet 订购最终 iptables 文件中定义的所有规则。默认的 Red Hat OpenStack Platform 规则使用 000 到 200 范围内的前缀。

18.3. 更改简单网络管理协议(SNMP)字符串

director 为您的 overcloud 提供默认的只读 SNMP 配置。建议更改 SNMP 字符串来降低未授权用户了解您的网络设备的风险。

注意

当您使用 string 参数配置 ExtraConfig 接口时,您必须使用以下语法来确保 heat 和 Hiera 没有将字符串解释为布尔值值: '"<VALUE>"'

在 overcloud 的环境文件中,使用 ExtraConfig hook 设置以下 hieradata:

SNMP 传统访问控制设置

snmp::ro_community
IPv4 只读 SNMP 社区字符串.默认值为 public
snmp::ro_community6
IPv6 只读 SNMP 社区字符串.默认值为 public
snmp::ro_network
允许 RO 查询 守护进程的网络。这个值可以是字符串或数组。默认值为 127.0.0.1
snmp::ro_network6
允许 RO 查询 带有 IPv6 的守护进程的网络。这个值可以是字符串或数组。默认值为 ::1/128
tripleo::profile::base::snmp::snmpd_config
要添加到 snmpd.conf 文件中的行数组,作为安全 valve。默认值为 []。有关所有可用选项,请参阅 SNMP Configuration File 网页。

例如:

parameter_defaults:
  ExtraConfig:
    snmp::ro_community: mysecurestring
    snmp::ro_community6: myv6securestring

这会更改所有节点上的只读 SNMP 社区字符串。

基于 SNMP 视图的访问控制设置(VACM)

snmp::com2sec
IPv4 安全名称。
snmp::com2sec6
IPv6 安全名称。

例如:

parameter_defaults:
  ExtraConfig:
    snmp::com2sec: mysecurestring
    snmp::com2sec6: myv6securestring

这会更改所有节点上的只读 SNMP 社区字符串。

如需更多信息,请参阅 snmpd.conf man page。

18.4. 更改 HAProxy 的 SSL/TLS 密码和规则

如果在 overcloud 中启用了 SSL/TLS,请考虑强化与 HAProxy 配置一起使用的 SSL/TLS 密码和规则。通过强化 SSL/TLS 密码,可帮助您避免 SSL/TLS 漏洞,如 POODLE 漏洞

  1. 创建名为 tls-ciphers.yaml 的 heat 模板环境文件:

    touch ~/templates/tls-ciphers.yaml
  2. 使用环境文件中的 ExtraConfig hook 将值应用到 tripleo::haproxy::ssl_cipher_suitetripleo::haproxy::ssl_options hieradata:

    parameter_defaults:
      ExtraConfig:
        tripleo::haproxy::ssl_cipher_suite:: `DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305`
    
        tripleo::haproxy::ssl_options:: no-sslv3 no-tls-tickets
    注意

    cipher 集合是一个连续行。

  3. 在部署 overcloud 时,包含 tls-ciphers.yaml 环境文件及 overcloud deploy 命令:

    openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/tls-ciphers.yaml
    ...

18.5. 使用 Open vSwitch 防火墙

您可以将安全组配置为使用 Red Hat OpenStack Platform director 中的 Open vSwitch (OVS)防火墙驱动程序。使用 NeutronOVSFirewallDriver 参数指定您要使用的防火墙驱动程序:

  • iptables_hybrid - 配置网络服务(neutron)以使用基于 iptables/hybrid 的实施。
  • openvswitch - 将网络服务配置为使用 OVS 防火墙流型驱动程序。

openvswitch 防火墙驱动程序包括更高的性能,并减少用于将客户机连接到项目网络的接口和网桥数量。

重要

多播流量由 Open vSwitch (OVS)防火墙驱动程序与 iptables 防火墙驱动程序不同的处理。使用 iptables 时,VRRP 流量被拒绝,且您必须在 VRRP 流量的安全组规则中启用 VRRP 才能访问端点。使用 OVS 时,所有端口共享相同的 OpenFlow 上下文,并且每个端口无法单独处理多播流量。由于安全组不应用到所有端口(例如,路由器上的端口),OVS 会使用 NORMAL 操作并将多播流量转发到 RFC 4541 指定的所有端口。

注意

iptables_hybrid 选项与 OVS-DPDK 不兼容。openvswitch 选项与 OVS Hardware Offload 不兼容。

network-environment.yaml 文件中配置 NeutronOVSFirewallDriver 参数:

NeutronOVSFirewallDriver: openvswitch
  • NeutronOVSFirewallDriver :配置您要在实现安全组时要使用的防火墙驱动程序名称。可能的值可能取决于您的系统配置。些示例包括 noopopenvswitchiptables_hybrid。空字符串的默认值会产生支持的配置。

第 19 章 配置网络插件

director 包括在配置第三方网络插件时可以使用的环境文件:

19.1. Fujitsu Converged Fabric (C-Fabric)

您可以使用位于 /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml 的环境文件来启用 Fujitsu Converged Fabric (C-Fabric)插件。

流程

  1. 将环境文件复制到模板 子目录中

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml /home/stack/templates/
  2. 编辑 resource_registry 以使用绝对路径:

    resource_registry:
      OS::TripleO::Services::NeutronML2FujitsuCfab: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-cfab.yaml
  3. 查看 /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml 中的 parameter_defaults

    • NeutronFujitsuCfabAddress - C-Fabric 的 telnet IP 地址(字符串)
    • neutronFujitsuCfabUserName - 要使用的 C-Fabric 用户名(字符串)
    • NeutronFujitsuCfabPassword - C-Fabric 用户帐户的密码。(字符串)
    • NeutronFujitsuCfabPhysicalNetworks -<physical_network>:& lt;vfab_id& gt; tuples,用于指定 physical_network 名称和对应的 vfab ID。(comma_delimited_list)
    • NeutronFujitsuCfabSharePprofile - 确定是否在使用相同的 VLAN ID 的 neutron 端口间共享 C-Fabric pprofile。(布尔值)
    • NeutronFujitsuCfabPprofilePrefix - pprofile name 的前缀字符串。(字符串)
    • NeutronFujitsuCfabSaveConfig - 确定是否保存配置。(布尔值)
  4. 要将模板应用到您的部署中,请在 openstack overcloud deploy 命令中包含环境文件:

    $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml [OTHER OPTIONS] ...

19.2. Fujitsu FOS Switch

您可以使用位于 /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml 的环境文件来启用 Fujitsu FOS Switch 插件。

流程

  1. 将环境文件复制到模板 子目录中

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml /home/stack/templates/
  2. 编辑 resource_registry 以使用绝对路径:

    resource_registry:
      OS::TripleO::Services::NeutronML2FujitsuFossw: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-fossw.yaml
  3. 查看 /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml 中的 parameter_defaults

    • NeutronFujitsuFosswIps - 所有 FOS 交换机的 IP 地址(comma_delimited_list)
    • neutronFujitsuFosswUserName - 要使用的 FOS 用户名(字符串)
    • NeutronFujitsuFosswPassword - FOS 用户帐户的密码。(字符串)
    • NeutronFujitsuFosswPort - 用于 SSH 连接的端口号。(数字)
    • NeutronFujitsuFosswTimeout - SSH 连接的超时周期。(数字)
    • NeutronFujitsuFosswUdpDestPort - FOS 交换机上的 VXLAN UDP 目的地的端口号。(数字)
    • NeutronFujitsuFosswOvsdbVlanidRangeMin - 用于绑定 VNI 和物理端口范围内的最小 VLAN ID。(数字)
    • NeutronFujitsuFosswOvsdbPort - FOS 交换机上 OVSDB 服务器的端口号。(数字)
  4. 要将模板应用到您的部署中,请在 openstack overcloud deploy 命令中包含环境文件:

    $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml [OTHER OPTIONS] ...

第 20 章 配置身份

director 包含有助于配置 Identity Service (keystone)设置的参数:

20.1. 区域名称

默认情况下,overcloud 区域名为 regionOne。您可以通过添加 KeystoneRegion 条目来更改您的环境文件。部署 overcloud 后您无法修改这个值。

parameter_defaults:
  KeystoneRegion: 'SampleRegion'

第 21 章 其他 overcloud 配置

使用以下配置来配置 overcloud 中的各种功能。

21.1. 调试模式

您可以为 overcloud 中的某些服务启用和禁用 DEBUG 级别日志记录模式。

要为服务配置调试模式,请设置对应的 debug 参数。例如,OpenStack Identity (keystone)使用 KeystoneDebug 参数。

流程

  • 在环境文件的 parameter_defaults 部分中设置参数:

    parameter_defaults:
      KeystoneDebug: True

KeystoneDebug 参数设置为 True 后,/var/log/containers/keystone/keystone.log 标准 keystone 日志文件使用 DEBUG 级别日志更新。

如需 debug 参数的完整列表,请参阅 Overcloud 参数指南中的"Debug 参数 "

21.2. 在 overcloud 节点上配置内核

Red Hat OpenStack Platform director 包括在 overcloud 节点上配置内核的参数。

ExtraKernelModules

要加载的内核模块。模块名称被列为带有空值的 hash 键:

  ExtraKernelModules:
    <MODULE_NAME>: {}
ExtraKernelPackages

在从 ExtraKernelModules 加载内核模块前要安装的与内核相关的软件包。软件包名称被列为带有空值的散列键。

  ExtraKernelPackages:
    <PACKAGE_NAME>: {}
ExtraSysctlSettings

要应用的 sysctl 设置哈希。使用 value 键设置每个参数的值。

  ExtraSysctlSettings:
    <KERNEL_PARAMETER>:
      value: <VALUE>

这个示例在环境文件中显示这些参数的语法:

parameter_defaults:
  ExtraKernelModules:
    iscsi_target_mod: {}
  ExtraKernelPackages:
    iscsi-initiator-utils: {}
  ExtraSysctlSettings:
    dev.scsi.logging_level:
      value: 1

21.3. 配置服务器控制台

overcloud 节点的控制台输出并不总是发送到服务器控制台。如果要在服务器控制台中查看此输出,您必须将 overcloud 配置为为您的硬件使用正确的控制台。使用以下方法之一执行此配置:

  • 修改每个 overcloud 角色的 KernelArgs heat 参数。
  • 自定义 director 用于置备 overcloud 节点的 overcloud-full.qcow2 镜像。

前提条件

  • 成功安装 undercloud。如需更多信息,请参阅 Director 安装和使用 指南。
  • overcloud 节点已准备好进行部署。

在部署过程中使用 heat 修改 KernelArgs

  1. stack 用户身份登录 undercloud 主机。
  2. 查找 stackrc 凭证文件:

    $ source stackrc
  3. 创建包含以下内容的环境文件 overcloud-console.yaml

    parameter_defaults:
      <role>Parameters:
        KernelArgs: "console=<console-name>"

    <role > 替换为您要配置的 overcloud 角色的名称,并将 <console-name > 替换为您要使用的控制台的 ID。例如,使用以下代码片段将默认角色中的所有 overcloud 节点配置为使用 tty0

    parameter_defaults:
      ControllerParameters:
        KernelArgs: "console=tty0"
      ComputeParameters:
        KernelArgs: "console=tty0"
      BlockStorageParameters:
        KernelArgs: "console=tty0"
      ObjectStorageParameters:
        KernelArgs: "console=tty0"
      CephStorageParameters:
        KernelArgs: "console=tty0"
  4. 使用 -e 选项在部署命令中包含 overcloud-console-tty0.yaml 文件。

修改 overcloud-full.qcow2 镜像

  1. stack 用户身份登录 undercloud 主机。
  2. 查找 stackrc 凭证文件:

    $ source stackrc
  3. 修改 overcloud-full.qcow2 镜像的内核参数,为您的硬件设置正确的控制台。例如,将控制台设置为 tty0

    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'grubby --update-kernel=ALL --args="console=tty0"'
  4. 将镜像导入 director:

    $ openstack overcloud image upload --image-path /home/stack/images/overcloud-full.qcow2
  5. 部署 overcloud。

验证

  1. 从 undercloud 登录 overcloud 节点:

    $ ssh heat-admin@<IP-address>

    <IP-address > 替换为 overcloud 节点的 IP 地址。

  2. 检查 /proc/cmdline 文件的内容,并确保 console= 参数设置为您要使用的控制台值:

    [heat-admin@controller-0 ~]$ cat /proc/cmdline
    BOOT_IMAGE=(hd0,msdos2)/boot/vmlinuz-4.18.0-193.29.1.el8_2.x86_64 root=UUID=0ec3dea5-f293-4729-b676-5d38a611ce81 ro console=tty0 console=ttyS0,115200n81 no_timer_check crashkernel=auto rhgb quiet

21.4. 配置外部负载均衡

overcloud 使用多个 Controller 作为高可用性集群,确保 OpenStack 服务的最大运行性能。另外,集群提供了对 OpenStack 服务的访问的负载均衡,这会均匀将流量分发到 Controller 节点,并减少每个节点的服务器超载。您还可以使用外部负载均衡器来执行此分发。例如,您可以使用自己的基于硬件的负载均衡器来处理到 Controller 节点的流量分布。

有关配置外部负载均衡的更多信息,请参阅 Overcloud 的专用外部负载平衡 指南。

21.5. 配置 IPv6 联网

本节检查 overcloud 的网络配置。这包括隔离 OpenStack 服务以使用特定的网络流量并使用 IPv6 选项配置 overcloud。