第 6 章为 Overcloud 配置高级的定制环境

本章是第 5 章 配置基本 Overcloud 一章的延续。到目前为止，director 已注册了节点并为 Overcloud 的创建配置了所需的服务。现在，您可以使用本章介绍的方法对 Overcloud 进行定制。

注意

本章中所举的例子是配置 Overcloud 的可选步骤。这些步骤只有在 Overcloud 需要额外功能时才需要进行。请只执行适用于您的环境的步骤。

6.1. 了解 Heat 模板

本章中的自定义配置使用 Heat 模板和环境变量来定义 Overcloud 的特定功能，如网络分离（network isolation）和网络接口配置。本节对 Heat 模板进行了一个基本的介绍，从而使您可以对 Red Hat OpenStack Platform director 中使用的模板结构和格式有所了解。

6.1.1. Heat 模板

director 使用 Heat Orchestration Templates（HOT）作为模板格式来组成 Overcloud 的部署计划。HOT 格式的模板通常使用 YAML 格式。一个模板的目的是创建一个栈（stack），栈中包括了一组资源集合，Heat 会创建并配置每个资源。资源就是 OpenStack 中的对象（object），它包括计算资源、网络配置、安全组、扩展规则和自定义资源。

一个 Heat 模板有以下 3 个主要项：

Parameters（参数） - 一组传递给 heat 的参数，可以被用来自定义一个栈，并设置在没有传递值时相关参数所使用的默认值。这些参数在模板的 parameters 项中定义。
Resources（资源） - 一组作为栈的一部分需要创建和配置的对象。OpenStack 包括一组分布在所有组件中的资源，它们在模板的 resources 项中定义。
Output（输出） - 一组在栈创建后从 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 ] }

这个模板使用资源类型 type: OS::Nova::Server 创建一个名为 my_instance 的实例，它具有特定的 flavor、镜像和关键字。这个栈会返回 instance_name 的值（My Cirros Instance）。

当 Heat 处理一个模板时会为模板创建一个栈，并为资源模板创建一组子栈。这就形成了一个分级结构的栈，它的最高级就是使用您的模板定义的主栈。使用以下命令可以查看栈的分级结构：

$ heat stack-list --show-nested

6.1.2. 环境文件

环境文件就是一个特殊类型的模板，它为 Heat 模板提供了自定义的功能。这个文件包括三个主要部分：

Resource Registry（资源注册表） - 它设置了自定义资源名，并连接到其它 heat 模板。这提供了一个创建没有存在于核心资源集合中的自定义资源的方法。它在环境文件的 resource_registry 项中设置。
Parameters（参数） - 应用到高级别模板参数中的常规设置。例如，您有一个模板用来部署嵌套的栈，如资源注册表映射，这些参数只需要应用于高级别的模板，而不需要在嵌套的栈中进行应用。参数在环境文件中的 parameters 部分进行定义。
Parameter Defaults（参数默认值） - 这些参数会修改所有模板中的参数默认值。例如，您有一个模板用来部署嵌套的栈，如资源注册表映射，参数的默认值会应用到所有模板中。包括高级别的模板以及所有嵌套的资源。参数的默认值在环境文件的 parameter_defaults 项中定义。

重要

在为 Overcloud 创建自定义环境文件时，推荐使用 parameter_defaults 而不是 parameters，这样可以使参数应用到 Overcloud 中的所有模板中。

以下是一个基本环境文件的示例：

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

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1

例如，当通过一个特定 heat 模板（my_template.yaml）创建一个栈时，可以包括这个环境文件（my_env.yaml）。my_env.yaml 文件会创建一个名为 OS::Nova::Server::MyServer 的新资源类型。myserver.yaml 文件是一个 Heat 模板文件，它为这个资源类型提供了一个实施来覆盖内建的设置。您可以在 my_template.yaml 文件中包括 OS::Nova::Server::MyServer 资源。

MyIP 只会对和这个环境文件一起部署的主 Heat 模板应用一个参数。在这个示例中，它只应用于 my_template.yaml 中的参数。

NetworkName 会对主 Heat 模板（在这个示例中是 my_template.yaml），以及与包括在主模板中的资源相关联的模板进行应用（在这个示例中，资源是 OS::Nova::Server::MyServer，模板是 myserver.yaml）。

6.1.3. 核心 Overcloud Heat 模板

director 为 Overcloud 包括了一个核心 Heat 模板集合，它被保存在 /usr/share/openstack-tripleo-heat-templates 中。

这个集合中包括了许多 heat 模板和环境文件。其中需要特别说明的主文件和目录是：

overcloud.yaml - 这是创建 Overcloud 环境所使用的主要模板。
overcloud-resource-registry-puppet.yaml - 这是创建 Overcloud 环境所使用的主要环境文件。它为 Puppet 模块提供了一组存储在 Overcloud 镜像中的配置。当 director 为每个节点写入 Overcloud 镜像后，Heat 将使用在环境文件中注册的资源来为每个节点进行配置。
environments - 一个包括了可以应用到 Overcloud 部署中的环境文件示例的目录。

6.2. 分离网络

director 提供了配置分离 Overcloud 网络的方法。这意味着，Overcloud 环境把不同类型的网络数据分离到不同的网络，从而可以把特定的网络数据分配给特定的网络接口或接口绑定。在配置完分离的网络后，director 会配置 OpenStack 服务来使用分离的网络。如果没有配置分离的网络，所有服务都会在 Provisioning 网络中运行。

在这个示例中，所有的服务都使用独立的网络：

Network 1 - Provisioning
Network 2 - Internal API
Network 3 - Tenant Network
Network 4 - Storage
Network 5 - Storage Management
Network 6 - Management
Network 7 - External 和 Floating IP（在创建 Overcloud 后被映射）

在这个示例中，每个 Overcloud 节点使用两个网络接口组成网络绑定来处理标记 VLAN（tagged VLAN）中的网络。这个绑定使用以下网络设置：

表 6.1. 网络子网和 VLAN 分配

网络类型	子网	VLAN
Internal API	172.16.0.0/24	201
Tenant	172.17.0.0/24	202
Storage	172.18.0.0/24	203
Storage Management	172.19.0.0/24	204
Management	172.20.0.0/24	205
External / Floating IP	10.1.1.0/24	100

如需了解更多网络配置示例，请参阅第 3.2 节 “规划网络”。

