红帽全球峰会高级 Overcloud 自定义
使用 Red Hat OpenStack Platform director 配置高级功能的方法
摘要
第 1 章 简介
Red Hat OpenStack Platform director 提供了一组工具来置备和创建功能齐全的 OpenStack 环境，也称为 Overcloud。Director 安装和使用指南涵盖了 Overcloud 的准备和配置。但是，正确的生产级 Overcloud 可能需要额外的配置，包括：
- 将 Overcloud 集成到现有网络基础架构的基本网络配置。
- 在单独的 VLAN 上针对某些 OpenStack 网络流量类型进行网络流量隔离。
- SSL 配置来保护公共端点上的通信
- 存储选项，如 NFS、iSCSI、Red Hat Ceph Storage 和多个第三方存储设备。
- 将节点注册到 Red Hat Content Delivery Network 或您的内部 Red Hat Satellite 5 或 6 服务器。
- 各种系统级别选项。
- 各种 OpenStack 服务选项。
本指南提供通过 director 增加 Overcloud 的说明。此时，director 注册了节点，并且配置了 Overcloud 创建所需的服务。现在，您可以使用本指南中的方法自定义 Overcloud。
本指南中的示例是配置 Overcloud 的可选步骤。这些步骤只需要为 Overcloud 提供额外功能。仅使用适用于您的环境需求的步骤。
第 2 章 了解 Heat 模板
本指南中的自定义配置使用 Heat 模板和环境文件来定义 Overcloud 的某些方面。本章介绍了 Heat 模板的基本介绍，以便您可以在 Red Hat OpenStack Platform director 中了解这些模板的结构和格式。
2.1. Heat 模板
director 使用 Heat 编配模板(HOT)作为其 Overcloud 部署计划的模板格式。HOT 格式的模板主要以 YAML 格式表示。模板的目的是定义和 创建堆栈，这是 heat 创建的资源集合，以及资源的配置。资源是 OpenStack 中的对象，可以包含计算资源、网络配置、安全组、扩展规则和自定义资源。
Heat 模板的结构有三个主要部分：
- 参数
-
这些设置传递到 heat，它提供了一种自定义堆栈以及无传递值的参数默认值的方法。它们在模板的
parameters部分中定义。 - Resources
-
这些是作为堆栈一部分创建和配置的具体对象。OpenStack 包含一组跨所有组件的核心资源。它们在模板的
resources部分中定义。 - 输出
-
这些是在堆栈创建后从 heat 传递的值。您可以通过 heat API 或客户端工具访问这些值。它们在模板的
output部分中定义。
以下是基本 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 --nested2.2. 环境文件
环境文件是特殊的模板，为您的 Heat 模板提供自定义。这包括三个关键部分：
- 资源 Registry
-
本节定义链接到其他 heat 模板的自定义资源名称。这基本上提供了一种创建在核心资源集合中不存在的自定义资源的方法。它们在环境文件的
resource_registry部分中定义。 - 参数
-
这些是适用于顶级模板参数的通用设置。例如，如果您有一个部署嵌套堆栈（如资源 registry 映射）的模板，则参数仅适用于顶层模板，而不是嵌套资源的模板。参数在环境文件的
parameters部分中定义。 - 参数默认值
-
这些参数修改所有模板中的参数的默认值。例如，如果您有一个部署嵌套堆栈（如资源 registry 映射）的 Heat 模板，则参数默认为所有模板。换句话说，顶级模板和定义所有嵌套资源的模板。参数默认值在环境文件的
parameter_defaults部分中定义。
建议您在为 Overcloud 创建自定义环境文件时使用 parameter_defaults 而不是 参数。因此，参数将应用到 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 模板。在本例中，它只适用于 my_template.yaml 中的参数。
NetworkName 适用于主 Heat 模板（本例中为 my_template.yaml）和与包含主模板的资源关联的模板，如 OS::Nova::Server::MyServer 资源及其 myserver.yaml 模板。
2.3. 核心 Overcloud Heat 模板
director 包含 Overcloud 的核心 heat 模板集合。此集合存储在 /usr/share/openstack-tripleo-heat-templates 中。
此集合中有许多 heat 模板和环境文件。但是，此模板集合中要注意的主要文件和目录是：
overcloud.j2.yaml- 这是用于创建 Overcloud 环境的主要模板文件。此文件使用 Jinja2 语法来迭代模板中的特定部分来创建自定义角色。在 overcloud 部署过程过程中，J Jinja2 格式呈现为 YAML。
overcloud-resource-registry-puppet.j2.yaml- 这是用于创建 Overcloud 环境的主要环境文件。它为 Overcloud 镜像中存储的 Puppet 模块提供一组配置。在 director 将 Overcloud 镜像写入每个节点后，Heat 会使用此环境文件中注册的资源启动每个节点的 Puppet 配置。此文件使用 Jinja2 语法来迭代模板中的特定部分来创建自定义角色。在 overcloud 部署过程过程中，J Jinja2 格式呈现为 YAML。
roles_data.yaml- 在 overcloud 中定义角色的文件，并将服务映射到各个角色。
capabilities-map.yaml-
overcloud 计划的环境文件映射。使用此文件通过 director 的 Web UI 描述和启用环境文件。在 overcloud 计划中检测到的自定义环境文件，但没有列在
capabilities-map.yaml中的其他 子选项卡中，2 指定 web UI 上的 Deployment Configuration > Overall Settings。 environments-
包含可用于创建 Overcloud 的其他 Heat 环境文件。这些环境文件为生成的 OpenStack 环境启用额外的功能。例如，目录包含用于启用 Cinder NetApp 后端存储(
cinder-netapp-config.yaml)的环境文件。 network- 组 Heat 模板，可帮助创建隔离的网络和端口。
puppet-
模板主要由使用 puppet 的配置驱动。以上
overcloud-resource-registry-puppet.j2.yaml环境文件使用此目录中的文件来驱动每个节点上的 Puppet 配置应用。 puppet/services- 在可组合服务架构中，包含所有服务的 heat 模板的目录。
extraconfig-
用于启用额外功能的模板。例如，
extraconfig/pre_deploy/rhel-registrationdirector 提供了将节点的 Red Hat Enterprise Linux 操作系统注册到 Red Hat Content Delivery 网络或您自己的 Red Hat Satellite 服务器的功能。 firstboot-
提供 director 最初创建节点时使用的
first_boot脚本示例。
2.4. 在 Overcloud 创建中包含环境文件
部署命令(openstack overcloud deploy)使用 -e 选项包含一个环境文件来自定义 Overcloud。您可以根据需要纳入多个环境文件。但是，环境文件的顺序非常重要，因为后续环境文件中定义的参数和资源更为优先。例如，您可能有两个环境文件：
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
在本例中，两个环境文件都包含一个通用资源类型(OS::TripleO::NodeExtraConfigPost)和通用参数(TimeZone)。openstack overcloud deploy 命令通过以下流程运行：
-
根据
--template选项，从核心 Heat 模板集合加载默认配置。 -
应用
environment-file-1.yaml的配置，这将覆盖默认配置中的任何通用设置。 -
应用
environment-file-2.yaml的配置，它会覆盖默认配置和environment-file-1.yaml中的任何通用设置。
这会导致对 Overcloud 的默认配置进行了以下更改：
-
OS::TripleO::NodeExtraConfigPost资源设置为每个environment-file-2.yaml的/home/stack/templates/template-2.yaml。 -
timezone参数设置为 perenvironment-file-2.yaml。 -
RabbitFDLimit参数被设置为65536，作为每个环境文件-1.yaml。environment-file-2.yaml不会更改此值。
这提供了一种方式，可将自定义配置定义为 Overcloud，而不定义来自多个环境文件的值。
2.5. 使用自定义核心 Heat 模板
在创建 overcloud 时，director 使用一组位于 /usr/share/openstack-tripleo-heat-templates 中的 Heat 模板的核心集合。如果要自定义此核心模板集合，请使用 Git 工作流来跟踪更改和合并更新。使用以下 git 进程来帮助管理自定义模板集合：
初始化自定义模板集合
使用以下流程来创建包含 Heat 模板集合的初始 Git 存储库：
将模板的目录复制到
stack用户目录中。这个示例将其复制到~/templates目录中：$ cd ~/templates $ cp -r /usr/share/openstack-tripleo-heat-templates .进入自定义模板目录并初始化 Git 存储库：
$ cd openstack-tripleo-heat-templates $ git init .暂存初始提交的所有模板：
$ git add *创建初始提交：
$ git commit -m "Initial creation of custom core heat templates"
这会创建一个包含最新核心模板集合的初始 master 分支。使用此分支作为自定义分支的基础，并将新模板版本合并到此分支。
创建自定义分支和提交更改
使用自定义分支将您的更改存储到核心模板集合。使用以下步骤创建 my-customizations 分支并为其添加自定义：
创建
my-customizations分支并切换到它：$ git checkout -b my-customizations- 编辑自定义分支中的文件。
在 git 中暂存更改：
$ git add [edited files]将更改提交到自定义分支：
$ git commit -m "[Commit message for custom changes]"
这会将您的更改作为提交添加到 my-customizations 分支。当 master 分支更新时，您可以 rebase my-customizations off master，这会导致 git 将这些提交添加到更新的模板集合中。这有助于跟踪您自定义并在将来的模板更新时重新显示它们。
更新自定义模板集合：
在更新 undercloud 时，openstack-tripleo-heat-templates 软件包可能会更新。使用以下步骤更新自定义模板集合：
将
openstack-tripleo-heat-templates软件包版本保存为环境变量：$ export PACKAGE=$(rpm -qv openstack-tripleo-heat-templates)进入模板集合目录，并为更新的模板创建新分支：
$ cd ~/templates/openstack-tripleo-heat-templates $ git checkout -b $PACKAGE删除分支中的所有文件，并将其替换为新版本：
$ git rm -rf * $ cp -r /usr/share/openstack-tripleo-heat-templates/* .为初始提交添加所有模板：
$ git add *为软件包更新创建提交：
$ git commit -m "Updates for $PACKAGE"将分支合并到 master 中。如果使用 Git 管理系统，如 GitLab，则使用管理工作流。如果在本地使用 git，请切换到
master分支并运行git merge命令：$ git checkout master $ git merge $PACKAGE
master 分支现在包含核心模板集合的最新版本。现在，您可以从这个更新的集合中重新生成 my-customization 分支。
重负自定义分支
使用以下流程更新 my-customization 分支，：
进入
my-customizations分支：$ git checkout my-customizations重新构建分支 off
master：$ git rebase master
这会更新 my-customizations 分支，并重播向此分支进行的自定义提交。
如果 git 在 rebase 期间报告任何冲突，请使用此流程：
检查哪些文件包含冲突：
$ git status- 解决识别的模板文件的冲突。
添加已解析的文件
$ git add [resolved files] $ git commit继续更新：
$ git rebase --continue
部署自定义模板
使用以下步骤部署自定义模板集合：
确保您已切换到
my-customization分支：git checkout my-customizations使用
--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)。
第 3 章 参数
director 模板集合中的每个 Heat 模板都包含一个 parameters 部分。本节定义特定于特定 overcloud 服务的所有参数。这包括以下内容：
-
overcloud.j2.yaml- 默认基础参数 -
roles_data.yaml- 可组合角色的默认参数 -
Puppet/services locate.yaml- 特定服务的默认参数
您可以使用以下方法修改这些参数的值：
- 为您的自定义参数创建一个环境文件。
-
在环境文件的
parameter_defaults部分中包含您的自定义参数。 -
使用
openstack overcloud deploy命令包含环境文件。
接下来的几个部分包含演示如何为 puppet/services 目录中的服务配置特定参数的示例。
3.1. 示例 1：配置时区
用于设置时区(puppet/services/time/timezone.yaml)的 Heat 模板包含一个 TimeZone 参数。如果将 TimeZone 参数留空，overcloud 会将时间设置为 UTC 作为默认值。director 识别时区数据库 /usr/share/zoneinfo/ 中定义的标准时区名称。例如，如果您想要将时区设置为 日本，您将检查 /usr/share/zoneinfo 的内容以查找合适的条目：
$ ls /usr/share/zoneinfo/
Africa Asia Canada Cuba EST GB GMT-0 HST iso3166.tab Kwajalein MST NZ-CHAT posix right Turkey UTC Zulu
America Atlantic CET EET EST5EDT GB-Eire GMT+0 Iceland Israel Libya MST7MDT Pacific posixrules ROC UCT WET
Antarctica Australia Chile Egypt Etc GMT Greenwich Indian Jamaica MET Navajo Poland PRC ROK Universal W-SU
Arctic Brazil CST6CDT Eire Europe GMT0 Hongkong Iran Japan Mexico NZ Portugal PST8PDT Singapore US zone.tab
以上列出的输出包括时区文件和目录，以及包含其他时区文件的目录。例如，日本 是这样一个单独的时区文件，但 非洲 是一个包含额外时区文件的目录：
$ ls /usr/share/zoneinfo/Africa/
Abidjan Algiers Bamako Bissau Bujumbura Ceuta Dar_es_Salaam El_Aaiun Harare Kampala Kinshasa Lome Lusaka Maseru Monrovia Niamey Porto-Novo Tripoli
Accra Asmara Bangui Blantyre Cairo Conakry Djibouti Freetown Johannesburg Khartoum Lagos Luanda Malabo Mbabane Nairobi Nouakchott Sao_Tome Tunis
Addis_Ababa Asmera Banjul Brazzaville Casablanca Dakar Douala Gaborone Juba Kigali Libreville Lubumbashi Maputo Mogadishu Ndjamena Ouagadougou Timbuktu Windhoek
在环境文件中添加条目，将您的时区设置为 日本 ：
parameter_defaults:
TimeZone: 'Japan'3.2. 示例 2：禁用第 3 层高可用性(L3HA)
OpenStack Networking (neutron) API (puppet/services/neutron-api.yaml)的 Heat 模板包含一个用于启用和禁用第 3 层高可用性(L3HA)的参数。参数的默认值为 false。但是，您可以在环境文件中使用以下内容启用它：
parameter_defaults:
NeutronL3HA: true3.3. 示例 3：配置 Telemetry Dispatcher
OpenStack 遥测(ceilometer)服务包含时间序列数据存储(gnocchi)的组件。puppet/services/ceilometer-base.yaml Heat 模板允许您在 gnocchi 和标准数据库之间切换。您可以使用 CeilometerMeterDispatcher 参数完成此操作，该参数设置为其中之一：
-
Gnocchi- 将新的时间序列数据库用于 Ceilometer 分配程序。这是默认选项。 -
数据库- 为 Ceilometer 分配程序使用标准数据库。
要切换到标准数据库，请在环境文件中添加以下内容：
parameter_defaults:
CeilometerMeterDispatcher: database3.4. 示例 4：配置 RabbitMQ 文件描述符限制
对于某些配置，您可能需要增加 RabbitMQ 服务器的文件描述符限制。puppet/services/rabbitmq.yaml Heat 模板允许您将 RabbitFDLimit 参数设置为您需要的限制。将以下内容添加到环境文件中。
parameter_defaults:
RabbitFDLimit: 655363.5. 示例 5：启用和禁用参数
在某些情况下，您可能需要在部署期间最初设置参数，然后禁用该参数用于将来的部署操作，如更新或扩展操作。例如，要在创建 overcloud 的过程中包括自定义 RPM，您将包括以下几项：
parameter_defaults:
DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]如果您需要从将来的部署中禁用此参数，则删除该参数就不足。相反，您可以将参数设置为空值：
parameter_defaults:
DeployArtifactURLs: []这可确保不再为后续部署操作设置该参数。
3.6. 识别要修改的参数
Red Hat OpenStack Platform director 为配置提供了许多参数。在某些情况下，您可能会遇到发现特定选项来配置和对应的 director 参数的难度。如果您要通过 director 配置的选项，请使用以下工作流来识别和将选项映射到特定的 overcloud 参数：
- 确定您要配置的选项。记录使用 选项的服务。
为此选项检查对应的 Puppet 模块。Red Hat OpenStack Platform 的 Puppet 模块位于 director 节点上的
/etc/puppet/modules下。每个模块对应于特定的服务。例如，keystone模块对应于 OpenStack Identity (keystone)。- 如果 Puppet 模块包含控制所选选项的变量，请转到下一步。
- 如果 Puppet 模块不包含控制所选选项的变量，则此选项没有 hieradata。如果可能，您可以在 overcloud 完成部署后手动设置选项。
以 hieradata 的形式，检查 director 的核心 Heat 模板集合中的 Puppet 变量。
puppet/services locate中的模板通常与同一服务的 Puppet 模块对应。例如，puppet/services/keystone.yaml模板为keystone模块提供 hieradata。- 如果 Heat 模板为 Puppet 变量设置 hieradata，则模板也应关闭基于 director 的参数进行修改。
- 如果 Heat 模板没有为 Puppet 变量设置 hieradata，请使用配置 hook 使用环境文件来传递 hieradata。有关自定义 hieradata 的更多信息，请参阅 第 4.5 节 “Puppet：为角色自定义 Hieradata”。
工作流示例
您可能的目标是更改 OpenStack Identity (keystone)的通知格式。使用工作流，您可以：
-
识别要配置的 OpenStack 参数(
notification_format)。 在
keystonePuppet 模块中搜索notification_format设置。例如：$ grep notification_format /etc/puppet/modules/keystone/manifests/*在这种情况下，
keystone模块使用keystone::notification_format变量管理这个选项。为此变量搜索
keystone服务模板。例如：$ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/puppet/services/keystone.yaml输出显示 director 使用
KeystoneNotificationFormat参数来设置keystone::notification_formathieradata。
下表显示了最终映射：
| Director 参数 | Puppet Hieradata | OpenStack Identity (keystone)选项 |
|---|---|---|
|
|
|
|
这意味着在 overcloud 的环境文件中设置 KeystoneNotificationFormat，会在 overcloud 的配置期间设置 keystone.conf 文件中的 notification_format 选项。
第 4 章 配置 Hook
配置 hook 提供了将您自己的配置功能注入 Overcloud 部署过程的方法。这包括用于在主 Overcloud 服务配置和 hook 之前和之后注入自定义配置的 hook，用于修改和包含基于 Puppet 的配置。
4.1. 首次启动：自定义第一个引导配置
director 提供了在 Overcloud 初始创建时在所有节点上执行配置的机制。director 通过 cloud-init 实现这一点，您可以使用 OS::TripleO::NodeUserData 资源类型来调用。
在本例中，您将使用所有节点上的自定义 IP 地址更新名称服务器。您必须首先创建一个基本的 heat 模板(/home/stack/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}
接下来，创建一个环境文件(/home/stack/templates/firstboot.yaml)，将 heat 模板注册为 OS::TripleO::NodeUserData 资源类型。
resource_registry:
OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml要添加第一个启动配置，请在首次创建 Overcloud 时将环境文件添加到堆栈中，以及其他环境文件。例如：
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/firstboot.yaml \
...
-e 将环境文件应用到 Overcloud 堆栈。
这会在首次创建和第一次引导时向所有节点添加配置。后续包含这些模板（如更新 Overcloud 堆栈）不会运行这些脚本。
您只能将 OS::TripleO::NodeUserData 注册到一个 heat 模板。后续用法会覆盖要使用的 heat 模板。
4.2. pre-Configuration：自定义特定 Overcloud 角色
本文档的早期版本使用 OS::TripleO::Tasks::*PreConfig 资源为每个角色提供预配置 hook。director 的 Heat 模板集合需要专门使用这些 hook，这意味着您不应将它们用于自定义用途。而是应使用下面概述的 OS::TripleO::*ExtraConfigPre hook。
Overcloud 使用 Puppet 进行 OpenStack 组件的核心配置。director 提供了一组 hook，用于在第一次引导完成后和内核配置开始前为特定节点角色提供自定义配置。这些 hook 包括：
- OS::TripleO::ControllerExtraConfigPre
- 在 Puppet 核心配置前，应用到 Controller 节点的额外配置。
- OS::TripleO::ComputeExtraConfigPre
- 在 Puppet 核心配置之前，应用到 Compute 节点的额外配置。
- OS::TripleO::CephStorageExtraConfigPre
- 在 Puppet 核心配置之前，应用到 Ceph Storage 节点的额外配置。
- OS::TripleO::ObjectStorageExtraConfigPre
- 在 Puppet 核心配置之前，应用到对象存储节点的其他配置。
- OS::TripleO::BlockStorageExtraConfigPre
- 在 Puppet 核心配置之前，应用到块存储节点的额外配置。
- OS::TripleO::[ROLE]ExtraConfigPre
-
在 Puppet 核心配置之前，应用到自定义节点的其他配置。将
[ROLE]替换为可组合角色名称。
在本例中，您首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml)，该脚本使用变量 nameserver 写入节点的 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资源的软件配置。注意以下几点：-
配置参数对CustomExtraConfigPre资源的引用，以便 Heat 知道要应用的配置。 -
server参数检索 Overcloud 节点的映射。此参数由父模板提供，并在此 hook 模板中是强制的。 -
actions参数定义要应用配置的时间。在这种情况下，我们仅在创建 Overcloud 时应用配置。可能的操作包括CREATE、UPDATE、DELETE、SUSPEND和RESUME。 -
input_values包含一个名为deploy_identifier的参数，它将从父模板存储DeployIdentifier。此参数为每个部署更新的资源提供时间戳。这可确保后续 overcloud 更新上的资源获取。
-
接下来，创建一个环境文件(/home/stack/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若要应用配置，可在创建或更新 Overcloud 时将环境文件添加到堆栈中，以及其他环境文件。例如：
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/pre_config.yaml \
...这会在内核配置从初始 Overcloud 创建或后续更新开始前，将配置应用到所有 Controller 节点。
您只能为每个 hook 只将一个 Heat 模板注册到一个 Heat 模板。后续用法会覆盖要使用的 Heat 模板。
4.3. pre-Configuration：自定义所有 Overcloud 角色
Overcloud 使用 Puppet 进行 OpenStack 组件的核心配置。director 提供了一个 hook，用于在第一次引导完成后配置所有节点类型，并在内核配置开始前配置：
- OS::TripleO::NodeExtraConfig
- 在 Puppet 核心配置之前，应用到所有节点角色的额外配置。
在本例中，您首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml)，该脚本会运行脚本来附加每个节点的 resolv.conf 及变量 nameserver。
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资源的软件配置。注意以下几点：-
配置参数对CustomExtraConfigPre资源的引用，以便 Heat 知道要应用的配置。 -
server参数检索 Overcloud 节点的映射。此参数由父模板提供，并在此 hook 模板中是强制的。 -
actions参数定义要应用配置的时间。在这种情况下，我们仅在创建 Overcloud 时应用配置。可能的操作包括CREATE、UPDATE、DELETE、SUSPEND和RESUME。 -
input_values参数包含一个名为deploy_identifier的子参数，它从父模板存储DeployIdentifier。此参数为每个部署更新的资源提供时间戳。这可确保后续 overcloud 更新上的资源获取。
-
接下来，创建一个环境文件(/home/stack/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若要应用配置，可在创建或更新 Overcloud 时将环境文件添加到堆栈中，以及其他环境文件。例如：
$ 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。director 的 Heat 模板集合需要专门使用这些 hook，这意味着您不应将它们用于自定义用途。而是应使用下面概述的 OS::TripleO::NodeExtraConfigPost hook。
您完成 Overcloud 创建但希望在初始创建时或后续更新 Overcloud 时添加额外的配置，可能会出现这种情况。在这种情况下，您可以使用以下安装后 hook：
- OS::TripleO::NodeExtraConfigPost
- 在 Puppet 核心配置后，应用到所有节点角色的额外配置。
在本例中，您首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml)，该脚本会运行脚本来附加每个节点的 resolv.conf 及变量 nameserver。
heat_template_version: 2014-10-16
description: >
Extra hostname configuration
parameters:
servers:
type: json
nameserver_ip:
type: string
DeployIdentifier:
type: string
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资源的软件配置。注意以下几点：-
配置参数对CustomExtraConfig资源的引用，以便 Heat 知道要应用的配置。 -
servers参数检索 Overcloud 节点的映射。此参数由父模板提供，并在此 hook 模板中是强制的。 -
actions参数定义要应用配置的时间。在这种情况下，我们仅在创建 Overcloud 时应用配置。可能的操作包括CREATE、UPDATE、DELETE、SUSPEND和RESUME。 -
input_values包含一个名为deploy_identifier的参数，它将从父模板存储DeployIdentifier。此参数为每个部署更新的资源提供时间戳。这可确保后续 overcloud 更新上的资源获取。
-
接下来，创建一个环境文件(/home/stack/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若要应用配置，可在创建或更新 Overcloud 时将环境文件添加到堆栈中，以及其他环境文件。例如：
$ 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 节点的配置。
- NovaComputeExtraConfig
- 添加到所有 Compute 节点的配置。
- BlockStorageExtraConfig
- 添加到所有块存储节点的配置。
- ObjectStorageExtraConfig
- 添加到所有对象存储节点的配置
- CephStorageExtraConfig
- 添加到所有 Ceph Storage 节点的配置
- [ROLE]ExtraConfig
-
要添加到可组合角色的配置。将
[ROLE]替换为可组合角色名称。 - ExtraConfig
- 添加到所有节点的配置。
要添加额外的配置到部署后配置，请在 parameter_defaults 部分中创建一个包含这些参数的环境文件。例如，要将 Compute 主机的保留内存增加到 1024 MB，并将 VNC keymap 设置为日语：
parameter_defaults:
NovaComputeExtraConfig:
nova::compute::reserved_host_memory: 1024
nova::compute::vnc_keymap: ja
在运行 openstack overcloud deploy 时包含此环境文件。
您只能定义每个参数一次。后续用法会覆盖以前的值。
4.6. Puppet：为单个节点自定义 Hieradata
您可以使用 Heat 模板集合为单个节点设置 Puppet hieradata。要达到此目的，您需要获取作为节点内省数据的一部分保存的系统 UUID：
$ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid这会输出系统 UUID。例如：
"F5055C6C-477F-47FB-AFE5-95C6928C407F"
在定义特定于节点的 hieradata 的环境文件中使用此系统 UUID，并将 per_node.yaml 模板注册到预配置 hook。例如：
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" ]}}'
在运行 openstack overcloud deploy 时包含此环境文件。
per_node.yaml 模板会在与每个系统 UUID 对应的节点上生成一组 heiradata 文件，其中包含您定义的 hieradata。如果未定义 UUID，则生成的 hieradata 文件为空。在上例中，per_node.yaml 模板在所有 Compute 节点上运行（如 OS::TripleO::ComputeExtraConfigPre hook），但只有带有系统 UUID F5055C6C-477F-47FB-AFE5-95C407F 的 Compute 节点接收 hieradata。
这提供了一种将每个节点根据特定要求定制的方法。
4.7. Puppet：应用自定义清单
在某些情况下，您可能需要为 Overcloud 节点安装和配置一些额外的组件。您可以通过一个自定义 Puppet 清单来实现此目的，该清单在主配置完成后应用到节点上的节点。作为基本示例，您可能打算将 motd 安装到每个节点。完成的过程是首先创建一个启动 Puppet 配置的 Heat 模板(/home/stack/templates/custom_puppet_config.yaml)。
heat_template_version: 2014-10-16
description: >
Run Puppet extra configuration to set new MOTD
parameters:
servers:
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 类。
接下来，创建一个环境文件(/home/stack/templates/puppet_post_config.yaml)，将 heat 模板注册为 OS::TripleO::NodeExtraConfigPost: 资源类型。
resource_registry:
OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml最后，在创建或更新 Overcloud 堆栈时，将此环境文件与其他环境文件一起包含：
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/puppet_post_config.yaml \
...
这会将 motd.pp 的配置应用到 Overcloud 中的所有节点。
第 5 章 Overcloud 注册
Overcloud 提供了一种将节点注册到 Red Hat Content Delivery Network、Red Hat Satellite 5 服务器或 Red Hat Satellite 6 服务器的方法。
5.1. 将 Overcloud 注册到环境文件
从 Heat 模板集合中复制注册文件：
$ cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration ~/templates/.
编辑 ~/templates/rhel-registration/environment-rhel-registration.yaml，并修改以下值以适合您的注册方法和详情。
- rhel_reg_method
-
选择注册方法。
门户、卫星或禁用。 - rhel_reg_type
-
要注册的单元类型。留空以注册
为系统 - rhel_reg_auto_attach
-
自动向此系统附加兼容订阅。设置为
true来启用。要禁用此功能，请从环境文件中删除此参数。 - rhel_reg_service_level
- 用于自动附加的服务级别。
- rhel_reg_release
- 使用此参数为自动附加设置发行版本。留空以从 Red Hat Subscription Manager 中使用默认值。
- rhel_reg_pool_id
-
要使用的订阅池 ID。如果没有自动附加订阅，则使用它。要找到此 ID，请从 undercloud 节点运行
sudo subscription-manager list --available --all --matches="*OpenStack*"，并使用生成的池 ID值。 - rhel_reg_sat_url
-
注册 Overcloud 节点的 Satellite 服务器的基本 URL。此参数需要使用 Satellite 的 HTTP URL 而不是 HTTPS URL。例如，使用 http://satellite.example.com 而不使用 https://satellite.example.com。Overcloud 创建过程使用此 URL 来确定服务器是 Red Hat Satellite 5 还是 Red Hat Satellite 6 服务器。如果 Red Hat Satellite 6 服务器，Overcloud 获取
katello-ca-consumer-latest.noarch.rpm文件，使用subscription-manager注册，并安装katello-agent。如果 Red Hat Satellite 5 服务器，Overcloud 获取RHN-ORG-TRUSTED-SSL-CERT文件，并使用rhnreg_ks注册。 - rhel_reg_server_url
- 要使用的订阅服务的主机名。默认值是客户门户网站订阅管理、subscription.rhn.redhat.com。如果没有使用这个选项，系统会在客户门户网站订阅管理中注册。订阅服务器 URL 使用 https://hostname:port/prefix 的形式。
- rhel_reg_base_url
- 提供用于接收更新的内容交付服务器的主机名。默认值为 https://cdn.redhat.com。由于 Satellite 6 托管自己的内容，因此 URL 必须用于 Satellite 6 注册的系统。内容的基本 URL 使用 https://hostname:port/prefix 的形式。
- rhel_reg_org
-
用于注册的组织。要找到此 ID，请从 undercloud 节点运行
sudo subscription-manager组织。出现提示时输入您的红帽凭证，并使用生成的Key值。 - rhel_reg_environment
- 在所选机构中使用的环境。
- rhel_reg_repos
- 以逗号分隔的存储库列表，以启用。
- rhel_reg_activation_key
- 用于注册的激活码。
- rhel_reg_user; rhel_reg_password
- 注册的用户名和密码。如果可能，使用激活密钥注册。
- rhel_reg_machine_name
- 机器名称。将此保留为空白，以使用节点的主机名。
- rhel_reg_force
-
设置为
true以强制注册选项。例如，重新注册节点时。 - rhel_reg_sat_repo
-
包含 Red Hat Satellite 6 管理工具的存储库，如
katello-agent。检查与 Red Hat Satellite 版本对应的正确的存储库名称，检查存储库是否在 Satellite 服务器上同步。例如，rhel-7-server-satellite-tools-6.2-rpms对应于 Red Hat Satellite 6.2。
部署命令(openstack overcloud deploy)使用 -e 选项添加环境文件。添加 ~/templates/rhel-registration/environment-rhel-registration.yaml 和 ~/templates/rhel-registration/rhel-registration-resource-registry.yaml。例如：
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml -e /home/stack/templates/rhel-registration/rhel-registration-resource-registry.yaml
注册设置为 OS::TripleO::NodeExtraConfig Heat 资源。这意味着您只能将此资源用于注册。如需更多信息，请参阅 第 4.2 节 “pre-Configuration：自定义特定 Overcloud 角色”。
5.2. 示例 1：注册到客户门户网站
以下使用 my-openstack 激活密钥将 overcloud 节点注册到红帽客户门户，并订阅到池 1a85f9223e3d5e43013e3d6e8ff506fd。
parameter_defaults:
rhel_reg_auto_attach: ""
rhel_reg_activation_key: "my-openstack"
rhel_reg_org: "1234567"
rhel_reg_pool_id: "1a85f9223e3d5e43013e3d6e8ff506fd"
rhel_reg_repos: "rhel-7-server-rpms,rhel-7-server-extras-rpms,rhel-7-server-rh-common-rpms,rhel-ha-for-rhel-7-server-rpms,rhel-7-server-openstack-10-rpms,rhel-7-server-rhceph-2-osd-rpms,rhel-7-server-rhceph-2-mon-rpms,rhel-7-server-rhceph-2-tools-rpms"
rhel_reg_method: "portal"
rhel_reg_sat_repo: ""
rhel_reg_base_url: ""
rhel_reg_environment: ""
rhel_reg_force: ""
rhel_reg_machine_name: ""
rhel_reg_password: ""
rhel_reg_release: "7.7"
rhel_reg_sat_url: ""
rhel_reg_server_url: ""
rhel_reg_service_level: ""
rhel_reg_user: ""
rhel_reg_type: ""
rhel_reg_http_proxy_host: ""
rhel_reg_http_proxy_port: ""
rhel_reg_http_proxy_username: ""
rhel_reg_http_proxy_password: ""5.3. 示例 2：注册到 Red Hat Satellite 6 服务器
以下命令将 overcloud 节点注册到位于 sat6.example.com 的 Red Hat Satellite 6 服务器，并使用 my-openstack 激活密钥订阅池 1a85f9223e3d5e43013e3d6e8ff506fd。在这种情况下，激活密钥还提供要启用的存储库。
parameter_defaults:
rhel_reg_activation_key: "my-openstack"
rhel_reg_org: "1"
rhel_reg_pool_id: "1a85f9223e3d5e43013e3d6e8ff506fd"
rhel_reg_method: "satellite"
rhel_reg_sat_url: "http://sat6.example.com"
rhel_reg_sat_repo: "rhel-7-server-satellite-tools-6.2-rpms"
rhel_reg_repos: ""
rhel_reg_auto_attach: ""
rhel_reg_base_url: ""
rhel_reg_environment: ""
rhel_reg_force: ""
rhel_reg_machine_name: ""
rhel_reg_password: ""
rhel_reg_release: "7.7"
rhel_reg_server_url: ""
rhel_reg_service_level: ""
rhel_reg_user: ""
rhel_reg_type: ""
rhel_reg_http_proxy_host: ""
rhel_reg_http_proxy_port: ""
rhel_reg_http_proxy_username: ""
rhel_reg_http_proxy_password: ""5.4. 示例 3：注册到 Red Hat Satellite 5 服务器
以下命令将 overcloud 节点注册到位于 sat5.example.com 的 Red Hat Satellite 5 服务器，使用 my-openstack 激活密钥，并自动附加订阅。在这种情况下，激活密钥还提供要启用的存储库。
parameter_defaults:
rhel_reg_auto_attach: ""
rhel_reg_activation_key: "my-openstack"
rhel_reg_org: "1"
rhel_reg_method: "satellite"
rhel_reg_sat_url: "http://sat5.example.com"
rhel_reg_repos: ""
rhel_reg_base_url: ""
rhel_reg_environment: ""
rhel_reg_force: ""
rhel_reg_machine_name: ""
rhel_reg_password: ""
rhel_reg_pool_id: ""
rhel_reg_release: "7.7"
rhel_reg_server_url: ""
rhel_reg_service_level: ""
rhel_reg_user: ""
rhel_reg_type: ""
rhel_reg_sat_repo: ""
rhel_reg_http_proxy_host: ""
rhel_reg_http_proxy_port: ""
rhel_reg_http_proxy_username: ""
rhel_reg_http_proxy_password: ""第 6 章 可组合服务和自定义角色
Overcloud 通常由预定义角色中的节点组成，如 Controller 节点、Compute 节点和不同的存储节点类型。这些默认角色各自包含 director 节点上核心 Heat 模板集合中定义的一组服务。但是，核心 Heat 模板的架构提供了如下方法：
- 创建自定义角色
- 为每个角色添加和删除服务
本章介绍了自定义角色、可组合服务和方法的架构。
指南和限制
请注意可组合节点架构的以下指南和限制：
-
您可以将任何
systemd受管服务分配给受支持的独立自定义角色。 - 您无法分割 Pacemaker 管理的服务。这是因为 Pacemaker 在 Overcloud 集群内的每个节点上管理相同的服务集合。分割 Pacemaker 管理的服务可能会导致集群部署错误。这些服务应保留在 Controller 角色上。
- 您无法在升级过程中更改为自定义角色和可组合服务，从 Red Hat OpenStack Platform 9 升级到 10。升级脚本只能容纳默认的 Overcloud 角色。
- 您可以在初始部署后创建额外的自定义角色，并进行部署以扩展现有服务。
- 在部署 Overcloud 后，您无法修改任何角色的服务列表。在 Overcloud 部署后修改服务列表可能会导致部署错误并在节点上保留孤立的服务。
支持的自定义角色架构
自定义角色和可组合服务是 Red Hat OpenStack Platform 10 中的新功能，在这个早期阶段只测试并验证了有限的可组合服务组合。红帽在使用自定义角色和可组合服务时支持以下构架：
- 架构 1 - Monolithic Controller
- 所有控制器服务都包含在一个 Controller 角色中。这是默认值。详情请查看 第 6.8 节 “服务架构：Monolithic Controller”。
- 架构 2 - Split Controller
控制器服务被分成两个角色：
- 控制器 PCMK - 核心 Pacemaker 管理的服务，如数据库和负载均衡
- Controller Systemd - 'systemd`-managed OpenStack Platform services
- 架构 3 - 独立角色
- 使用架构 1 或架构 2，除了将 OpenStack Platform 服务分成自定义角色外。详情请查看 第 6.10 节 “服务架构：独立角色”。
6.1. 检查自定义角色架构
Overcloud 创建流程利用包含角色数据的模板来定义其角色。默认模板位于 /usr/share/openstack-tripleo-heat-templates/roles_data.yaml，定义所有默认角色类型： Controller、Compute、BlockStorage、ObjectStorage 和 CephStorage。
如果创建自定义 roles_data.yaml 文件，则 Controller 角色必须始终是定义的第一个角色。此角色被视为主要角色。
每个角色都包含以下参数：
- name
-
（必需） 角色的名称，这是没有空格或特殊字符的纯文本名称。检查所选名称不会导致与其他资源冲突。例如，使用
Networker作为名称而不是Network。有关角色名称的建议，请参阅 第 6.9 节 “Service Architecture: Split Controller”。 - CountDefault
- （可选） 定义要为此角色部署的默认节点数量。
- HostnameFormatDefault
（可选） 定义角色的默认主机名格式。默认命名规则使用以下格式：
[STACK NAME]-[ROLE NAME]-[NODE ID]例如，默认的 Controller 节点被命名：
overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ...- ServicesDefault
- （可选） 定义节点上要包含的默认服务列表。如需更多信息，请参阅 第 6.2 节 “检查可组合服务架构”。
这些选项提供了创建新角色并定义要包含哪些服务的方法。
openstack overcloud deploy 命令将 roles_data.yaml 文件中的参数集成到 overcloud.j2.yaml Heat 模板。在某些点上，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.yaml 中的每个 name 参数来命名每个对应的 OS::Heat::ResourceGroup 资源。
6.2. 检查可组合服务架构
核心 Heat 模板集合包含 puppet/services 子目录中的可组合服务模板集合。您可以使用以下命令查看这些服务：
$ ls /usr/share/openstack-tripleo-heat-templates/puppet/services
每个服务模板都包含标识其目的的描述。例如，keystone.yaml 服务模板包含以下描述：
description: >
OpenStack Identity (`keystone`) service configured with Puppet
这些服务模板注册为特定于 Red Hat OpenStack Platform 部署的资源。这意味着，您可以使用 overcloud-resource-registry-puppet.j2.yaml 文件中定义的唯一 Heat 资源命名空间来调用每个资源。所有服务都使用 OS::TripleO::Services 命名空间作为其资源类型。例如，keystone.yaml 服务模板注册到 OS::TripleO::Services::Keystone 资源类型：
grep "OS::TripleO::Services::Keystone" /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.j2.yaml
OS::TripleO::Services::Keystone: puppet/services/keystone.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([])}}
对于默认角色，这会创建以下服务列表参数： ControllerServices,ComputeServices,BlockStorageServices,ObjectStorageServices, 和 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 文件中的 services 列表。
6.3. 启用禁用的服务
一些服务默认为禁用。这些服务在 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 文件，该文件包含以下内容：
resource_registry:
OS::TripleO::Services::CinderBackup: ../puppet/services/pacemaker/cinder-backup.yaml
...
这会覆盖默认的 null 操作资源并启用服务。在运行 openstack overcloud deploy 命令时包含此环境文件。
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml
有关如何启用禁用服务的另一个示例，请参阅 OpenStack 数据处理 指南中的 安装 部分。本节介绍如何在 overcloud 上启用 OpenStack 数据处理服务(sahara)。
6.4. 从角色添加和删除服务
添加或删除服务的基本方法涉及为节点角色创建默认服务列表的副本，然后添加或删除服务。例如，您可能想从 Controller 节点移除 OpenStack Orchestration (heat)。在这种情况下，创建默认 roles_data.yaml 文件的自定义副本：
$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/templates/roles_data-no_heat.yaml
编辑 roles_data 文件并修改 Controller 的 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
在运行 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::None6.5. 创建新角色
在本例中，旨在创建一个新的 Networker 角色，以仅托管 OpenStack 网络(neutron)代理。在这种情况下，您可以创建一个包含新角色信息的自定义 roles_data 文件。
创建默认 roles_data.yaml 文件的自定义副本：
$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/templates/roles_data-network_node.yaml
编辑新的 roles_data 文件，再创建一个新的 Networker 角色，其中包含基础和核心 OpenStack 网络服务。例如：
- name: Networker
CountDefault: 1
HostnameFormatDefault: '%stackname%-networker-%index%'
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::NeutronDhcpAgent
- OS::TripleO::Services::NeutronL3Agent
- OS::TripleO::Services::NeutronMetadataAgent
- OS::TripleO::Services::NeutronOvsAgent
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::VipHosts
最好将 CountDefault 设置为 1，以便默认 Overcloud 始终包含网络节点。
如果在现有 overcloud 中扩展服务，请将现有服务保留在 Controller 角色上。如果创建新 overcloud，且您只希望 OpenStack 网络代理保留在单机角色中，请从 Controller 角色定义中删除 OpenStack 网络代理：
- 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
- OS::TripleO::Services::HeatApi
- OS::TripleO::Services::HeatApiCfn
- OS::TripleO::Services::HeatApiCloudwatch
- OS::TripleO::Services::HeatEngine
- OS::TripleO::Services::MySQL
- OS::TripleO::Services::NeutronDhcpAgent # Remove this service
- OS::TripleO::Services::NeutronL3Agent # Remove this service
- OS::TripleO::Services::NeutronMetadataAgent # Remove this service
- OS::TripleO::Services::NeutronApi
- OS::TripleO::Services::NeutronCorePlugin
- OS::TripleO::Services::NeutronOvsAgent # Remove this service
- OS::TripleO::Services::RabbitMQ
...
您可能需要为此角色定义一个新类别，以便您可以标记特定的节点。在本例中，使用以下命令创建 networker 类别：
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 networker
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker使用以下命令将节点标记为新类别：
$ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13使用以下环境文件片断定义 Networker 节点数和类别：
parameter_defaults:
OvercloudNetworkerFlavor: networker
NetworkerCount: 1
在运行 openstack overcloud deploy 命令时，包括新的 roles_data 文件和环境文件。例如：
$ openstack overcloud deploy --templates -r ~/templates/roles_data-network_node.yaml -e ~/templates/node-count-flavor.yaml部署完成后，这将创建一个由一个 Controller 节点、一个 Compute 节点和一个 Networker 节点组成的三节点 Overcloud。要查看 Overcloud 的节点列表，请运行以下命令：
$ nova list6.6. 创建带有 No Services 的通用节点
Red Hat OpenStack Platform 提供了创建没有配置任何 OpenStack 服务的通用 Red Hat Enterprise Linux 7 节点的功能。如果您需要在 Red Hat OpenStack Platform 核心环境外托管软件，这将非常有用。例如，OpenStack 平台提供与 Kibana 和 Sensu 等监控工具的集成（请参阅 第 12 章 监控工具配置）。虽然红帽不提供对监控工具本身的支持，但 director 可以创建一个通用的 Red Hat Enterprise Linux 7 节点来托管这些工具。
通用节点仍然使用基础 overcloud-full 镜像，而不是基础 Red Hat Enterprise Linux 7 镜像。这意味着节点安装了一些 Red Hat OpenStack Platform 软件，但不启用或配置。
创建通用节点需要一个没有 ServicesDefault 列表的新角色：
- name: Generic
在您的自定义 roles_data 文件(roles_data_with_generic.yaml)中包含该角色。确保保留现有的 Controller 和 Compute 角色。
您还可以包括一个环境文件(generic-node-params.yaml)，用于指定需要多少个通用 Red Hat Enterprise Linux 7 节点，以及在选择要置备节点时类别。例如：
parameter_defaults:
OvercloudGenericFlavor: baremetal
GenericCount: 1
在运行 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 7 节点的三节点环境。
6.7. 创建超融合计算和 Ceph 服务
超融合计算和 Ceph 服务是一个技术预览功能。技术预览功能不完全支持在红帽订阅服务级别协议(SLA)中，其功能可能并不完善，且不适用于生产环境。但是，这些功能可让您早期访问即将推出的产品创新，使客户能够在开发过程中测试并提供反馈意见。有关技术预览功能的支持范围的更多信息，请参阅 https://access.redhat.com/support/offerings/techpreview/。
Ceph OSD 服务通常在自己的 Ceph Storage 节点上运行。但是，可组合服务提供了一种在 Compute 节点上配置 Ceph OSD 服务的方法。
例如，每个角色的默认服务列表包括：
Compute 节点：
- name: Compute
CountDefault: 1
HostnameFormatDefault: '%stackname%-novacompute-%index%'
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::CephClient
- OS::TripleO::Services::CephExternal
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::NovaCompute
- OS::TripleO::Services::NovaLibvirt
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::ComputeNeutronCorePlugin
- OS::TripleO::Services::ComputeNeutronOvsAgent
- OS::TripleO::Services::ComputeCeilometerAgent
- OS::TripleO::Services::ComputeNeutronL3Agent
- OS::TripleO::Services::ComputeNeutronMetadataAgent
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::NeutronSriovAgent
- OS::TripleO::Services::OpenDaylightOvs
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::VipHostsCeph Storage 节点：
- name: CephStorage
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::CephOSD
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::VipHosts
Ceph Storage 角色包含 Compute 角色通用的服务，这意味着您可以忽略它们。一个服务保留： OS::TripleO::Services::CephOSD。
创建默认 roles_data 文件的自定义版本：
$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/templates/roles_data-ceph_osd_on_compute.yaml
编辑该文件，将 OS::TripleO::Services::CephOSD 添加到计算的服务列表中：
- name: Compute
CountDefault: 1
HostnameFormatDefault: '%stackname%-novacompute-%index%'
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::CephClient
- OS::TripleO::Services::CephOSD
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::NovaCompute
- OS::TripleO::Services::NovaLibvirt
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::ComputeNeutronCorePlugin
- OS::TripleO::Services::ComputeNeutronOvsAgent
- OS::TripleO::Services::ComputeCeilometerAgent
- OS::TripleO::Services::ComputeNeutronL3Agent
- OS::TripleO::Services::ComputeNeutronMetadataAgent
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::NeutronSriovAgent
- OS::TripleO::Services::OpenDaylightOvs
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::VipHosts
您也可以从计算服务列表中安全地移除 OS::TripleO::Services::CephExternal 服务，因为 Overcloud 不与外部 Ceph 存储集群集成。
在运行 openstack overcloud deploy 命令时包含此角色文件。例如：
$ openstack overcloud deploy --templates -r ~/templates/roles_data-ceph_osd_on_compute.yaml -e ~/template/storage-environment.yaml
请注意，这个命令还包括用于存储的自定义环境文件(storage-environment.yaml)，其中包含特定于 Ceph Storage 的参数。
在 Overcloud 部署后，验证 Compute 节点上的 Ceph OSD 安装。登录到 Compute 节点并运行以下命令：
[root@overcloud-novacompute-0 ~]# ps ax | grep ceph
17437 ? Ss 0:00 /bin/bash -c ulimit -n 32768; /usr/bin/ceph-osd -i 0 --pid-file /var/run/ceph/osd.0.pid -c /etc/ceph/ceph.conf --cluster ceph -f
17438 ? Sl 0:00 /usr/bin/ceph-osd -i 0 --pid-file /var/run/ceph/osd.0.pid -c /etc/ceph/ceph.conf --cluster ceph -f6.8. 服务架构：Monolithic Controller
可组合服务的默认架构使用单一控制器，其中包含 Red Hat OpenStack Platform 核心服务。这些默认服务在 director 的 Heat 模板集合(/usr/share/openstack-tripleo-heat-templates/roles_data.yaml)中包含的角色文件中定义。
一些服务默认为禁用。有关如何启用这些服务的详情，请查看 第 6.3 节 “启用禁用的服务”。
- name: Controller
ServicesDefault:
- OS::TripleO::Services::Apache
- OS::TripleO::Services::AodhApi
- OS::TripleO::Services::AodhEvaluator
- OS::TripleO::Services::AodhListener
- OS::TripleO::Services::AodhNotifier
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::CeilometerAgentCentral
- OS::TripleO::Services::CeilometerAgentNotification
- OS::TripleO::Services::CeilometerApi
- OS::TripleO::Services::CeilometerCollector
- OS::TripleO::Services::CeilometerExpirer
- OS::TripleO::Services::CephClient
- OS::TripleO::Services::CephExternal
- OS::TripleO::Services::CephMon
- OS::TripleO::Services::CephRgw
- OS::TripleO::Services::CinderApi
- OS::TripleO::Services::CinderBackup
- OS::TripleO::Services::CinderScheduler
- OS::TripleO::Services::CinderVolume
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::GlanceApi
- OS::TripleO::Services::GlanceRegistry
- OS::TripleO::Services::GnocchiApi
- 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
- OS::TripleO::Services::IronicApi
- OS::TripleO::Services::IronicConductor
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Keepalived
- OS::TripleO::Services::Keystone
- OS::TripleO::Services::ManilaApi
- OS::TripleO::Services::ManilaBackendCephFs
- OS::TripleO::Services::ManilaBackendGeneric
- OS::TripleO::Services::ManilaBackendNetapp
- OS::TripleO::Services::ManilaScheduler
- OS::TripleO::Services::ManilaShare
- OS::TripleO::Services::Memcached
- OS::TripleO::Services::MongoDb
- OS::TripleO::Services::MySQL
- OS::TripleO::Services::NeutronApi
- OS::TripleO::Services::NeutronCorePlugin
- OS::TripleO::Services::NeutronCorePluginML2OVN
- OS::TripleO::Services::NeutronCorePluginMidonet
- OS::TripleO::Services::NeutronCorePluginNuage
- OS::TripleO::Services::NeutronCorePluginOpencontrail
- OS::TripleO::Services::NeutronCorePluginPlumgrid
- OS::TripleO::Services::NeutronDhcpAgent
- OS::TripleO::Services::NeutronL3Agent
- OS::TripleO::Services::NeutronMetadataAgent
- OS::TripleO::Services::NeutronOvsAgent
- OS::TripleO::Services::NovaApi
- OS::TripleO::Services::NovaConductor
- OS::TripleO::Services::NovaConsoleauth
- OS::TripleO::Services::NovaIronic
- OS::TripleO::Services::NovaScheduler
- OS::TripleO::Services::NovaVncProxy
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::OpenDaylightApi
- OS::TripleO::Services::OpenDaylightOvs
- OS::TripleO::Services::Pacemaker
- OS::TripleO::Services::RabbitMQ
- OS::TripleO::Services::Redis
- OS::TripleO::Services::SaharaApi
- OS::TripleO::Services::SaharaEngine
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::SwiftProxy
- OS::TripleO::Services::SwiftRingBuilder
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts6.9. Service Architecture: Split Controller
您可以将 Controller 节点上的服务分成两个独立的角色：
- Controller PCMK - 仅包含 Pacemaker 管理（包括数据库和负载均衡）的核心服务
- Controller systemd - Contains all OpenStack services
剩余的默认角色(Compute、Ceph Storage、Object Storage 和 Block Storage)保持不受影响。
使用下表作为创建分割控制器架构的指南。
一些服务默认为禁用。有关如何启用这些服务的详情，请查看 第 6.3 节 “启用禁用的服务”。
Controller PCMK
以下服务是 Controller PCMK 角色所需的最低服务。
- name: Controller
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::CephClient
- OS::TripleO::Services::CephExternal
- OS::TripleO::Services::CinderBackup
- OS::TripleO::Services::CinderVolume
- OS::TripleO::Services::HAproxy
- OS::TripleO::Services::Keepalived
- OS::TripleO::Services::ManilaBackendGeneric
- OS::TripleO::Services::ManilaBackendNetapp
- OS::TripleO::Services::ManilaBackendCephFs
- OS::TripleO::Services::ManilaShare
- OS::TripleO::Services::Memcached
- OS::TripleO::Services::MySQL
- OS::TripleO::Services::Pacemaker
- OS::TripleO::Services::RabbitMQ
- OS::TripleO::Services::RedisController systemd
下表表示 Controller systemd 角色中可用的服务：
- name: ControllerSystemd
ServicesDefault:
- OS::TripleO::Services::Apache
- OS::TripleO::Services::AodhApi
- OS::TripleO::Services::AodhEvaluator
- OS::TripleO::Services::AodhListener
- OS::TripleO::Services::AodhNotifier
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::CeilometerAgentCentral
- OS::TripleO::Services::CeilometerAgentNotification
- OS::TripleO::Services::CeilometerApi
- OS::TripleO::Services::CeilometerCollector
- OS::TripleO::Services::CeilometerExpirer
- OS::TripleO::Services::CephClient
- OS::TripleO::Services::CephExternal
- OS::TripleO::Services::CephMon
- OS::TripleO::Services::CephRgw
- OS::TripleO::Services::CinderApi
- OS::TripleO::Services::CinderScheduler
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::GlanceApi
- OS::TripleO::Services::GlanceRegistry
- OS::TripleO::Services::GnocchiApi
- OS::TripleO::Services::GnocchiMetricd
- OS::TripleO::Services::GnocchiStatsd
- OS::TripleO::Services::HeatApi
- OS::TripleO::Services::HeatApiCfn
- OS::TripleO::Services::HeatApiCloudwatch
- OS::TripleO::Services::HeatEngine
- OS::TripleO::Services::Horizon
- OS::TripleO::Services::IronicApi
- OS::TripleO::Services::IronicConductor
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Keystone
- OS::TripleO::Services::ManilaApi
- OS::TripleO::Services::ManilaScheduler
- OS::TripleO::Services::MongoDb
- OS::TripleO::Services::NeutronApi
- OS::TripleO::Services::NeutronCorePlugin
- OS::TripleO::Services::NeutronCorePluginML2OVN
- OS::TripleO::Services::NeutronCorePluginMidonet
- OS::TripleO::Services::NeutronCorePluginNuage
- OS::TripleO::Services::NeutronCorePluginOpencontrail
- OS::TripleO::Services::NeutronCorePluginPlumgrid
- OS::TripleO::Services::NeutronDhcpAgent
- OS::TripleO::Services::NeutronL3Agent
- OS::TripleO::Services::NeutronMetadataAgent
- OS::TripleO::Services::NeutronOvsAgent
- OS::TripleO::Services::NovaApi
- OS::TripleO::Services::NovaConductor
- OS::TripleO::Services::NovaConsoleauth
- OS::TripleO::Services::NovaIronic
- OS::TripleO::Services::NovaScheduler
- OS::TripleO::Services::NovaVncProxy
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::OpenDaylightApi
- OS::TripleO::Services::OpenDaylightOvs
- OS::TripleO::Services::SaharaApi
- OS::TripleO::Services::SaharaEngine
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::SwiftProxy
- OS::TripleO::Services::SwiftRingBuilder
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts6.10. 服务架构：独立角色
下表列出了您可以使用 Red Hat OpenStack Platform 中的可组合服务架构创建和扩展支持的自定义角色集合。将这些集合分组到各个角色中，并将它们与之前的架构一起使用来隔离和分割服务：
一些服务默认为禁用。有关如何启用这些服务的详情，请查看 第 6.3 节 “启用禁用的服务”。
请注意，所有角色都使用一组 通用服务，其中包括：
-
OS::TripleO::Services::CACerts -
OS::TripleO::Services::FluentdClient -
OS::TripleO::Services::Kernel -
OS::TripleO::Services::Ntp -
OS::TripleO::Services::SensuClient -
OS::TripleO::Services::Sshd -
OS::TripleO::Services::Snmp -
OS::TripleO::Services::Timezone -
OS::TripleO::Services::TripleoFirewall -
OS::TripleO::Services::TripleoPackages -
OS::TripleO::Services::VipHosts
在选择了要包含在 overcloud 中的角色后，从主 Controller 角色中删除相关服务（通用服务除外）。例如，如果创建独立 Keystone 角色，请从 Controller 节点中删除 OS::TripleO::Services::Apache 和 OS::TripleO::Services::Keystone 服务。唯一的例外是服务有有限的自定义角色支持（请参阅 表 6.1 “自定义角色支持”）。
单击下表中的角色，以查看与其关联的服务。
| 角色 | 支持状态 |
|---|---|
| 支持 | |
| 支持 | |
| 有限.如果分割，这个服务需要是 Controller systemd 角色的一部分。 | |
| 支持 | |
| 支持 | |
| 支持 | |
| 支持 | |
| 支持 | |
| 有限.如果分割，这个服务需要是 Controller systemd 角色的一部分。 | |
| 支持 | |
| 有限.如果分割，这个服务需要是 Controller systemd 角色的一部分。 | |
| 支持 | |
| 支持 | |
| 支持 | |
| 支持 | |
| 技术预览 | |
| 有限.如果分割，这个服务需要是 Controller systemd 角色的一部分。 | |
| 支持 | |
| 支持 | |
| 支持 |
Ceph Storage Monitor
以下服务配置 Ceph 存储监控器。
- name: CephMon
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::CephMonCeph Storage OSD
以下服务配置 Ceph Storage OSD。
- name: CephStorage
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::CephOSDCeph Storage RadosGW
以下服务配置 Ceph Storage RadosGW。如果分离这些服务，它们需要是 Controller systemd 角色的一部分。
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::CephRgw
- OS::TripleO::Services::CephClientCinder API
以下服务配置 OpenStack Block Storage API。
- name: CinderApi
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::CinderApi
- OS::TripleO::Services::CinderSchedulerController PCMK
以下服务是 Controller PCMK 角色所需的最低服务。
- name: ControllerPcmk
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::CephClient
- OS::TripleO::Services::CephExternal
- OS::TripleO::Services::CinderBackup
- OS::TripleO::Services::CinderVolume
- OS::TripleO::Services::HAproxy
- OS::TripleO::Services::Keepalived
- OS::TripleO::Services::ManilaBackendGeneric
- OS::TripleO::Services::ManilaBackendNetapp
- OS::TripleO::Services::ManilaBackendCephFs
- OS::TripleO::Services::ManilaShare
- OS::TripleO::Services::Memcached
- OS::TripleO::Services::MySQL
- OS::TripleO::Services::Pacemaker
- OS::TripleO::Services::RabbitMQ
- OS::TripleO::Services::Redis
- OS::TripleO::Services::VipHostsGlance
以下服务配置 OpenStack 镜像服务。
- name: Glance
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::CephClient
- OS::TripleO::Services::CephExternal
- OS::TripleO::Services::GlanceApi
- OS::TripleO::Services::GlanceRegistryHeat
以下服务配置 OpenStack 编排服务：
- name: Heat
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::HeatApi
- OS::TripleO::Services::HeatApiCfn
- OS::TripleO::Services::HeatApiCloudwatch
- OS::TripleO::Services::HeatEngineHorizon
以下服务配置 OpenStack 控制面板。
- name: Horizon
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::Apache
- OS::TripleO::Services::Horizonironic
以下服务配置 OpenStack 裸机置备服务。如果分离这些服务，它们需要是 Controller systemd 角色的一部分。
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::IronicApi
- OS::TripleO::Services::IronicConductor
- OS::TripleO::Services::NovaIronicKeystone
以下服务配置 OpenStack 身份服务：在执行次要更新时，请确保在更新其他服务前更新此角色。
- name: Keystone
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::Apache
- OS::TripleO::Services::KeystoneManila
以下服务配置 OpenStack 共享文件系统服务。如果分离这些服务，它们需要是 Controller systemd 角色的一部分。
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::ManilaApi
- OS::TripleO::Services::ManilaSchedulerNetworker
以下服务配置 OpenStack 网络代理：
- name: Networker
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::NeutronDhcpAgent
- OS::TripleO::Services::NeutronL3Agent
- OS::TripleO::Services::NeutronMetadataAgent
- OS::TripleO::Services::NeutronOvsAgentNeutron API
以下服务配置 OpenStack 网络 API：
- name: NeutronApi
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::NeutronApi
- OS::TripleO::Services::NeutronCorePlugin
- OS::TripleO::Services::NeutronCorePluginML2OVN
- OS::TripleO::Services::NeutronCorePluginMidonet
- OS::TripleO::Services::NeutronCorePluginNuage
- OS::TripleO::Services::NeutronCorePluginOpencontrail
- OS::TripleO::Services::NeutronCorePluginPlumgridNova
以下服务配置 OpenStack 计算服务：
- name: Nova
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::NovaApi
- OS::TripleO::Services::NovaConductor
- OS::TripleO::Services::NovaConsoleauth
- OS::TripleO::Services::NovaScheduler
- OS::TripleO::Services::NovaVncProxyNova Compute
以下服务配置 OpenStack Compute 节点。
- name: Compute
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::CephClient
- OS::TripleO::Services::CephExternal
- OS::TripleO::Services::ComputeCeilometerAgent
- OS::TripleO::Services::ComputeNeutronCorePlugin
- OS::TripleO::Services::ComputeNeutronL3Agent
- OS::TripleO::Services::ComputeNeutronMetadataAgent
- OS::TripleO::Services::ComputeNeutronOvsAgent
- OS::TripleO::Services::NeutronSriovAgent
- OS::TripleO::Services::NovaCompute
- OS::TripleO::Services::NovaLibvirt
- OS::TripleO::Services::OpenDaylightOvsOpenDaylight
以下服务配置 OpenDayLight。这些服务是 Red Hat OpenStack Platform 10 的技术预览。
- name: Opendaylight
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::OpenDaylightApi
- OS::TripleO::Services::OpenDaylightOvsSahara
以下服务配置 OpenStack 集群服务。如果分离这些服务，它们需要成为 Controller systemd 角色的一部分。
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::SaharaApi
- OS::TripleO::Services::SaharaEngineSwift API
以下服务配置 OpenStack 对象存储 API。
- name: SwiftApi
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::SwiftProxy
- OS::TripleO::Services::SwiftRingBuilderSwift Storage
以下服务配置 OpenStack 对象存储服务：
- name: ObjectStorage
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::SwiftRingBuilder
- OS::TripleO::Services::SwiftStorageTelemetry
以下服务配置 OpenStack 遥测服务：
- name: Telemetry
ServicesDefault:
- OS::TripleO::Services::CACerts
- OS::TripleO::Services::FluentdClient
- OS::TripleO::Services::Kernel
- OS::TripleO::Services::Ntp
- OS::TripleO::Services::SensuClient
- OS::TripleO::Services::Sshd
- OS::TripleO::Services::Snmp
- OS::TripleO::Services::Timezone
- OS::TripleO::Services::TripleoFirewall
- OS::TripleO::Services::TripleoPackages
- OS::TripleO::Services::VipHosts
- OS::TripleO::Services::Apache
- OS::TripleO::Services::AodhApi
- OS::TripleO::Services::AodhEvaluator
- OS::TripleO::Services::AodhListener
- OS::TripleO::Services::AodhNotifier
- OS::TripleO::Services::CeilometerAgentCentral
- OS::TripleO::Services::CeilometerAgentNotification
- OS::TripleO::Services::CeilometerApi
- OS::TripleO::Services::CeilometerCollector
- OS::TripleO::Services::CeilometerExpirer
- OS::TripleO::Services::GnocchiApi
- OS::TripleO::Services::GnocchiMetricd
- OS::TripleO::Services::GnocchiStatsd
- OS::TripleO::Services::MongoDb6.11. 可组合服务参考
下表包含 Red Hat OpenStack Platform 中所有可用可组合服务的列表。
一些服务默认为禁用。有关如何启用这些服务的详情，请查看 第 6.3 节 “启用禁用的服务”。
| 服务 | 描述 |
|---|---|
|
|
使用 Puppet 配置的 OpenStack Telemetry Alarming ( |
|
|
OpenStack Telemetry Alarming ( |
|
|
使用 Puppet 配置的 OpenStack Telemetry Alarming ( |
|
|
使用 Puppet 配置的 OpenStack Telemetry Alarming ( |
|
| 配置有 Puppet 的 Apache 服务。请注意，这通常和通过 Apache 运行的其他服务自动包括。 |
|
| 配置 Puppet 的 HAProxy 服务 |
|
|
OpenStack Telemetry ( |
|
|
OpenStack Telemetry ( |
|
|
OpenStack Telemetry ( |
|
|
OpenStack Telemetry ( |
|
|
OpenStack Telemetry ( |
|
| (默认禁用) Ceph 客户端服务 |
|
| (默认禁用) Ceph 外部服务 |
|
| (默认禁用) Ceph Monitor 服务 |
|
| (默认禁用) Ceph OSD 服务 |
|
|
使用 Puppet 配置的 OpenStack Block Storage ( |
|
|
(默认为禁用)配置了 Puppet 的 OpenStack Block Storage ( |
|
|
OpenStack Block Storage ( |
|
|
使用 Puppet 配置的 OpenStack Block Storage ( |
|
|
OpenStack Telemetry ( |
|
|
OpenStack 网络( |
|
|
(默认禁用) OpenStack 网络( |
|
|
(默认情况下禁用)配置了 Puppet 的 OpenStack 网络( |
|
|
使用 Puppet 配置的 OpenStack 网络( |
|
| (默认禁用)配置了 Puppet 的 Fluentd 客户端 |
|
|
OpenStack Image ( |
|
|
OpenStack Image ( |
|
|
OpenStack Telemetry Metrics ( |
|
|
OpenStack Telemetry Metrics ( |
|
|
OpenStack Telemetry Metrics ( |
|
| 使用 Puppet 配置的 HAProxy 服务(Pacemaker 管理) |
|
|
使用 Puppet 配置的 OpenStack Orchestration ( |
|
|
使用 Puppet 配置的 OpenStack Orchestration ( |
|
|
使用 Puppet 配置的 OpenStack Orchestration ( |
|
|
使用 Puppet 配置的 OpenStack Orchestration ( |
|
|
OpenStack Dashboard ( |
|
|
(默认禁用) OpenStack Bare Metal Provisioning ( |
|
|
(默认禁用) OpenStack Bare Metal Provisioning ( |
|
| keepalived 服务配置有 Puppet |
|
| 使用 kmod 加载内核模块并使用 sysctl 配置内核选项 |
|
|
(默认禁用)配置了 Puppet 的 OpenStack 共享文件系统服务( |
|
|
(默认为禁用)配置了 Puppet 的 OpenStack 共享文件系统服务( |
|
|
(默认情况下禁用) OpenStack 共享文件系统服务( |
|
|
使用 Puppet 配置的 OpenStack Identity ( |
|
| 使用 Puppet 配置的 Memcached 服务 |
|
| 使用 puppet 部署 MongoDB 服务 |
|
| 使用 puppet 部署 MySQL (Pacemaker 管理的)服务部署 |
|
|
使用 Puppet 配置的 OpenStack 网络( |
|
|
OpenStack 网络( |
|
|
使用 Puppet 配置的 OpenStack 网络( |
|
|
OpenStack Networking ( |
|
|
OpenStack 网络( |
|
|
OpenStack Networking ( |
|
|
OpenStack Networking ( |
|
|
使用 Puppet 配置的 OpenStack 网络( |
|
|
使用 Puppet 配置的 OpenStack 网络( |
|
|
使用 Puppet 配置的 OpenStack 网络( |
|
|
使用 Puppet 配置的 OpenStack 网络( |
|
|
使用 Puppet 配置的 OpenStack 网络( |
|
| (默认情况下禁用)配置了 Puppet 的 OpenStack Neutron SR-IOV nic 代理 |
|
|
OpenStack Compute ( |
|
|
配置了 Puppet 的 OpenStack Compute ( |
|
|
OpenStack Compute ( |
|
|
OpenStack Compute ( |
|
|
(默认情况下禁用) OpenStack Compute ( |
|
| libvirt 服务配置有 Puppet |
|
|
OpenStack Compute ( |
|
|
OpenStack Compute ( |
|
| 使用 Puppet 进行 NTP 服务部署. |
|
| (默认禁用) OpenDaylight SDN 控制器 |
|
| (默认禁用) OpenDaylight OVS 配置 |
|
| 使用 Puppet 配置的 Pacemaker 服务 |
|
| 使用 Puppet 配置的 RabbitMQ 服务(Pacemaker 管理) |
|
| 使用 Puppet 配置的 OpenStack Redis 服务 |
|
|
(默认禁用) OpenStack 集群( |
|
|
(默认禁用)使用 Puppet 配置的 OpenStack 集群( |
|
| (默认情况下禁用)配置了 Puppet 的 Sensu 客户端 |
|
| (默认禁用) SSH 守护进程配置。作为默认服务包括。 |
|
| SNMP 客户端配置了 Puppet，在 undercloud 中促进 Ceilometer 硬件监控。启用硬件监控需要此服务。 |
|
|
OpenStack Object Storage ( |
|
|
OpenStack Object Storage ( |
|
|
OpenStack Object Storage ( |
|
| 可组合时区服务 |
|
| 防火墙设置 |
|
| 软件包安装设置 |
第 7 章 隔离网络
director 提供了配置隔离 Overcloud 网络的方法。这意味着 Overcloud 环境将网络流量类型划分为不同的网络，后者将网络流量分配到特定的网络接口或绑定。配置隔离的网络后，director 将 OpenStack 服务配置为使用隔离的网络。如果没有配置隔离网络，则所有服务都在 Provisioning 网络上运行。
这个示例为所有服务使用单独的网络：
- 网络 1 - 置备
- 网络 2 - 内部 API
- 网络 3 - 租户网络
- 网络 4 - 存储
- 网络 5 - 存储管理
- 网络 6 - 管理
- 网络 7 - 外部浮动 IP ( Overcloud 创建后映射)
在本例中，每个 Overcloud 节点使用绑定中的两个网络接口来提供 tagged VLAN 中的网络。以下网络分配适用于此绑定：
| 网络类型 | subnet | VLAN |
| 内部 API | 172.16.0.0/24 | 201 |
| tenant | 172.17.0.0/24 | 202 |
| 存储 | 172.18.0.0/24 | 203 |
| 存储管理 | 172.19.0.0/24 | 204 |
| 管理 | 172.20.0.0/24 | 205 |
| 外部/浮动 IP | 10.1.1.0/24 | 100 |
7.1. 创建自定义模板
Overcloud 网络配置需要一组网络接口模板。您可以自定义这些模板，以针对每个角色配置节点接口。这些模板是 YAML 格式的标准 Heat 模板（请参阅 第 2.1 节 “Heat 模板”）。director 包含一组示例模板，供您启动：
-
/usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans- 包含每个角色上带有 VLAN 配置的单个 NIC 的模板。 -
/usr/share/openstack-tripleo-heat-templates/network/bond-with-vlans- 包含每个角色上绑定 NIC 配置的模板的目录。 -
/usr/share/openstack-tripleo-heat-templates/network/config/multiple-nics- 包含每个角色为多个 NIC 配置的模板的目录。 -
/usr/share/openstack-tripleo-heat-templates/network/config/single-nic-linux-bridge-vlans- 包含每个角色上带有 VLAN 配置的单一 NIC 的模板，并使用 Linux 网桥而不是 Open vSwitch 网桥。
这些示例仅包含默认角色的模板。要为自定义角色定义网络接口配置，请将这些模板用作基础。
在本例中，使用默认绑定的 NIC 示例配置作为基础。复制位于 /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans 的版本。
$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans ~/templates/nic-configs
这会创建一组本地的 heat 模板，该模板为每个角色定义绑定的网络接口配置。每个模板都包含标准 参数、资源 和 output 部分。在本例中，您将只编辑 resources 部分。每个 resources 部分都以以下方式开始：
resources:
OsNetConfigImpl:
type: OS::Heat::StructuredConfig
properties:
group: os-apply-config
config:
os_net_config:
network_config:
这会为 os-apply-config 命令和 os-net-config 子命令创建一个请求，以配置节点的网络属性。network_config 部分包含基于类型的顺序排列的自定义接口配置，其中包括：
- interface
定义单个网络接口。配置使用实际接口名称("eth0", "eth1", "enp0s25")或一组数字接口("nic1", "nic2", "nic3")来定义各个接口。
- type: interface name: nic2- vlan
一个 VLAN。使用从
parameters部分传递的 VLAN ID 和子网。- type: vlan vlan_id: {get_param: ExternalNetworkVlanID} addresses: - ip_netmask: {get_param: ExternalIpSubnet}- ovs_bond
在 Open vSwitch 中定义绑定，将两个或多个
接口加入一起。这有助于冗余并增加带宽。- type: ovs_bond name: bond1 members: - type: interface name: nic2 - type: interface name: nic3- ovs_bridge
在 Open vSwitch 中定义一个网桥，它将多个接口
ovs_bond和vlan对象连接在一起。- type: ovs_bridge name: {get_input: bridge_name} members: - type: ovs_bond name: bond1 members: - type: interface name: nic2 primary: true - type: interface name: nic3 - type: vlan device: bond1 vlan_id: {get_param: ExternalNetworkVlanID} addresses: - ip_netmask: {get_param: ExternalIpSubnet}- linux_bond
定义一个将两个或多个
接口加入在一起的 Linux 绑定。这有助于冗余并增加带宽。确保在bonding_options参数中包含基于内核的绑定选项。有关 Linux 绑定选项的更多信息，请参阅 4.5.1。bonding Module Directives （在 Red Hat Enterprise Linux 7 网络指南中）。- type: linux_bond name: bond1 members: - type: interface name: nic2 - type: interface name: nic3 bonding_options: "mode=802.3ad"- linux_bridge
定义一个 Linux 网桥，它将多个接口 ,
linux_bond和vlan对象连接在一起。- type: linux_bridge name: bridge1 addresses: - ip_netmask: list_join: - '/' - - {get_param: ControlPlaneIp} - {get_param: ControlPlaneSubnetCidr} members: - type: interface name: nic1 primary: true - type: vlan vlan_id: {get_param: ExternalNetworkVlanID} device: bridge1 addresses: - ip_netmask: {get_param: ExternalIpSubnet} routes: - ip_netmask: 0.0.0.0/0 default: true next_hop: {get_param: ExternalInterfaceDefaultRoute}
有关这些项目的完整参数列表，请参阅 附录 C, 网络接口参数。
在本例中，您使用默认的绑定接口配置。例如，/home/stack/templates/nic-configs/controller.yaml 模板使用以下 network_config ：
resources:
OsNetConfigImpl:
type: OS::Heat::StructuredConfig
properties:
group: os-apply-config
config:
os_net_config:
network_config:
- type: interface
name: nic1
use_dhcp: false
addresses:
- ip_netmask:
list_join:
- '/'
- - {get_param: ControlPlaneIp}
- {get_param: ControlPlaneSubnetCidr}
routes:
- ip_netmask: 169.254.169.254/32
next_hop: {get_param: EC2MetadataIp}
- type: ovs_bridge
name: {get_input: bridge_name}
dns_servers: {get_param: DnsServers}
members:
- type: ovs_bond
name: bond1
ovs_options: {get_param: BondInterfaceOvsOptions}
members:
- type: interface
name: nic2
primary: true
- type: interface
name: nic3
- type: vlan
device: bond1
vlan_id: {get_param: ExternalNetworkVlanID}
addresses:
- ip_netmask: {get_param: ExternalIpSubnet}
routes:
- default: true
next_hop: {get_param: ExternalInterfaceDefaultRoute}
- type: vlan
device: bond1
vlan_id: {get_param: InternalApiNetworkVlanID}
addresses:
- ip_netmask: {get_param: InternalApiIpSubnet}
- type: vlan
device: bond1
vlan_id: {get_param: StorageNetworkVlanID}
addresses:
- ip_netmask: {get_param: StorageIpSubnet}
- type: vlan
device: bond1
vlan_id: {get_param: StorageMgmtNetworkVlanID}
addresses:
- ip_netmask: {get_param: StorageMgmtIpSubnet}
- type: vlan
device: bond1
vlan_id: {get_param: TenantNetworkVlanID}
addresses:
- ip_netmask: {get_param: TenantIpSubnet}
- type: vlan
device: bond1
vlan_id: {get_param: ManagementNetworkVlanID}
addresses:
- ip_netmask: {get_param: ManagementIpSubnet}网络接口 Heat 模板中的管理网络部分已注释掉。取消注释本节以启用管理网络。
此模板定义网桥（通常是名为 br-ex的外部网桥），并从两个数字的接口创建一个名为 bond1 的绑定接口： nic2 和 nic3。该网桥还包含一些标记的 VLAN 设备，其使用 bond1 作为父设备。该模板还包括连接到 director 的接口(nic1)。
有关网络接口模板的更多示例，请参阅 附录 B, 网络接口模板示例。
请注意，其中很多参数使用 get_param 函数。您可以在您为网络创建的环境文件中定义。
未使用的接口可能会导致不必要的默认路由和网络循环。例如，模板可能包含一个网络接口(nic4)，它不使用 OpenStack 服务的任何 IP 分配，但仍使用 DHCP 和/或默认路由。为了避免网络冲突，请从 ovs_bridge 设备中删除所有未使用的接口，并禁用 DHCP 和默认路由设置：
- type: interface
name: nic4
use_dhcp: false
defroute: false7.2. 创建网络环境文件
网络环境文件是描述 Overcloud 网络环境的 Heat 环境文件，并指向上一节中的网络接口配置模板。您可以为网络定义子网和 VLAN 以及 IP 地址范围。然后您可以为本地环境自定义这些值。
director 包含一组示例环境文件，供您启动。每个环境文件对应于 /usr/share/openstack-tripleo-heat-templates/network/config/ 中的 example 网络接口文件：
-
/usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-NIC 的带有 VLAN 配置的环境文件。用于禁用外部网络(vlans.yaml- 单一net-single-nic-with-vlans-no-external.yaml)的环境文件或启用 IPv6 (net-single-nic-with-vlans-v6.yaml)。 -
/usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml-bond-with-vlans网络接口目录中绑定 NIC 配置的示例环境文件。用于禁用外部网络(net-bond-with-vlans-no-external.yaml)的环境文件或启用 IPv6 (net-bond-with-vlans-v6.yaml)。 -
/usr/share/openstack-tripleo-heat-templates/environments/net-- 多个 NIC 配置的示例环境文件。也提供用于启用 IPv6 的环境文件(multiple-nics.yamlnet-multiple-nics-v6.yaml)。 -
/usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-linux-bridge-with-vlans.yaml- 使用 Linux 网桥而不是 Open vSwitch 配置的单一 NIC 的示例环境文件，它使用single-nic-linux-bridge-vlans网络接口目录。
此场景使用 /usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml 文件的修改版本。将这个文件复制到 stack 用户的 templates 目录中。
$ cp /usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml /home/stack/templates/network-environment.yaml环境文件包含以下修改的部分：
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:
InternalApiNetCidr: 172.16.0.0/24
TenantNetCidr: 172.17.0.0/24
StorageNetCidr: 172.18.0.0/24
StorageMgmtNetCidr: 172.19.0.0/24
ManagementNetCidr: 172.20.0.0/24
ExternalNetCidr: 10.1.1.0/24
InternalApiAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}]
TenantAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}]
StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}]
ManagementAllocationPools: [{'start': '172.20.0.10', 'end': '172.20.0.200'}]
# Leave room for floating IPs in the External allocation pool
ExternalAllocationPools: [{'start': '10.1.1.10', 'end': '10.1.1.50'}]
# Set to the router gateway on the external network
ExternalInterfaceDefaultRoute: 10.1.1.1
# 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"]
InternalApiNetworkVlanID: 201
StorageNetworkVlanID: 202
StorageMgmtNetworkVlanID: 203
TenantNetworkVlanID: 204
ManagementNetworkVlanID: 205
ExternalNetworkVlanID: 100
NeutronExternalNetworkBridge: "''"
# Customize bonding options if required
BondInterfaceOvsOptions:
"bond_mode=balance-slb"
resource_registry 部分包含每个节点的角色的修改链接到自定义网络接口模板的链接。另外，使用以下格式为自定义角色包含到网络接口模板的链接：
-
OS::TripleO::[ROLE]::Net::SoftwareConfig: [FILE]
将 [ROLE] 替换为角色名称，将 [FILE] 替换为网络接口模板位置。
parameter_defaults 部分包含参数列表，它们为每个网络类型定义网络选项。有关这些选项的完整参考，请参阅 附录 A, 网络环境选项。
此场景定义每个网络的选项。所有网络类型都使用单独的 VLAN 和子网，用于将 IP 地址分配到主机和虚拟 IP。在上例中，内部 API 网络的分配池从 172.16.0.10 开始，并继续使用 VLAN 201 的 172.16.0.200。这会造成从 172.16.0.10 开始分配的静态和虚拟 IP，并在您的环境中使用 VLAN 201 时最多生成 172.16.0.200。
External 网络托管 Horizon 控制面板和公共 API。如果将外部网络用于云管理和浮动 IP，请确保有 IP 池空间，用作虚拟机实例的浮动 IP。在本例中，您只有 10.1.1.10 到 10.1.1.50 的 IP 地址分配给外部网络，这会使 IP 地址从 10.1.1.51 中保留下来，并且上面的 IP 地址可用于浮动 IP 地址。或者，将浮动 IP 网络放在单独的 VLAN 上，并在创建后配置 Overcloud 以使用它。
BondInterfaceOvsOptions 选项使用 nic2 和 nic3 为绑定接口提供选项。有关绑定选项的详情请参考 附录 D, 绑定选项。
在创建 Overcloud 后更改网络配置可能会导致配置问题，因为资源的可用性。例如，如果用户在网络隔离模板中更改了网络的子网范围，则重新配置可能会失败，因为子网已经在使用中。
7.3. 将 OpenStack 服务分配给隔离网络
每个 OpenStack 服务都分配到资源 registry 中的默认网络类型。然后，这些服务绑定到网络类型分配的网络中的 IP 地址。尽管 OpenStack 服务划分在这些网络中，但实际的物理网络数量可能与网络环境文件中定义的不同。您可以通过在网络环境文件(/home/stack/templates/network-environment.yaml)中定义新网络映射，将 OpenStack 服务重新分配给不同的网络类型。ServiceNetMap 参数决定用于每个服务的网络类型。
例如，您可以通过修改突出显示的部分将 Storage Management 网络服务分配给 Storage Network：
parameter_defaults:
ServiceNetMap:
SwiftMgmtNetwork: storage # Changed from storage_mgmt
CephClusterNetwork: storage # Changed from storage_mgmt
将这些参数更改为 存储会将这些服务放在存储 网络上，而不是存储管理网络。这意味着您只需要为 Storage 网络定义一组 parameter_defaults，而不是 Storage Management 网络。
director 将自定义 ServiceNetMap 参数定义合并到 ServiceNetMapDefaults 中预定义的默认值列表中，并覆盖默认值。然后，director 返回包括自定义回 ServiceNetMap 在内的完整列表，用于为各种服务配置网络分配。
在 /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml 中的 ServiceNetMapDefaults 参数中找到默认服务的完整列表。
7.4. 选择要部署的网络
对于网络和端口的环境文件中的 resource_registry 部分中的设置不需要更改。如果只需要网络的子集，则可以更改网络列表。
当指定自定义网络和端口时，不要在部署命令行中包含 environments/network-isolation.yaml。相反，指定网络环境文件中的所有网络和端口。
要使用隔离的网络，服务器必须在每个网络上具有 IP 地址。您可以在 Undercloud 中使用 neutron 来管理隔离的网络上的 IP 地址，因此您需要为每个网络启用 neutron 端口创建。您可以覆盖环境文件中的资源 registry。
首先，这是可部署的每个角色的默认网络和端口的完整集合：
resource_registry:
# This section is usually not modified, if in doubt stick to the defaults
# TripleO overcloud networks
OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml
OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml
OS::TripleO::Network::StorageMgmt: /usr/share/openstack-tripleo-heat-templates/network/storage_mgmt.yaml
OS::TripleO::Network::Storage: /usr/share/openstack-tripleo-heat-templates/network/storage.yaml
OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml
OS::TripleO::Network::Management: /usr/share/openstack-tripleo-heat-templates/network/management.yaml
# Port assignments for the VIPs
OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
OS::TripleO::Network::Ports::TenantVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
OS::TripleO::Network::Ports::ManagementVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml
# Port assignments for the controller role
OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
OS::TripleO::Controller::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
# Port assignments for the compute role
OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
OS::TripleO::Compute::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
# Port assignments for the ceph storage role
OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::CephStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
OS::TripleO::CephStorage::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
# Port assignments for the swift storage role
OS::TripleO::SwiftStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::SwiftStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::SwiftStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
OS::TripleO::SwiftStorage::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
# Port assignments for the block storage role
OS::TripleO::BlockStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::BlockStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::BlockStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
OS::TripleO::BlockStorage::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
此文件的第一部分包含 OS::TripleO::Network::* 资源的资源 registry 声明。默认情况下，这些资源使用 OS::Heat::None 资源类型，该类型不创建任何网络。通过将这些资源重定向到每个网络的 YAML 文件，您可以创建这些网络。
接下来的几个部分为各个角色中的节点创建 IP 地址。控制器节点在每个网络上都有 IP。计算和存储节点在网络的子集上都有 IP。
默认文件仅包含默认角色的端口分配。要为自定义角色配置端口分配，请使用与其他资源定义相同的约定，并链接到 network/ports 目录中的相应 Heat 模板：
-
OS::TripleO::[ROLE]::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml -
OS::TripleO::[ROLE]::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml -
OS::TripleO::[ROLE]::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml -
OS::TripleO::[ROLE]::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml -
OS::TripleO::[ROLE]::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml -
OS::TripleO::[ROLE]::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
将 [ROLE] 替换为您的角色的名称。
要在没有预先配置的网络的情况下部署，请为角色禁用网络定义和对应的端口定义。例如，所有对 storage_mgmt.yaml 的引用都可以替换为 OS::Heat::None ：
resource_registry:
# This section is usually not modified, if in doubt stick to the defaults
# TripleO overcloud networks
OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml
OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml
OS::TripleO::Network::StorageMgmt: OS::Heat::None
OS::TripleO::Network::Storage: /usr/share/openstack-tripleo-heat-templates/network/storage.yaml
OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml
# Port assignments for the VIPs
OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::Network::Ports::StorageMgmtVipPort: OS::Heat::None
OS::TripleO::Network::Ports::TenantVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml
# Port assignments for the controller role
OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::Controller::Ports::StorageMgmtPort: OS::Heat::None
OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
# Port assignments for the compute role
OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
# Port assignments for the ceph storage role
OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::CephStorage::Ports::StorageMgmtPort: OS::Heat::None
# Port assignments for the swift storage role
OS::TripleO::SwiftStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::SwiftStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::SwiftStorage::Ports::StorageMgmtPort: OS::Heat::None
# Port assignments for the block storage role
OS::TripleO::BlockStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
OS::TripleO::BlockStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
OS::TripleO::BlockStorage::Ports::StorageMgmtPort: OS::Heat::None
parameter_defaults:
ServiceNetMap:
ApacheNetwork: internal_api
NeutronTenantNetwork: tenant
CeilometerApiNetwork: internal_api
AodhApiNetwork: internal_api
GnocchiApiNetwork: internal_api
MongodbNetwork: internal_api
CinderApiNetwork: internal_api
CinderIscsiNetwork: storage
GlanceApiNetwork: internal_api
GlanceRegistryNetwork: internal_api
IronicApiNetwork: ctlplane
IronicNetwork: ctlplane
KeystoneAdminApiNetwork: ctlplane # allows undercloud to config endpoints
KeystonePublicApiNetwork: internal_api
ManilaApiNetwork: internal_api
NeutronApiNetwork: internal_api
HeatApiNetwork: internal_api
HeatApiCfnNetwork: internal_api
HeatApiCloudwatchNetwork: internal_api
NovaApiNetwork: internal_api
NovaColdMigrationNetwork: ctlplane
NovaMetadataNetwork: internal_api
NovaVncProxyNetwork: internal_api
NovaLibvirtNetwork: internal_api
SwiftStorageNetwork: storage # Changed from storage_mgmt
SwiftProxyNetwork: storage
SaharaApiNetwork: internal_api
HorizonNetwork: internal_api
MemcachedNetwork: internal_api
RabbitmqNetwork: internal_api
RedisNetwork: internal_api
MysqlNetwork: internal_api
CephClusterNetwork: storage # Changed from storage_mgmt
CephMonNetwork: storage
CephRgwNetwork: storage
PublicNetwork: external
OpendaylightApiNetwork: internal_api
CephStorageHostnameResolveNetwork: storage
ControllerHostnameResolveNetwork: internal_api
ComputeHostnameResolveNetwork: internal_api
ObjectStorageHostnameResolveNetwork: internal_api
BlockStorageHostnameResolveNetwork: internal_api
通过使用 OS::Heat::None，不会创建任何网络或端口，因此存储管理网络上的服务将默认为 Provisioning 网络。这可以在 ServiceNetMap 中进行更改，以便将存储管理服务移至另一网络，如存储网络。
第 8 章 控制节点放置
director 的默认行为是为每个角色随机选择节点，通常基于它们的 profile 标签。但是，director 提供了定义特定节点放置的功能。这是对以下情况的非常有用的方法：
-
分配特定的节点 ID，如
controller-0、controller-1等 - 分配自定义主机名
- 分配特定的 IP 地址
- 分配特定的虚拟 IP 地址
为网络手动设置可预测的 IP 地址、虚拟 IP 地址和端口，可减少分配池的需求。但是，建议为每个网络保留分配池，以便更轻松地扩展新节点。确保任何静态定义的 IP 地址不在分配池之外。有关设置分配池的详情请参考 第 7.2 节 “创建网络环境文件”。
8.1. 分配特定的节点 ID
此流程将节点 ID 分配给特定的节点。节点 ID 的示例包括 controller-0、controller-1、compute-0、compute-1 等。
第一步是将 ID 指定为与部署上的 Nova 调度程序匹配的每个节点功能。例如：
openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <id>
这会将 capability node:controller-0 分配给节点。使用唯一连续索引重复此模式，从 0 开始，对所有节点从 0 开始。确保给定角色(Controller、Compute 或每个存储角色)的所有节点都以相同的方式标记，否则 Nova 调度程序将不能正确匹配。
下一步是创建一个 Heat 环境文件（如 scheduler_hints_env.yaml），该文件使用调度程序提示来匹配每个节点的功能。例如：
parameter_defaults:
ControllerSchedulerHints:
'capabilities:node': 'controller-%index%'
要使用这些调度程序提示，请在 Overcloud 创建过程中包括带有 overcloud deploy 命令的 ' scheduler_hints_env.yaml' 环境文件。
通过这些参数，每个角色都可以使用相同的方法：
-
Controller 节点的
ControllerSchedulerHints。 -
Compute 节点的
NovaComputeSchedulerHints。 -
Block Storage 节点的
BlockStorageSchedulerHints。 -
Object Storage 节点的
ObjectStorageSchedulerHints。 -
Ceph Storage 节点的
CephStorageSchedulerHints。 -
[ROLE] 自定义角色的SchedulerHints。将[ROLE]替换为角色名称。
节点放置优先于配置集匹配。为避免调度失败，请使用默认的 baremetal 类别进行部署，而不是为配置文件匹配而设计的类别(计算、控制 等等)。例如：
$ openstack overcloud deploy ... --control-flavor baremetal --compute-flavor baremetal ...8.2. 分配自定义主机名
与 第 8.1 节 “分配特定的节点 ID” 中的节点 ID 配置结合使用，director 也可以为每个节点分配特定的自定义主机名。当您需要定义系统所在的位置（如 rack2-row12）、匹配清单标识符或其他需要自定义主机名的情况时，这非常有用。
要自定义节点主机名，请在环境文件中使用 HostnameMap 参数，如 第 8.1 节 “分配特定的节点 ID” 中的 ' scheduler_hints_env.yaml' 文件。例如：
parameter_defaults:
ControllerSchedulerHints:
'capabilities:node': 'controller-%index%'
NovaComputeSchedulerHints:
'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-compute-0: overcloud-compute-prod-abc-0
在 parameter_defaults 部分中定义 HostnameMap，将每个映射设置为 Heat 使用 HostnameFormat 参数（如 overcloud-controller-0）定义的原始主机名（如 overcloud-controller-prod-123-0），第二个值是该节点所需的自定义主机名（如 overcloud-controller-prod-123-0）。
将此方法与节点 ID 放置结合使用可确保每个节点都有自定义主机名。
8.3. 分配可预测 IP
为了进一步控制生成的环境，director 也可以为每个网络分配具有特定 IP 的 Overcloud 节点。在核心 Heat 模板集合中，使用 environment /ips-from-pool-all.yaml 环境文件。将这个文件复制到 stack 用户的 templates 目录中。
$ cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-all.yaml ~/templates/.
ips-from-pool-all.yaml 文件中有两个主要部分。
第一个是覆盖默认值的一组 resource_registry 引用。它们告知 director 对节点类型上给定端口使用特定 IP。修改每个资源，以使用其对应模板的绝对路径。例如：
OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external_from_pool.yaml
OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api_from_pool.yaml
OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_from_pool.yaml
OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt_from_pool.yaml
OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant_from_pool.yaml
默认配置在所有节点类型上设置所有网络，以使用预分配的 IP。要允许特定网络或节点类型使用默认 IP 分配，只需从环境文件中删除与该节点类型或网络相关的 resource_registry 条目。
第二部分是 parameter_defaults，其中分配了实际的 IP 地址。每个节点类型都有一个关联的参数：
-
Controller 节点的ControllerIP。 -
Compute 节点的
NovaComputeIPs。 -
Ceph Storage 节点的
CephStorageIPs。 -
BlockStorageIPs用于块存储节点。 -
Object
Storage 节点的 SwiftStorageIP。 -
[ROLE]IPs用于自定义角色。将[ROLE]替换为角色名称。
每个参数都是网络名称到地址列表的映射。每个网络类型必须至少具有任意数量的地址，因为该网络上有节点。director 按顺序分配地址。每种类型的第一个节点在每个对应列表上接收第一个地址，第二个节点在各个对应的列表中接收第二个地址，以此类推。
例如，如果 Overcloud 将包含三个 Ceph Storage 节点，CephStorageIPs 参数可能类似如下：
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。相同的模式适用于其他节点类型。
确保所选 IP 地址不在网络环境文件中定义的每个网络的分配池之外（请参阅 第 7.2 节 “创建网络环境文件”）。例如，确保 internal_api 分配不在 InternalApiAllocationPools 范围之外。这可避免与自动选择的任何 IP 冲突。同样，请确保 IP 分配与 VIP 配置没有冲突，对于标准的可预测的 VIP 放置（请参阅 第 8.4 节 “分配可预测虚拟 IP”）或外部负载均衡（请参阅 第 14.1 节 “配置外部负载平衡”）。
如果删除了 overcloud 节点，请不要删除 IP 列表中的条目。IP 列表基于底层 Heat 索引，即使删除节点也不会改变。要在列表中指定给定条目已不再使用，请将 IP 值替换为值，如 DELETED 或 UNUSED。不应从 IP 列表中删除条目，只更改或添加条目。
要在部署期间应用此配置，请使用 openstack overcloud deploy 命令包含 ips-from-pool-all.yaml 环境文件。
如果使用网络隔离（请参阅 第 7 章 隔离网络），在 network-isolation.yaml 文件后包含 ips-from-pool-all.yaml 文件。
例如：
$ openstack overcloud deploy --templates \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e ~/templates/ips-from-pool-all.yaml \
[OTHER OPTIONS]8.4. 分配可预测虚拟 IP
除了为每个节点定义可预测的 IP 地址外，director 还提供了为集群服务定义可预测的虚拟 IP (VIP)的功能。要达到此目的，请从 第 7.2 节 “创建网络环境文件” 编辑网络环境文件，并在 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'}]
从对应的分配池范围之外选择这些 IP。例如，为不在 InternalApiAllocationPools 范围内的 InternalApiVirtualFixedIPs 选择一个 IP 地址。
此步骤仅适用于使用默认内部负载平衡配置的 overcloud。如果使用外部负载均衡器分配 VIP，请使用 Overcloud 专用外部负载平衡 中的步骤。
第 9 章 在 Overcloud 中启用 SSL/TLS
默认情况下，overcloud 使用未加密的端点作为其服务。这意味着 overcloud 配置需要额外的环境文件，才能为其公共 API 端点启用 SSL/TLS。下面的章节演示了如何配置 SSL/TLS 证书，并将其作为 overcloud 创建的一部分包含在内。
这个过程只为公共 API 端点启用 SSL/TLS。Internal 和 Admin API 会保持未加密的状态。
此过程需要网络隔离来定义公共 API 的端点。有关网络隔离的说明，请参阅 第 7 章 隔离网络。
9.1. 初始化签名主机
签名主机是生成新证书并使用证书颁发机构签名的主机。如果您从未在所选签名主机上创建 SSL 证书，您可能需要初始化该主机，让它能够为新证书签名。
/etc/pki/CA/index.txt 文件存储所有签名证书的记录。检查是否存在此文件。如果不存在，请创建一个空文件：
$ sudo touch /etc/pki/CA/index.txt
/etc/pki/CA/serial 文件标识下一个序列号，以用于下一个要签名的证书。检查是否存在此文件。如果不存在，请使用新起始值创建新文件：
$ echo '1000' | sudo tee /etc/pki/CA/serial9.2. 创建证书颁发机构
一般情况下，您需要使用一个外部的证书认证机构来签发您的 SSL/TLS 证书。在某些情况下，您可能打算使用自己的证书颁发机构。例如，您可能有一个仅限内部的证书颁发机构。
例如，生成要充当证书颁发机构的密钥和证书对：
$ openssl genrsa -out ca.key.pem 4096
$ openssl req -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
openssl req 命令会要求输入认证机构的详细信息。输入这些详情。
这会创建一个名为 ca.crt.pem 的证书颁发机构文件。
9.3. 将证书颁发机构添加到客户端
对于旨在使用 SSL/TLS 通信的任何外部客户端，将证书颁发机构文件复制到需要访问 Red Hat OpenStack Platform 环境的每个客户端。复制到客户端后，在客户端上运行以下命令将其添加到证书颁发机构信任捆绑包中：
$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
$ sudo update-ca-trust extract例如，undercloud 需要证书颁发机构文件的副本，以便它可以在创建 overcloud 端点期间与 overcloud 端点通信。
9.4. 创建 SSL/TLS 密钥
运行以下命令生成 SSL/TLS 密钥(server.key.pem)，我们使用不同的点生成 undercloud 或 overcloud 证书：
$ openssl genrsa -out server.key.pem 20489.5. 创建 SSL/TLS 证书签名请求
下一步为 overcloud 创建证书签名请求。复制默认 OpenSSL 配置文件以进行自定义。
$ cp /etc/pki/tls/openssl.cnf .
编辑自定义 openssl.cnf 文件并设置用于 overcloud 的 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 = 10.0.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 = 10.0.0.1
DNS.1 = 10.0.0.1
DNS.2 = myovercloud.example.com
将 commonName_default 设置为以下之一：
-
如果使用 IP 通过 SSL/TLS 访问，请使用公共 API 的虚拟 IP。使用环境文件中的
PublicVirtualFixedIPs参数设置这个 VIP。更多信息请参阅 第 8.4 节 “分配可预测虚拟 IP”。如果您不使用可预测的 VIP，director 会从ExternalAllocationPools参数中定义的范围分配第一个 IP 地址。 - 如果使用完全限定域名通过 SSL/TLS 访问，请使用域名。
在 alt_names 部分中包括与 IP 条目和 DNS 条目相同的公共 API IP 地址。如果也使用 DNS，请在同一部分中将服务器的主机名作为 DNS 条目包含在内。有关 openssl.cnf 的更多信息，请运行 man openssl.cnf。
运行以下命令以生成证书签名请求(server.csr.pem)：
$ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem
确保在 第 9.4 节 “创建 SSL/TLS 密钥” 中为 -key 选项包含您创建的 SSL/TLS 密钥。
使用 server.csr.pem 文件在下一部分中创建 SSL/TLS 证书。
9.6. 创建 SSL/TLS 证书
以下命令为 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这个命令使用：
-
指定 v3 扩展的配置文件。将此选项作为
-config选项包含在内。 -
来自 第 9.5 节 “创建 SSL/TLS 证书签名请求” 的证书签名请求，以生成证书并通过证书颁发机构签名。将此选项作为
-in选项包含在内。 -
您在 第 9.2 节 “创建证书颁发机构” 中创建的证书颁发机构，它为证书签名。将此选项包含为
-cert选项。 -
您在 第 9.2 节 “创建证书颁发机构” 中创建的证书颁发机构私钥。将此选项作为
-keyfile选项包含在内。
这会生成一个名为 server.crt.pem 的证书。将此证书与来自 第 9.4 节 “创建 SSL/TLS 密钥” 的 SSL/TLS 密钥一起使用以启用 SSL/TLS。
9.7. 启用 SSL/TLS
从 Heat 模板集合中复制 enable-tls.yaml 环境文件：
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/enable-tls.yaml ~/templates/.编辑这个文件并为这些参数进行以下更改：
- SSLCertificate
将证书文件(
server.crt.pem)的内容复制到SSLCertificate参数中。例如：parameter_defaults: SSLCertificate: | -----BEGIN CERTIFICATE----- MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV ... sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp -----END CERTIFICATE-----重要证书内容为所有新行需要相同的缩进级别。
- SSLKey
将私钥(
server.key.pem)的内容复制到SSLKey参数中。例如：parameter_defaults: ... SSLKey: | -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO9hkJZnGP6qb6wtYUoy1bVP7 ... ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4XpZUC7yhqPaU -----END RSA PRIVATE KEY-----重要私钥内容为所有新行需要相同的缩进级别。
- OS::TripleO::NodeTLSData
将
OS::TripleO::NodeTLSData:的资源路径改为绝对路径：resource_registry: OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml
9.8. 注入 Root 证书
如果证书签名人不在 overcloud 镜像的默认信任存储中，您必须将证书颁发机构注入 overcloud 镜像。从 heat 模板集合中复制 inject-trust-anchor.yaml 环境文件：
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/inject-trust-anchor.yaml ~/templates/.编辑这个文件并为这些参数进行以下更改：
- SSLRootCertificate
将 root 证书颁发机构文件(
ca.crt.pem)的内容复制到SSLRootCertificate参数。例如：parameter_defaults: SSLRootCertificate: | -----BEGIN CERTIFICATE----- MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV ... sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp -----END CERTIFICATE-----重要证书颁发机构内容为所有新行需要相同的缩进级别。
- OS::TripleO::NodeTLSCAData
将
OS::TripleO::NodeTLSCAData 的资源路径改为绝对路径：resource_registry: OS::TripleO::NodeTLSCAData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/ca-inject.yaml
9.9. 配置 DNS 端点
如果使用 DNS 主机名通过 SSL/TLS 访问 overcloud，请创建一个新的环境文件(~/templates/cloudname.yaml)来定义 overcloud 端点的主机名。使用以下参数：
- CloudName
- overcloud 端点的 DNS 主机名。
- DnsServers
-
要使用的 DNS 服务器列表。配置的 DNS 服务器必须包含配置的
CloudName的条目，该条目与公共 API 的 IP 地址匹配。
此文件的内容示例：
parameter_defaults:
CloudName: overcloud.example.com
DnsServers: ["10.0.0.254"]9.10. 在 Overcloud 创建过程中添加环境文件
部署命令(openstack overcloud deploy)使用 -e 选项添加环境文件。按照以下顺序添加本节中的环境文件：
-
启用 SSL/TLS 的环境文件(
enable-tls.yaml) -
用于设置 DNS 主机名(
cloudname.yaml)的环境文件 -
用于注入根证书颁发机构的环境文件(
inject-trust-anchor.yaml) 设置公共端点映射的环境文件：
-
如果使用 DNS 名称访问公共端点，请使用
/usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-dns.yaml -
如果使用 IP 地址访问公共端点，请使用
/usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-ip.yaml
-
如果使用 DNS 名称访问公共端点，请使用
例如：
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-dns.yaml9.11. 更新 SSL/TLS 证书
如果您需要在以后更新证书：
-
编辑
enable-tls.yaml文件并更新SSLCertificate、SSLKey和SSLIntermediateCertificate参数。 -
如果您的证书颁发机构已更改，请编辑
inject-trust-anchor.yaml文件并更新SSLRootCertificate参数。
新证书内容就位后，重新运行部署命令。例如：
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-dns.yaml第 10 章 存储配置
本章概述了为 Overcloud 配置存储选项的几种方法。
Overcloud 将本地和 LVM 存储用于默认存储选项。但是，企业级 Overcloud 不支持这些选项。建议您在本章中使用其中一个存储选项。
10.1. 配置 NFS 存储
本节介绍将 Overcloud 配置为使用 NFS 共享。安装和配置流程基于修改核心 Heat 模板集合中的现有环境文件。
核心 heat 模板集合包含 /usr/share/openstack-tripleo-heat-templates/environments/ 中的一组环境文件。这些环境模板有助于自定义配置 director 创建的 Overcloud 中一些支持的功能。这包括帮助配置存储的环境文件。此文件位于 /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml。将此文件复制到 stack 用户的模板目录。
$ cp /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml ~/templates/.环境文件包含一些参数，可帮助为 OpenStack 的块存储和镜像存储组件 cinder 和 glance 配置不同的存储选项。在本例中，您要将 Overcloud 配置为使用 NFS 共享。修改以下参数：
- CinderEnableIscsiBackend
-
启用 iSCSI 后端。设置为
false。 - CinderEnableRbdBackend
-
启用 Ceph 存储后端。设置为
false。 - CinderEnableNfsBackend
-
启用 NFS 后端。设置为
true。 - NovaEnableRbdBackend
-
为 Nova 临时存储启用 Ceph Storage。设置为
false。 - GlanceBackend
-
定义用于 Glance 的后端。设置为
file，以将基于文件的存储用于镜像。Overcloud 会将这些文件保存到 Glance 的挂载的 NFS 共享中。 - CinderNfsMountOptions
- 卷存储的 NFS 挂载选项。
- CinderNfsServers
- 为卷存储挂载的 NFS 共享。例如： 192.168.122.1:/export/cinder。
- GlanceNfsEnabled
-
启用 Pacemaker 管理镜像存储的共享。如果禁用，Overcloud 会将镜像存储在 Controller 节点的文件系统中。设置为
true。 - GlanceNfsShare
- 为镜像存储挂载的 NFS 共享。例如： 192.168.122.1:/export/glance。
- GlanceNfsOptions
- 镜像存储的 NFS 挂载选项。
环境文件的选项应类似于如下：
parameter_defaults:
CinderEnableIscsiBackend: false
CinderEnableRbdBackend: false
CinderEnableNfsBackend: true
NovaEnableRbdBackend: false
GlanceBackend: 'file'
CinderNfsMountOptions: 'rw,sync'
CinderNfsServers: '192.0.2.230:/cinder'
GlanceNfsEnabled: true
GlanceNfsShare: '192.0.2.230:/glance'
GlanceNfsOptions: 'rw,sync,context=system_u:object_r:glance_var_lib_t:s0'
在 GlanceNfsOptions 参数中包含 context=system_u:object_r:glance_var_lib_t:s0，以允许 glance 访问 /var/lib 目录。如果没有此 SELinux 内容，glance 将无法写入到挂载点。
这些参数作为 heat 模板集合的一部分进行集成。设置它们，如为 cinder 和 glance 创建两个 NFS 挂载点。
保存此文件，以包含在 Overcloud 中创建中。
10.2. 配置 Ceph 存储
director 提供两种主要方法，用于将 Red Hat Ceph Storage 集成到 Overcloud 中。
- 使用自己的 Ceph Storage 集群创建 Overcloud
- director 可以在 Overcloud 上创建 Ceph Storage 集群期间创建 Ceph 存储集群。director 创建一组 Ceph Storage 节点，它们使用 Ceph OSD 存储数据。此外，director 在 Overcloud 的 Controller 节点上安装 Ceph Monitor 服务。这意味着，如果组织创建具有三个高可用性控制器节点的 Overcloud，Ceph 监控器也会变为高度可用的服务。
- 将现有 Ceph 存储集成到 Overcloud 中
- 如果您已经有一个现有的 Ceph Storage 集群，可以在 Overcloud 部署期间集成此集群。这意味着您可以在 Overcloud 配置之外管理和扩展集群。
有关配置 Overcloud Ceph Storage 的更多信息，请参阅 Overcloud 的专用 Red Hat Ceph Storage 指南， 以了解这两种场景的完整说明。
10.3. 配置第三方存储
director 包括几个环境文件，以帮助配置第三方存储供应商。这包括：
- 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 块存储
将 NetApp 存储设备部署为 Block Storage (cinder)服务的后端。
环境文件位于
/usr/share/openstack-tripleo-heat-templates/environments/cinder-netapp-config.yaml。有关完整配置信息，请参阅 NetApp Block Storage 后端指南。
第 11 章 配置容器化计算节点
director 提供了将 OpenStack 容器化项目(kolla)中的服务集成到 Overcloud 的 Compute 节点的选项。这包括创建使用 Red Hat Enterprise Linux Atomic Host 作为基础操作系统和单个容器来运行不同的 OpenStack 服务的计算节点。
容器化 Compute 节点是一个技术预览功能。技术预览功能不完全支持在红帽订阅服务级别协议(SLA)中，其功能可能并不完善，且不适用于生产环境。但是，这些功能可让您早期访问即将推出的产品创新，使客户能够在开发过程中测试并提供反馈意见。有关技术预览功能的支持范围的更多信息，请参阅 https://access.redhat.com/support/offerings/techpreview/。
director 的核心 Heat 模板集合包括环境文件，用于帮助配置容器化 Compute 节点。这些文件包括：
-
docker.yaml- 配置容器化 Compute 节点的主要环境文件。 -
docker-network.yaml- 容器化 Compute 节点网络的环境文件，而不进行网络隔离。 -
docker-network-isolation.yaml- 使用网络隔离容器化 Compute 节点的环境文件。
11.1. 增加 Stack Depth
为了容纳容器化计算 Heat 模板中的资源堆栈数量，您应该增加 undercloud 上 OpenStack Orchestration (heat)的堆栈深度。使用以下步骤增加堆栈深度：
编辑
/etc/heat/heat.conf并搜索max_nested_stack_depth参数。将此参数的值增加到10：max_nested_stack_depth = 10保存这个文件。
重启 OpenStack Orchestration (heat)服务：
sudo systemctl restart openstack-heat-engine.service
undercloud 次版本和主版本更新可以恢复对 /etc/heat/heat.conf 文件的更改。如有必要，设置 heat::engine::max_nested_stack_depth hieradata，以确保堆栈深度是永久的。要设置 undercloud hieradata，请将 undercloud.conf 文件中的 hieradata_override 参数指向含有自定义 hieradata 的文件。
11.2. 检查容器化 Compute 环境文件(docker.yaml)
docker.yaml 文件是容器化 Compute 节点配置的主要环境文件。它包括 resource_registry 中的条目：
resource_registry:
OS::TripleO::ComputePostDeployment: ../docker/compute-post.yaml
OS::TripleO::NodeUserData: ../docker/firstboot/install_docker_agents.yaml- OS::TripleO::NodeUserData
-
提供在第一次引导时使用自定义配置的 Heat 模板。在这种情况下，它会在计算节点第一次引导时在 Compute 节点上安装
openstack-heat-docker-agents容器。此容器提供了一组初始化脚本，用于配置容器化 Compute 节点和 Heat hook 与 director 通信。 - OS::TripleO::ComputePostDeployment
提供一个 Heat 模板，其中包含 Compute 节点的一组后配置资源。这包括为 Puppet 提供一组标签的
软件配置资源：ComputePuppetConfig: type: OS::Heat::SoftwareConfig properties: group: puppet options: enable_hiera: True enable_facter: False tags: package,file,concat,file_line,nova_config,neutron_config,neutron_agent_ovs,neutron_plugin_ml2 inputs: - name: tripleo::packages::enable_install type: Boolean default: True outputs: - name: result config: get_file: ../puppet/manifests/overcloud_compute.pp这些标签定义要传递给
openstack-heat-docker-agents容器的 Puppet 模块。
docker.yaml 文件包含一个名为 NovaImage 的参数，它将在置备 Compute 节点时将标准的 overcloud-full 镜像替换为其他镜像(atomic-image)。有关上传此新镜像的步骤，请参阅 第 11.3 节 “上传 Atomic 主机镜像”。
docker.yaml 文件还包含 parameter_defaults 部分，用于定义用于我们的 Compute 节点服务的 Docker registry 和镜像。您可以修改本节以使用本地 registry 而不是默认的 registry.access.redhat.com。有关配置本地 registry 的说明，请参阅 第 11.4 节 “使用本地 Registry”。
11.3. 上传 Atomic 主机镜像
director 需要 Red Hat Enterprise Linux 7 Atomic Host 的 Cloud Image 的副本作为 atomic-image 导入到其镜像中。这是因为在创建 Overcloud 的置备阶段，Compute 节点需要此镜像用于基础操作系统。
从 Red Hat Enterprise Linux 7 Atomic Host 产品页面(https://access.redhat.com/downloads/content/271/ver=/rhel---7/7.2.2-2/x86_64/product-software)下载云镜像的副本，并将其保存到 stack 用户的主目录中的 images 子目录。
镜像下载完成后，以 stack 用户身份将镜像导入到 director。
$ glance image-create --name atomic-image --file ~/images/rhel-atomic-cloud-7.2-12.x86_64.qcow2 --disk-format qcow2 --container-format bare这会将镜像与其他 Overcloud 镜像一起导入。
$ glance image-list
+--------------------------------------+------------------------+
| ID | Name |
+--------------------------------------+------------------------+
| 27b5bad7-f8b2-4dd8-9f69-32dfe84644cf | atomic-image |
| 08c116c6-8913-427b-b5b0-b55c18a01888 | bm-deploy-kernel |
| aec4c104-0146-437b-a10b-8ebc351067b9 | bm-deploy-ramdisk |
| 9012ce83-4c63-4cd7-a976-0c972be747cd | overcloud-full |
| 376e95df-c1c1-4f2a-b5f3-93f639eb9972 | overcloud-full-initrd |
| 0b5773eb-4c64-4086-9298-7f28606b68af | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+11.4. 使用本地 Registry
默认配置使用红帽的容器 registry 进行镜像下载。但是，作为可选步骤，您可以在 Overcloud 创建过程中使用本地 registry 来节省带宽。
您可以使用现有本地 registry 或安装一个新 registry。要安装新 registry，请使用 容器 开始使用 Docker 格式容器镜像" 入门 "中的说明。
将所需的镜像拉取到 registry 中：
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-nova-compute:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-data:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-nova-libvirt:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-neutron-openvswitch-agent:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-openvswitch-vswitchd:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-openvswitch-db-server:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-heat-docker-agents:latest拉取镜像后，使用正确的 registry 主机标记它们：
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-nova-compute:latest localhost:8787/registry.access.redhat.com/openstack-nova-compute:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-data:latest localhost:8787/registry.access.redhat.com/openstack-data:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-nova-libvirt:latest localhost:8787/registry.access.redhat.com/openstack-nova-libvirt:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-neutron-openvswitch-agent:latest localhost:8787/registry.access.redhat.com/openstack-neutron-openvswitch-agent:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-openvswitch-vswitchd:latest localhost:8787/registry.access.redhat.com/openstack-openvswitch-vswitchd:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-openvswitch-db-server:latest localhost:8787/registry.access.redhat.com/openstack-openvswitch-db-server:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-heat-docker-agents:latest localhost:8787/registry.access.redhat.com/openstack-heat-docker-agents:latest将其推送到 registry：
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-nova-compute:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-data:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-nova-libvirt:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-neutron-openvswitch-agent:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-openvswitch-vswitchd:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-openvswitch-db-server:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-heat-docker-agents:latest
在 templates 子目录中创建主 docker.yaml 环境文件的副本：
$ cp /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml ~/templates/.
编辑该文件并修改 resource_registry 以使用绝对路径：
resource_registry:
OS::TripleO::ComputePostDeployment: /usr/share/openstack-tripleo-heat-templates/docker/compute-post.yaml
OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/docker/firstboot/install_docker_agents.yaml
将 parameter_defaults 中的 DockerNamespace 设置为 registry URL。另外，将 DockerNamespaceIsRegistry 设置为 true，例如：
parameter_defaults:
DockerNamespace: registry.example.com:8787/registry.access.redhat.com
DockerNamespaceIsRegistry: true现在，您的本地 registry 具有所需的 docker 镜像，容器化 Compute 配置现已设置为使用该 registry。
11.5. 在 Overcloud 部署中包括环境文件
在运行 Overcloud 创建时，请包括容器化 Compute 节点以及 openstack overcloud deploy 命令的主要环境文件(docker.yaml)和网络环境文件(docker-network.yaml)。例如：
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-network.yaml [OTHER OPTIONS] ...
容器化 Compute 节点在 Overcloud 中也具有网络隔离功能。这还需要主环境文件以及网络隔离文件(docker-network-isolation.yaml)。在网络隔离文件 第 7 章 隔离网络 之前添加这些文件。例如：
openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml [OTHER OPTIONS] ...director 会创建一个带有容器化 Compute 节点的 Overcloud。
第 12 章 监控工具配置
监控工具是一个可选的工具套件，旨在帮助操作员维护 OpenStack 环境。这些工具执行以下功能：
- 集中式日志记录：允许您在一个中央位置从 OpenStack 环境中所有组件收集日志。您可以识别所有节点和服务的问题，也可以选择性地将日志数据导出到红帽，以帮助诊断问题。
- 可用性监控：允许您监控 OpenStack 环境中的所有组件，并确定任何组件当前遇到中断或无法正常工作。您还可以在出现问题以优化响应时间时收到通知。
12.1. 架构
监控工具使用客户端-服务器模型，以及部署到 Red Hat OpenStack Platform overcloud 节点上的客户端。Fluentd 服务提供客户端集中式日志记录(CL)和 Sensu 客户端服务，提供客户端可用性监控(AM)。
12.1.1. 集中式日志记录
通过集中式日志记录，您可以有一个集中记录来查看整个 OpenStack 环境之间的日志。这些日志来自操作系统，如 syslog 和 audit 日志文件、RabbitMQ 和 MariaDB 等基础架构组件，以及身份、计算等 OpenStack 服务。
集中式日志记录工具链由多个组件组成，包括：
- 日志集合代理(Fluentd)
- log Relay/Transformer (Fluentd)
- 数据存储(Elasticsearch)
- API/高级层(Kibana)
director 不部署用于集中日志记录的服务器端组件。红帽不支持服务器端组件，包括 Elasticsearch 数据库、Kibana 和 Fluentd，它们带有作为日志聚合器运行的插件。
中央日志记录组件及其交互在下图中布局：
blue 中显示的项目表示红帽支持的组件。
图 12.1. 处于高级别的集中式日志记录架构
图 12.2. Red Hat OpenStack Platform 的单节点部署
图 12.3. Red Hat OpenStack Platform 的 HA 部署
12.1.2. 可用性监控
通过可用性监控，您可以有一个中央位置监控整个 OpenStack 环境中所有组件的高级别功能。
可用性监控工具链由多个组件组成，包括：
- 监控代理(Sensu 客户端)
- 监控中继/Proxy (RabbitMQ)
- 监控控制器/服务器(Sensu 服务器)
- API/高级层(Uchiwa)
director 不会为可用性监控部署服务器端组件。红帽不支持服务器端组件，包括 Uchiwa、Sensu Server、Sensu API 和 RabbitMQ，以及在监控节点上运行的 Redis 实例。
下方图中提供了可用性监控组件及其交互：
blue 中显示的项目表示红帽支持的组件。
图 12.4. 在高级别上的可用性监控架构
图 12.5. Red Hat OpenStack Platform 的单节点部署
图 12.6. Red Hat OpenStack Platform 的 HA 部署
12.2. 安装客户端工具
在 overcloud 部署之前，您需要确定应用到每个客户端的配置设置。复制 director 的 Heat 模板集合中的示例环境文件，并将其修改为适合您的环境。
12.2.1. 设置集中式日志记录客户端参数
对于 Fluentd 配置设置，复制 /usr/share/openstack-tripleo-heat-templates/environments/logging-environment.yaml，并修改该文件以适合您的环境。例如：
简单配置
resource_registry:
OS::TripleO::Services::FluentdClient: ../puppet/services/logging/fluentd-client.yaml
parameter_defaults:
LoggingServers:
- host: log0.example.com
port: 24224
- host: log1.example.com
port: 24224SSL 配置示例
## (note the use of port 24284 for ssl connections)
resource_registry:
OS::TripleO::Services::FluentdClient: ../puppet/services/logging/fluentd-client.yaml
parameter_defaults:
LoggingServers:
- host: 192.0.2.11
port: 24284
LoggingUsesSSL: true
LoggingSharedKey: secret
LoggingSSLCertificate: |
-----BEGIN CERTIFICATE-----
...certificate data here...
-----END CERTIFICATE------
LoggingServers- 将接收 Fluentd 日志消息的目标系统。 -
LoggingUsesSSL- 决定在转发日志消息时使用secure_forward的设置。 -
LoggingSharedKey-secure_forward使用的共享 secret。 -
LoggingSSLCertificate- SSL CA 证书的 PEM 编码内容。
12.2.2. 设置可用性监控客户端参数
对于 Sensu 客户端配置设置，复制 /usr/share/openstack-tripleo-heat-templates/environments/monitoring-environment.yaml，修改该文件以适合您的环境。例如：
resource_registry:
OS::TripleO::Services::SensuClient: ../puppet/services/monitoring/sensu-client.yaml
parameter_defaults:
MonitoringRabbitHost: 10.10.10.10
MonitoringRabbitPort: 5672
MonitoringRabbitUserName: sensu
MonitoringRabbitPassword: sensu
MonitoringRabbitUseSSL: false
MonitoringRabbitVhost: "/sensu"
SensuClientCustomConfig:
api:
warning: 10
critical: 20-
MonitoringRabbit*- 这些参数将 Sensu 客户端服务连接到监控服务器上运行的 RabbitMQ 实例。 -
MonitoringRabbitUseSSL- 此参数目前不适用于可用性监控。 -
SensuClientCustomConfig- Specify additional Sensu client configuration.定义要使用的 OpenStack 凭据，包括用户名/密码、auth_url、租户和地区。
12.2.3. 在 Overcloud 节点上安装操作工具
使用 openstack overcloud deploy 命令包括修改后的 YAML 文件，以便在所有 overcloud 节点上安装 Sensu 客户端和 Fluentd 工具。例如：
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e network-environment.yaml -e ~/templates/monitoring-environment.yaml -e ~/templates/logging-environment.yaml --control-scale 3 --compute-scale 1 --ntp-server 192.168.122.1012.3. 安装 Server-Side 组件
红帽不支持服务器端组件及其部署过程。
您可以使用 opstools-ansible playbook 将服务器端组件安装到 Red Hat Enterprise Linux 7 中。这些服务器端组件包括可用性监控和集中式日志记录服务，它们补充红帽支持的客户端侧组件。最测试的 opstools-ansible 场景是将服务器端组件部署到 CentOS 7。具体步骤可在 README.md:https://github.com/centos-opstools/opstools-ansible
12.4. 监控 OpenStack Platform
有关 Sensu 堆栈基础架构的详情，请查看 Sensu 文档： https://sensuapp.org/docs/latest/overview/architecture.html
红帽在 osops-tools-monitoring-oschecks 软件包中提供了一组检查脚本。大多数检查脚本只检查与 OpenStack 组件的 API 连接。但是，某些脚本还为 OpenStack Compute (nova)、OpenStack Block Storage (cinder)、OpenStack Image (glance)和 OpenStack Networking (neutron)执行额外的 OpenStack 资源管理。例如，OpenStack Identity (keystone) API 检查在 keystone 运行时给出以下结果：
OK: Got a token, Keystone API is working.12.5. 验证 Sensu 客户端安装
检查每个 overcloud 节点上的
sensu-client的状态：# systemctl status sensu-client-
检查任何问题的错误日志：
/var/log/sensu/sensu-client.log -
验证每个 overcloud 节点具有
/etc/sensu/conf.d/rabbitmq.json文件，该文件用于设置监控服务器的 IP 地址。
12.6. 检查节点的状态
如果您部署了 Uchiwa 仪表板，您可以将其与 Sensu 服务器一起使用，以检查节点的状态：
登录 Uchiwa 仪表板，再单击
Data Center选项卡以确认数据中心是否正常运行。http://<SERVER_IP_ADDRESS>/uchiwa-
检查所有 overcloud 节点都处于
Connected状态。 - 在合适的时间，重启其中一个 overcloud 节点，并在 Uchiwa 仪表板中检查重新引导的节点状态。重启完成后，验证节点是否成功重新连接到 Sensu 服务器，并开始执行检查。
12.7. 检查 OpenStack 服务的状态
本例测试 openstack-ceilometer-central 服务的监控。
确认
openstack-ceilometer-central服务正在运行：systemctl status openstack-ceilometer-central.service-
连接到 Uchiwa 控制面板，并确认
ceilometerJSON 文件中存在并运行成功ceilometer检查。 停止
openstack-ceilometer-central服务。注意这可能会破坏服务，因此请在适当的时间运行此测试。
systemctl stop openstack-ceilometer-central.service-
登录 Uchiwa 控制面板，并确认报告失败的
ceilometer检查。 启动
openstack-ceilometer-central服务：systemctl start openstack-ceilometer-central.service-
登录 Uchiwa 仪表板，并查看
ceilometer检查报告之间的时间间隔，以确认检查的时间间隔在ceilometerJSON 文件中定义的时间间隔内运行。
第 13 章 安全增强
以下小节提供了强化 overcloud 安全性的建议。
13.1. 管理 Overcloud 防火墙
OpenStack Platform 核心服务各自包含防火墙规则，它们对应的可组合服务模板。这会自动为每个 overcloud 节点创建一组默认的防火墙规则。
overcloud Heat 模板包含一组参数，以帮助进行额外的防火墙管理：
- ManageFirewall
-
定义是否自动管理防火墙规则。设置为
true，以允许 Puppet 在每个节点上自动配置防火墙。如果要手动管理防火墙，则设置为false。默认值是true。 - PurgeFirewallRules
-
定义在配置新之前是否清除默认的 Linux 防火墙规则。默认值为
false。
如果 ManageFirewall 设为 true，您可以在部署时创建额外的防火墙规则。使用 overcloud 的环境文件中的配置 hook （请参阅 第 4.5 节 “Puppet：为角色自定义 Hieradata”）设置 tripleo::firewall::firewall_rules hieradata。这个 hieradata 是一个哈希值，其中包含防火墙规则名称，它们对应的参数作为键，所有这些参数都是可选的：
- port
- 与规则关联的端口。
- dport
- 与规则关联的目的地端口。
- 重要信息
- 与规则关联的源端口。
- Proto
-
与规则关联的协议。默认为
tcp。 - action
-
与规则关联的操作策略。默认为
accept。 - jump
-
要跳到的链。如果存在，它将覆盖
操作。 - 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 文件中定义的所有规则。默认的 OpenStack Platform 规则使用 000 到 200 范围的前缀。
13.2. 更改简单网络管理协议(SNMP)字符串
director 为您的 overcloud 提供默认的只读 SNMP 配置。建议您更改 SNMP 字符串，以减少未授权用户了解您的网络设备的风险。
在 overcloud 的环境文件中使用 ExtraConfig hook 设置以下 hieradata：
- snmp::ro_community
-
IPv4 只读 SNMP 社区字符串.默认值为
public。 - snmp::ro_community6
-
IPv6 只读 SNMP 社区字符串.默认值为
public。 - snmp::ro_network
-
允许
查询守护进程的网络。这个值可以是字符串或数组。默认值为127.0.0.1。 - snmp::ro_network6
-
允许通过 IPv
6 查询守护进程的网络。这个值可以是字符串或数组。默认值为::1/128。 - snmp::snmpd_config
-
要添加到 snmpd.conf 文件中的行数组，作为安全 valve。默认值为
[]。有关所有可用选项，请参阅 SNMP Configuration File 网页。
例如：
parameter_defaults:
ExtraConfig:
snmp::ro_community: mysecurestring
snmp::ro_community6: myv6securestring这会更改所有节点上的只读 SNMP 社区字符串。
13.3. 更改 HAProxy 的 SSL/TLS Cipher 和 Rules
如果您在 overcloud 中启用了 SSL/TLS （请参阅 第 9 章 在 Overcloud 中启用 SSL/TLS），您可能需要强化与 HAProxy 配置一起使用的 SSL/TLS 密码和规则。这有助于避免 SSL/TLS 漏洞，如 POODLE 漏洞。
在 overcloud 的环境文件中使用 ExtraConfig hook 设置以下 hieradata：
- tripleo::haproxy::ssl_cipher_suite
- HAProxy 中使用的密码套件。
- tripleo::haproxy::ssl_options
- HAProxy 中使用的 SSL/TLS 规则。
例如，您可能需要使用下列密码和规则：
-
密码：
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS -
规则：
no-sslv3 no-tls-tickets
使用以下内容创建环境文件：
parameter_defaults:
ExtraConfig:
tripleo::haproxy::ssl_cipher_suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
tripleo::haproxy::ssl_options: no-sslv3 no-tls-ticketscipher 集合是一个连续行。
在您的 overcloud 创建中包含此环境文件。
第 14 章 其他配置
14.1. 配置外部负载平衡
Overcloud 将多个控制器用作高可用性集群，这样可确保 OpenStack 服务的最大操作性能。另外，集群提供了对 OpenStack 服务的访问的负载均衡，这会均匀将流量分发到 Controller 节点，并减少每个节点的服务器超载。也可以使用外部负载均衡器来执行此分发。例如，一个机构可能使用自己的基于硬件的负载均衡器来处理到 Controller 节点的流量分布。
有关配置外部负载平衡的更多信息，请参阅 Overcloud 的专用外部负载平衡指南以了解 完整说明。
14.2. 配置 IPv6 网络
作为默认，Overcloud 使用互联网协议版本 4 (IPv4)来配置服务端点。但是，Overcloud 还支持互联网协议版本 6 (IPv6)端点，这对于支持 IPv6 基础架构的组织很有用。director 包括一组环境文件，用于帮助创建基于 IPv6 的 Overcloud。
有关在 Overcloud 中配置 IPv6 的更多信息，请参阅 Overcloud 的专用 IPv6 网络指南。
附录 A. 网络环境选项
| 参数 | 描述 | 示例 |
|---|---|---|
| InternalApiNetCidr | 内部 API 网络的网络和子网 | 172.17.0.0/24 |
| StorageNetCidr | 存储网络的网络和子网 | |
| StorageMgmtNetCidr | Storage Management 网络的网络和子网 | |
| TenantNetCidr | 租户网络的网络和子网 | |
| ExternalNetCidr | External 网络的网络和子网 | |
| InternalApiAllocationPools | 内部 API 网络的分配池，格式为 tuple 格式 | [{start:172.17.0.10,end:172.17.0.200}] |
| StorageAllocationPools | 存储网络的分配池，格式为 tuple | |
| StorageMgmtAllocationPools | Storage Management 网络的分配池，格式为 tuple | |
| TenantAllocationPools | 租户网络的分配池，格式为 tuple | |
| ExternalAllocationPools | 元组格式外部网络的分配池 | |
| InternalApiNetworkVlanID | 内部 API 网络的 VLAN ID | 200 |
| StorageNetworkVlanID | 存储网络的 VLAN ID | |
| StorageMgmtNetworkVlanID | Storage Management 网络的 VLAN ID | |
| TenantNetworkVlanID | 租户网络的 VLAN ID | |
| ExternalNetworkVlanID | External 网络的 VLAN ID | |
| ExternalInterfaceDefaultRoute | External 网络的网关 IP 地址 | 10.1.2.1 |
| ControlPlaneDefaultRoute | Provisioning 网络的网关路由器（或 Undercloud IP） | ControlPlaneDefaultRoute: 192.0.2.254 |
| ControlPlaneSubnetCidr | 置备网络的 CIDR 子网掩码长度 | ControlPlaneSubnetCidr: 24 |
| EC2MetadataIp | EC2 元数据服务器的 IP 地址。Undercloud 的 IP 通常. | EC2MetadataIp: 192.0.2.1 |
| DnsServers | 定义 Overcloud 节点的 DNS 服务器。最多包含 2 个. | DnsServers: ["8.8.8.8","8.8.4.4"] |
| BondInterfaceOvsOptions | 绑定接口的选项 | BondInterfaceOvsOptions:"bond_mode=balance-slb" |
| NeutronFlatNetworks | 定义要在 neutron 插件中配置的扁平网络。默认为 "datacentre" 以允许外部网络创建 | NeutronFlatNetworks: "datacentre" |
| NeutronExternalNetworkBridge | 在每个虚拟机监控程序上创建的 Open vSwitch 网桥。通常，这应该不需要更改。 | NeutronExternalNetworkBridge: "''" |
| NeutronBridgeMappings | 要使用的物理网桥映射逻辑。默认为将主机上的外部网桥(br-ex)映射到物理名称(datacentre)。您将将其用于默认浮动网络 | NeutronBridgeMappings: "datacentre:br-ex" |
| NeutronPublicInterface | 定义要在 br-ex 上桥接到网络节点的接口 | NeutronPublicInterface: "eth0" |
| NeutronNetworkType | Neutron 的租户网络类型 | NeutronNetworkType: "vxlan" |
| NeutronTunnelTypes | neutron 租户网络的隧道类型。要指定多个值，请使用以逗号分隔的字符串。 | NeutronTunnelTypes: gre,vxlan |
| NeutronTunnelIdRanges | GRE 隧道 ID 范围，用于租户网络分配 | NeutronTunnelIdRanges "1:1000" |
| NeutronVniRanges | VXLAN VNI ID 范围，用于租户网络分配 | NeutronVniRanges: "1:1000" |
| NeutronEnableTunnelling | 定义在打算使用 VLAN 段网络或 Neutron 的扁平网络时，启用或禁用隧道。默认为 enabled | |
| NeutronNetworkVLANRanges | 用于支持的 neutron ML2 和 Open vSwitch VLAN 映射范围。默认为允许 datacentre 物理网络中的任何 VLAN。 | NeutronNetworkVLANRanges: "datacentre:1:1000" |
| NeutronMechanismDrivers | neutron 租户网络的机制驱动程序。默认为 "openvswitch"。要指定多个值，请使用以逗号分隔的字符串 | NeutronMechanismDrivers: openvswitch,l2population |
附录 B. 网络接口模板示例
本附录提供了几个示例 Heat 模板，用于演示网络接口配置。
B.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、 等)而不是命名接口(nic 2eth0、 主机的网络接口不必完全相同。例如，一个主机可能具有接口 eno2 等)时，角色中的em1 和 em2，而另一个主机具有 eno1 和 eno2，但您可以将主机的 NIC 指代为 nic1 和 nic2。
数字接口的顺序对应于命名网络接口类型的顺序：
-
ethX接口，如eth0、eth1等。这些通常是板载接口。 -
enoX接口，如eno0、eno1等。这些通常是板载接口。 -
enX接口，按数字顺序排序，如enp3s0、enp3s1、ens3等。这些通常是附加接口。
编号的 NIC 方案仅考虑实时接口，例如，如果它们有电缆附加到交换机。如果您的主机有四个接口，并且有六个接口，您应该使用 nic1 到 nic4，并且每个主机上仅插入四个电缆。
B.2. 配置路由和默认路由
主机设置了默认路由的方法有两种。如果接口正在使用 DHCP，并且 DHCP 服务器提供网关地址，则系统会将默认路由用于该网关。否则，您可以使用静态 IP 在接口上设置默认路由。
虽然 Linux 内核支持多个默认网关，但它只使用具有最低指标的用户。如果有多个 DHCP 接口，这可能会导致无法预测的默认网关。在这种情况下，建议为使用默认路由的接口设置 defroute=no。
例如，您可能希望 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.1B.3. 将原生 VLAN 用于浮动 IP
Neutron 将默认空字符串用于其外部网桥映射。这会将物理接口映射到 br-int，而不直接使用 br-ex。此模型允许使用 VLAN 或多个物理连接的多个浮动 IP 网络。
在网络隔离环境文件的 parameter_defaults 部分中使用 NeutronExternalNetworkBridge 参数：
parameter_defaults:
# Set to "br-ex" when using floating IPs on the native VLAN
NeutronExternalNetworkBridge: "''"在网桥的原生 VLAN 上仅使用一个浮动 IP 网络，这意味着您可以选择性地设置 neutron 外部网桥。这会导致数据包只需要遍历一个网桥，而不是两个，这在通过浮动 IP 网络传输流量时可能会导致 CPU 使用量稍低。
B.4. 在 Trunked 接口上使用原生 VLAN
如果中继接口或绑定在原生 VLAN 上有网络，则 IP 地址直接分配给网桥，且没有 VLAN 接口。
例如，如果 External 网络位于原生 VLAN 上，绑定的配置类似如下：
network_config:
- type: ovs_bridge
name: {get_input: bridge_name}
dns_servers: {get_param: DnsServers}
addresses:
- ip_netmask: {get_param: ExternalIpSubnet}
routes:
- ip_netmask: 0.0.0.0/0
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 接口。对所有适用角色进行更改。External 网络仅在控制器上，因此只有控制器模板需要更改。另一方面，存储网络附加到所有角色，因此如果存储网络位于默认的 VLAN 中，则所有角色都需要修改。
B.5. 配置巨型帧
最大传输单元(MTU)设置决定了通过单个以太网帧传输的最大数据量。使用较大的值会导致开销较少，因为每个帧以标头的形式添加数据。默认值为 1500，使用较高的值需要配置交换机端口来支持巨型帧。大多数交换机支持至少 9000 的 MTU，但很多交换机默认配置为 1500。
VLAN 的 MTU 不能超过物理接口的 MTU。确保在绑定和/或接口上包含 MTU 值。
存储、存储管理、内部 API 和租户网络都受益于巨型帧。在测试中，当结合使用巨型帧与 VXLAN 隧道时，租户网络吞吐量超过 300%。
建议 Provisioning 接口、外部接口和任何浮动 IP 接口保留在 1500 的默认 MTU。否则可能会发生连接问题。这是因为路由器通常无法跨第 3 层边界转发巨型帧。
- type: ovs_bond
name: bond1
mtu: 9000
ovs_options: {get_param: BondInterfaceOvsOptions}
members:
- type: interface
name: nic3
mtu: 9000
primary: true
- type: interface
name: nic4
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:
- ip_netmask: 0.0.0.0/0
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}附录 C. 网络接口参数
下表定义网络接口类型的 Heat 模板参数。
C.1. 接口选项
| 选项 | 默认值 | 描述 |
| name | 接口的名称 | |
| use_dhcp | False | 使用 DHCP 获取 IP 地址 |
| use_dhcpv6 | False | 使用 DHCP 获取 v6 IP 地址 |
| addresses | 分配给接口的 IP 地址序列 | |
| Routes | 分配给接口的一组路由 | |
| mtu | 1500 | 连接的最大传输单元(MTU) |
| primary | False | 将接口定义为主接口 |
| defroute | true | 使用此接口作为默认路由 |
| persist_mapping | False | 写入设备别名配置，而不是系统名称 |
| dhclient_args | None | 传递给 DHCP 客户端的参数 |
| dns_servers | None | 用于接口的 DNS 服务器列表 |
C.2. VLAN 选项
| 选项 | 默认值 | 描述 |
| vlan_id | VLAN ID | |
| device | VLAN 的父设备来附加 VLAN。例如，使用此参数将 VLAN 附加到绑定接口设备。 | |
| use_dhcp | False | 使用 DHCP 获取 IP 地址 |
| use_dhcpv6 | False | 使用 DHCP 获取 v6 IP 地址 |
| addresses | 分配给 VLAN 的 IP 地址序列 | |
| Routes | 分配给 VLAN 的一组路由 | |
| mtu | 1500 | 连接的最大传输单元(MTU) |
| primary | False | 将 VLAN 定义为主接口 |
| defroute | true | 使用此接口作为默认路由 |
| persist_mapping | False | 写入设备别名配置，而不是系统名称 |
| dhclient_args | None | 传递给 DHCP 客户端的参数 |
| dns_servers | None | 用于 VLAN 的 DNS 服务器列表 |
C.3. OVS 绑定选项
| 选项 | 默认值 | 描述 |
| name | 绑定的名称 | |
| use_dhcp | False | 使用 DHCP 获取 IP 地址 |
| use_dhcpv6 | False | 使用 DHCP 获取 v6 IP 地址 |
| addresses | 分配给绑定的 IP 地址序列 | |
| Routes | 分配给绑定的一组路由 | |
| mtu | 1500 | 连接的最大传输单元(MTU) |
| primary | False | 将接口定义为主接口 |
| 成员 | 在绑定中使用的一系列接口对象 | |
| ovs_options | 创建绑定时传递给 OVS 的一组选项 | |
| ovs_extra | 在绑定的网络配置文件中设置为 OVS_EXTRA 参数的一组选项 | |
| defroute | true | 使用此接口作为默认路由 |
| persist_mapping | False | 写入设备别名配置，而不是系统名称 |
| dhclient_args | None | 传递给 DHCP 客户端的参数 |
| dns_servers | None | 用于绑定的 DNS 服务器列表 |
C.4. OVS Bridge 选项
| 选项 | 默认值 | 描述 |
| name | 网桥的名称 | |
| use_dhcp | False | 使用 DHCP 获取 IP 地址 |
| use_dhcpv6 | False | 使用 DHCP 获取 v6 IP 地址 |
| addresses | 分配给网桥的 IP 地址序列 | |
| Routes | 分配给网桥的一组路由 | |
| mtu | 1500 | 连接的最大传输单元(MTU) |
| 成员 | 网桥中使用的接口、VLAN 和绑定对象序列 | |
| ovs_options | 创建网桥时传递给 OVS 的一组选项 | |
| ovs_extra | 一组要设置为网桥网络配置文件中的 OVS_EXTRA 参数的选项 | |
| defroute | true | 使用此接口作为默认路由 |
| persist_mapping | False | 写入设备别名配置，而不是系统名称 |
| dhclient_args | None | 传递给 DHCP 客户端的参数 |
| dns_servers | None | 用于网桥的 DNS 服务器列表 |
C.5. Linux 绑定选项
| 选项 | 默认值 | 描述 |
| name | 绑定的名称 | |
| use_dhcp | False | 使用 DHCP 获取 IP 地址 |
| use_dhcpv6 | False | 使用 DHCP 获取 v6 IP 地址 |
| addresses | 分配给绑定的 IP 地址序列 | |
| Routes | 分配给绑定的一组路由 | |
| mtu | 1500 | 连接的最大传输单元(MTU) |
| primary | False | 将接口定义为主接口 |
| 成员 | 在绑定中使用的一系列接口对象 | |
| bonding_options | 创建绑定时的一组选项。有关 Linux 绑定选项的更多信息，请参阅 4.5.1。bonding Module Directives （在 Red Hat Enterprise Linux 7 网络指南中）。 | |
| defroute | true | 使用此接口作为默认路由 |
| persist_mapping | False | 写入设备别名配置，而不是系统名称 |
| dhclient_args | None | 传递给 DHCP 客户端的参数 |
| dns_servers | None | 用于绑定的 DNS 服务器列表 |
C.6. Linux Bridge 选项
| 选项 | 默认值 | 描述 |
| name | 网桥的名称 | |
| use_dhcp | False | 使用 DHCP 获取 IP 地址 |
| use_dhcpv6 | False | 使用 DHCP 获取 v6 IP 地址 |
| addresses | 分配给网桥的 IP 地址序列 | |
| Routes | 分配给网桥的一组路由 | |
| mtu | 1500 | 连接的最大传输单元(MTU) |
| 成员 | 网桥中使用的接口、VLAN 和绑定对象序列 | |
| defroute | true | 使用此接口作为默认路由 |
| persist_mapping | False | 写入设备别名配置，而不是系统名称 |
| dhclient_args | None | 传递给 DHCP 客户端的参数 |
| dns_servers | None | 用于网桥的 DNS 服务器列表 |
附录 D. 绑定选项
您可以将多个物理 NIC 捆绑在一起，以形成一个逻辑频道，称为绑定。可将绑定配置为为高可用性系统提供冗余性或增加吞吐量。
D.1. 网络接口绑定和链路聚合控制协议(LACP)
Red Hat OpenStack Platform 支持 Linux 绑定、Open vSwitch (OVS)内核绑定和 OVS-DPDK 绑定。
绑定可用于可选的链路聚合控制协议(LACP)。LACP 是一个协商协议，可为负载平衡和容错创建动态绑定。
在与虚拟机实例直接交互的任何网络中，红帽建议使用 OVS 内核绑定(bond 类型 ovs_bond)或 OVS-DPDK 绑定(bond type ovs_dpdk_bond)带有 LACP。但是，不要将 OVS 内核绑定和 OVS-DPDK 绑定组合在同一节点上。
在控制和存储网络上，红帽建议将 Linux 绑定与 VLAN 和 LACP 搭配使用，因为 OVS 或 neutron 代理重启更新、热修复和其他事件时可能会发生 control plane 中断预算。Linux 绑定/LACP/VLAN 配置提供 NIC 管理，而无需 OVS 中断。以下是具有一个 VLAN 的 Linux 绑定配置示例。
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: InternalApiIpSubnetD.2. Open vSwitch 绑定选项
Overcloud 通过 Open vSwitch (OVS)提供网络。下表描述了对 OVS 内核和 OVS-DPDK 用于绑定接口的支持。OVS/OVS-DPDK balance-tcp 模式仅作为技术预览提供。
下表中描述的绑定选项需要 OVS 2.9 或更高版本。
| OVS 绑定模式 | Application（应用程序） | 备注 | 兼容 LACP 选项 |
| active-backup | 高可用性（主动-被动） | 主动、被动或关闭 | |
| balance-slb | 增加吞吐量(active-active) |
| 主动、被动或关闭 |
| balance-tcp （仅限技术预览） | 不建议(active-active) |
| 主动或被动 |
您可以使用 BondInterfaceOvsOptions 参数在网络环境文件中配置绑定接口，如下例所示：
parameter_defaults:
BondInterfaceOvsOptions: "bond_mode=balance-slb"D.3. balance-tcp 模式的注意事项
如果您决定使用 balance-tcp 模式，尽管其技术预览状态和已知的性能问题，您必须在部署前从每个网络接口配置(NIC)文件中手动删除以下行：
constraints:
- allowed_pattern: "^((?!balance.tcp).)*$"
description: |
The balance-tcp bond mode is known to cause packet loss and
should not be used in BondInterfaceOvsOptions.从每个 NIC 文件中删除约束后，您可以在绑定接口参数中设置绑定模式选项：
BondInterfaceOvsOptions:
"bond_mode=balance-tcp"D.4. Linux 绑定选项
您可以在网络接口模板中将 LACP 与 Linux 绑定一起使用。例如：
- 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"-
mode- 启用 LACP。 -
lacp_rate- 定义 LACP 数据包是否每 1 秒发送一次，还是每 30 秒发送一次。 -
updelay- 定义接口在用于流量之前必须活跃的最少时间（这有助于缓解端口流中断）。 -
miimon- 使用驱动程序的 MIIMON 功能监控端口状态的时间间隔（以毫秒为单位）。
有关 Linux 绑定选项的更多信息，请参阅 4.5.1。bonding Module Directives in the Red Hat Enterprise Linux 7 Networking Guide.
D.5. 绑定选项
下表根据硬件提供了这些选项的一些说明和一些替代方案。
|
|
根据源 MAC 地址和输出 VLAN 平衡流，并在流量模式更改时定期重新平衡。与 |
|
| 这个模式提供主动/standby 故障转移，在活跃连接失败时待机 NIC 恢复网络操作。物理交换机仅显示一个 MAC 地址。这个模式不需要任何特殊的交换机支持或配置，当链接连接到单独的交换机时可以正常工作。这个模式不提供负载均衡。 |
|
|
控制链路聚合控制协议(LACP)行为。只有特定的交换机支持 LACP。如果您的交换机不支持 LACP，请使用 |
|
| 设置 LACP 行为，以切换到 bond_mode=active-backup 作为回退。 |
|
| 将 LACP heartbeat 设置为 1 秒(fast)或 30 秒(slow)。默认设置会较慢。 |
|
| 将链路检测设置为使用 miimon heartbeats (miimon)或监控载体(carrier)。默认值为 carrier。 |
|
| 如果使用 miimon，以毫秒为单位设置心跳间隔。 |
|
| 必须激活链接的毫秒数，以防止流动。 |
|
| 绑定成员之间的重新平衡流间隔的毫秒。设置为 0 以禁用。 |
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}