Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

高级 Overcloud 自定义

Red Hat OpenStack Platform 10

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

OpenStack Documentation Team

摘要

本指南说明了如何使用 Red Hat OpenStack Platform Director 为 Red Hat OpenStack Platform 企业环境配置特定的高级功能。这包括网络隔离、存储配置、SSL 通信和常规配置方法等功能。

第 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 --nested

2.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-registration director 提供了将节点的 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 命令通过以下流程运行:

  1. 根据 --template 选项,从核心 Heat 模板集合加载默认配置。
  2. 应用 environment-file-1.yaml 的配置,这将覆盖默认配置中的任何通用设置。
  3. 应用 environment-file-2.yaml 的配置,它会覆盖默认配置和 environment-file-1.yaml 中的任何通用设置。

这会导致对 Overcloud 的默认配置进行了以下更改:

  • OS::TripleO::NodeExtraConfigPost 资源设置为每个 environment-file-2.yaml/home/stack/templates/template-2.yaml
  • timezone 参数设置为 per environment-file-2.yaml
  • RabbitFDLimit 参数被设置为 65536,作为每个 环境文件-1.yamlenvironment-file-2.yaml 不会更改此值。

这提供了一种方式,可将自定义配置定义为 Overcloud,而不定义来自多个环境文件的值。

2.5. 使用自定义核心 Heat 模板

在创建 overcloud 时,director 使用一组位于 /usr/share/openstack-tripleo-heat-templates 中的 Heat 模板的核心集合。如果要自定义此核心模板集合,请使用 Git 工作流来跟踪更改和合并更新。使用以下 git 进程来帮助管理自定义模板集合:

初始化自定义模板集合

使用以下流程来创建包含 Heat 模板集合的初始 Git 存储库:

  1. 将模板的目录复制到 stack 用户目录中。这个示例将其复制到 ~/templates 目录中:

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

    $ cd openstack-tripleo-heat-templates
    $ git init .
  3. 暂存初始提交的所有模板:

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

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

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

创建自定义分支和提交更改

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

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

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

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

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

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

更新自定义模板集合:

在更新 undercloud 时,openstack-tripleo-heat-templates 软件包可能会更新。使用以下步骤更新自定义模板集合:

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

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

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

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

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

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

    $ git checkout master
    $ git merge $PACKAGE

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

重负自定义分支

使用以下流程更新 my-customization 分支,:

  1. 进入 my-customizations 分支:

    $ git checkout my-customizations
  2. 重新构建分支 off master

    $ git rebase master

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

如果 git 在 rebase 期间报告任何冲突,请使用此流程:

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

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

    $ git add [resolved files]
    $ git commit
  4. 继续更新:

    $ git rebase --continue

部署自定义模板

使用以下步骤部署自定义模板集合:

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

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

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

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

第 3 章 参数

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

  • overcloud.j2.yaml - 默认基础参数
  • roles_data.yaml - 可组合角色的默认参数
  • Puppet/services locate.yaml - 特定服务的默认参数

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

  1. 为您的自定义参数创建一个环境文件。
  2. 在环境文件的 parameter_defaults 部分中包含您的自定义参数。
  3. 使用 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: true

3.3. 示例 3:配置 Telemetry Dispatcher

OpenStack 遥测(ceilometer)服务包含时间序列数据存储(gnocchi)的组件。puppet/services/ceilometer-base.yaml Heat 模板允许您在 gnocchi 和标准数据库之间切换。您可以使用 CeilometerMeterDispatcher 参数完成此操作,该参数设置为其中之一:

  • Gnocchi - 将新的时间序列数据库用于 Ceilometer 分配程序。这是默认选项。
  • 数据库 - 为 Ceilometer 分配程序使用标准数据库。

要切换到标准数据库,请在环境文件中添加以下内容:

parameter_defaults:
  CeilometerMeterDispatcher: database

3.4. 示例 4:配置 RabbitMQ 文件描述符限制