6.2.1. 创建自定义接口模板

Overcloud 网络配置需要一组网络接口模板。您可以对这些模板进行定制来基于角色对节点进行配置。这些模板是 YAML 格式的标准 Heat 模板（请参阅第 6.1.1 节 “Heat 模板”）。director 包括了一组模板示例以供参考：

/usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans - 这个目录中包括了基于角色的、带有 VLAN 配置的单独 NIC 的模板。
/usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans - 这个目录中包括了基于角色的、绑定 NIC 配置的模板。
/usr/share/openstack-tripleo-heat-templates/network/config/multiple-nics - 这个目录包括了多 NIC 配置的模板，其中的每个角色都使用一个 NIC。
/usr/share/openstack-tripleo-heat-templates/network/config/single-nic-linux-bridge-vlans - 这个目录中包括了基于角色的、带有 VLAN 配置的单独 NIC 的模板，其中的 VLAN 使用 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 模板，它们为每个角色定义了一个绑定的网络接口配置。每个模板都包括标准的 parameters、resources 和 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 中的绑定。一个绑定会把两个 interfaces 组合在一起来起到冗余和增加带宽的目的。

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

ovs_bridge

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

          - type: ovs_bridge
            name: {get_input: bridge_name}
            members:
              - type: ovs_bond
                name: bond1
                members:
                  - type: interface
                    name: nic2
                    primary: true
                  - type: interface
                    name: nic3
              - type: vlan
                device: bond1
                vlan_id: {get_param: ExternalNetworkVlanID}
                addresses:
                  - ip_netmask: {get_param: ExternalIpSubnet}

linux_bond

定义一个把两个或多个 interfaces 连接到一起的 Linux 绑定。这可以起到冗余和增加带宽的效果。请确定在 bonding_options 参数中包括了基于内核的绑定选项。如需了解更多与 Linux 绑定选项相关的信息，请参阅 Red Hat Enterprise Linux 7 Networking Guide 中的 4.5.1. Bonding Module Directives。

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

linux_bridge

定义一个 Linux 网桥，它把多个 interface、linux_bond 和 vlan 项连接到一起。

            - type: linux_bridge
              name: bridge1
              addresses:
                - ip_netmask:
                    list_join:
                      - '/'
                      - - {get_param: ControlPlaneIp}
                        - {get_param: ControlPlaneSubnetCidr}
              members:
                - type: interface
                  name: nic1
                  primary: true
            - type: vlan
              vlan_id: {get_param: ExternalNetworkVlanID}
              device: bridge1
              addresses:
                - ip_netmask: {get_param: ExternalIpSubnet}
              routes:
                - ip_netmask: 0.0.0.0/0
                  default: true
                  next_hop: {get_param: ExternalInterfaceDefaultRoute}

如需了解更详细的信息，请参阅附录 E, 网络接口参数。

在这个示例中，我们使用默认的绑定节点配置。例如，/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}

注意

Management 网络的配置内容在网络接口 Heat 模板中被注释掉。取消注释这些内容可以启用 Management 网络。

这个模板定义了一个网桥（通常是名为 br-ex 的外部网桥），并创建了一个由两个编号的接口（nic2 和 nic3）组成的一个名为 bond1 的绑定接口。这个网络还包括了一组加标签的 VLAN（tagged VLAN）设备，并使用 bond1 作为父设备。这个模板还包括了一个接口，它被用来连接回 director（nic1）。

附录 F, 网络接口模板示例 中包括了更多网络接口模板示例。

请注意，许多参数使用了 get_param 功能。您可以在一个针对于您的网络所创建的一个环境文件中定义它们。

重要

未使用的接口可能会导致不需要的默认路由和网络循环。例如，您的模板可能会包括一个网络接口（nic4），它不使用任何为 OpenStack 服务分配的 IP，但使用 DHCP 或默认的路由。为了避免网络冲突，从 ovs_bridge 设备中删除所有使用的接口，并禁用 DHCP 和默认路由设置：

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

6.2.2. 创建一个网络环境文件

网络环境文件是一个 Heat 环境文件，它描述了 Overcloud 的网络环境，并指向在前一节中提到的网络接口配置模板。您可以在定义网络 IP 地址范围的同时还定义子网和 VLAN。然后根据本地环境对这些值进行定制。

为了方便用户，director 包括了一组环境文件示例。每个环境文件对应于 /usr/share/openstack-tripleo-heat-templates/network/config/ 中的示例网络接口文件：

/usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml - 在 single-nic-vlans 网络接口目录中的、带有 VLAN 配置的单一 NIC 的环境文件。同时，还包括了用来禁用 External 网络的环境文件（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 配置的环境文件。同时，还包括了用来禁用 External 网络的环境文件（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 - 在 multiple-nics 网络接口目录中的、多 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 配置的环境变量，这个 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 的部分应该包括到每个角色的自定义网络接口模板的链接。相关信息，请参阅第 6.1.2 节 “环境文件”。
parameter_defaults 项应该包括一组参数，它们被用来定义每个网络类型的网络选项。如需获得这些参数的详细信息，请参阅附录 G, 网络环境选项。

例如：

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
  # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"
  # Customize bonding options if required
  BondInterfaceOvsOptions:
    "bond_mode=balance-slb"

它为每个网络定义了选项。所有网络都使用单独的 VLAN，而子网被用来为主机和虚拟 IP 分配 IP 地址。在上面的示例中，Internal API 网络的分配池从 172.16.0.10 开始，直到 172.16.0.200（使用 VLAN 201）。静态 IP 和虚拟 IP 的分配范围从 172.16.0.10 开始，直到 172.16.0.200（使用 VLAN 201）。

External 网络用来运行 Horizon dashboard 和 Public API。如果使用 External 网络进行云管理，以及对浮动 IP 的管理，需要确保有足够的空间容纳一个 IP 池来为虚拟机提供 IP 地址。在这个示例中，为 External 网络分配的 IP 地址范围是从 10.1.1.10 到 10.1.1.50，而从 10.1.1.51 开始的未使用的 IP 地址可以作为浮动 IP 地址使用。或者，把 Floating IP 网络放置到一个独立的 VLAN 中，并在创建 Overcloud 后进行配置来使用它。

