Red Hat Training

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

第 11 章 扩展 overcloud

警告

如果使用了计算实例高可用性功能(或称为“实例 HA”,如 High Availability for Compute Instances 中所述),则升级或扩展操作都无法执行。任何此类尝试都会失败。

如果启用了实例 HA 功能,必须先禁用然后再执行升级或扩展。为此,可按照 Rollback 中的说明来执行 rollback

在某些情况下,您可能需要在创建 overcloud 后添加或删除节点。例如,可能需要为 overcloud 添加计算节点。这样的情形需要更新 overcloud。

下表介绍了对每个节点类型进行扩展的支持信息:

表 11.1. 每个节点类型的扩展支持

节点类型

扩充

缩小

备注

Controller

N

N

 

Compute

Y

Y

 

Ceph Storage 节点

Y

N

在初始创建的 overcloud 中必须至少有一个 Ceph 存储节点。

Block Storage 节点

N

N

 

Object Storage 节点

Y

Y

需要手工进行 ring 管理。相关详情请参阅 第 11.6 节 “替换 Object 存储节点”

重要

在进行 overcloud 扩展前,确保至少有 10 GB 的可用空间。这些可用空间将在节点部署过程中用于保存镜像转换和缓存。

11.1. 添加额外节点

为 director 的节点池添加更多节点,创建一个包括用来注册新节点信息的 JSON 文件(例如,newnodes.json):

{
  "nodes":[
    {
        "mac":[
            "dd:dd:dd:dd:dd:dd"
        ],
        "cpu":"4",
        "memory":"6144",
        "disk":"40",
        "arch":"x86_64",
        "pm_type":"pxe_ipmitool",
        "pm_user":"admin",
        "pm_password":"p@55w0rd!",
        "pm_addr":"192.168.24.207"
    },
    {
        "mac":[
            "ee:ee:ee:ee:ee:ee"
        ],
        "cpu":"4",
        "memory":"6144",
        "disk":"40",
        "arch":"x86_64",
        "pm_type":"pxe_ipmitool",
        "pm_user":"admin",
        "pm_password":"p@55w0rd!",
        "pm_addr":"192.168.24.208"
    }
  ]
}

如需了解与这些参数相关的信息,请参阅 第 6.1 节 “为 overcloud 注册节点”

运行以下命令注册这些节点:

$ source ~/stackrc
(undercloud) $ openstack overcloud node import newnodes.json

在注册完这些节点后,为它们启动内省进程。为每个新节点运行以下命令:

(undercloud) $ openstack baremetal node manage [NODE UUID]
(undercloud) $ openstack overcloud node introspect [NODE UUID] --provide

这会发现节点,并为它们创建硬件属性的基准数据。

在内省操作完成后,把新节点标记为相应的角色。例如,使用以下命令把节点标记为一个 Compute 节点:

(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]

设置部署时使用的引导镜像。找到 bm-deploy-kernelbm-deploy-ramdisk 镜像的 UUID:

(undercloud) $ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+

在新节点的 deploy_kerneldeploy_ramdisk 设置中使用这些 UUID:

(undercloud) $ openstack baremetal node set --driver-info deploy_kernel='09b40e3d-0382-4925-a356-3a4b4f36b514' [NODE UUID]
(undercloud) $ openstack baremetal node set --driver-info deploy_ramdisk='765a46af-4417-4592-91e5-a300ead3faf6' [NODE UUID]

若要扩展 overcloud,需要使用角色所需的节点数量,重新运行 openstack overcloud deploy。例如,扩展到 5 个 Compute 节点:

parameter_defaults:
  ...
  ComputeCount: 5
  ...

使用更新后的文件(在本示例中,该文件名为 node-info.yaml),重新运行部署命令:

(undercloud) $ openstack overcloud deploy --templates -e /home/stack/templates/node-info.yaml [OTHER_OPTIONS]

这会更新整个 overcloud 栈。请注意,这只会更新栈,而不会删除 overcloud 或替换栈。

重要

务必包含初始 overcloud 创建中的所有环境文件和选项。其中包括非计算节点的相同扩展参数。

11.2. 删除 Compute 节点

在某些情况下,您可能需要从 overcloud 中删除计算节点。例如,需要替换有问题的计算节点。

重要

在从 overcloud 中删除计算节点前,先将该节点上的工作负载迁移到其他计算节点。请参阅???了解详细信息。

接下来,在 overcloud 中禁用节点的计算服务。这会停止在此节点上调度新的实例。

