Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

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

本章介绍了使用预配置节点来配置 OpenStack Platform 环境的基本步骤。这种配置情境与标准的 overcloud 创建场景之间存在多项差异:

  • 您可以使用外部工具配置节点,让 director 仅控制 overcloud 的配置。
  • 您无需依赖 director 的配置方法,可直接使用节点。在不实施电源管理控制的情况下创建 overcloud,或者使用具有 DHCP/PXE 引导限制的网络时,这一点非常有用。
  • director 不使用 OpenStack Compute (nova)、OpenStack Bare Metal (ironic) 或者 OpenStack Image (glance) 来管理节点。
  • 预配置节点使用自定义分区布局。

本场景提供的是基本配置,不包含任何自定义功能。但是,您可以按照 Advanced Overcloud Customization 指南中的说明,向这类基本 overcloud 添加高级配置选项,并按照您的具体规格进行自定义。

重要

不支持在 overcloud 中混用预配置节点和 director 配置节点。

配置要求

  • 第 4 章 安装 undercloud中创建的 director 节点。
  • 一组作为节点的裸机。所需的节点数量由您需要创建的 overcloud 类型所决定(请参阅第 3.1 节 “规划节点的实施角色”,以了解与 overcloud 角色有关的信息)。这些机器还需要满足每个节点类型的相应要求。如需了解这些要求,请参阅第 2.4 节 “overcloud 的配置要求”。这些节点需要安装 Red Hat Enterprise Linux 7.3 操作系统的最新最低版本。
  • 用于管理预配置节点的一个网络连接。本情境需要具备对节点的不间断 SSH 访问权限以进行编配代理配置。
  • Control Plane 网络的一个网络连接。这种网络具备两种主要情境:

    • 将 Provisioning 网络用作 Control Plane,这种是默认情境。这种网络通常是预配置节点至 director 的 3 层 (L3) 可路由网络连接。本情境示例使用以下 IP 地址分配:

      表 8.1. Provisioning 网络 IP 分配信息

      节点名IP 地址

      Director

      192.168.24.1

      Controller

      192.168.24.2

      Compute

      192.168.24.3

    • 使用单独的网络。当 director 的 Provisioning 网络是一种专用的不可路由的网络时,您可以从任何子网定义节点的 IP 地址,通过公共 API 端点与 director 通讯。本情境有一些需要注意的地方,详情请参阅第 8.6 节 “使用单独的 overcloud 节点网络”章节。
  • 本示例中的所有其他网络类型使用 Control Plane 网络来提供 OpenStack 服务。不过,您可以为其他网络流量类型创建额外的网络。