BondInterfaceOvsOptions 提供了使用 nic2 和 nic3 组成绑定接口的方法。如需了解更多与绑定选项相关的信息，请参阅附录 H, Open vSwitch 绑定选项。

重要

由于资源可用性的问题，在创建 Overcloud 后改变网络配置可能会出现配置问题。例如，一个用户在网络分离模板中修改了一个网络的子网范围，因为这个资源可能已在使用，重新配置操作会失败。

6.2.3. 把 OpenStack 服务分配到分离的网络

每个 OpenStack 服务都会被分配到资源注册表中的一个默认网络类型。这些服务然后会和网络类型所分配的网络中的一个 IP 地址相绑定。虽然 OpenStack 服务在这些网络中被分开，实际的物理网络数量可能会和网络环境文件中所定义的不同。您可以通过在网络环境文件（/home/stack/templates/network-environment.yaml）中定义一个新的网络映射来把 OpenStack 服务重新分配给不同的网络类型。ServiceNetMap 参数决定了每个服务所使用的网络类型。

例如，您可以通过修改 ServiceNetMap 把 Storage Management 网络服务重新分配给 Storage Network：

parameter_defaults:
  ...
  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: internal_api
    KeystonePublicApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    SwiftMgmtNetwork: storage          # Change from 'storage_mgmt'
    SwiftProxyNetwork: storage
    HorizonNetwork: internal_api
    MemcachedNetwork: internal_api
    RabbitMqNetwork: internal_api
    RedisNetwork: internal_api
    MysqlNetwork: internal_api
    CephClusterNetwork: storage        # Change from 'storage_mgmt'
    CephPublicNetwork: storage
    # Define which network will be used for hostname resolution
    ControllerHostnameResolveNetwork: internal_api
    ComputeHostnameResolveNetwork: internal_api
    BlockStorageHostnameResolveNetwork: internal_api
    ObjectStorageHostnameResolveNetwork: internal_api
    CephStorageHostnameResolveNetwork: storage
    ...

把这些参数改为 storage 会把这些服务放置到 Storage 网络而不是 Storage Management 网络。这意味着，您只需要为 Storage 网络定义一组 parameter_defaults，而不是 Storage Management 网络。

6.2.4. 选择要部署的网络

在一般情况下，环境文件中的 resource_registry 项中的设置不需要修改。如果只需要其中列出的一部分网络，可以对网络列表进行修改。

注意

在指定自定义网络和端口时，不要在部署命令中包括 environments/network-isolation.yaml，而是在网络环境文件中指定所有的网络和端口。

为了使用分离的网络，服务器需要有每个网络上的 IP。您可以在 Undercloud 中使用 neutron 来管理分离网络中的 IP 地址，这需要为每个网络启动 neutron 端口创建。您可以在环境文件中覆盖资源注册表中的设置。

首先是可以被部署的网络和端口的完整列表：

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::* 资源的资源注册信息。在默认情况下，这些资源指向一个 noop.yaml 文件，它不会创建任何网络。通过把这些资源指向相关的 YAML 文件，就可以启用对这些网络的创建。

接下来的几个部分会为每个角色中的节点创建 IP 地址。控制器节点（controller node）有每个网络上的 IP，而计算节点（compute node）和存储节点（storage node）具有网络中相应子网的 IP。

要在没有预配置网络的情况下进行部署，为角色禁用网络定义，以及相关的端口定义。例如，所有到 storage_mgmt.yaml 的指代都需要替换为指代到 noop.yaml：

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/noop.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

  # 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/noop.yaml
  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: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  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: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.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/noop.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/noop.yaml

parameter_defaults:
  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    AodhApiNetwork: internal_api
    GnocchiApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: ctlplane # Admin connection for Undercloud
    KeystonePublicApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    SwiftMgmtNetwork: 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
    CephPublicNetwork: storage
    ControllerHostnameResolveNetwork: internal_api
    ComputeHostnameResolveNetwork: internal_api
    BlockStorageHostnameResolveNetwork: internal_api
    ObjectStorageHostnameResolveNetwork: internal_api
    CephStorageHostnameResolveNetwork: storage

使用 noop.yaml 将不会创建任何网络或端口，因此，Storage Management 网络上的服务会被默认位于 Provisioning 网络中。通过 ServiceNetMap，可以把 Storage Management 服务移到另外一个网络中（如 Storage network）。

6.3. 控制节点的位置

默认情况下，director 为每个角色随机选择节点，通常基于它们的配置集标签（tag）。但是，director 也提供了指定特定节点的功能。它可以实现：

分配特定节点 ID，如 controller-0、controller-1 等
设置自定义的主机名
设置特定的 IP 地址
设置特定的虚拟 IP 地址

6.3.1. 分配特定的节点 ID

这个过程把节点 ID 分配给特定节点。节点 ID 的示例包括 controller-0、controller-1、novacompute-0、novacompute-1 等等。

第一步是，分配 ID 作为每个节点的能力，从而使 Nova 调度程序可以在部署时进行匹配。例如：

ironic node-update <id> replace properties/capabilities='node:controller-0,boot_option:local'

这会把能力 node:controller-0 分配给节点。使用连续的索引值来为所有节点进行分配（以 0 开始）。确定对于一个特定角色（Controller、Compute 以及每个存储角色）的所有节点都以同样形式进行标记（tag），否则 Nova 调度程序将无法正确匹配能力。

下一步是，创建一个 Heat 环境文件（例如，scheduler_hints_env.yaml），它使用调度程序的 hint 来为每个节点匹配能力。例如：

parameter_defaults:
  ControllerSchedulerHints:
    'capabilities:node': 'controller-%index%'

要使用这些调度程序 hint，在进行 Overcloud 创建时在 overcloud deploy command 中包括 scheduler_hints_env.yaml 环境文件。

按照同样的方法，使用以下参数设置每个节点：

ControllerSchedulerHints 用于 Controller 节点。
NovaComputeSchedulerHints 用于 Compute 节点。
BlockStorageSchedulerHints 用于 Block Storage 节点。
ObjectStorageSchedulerHints 用于 Object Storage 节点。
CephStorageSchedulerHints 用于 Ceph Storage 节点。

注意

节点位置的设置会比配置集匹配有更高优先级。为了避免调度失败，在部署时使用 baremetal flavor，而不要使用针对于配置集匹配的 flavor（如 compute、control 等）。例如：

