第 11 章 扩展 overcloud
如果使用了计算实例高可用性功能(或称为“实例 HA”,如 High Availability for Compute Instances 中所述),则升级或扩展操作都无法执行。任何此类尝试都会失败。
如果启用了实例 HA 功能,必须先禁用然后再执行升级或扩展。为此,可按照 Rollback 中的说明来执行 rollback。
在某些情况下,您可能需要在创建 overcloud 后添加或删除节点。例如,可能需要为 overcloud 添加计算节点。这样的情形需要更新 overcloud。
下表介绍了对每个节点类型进行扩展的支持信息:
节点类型 |
扩充 |
缩小 |
备注 |
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-kernel
和 bm-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_kernel
和 deploy_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 节点:
- 迁移 Compute 节点上的负载并关闭节点。详细信息,请参阅 第 9.10 节 “从 Compute 节点中迁移实例”。
- 从 overcloud 中删除计算节点。有关此过程的信息,请参阅第 11.2 节 “删除 Compute 节点”。
- 使用新的计算节点扩展 overcloud。有关此过程的信息,请参阅 第 11.1 节 “添加额外节点”。
这个过程确保了替换节点的操作不会影响到任何实例的可用性。
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 中执行这些检查的所有命令。
在 undercloud 中检查
overcloud
栈的当前状态:$ source stackrc (undercloud) $ openstack stack list --nested
overcloud
栈以及它们的子栈的状态需要是CREATE_COMPLETE
或UPDATE_COMPLETE
。对 undercloud 数据库进行备份:
(undercloud) $ mkdir /home/stack/backup (undercloud) $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz
- 确认您的 undercloud 拥有 10 GB 的可用存储空间,以容纳部署新节点期间的镜像缓存和转换。
在运行的 Controller 节点上检查 Pacemaker 的状态。例如,运行的 Controller 节点的 IP 地址是 192.168.0.47,使用以下命令获得 Pacemaker 的状态:
(undercloud) $ ssh heat-admin@192.168.0.47 'sudo pcs status'
这个命令的输出应该显示,所有服务都在存在的节点上运行,并已在出现故障的节点上停止运行。
检查 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
-
检查 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
应该只显示两个可用的节点,而不会显示有故障的节点。如果启用了隔离服务,需要禁用它。例如,一个运行的 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"
在 director 节点上检查
nova-compute
服务:(undercloud) $ sudo systemctl status openstack-nova-compute (undercloud) $ openstack hypervisor list
以上命令的输出应该显示所有没有处于维护模式的节点的状态为
up
。确保所有 undercloud 服务都在运行:
(undercloud) $ sudo systemctl -t service
11.4.2. 删除 Ceph Monitor 守护进程
这个操作过程旨在从存储集群中删除 ceph-mon
守护进程。如果 Controller 节点正在运行 Ceph monitor 服务,请完成以下步骤以删除 ceph-mon 守护进程。这个操作过程假设 Controller 可供连接。
在集群中添加新的 Controller 后,会随之添加新的 Ceph monitor 守护进程。
连接到要被替换的 Controller,并改用 root 用户身份:
# ssh heat-admin@192.168.0.47 # sudo su -
注意如果无法连接到该 Controller,请跳过第 1 步和第 2 步,然后在能够正常工作的任意 Controller 节点上从第 3 步开始继续执行这个操作过程。
以 root 用户的身份,停止该监控器:
# systemctl stop ceph-mon@<monitor_hostname>
例如:
# systemctl stop ceph-mon@overcloud-controller-2
从集群中删除该监控器:
# ceph mon remove <mon_id>
在 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
在其他的 overcloud 节点上,对
/etc/ceph/ceph.conf
执行相同的更改。注意在添加用于替换的 Controller 节点后,director 会在相关的 overcloud 节点上更新
ceph.conf
文件。通常,这个配置文件仅由 director 管理,不应该进行手动编辑。但是,director 会在执行这一步时对其进行编辑。这样,即使其他节点在新节点完成添加前重启,也可确保一致性。(可选)归档监控器数据,并将其保存到其他服务器上:
# 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 模块不支持节点替换。因此,这一时点上需要一些人工干预。请执行以下配置步骤:
获得 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 | +------------------------+-----------------------+
从每个节点的 Corosync 配置中删除失败的节点,并重启 Corosync。对于这个示例,登录到
overcloud-controller-0
和overcloud-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
登录到剩下的节点之一,使用
crm_node
命令从集群中删除节点:(undercloud) $ ssh heat-admin@192.168.0.47 [heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force
保持在这个节点的登录。
从 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
更新 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
为集群添加新节点:
[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3
启动新的 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
(实际上是替换它)。
使用以下内容,创建一个名为 ~/templates/swift-upscale.yaml 的环境文件:
parameter_defaults: ObjectStorageCount: 3
ObjectStorageCount
定义了环境中存在的 Object Storage 节点数量。在这种情况下,我们将节点从 2 个扩展到 3 个。在
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 节点。
现在需要将数据复制到新节点中。移除节点(在本例中,为
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
为了从 ring 中删除旧节点,减少
swift-upscale.yaml
中ObjectStorageCount
的值。在这个示例中,我们把它减为 2:parameter_defaults: ObjectStorageCount: 2
创建一个新环境文件,命名为
remove-object-node.yaml
。该文件将确认和移除指定的 Object Storage 节点。以下内容指定了overcloud-objectstorage-1
的移除:parameter_defaults: ObjectStorageRemovalPolicies: [{'resource_list': ['1']}]
在部署命令中包括这两个环境文件:
(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 部署将使用先前保存的参数值。