第 7 章 使用预配置节点配置基本 overcloud

在本流程稍后的阶段，director 需要具备以 stack 用户的身份访问 overcloud 节点的 SSH 权限。

每个节点需要具备访问红帽订阅的权限。以下步骤显示了如何将每个节点注册到 Red Hat Content Delivery Network。对每个节点执行以下操作：

节点现在可供您的 overcloud 使用。

各预配置节点使用 OpenStack Orchestration (heat) 代理与 director 通讯。各节点上的代理对 director 轮询，获得针对各节点定制的元数据。该元数据允许代理配置各节点。

在各节点上为编配代理安装初始软件包：

[root@controller ~]# sudo yum -y install python-heat-agent*

如果 director 使用 SSL/TLS，那么预配置节点需要用于签署 director 的 SSL/TLS 证书的证书授权机构文件。如果使用您自己的证书授权机构，则在各 overcloud 节点上执行以下操作：

这可以确保 overcloud 节点能够通过 SSL/TLS 访问 director 的 Public API。

预配置 overcloud 节点使用标准 HTTP 请求从 director 获取元数据。这表示所有 overcloud 节点都需要 L3 权限来访问以下之一：

director 使用 Control Plane 网络来管理和配置标准 overcloud。对于具备预配置节点的 overcloud，您可能需要对网络配置做一些修改，以适应 director 与预配置节点通讯的方式。

创建标准 overcloud 期间，director 创建 OpenStack Networking (neutron) 端口，用于自动为 Provisioning / Control Plane 网络池上的 overcloud 节点分配 IP 地址。但是，这可能导致 director 为手动配置的节点分配不同的 IP 地址。在这种情况下，使用可预测的 IP 地址策略来强制 director 使用 Control Plane 上的预配置 IP 分配。

可预测 IP 策略的一个示例是使用 IP 地址分配如下的环境文件 (ctlplane-assignments.yaml)：

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

parameter_defaults:
  DeployedServerPortMap:
    controller-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.2
      subnets:
        - cidr: 24
    compute-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.3
      subnets:
        - cidr: 24

在本示例中，OS::TripleO::DeployedServer::ControlPlanePort 资源将一组参数传递至 director，并为预配置的节点定义 IP 分配。DeployedServerPortMap 参数定义与每个 overcloud 节点对应的 IP 地址和子网 CIDR。映射定义：

本章之后的步骤将生成的环境文件 (ctlplane-assignments.yaml) 用作 openstack overcloud deploy 命令的组成部分。

默认情况下，director 使用 Provisioning 网络作为 overcloud Control Plane。但是，如果此网络被隔离且不可路由，则节点在配置期间不能与 director 的内部 API 通讯。在这种情况下，您可能需要为节点指定一个单独的网络，并进行配置，以便通过公共 API 与 director 通讯。

对于此情境，有几个需要满足的要求：

本节中的示例使用了与主要情境不同的 IP 地址分配：

以下章节为需要单独的 overcloud 节点网络的情境提供额外配置。

您的 undercloud.conf 中的 hieradata_override 允许您指定用于 undercloud 配置的额外 Puppet hieradata。使用以下步骤修改与 OpenStack 编配相关的 hieradata：

这会使编配元数据服务器切换为使用 director 的公共 API 上的 URL。

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml 1

parameter_defaults:
  NeutronPublicInterface: eth1
  EC2MetadataIp: 192.168.100.1 2
  ControlPlaneDefaultRoute: 192.168.100.1
  DeployedServerPortMap:
    control_virtual_ip:
      fixed_ips:
        - ip_address: 192.168.100.1
    controller0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.2
    compute0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.3

overcloud 部署使用来自 ??? 的标准 CLI 方法。对于预配置节点，该部署命令需要使用来自核心 Heat 模板集的一些额外选项和环境文件：

以下是一个 overcloud 部署命令命令，采用了针对预配置架构的特定环境文件：

[stack@director ~]$ source ~/stackrc
[stack@director ~]$ openstack overcloud deploy \
  [other arguments] \
  --disable-validations \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-bootstrap-environment-rhel.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-pacemaker-environment.yaml \
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml

由此开始 overcloud 配置。但是，当 overcloud 节点资源进入 CREATE_IN_PROGRESS 阶段时，部署堆栈暂停：

2017-01-14 13:25:13Z [overcloud.Compute.0.Compute]: CREATE_IN_PROGRESS  state changed
2017-01-14 13:25:14Z [overcloud.Controller.0.Controller]: CREATE_IN_PROGRESS  state changed