$ openstack overcloud deploy ... --control-flavor baremetal --compute-flavor baremetal ...

6.3.2. 自定义主机名

通过使用第 6.3.1 节 “分配特定的节点 ID” 中介绍的节点 ID 配置，director 可以为每个节点分配一个特定的自定义主机名。如把系统的主机名设置为 rack2-row12 来表示它所在的位置。

为了自定义节点主机名，在环境文件中（如第 6.3.1 节 “分配特定的节点 ID” 中的 scheduler_hints_env.yaml 文件）使用 HostnameMap 参数。例如：

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，使用 HostnameFormat 参数设置 head 定义的原始主机名的映射信息（如 overcloud-controller-0），第二个值是那个节点的自定义主机名（如 overcloud-controller-prod-123-0）。

通过使用这个方法以及节点 ID 的放置功能，每个节点将会有一个自定义主机名。

6.3.3. 分配可预测的 IP

为了可以对环境进行更好的控制，director 可以在每个网络中为 Overcloud 节点分配特定的 IP。使用核心 Heat 模板集合中的 environments/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 地址。每个节点类型都有一个相关的参数：

ControllerIPs 代表 Controller 节点。
NovaComputeIPs 代表 Compute 节点。
CephStorageIPs 代表 Ceph Storage 节点。
BlockStorageIPs 代表 Block Storage 节点。
SwiftStorageIPs 代表 Object Storage 节点。

每个参数就是一个网络名称到地址列表的映射信息。每个网络类型最少具有的地址数量不能少于它们中的节点数量。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 地址位于环境文件中定义的每个网络的地址分配池之外（请参阅第 6.2.2 节 “创建一个网络环境文件”）。例如，确定 internal_api 分配的地址位于 InternalApiAllocationPools 的范围之外，这会避免与每个网络所选 VIP 的冲突。同样，确定分配的 IP 地址与为外部负载平衡环境定义的 VIP 配置没有冲突（请参阅第 6.5 节 “配置外部负载平衡”）。

要在部署过程中应用这个配置，在 openstack overcloud deploy 命令中包括环境文件。如果使用网络隔离（请参阅第 6.2 节 “分离网络”），在这个文件的后面包括 network-isolation.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]

6.3.4. 分配可预测的虚拟 IP

除了为每个节点定义可预测的 IP 地址，director 还可以为集群的服务提供相似的可预测的虚拟 IP（VIP）。要实现这个功能，对第 6.2.2 节 “创建一个网络环境文件” 中的网络环境文件进行如下修改：

在 resource_registry 项中添加一组 OS::TripleO::Network::Ports 资源定义：

resource_registry:
  OS::TripleO::Network::Ports::NetVipMap: /usr/share/openstack-tripleo-heat-templates/network/ports/net_vip_map_external.yaml
  OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/from_service.yaml

这会覆盖主资源注册表中的 VIP 端口定义。

在 parameter_defaults 项中添加 VIP 参数：

parameter_defaults:
  ...
  # Predictable VIPs
  ControlPlaneIP: 192.168.0.230
  ExternalNetworkVip: 10.1.1.190
  InternalApiNetworkVip: 172.16.0.30
  StorageNetworkVip: 172.18.0.30
  StorageMgmtNetworkVip: 172.19.0.40
  ServiceVips:
    redis: 172.16.0.31

重要

如果使用这个功能，需要为所有网络分配一个 VIP。

从它们相关的分配池范围内选择这些 IP。例如，从 InternalApiAllocationPools 范围中选 InternalApiNetworkVip。一个例外是 ControlPlaneIP，您需要从 undercloud.conf 文件所定义的分配范围之外进行选择。

6.4. 配置容器化的 Compute 节点

director 提供了一个选项来把 OpenStack 的容器化项目（kolla）的服务集成到 Overcloud 的 Compute 节点上。这包括使用 Red Hat Enterprise Linux Atomic Host 作为基本操作系统和独立的容器来运行不同 OpenStack 服务的 Compute 节点。

重要

容器化 Compute 节点现在还是一个技术预览（Technology Preview ）。技术预览将不被 Red Hat Subscription Service Level Agreements（SLAs）所完全支持，也不能保证它的所有功能都可以正常运行。Technology Preview 功能并不是为当前的生产环境所提供的，但用户可以通过这些功能来尽早接触将来会被使用的新产品技术，同时可以反馈您的意见来完善产品的开发。如需了解更多与对技术预览的支持相关的信息，请参阅 https://access.redhat.com/support/offerings/techpreview/。

director 的核心 Heat 模板集合包括环境文件来帮助配置容器化的 Compute 节点。这些文件包括：

docker.yaml - 配置容器化 Compute 节点的主要环境文件。
docker-network.yaml - 没有网络隔离的容器化 Compute 节点网络的环境文件。
docker-network-isolation.yaml - 使用网络隔离的容器化 Compute 节点的环境文件。

6.4.1. 容器化 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

提供一组 Compute 节点的后配置资源的 Heat 模板。这包括了一个软件配置资源，它为 Puppet 提供了一组 tags：

  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

这些 tag 定义了要传递给 openstack-heat-docker-agents 容器的 Puppet 模板。

docker.yaml 文件包括了一个名为 NovaImage 的 parameter，它会在配置 Compute 节点时使用一个不同的镜像（atomic-image）替换标准的 overcloud-full 镜像。第 6.4.2 节 “上传 Atomic Host 镜像” 介绍了上传这个新镜像的方法。

docker.yaml 文件还包括了一个 parameter_defaults 部分，它定义了 Docker 的注册表以及 Compute 节点服务要使用的镜像。您可以修改这个部分来使用本地的注册表，而不使用默认的 registry.access.redhat.com。如需了解配置一个本地注册表的信息，请参阅第 6.4.3 节 “使用本地注册表”。

6.4.2. 上传 Atomic Host 镜像

director 需要把一个 Red Hat Enterprise Linux 7 Atomic Host 的云镜像（Cloud Image）导入到它的镜像存储中（atomic-image）。这是因为，在 Overcloud 创建的 provisioning 阶段，Compute 节点需要这个镜像作为基础 OS。

从 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）中下载 Cloud Image，把它保存到 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 |
+--------------------------------------+------------------------+

6.4.3. 使用本地注册表

默认的设置是使用红帽的容器注册表来进行镜像下载。但是，为了节省带宽，也可以在 Overcloud 的创建过程中使用一个本地的注册表。

