高级 Overcloud 自定义

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

Heat 模板有三个主要部分：

以下是基本 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

环境文件是特殊的模板，可为您的 heat 模板提供自定义。这包括三个关键部分：

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 模板。

director 包含 Overcloud 的核心 heat 模板集合。此集合保存在 /usr/share/openstack-tripleo-heat-templates 中。

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

计划环境元数据文件允许您定义 overcloud 计划的元数据。此信息用于导入和导出 overcloud 计划，并在您的计划创建 overcloud 期间使用。

计划环境元数据文件包括以下参数：

以下是计划环境文件的语法示例：

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

您可以使用 -p 选项通过 openstack overcloud deploy 命令包含计划环境文件。例如：

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

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

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

capabilities map 提供规划及其依赖项中的环境文件映射。使用此文件通过 director 的 Web UI 描述和启用环境文件。在 overcloud 计划中检测到的自定义环境文件，但没有列在 capabilities-map.yaml 中，它们列在 其他 子选项卡中的 2 子选项卡中。指定 web UI 上的 Deployment Configuration > Overall Settings。

默认文件位于 /usr/share/openstack-tripleo-heat-templates/capabilities-map.yaml。

以下是功能映射的语法示例：

topics: 1
  - title: My Parent Section
    description: This contains a main section for different environment files
    environment_groups: 2
      - name: my-environment-group
        title: My Environment Group
        description: A list of environment files grouped together
        environments: 3
          - file: environment_file_1.yaml
            title: Environment File 1
            description: Enables environment file 1
            requires: 4
              - dependent_environment_file.yaml
          - file: environment_file_2.yaml
            title: Environment File 2
            description: Enables environment file 2
            requires: 5
              - dependent_environment_file.yaml
          - file: dependent_environment_file.yaml
            title: Dependent Environment File
            description: Enables the dependent environment file

部署命令(openstack overcloud deploy)使用 -e 选项包括环境文件来自定义 Overcloud。您可以根据需要纳入多个环境文件。但是，环境文件的顺序非常重要，因为后续环境文件中定义的参数和资源更为优先。例如，您可能有两个环境文件：

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

parameter_defaults:
  RabbitFDLimit: 65536
  TimeZone: 'Japan'

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 命令通过以下进程运行：

这会对 Overcloud 的默认配置进行以下更改：

这提供了一种从多个环境文件冲突地定义自定义配置到 Overcloud 的方法。

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

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

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

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

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

如果 git 在 rebase 期间报告任何冲突，请使用以下步骤：

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

支持 Jinja2 的 Heat 模板使用 Jinja2 语法为迭代值创建参数和资源。例如，overcloud.j2.yaml 文件包含以下代码片段：

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

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

参数渲染版本示例如下：

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

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

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

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

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

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

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

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

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

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

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

要获取时区列表，请运行 timedatectl list-timezones 命令。以下示例命令检索亚洲的时区：

$ sudo timedatectl list-timezones|grep "Asia"

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

parameter_defaults:
  TimeZone: 'Asia/Tokyo'

OpenStack Networking (neutron) API 的 Heat 模板(puppet/services/neutron-api.yaml)包含一个参数，用于启用和禁用分布式虚拟路由(DVR)。参数的默认值为 false。但是，您可以在环境文件中使用以下内容启用它：

parameter_defaults:
  NeutronEnableDVR: true

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

parameter_defaults:
  RabbitFDLimit: 65536

在某些情况下，您可能需要首先在部署期间设置参数，然后为将来的部署操作禁用 参数，如更新或扩展操作。例如，要在 overcloud 创建过程中包括自定义 RPM，您需要包括以下内容：

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

如果您需要从将来的部署中禁用这个参数，则它不足以移除该参数。相反，您要将参数设置为空值：

parameter_defaults:
  DeployArtifactURLs: []

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

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

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

parameter_defaults:
  ControllerParameters:
    LogrotateMaxsize: 10M
    LogrotatePurgeAfterDays: 30
  ComputeParameters:
    LogrotateMaxsize: 20M
    LogrotatePurgeAfterDays: 15

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

下表显示了最终映射：

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

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 堆栈。

Overcloud 使用 Puppet 作为 OpenStack 组件的核心配置。director 提供了一组 hook，用于在第一次引导完成并开始核心配置前为特定节点角色提供自定义配置。这些 hook 包括：

在本例中，您首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml)，它将运行一个脚本来写入具有变量名称服务器的节点的 resolv.conf。

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  server:
    type: string
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string

resources:
  CustomExtraConfigPre:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" > /etc/resolv.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  CustomExtraDeploymentPre:
    type: OS::Heat::SoftwareDeployment
    properties:
      server: {get_param: server}
      config: {get_resource: CustomExtraConfigPre}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

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

在本例中，Resources 部分包含以下内容：

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

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

在本例中，您首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml)，它将运行一个脚本，将每个节点的 resolv.conf 附加到变量名称服务器。

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  server:
    type: string
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string

resources:
  CustomExtraConfigPre:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  CustomExtraDeploymentPre:
    type: OS::Heat::SoftwareDeployment
    properties:
      server: {get_param: server}
      config: {get_resource: CustomExtraConfigPre}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

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

在本例中，Resources 部分包含以下内容：

接下来，创建一个环境文件(/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 创建或后续更新时，将配置应用到所有节点。

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

在本例中，您首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml)，它将运行一个脚本，将每个节点的 resolv.conf 附加到变量名称服务器。

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}

在本例中，Resources 部分包含以下内容：