$ source ~/stack/overcloudrc
(overcloud) $ openstack compute service list
(overcloud) $ openstack compute service set [hostname] nova-compute --disable

切换回 undercloud:

(overcloud) $ source ~/stack/stackrc

若要删除 overcloud 节点,需要使用本地模板文件对 director 中的 overcloud 栈进行更新。首先,确定 overcloud 栈的 UUID:

(undercloud) $ openstack stack list

找到要被删除的节点的 UUID:

(undercloud) $ openstack server list

运行以下命令来从栈中删除节点,并相应地更新计划:

(undercloud) $ openstack overcloud node delete --stack [STACK_UUID] --templates -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]
重要

如果在创建 overcloud 时传递了额外的环境文件,请使用 -e--environment-file 选项再次传递它们来避免对 overcloud 进行不必要的手动更改。

重要

在继续进行操作前,请确认 openstack overcloud node delete 命令已运行完。使用 openstack stack list 命令检查 overcloud 栈的状态是否已变为 UPDATE_COMPLETE

最后,删除节点的 Compute 服务:

(undercloud) $ source ~/stack/overcloudrc
(overcloud) $ openstack compute service list
(overcloud) $ openstack compute service delete [service-id]

删除节点的 Open vSwitch 代理:

(overcloud) $ openstack network agent list
(overcloud) $ openstack network agent delete [openvswitch-agent-id]

现在,可以安全地把节点从 overcloud 中删除,并将它部署用于其他目的。

11.3. 替换 Compute 节点

当一个 Compute 节点出现问题时,您可以使用一个正常的节点替换它。使用以下步骤替换 Compute 节点:

这个过程确保了替换节点的操作不会影响到任何实例的可用性。

11.4. 替换 Controller 节点

在一些情况下,高可用性集群中的 Controller 节点可能会出现故障。在这种情况下,您需要把这个节点从集群中删除,并使用一个新 Controller 节点替换它。另外,还要保证节点可以和集群中的其它节点进行连接。

本节介绍了如何替换控制器节点。此过程包括运行 openstack overcloud deploy 命令来通过替换控制器节点的请求更新 overcloud。请注意,此过程不是完全自动的;在 overcloud 栈更新过程中,openstack overcloud deploy 命令会在某个时点上报告失败,overcloud 栈更新过程随之停止。这时,需要一些人工干预,然后 openstack overcloud deploy 进程才会继续。

重要

以下操作过程仅适用于高可用性环境。在只有一个 Controller 节点的情况下不要使用该过程。

11.4.1. 预检查

在尝试替换 overcloud 控制器节点前,务必要检查 Red Hat OpenStack Platform 环境的当前状态;此检查有助于避免在替换控制器节点的过程中出现混乱。参照以下初步检查列表,确定是否可以安全地执行控制器节点替换。在 undercloud 中执行这些检查的所有命令。

  1. 在 undercloud 中检查 overcloud 栈的当前状态:

    $ source stackrc
    (undercloud) $ openstack stack list --nested

    overcloud 栈以及它们的子栈的状态需要是 CREATE_COMPLETEUPDATE_COMPLETE

  2. 对 undercloud 数据库进行备份:

    (undercloud) $ mkdir /home/stack/backup
    (undercloud) $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz
  3. 确认您的 undercloud 拥有 10 GB 的可用存储空间,以容纳部署新节点期间的镜像缓存和转换。
  4. 在运行的 Controller 节点上检查 Pacemaker 的状态。例如,运行的 Controller 节点的 IP 地址是 192.168.0.47,使用以下命令获得 Pacemaker 的状态:

    (undercloud) $ ssh heat-admin@192.168.0.47 'sudo pcs status'

    这个命令的输出应该显示,所有服务都在存在的节点上运行,并已在出现故障的节点上停止运行。

  5. 检查 overcloud 的 MariaDB 集群中各个节点的以下参数:

    • wsrep_local_state_comment: Synced
    • wsrep_cluster_size: 2

      使用以下命令在每个运行的 Controller 节点上检查这些参数(IP 地址分别为 192.168.0.47 和 192.168.0.46):

      (undercloud) $ for i in 192.168.0.47 192.168.0.46 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql -p\$(sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password) --execute=\"SHOW STATUS LIKE 'wsrep_local_state_comment'; SHOW STATUS LIKE 'wsrep_cluster_size';\""; done
  6. 检查 RabbitMQ 的状态。例如,一个运行节点的 IP 地址是 192.168.0.47,使用以下命令获得状态值

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo docker exec \$(sudo docker ps -f name=rabbitmq-bundle -q) rabbitmqctl cluster_status"

    running_nodes 应该只显示两个可用的节点,而不会显示有故障的节点。

  7. 如果启用了隔离服务,需要禁用它。例如,一个运行的 Controller 节点的 IP 地址是 192.168.0.47,使用以下命令禁用隔离服务:

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"

    使用以下命令检查隔离服务的状态:

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"
  8. 在 director 节点上检查 nova-compute 服务:

    (undercloud) $ sudo systemctl status openstack-nova-compute
    (undercloud) $ openstack hypervisor list

    以上命令的输出应该显示所有没有处于维护模式的节点的状态为 up

  9. 确保所有 undercloud 服务都在运行:

    (undercloud) $ sudo systemctl -t service