您可以选择使用一个存在的本地注册表，或安装一个新的本地注册表。要安装一个新的注册表，请参阅 Getting Started with Containers 文档中的 Chapter 2. Get Started with Docker Formatted Container Images。

把所需的所有镜像导入到注册表中：

$ sudo docker pull registry.access.redhat.com/rhosp9_tech_preview/openstack-nova-compute:latest
$ sudo docker pull registry.access.redhat.com/rhosp9_tech_preview/openstack-data:latest
$ sudo docker pull registry.access.redhat.com/rhosp9_tech_preview/openstack-nova-libvirt:latest
$ sudo docker pull registry.access.redhat.com/rhosp9_tech_preview/openstack-neutron-openvswitch-agent:latest
$ sudo docker pull registry.access.redhat.com/rhosp9_tech_preview/openstack-openvswitch-vswitchd:latest
$ sudo docker pull registry.access.redhat.com/rhosp9_tech_preview/openstack-openvswitch-db-server:latest
$ sudo docker pull registry.access.redhat.com/rhosp9_tech_preview/openstack-heat-docker-agents:latest

在获得镜像后，把它们标记到适当的注册表主机：

$ sudo docker tag registry.access.redhat.com/rhosp9_tech_preview/openstack-nova-compute:latest localhost:8787/registry.access.redhat.com/openstack-nova-compute:latest
$ sudo docker tag registry.access.redhat.com/rhosp9_tech_preview/openstack-data:latest localhost:8787/registry.access.redhat.com/openstack-data:latest
$ sudo docker tag registry.access.redhat.com/rhosp9_tech_preview/openstack-nova-libvirt:latest localhost:8787/registry.access.redhat.com/openstack-nova-libvirt:latest
$ sudo docker tag registry.access.redhat.com/rhosp9_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/rhosp9_tech_preview/openstack-openvswitch-vswitchd:latest localhost:8787/registry.access.redhat.com/openstack-openvswitch-vswitchd:latest
$ sudo docker tag registry.access.redhat.com/rhosp9_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/rhosp9_tech_preview/openstack-heat-docker-agents:latest localhost:8787/registry.access.redhat.com/openstack-heat-docker-agents:latest

把它们推到注则表：

$ 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 设置为您的注册表的 URL。另外，还需要把 DockerNamespaceIsRegistry 设置为 true。例如：

parameter_defaults:
  DockerNamespace: registry.example.com:8787/registry.access.redhat.com
  DockerNamespaceIsRegistry: true

现在，本地的注册表包括了所需的 docker 镜像，容器化的 Compute 现在被设置为使用这个注册表。

6.4.4. 在 Overcloud 部署中包括环境文件

在运行 Overcloud 创建命令时，在 openstack overcloud deploy 命令中包括容器化 Compute 节点的主环境文件（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）。在第 6.2 节 “分离网络” 介绍的网络分离文件前添加这些文件。例如：

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。

6.5. 配置外部负载平衡

一个 Overcloud 会使用多个 Controller 来组成一个高可用性集群，从而确保 OpenStack 服务获得最大的操作性能。另外，集群还可以实现对 OpenStack 服务访问的负载平衡（在各个 Controller 节点间平衡分配访问操作，减少每个节点的服务器负载）。这个功能也可以通过使用一个外部的负载平衡系统来实现。例如，一个机构可以选择使用自己的、基于硬件的负载平衡系统来在 Controller 节点间分配访问流量。

如需了解更多配置外部负载平衡系统的信息，请参阅 External Load Balancing for the Overcloud。

6.6. 配置 IPv6 网络

默认情况下，Overcloud 使用 IPv4 来配置服务端点（endpoint）。但是，Overcloud 同样支持 IPv6 端点，这一点对支持 IPv6 基础架构的机构会非常有用。director 包括了一组环境文件来帮助创建基于 IPv6 的 Overcloud。

如需了解更多在 Overcloud 中配置 IPv6 的信息，请参阅 IPv6 Networking for the Overcloud。

6.7. 配置 NFS 存储

本节介绍了配置 Overcloud 来使用 NFS 共享的方法。整个安装和配置的过程基于对核心 Heat 模板中的一个环境文件的修改。

在 /usr/share/openstack-tripleo-heat-templates/environments/ 中，核心 heat 模板集合包括了一组环境文件。这些环境文件可以帮助对由 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 临时存储（ephemeral storage）启用 Ceph 存储。把它设置为 false。
GlanceBackend: 定义 Glance 的后端。把它设为 file 来为镜像使用基于文件的存储。Overcloud 会为 Glance 在一个挂载的 NFS 共享中存储这些文件。
CinderNfsMountOptions: 卷存储的 NFS 挂载选项。
CinderNfsServers: 为卷共享挂载的 NFS 共享。例如，192.168.122.1:/export/cinder。
GlanceFilePcmkManage: 为镜像存储启用 Pacemaker 来管理共享。如果被禁用，Overcloud 会把镜像存储在 Controller 节点的文件系统中。把它设置为 true。
GlanceFilePcmkFstype: 定义 Pacemaker 用来进行镜像存储的文件系统类型。把它设为 nfs。
GlanceFilePcmkDevice: 挂载的、用于镜像存储的 NFS 共享。例如：192.168.122.1:/export/glance。
GlanceFilePcmkOptions: 用于镜像存储的 NFS 挂载选项。

环境文件的选项应该和以下类似：

parameter_defaults:
  CinderEnableIscsiBackend: false
  CinderEnableRbdBackend: false
  CinderEnableNfsBackend: true
  NovaEnableRbdBackend: false
  GlanceBackend: 'file'

  CinderNfsMountOptions: 'rw,sync'
  CinderNfsServers: '192.0.2.230:/cinder'

  GlanceFilePcmkManage: true
  GlanceFilePcmkFstype: 'nfs'
  GlanceFilePcmkDevice: '192.0.2.230:/glance'
  GlanceFilePcmkOptions: 'rw,sync,context=system_u:object_r:glance_var_lib_t:s0'

重要

在 GlanceFilePcmkOptions 参数中包括 context=system_u:object_r:glance_var_lib_t:s0 允许 glance 访问 /var/lib 目录。如果没有这个 SELinux 设置，glance 将无法写挂载点。