接下来，创建一个环境文件(/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 创建或后续更新上完成核心配置后，将配置应用到所有节点。

Heat 模板集合包含一组参数，用于将额外配置传递给某些节点类型。这些参数将配置保存为节点的 Puppet 配置的 hieradata。这些参数：

要在部署后配置过程中添加额外的配置，请在 parameter_defaults 部分中创建一个包含这些参数的环境文件。例如，要将 Compute 主机保留的内存增加到 1024 MB，并将 VNC 键映射设置为日语：

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

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

您可以使用 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-95C6928C407F 接收 hieradata 的 Compute 节点。

这提供了一种根据特定要求定制每个节点的方法。

如需有关 NodeDataLookup 的更多信息，请参阅使用容器化 Red Hat Ceph 部署 Overcloud 指南中的配置 Ceph Storage 集群设置。

在某些情况下，您可能需要为 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.ppp 的配置应用到 Overcloud 中的所有节点。

从 Heat 模板集合中复制注册文件：

$ cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration ~/templates/.

编辑 ~/templates/rhel-registration/environment-rhel-registration.yaml 文件，并更改适用于您的注册方法和详情的参数值。

部署命令(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

以下使用 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-13-rpms,rhel-7-server-rhceph-3-osd-rpms,rhel-7-server-rhceph-3-mon-rpms,rhel-7-server-rhceph-3-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: ""
  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: ""

以下将 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: ""
  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: ""

以下将 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: ""
  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: ""

以下示例参数为您的所需注册方法设置 HTTP 代理设置：

parameter_defaults:
  ...
  rhel_reg_http_proxy_host: "proxy.example.com"
  rhel_reg_http_proxy_port: "8080"
  rhel_reg_http_proxy_username: "proxyuser"
  rhel_reg_http_proxy_password: "p@55w0rd!"
  ...

在某些情况下，您可能想要将不同的角色注册到不同的订阅类型。例如，您可能只将 Controller 节点订阅到 OpenStack Platform 订阅，并将 Ceph Storage 节点订阅到 Ceph Storage 订阅。本节提供了一些高级注册方法，以帮助为不同的角色分配单独的订阅。

ControllerRegistrationConfig:
  type: OS::Heat::SoftwareConfig
  properties:
    group: script
    config: |
      #!/bin/sh
      sudo subscription-manager register --org 1234567 \
        --activationkey "my-openstack"
      sudo subscription-manager attach --pool 1a85f9223e3d5e43013e3d6e8ff506fd
      sudo subscription-manager repos --enable rhel-7-server-rpms \
        --enable rhel-7-server-extras-rpms \
        --enable rhel-7-server-rh-common-rpms \
        --enable rhel-ha-for-rhel-7-server-rpms \
        --enable rhel-7-server-openstack-13-rpms \
        --enable rhel-7-server-rhceph-3-mon-rpms

ControllerRegistrationDeployment:
  type: OS::Heat::SoftwareDeployment
  properties:
    server: {get_param: server}
    config: {get_resource: ControllerRegistrationConfig}
    actions: ['CREATE','UPDATE']
    input_values:
      deploy_identifier: {get_param: DeployIdentifier}

该脚本使用一组 subscription-manager 命令来注册系统，附加订阅并启用所需的存储库。

有关 hook 的更多信息，请参阅 第 4 章 配置 Hook。

---
- name: Register Controller nodes
  hosts: Controller
  become: yes
  vars:
    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-13-rpms
      - rhel-7-server-rhceph-3-mon-rpms
  tasks:
    - name: Register system
      redhat_subscription:
        activationkey: my-openstack
        org_id: 1234567
        pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
    - name: Disable all repos
      command: "subscription-manager repos --disable *"
    - name: Enable Controller node repos
      command: "subscription-manager repos --enable {{ item }}"
      with_items: "{{ repos }}"

此 play 包含三个任务： - 使用激活密钥注册节点 - 禁用任何启用自动启用的存储库 - 仅启用与 Controller 节点相关的存储库。存储库使用 repos 变量列出。

部署 overcloud 后，您可以运行以下命令，以便 Ansible 为您的 overcloud 执行 playbook (ansible-osp-registration.yml)：

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

该命令执行以下操作： - 运行动态清单脚本来获取主机及其组列表 - 将 playbook 任务应用到 playbook 的 hosts 参数中定义的组内的节点，本例中为 Controller 组。

有关 overcloud 上运行 Ansible 自动化的更多信息，请参阅 Director 安装和使用 指南中的 "运行 Ansible Automation "。

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

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/extraconfig/services/rhsm.yaml

rhsm 可组合服务接受一个 RhsmVars 参数，它允许您定义与注册相关的多个子参数。例如：

parameter_defaults:
  RhsmVars:
    rhsm_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-13-rpms
      - rhel-7-server-rhceph-3-osd-rpms
      - rhel-7-server-rhceph-3-mon-rpms
      - rhel-7-server-rhceph-3-tools-rpms
    rhsm_activation_key: "my-openstack"
    rhsm_org_id: "1234567"

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

下一节是可用于 RhsmVars 参数的子参数列表，可用于 rhsm 可组合服务。

现在，您已经了解了 rhsm 可组合服务的工作方式以及如何进行配置，您可以使用以下步骤配置您自己的注册详情。

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

您还可以为特定 overcloud 角色提供注册详情。下一节提供了此示例。

您可以以每个角色为基础应用 rhsm 可组合服务。例如，您可以将一组配置应用到 Controller 节点，并将不同的配置集合应用到 Compute 节点。

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

这些过程在 overcloud 中启用并配置 rhsm。但是，如果您使用 第 5 章 overcloud 注册 中的 rhel-registration 方法，则必须禁用它切换到基于 Ansible 的方法。使用以下步骤从 rhel-registration 方法切换到基于 Ansible 的方法。

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

此流程演示了如何从 rhel-registration 方法切换到 rhsm 可组合服务。

此方法将 rhel-registration 参数替换为 rhsm 服务参数，并更改启用服务的 Heat 资源：

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

改为：

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/extraconfig/services/rhsm.yaml

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

现在，您已为 rhsm 服务配置了环境文件，您可以将它包含在下一个 overcloud 部署操作中。

此过程演示了如何将 rhsm 配置应用到 overcloud。

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

director 将核心 OpenStack Platform 服务安装为 overcloud 上的容器。容器化服务的模板位于 /usr/share/openstack-tripleo-heat-templates/docker/services/。这些模板引用对应的可组合服务模板。例如，OpenStack Identity (keystone)容器化服务模板(docker/services/keystone.yaml)包括以下资源：

  KeystoneBase:
    type: ../../puppet/services/keystone.yaml
    properties:
      EndpointMap: {get_param: EndpointMap}
      ServiceData: {get_param: ServiceData}
      ServiceNetMap: {get_param: ServiceNetMap}
      DefaultPasswords: {get_param: DefaultPasswords}
      RoleName: {get_param: RoleName}
      RoleParameters: {get_param: RoleParameters}

这个类型 指的是对应的 OpenStack Identity (keystone)可组合服务，并从该模板中提取 输出 数据。容器化服务将这些数据与其自己的特定容器数据合并。

使用容器化服务的所有节点都必须启用 OS::TripleO::Services::Docker 服务。为自定义角色配置创建 roles_data.yaml 文件时，请将带有基本可组合服务的 OS::TripleO::Services::Docker 服务作为容器化服务包括在内。例如，Keystone 角色使用以下角色定义：

- name: Keystone
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Fluentd
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Keystone

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

红帽通过 Red Hat Container Catalog (registry.redhat.io)提供了一组预构建的容器镜像。可以修改这些镜像并向其中添加其他层。这对于向容器添加认证第三方驱动程序的 RPM 非常有用。

本例演示了如何自定义最新的 openstack-keystone 镜像。但是，这些说明也可以应用到其他镜像：

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

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

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

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

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

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

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

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

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

overcloud 网络的其他功能，如 第 10 章 自定义可组合网络 和 第 11 章 自定义网络接口模板 依赖于此网络隔离环境文件。因此，您需要使用部署命令包含所生成的文件的名称。例如：

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

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

为每个网络编辑以下内容：

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

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

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

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

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

对于默认 Compute 节点，这只为 Storage、Internal API 和 Tenant 网络呈现网络信息：

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

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

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

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

此流程演示了如何使用其中一个默认 NIC 模板启用基本网络隔离。在本例中，这是带有 VLAN 模板的单个 NIC (single-nic-vlans)。

例如：

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

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

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

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

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

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

使用 -n 选项，将自定义 network_data 文件与您的部署包含。如果没有 -n 选项，部署命令将使用默认网络集合。

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

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

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

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

parameter_defaults:
  ServiceNetMap:
    SwiftMgmtNetwork: storage_backup
    CephClusterNetwork: storage_backup

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

director 将您的自定义 ServiceNetMap 参数定义合并到从 ServiceNetMapDefaults 获取的预定义默认值列表中，并覆盖默认值。然后，director 返回完整的列表，包括自定义到 ServiceNetMap，用于为各种服务配置网络分配。

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

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

例如：

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

这将在 overcloud 中的节点之间部署可组合网络，包括其他自定义网络。

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

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

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

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

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

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

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

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

例如：

  - type: interface
    name: nic2

例如：

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

例如：

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

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

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

例如：

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

例如：

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

请注意，nic2 使用 primary: true。这样可确保绑定将 MAC 地址用于 nic2。

例如：

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

例如：

  - type: interface
    name: nic2
    ...
    routes:
      - ip_netmask: 10.1.2.0/24
        default: true
        next_hop:
          get_param: EC2MetadataIp

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

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

              # NIC 1 - Provisioning
              - 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

              # NIC 2 - Control Group
              - type: interface
                name: nic2
                use_dhcp: false
              - type: vlan
                device: nic2
                vlan_id:
                  get_param: InternalApiNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: InternalApiIpSubnet
              - type: vlan
                device: nic2
                vlan_id:
                  get_param: StorageMgmtNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: StorageMgmtIpSubnet
              - type: vlan
                device: nic2
                vlan_id:
                  get_param: ExternalNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: ExternalIpSubnet
                routes:
                - default: true
                  next_hop:
                    get_param: ExternalInterfaceDefaultRoute

              # NIC 3 - Data Group
              - type: ovs_bridge
                name: bridge_name
                dns_servers:
                  get_param: DnsServers
                members:
                - type: interface
                  name: nic3
                  primary: true
                - type: vlan
                  vlan_id:
                    get_param: StorageNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: StorageIpSubnet
                - type: vlan
                  vlan_id:
                    get_param: TenantNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: TenantIpSubnet

                # NIC 4 - Management
                - type: interface
                  name: nic4
                  use_dhcp: false
                  addresses:
                  - ip_netmask: {get_param: ManagementIpSubnet}
                  routes:
                  - default: true
                    next_hop: {get_param: ManagementInterfaceDefaultRoute}

此模板使用四个网络接口，并将多个标记的 VLAN 设备分配给编号的接口 nic1 到 nic4。在 nic3 上，它创建托管 Storage 和租户网络的 OVS 网桥。因此，它会创建以下布局：

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

每个静态文件都需要自定义网络的所有参数定义，即使角色上未使用了网络。检查以确保渲染的模板包含这些参数。例如，如果只将 StorageBackup 网络添加到 Ceph 节点，则所有角色的 NIC 配置模板中的 parameter 部分还包括此定义：

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

如果需要，您还可以包含 VLAN ID 和/或网关 IP 的参数定义：

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

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

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

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

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

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

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

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

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

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

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

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

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

例如：

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /home/stack/templates/custom-network-configuration.yaml \
    ...

单个接口可能需要修改。以下示例显示了使用第二个 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、eth 1、enp0s25)或一组编号的接口(nic1、 nic2、nic3)。当使用编号接口(nic1、nic 2 等)而不是指定接口(eth 0、eno2 等)时，角色内主机的网络接口不必完全相同。例如，一个主机可能具有 em1 和 em2 接口，而另一个主机具有 eno1 和 eno2，但您可以将两个主机的 NIC 指代为 nic1 和 nic2。

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

numbered NIC 方案只考虑在线接口，例如，如果它们附加了交换机的电缆。如果您有一个有四个接口以及一些带有六个接口的主机，您应该使用 nic1 到 nic4，并且仅在每台主机上插入四个电缆。

您可以将物理接口硬编码到特定的别名。这样，您可以预先确定哪个物理 NIC 将映射为 nic1 或 nic2 等。您还可以将 MAC 地址映射到指定的别名。

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

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

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

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

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

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

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

要在带有静态 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

最大传输单元(MTU)设置决定了通过单一以太网帧传输的最大数据量。使用较大的值会导致开销更少，因为每个帧以标头的形式添加数据。默认值为 1500，使用更高的值需要配置交换机端口来支持巨型帧。大多数交换机支持至少 9000 的 MTU，但很多交换机默认配置为 1500。

VLAN 的 MTU 不能超过物理接口的 MTU。确保在绑定和/或接口上包括 MTU 值。

存储、存储管理、内部 API 和租户网络都受益于巨型帧。在测试中，项目的网络吞吐量在将巨型帧与 VXLAN 隧道结合使用时具有显著改进。

- 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

如果中继接口或绑定在原生 VLAN 上有一个网络，则 IP 地址会直接分配给网桥，且没有 VLAN 接口。

例如，如果外部网络位于原生 VLAN 上，则绑定的配置类似如下：

network_config:
  - type: ovs_bridge
    name: 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

Red Hat OpenStack Platform (RHOSP)网络服务(neutron)使用 netfilter 连接跟踪来构建有状态的防火墙，并在虚拟网络中提供网络地址转换(NAT)。有些情况下可能会导致内核空间达到最大连接限制，并导致错误（如 nf_conntrack: table full, drop 数据包）。您可以增加连接跟踪(conntrack)的限值，并避免这些类型的错误。您可以为 RHOSP 部署中的一个或多个角色增加 conntrack 限制。

您可以将多个物理 NIC 捆绑到一起组成一个逻辑频道，称为绑定。您可以配置绑定来为高可用性系统或增加吞吐量提供冗余。

Red Hat OpenStack Platform 支持 Linux 绑定、Open vSwitch (OVS)内核绑定和 OVS-DPDK 绑定。

绑定可与可选链路聚合控制协议(LACP)一起使用。LACP 是一个协商协议，可为负载平衡和容错创建动态绑定。

红帽建议使用 Linux 内核绑定(bond type: linux_bond) over OvS 内核绑定(bond type: ovs_bond)。用户模式绑定(bond type：ovs_dpdk_bond)必须与用户模式桥接(type: ovs_user_bridge)一同使用，而不是内核模式网桥(type: ovs_bridge)。但是，不要在同一节点上组合 ovs_bridge 和 ovs_user_bridge。

在控制和存储网络上，红帽建议使用带有 VLAN 和 LACP 的 Linux 绑定，因为 OVS 绑定增加了在 OVS 或 neutron 代理重启时出现 control plane 中断的可能性。Linux 绑定/LACP/VLAN 配置在不出现 OVS 中断的情况下提供 NIC 管理。

以下是一个使用 VLAN 的 Linux 绑定配置示例。

params:
            $network_config:
              network_config:

              - type: linux_bond
                name: bond_api
                bonding_options: "mode=active-backup"
                use_dhcp: false
                dns_servers:
                  get_param: DnsServers
                members:
                - type: interface
                  name: nic3
                  primary: true
                - type: interface
                  name: nic4

              - type: vlan
                vlan_id:
                  get_param: InternalApiNetworkVlanID
                device: bond_api
                addresses:
                - ip_netmask:
                    get_param: InternalApiIpSubnet

以下示例显示了将 Linux 绑定插入到 OVS 网桥中

params:
            $network_config:
              network_config:

            -  type: ovs_bridge
                name: br-tenant
                use_dhcp: false
                mtu: 9000
                members:
                  - type: linux_bond
                    name: bond_tenant
                    bonding_options: "mode=802.3ad updelay=1000 miimon=100"
                    use_dhcp: false
                    dns_servers:
                      get_param: DnsServers
                    members:
                    - type: interface
                      name: p1p1
                      primary: true
                    - type: interface
                      name: p1p2
                  - type: vlan
                    device: bond_tenant
                    vlan_id: {get_param: TenantNetworkVlanID}
                    addresses:
                      -
                        ip_netmask: {get_param: TenantIpSubnet}

以下示例显示了 OVS 用户空间网桥：

params:
            $network_config:
              network_config:

          -    type: ovs_user_bridge
                name: br-ex
                use_dhcp: false
                members:
                - type: ovs_dpdk_bond
                  name: dpdkbond0
                  mtu: 2140
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  #ovs_extra:
                  #- set interface dpdk0 mtu_request=$MTU
                  #- set interface dpdk1 mtu_request=$MTU
                  rx_queue:
                    get_param: NumDpdkInterfaceRxQueues
                  members:
                  - type: ovs_dpdk_port
                    name: dpdk0
                    mtu: 2140
                    members:
                    - type: interface
                      name: p1p1
                  - type: ovs_dpdk_port
                    name: dpdk1
                    mtu: 2140
                    members:
                    - type: interface
                      name: p1p2

overcloud 通过 Open vSwitch (OVS)提供网络。使用下表来了解 OVS 内核和 OVS-DPDK 对绑定接口的支持兼容性。OVS/OVS-DPDK balance-tcp 模式仅作为技术预览提供。

您可以使用 BondInterfaceOvsOptions 参数在网络环境文件中配置绑定接口，如下例所示：

parameter_defaults:
  BondInterfaceOvsOptions: "bond_mode=balance-slb"

您可以在网络接口模板中使用 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"

有关 Linux 绑定选项的详情请参考 7.7.1。绑定模块指令 （在 Red Hat Enterprise Linux 7 网络指南》 中。

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

此流程为特定节点分配节点 ID。节点 ID 示例包括 controller-0、controller-1、compute-0、compute-1 等。

第一步是将 ID 分配为部署时与计算调度程序匹配的每个节点功能。例如：

openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <id>

这会将功能 node:controller-0 分配给节点。为所有节点使用唯一连续索引（从 0 开始）重复此模式。确保给定角色(Controller、Compute 或每个存储角色)的所有节点都相同，否则计算调度程序将不会正确匹配功能。

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

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

要使用这些调度程序提示，请在 Overcloud 创建过程中包括 ' scheduler_hints_env.yaml' 环境文件及 overcloud deploy 命令。

每个角色都可以通过这些参数进行相同的方法：

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

与 第 14.1 节 “分配特定节点 ID” 中的节点 ID 配置相结合，director 还可以为每个节点分配特定的自定义主机名。当您需要定义系统所在的位置（例如 rack2-row12），匹配清单标识符或其他需要自定义主机名的情况时，这非常有用。

要自定义节点主机名，请使用环境文件中的 HostnameMap 参数，如来自 第 14.1 节 “分配特定节点 ID” 的 ' scheduler_hints_env.yaml' 文件。例如：

parameter_defaults:
  ControllerSchedulerHints:
    'capabilities:node': 'controller-%index%'
  ComputeSchedulerHints:
    'capabilities:node': 'compute-%index%'
  HostnameMap:
    overcloud-controller-0: overcloud-controller-prod-123-0
    overcloud-controller-1: overcloud-controller-prod-456-0
    overcloud-controller-2: overcloud-controller-prod-789-0
    overcloud-compute-0: overcloud-compute-prod-abc-0

在 parameter_defaults 部分中定义 HostnameMap，并将每个 map 设置为 Heat 使用 HostnameFormat 参数（如 overcloud-controller-0）定义的原始主机名，第二个值是该节点所需的自定义主机名（如 overcloud-controller-prod-123-0）。

将此方法与节点 ID 放置结合使用可确保每个节点具有自定义主机名。

为进一步控制生成的环境，director 还可在每个网络上分配具有特定 IP 的 Overcloud 节点。在核心 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 地址。每个节点类型都有一个关联的参数：

每个参数都是一个到地址列表的网络名称映射。每种网络类型必须至少包含与该网络上节点相同的地址。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 地址不在网络环境文件中定义的每个网络的分配池之外（请参阅 第 11.7 节 “自定义网络环境文件”）。例如，确保 internal_api 分配在 InternalApiAllocationPools 范围之外。这可避免与所选 IP 相冲突。同样，请确保 IP 分配不会与 VIP 配置冲突，可以是标准的可预测 VIP 放置（请参阅 第 14.4 节 “分配可预测虚拟 IP”）或外部负载均衡（请参阅 第 23.2 节 “配置外部负载平衡”）。

要在部署期间应用此配置，请使用 openstack overcloud deploy 命令包含 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]