对于某些配置,您可能需要增加 RabbitMQ 服务器的文件描述符限制。puppet/services/rabbitmq.yaml Heat 模板允许您将 RabbitFDLimit 参数设置为您需要的限制。将以下内容添加到环境文件中。

parameter_defaults:
  RabbitFDLimit: 65536

3.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 参数:

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

    • 如果 Puppet 模块包含控制所选选项的变量,请转到下一步。
    • 如果 Puppet 模块不包含控制所选选项的变量,则此选项没有 hieradata。如果可能,您可以在 overcloud 完成部署后手动设置选项。
  3. 以 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)的通知格式。使用工作流,您可以:

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

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

    在这种情况下,keystone 模块使用 keystone::notification_format 变量管理这个选项。

  3. 为此变量搜索 keystone 服务模板。例如:

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

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

下表显示了最终映射:

Director 参数Puppet HieradataOpenStack Identity (keystone)选项

KeystoneNotificationFormat

keystone::notification_format

notification_format

这意味着在 overcloud 的环境文件中设置 KeystoneNotificationFormat,会在 overcloud 的配置期间设置 keystone.conf 文件中的 notification_format 选项。

第 4 章 配置 Hook

配置 hook 提供了将您自己的配置功能注入 Overcloud 部署过程的方法。这包括用于在主 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 时应用配置。可能的操作包括 CREATEUPDATEDELETESUSPENDRESUME
  • 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 时应用配置。可能的操作包括 CREATEUPDATEDELETESUSPENDRESUME
  • 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 时应用配置。可能的操作包括 CREATEUPDATEDELETESUSPENDRESUME
  • 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

详情请查看 第 6.9 节 “Service Architecture: Split Controller”

架构 3 - 独立角色
使用架构 1 或架构 2,除了将 OpenStack Platform 服务分成自定义角色外。详情请查看 第 6.10 节 “服务架构:独立角色”

6.1. 检查自定义角色架构

Overcloud 创建流程利用包含角色数据的模板来定义其角色。默认模板位于 /usr/share/openstack-tripleo-heat-templates/roles_data.yaml,定义所有默认角色类型: ControllerComputeBlockStorageObjectStorageCephStorage

重要

如果创建自定义 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::None

6.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 list

6.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)中包含该角色。确保保留现有的 ControllerCompute 角色。