这些参数被集成在一起作为 heat 模板集合的一部分。这样设置它们会创建两个 cinder 和 glance 使用的 NFS 挂载点。

保存这个文件。

6.8. 配置 Ceph 存储

director 提供了两个主要的方法把 Red Hat Ceph Storage 集成到 Overcloud。

创建一个带有自己的 Ceph Storage Cluster 的 Overcloud: director 在创建 Overcloud 时可以创建一个 Ceph Storage Cluster。director 会创建一组使用 Ceph OSD 来存储数据的 Ceph Storage 节点。另外，director 还会在 Overcloud 的 Controller 节点上安装 Ceph Monitor 服务。这意味着，如果创建了一个带有 3 个高可用性 controller 节点的 Overcloud，Ceph Monitor 服务也会成为高可用性服务。
把一个已存在的 Ceph Storage 集成到 Overcloud: 如果您已有一个 Ceph Storage Cluster，则可以在部署 Overcloud 的时候把它集成到 Overcloud。这意味着，您可以管理和扩展 Overcloud 配置以外的集群。

如需了解更多相关信息，请参阅 Red Hat Ceph Storage for the Overcloud 中的相关内容。

6.9. 配置第三方存储

director 包括了一些环境文件来帮助配置第三方存储供应商。这包括：

Dell Storage Center

部署一个单一的 Dell Storage Center 后台作为 Block Storage（cinder）服务。

环境文件位于 /usr/share/openstack-tripleo-heat-templates/environments/cinder-eqlx-config.yaml。

如需了解更详细的配置信息，请参阅 Dell Storage Center Back End Guide。

Dell EqualLogic

部署一个单独的 Dell EqualLogic 后台作为 Block Storage（cinder）服务。

环境文件位于 /usr/share/openstack-tripleo-heat-templates/environments/cinder-eqlx-config.yaml。

如需了解更详细的配置信息，请参阅 Dell EqualLogic Back End Guide。

NetApp Block Storage

部署一个 NetApp storage appliance 作为 Block Storage（cinder）服务的后端。

环境文件位于 /usr/share/openstack-tripleo-heat-templates/environments/cinder-dellsc-config.yaml/cinder-netapp-config.yaml。

如需了解详细的配置信息，请参阅 NetApp Block Storage Back End Guide。

6.10. 在 Overcloud 中启用 SSL/TLS

默认情况下，Overcloud 使用未加密的端点（endpoints）提供相关的服务。因此，Overcloud 的配置需要一个额外的环境文件来为它的 Public API 端点启用 SSL/TLS。

注意

这个过程只为 Public API 端点启用 SSL/TLS。Internal API 和 Admin API 仍然没有加密。

这个过程需要网络分离来为 Public API 定义端点。如需了解与网络分离相关的信息，请参阅第 6.2 节 “分离网络”。

请确认已有一个私人密钥并创建了证书认证机构（CA）。如需了解更多与创建 SSL/TLS 密钥和证书认证机构文件的信息，请参阅附录 A, SSL/TLS 证书配置。

6.10.1. 启用 SSL/TLS

从 Heat 模板集合中复制 enable-tls.yaml 环境文件：

$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/enable-tls.yaml ~/templates/.

编辑这个文件，对以下参数进行修改：

SSL证书

把证书文件的内容复制到 SSLCertificate 参数中。例如：

parameter_defaults:
  SSLCertificate: |
    -----BEGIN CERTIFICATE-----
    MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV
    ...
    sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp
    -----END CERTIFICATE-----

重要

证书授权内容中的所有新行都需要有相同的行缩进。

SSL 密钥

把私人密钥的内容复制到 SSLKey 参数。例如：

parameter_defaults:
  ...
  SSLKey: |
    -----BEGIN RSA PRIVATE KEY-----
    MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO9hkJZnGP6qb6wtYUoy1bVP7
    ...
    ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4XpZUC7yhqPaU
    -----END RSA PRIVATE KEY-----

重要

私人密钥的内容中的所有新行都需要有相同的行缩进。

EndpointMap

EndpointMap 包括了使用 HTTPS 和 HTTP 的服务的映射信息。如果 SSL 使用 DNS，不要修改这个部分的默认设置。但是，如果使用一个 IP 地址作为 SSL 证书的常规名（请参阅附录 A, SSL/TLS 证书配置），使用 IP_ADDRESS 替换所有 CLOUDNAME 实例。运行以下命令：

$ sed -i 's/CLOUDNAME/IP_ADDRESS/' ~/templates/enable-tls.yaml

重要

不要使用实际的值替换 IP_ADDRESS 和 CLOUDNAME，Heat 会在 Overcloud 创建的过程中替换这些变量。

OS::TripleO::NodeTLSData

把 OS::TripleO::NodeTLSData: 的资源路径改为一个绝对路径：

resource_registry:
  OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml

6.10.2. 注入一个 Root 证书

如果证书的签发者不在 Overcloud 镜像中的默认的 trust store 中，则需要把证书“注入”到 Overcloud 镜像中。从 heat 模板集合中复制 inject-trust-anchor.yaml 环境文件：

$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/inject-trust-anchor.yaml ~/templates/.

编辑这个文件，对以下参数进行修改：

SSLRootCertificate

把 root 证书授权文件的内容复制到 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

6.10.3. 配置 DNS 端点

如果使用 DNS 主机名通过 SSL/TLS 来访问 Overcloud，创建一个新环境文件（~/templates/cloudname.yaml）来定义 Overcloud 端点的主机名。使用以下参数：

CloudName: Overcloud 端点的 DNS 主机名。
DnsServers: 使用的 DNS 服务器列表。配置的 DNS 服务器需要包括一个配置的 CloudName 的项，它需要和 Public API 的 IP 地址相匹配。

以下是这个文件的一个示例：

parameter_defaults:
  CloudName: overcloud.example.com
  DnsServers: ["10.0.0.1"]

6.10.4. 在 Overcloud 创建期间添加环境文件

在第 7 章 创建 Overcloud 中介绍的部署命令（openstack overcloud deploy）中使用 -e 选项来添加环境文件。使用以下顺序在这个部分添加环境文件：

启用 SSL/TLS 的环境文件（enable-tls.yaml）
设置 DNS 主机名的环境文件（cloudname.yaml）
注入 root 证书授权的环境文件（inject-trust-anchor.yaml）