除了为每个节点定义可预测的 IP 地址外，director 还提供类似为集群服务定义可预测虚拟 IP (VIP)的功能。要做到这一点，从 第 11.7 节 “自定义网络环境文件” 编辑网络环境文件，并在 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。例如，为 InternalApiVirtualFixedIPs 选择一个 IP 地址，该地址没有在 InternalApiAllocationPools 范围内。

此步骤只适用于使用默认内部负载均衡配置的 overcloud。如果使用外部负载均衡器分配 VIP，请使用 Overcloud 指南中的专用外部负载平衡 中的步骤。

签名主机是生成新证书的主机，并使用证书颁发机构进行签名。如果您从未在所选签名主机上创建 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

一般情况下，您需要使用一个外部的证书认证机构来签发您的 SSL/TLS 证书。在某些情况下，您可能需要使用自己的证书颁发机构。例如，您可能想获得仅限内部的证书颁发机构。

例如，生成密钥和证书对以充当证书颁发机构：

$ sudo openssl genrsa -out ca.key.pem 4096
$ sudo openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem

openssl req 命令会要求输入认证机构的详细信息。输入这些详情。

这会创建一个名为 ca.crt.pem 的证书颁发机构文件。

对于旨在使用 SSL/TLS 通信的任何外部客户端，请将证书颁发机构文件复制到需要访问 Red Hat OpenStack Platform 环境的每个客户端。复制到客户端后，在客户端上运行以下命令将其添加到证书颁发机构信任捆绑包中：