11.4.2. 删除 Ceph Monitor 守护进程

这个操作过程旨在从存储集群中删除 ceph-mon 守护进程。如果 Controller 节点正在运行 Ceph monitor 服务,请完成以下步骤以删除 ceph-mon 守护进程。这个操作过程假设 Controller 可供连接。

注意

在集群中添加新的 Controller 后,会随之添加新的 Ceph monitor 守护进程。

  1. 连接到要被替换的 Controller,并改用 root 用户身份:

    # ssh heat-admin@192.168.0.47
    # sudo su -
    注意

    如果无法连接到该 Controller,请跳过第 1 步和第 2 步,然后在能够正常工作的任意 Controller 节点上从第 3 步开始继续执行这个操作过程。

  2. 以 root 用户的身份,停止该监控器:

    # systemctl stop ceph-mon@<monitor_hostname>

    例如:

    # systemctl stop ceph-mon@overcloud-controller-2
  3. 从集群中删除该监控器:

    # ceph mon remove <mon_id>
  4. 在 Ceph monitor 节点上,从 /etc/ceph/ceph.conf 中删除该监控器的条目。例如,如果删除的是 controller-2,请删除 controller-2 的 IP 和主机名。

    删除前:

    mon host = 172.18.0.21,172.18.0.22,172.18.0.24
    mon initial members = overcloud-controller-2,overcloud-controller-1,overcloud-controller-0

    删除后:

    mon host = 172.18.0.22,172.18.0.24
    mon initial members = overcloud-controller-1,overcloud-controller-0
  5. 在其他的 overcloud 节点上,对 /etc/ceph/ceph.conf 执行相同的更改。

    注意

    在添加用于替换的 Controller 节点后,director 会在相关的 overcloud 节点上更新 ceph.conf 文件。通常,这个配置文件仅由 director 管理,不应该进行手动编辑。但是,director 会在执行这一步时对其进行编辑。这样,即使其他节点在新节点完成添加前重启,也可确保一致性。

  6. (可选)归档监控器数据,并将其保存到其他服务器上:

    # mv /var/lib/ceph/mon/<cluster>-<daemon_id> /var/lib/ceph/mon/removed-<cluster>-<daemon_id>

11.4.3. 替换节点

找出要被删除节点的索引。节点索引是 nova list 输出中的实例名的一个后缀。

(undercloud) $ openstack server list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 861408be-4027-4f53-87a6-cd3cf206ba7a | overcloud-compute-0    |
| 0966e9ae-f553-447a-9929-c4232432f718 | overcloud-compute-1    |
| 9c08fa65-b38c-4b2e-bd47-33870bff06c7 | overcloud-compute-2    |
| a7f0f5e1-e7ce-4513-ad2b-81146bc8c5af | overcloud-controller-0 |
| cfefaf60-8311-4bc3-9416-6a824a40a9ae | overcloud-controller-1 |
| 97a055d4-aefd-481c-82b7-4a5f384036d2 | overcloud-controller-2 |
+--------------------------------------+------------------------+

本例中的目标是删除 overcloud-controller-1 节点,并替换为 overcloud-controller-3。首先,把节点设置为维护模式,从而使 director 不再重新部署故障节点。把 nova list 中的实例 ID 与 ironic node-list 中的节点 ID 相关联