例如：

$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml

6.11. 配置基础参数

Overcloud 的 Heat 模板包括了一组基础参数，您可以在运行 openstack overcloud deploy 命令前配置它们。把这些基础参数包括在一个环境文件的 parameter_defaults 项中，并在 openstack overcloud deploy 命令中使用这个环境文件。

如需了解 Overcloud 基础参数的完整列表，请参阅附录 D, 基础参数 。

示例 1：配置时区

在环境文件中把时区设置为 Japan：

parameter_defaults:
  TimeZone: 'Japan'

示例 2：禁用第 3 层高可用性（L3HA）

如果需要为 OpenStack Networking 禁用第 3 层高可用性功能（L3HA），把以下内容添加到环境文件中：

parameter_defaults:
  NeutronL3HA: False

示例 3：配置 Telemetry Dispatcher

OpenStack Telemetry（ceilometer）服务包括了一个时间序列数据存储的新组件（gnocchi）。现在，可以在 Red Hat OpenStack Platform 中把默认的 Ceilometer dispatcher 切换为使用新组件，而不是使用标准的数据库。这个设置是通过 CeilometerMeterDispatcher 实现的，您可以把它设置为以下之一：

database - 为 Ceilometer dispatcher 使用标准数据库。这是默认选项。
gnocchi - 为 Ceilometer dispatcher 使用新的时间序列数据库。

要切换为使用时间序列数据库，在环境文件中添加以下内容：

parameter_defaults:
  CeilometerMeterDispatcher: gnocchi

示例 4：配置 RabbitMQ File Descriptor Limit

在特定配置中，您可能需要为 RabbitMQ 服务器提高文件描述符（file descriptor）的数量限制。根据需要，为 RabbitFDLimit 参数设置适当的值：

parameter_defaults:
  RabbitFDLimit: 65536

6.12. 注册 Overcloud

Overcloud 提供了把节点注册到 Red Hat Content Delivery Network、Red Hat Satellite 5 server 或 Red Hat Satellite 6 server 的方法。您可以选择使用环境变量实现它，也可以使用命令行来实现。

6.12.1. 方法 1：命令行

部署命令（openstack overcloud deploy）使用一组选项来定义您的注册详情。第 7.1 节 “设置 Overcloud 参数” 中的表格包括了这些选项以及它们的描述信息。使用第 7 章 创建 Overcloud 中的部署命令时包括这些选项，例如：

# openstack overcloud deploy --templates --rhel-reg --reg-method satellite --reg-sat-url http://example.satellite.com  --reg-org MyOrg --reg-activation-key MyKey --reg-force [...]

6.12.2. 方法 2 - 环境文件

从 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: 选择注册方法。可以是 portal、satellite 或 disable。
rhel_reg_type: 注册的单元类型。如果注册为一个 system，把它设为空
rhel_reg_auto_attach: 为系统自动附加兼容的订阅。如需启用这个功能，把它设置为 true。
rhel_reg_service_level: 自动附加所使用的服务级别。
rhel_reg_release: 使用这个参数来为自动附加设置发行版本。如果设置为空，则使用从 Red Hat Subscription Manager 获得的默认值。
rhel_reg_pool_id: 使用的订阅池 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: 订阅服务使用的主机名。默认是 Customer Portal Subscription Management（subscription.rhn.redhat.com）。如果这个选项没有被使用，系统会使用 Customer Portal Subscription Management 进行注册。订阅服务器 URL 的格式是 https://hostname:port/prefix。
rhel_reg_base_url: 获得系统更新的内容服务器的主机名，它的默认值是 https://cdn.redhat.com。因为 Satellite 6 主机有它自己的内容，注册到 Satellite 6 的系统需要在这个参数中指定 URL。基本 URL 的格式是 https://hostname:port/prefix。
rhel_reg_org: 注册的机构
rhel_reg_environment: 在所选机构内使用的环境
rhel_reg_repos: 以逗号分隔的软件仓库列表。如需了解更详细的信息，请参阅第 2.5 节 “软件仓库的要求”。
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）的仓库。例如，rhel-7-server-satellite-tools-6.1-rpms。

在第 7 章 创建 Overcloud 中介绍的部署命令（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 资源。这意味着，您只能使用这个资源进行注册。如需了解更多信息，请参阅第 6.14 节 “自定义 Overcloud 的预配置”。

6.13. 自定义第一次引导的配置

director 提供了一个在初始创建 Overcloud 时在所有节点上进行配置操作的机制。director 使用 cloud-init，您可以使用 OS::TripleO::NodeUserData 资源类型调用它。

在这个示例中，您需要在所有节点上更新域名解析服务器来使用一个自定义的 IP 地址。首先，创建一个基本的 heat 模板（/home/stack/templates/nameserver.yaml），它运行一个脚本来为每个节点的 resolv.conf 添加一个特定的名称解析服务器（nameserver）。使用 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 模板。

6.14. 自定义 Overcloud 的预配置

Overcloud 使用 Puppet 进行 OpenStack 组件的核心配置。director 提供了一组在第一次引导完成后，核心配置开始前，提供自定义配置的资源。这些资源包括：

OS::TripleO::ControllerExtraConfigPre: 在核心 Puppet 配置前，应用到 Controller 节点上的额外配置。
OS::TripleO::ComputeExtraConfigPre: 在核心 Puppet 配置前，应用到 Controller 节点上的额外配置。
OS::TripleO::CephStorageExtraConfigPre: 在核心 Puppet 配置前，应用到 CephStorage 节点上的额外配置。
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

resources:
  ExtraPreConfig:
    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}
  ExtraPreDeployment:
    type: OS::Heat::SoftwareDeployment
    properties:
      config: {get_resource: ExtraPreConfig}
      server: {get_param: server}
      actions: ['CREATE','UPDATE']

outputs:
  deploy_stdout:
    description: Deployment reference, used to trigger pre-deploy on changes
    value: {get_attr: [ExtraPreDeployment, deploy_stdout]}

重要

server 参数是应用配置的服务器列表，它由父模板提供。这个参数在所有预配置模板中都是必需的。

接下来，创建一个环境文件（/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

这会在初始创建的主配置开始前，或以后的更新过程的主配置开始前，在所有节点中应用配置。

重要

您可以只把这些资源注册到一个 Heat 模板。以后的使用会覆盖 heat 模板来使用每个资源。