$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
$ sudo update-ca-trust extract

例如，undercloud 需要证书颁发机构文件的副本，以便它在创建期间与 overcloud 端点通信。

运行以下命令生成 SSL/TLS 密钥(server.key.pem)，我们在不同时间点上生成 undercloud 或 overcloud 证书：

$ openssl genrsa -out server.key.pem 2048

下一个流程为 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 设置为以下内容之一：

在 alt_names 部分中，包含与 IP 条目相同的公共 API IP 地址以及 DNS 条目。如果也使用 DNS，请在同一部分中包含服务器的主机名作为 DNS 条目。有关 openssl.cnf 的更多信息，请运行 man openssl.cnf。

运行以下命令以生成证书签名请求(server.csr.pem)：

$ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

确保为 -key 选项包括您在 第 15.4 节 “创建 SSL/TLS 密钥” 中创建的 SSL/TLS 密钥。

使用 server.csr.pem 文件在下一节中创建 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 的证书。将此证书与来自 第 15.4 节 “创建 SSL/TLS 密钥” 的 SSL/TLS 密钥一起使用，以启用 SSL/TLS。

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

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

编辑此文件并对这些参数进行以下更改：

如果证书 signer 没有包括在 overcloud 镜像的默认信任存储中，您必须将证书颁发机构注入 overcloud 镜像。从 heat 模板集合中复制 inject-trust-anchor.yaml 环境文件：

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

