11.4. 使用预置备节点配置基本 overcloud

在开始使用预置备节点部署 overcloud 前，请确保环境中存在以下配置：

使用预置备节点配置 overcloud 时，director 需要对 overcloud 节点进行 SSH 访问。在预置备的节点上，您必须创建一个使用 SSH 密钥身份验证的用户，并为该用户配置免密码 sudo 访问。在预置备的节点上创建用户后，可以结合使用 --overcloud-ssh-user 和 --overcloud-ssh-key 选项及 openstack overcloud deploy 命令，创建具有预置备节点的 overcloud。

默认情况下，overcloud SSH 用户和 overcloud SSH 密钥的值是 stack 用户和 ~/.ssh/id_rsa。要创建 stack 用户，请完成以下步骤。

每个节点需要具备访问红帽订阅的权限。在每个节点上完成以下步骤，将节点注册到 Red Hat Content Delivery Network 中。以 root 用户身份或具有 sudo 特权的用户身份执行命令。

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

如果 director 使用 SSL/TLS，那么预置备节点需要用于签署 director 的 SSL/TLS 证书的证书授权机构文件。如果使用自己的证书颁发机构（CA），请在每个 overcloud 节点上执行以下操作。

这些步骤将确保 overcloud 节点可以通过 SSL/TLS 访问 director 的公共 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 分配。

如果您使用网络隔离，请创建一个自定义环境文件 deployed-ports.yaml 来实现可预测的 IP 策略。以下示例自定义环境文件 deployed-ports.yaml，将一组资源 registry 映射和参数传递给 director，并且定义预置备节点的 IP 分配。NodePortMap、ControlPlaneVipData 和 VipPortMap 参数定义与每个 overcloud 节点对应的 IP 地址和子网 CIDR。

resource_registry:
  # Deployed Virtual IP port resources
  OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_external.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_internal_api.yaml
  OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_storage.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_vip_storage_mgmt.yaml

  # Deployed ControlPlane port resource
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

  # Controller role port resources
  OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_external.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_internal_api.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage_mgmt.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_tenant.yaml

  # Compute role port resources
  OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_internal_api.yaml
  OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml
  OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_tenant.yaml

  # CephStorage role port resources
  OS::TripleO::CephStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage_mgmt.yaml
  OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/deployed_storage.yaml

parameter_defaults:
  NodePortMap: 1
    # Controller node parameters
    controller-00-rack01: 2
      ctlplane: 3
        ip_address: 192.168.24.201
        ip_address_uri: 192.168.24.201
        ip_subnet: 192.168.24.0/24
      external:
        ip_address: 10.0.0.201
        ip_address_uri: 10.0.0.201
        ip_subnet: 10.0.0.10/24
      internal_api:
        ip_address: 172.16.2.201
        ip_address_uri: 172.16.2.201
        ip_subnet: 172.16.2.10/24
      management:
        ip_address: 192.168.1.201
        ip_address_uri: 192.168.1.201
        ip_subnet: 192.168.1.10/24
      storage:
        ip_address: 172.16.1.201
        ip_address_uri: 172.16.1.201
        ip_subnet: 172.16.1.10/24
      storage_mgmt:
        ip_address: 172.16.3.201
        ip_address_uri: 172.16.3.201
        ip_subnet: 172.16.3.10/24
      tenant:
        ip_address: 172.16.0.201
        ip_address_uri: 172.16.0.201
        ip_subnet: 172.16.0.10/24
    ...

    # Compute node parameters
    compute-00-rack01:
      ctlplane:
        ip_address: 192.168.24.11
        ip_address_uri: 192.168.24.11
        ip_subnet: 192.168.24.0/24
      internal_api:
        ip_address: 172.16.2.11
        ip_address_uri: 172.16.2.11
        ip_subnet: 172.16.2.10/24
      storage:
        ip_address: 172.16.1.11
        ip_address_uri: 172.16.1.11
        ip_subnet: 172.16.1.10/24
      tenant:
        ip_address: 172.16.0.11
        ip_address_uri: 172.16.0.11
        ip_subnet: 172.16.0.10/24
    ...

    # Ceph node parameters
    ceph-00-rack01:
      ctlplane:
        ip_address: 192.168.24.101
        ip_address_uri: 192.168.24.101
        ip_subnet: 192.168.24.0/24
      storage:
        ip_address: 172.16.1.101
        ip_address_uri: 172.16.1.101
        ip_subnet: 172.16.1.10/24
      storage_mgmt:
        ip_address: 172.16.3.101
        ip_address_uri: 172.16.3.101
        ip_subnet: 172.16.3.10/24
    ...

  # Virtual IP address parameters
  ControlPlaneVipData:
    fixed_ips:
    - ip_address: 192.168.24.5
    name: control_virtual_ip
    network:
      tags: [192.168.24.0/24]
      subnets:
      - ip_version: 4
  VipPortMap
    external:
      ip_address: 10.0.0.100
      ip_address_uri: 10.0.0.100
      ip_subnet: 10.0.0.100/24
    internal_api:
      ip_address: 172.16.2.100
      ip_address_uri: 172.16.2.100
      ip_subnet: 172.16.2.100/24
    storage:
      ip_address: 172.16.1.100
      ip_address_uri: 172.16.1.100
      ip_subnet: 172.16.1.100/24
    storage_mgmt:
      ip_address: 172.16.3.100
      ip_address_uri: 172.16.3.100
      ip_subnet: 172.16.3.100/24

  RedisVirtualFixedIPs:
    - ip_address: 192.168.24.6
        use_neutron: false

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

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

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

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