6.15. Overcloud 创建后的自定义配置

在创建完 Overcloud 后，您可能需要在初始创建时，或以后对 Overcloud 进行更新时添加以下额外的配置。在这种情况下，您可以使用 OS::TripleO::NodeExtraConfigPost 资源来应用使用标准的 OS::Heat::SoftwareConfig 类型的配置。这会在主 Overcloud 配置完成后应用额外的配置。

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  servers:
    type: json
  nameserver_ip:
    type: string

resources:
  ExtraConfig:
    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}

  ExtraDeployments:
    type: OS::Heat::SoftwareDeployments
    properties:
      servers:  {get_param: servers}
      config: {get_resource: ExtraConfig}
      actions: ['CREATE','UPDATE']

重要

servers 参数是应用配置的服务器列表，它由父模板提供。这个参数在所有 OS::TripleO::NodeExtraConfigPost 模板中都是必需的。

接下来，创建一个环境文件（/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

这会在初始创建的主配置完成后，或以后的更新过程的主配置完成后，在所有节点中应用配置。

重要

您可以只把 OS::TripleO::NodeExtraConfigPost 注册到一个 heat 模板。随后的使用会覆盖 heat 模板。

6.16. 自定义 Puppet 配置数据

Heat 模板集合包括一组参数来把额外的配置传递到特定的节点类型。这些参数把相关的配置保存为 hieradata 来作为节点的 Puppet 配置。这些参数包括：

ExtraConfig: 添加到所有节点的配置
controllerExtraConfig: 添加到所有 Controller 节点的配置。
NovaComputeExtraConfig: 添加到所有 Compute 节点的配置。
BlockStorageExtraConfig: 添加到所有 Block Storage 节点的配置。
ObjectStorageExtraConfig: 添加到所有 Object Storage 节点的配置。
CephStorageExtraConfig: 添加到所有 Ceph Storage 节点的配置。

为了把额外的配置添加到部署后的配置过程中，创建一个在 parameter_defaults 的部分中包括这些参数的环境文件。例如，把 Compute 主机的保留内存增加到 1024 MB，把 VNC 的键盘输入设置为日语：

parameter_defaults:
  NovaComputeExtraConfig:
    nova::compute::reserved_host_memory: 1024
    nova::compute::vnc_keymap: ja

在运行 openstack overcloud deploy 时包括这个环境文件。

重要

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

6.17. 应用自定义 Puppet 配置

在特定情况下，您可能会需要在 Overcloud 节点上安装并配置一些额外的组件。您可以通过在主配置完成后，在节点上应用一个自定义 Puppet manifest 来达到这个目的。作为一个基本的例子，您可以在每个节点上安装 motd。这会首先创建一个 Heat 模板（/home/stack/templates/custom_puppet_config.yaml）来启动 Puppet 配置。

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::SoftwareDeployments
    properties:
      config: {get_resource: ExtraPuppetConfig}
      servers: {get_param: servers}

这会在模板内包括 /home/stack/templates/motd.pp，并把它传递给节点进行配置。motd.pp 文件本身包括了我们的 Puppet 类来进行安装和配置 motd。

接下来，创建一个环境文件（/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 的所有节点上。

6.18. 使用定制的核心 Heat 模板

在创建 Overcloud 时，director 会使用一组核心的 heat 模板。您可以把这些标准的 heat 模板复制到一个本地目录中，使用这些模板来创建您自己的 Overcloud。

把 /usr/share/openstack-tripleo-heat-templates 中的 heat 模板复制到 stack 用户的模板目录中：

$ cp -r /usr/share/openstack-tripleo-heat-templates ~/templates/my-overcloud

这会创建 Overcloud Heat 模板的一个克隆。在运行 openstack overcloud deploy 时，我们使用了 --templates 选项来指定本地的模板目录。请参阅第 7 章 创建 Overcloud。

注意

如果没有为 --templates 选项设置值，director 会使用默认的模板目录（/usr/share/openstack-tripleo-heat-templates）。

重要

红帽会在后续的发行版本中提供对 heat 模板的更新。使用一个经过修改过的模板集合会造成您的定制版本和位于 /usr/share/openstack-tripleo-heat-templates 中的原始版本的不同。红帽推荐使用以下章节中介绍的方法来进行配置，而不是直接修改 heat 模板集合：

在创建 heat 模板集合的一个副本时，您需要使用一个版本控制工具（如 git）来记录对模板的改变。

Where did the comment section go?

Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.

第 6 章 为 Overcloud 配置高级的定制环境

6.1. 了解 Heat 模板

6.1.1. Heat 模板

6.1.2. 环境文件

6.1.3. 核心 Overcloud Heat 模板

6.2. 分离网络

6.2.1. 创建自定义接口模板

6.2.2. 创建一个网络环境文件

6.2.3. 把 OpenStack 服务分配到分离的网络

6.2.4. 选择要部署的网络

6.3. 控制节点的位置

6.3.1. 分配特定的节点 ID

6.3.2. 自定义主机名

6.3.3. 分配可预测的 IP

6.3.4. 分配可预测的虚拟 IP

6.4. 配置容器化的 Compute 节点

6.4.1. 容器化 Compute 环境文件（docker.yaml）

6.4.2. 上传 Atomic Host 镜像

6.4.3. 使用本地注册表

6.4.4. 在 Overcloud 部署中包括环境文件

6.5. 配置外部负载平衡

6.6. 配置 IPv6 网络

6.7. 配置 NFS 存储

6.8. 配置 Ceph 存储

6.9. 配置第三方存储

6.10. 在 Overcloud 中启用 SSL/TLS

6.10.1. 启用 SSL/TLS

6.10.2. 注入一个 Root 证书

6.10.3. 配置 DNS 端点

6.10.4. 在 Overcloud 创建期间添加环境文件

6.11. 配置基础参数

6.12. 注册 Overcloud

6.12.1. 方法 1：命令行

6.12.2. 方法 2 - 环境文件

6.13. 自定义第一次引导的配置

6.14. 自定义 Overcloud 的预配置

6.15. Overcloud 创建后的自定义配置

6.16. 自定义 Puppet 配置数据

6.17. 应用自定义 Puppet 配置

6.18. 使用定制的核心 Heat 模板

Where did the comment section go?

第 6 章为 Overcloud 配置高级的定制环境