编辑此文件并对这些参数进行以下更改：

如果要注入多个 CA，您可以使用 inject-trust-anchor-hiera.yaml 环境文件。例如，您可以同时注入 undercloud 和 overcloud 的 CA：

parameter_defaults:
  CAMap:
    undercloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        ... cert content ...
        -----END CERTIFICATE-----
    overcloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        ... cert content ...
        -----END CERTIFICATE-----

如果使用 DNS 主机名通过 SSL/TLS 访问 overcloud，则需要将 custom-domain.yaml 文件复制到 /home/stack/templates 中。您可以在 /usr/share/tripleo-heat-templates/environments/predictable-placement/ 中找到这个文件。

部署命令(openstack overcloud deploy)使用 -e 选项添加环境文件。按照以下顺序添加本节中的环境文件：

例如：

$ 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/ssl/tls-endpoints-public-dns.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/ssl/tls-endpoints-public-dns.yaml

在部署 overcloud 之前，您必须将 undercloud 添加到证书颁发机构(CA)中：

此流程使用 IdM 注册 undercloud，并配置 novajoin。在 undercloud.conf 中配置以下设置（在 [DEFAULT] 部分中）：

要自动检测 IdM 环境并更容易注册，请考虑使用 IdM 作为您的 DNS 服务器：