出现这种暂停是因为 director 等待 overcloud 节点上的编配代理来轮询元数据服务器。下一节将介绍如何配置节点以开始轮询元数据服务器。

部署目前正在进行，但会在进入 CREATE_IN_PROGRESS 阶段后暂停。下一步是在 overcloud 节点上配置编配代理，以便在 director 上轮询元数据服务器。可采用两种方式完成此操作：

[stack@director ~]$ source ~/stackrc

此外，该脚本也要求使用一些额外的环境变量来定义节点的角色及其 IP 地址。这些环境变量包括：

以下命令演示了如何设置这些环境变量：

[stack@director ~]$ export OVERCLOUD_ROLES="ControllerDeployedServer ComputeDeployedServer"
[stack@director ~]$ export ControllerDeployedServer_hosts="192.168.100.2"
[stack@director ~]$ export ComputeDeployedServer_hosts="192.168.100.3"

运行该脚本，在各 overcloud 节点上配置编配代理：

[stack@director ~]$ /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/get-occ-config.sh

该脚本完成以下操作：

脚本完成之后，overcloud 节点开始在 director 上轮询编配服务。堆栈部署继续进行。

[stack@director ~]$ source ~/stackrc
[stack@director ~]$ for STACK in $(openstack stack resource list -n5 --filter name=deployed-server -c stack_name -f value overcloud) ; do STACKID=$(echo $STACK | cut -d '-' -f2,4 --output-delimiter " ") ; echo "== Metadata URL for $STACKID ==" ; openstack stack resource metadata $STACK deployed-server | jq -r '.["os-collect-config"].request.metadata_url' ; echo ; done

这会显示堆栈名称和各节点的元数据 URL：

== Metadata URL for ControllerDeployedServer 0 ==
http://192.168.24.1:8080/v1/AUTH_6fce4e6019264a5b8283e7125f05b764/ov-edServer-ts6lr4tm5p44-deployed-server-td42md2tap4g/43d302fa-d4c2-40df-b3ac-624d6075ef27?temp_url_sig=58313e577a93de8f8d2367f8ce92dd7be7aac3a1&temp_url_expires=2147483586

== Metadata URL for ComputeDeployedServer 0 ==
http://192.168.24.1:8080/v1/AUTH_6fce4e6019264a5b8283e7125f05b764/ov-edServer-wdpk7upmz3eh-deployed-server-ghv7ptfikz2j/0a43e94b-fe02-427b-9bfe-71d2b7bb3126?temp_url_sig=8a50d8ed6502969f0063e79bb32592f4203a136e&temp_url_expires=2147483586

在各 overcloud 节点上：

在配置和重新启动之后，这些编配代理会轮询 director 的编配服务以获取 overcloud 配置。部署堆栈继续创建过程，各节点的堆栈最终变更为 CREATE_COMPLETE。

overcloud 配置过程开始。此过程需要一些时间完成。要查看 overcloud 创建的状态，请以 stack 用户身份打开另外一个终端并运行：

$ source ~/stackrc
$ heat stack-list --show-nested

heat stack-list --show-nested 命令会显示 overcloud 创建过程的当前状态。

director 会生成脚本来配置和帮助认证 director 主机与 overcloud 的交互。director 将此文件保存为 stack 用户主目录的 overcloudrc 文件。运行以下命令来使用此文件：

$ source ~/overcloudrc

这会加载所需的环境变量，以便从 director 节点上的 CLI 与 overcloud 交互。要回到与 director 节点交互的状态，请运行：

$ source ~/stackrc

扩展预配置节点的流程与???中的标准扩展流程类似。但是，添加新预配置节点的流程却不相同，这是因为预配置节点不从 OpenStack Bare Metal (ironic) 和 OpenStack Compute (nova) 使用标准注册和管理流程。

扩展节点的常规流程如下：

从堆栈中移除 overcloud 节点之后，关闭这些节点。在标准部署中，此功能由 director 的裸机服务管控。但是，使用预配置节点时，您应当手动关闭这些节点，或者使用各物理系统的电源管理控制功能。从堆栈中移除节点之后，如果您不关闭它们，它们可能保持运行，并作为 overcloud 环境的组成部分重新连接。

关闭已移除的节点之后，重新将它们部署到基础操作系统配置中，避免它们将来意外加入到 overcloud 中

使用与标准 overcloud 相同的流程，移除使用预配置节点的整个 overcloud。请参阅???了解更多详细信息。

移除 overcloud 之后，关闭所有节点，并将它们重新部署到基础操作系统配置中。

通过预配置节点创建 overcloud 的流程到此结束。如需了解创建之后的功能，请参阅???。