8.1. 创建配置节点的用户

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

  1. 在每个 overcloud 节点上,创建名为 stack 的用户,并为每个节点设置密码。例如,在 Controller 节点上运行以下命令:

    [root@controller ~]# useradd stack
    [root@controller ~]# passwd stack  # specify a password
  2. 进行以下操作以使这个用户使用 sudo 时不需要输入密码:

    [root@controller ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
    [root@controller ~]# chmod 0440 /etc/sudoers.d/stack
  3. 在所有预配置节点上创建和配置 stack 用户之后,将 stack 用户的公共 SSH 密钥从 director 节点复制到每个 overcloud 节点。例如,将 director 的公共 SSH 密钥复制到 Controller 节点:

    [stack@director ~]$ ssh-copy-id stack@192.168.24.2

8.2. 为节点注册操作系统

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

  1. 运行注册命令,按照提示输入您的客户门户用户名和密码:

    [root@controller ~]# sudo subscription-manager register
  2. 找到 Red Hat OpenStack Platform 13 所在的权利池:

    [root@controller ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
  3. 使用上一步中找到的池 ID 来添加 Red Hat OpenStack Platform 13 的权利:

    [root@controller ~]# sudo subscription-manager attach --pool=pool_id
  4. 禁用所有默认软件仓库:

    [root@controller ~]# sudo subscription-manager repos --disable=*
  5. 启用所需的 Red Hat Enterprise Linux 软件仓库。

    1. 对于 x86_64 系统,请运行:

      [root@controller ~]# 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-2-osd-rpms --enable=rhel-7-server-rhceph-2-mon-rpms --enable=rhel-7-server-rhceph-2-tools-rpms
    2. 对于 POWER 系统,请运行:

      [root@controller ~]# sudo subscription-manager repos --enable=rhel-7-for-power-le-rpms --enable=rhel-7-server-openstack-13-for-power-le-rpms
    重要

    仅启用 第 2.5 节 “软件仓库的要求”中列出的软件仓库。其他软件仓库都可能会造成软件包和软件冲突,请勿启用任何其他软件仓库。

  6. 更新您的系统,确保您具备最新的基础系统软件包:

    [root@controller ~]# sudo yum update -y
    [root@controller ~]# sudo reboot

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

8.3. 在节点上安装用户代理

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

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

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

8.4. 为 director 配置 SSL/TLS 访问权限

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

  1. 将证书授权机构文件复制到各预配置节点上的 /etc/pki/ca-trust/source/anchors/ 目录中。
  2. 在每个 overcloud 节点上运行以下命令:

    [root@controller ~]#  sudo update-ca-trust extract

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

8.5. 为 Control Plane 配置网络

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

  • director 的 Control Plane 网络,这是使用 undercloud.conf 文件中的 network_cidr 参数定义的子网。该节点需要直接访问此子网,或者需要通过路由访问此子网。
  • director 的 Public API 端点,由 undercloud.conf 文件中的 undercloud_public_host 参数指定。当您无法通过 L3 路由至 Control Plane 时,或者在轮询 director 的元数据期间计划使用 SSL/TLS 通信时,此选项都可用。请参阅 ???了解配置 overcloud 节点以使用 Public API 端点的更多步骤。

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

使用网络隔离

网络隔离允许您对服务进行分组,以使用特定的网络,包括 Control Plane。请参阅 Advanced Overcloud Customization 指南,以了解多种网络隔离策略。此外,您也可以为 Control Plane 上的节点指定特定的 IP 地址。有关隔离网络和创建可预测节点放置策略的更多信息,请参阅 Advanced Overcloud Customization 指南中的以下章节:

注意

使用网络隔离时,确保您的 NIC 模板不包含用于访问 undercloud 的 NIC。这些模板可能会重新配置 NIC,从而导致部署期间出现连接和配置问题。

分配 IP 地址

如果不使用网络隔离,您可以使用单个 Control Plane 网络来管理所有服务。这需要手动配置每个节点的 Control Plane NIC,以便使用 Control Plane 网络范围内的 IP 地址。如果将 director 的 Provisioning 网络用作 Control Plane,确保选定的 overcloud IP 地址不在 DHCP 所提供的置备范围(dhcp_startdhcp_end)和内省范围(inspection_iprange)之内。

创建标准 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。映射定义:

  1. 分配的名称,其格式为 <node_hostname>-<network>。例如:controller-ctlplanecompute-ctlplane
  2. IP 分配,它采用以下参数形式:

    • fixed_ips/ip_address - 为 control plane 指定固定的 IP 地址。使用 ip_address 列表中的多个参数来定义多个 IP 地址。
    • subnets/cidr - 定义子网的 CIDR 值。

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

8.6. 使用单独的 overcloud 节点网络

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

对于此情境,有几个需要满足的要求:

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

表 8.2. Provisioning 网络 IP 分配信息

节点名IP 地址或 FQDN

Director(内部 API)

192.168.24.1 (Provisioning 网络和 Control Plane)

Director(公共 API)

10.1.1.1 / director.example.com

overcloud 虚拟 IP

192.168.100.1

Controller

192.168.100.2

Compute

192.168.100.3

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

编配配置

在 undercloud 上启用 SSL/TLS 通讯之后,director 为大部分服务提供公共 API 端点。但是,OpenStack Orchestration (heat) 使用内部端点作为默认的元数据供应商。这表示,需要对 undercloud 做一些修改,以便 overcloud 节点可以在公共端点访问 OpenStack Orchestration。此修改涉及更改 director 上的某些 Puppet hieradata。

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

  1. 如果您尚未使用 hieradata_override 文件,请创建一个新文件。本示例使用了位于 /home/stack/hieradata.yaml 的文件。
  2. /home/stack/hieradata.yaml 中包含下列 hieradata:

    heat_clients_endpoint_type: public
    heat::engine::default_deployment_signal_transport: TEMP_URL_SIGNAL

    此操作会将端点类型从默认的 internal 更改为 public,同时将信令方法更改为使用 OpenStack Object Storage(swift)中的 TempURL。

  3. 在您的 undercloud.conf 中,将 hieradata_override 参数设置为 hieradata 文件的路径:

    hieradata_override = /home/stack/hieradata.yaml
  4. 重新运行 openstack overcloud install 命令,以实施新配置选项。

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

IP 地址分配

IP 分配方法与第 8.5 节 “为 Control Plane 配置网络”类似。但是,由于 Control Plane 无法从部署的服务器路由,您将使用 DeployedServerPortMap 参数从您选定的 overcloud 节点子网分配 IP 地址,包括用于访问 Control Plane 的虚拟 IP 地址。以下是从 第 8.5 节 “为 Control Plane 配置网络” 修改的 ctlplane-assignments.yaml 环境文件版本,融合了这种网络架构:

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
1
RedisVipPort 资源被映射至 network/ports/noop.yaml。出现这种映射的原因是默认的 Redis VIP 地址来自 Control Plane。在这种情况下,我们使用 noop 来禁用这种 Control Plane 映射。
2
EC2MetadataIpControlPlaneDefaultRoute 参数被设置为 Control Plane 虚拟 IP 地址的值。默认的 NIC 配置模板需要这些参数,且您必须将它们设置为可 ping 通的 IP 地址,以便通过部署期间执行的验证。或者,自定义 NIC 配置,使它们无需使用这些参数。

8.7. 利用预配置节点创建 overcloud

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

  • --disable-validations - 禁止对未用于预配置基础架构的服务执行基本的 CLI 验证功能,否则,部署将失败。
  • environments/deployed-server-environment.yaml - 用于创建和配置预配置基础架构的主要环境文件。这种环境文件用 OS::Heat::DeployedServer 资源代替 OS::Nova::Server 资源。
  • environments/deployed-server-bootstrap-environment-rhel.yaml -用于在预配置服务器上执行启动引导脚本的环境文件。此脚本安装额外的软件包,并为 overcloud 节点提供基本配置。
  • environments/deployed-server-pacemaker-environment.yaml - 用于在预配置 Controller 节点上进行 Pacemaker 配置的环境文件。 此文件的注册资源的命名空间使用来自 deployed-server/deployed-server-roles-data.yaml 的 Controller 角色名称,默认为 ControllerDeployedServer
  • deployed-server/deployed-server-roles-data.yaml - 一个示例自定义角色文件。此文件复制了默认的 roles_data.yaml,也包括各角色的 disable_constraints: True 参数。此参数会禁用生成的角色模板中的编配限制。这些限制适用于未搭配使用预配置基础架构的服务。

    使用您自己的自定义角色文件时,确保将各角色的 disable_constraints: True 参数包含在内。例如:

    - name: ControllerDeployedServer
      disable_constraints: True
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephMon
        - OS::TripleO::Services::CephExternal
        - OS::TripleO::Services::CephRgw
        ...

以下是一个 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 \
  -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 节点上的编配代理来轮询元数据服务器。下一节将介绍如何配置节点以开始轮询元数据服务器。

8.8. 轮询元数据服务器

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

重要

仅在初始部署时使用自动配置。扩展节点时不要使用自动配置。

自动配置

director 的核心 Heat 模板集包含一个脚本,在 overcloud 节点上对 Heat 代理执行自动配置。此脚本要求您以 stack 用户的身份 source stackrc 文件,以便进行 director 验证并查询编配服务:

[stack@director ~]$ source ~/stackrc

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

OVERCLOUD_ROLES
待配置的以空格隔开的角色列表。这些角色与您的角色数据文件中定义的角色相关联。
[ROLE]_hosts
每个角色都需要一个环境变量,包括以空格隔开的、此角色中的节点 IP 地址列表。

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

(undercloud) $ export OVERCLOUD_ROLES="ControllerDeployedServer ComputeDeployedServer"
(undercloud) $ export ControllerDeployedServer_hosts="192.168.100.2"
(undercloud) $ export ComputeDeployedServer_hosts="192.168.100.3"

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

(undercloud) $ /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/get-occ-config.sh
注意

该脚本使用执行脚本的同一用户身份,通过 SSH 访问预配置节点。在这种情况下,该脚本以 stack 用户的身份进行验证。

该脚本完成以下操作:

  • 查询 director 的编配服务获取各节点的元数据 URL 。
  • 访问节点,使用各节点特定的元数据 URL 配置各节点的代理。
  • 重新启动编配代理服务。

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

手动配置

如果您更愿意在预配置节点上手动配置编配代理,请使用下列命令在 director 上查询编配服务以获取各节点的元数据 URL:

[stack@director ~]$ source ~/stackrc
(undercloud) $ 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 节点上:

  1. 删除现有的 os-collect-config.conf 模板。此操作可以确保代理不会覆盖我们手动做出的更改:

    $ sudo /bin/rm -f /usr/libexec/os-apply-config/templates/etc/os-collect-config.conf
  2. 配置 /etc/os-collect-config.conf 文件,使其使用对应的元数据 URL。例如,Controller 节点使用以下命令:

    [DEFAULT]
    collectors=request
    command=os-refresh-config
    polling_interval=30
    
    [request]
    metadata_url=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
  3. 保存这个文件。
  4. 重新启动 os-collect-config 服务:

    [stack@controller ~]$ sudo systemctl restart os-collect-config

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

8.9. 监控 overcloud 的创建过程

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

[stack@director ~]$ source ~/stackrc
(undercloud) $ heat stack-list --show-nested

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

8.10. 访问 overcloud

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

(undercloud) $ source ~/overcloudrc

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

(overcloud) $

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

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

8.11. 扩展预配置节点

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

扩展预配置节点

利用预配置节点扩展 overcloud 时,您需要配置各节点上的编配代理,以匹配 director 的节点数量。

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

  1. 依照配置要求准备新的预配置节点。
  2. 扩展节点。请参阅???了解这些说明。
  3. 执行部署命令之后,等稍等片刻,直至 director 创建新的节点资源。依照 第 8.8 节 “轮询元数据服务器” 中的说明,手动配置预配置节点以轮询 director 的编配服务器元数据 URL。

缩减预配置节点

使用预配置节点缩减 overcloud 时,请遵循 ??? 中显示的常规缩减说明。

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

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

注意

在将之前已经从 overcloud 移除的节点重新部署到新的基础操作系统之前,不要尝试再次使用它们。缩减流程只从 overcloud 堆栈移除节点,不会卸载任何软件包。

8.12. 移除预配置 overcloud

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

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

注意

在将之前已经从 overcloud 移除的节点重新部署到新的基础操作系统之前,不要尝试再次使用它们。移除流程只删除 overcloud 堆栈,不会卸载任何软件包。

8.13. 完成 overcloud 的创建

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