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

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

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

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

如果 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 节点网络的情境提供额外配置。

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
      subnets:
        - cidr: 24
    controller0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.2
      subnets:
        - cidr: 24
    compute0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.3
      subnets:
        - cidr: 24

在配置预置备的节点时，您需要将基于 Heat 的主机名映射到它们的实际主机名，以便 ansible-playbook 可以访问可解析的主机。请使用 HostnameMap 来映射这些值。

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

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

$ source ~/stackrc
(undercloud) $ 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 \
  -e /home/stack/templates/hostname-map.yaml /
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml
  --overcloud-ssh-user stack \
  --overcloud-ssh-key ~/.ssh/id_rsa \
  [OTHER OPTIONS]

--overcloud-ssh-user 和 --overcloud-ssh-key 选项用于在配置阶段通过 SSH 连接每个 overcloud 节点，创建初始 tripleo-admin 用户，以及将 SSH 密钥注入 /home/tripleo-admin/.ssh/authorized_keys。要注入 SSH 密钥，用户可以使用 --overcloud-ssh-user 和 --overcloud-ssh-key（默认值为 ~/.ssh/id_rsa）为初始 SSH 连接指定凭证。为免泄露使用 --overcloud-ssh-key 指定的私钥，director 不会向任何 API 服务（如 Heat 或 MIstral）传递这个密钥，而且只有 director 的 openstack overcloud deploy 命令会用这个密钥为 tripleo-admin 用户启用访问权限。

一旦 overcloud 创建完毕，director 会提供为配置 overcloud 而执行的 Ansible play 的总结：

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director 还会提供用于访问 overcloud 的详细信息。

Ansible passed.
Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.113:5000
Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed

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

(undercloud) $ source ~/overcloudrc

这会加载所需的环境变量，以便通过 director 主机的 CLI 与 overcloud 进行交互。命令提示符的变化会显示当前状态：

(overcloud) $

要返回与 director 主机进行交互的状态，运行以下命令：

(overcloud) $ source ~/stackrc
(undercloud) $

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

扩展预置备节点的一般流程包括下列步骤：

在大多数缩放操作中，您必须获取节点的 UUID 值，以传递给 openstack overcloud node delete。要获取此 UUID，请列出供特定角色使用的资源：

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::<RoleName>Server

将上述命令中的 <RoleName> 替换为您要缩减的角色的实际名称。例如，对于 ComputeDeployedServer 角色：

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::ComputeDeployedServerServer

使用命令输出中的 stack_name 列来识别与各个节点相关的 UUID。stack_name 包含节点在 Heat 资源组中的索引的整数值。例如，在以下示例输出中：

+------------------------------------+----------------------------------+
| physical_resource_id               | stack_name                       |
+------------------------------------+----------------------------------+
| 294d4e4d-66a6-4e4e-9a8b-           | overcloud-ComputeDeployedServer- |
| 03ec80beda41                       | no7yfgnh3z7e-1-ytfqdeclwvcg      |
| d8de016d-                          | overcloud-ComputeDeployedServer- |
| 8ff9-4f29-bc63-21884619abe5        | no7yfgnh3z7e-0-p4vb3meacxwn      |
| 8c59f7b1-2675-42a9-ae2c-           | overcloud-ComputeDeployedServer- |
| 2de4a066f2a9                       | no7yfgnh3z7e-2-mmmaayxqnf3o      |
+------------------------------------+----------------------------------+

stack_name 列中的索引 0、1 或 2 对应于 Heat 资源组中的节点次序。将 physical_resource_id 列中的对应 UUID 值传递到 openstack overcloud node delete 命令。

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

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

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

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

通过预置备节点创建 overcloud 的流程到此结束。如需了解创建之后的功能，请参阅 第 9 章 创建 overcloud 后执行的任务。