默认情况下，您现有的 Red Hat OpenStack Platform 13 overcloud 不会使用 TLS 加密某些端点。例如，以下输出包括使用 http 而不是 https 的 URL；这些 URL 不加密：

+----------------------------------+-----------+--------------+--------------+---------+-----------+--------------------------------------------------------+
| ID                               | Region    | Service Name | Service Type | Enabled | Interface | URL                                                    |
+----------------------------------+-----------+--------------+--------------+---------+-----------+--------------------------------------------------------+
| 0ad11e943e1f4ff988650cfba57b4031 | regionOne | nova         | compute      | True    | internal  | http://172.16.2.17:8774/v2.1                           |
| 1413eb9ef38a45b8bee1bee1b0dfe744 | regionOne | swift        | object-store | True    | public    | https://overcloud.lab.local:13808/v1/AUTH_%(tenant_id)s |
| 1a54f13f212044b0a20468861cd06f85 | regionOne | neutron      | network      | True    | public    | https://overcloud.lab.local:13696                       |
| 3477a3a052d2445697bb6642a8c26a91 | regionOne | placement    | placement    | True    | internal  | http://172.16.2.17:8778/placement                      |
| 3f56445c0dd14721ac830d6afb2c2cd4 | regionOne | nova         | compute      | True    | admin     | http://172.16.2.17:8774/v2.1                           |
| 425b1773a55c4245bcbe3d051772ebba | regionOne | glance       | image        | True    | internal  | http://172.16.2.17:9292                                |
| 57cf09fa33ed446f8736d4228bdfa881 | regionOne | placement    | placement    | True    | public    | https://overcloud.lab.local:13778/placement             |
| 58600f3751e54f7e9d0a50ba618e4c54 | regionOne | glance       | image        | True    | public    | https://overcloud.lab.local:13292                       |
| 5c52f273c3284b068f2dc885c77174ca | regionOne | neutron      | network      | True    | internal  | http://172.16.2.17:9696                                |
| 8792a4dd8bbb456d9dea4643e57c43dc | regionOne | nova         | compute      | True    | public    | https://overcloud.lab.local:13774/v2.1                  |
| 94bbea97580a4c4b844478aad5a85e84 | regionOne | keystone     | identity     | True    | public    | https://overcloud.lab.local:13000                       |
| acbf11b5c76d44198af49e3b78ffedcd | regionOne | swift        | object-store | True    | internal  | http://172.16.1.9:8080/v1/AUTH_%(tenant_id)s           |
| d4a1344f02a74f7ab0a50c5a7c13ca5c | regionOne | keystone     | identity     | True    | internal  | http://172.16.2.17:5000                                |
| d86c241dc97642419ddc12533447d73d | regionOne | placement    | placement    | True    | admin     | http://172.16.2.17:8778/placement                      |
| de7d6c34533e4298a2752852427a7030 | regionOne | glance       | image        | True    | admin     | http://172.16.2.17:9292                                |
| e82086062ebd4d4b9e03c7f1544bdd3b | regionOne | swift        | object-store | True    | admin     | http://172.16.1.9:8080                                 |
| f8134cd9746247bca6a06389b563c743 | regionOne | keystone     | identity     | True    | admin     | http://192.168.24.6:35357                              |
| fe29177bd29545ca8fdc0c777a7cf03f | regionOne | neutron      | network      | True    | admin     | http://172.16.2.17:9696                                |
+----------------------------------+-----------+--------------+--------------+---------+-----------+--------------------------------------------------------+

以下小节解释了如何使用 TLS 加密这些端点。

目前，TLS Everywhere 存在已知问题，因此 overcloud 节点无法注册到 IdM。作为临时解决方案，在运行 overcloud 部署前从所有 overcloud 节点中删除 /etc/ipa/ca.crt/。如需更多信息，请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1732564。

例如，以下脚本是应用临时解决方案的一种方法。您可能需要调整此功能以适合您的部署。

[stack@undercloud-0 ~]$ vi rm-ca.crt-dir.sh
#!/bin/bash