您还可以包括一个环境文件(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::VipHosts

Ceph 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 -f

6.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::VipHosts

6.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::Redis

Controller 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::VipHosts

6.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::ApacheOS::TripleO::Services::Keystone 服务。唯一的例外是服务有有限的自定义角色支持(请参阅 表 6.1 “自定义角色支持”)。

单击下表中的角色,以查看与其关联的服务。

表 6.1. 自定义角色支持

角色支持状态

Ceph Storage Monitor

支持

Ceph Storage OSD

支持

Ceph Storage RadosGW

有限.如果分割,这个服务需要是 Controller systemd 角色的一部分。

Cinder API

支持

Controller PCMK

支持

Glance

支持

Heat

支持

Horizon

支持

ironic

有限.如果分割,这个服务需要是 Controller systemd 角色的一部分。

Keystone

支持

Manila

有限.如果分割,这个服务需要是 Controller systemd 角色的一部分。

Networker

支持

Neutron API

支持

Nova

支持

Nova Compute

支持

OpenDaylight

技术预览

Sahara

有限.如果分割,这个服务需要是 Controller systemd 角色的一部分。

Swift API

支持

Swift Storage

支持

Telemetry

支持

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::CephMon

Ceph 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::CephOSD

Ceph 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::CephClient

Cinder 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::CinderScheduler

Controller 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::VipHosts

Glance

以下服务配置 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::GlanceRegistry

Heat

以下服务配置 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::HeatEngine

Horizon

以下服务配置 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::Horizon

ironic

以下服务配置 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::NovaIronic

Keystone

以下服务配置 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::Keystone

Manila

以下服务配置 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::ManilaScheduler

Networker

以下服务配置 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::NeutronOvsAgent

Neutron 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::NeutronCorePluginPlumgrid

Nova

以下服务配置 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::NovaVncProxy

Nova 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::OpenDaylightOvs

OpenDaylight

以下服务配置 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::OpenDaylightOvs

Sahara

以下服务配置 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::SaharaEngine

Swift 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::SwiftRingBuilder

Swift 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::SwiftStorage

Telemetry

以下服务配置 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::MongoDb

6.11. 可组合服务参考

下表包含 Red Hat OpenStack Platform 中所有可用可组合服务的列表。

重要

一些服务默认为禁用。有关如何启用这些服务的详情,请查看 第 6.3 节 “启用禁用的服务”

服务描述

OS::TripleO::Services::AodhApi

使用 Puppet 配置的 OpenStack Telemetry Alarming (aodh) API 服务

OS::TripleO::Services::AodhEvaluator

OpenStack Telemetry Alarming (aodh) Evaluator 服务配置有 Puppet

OS::TripleO::Services::AodhListener

使用 Puppet 配置的 OpenStack Telemetry Alarming (aodh) Listener 服务

OS::TripleO::Services::AodhNotifier

使用 Puppet 配置的 OpenStack Telemetry Alarming (aodh) Notifier 服务

OS::TripleO::Services::Apache

配置有 Puppet 的 Apache 服务。请注意,这通常和通过 Apache 运行的其他服务自动包括。

OS::TripleO::Services::CACerts

配置 Puppet 的 HAProxy 服务

OS::TripleO::Services::CeilometerAgentCentral

OpenStack Telemetry (ceilometer)中央代理服务配置有 Puppet

OS::TripleO::Services::CeilometerAgentNotification

OpenStack Telemetry (ceilometer)通知代理服务配置有 Puppet

OS::TripleO::Services::CeilometerApi

OpenStack Telemetry (ceilometer) API 服务配置有 Puppet

OS::TripleO::Services::CeilometerCollector

OpenStack Telemetry (ceilometer) Collector 服务配置有 Puppet

OS::TripleO::Services::CeilometerExpirer

OpenStack Telemetry (ceilometer) Expirer 服务配置有 Puppet

OS::TripleO::Services::CephClient

(默认禁用) Ceph 客户端服务

OS::TripleO::Services::CephExternal

(默认禁用) Ceph 外部服务

OS::TripleO::Services::CephMon

(默认禁用) Ceph Monitor 服务

OS::TripleO::Services::CephOSD

(默认禁用) Ceph OSD 服务

OS::TripleO::Services::CinderApi

使用 Puppet 配置的 OpenStack Block Storage (cinder) API 服务

OS::TripleO::Services::CinderBackup

(默认为禁用)配置了 Puppet 的 OpenStack Block Storage (cinder)备份服务

OS::TripleO::Services::CinderScheduler

OpenStack Block Storage (cinder)调度程序服务配置有 Puppet

OS::TripleO::Services::CinderVolume

使用 Puppet 配置的 OpenStack Block Storage (cinder)卷服务(Pacemaker-managed)

OS::TripleO::Services::ComputeCeilometerAgent

OpenStack Telemetry (ceilometer)计算代理服务配置有 Puppet

OS::TripleO::Services::ComputeNeutronCorePlugin

OpenStack 网络(neutron) ML2 插件配置有 Puppet

OS::TripleO::Services::ComputeNeutronL3Agent

(默认禁用) OpenStack 网络(neutron)用于启用 DVR 的 Compute 节点的 L3 代理使用 Puppet 配置

OS::TripleO::Services::ComputeNeutronMetadataAgent

(默认情况下禁用)配置了 Puppet 的 OpenStack 网络(neutron)元数据代理

OS::TripleO::Services::ComputeNeutronOvsAgent

使用 Puppet 配置的 OpenStack 网络(neutron) OVS 代理

OS::TripleO::Services::FluentdClient

(默认禁用)配置了 Puppet 的 Fluentd 客户端

OS::TripleO::Services::GlanceApi

OpenStack Image (glance) API 服务配置有 Puppet

OS::TripleO::Services::GlanceRegistry

OpenStack Image (glance) Registry 服务配置有 Puppet

OS::TripleO::Services::GnocchiApi

OpenStack Telemetry Metrics (gnocchi)服务配置有 Puppet

OS::TripleO::Services::GnocchiMetricd

OpenStack Telemetry Metrics (gnocchi)服务配置有 Puppet

OS::TripleO::Services::GnocchiStatsd

OpenStack Telemetry Metrics (gnocchi)服务配置有 Puppet

OS::TripleO::Services::HAproxy

使用 Puppet 配置的 HAProxy 服务(Pacemaker 管理)

OS::TripleO::Services::HeatApi

使用 Puppet 配置的 OpenStack Orchestration (heat) API 服务

OS::TripleO::Services::HeatApiCfn

使用 Puppet 配置的 OpenStack Orchestration (heat) CloudFormation API 服务

OS::TripleO::Services::HeatApiCloudwatch

使用 Puppet 配置的 OpenStack Orchestration (heat) CloudWatch API 服务

OS::TripleO::Services::HeatEngine

使用 Puppet 配置的 OpenStack Orchestration (heat) Engine 服务

OS::TripleO::Services::Horizon

OpenStack Dashboard (horizon)服务配置有 Puppet

OS::TripleO::Services::IronicApi

(默认禁用) OpenStack Bare Metal Provisioning (ironic) API 配置有 Puppet

OS::TripleO::Services::IronicConductor

(默认禁用) OpenStack Bare Metal Provisioning (ironic)配置有 Puppet 的编排器

OS::TripleO::Services::Keepalived

keepalived 服务配置有 Puppet

OS::TripleO::Services::Kernel

使用 kmod 加载内核模块并使用 sysctl 配置内核选项

OS::TripleO::Services::ManilaApi

(默认禁用)配置了 Puppet 的 OpenStack 共享文件系统服务(manila) API 服务

OS::TripleO::Services::ManilaScheduler

(默认为禁用)配置了 Puppet 的 OpenStack 共享文件系统服务(manila)调度程序服务

OS::TripleO::Services::ManilaShare

(默认情况下禁用) OpenStack 共享文件系统服务(manila)使用 Puppet 配置

OS::TripleO::Services::Keystone

使用 Puppet 配置的 OpenStack Identity (keystone)服务

OS::TripleO::Services::Memcached

使用 Puppet 配置的 Memcached 服务

OS::TripleO::Services::MongoDb

使用 puppet 部署 MongoDB 服务

OS::TripleO::Services::MySQL

使用 puppet 部署 MySQL (Pacemaker 管理的)服务部署

OS::TripleO::Services::NeutronApi

使用 Puppet 配置的 OpenStack 网络(neutron)服务器

OS::TripleO::Services::NeutronCorePlugin

OpenStack 网络(neutron) ML2 插件配置有 Puppet

OS::TripleO::Services::NeutronCorePluginML2OVN

使用 Puppet 配置的 OpenStack 网络(neutron) ML2/OVN 插件

OS::TripleO::Services::NeutronCorePluginMidonet

OpenStack Networking (neutron) Midonet 插件和服务

OS::TripleO::Services::NeutronCorePluginNuage

OpenStack 网络(neutron) Nuage 插件

OS::TripleO::Services::NeutronCorePluginOpencontrail

OpenStack Networking (neutron) Opencontrail 插件

OS::TripleO::Services::NeutronCorePluginPlumgrid

OpenStack Networking (neutron) Plumgrid 插件

OS::TripleO::Services::NeutronDhcpAgent

使用 Puppet 配置的 OpenStack 网络(neutron) DHCP 代理

OS::TripleO::Services::NeutronL3Agent

使用 Puppet 配置的 OpenStack 网络(neutron) L3 代理

OS::TripleO::Services::NeutronMetadataAgent

使用 Puppet 配置的 OpenStack 网络(neutron)元数据代理

OS::TripleO::Services::NeutronOvsAgent

使用 Puppet 配置的 OpenStack 网络(neutron) OVS 代理

OS::TripleO::Services::NeutronServer

使用 Puppet 配置的 OpenStack 网络(neutron)服务器

OS::TripleO::Services::NeutronSriovAgent

(默认情况下禁用)配置了 Puppet 的 OpenStack Neutron SR-IOV nic 代理

OS::TripleO::Services::NovaApi

OpenStack Compute (nova) API 服务配置有 Puppet

OS::TripleO::Services::NovaCompute

配置了 Puppet 的 OpenStack Compute (nova) Compute 服务

OS::TripleO::Services::NovaConductor

OpenStack Compute (nova) Conductor 服务配置有 Puppet

OS::TripleO::Services::NovaConsoleauth

OpenStack Compute (nova) Consoleauth 服务配置有 Puppet

OS::TripleO::Services::NovaIronic

(默认情况下禁用) OpenStack Compute (nova)服务配置有 Puppet 并且使用 Ironic

OS::TripleO::Services::NovaLibvirt

libvirt 服务配置有 Puppet

OS::TripleO::Services::NovaScheduler

OpenStack Compute (nova)调度程序服务配置有 Puppet

OS::TripleO::Services::NovaVncProxy

OpenStack Compute (nova) Vncproxy 服务配置有 Puppet

OS::TripleO::Services::Ntp

使用 Puppet 进行 NTP 服务部署.

OS::TripleO::Services::OpenDaylight

(默认禁用) OpenDaylight SDN 控制器

OS::TripleO::Services::OpenDaylightOvs

(默认禁用) OpenDaylight OVS 配置

OS::TripleO::Services::Pacemaker

使用 Puppet 配置的 Pacemaker 服务

OS::TripleO::Services::RabbitMQ

使用 Puppet 配置的 RabbitMQ 服务(Pacemaker 管理)

OS::TripleO::Services::Redis

使用 Puppet 配置的 OpenStack Redis 服务

OS::TripleO::Services::SaharaApi

(默认禁用) OpenStack 集群(sahara)使用 Puppet 配置的 API 服务

OS::TripleO::Services::SaharaEngine

(默认禁用)使用 Puppet 配置的 OpenStack 集群(sahara) Engine 服务

OS::TripleO::Services::SensuClient

(默认情况下禁用)配置了 Puppet 的 Sensu 客户端

OS::TripleO::Services::Sshd

(默认禁用) SSH 守护进程配置。作为默认服务包括。

OS::TripleO::Services::Snmp

SNMP 客户端配置了 Puppet,在 undercloud 中促进 Ceilometer 硬件监控。启用硬件监控需要此服务。

OS::TripleO::Services::SwiftProxy

OpenStack Object Storage (swift)代理服务配置有 Puppet

OS::TripleO::Services::SwiftRingBuilder

OpenStack Object Storage (swift) Ringbuilder

OS::TripleO::Services::SwiftStorage

OpenStack Object Storage (swift)服务配置有 Puppet

OS::TripleO::Services::Timezone

可组合时区服务

OS::TripleO::Services::TripleoFirewall

防火墙设置

OS::TripleO::Services::TripleoPackages

软件包安装设置

第 7 章 隔离网络

director 提供了配置隔离 Overcloud 网络的方法。这意味着 Overcloud 环境将网络流量类型划分为不同的网络,后者将网络流量分配到特定的网络接口或绑定。配置隔离的网络后,director 将 OpenStack 服务配置为使用隔离的网络。如果没有配置隔离网络,则所有服务都在 Provisioning 网络上运行。

这个示例为所有服务使用单独的网络:

  • 网络 1 - 置备
  • 网络 2 - 内部 API
  • 网络 3 - 租户网络
  • 网络 4 - 存储
  • 网络 5 - 存储管理
  • 网络 6 - 管理
  • 网络 7 - 外部浮动 IP ( Overcloud 创建后映射)

在本例中,每个 Overcloud 节点使用绑定中的两个网络接口来提供 tagged VLAN 中的网络。以下网络分配适用于此绑定:

表 7.1. 网络子网和 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_bondvlan 对象连接在一起。

          - 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_bondvlan 对象连接在一起。

            - 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 的绑定接口: nic2nic3。该网桥还包含一些标记的 VLAN 设备,其使用 bond1 作为父设备。该模板还包括连接到 director 的接口(nic1)。

有关网络接口模板的更多示例,请参阅 附录 B, 网络接口模板示例

请注意,其中很多参数使用 get_param 函数。您可以在您为网络创建的环境文件中定义。

重要

未使用的接口可能会导致不必要的默认路由和网络循环。例如,模板可能包含一个网络接口(nic4),它不使用 OpenStack 服务的任何 IP 分配,但仍使用 DHCP 和/或默认路由。为了避免网络冲突,请从 ovs_bridge 设备中删除所有未使用的接口,并禁用 DHCP 和默认路由设置:

- type: interface
  name: nic4
  use_dhcp: false
  defroute: false

7.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- vlans.yaml- 单一 NIC 的带有 VLAN 配置的环境文件。用于禁用外部网络(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- multiple-nics.yaml - 多个 NIC 配置的示例环境文件。也提供用于启用 IPv6 的环境文件(net-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 选项使用 nic2nic3 为绑定接口提供选项。有关绑定选项的详情请参考 附录 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-0controller-1
  • 分配自定义主机名
  • 分配特定的 IP 地址
  • 分配特定的虚拟 IP 地址
注意

为网络手动设置可预测的 IP 地址、虚拟 IP 地址和端口,可减少分配池的需求。但是,建议为每个网络保留分配池,以便更轻松地扩展新节点。确保任何静态定义的 IP 地址不在分配池之外。有关设置分配池的详情请参考 第 7.2 节 “创建网络环境文件”

8.1. 分配特定的节点 ID

此流程将节点 ID 分配给特定的节点。节点 ID 的示例包括 controller-0controller-1compute-0compute-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 节点的 Swift StorageIP。
  • [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 值替换为值,如 DELETEDUNUSED。不应从 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/serial

9.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 2048

9.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

这个命令使用:

这会生成一个名为 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

例如:

$ 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

9.11. 更新 SSL/TLS 证书

如果您需要在以后更新证书:

  • 编辑 enable-tls.yaml 文件并更新 SSLCertificateSSLKeySSLIntermediateCertificate 参数。
  • 如果您的证书颁发机构已更改,请编辑 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)的堆栈深度。使用以下步骤增加堆栈深度:

  1. 编辑 /etc/heat/heat.conf 并搜索 max_nested_stack_depth 参数。将此参数的值增加到 10

    max_nested_stack_depth = 10

    保存这个文件。

  2. 重启 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 的单节点部署

集中式日志记录单个节点 fluentd

图 12.3. Red Hat OpenStack Platform 的 HA 部署

集中式日志记录 ha fluentd

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 的单节点部署

Monitoring single node sensu

图 12.6. Red Hat OpenStack Platform 的 HA 部署

monitoring ha sensu

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: 24224

SSL 配置示例

## (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.10

12.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 客户端安装

  1. 检查每个 overcloud 节点上的 sensu-client 的状态:

    # systemctl status sensu-client
  2. 检查任何问题的错误日志: /var/log/sensu/sensu-client.log
  3. 验证每个 overcloud 节点具有 /etc/sensu/conf.d/rabbitmq.json 文件,该文件用于设置监控服务器的 IP 地址。

12.6. 检查节点的状态

如果您部署了 Uchiwa 仪表板,您可以将其与 Sensu 服务器一起使用,以检查节点的状态:

  1. 登录 Uchiwa 仪表板,再单击 Data Center 选项卡以确认数据中心是否正常运行。

    http://<SERVER_IP_ADDRESS>/uchiwa
  2. 检查所有 overcloud 节点都处于 Connected 状态。
  3. 在合适的时间,重启其中一个 overcloud 节点,并在 Uchiwa 仪表板中检查重新引导的节点状态。重启完成后,验证节点是否成功重新连接到 Sensu 服务器,并开始执行检查。

12.7. 检查 OpenStack 服务的状态

本例测试 openstack-ceilometer-central 服务的监控。

  1. 确认 openstack-ceilometer-central 服务正在运行:

    systemctl status openstack-ceilometer-central.service
  2. 连接到 Uchiwa 控制面板,并确认 ceilometer JSON 文件中存在并运行成功 ceilometer 检查。
  3. 停止 openstack-ceilometer-central 服务。

    注意

    这可能会破坏服务,因此请在适当的时间运行此测试。

    systemctl stop openstack-ceilometer-central.service
  4. 登录 Uchiwa 控制面板,并确认报告失败的 ceilometer 检查。
  5. 启动 openstack-ceilometer-central 服务:

    systemctl start openstack-ceilometer-central.service
  6. 登录 Uchiwa 仪表板,并查看 ceilometer 检查报告之间的时间间隔,以确认检查的时间间隔在 ceilometer JSON 文件中定义的时间间隔内运行。

第 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-tickets
注意

cipher 集合是一个连续行。

在您的 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. 网络环境选项

表 A.1. 网络环境选项

参数描述示例

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 2 等)而不是命名接口(eth0、eno2 等)时,角色中的 主机的网络接口不必完全相同。例如,一个主机可能具有接口 em1em2,而另一个主机具有 eno1eno2,但您可以将主机的 NIC 指代为 nic1nic2

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

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

编号的 NIC 方案仅考虑实时接口,例如,如果它们有电缆附加到交换机。如果您的主机有四个接口,并且有六个接口,您应该使用 nic1nic4,并且每个主机上仅插入四个电缆。

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.1

B.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.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)

  • 性能受每个数据包的额外解析的影响。
  • vhost-user 锁定争用很有可能。

主动、被动或关闭

balance-tcp (仅限技术预览)

不建议(active-active)

  • 循环需要循环进行 L4 哈希的性能影响。
  • 与 balance-slb 一样,性能会受到每个数据包的额外解析的影响,且可能被 vhost-user 锁定争用。
  • 必须启用 LACP。

主动或被动

您可以使用 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. 绑定选项

下表根据硬件提供了这些选项的一些说明和一些替代方案。

表 D.1. 绑定选项

bond_mode=balance-slb

根据源 MAC 地址和输出 VLAN 平衡流,并在流量模式更改时定期重新平衡。与 balance-slb 绑定允许有限的负载均衡,而无需远程交换机的知识或协作。SLB 将每个源 MAC 和 VLAN 对分配给一个链接,并通过该链接传输来自该 MAC 和 VLAN 的所有数据包。此模式使用基于源 MAC 地址和 VLAN 号的简单哈希算法,并作为流量模式更改定期重新平衡。这个模式与 Linux 绑定驱动程序使用的模式 2 绑定类似。

bond_mode=active-backup

这个模式提供主动/standby 故障转移,在活跃连接失败时待机 NIC 恢复网络操作。物理交换机仅显示一个 MAC 地址。这个模式不需要任何特殊的交换机支持或配置,当链接连接到单独的交换机时可以正常工作。这个模式不提供负载均衡。

lacp=[active|passive|off]

控制链路聚合控制协议(LACP)行为。只有特定的交换机支持 LACP。如果您的交换机不支持 LACP,请使用 bond_mode=balance-slbbond_mode=active-backup

other-config:lacp-fallback-ab=true

设置 LACP 行为,以切换到 bond_mode=active-backup 作为回退。

other_config:lacp-time=[fast|slow]

将 LACP heartbeat 设置为 1 秒(fast)或 30 秒(slow)。默认设置会较慢。

other_config:bond-detect-mode=[miimon|carrier]

将链路检测设置为使用 miimon heartbeats (miimon)或监控载体(carrier)。默认值为 carrier。

other_config:bond-miimon-interval=100

如果使用 miimon,以毫秒为单位设置心跳间隔。

bond_updelay=1000

必须激活链接的毫秒数,以防止流动。

other_config:bond-rebalance-interval=10000

绑定成员之间的重新平衡流间隔的毫秒。设置为 0 以禁用。

法律通告

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