parameter_defaults:
  NodePortMap:
    controller-00-rack01
      ctlplane
        ip_address: 192.168.100.2
        ip_address_uri: 192.168.100.2
        ip_subnet: 192.168.100.0/24
...
    compute-00-rack01:
      ctlplane
        ip_address: 192.168.100.3
        ip_address_uri: 192.168.100.3
        ip_subnet: 192.168.100.0/24
...
  ControlPlaneVipData:
    fixed_ips:
    - ip_address: 192.168.100.1
    name: control_virtual_ip
    network:
      tags: [192.168.100.0/24]
    subnets:
    - ip_version: 4
  VipPortMap:
    external:
      ip_address: 10.0.0.100
      ip_address_uri: 10.0.0.100
      ip_subnet: 10.0.0.100/24
....
  RedisVirtualFixedIPs:1
    - ip_address: 192.168.100.10
      use_neutron: false

配置预置备节点时，必须将基于 heat 的主机名映射到实际主机名，以便 ansible-playbook 能够到达可解析主机。请使用 HostnameMap 来映射这些值。

在 undercloud 主机上完成以下步骤，为已部署的节点配置 Ceph。

运行 openstack overcloud deploy 命令时，Ansible 配置您在 OVERCLOUD_HOSTS 变量中定义为 Ceph 客户端的主机。

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

以下命令是示例 overcloud 部署命令，且环境文件特定于预置备的架构：

$ source ~/stackrc
(undercloud)$ openstack overcloud deploy \
  --disable-validations \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
  -e /home/stack/templates/deployed-ports.yaml \
  -e /home/stack/templates/hostname-map.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 密钥，请为初始 SSH 连接指定包含 --overcloud-ssh-user 和 --overcloud-ssh-key（默认为 ~/.ssh/id_rsa）的凭证。为了限制暴露使用 --overcloud-ssh-key 选项指定的私钥，director 不会将该密钥传递给任何 API 服务，如 heat，而只有 director openstack overcloud deploy 命令使用此密钥为 tripleo-admin 用户启用访问权限。

director 生成凭据文件，其中包含从 undercloud 操作 overcloud 所需的凭据。director 将此文件保存为 stack 用户主目录的 overcloudrc 文件。

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

执行以下操作以扩展 overcloud 节点：

在缩减操作中，您可以为 OSP 置备或预置备节点使用主机名。您也可以将 UUID 用于 OSP 置备的节点。但是，预先提供的节点没有 UUID，因此您始终使用主机名。将 hostname 或 UUID 值传递给 openstack overcloud node delete 命令。

流程

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

关闭移除的节点后，将其重新置备为基础操作系统配置，以免它们未来意外加入 overcloud。