source /home/stack/stackrc
NODES=$(openstack server list -f value -c Networks|sed s/ctlplane=//g)

for NODE in $NODES
do
    ssh heat-admin@$NODE sudo rm -rf /etc/ipa/ca.crt/
Done

[stack@undercloud-0 ~]$ bash rm-ca.crt-dir.sh

本节介绍如何为现有部署启用 TLS 端点加密，然后如何检查端点是否已正确配置。

在随处启用 TLS 时，有不同的升级路径，具体取决于您的域是如何构成的。这些示例使用示例域名来描述升级路径：

本节中的步骤解释了如何使用上述各种组合配置此集成。

overcloud 重新部署完成后，检查是否现在使用 TLS 加密所有端点。在本例中，所有端点都配置为使用 https，表示它们正在使用 TLS 加密：

+----------------------------------+-----------+--------------+----------------+---------+-----------+---------------------------------------------------------------+
| ID                               | Region    | Service Name | Service Type   | Enabled | Interface | URL                                                           |
+----------------------------------+-----------+--------------+----------------+---------+-----------+---------------------------------------------------------------+
| 0fee4efdc4ae4310b6a139a25d9c0d9c | regionOne | neutron      | network        | True    | public    | https://overcloud.lab.local:13696                              |
| 220558ab1d2445139952425961a0c89a | regionOne | glance       | image          | True    | public    | https://overcloud.lab.local:13292                              |
| 24d966109ffa419da850da946f19c4ca | regionOne | placement    | placement      | True    | admin     | https://overcloud.internalapi.lab.local:8778/placement         |
| 27ac9e0d22804ee5bd3cd8c0323db49c | regionOne | nova         | compute        | True    | internal  | https://overcloud.internalapi.lab.local:8774/v2.1              |
| 31d376853bd241c2ba1a27912fc896c6 | regionOne | swift        | object-store   | True    | admin     | https://overcloud.storage.lab.local:8080                       |
| 350806234c784332bfb8615e721057e3 | regionOne | nova         | compute        | True    | admin     | https://overcloud.internalapi.lab.local:8774/v2.1              |
| 49c312f4db6748429d27c60164779302 | regionOne | keystone     | identity       | True    | public    | https://overcloud.lab.local:13000                              |
| 4e535265c35e486e97bb5a8bc77708b6 | regionOne | nova         | compute        | True    | public    | https://overcloud.lab.local:13774/v2.1                         |
| 5e93dd46b45f40fe8d91d3a5d6e847d3 | regionOne | keystone     | identity       | True    | admin     | https://overcloud.ctlplane.lab.local:35357                     |
| 6561984a90c742a988bf3d0acf80d1b6 | regionOne | swift        | object-store   | True    | public    | https://overcloud.lab.local:13808/v1/AUTH_%(tenant_id)s        |
| 76b8aad0bdda4313a02e4342e6a19fd6 | regionOne | placement    | placement      | True    | public    | https://overcloud.lab.local:13778/placement                    |
| 96b004d5217c4d87a38cb780607bf9fb | regionOne | placement    | placement      | True    | internal  | https://overcloud.internalapi.lab.local:8778/placement         |
| 98489b4b107f4da596262b712c3fe883 | regionOne | glance       | image          | True    | internal  | https://overcloud.internalapi.lab.local:9292                   |
| bb7ab36f30b14b549178ef06ec74ff84 | regionOne | glance       | image          | True    | admin     | https://overcloud.internalapi.lab.local:9292                   |
| c1547f7bf9a14e9e85eaaaeea26413b7 | regionOne | neutron      | network        | True    | admin     | https://overcloud.internalapi.lab.local:9696                   |
| ca66f499ec544f42838eb78a515d9f1e | regionOne | keystone     | identity       | True    | internal  | https://overcloud.internalapi.lab.local:5000                   |
| df0181358c07431390bc66822176281d | regionOne | swift        | object-store   | True    | internal  | https://overcloud.storage.lab.local:8080/v1/AUTH_%(tenant_id)s |
| e420350ef856460991c3edbfbae917c1 | regionOne | neutron      | network        | True    | internal  | https://overcloud.internalapi.lab.local:9696                   |
+----------------------------------+-----------+--------------+----------------+---------+-----------+---------------------------------------------------------------+

本节论述了如何将 overcloud 配置为使用 NFS 共享。安装和配置过程基于修改核心 heat 模板集合中的现有环境文件。

核心 heat 模板集合包含 /usr/share/openstack-tripleo-heat-templates/environments/ 中的一组环境文件。使用这些环境文件，您可以在由 director 创建的 overcloud 中创建自定义配置受支持的功能。这包括配置存储的环境文件。此文件位于 /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml。

director 提供了两种主要方法，用于将 Red Hat Ceph Storage 集成到 Overcloud 中。

您可以通过禁用控制器节点上的默认 Object Storage 服务部署来重复使用外部 Object Storage (swift)集群。这样做会禁用对象存储的代理和存储服务，并将 haproxy 和 keystone 配置为使用给定的外部 Swift 端点。

您需要外部 Object Storage 集群的端点 IP 地址和外部 Object Storage proxy-server.conf 文件中的 authtoken 密码。您可以使用 openstack endpoint list 命令查找此信息。

使用外部 Swift 集群部署 director：

OpenStack Image 服务(glance)的默认设置由安装 OpenStack 时使用的 Heat 模板决定。镜像服务 Heat 模板为 tht/puppet/services/glance-api.yaml。

可互操作镜像导入允许两个镜像导入方法：

web-download 方法可让您从 URL 导入镜像； glance-direct 方法可让您从本地卷导入镜像。

parameter_defaults:
  # Configure NFS backend
  GlanceBackend: file
  GlanceNfsEnabled: true
  GlanceNfsShare: 192.168.122.1:/export/glance

  # Enable glance-direct import method
  GlanceEnabledImportMethods: glance-direct,web-download

  # Configure NFS staging area (required for glance-direct import method)
  GlanceStagingNfsShare: 192.168.122.1:/export/glance-staging

GlanceBackend 参数设置镜像服务用来存储镜像的后端。

默认情况下，您可以将无限数量的存储设备附加到单个实例。要限制最大设备数量，请在 Compute 环境文件中添加 max_disk_devices_to_attach 参数。以下示例演示了如何将 max_disk_devices_to_attach 的值改为 "30"：

parameter_defaults:
   ComputeExtraConfig:
          nova::config::nova_config:
            compute/max_disk_devices_to_attach:
                value: '30'

director 包括几个环境文件，以帮助配置第三方存储供应商。这包括：

每个核心 OpenStack 平台服务都在其相应的可组合服务模板中包含防火墙规则。这会为每个 overcloud 节点自动创建一组默认防火墙规则。

overcloud Heat 模板包含一组有助于其他防火墙管理的参数：

如果 ManageFirewall 设为 true，则可以在部署时创建额外的防火墙规则。使用配置 hook 设置 tripleo::firewall::firewall_rules hieradata （请参阅 overcloud 环境文件中的 第 4.5 节 “Puppet：为角色自定义 Hieradata”）。此 hieradata 是一个哈希，包含防火墙规则名称及其对应的参数作为键，它们都是可选的：

以下示例演示了防火墙规则格式的语法：

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 将两个额外的防火墙规则应用于所有节点。

director 为您的 overcloud 提供默认的只读 SNMP 配置。建议更改 SNMP 字符串来降低未授权用户了解您的网络设备的风险。

在 overcloud 的环境文件中，使用 ExtraConfig hook 设置以下 hieradata：

SNMP 传统访问控制设置

例如：

parameter_defaults:
  ExtraConfig:
    snmp::ro_community: mysecurestring
    snmp::ro_community6: myv6securestring

这会更改所有节点上的只读 SNMP 社区字符串。

基于 SNMP 视图的访问控制设置(VACM)

例如：

parameter_defaults:
  ExtraConfig:
    snmp::com2sec: mysecurestring
    snmp::com2sec6: myv6securestring

这会更改所有节点上的只读 SNMP 社区字符串。

如需更多信息，请参阅 snmpd.conf man page。

如果在 overcloud 中启用了 SSL/TLS （请参阅 第 15 章 在 Overcloud 公共端点中启用 SSL/TLS），您可能想加强与 HAProxy 配置一起使用的 SSL/TLS 密码和规则。这有助于避免 SSL/TLS 漏洞，如 POODLE 漏洞。

在 overcloud 的环境文件中，使用 ExtraConfig hook 设置以下 hieradata：

例如，您可能需要使用下列密码和规则：

使用以下内容创建环境文件：

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

在 overcloud 创建中包含此环境文件。

您可以将安全组配置为使用 Red Hat OpenStack Platform director 中的 Open vSwitch (OVS)防火墙驱动程序。NeutronOVSFirewallDriver 参数允许您指定要使用的防火墙驱动程序：

openvswitch 防火墙驱动程序包括更高的性能，并减少用于将客户机连接到项目网络的接口和网桥数量。

在 network-environment.yaml 文件中配置 NeutronOVSFirewallDriver 参数：

NeutronOVSFirewallDriver: openvswitch

overcloud 镜像自动包含 root 用户的强化安全性。例如，每个部署的 overcloud 节点都会自动禁用对 root 用户的直接 SSH 访问。您仍然可以通过以下方法访问 overcloud 节点上的 root 用户：

该方法使用第一个引导配置 hook （请参阅 第 4.1 节 “首次启动：自定义第一个引导配置”）。将以下内容放在环境文件中：

resource_registry:
  OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml

parameter_defaults:
  NodeRootPassword: "p@55w0rd!"

注意以下几点：

在创建 overcloud 时，请使用 openstack overcloud deploy 命令包含此环境文件。

您可以使用位于 /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml 的环境文件来启用 Fujitsu Converged Fabric (C-Fabric)插件。

您可以使用位于 /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml 的环境文件来启用 Fujitsu FOS Switch 插件。

默认情况下，overcloud 的区域将命名为 regionOne。您可以通过添加 KeystoneRegion 条目来更改您的环境文件。这个设置无法在部署后更改：

parameter_defaults:
  KeystoneRegion: 'SampleRegion'

OpenStack Platform director 包含在 overcloud 节点上配置内核的参数。

这个示例在环境文件中显示这些参数的语法：

parameter_defaults:
  ExtraKernelModules:
    iscsi_target_mod: {}
  ExtraKernelPackages:
    iscsi-initiator-utils: {}
  ExtraSysctlSettings:
    dev.scsi.logging_level:
      value: 1

Overcloud 使用多个 Controller 作为高可用性集群，确保 OpenStack 服务的最大运行性能。另外，集群为访问 OpenStack 服务提供负载均衡，它会平均分配流量到 Controller 节点，并减少每个节点的服务器过载。也可以使用外部负载均衡器来执行此分发。例如，组织可能会使用自己的基于硬件的负载均衡器来处理到 Controller 节点的流量分布。

有关配置外部负载均衡的更多信息，请参阅 Overcloud 的专用外部负载平衡 以 获得完整说明。

作为默认情况，Overcloud 使用 Internet Protocol 版本 4 (IPv4)来配置服务端点。但是，Overcloud 还支持互联网协议版本 6 (IPv6)端点，对于支持 IPv6 基础架构的组织有用。director 包括一组环境文件，可帮助创建基于 IPv6 的 Overcloud。

有关在 Overcloud 中配置 IPv6 的详情，请参考 Overcloud 的专用 IPv6 网络 以获得完整说明。