(undercloud) $ openstack baremetal node list
+--------------------------------------+------+--------------------------------------+
| UUID                                 | Name | Instance UUID                        |
+--------------------------------------+------+--------------------------------------+
| 36404147-7c8a-41e6-8c72-a6e90afc7584 | None | 7bee57cf-4a58-4eaf-b851-2a8bf6620e48 |
| 91eb9ac5-7d52-453c-a017-c0e3d823efd0 | None | None                                 |
| 75b25e9a-948d-424a-9b3b-f0ef70a6eacf | None | None                                 |
| 038727da-6a5c-425f-bd45-fda2f4bd145b | None | 763bfec2-9354-466a-ae65-2401c13e07e5 |
| dc2292e6-4056-46e0-8848-d6e96df1f55d | None | 2017b481-706f-44e1-852a-2ee857c303c4 |
| c7eadcea-e377-4392-9fc3-cf2b02b7ec29 | None | 5f73c7d7-4826-49a5-b6be-8bfd558f3b41 |
| da3a8d19-8a59-4e9d-923a-6a336fe10284 | None | cfefaf60-8311-4bc3-9416-6a824a40a9ae |
| 807cb6ce-6b94-4cd1-9969-5c47560c2eee | None | c07c13e6-a845-4791-9628-260110829c3a |
+--------------------------------------+------+--------------------------------------+

把节点设为维护模式:

(undercloud) $ openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284

使用 control 配置集标记新节点。

(undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf

overcloud 的数据库必须在替换过程中继续运行。为了确保 Pacemaker 不会在此过程中停止 Galera 运行,可选择一个运行中的 Controller 节点,然后使用该 Controller 节点的 IP 地址在 undercloud 上执行以下命令:

(undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"

创建一个 YAML 文件(~/templates/remove-controller.yaml),它定义了要被删除的节点索引:

parameters:
  ControllerRemovalPolicies:
    [{'resource_list': ['1']}]
注意

您可以通过减少尝试安置到 Corosync 的次数来加快替换过程。为此,将 CorosyncSettleTries 参数纳入 ~/templates/remove-controller.yaml 环境文件中:

parameter_defaults:
  CorosyncSettleTries: 5

在确定节点索引后,重新部署 overcloud 并包含 remove-controller.yaml 环境文件:

(undercloud) $ openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]

如果在创建 overcloud 时传递了额外的环境文件或选项,现在请再次传递它们来避免对 overcloud 进行不必要的更改。

请注意,-e ~/templates/remove-controller.yaml 在这个实例中只需要一次。

director 会删除旧节点,创建一个新节点并更新 overcloud 栈。您可以使用以下命令检查 overcloud 栈的状态:

(undercloud) $ openstack stack list --nested

11.4.4. 手工干预

ControllerNodesPostDeployment 阶段,overcloud 栈更新会在 ControllerDeployment_Step1 中因出现 UPDATE_FAILED 错误而终止执行。这是因为一些 Puppet 模块不支持节点替换。因此,这一时点上需要一些人工干预。请执行以下配置步骤:

  1. 获得 Controller 节点的 IP 地址列表。例如:

    (undercloud) $ openstack server list -c Name -c Networks
    +------------------------+-----------------------+
    | Name                   | Networks              |
    +------------------------+-----------------------+
    | overcloud-compute-0    | ctlplane=192.168.0.44 |
    | overcloud-controller-0 | ctlplane=192.168.0.47 |
    | overcloud-controller-2 | ctlplane=192.168.0.46 |
    | overcloud-controller-3 | ctlplane=192.168.0.48 |
    +------------------------+-----------------------+
  2. 从每个节点的 Corosync 配置中删除失败的节点,并重启 Corosync。对于这个示例,登录到 overcloud-controller-0overcloud-controller-2 并运行以下命令:

    (undercloud) $ for NAME in overcloud-controller-0 overcloud-controller-2; do IP=$(openstack server list -c Networks -f value --name $NAME | cut -d "=" -f 2) ; ssh heat-admin@$IP "sudo pcs cluster localnode remove overcloud-controller-1; sudo pcs cluster reload corosync"; done
  3. 登录到剩下的节点之一,使用 crm_node 命令从集群中删除节点:

    (undercloud) $ ssh heat-admin@192.168.0.47
    [heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force

    保持在这个节点的登录。

  4. 从 RabbitMQ 集群中删除故障节点:

    [heat-admin@overcloud-controller-0 ~]$ sudo docker exec -it $(sudo docker ps -f name=rabbitmq-bundle -q) rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1
  5. 更新 Galera 集群的节点列表并刷新集群:

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera cluster_host_map="overcloud-controller-0:overcloud-controller-0.internalapi.localdomain;overcloud-controller-3:overcloud-controller-3.internalapi.localdomain;overcloud-controller-2:overcloud-controller-2.internalapi.localdomain" wsrep_cluster_address="gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-3.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain"
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource refresh galera
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galera
  6. 为集群添加新节点:

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3
  7. 启动新的 Controller 节点:

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start overcloud-controller-3

手动配置已完成。保持登录到 Controller 的状态。

打开一个新的终端,重新运行 overcloud 部署命令以继续栈的更新:

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]
重要

如果在创建 overcloud 时传递了额外的环境文件或选项,现在请再次传递它们来避免对 overcloud 进行不必要的更改。但请注意,此时不再需要 remove-controller.yaml 文件。

11.4.5. 完成配置 overcloud 服务

完成 overcloud 栈的更新之后,应设置适当的集群节点属性,允许 pacemaker 在新加入的控制器节点上运行控制器服务。在一个现有的控制器节点上(例如 overcloud-controller-0)运行以下命令:

[heat-admin@overcloud-controller-0 ~]$ for i in $(sudo pcs property | grep overcloud-controller-0: | cut -d' ' -f 3- | tr  ' ' '\n' | grep role); do sudo pcs property set --node overcloud-controller-3 $i; done

从此以后,由 pacemaker 托管的服务将在新加入的 controller 节点上启动。

执行最后的状态检查来确保服务在正确运行:

[heat-admin@overcloud-controller-0 ~]$ sudo pcs status
注意

如果有服务失败,请在解决相关问题后使用 pcs resource refresh 命令重启相应的服务。

退出 director

[heat-admin@overcloud-controller-0 ~]$ exit

11.4.6. 完成 L3 代理路由器的配置

overcloudrc 文件执行 source 命令,从而可以和 overcloud 进行交互。检查您的路由器,确保 overcloud 环境中的 L3 代理正确托管了路由器。本例中使用了名为 r1 的路由器:

$ source ~/overcloudrc
(overcloud) $ neutron l3-agent-list-hosting-router r1

这个命令可能仍然会显示旧节点而不是新节点。要替换它,列出环境中的 L3 网络代理:

(overcloud) $ neutron agent-list | grep "neutron-l3-agent"

找出新节点和旧节点上代理的 UUID。把路由添加到新节点上的代理,并从旧节点上删除。例如:

(overcloud) $ neutron l3-agent-router-add fd6b3d6e-7d8c-4e1a-831a-4ec1c9ebb965 r1
(overcloud) $ neutron l3-agent-router-remove b40020af-c6dd-4f7a-b426-eba7bac9dbc2 r1

在路由器上进行最后的检查,确认所有都已激活:

(overcloud) $ neutron l3-agent-list-hosting-router r1

删除那些指向旧的 Controller 节点的 Neutron 代理。例如:

(overcloud) $ neutron agent-list -F id -F host | grep overcloud-controller-1
| ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb | overcloud-controller-1.localdomain |
(overcloud) $ neutron agent-delete ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb

11.4.7. 完成 Compute 服务配置

已删除节点的计算服务仍然存在于 overcloud 中,需要删除。对 overcloudrc 文件执行 source 命令,从而可以和 overcloud 进行交互。检查已删除节点的计算服务:

[stack@director ~]$ source ~/overcloudrc
(overcloud) $ openstack compute service list --host overcloud-controller-1.localdomain

删除已删除节点的 compute 服务:

(overcloud) $ for SERVICE in $(openstack compute service list --host overcloud-controller-1.localdomain -f value -c ID) ; do openstack compute service delete $SERVICE ; done

11.4.8. 结果

失败的 Controller 节点和它的相关服务被一个新节点替代。

重要

如果禁用了 Object Storage 的自动 ring 构建(如 第 11.6 节 “替换 Object 存储节点”),则需要手工为新节点构建 Object Storage ring 文件。如需了解更多与手工构建 ring 文件相关的信息,请参阅 第 11.6 节 “替换 Object 存储节点”

11.5. 替换 Ceph 存储节点

director 提供了一个在 director 创建的集群中替换 Ceph Storage 节点的方法。相关说明可在 Deploying an Overcloud with Containerized Red Hat Ceph 指南中找到。

11.6. 替换 Object 存储节点

本节介绍了如何在保持集群完整性的情况下替换 Object Storage 节点。在这个示例中,有一个带有 2 个节点 的 Object Storage 集群,它需要更换 overcloud-objectstorage-1 节点。我们需要添加一个额外的节点,然后移除 overcloud-objectstorage-1(实际上是替换它)。

  1. 使用以下内容,创建一个名为 ~/templates/swift-upscale.yaml 的环境文件:

    parameter_defaults:
      ObjectStorageCount: 3

    ObjectStorageCount 定义了环境中存在的 Object Storage 节点数量。在这种情况下,我们将节点从 2 个扩展到 3 个。

  2. openstack overcloud deploy 命令中包含 swift-upscale.yaml 文件及 overcloud 的其余环境文件 (ENVIRONMENT_FILES):

    $ source ~/stackrc
    (undercloud) $ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml
    注意

    swift-upscale.yaml 添加到环境文件列表的最后,从而使它的参数可以覆盖前面的环境文件参数。

    重新部署完成后,overcloud 中现在包含一个额外的 Object Storage 节点。

  3. 现在需要将数据复制到新节点中。移除节点(在本例中,为 overcloud-objectstorage-1)之前,应等待 replication pass 在新节点操作完成。您可以通过 /var/log/swift/swift.log 查看复制传递的进度。传递完成后,Object Storage 服务应记录类似以下的条目:

    Mar 29 08:49:05 localhost object-server: Object replication complete.
    Mar 29 08:49:11 localhost container-server: Replication run OVER
    Mar 29 08:49:13 localhost account-server: Replication run OVER
  4. 为了从 ring 中删除旧节点,减少 swift-upscale.yamlObjectStorageCount 的值。在这个示例中,我们把它减为 2:

    parameter_defaults:
      ObjectStorageCount: 2
  5. 创建一个新环境文件,命名为 remove-object-node.yaml。该文件将确认和移除指定的 Object Storage 节点。以下内容指定了 overcloud-objectstorage-1 的移除:

    parameter_defaults:
      ObjectStorageRemovalPolicies:
        [{'resource_list': ['1']}]
  6. 在部署命令中包括这两个环境文件:

    (undercloud) $ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml -e remove-object-node.yaml ...

director 从 overcloud 中删除对象存储节点,并更新 overcloud 中的其他节点来使删除生效。

11.7. 将节点列入黑名单

您可以阻止 overcloud 节点获得更新的部署内容。这在某些情况下非常有用,比如,您准备扩展新节点,同时想阻止现有节点获得核心 Heat 模板集合中更新的参数集和资源。换句话说,列入黑名单的节点将完全不受栈操作的影响。

在环境文件中使用 DeploymentServerBlacklist 参数可创建黑名单。

设置黑名单

DeploymentServerBlacklist 参数是服务器名称列表。可以将其写入新的环境文件,或将参数值添加到现有的自定义环境文件,然后将此文件传递给部署命令:

parameter_defaults:
  DeploymentServerBlacklist:
    - overcloud-compute-0
    - overcloud-compute-1
    - overcloud-compute-2
注意

参数值中的服务器名称是由 OpenStack Orchestration (heat) 规定的名称,并非实际的服务器主机名。

将此环境文件纳入 openstack overcloud deploy 命令中。例如:

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e server-blacklist.yaml \
  [OTHER OPTIONS]

Heat 会将列表中的任何服务器列入黑名单,阻止其获得更新的 Heat 部署内容。在栈操作完成后,黑名单中的服务器不会发生任何变化。您也可以在操作过程中关闭或停止 os-collect-config 代理。

警告
  • 将节点列入黑名单时要非常谨慎。在使用黑名单前,必须完全清楚在有黑名单的情况下如何应用所要求的更改。因为使用黑名单功能有可能造成栈停止工作,或对 overcloud 执行不正确的配置。例如,如果集群配置更改适用于 Pacemaker 集群的所有成员,那么,在执行更改时将 Pacemaker 集群的某个成员列入黑名单就会导致集群出现问题。
  • 不要在更新或升级过程中使用黑名单。这些过程本身有一些方法可将更改操作与特定服务器进行隔离。如需更多信息,请参阅 Upgrading Red Hat OpenStack Platform 文档。
  • 将服务器加入黑名单后,不允许再对这些节点进行更改操作,除非将其从黑名单中移除。这包括更新、升级、扩展、缩减和节点替换等操作。

清除黑名单

要清除黑名单以便对其中节点执行后续的栈操作,可编辑 DeploymentServerBlacklist,使其成为空阵列:

parameter_defaults:
  DeploymentServerBlacklist: []
警告

不要直接省略 DeploymentServerBlacklist 参数。如果省略该参数,overcloud 部署将使用先前保存的参数值。