Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第 8 章 扩展 Overcloud
为实例实施高可用性期间无法执行任何升级或扩展操作(如计算实例高可用性中所述)。此类操作的任何尝试都会失败。
此外,为实例启用高可用性也会阻碍您未来使用 director 升级 overcloud,不论升级的幅度如何。如需更多信息,请参阅 https://access.redhat.com/solutions/2661641。
在某些情况下,您可能需要在创建 overcloud 后添加或删除节点。例如,可能需要为 overcloud 添加计算节点。这样的情形需要更新 overcloud。
下表介绍了对每个节点类型进行扩展的支持信息:
表 8.1. 每个节点类型的扩展支持
节点类型 |
扩充 |
缩小 |
备注 |
Controller |
N |
N | |
Compute |
Y |
Y | |
Ceph Storage 节点 |
Y |
N |
在初始创建的 overcloud 中必须至少有一个 Ceph 存储节点。 |
Block Storage 节点 |
N |
N | |
Object Storage 节点 |
Y |
Y |
需要手工进行 ring 管理。相关详情请参阅 第 8.6 节 “替换 Object 存储节点”。 |
在进行 overcloud 扩展前,确保至少有 10 GB 的可用空间。这些可用空间将在节点部署过程中用于保存镜像转换和缓存。
8.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.0.2.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.0.2.208" } ] }
如需了解与这些参数相关的信息,请参阅 第 5.1 节 “为 Overcloud 注册节点”。
运行以下命令注册这些节点:
$ openstack baremetal import --json newnodes.json
在注册完这些节点后,为它们启动内省进程。为每个新节点运行以下命令:
$ openstack baremetal node manage [NODE UUID] $ openstack overcloud node introspect [NODE UUID] --provide
这会发现节点,并为它们创建硬件属性的基准数据。
在内省操作完成后,把新节点标记为相应的角色。例如,使用以下命令把节点标记为一个 Compute 节点:
$ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]
设置部署时使用的引导镜像。找到 bm-deploy-kernel
和 bm-deploy-ramdisk
镜像的 UUID:
$ 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:
$ openstack baremetal node set --driver-info deploy_kernel='09b40e3d-0382-4925-a356-3a4b4f36b514' [NODE UUID] $ openstack baremetal node set --driver-info deploy_ramdisk='765a46af-4417-4592-91e5-a300ead3faf6' [NODE UUID]
若要扩展 overcloud,需要使用角色所需的节点数量,重新运行 openstack overcloud deploy
。例如,扩展到 5 个计算节点:
$ openstack overcloud deploy --templates --compute-scale 5 [OTHER_OPTIONS]
这会更新整个 overcloud 栈。请注意,这只会更新栈,而不会删除 overcloud 或替换栈。
务必包含初始 overcloud 创建中的所有环境文件和选项。其中包括非计算节点的相同扩展参数。
8.2. 删除 Compute 节点
在某些情况下,您可能需要从 overcloud 中删除计算节点。例如,需要替换有问题的计算节点。
在从 overcloud 中删除计算节点前,先将该节点上的工作负载迁移到其他计算节点。请参阅第 7.9 节 “从一个 Overcloud Compute 节点中迁移虚拟机”了解详细信息。
接下来,在 overcloud 中禁用节点的计算服务。这会停止在此节点上调度新的实例。
$ source ~/stack/overcloudrc $ openstack compute service list $ openstack compute service set [hostname] nova-compute --disable $ source ~/stack/stackrc
若要删除 overcloud 节点,需要使用本地模板文件对 director 中的 overcloud
栈进行更新。首先,确定 overcloud 栈的 UUID:
$ openstack stack list
找到要被删除的节点的 UUID:
$ openstack server list
运行以下命令来从栈中删除节点,并相应地更新计划:
$ 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 服务:
$ source ~/stack/overcloudrc $ openstack compute service delete [service-id] $ source ~/stack/stackrc
删除节点的 Open vSwitch 代理:
$ source ~/stack/overcloudrc $ openstack network agent list $ openstack network agent delete [openvswitch-agent-id] $ source ~/stack/stackrc
现在,可以安全地把节点从 overcloud 中删除,并将它部署用于其他目的。
8.3. 替换 Compute 节点
当一个 Compute 节点出现问题时,您可以使用一个正常的节点替换它。使用以下步骤替换 Compute 节点:
- 迁移 Compute 节点上的负载并关闭节点。详细信息,请参阅 第 7.9 节 “从一个 Overcloud Compute 节点中迁移虚拟机”。
- 从 overcloud 中删除计算节点。有关此过程的信息,请参阅第 8.2 节 “删除 Compute 节点”。
- 使用新的计算节点扩展 overcloud。有关此过程的信息,请参阅 第 8.1 节 “添加额外节点”。
这个过程确保了替换节点的操作不会影响到任何实例的可用性。
8.4. 替换 Controller 节点
在一些情况下,高可用性集群中的 Controller 节点可能会出现故障。在这种情况下,您需要把这个节点从集群中删除,并使用一个新 Controller 节点替换它。另外,还要保证节点可以和集群中的其它节点进行连接。
本节介绍了如何替换控制器节点。此过程包括运行 openstack overcloud deploy
命令来通过替换控制器节点的请求更新 overcloud。请注意,此过程不是完全自动的;在 overcloud 栈更新过程中,openstack overcloud deploy
命令会在某个时点上报告失败,overcloud 栈更新过程随之停止。这时,需要一些人工干预,然后 openstack overcloud deploy
进程才会继续。
8.4.1. 预检查
在尝试替换 overcloud 控制器节点前,务必要检查 Red Hat OpenStack Platform 环境的当前状态;此检查有助于避免在替换控制器节点的过程中出现混乱。参照以下初步检查列表,确定是否可以安全地执行控制器节点替换。在 undercloud 中执行这些检查的所有命令。
在 undercloud 中检查
overcloud
栈的当前状态:$ source stackrc $ openstack stack list --nested
overcloud
栈以及它们的子栈的状态需要是CREATE_COMPLETE
或UPDATE_COMPLETE
。对 undercloud 数据库进行备份:
$ mkdir /home/stack/backup $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz $ sudo systemctl stop openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-inspector.service openstack-ironic-inspector-dnsmasq.service $ sudo cp /var/lib/ironic-inspector/inspector.sqlite /home/stack/backup $ sudo systemctl start openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-inspector.service openstack-ironic-inspector-dnsmasq.service
- 确认您的 undercloud 拥有 10 GB 的可用存储空间,以容纳部署新节点期间的镜像缓存和转换。
在运行的 Controller 节点上检查 Pacemaker 的状态。例如,运行的 Controller 节点的 IP 地址是 192.168.0.47,使用以下命令获得 Pacemaker 的状态:
$ 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):
$ for i in 192.168.0.47 192.168.0.46 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_state_comment'\" ; sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_cluster_size'\""; done
-
检查 RabbitMQ 的状态。例如,一个运行节点的 IP 地址是 192.168.0.47,使用以下命令获得状态值
$ ssh heat-admin@192.168.0.47 "sudo rabbitmqctl cluster_status"
running_nodes
应该只显示两个可用的节点,而不会显示有故障的节点。如果启用了隔离服务,需要禁用它。例如,一个运行的 Controller 节点的 IP 地址是 192.168.0.47,使用以下命令禁用隔离服务:
$ ssh heat-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"
使用以下命令检查隔离服务的状态:
$ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"
在 director 节点上检查
nova-compute
服务:$ sudo systemctl status openstack-nova-compute $ openstack hypervisor list
以上命令的输出应该显示所有没有处于维护模式的节点的状态为
up
。确保所有 undercloud 服务都在运行:
$ sudo systemctl -t service
8.4.2. 替换节点
找出要被删除节点的索引。节点索引是 nova list
输出中的实例名的一个后缀。
[stack@director ~]$ 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 相关联
[stack@director ~]$ 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 | +--------------------------------------+------+--------------------------------------+
把节点设为维护模式:
[stack@director ~]$ openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284
使用 control
配置集标记新节点。
[stack@director ~]$ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf
创建一个 YAML 文件(~/templates/remove-controller.yaml
),它定义了要被删除的节点索引:
parameters: ControllerRemovalPolicies: [{'resource_list': ['1']}]
在确定节点索引后,重新部署 overcloud 并包含 remove-controller.yaml
环境文件:
[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]
如果在创建 overcloud 时传递了额外的环境文件或选项,现在请再次传递它们来避免对 overcloud 进行不必要的更改。
请注意,-e ~/templates/remove-controller.yaml
在这个实例中只需要一次。
director 会删除旧节点,创建一个新节点并更新 overcloud 栈。您可以使用以下命令检查 overcloud 栈的状态:
[stack@director ~]$ openstack stack list --nested
8.4.3. 手工干预
在 ControllerNodesPostDeployment
阶段,overcloud 栈更新会在 ControllerLoadBalancerDeployment_Step1
的步骤中出现因 UPDATE_FAILED
错误而终止执行的情况。这是因为一些 Puppet 模块不支持节点替换。因此,这一时点上需要一些人工干预。请执行以下配置步骤:
获得 Controller 节点的 IP 地址列表。例如:
[stack@director ~]$ openstack server list ... +------------------------+ ... +-------------------------+ ... | 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 | ... +------------------------+ ... +-------------------------+
在一个存在节点的
/etc/corosync/corosync.conf
文件中检查删除节点的nodeid
值。例如,节点overcloud-controller-0
(IP 地址为 192.168.0.47):[stack@director ~]$ ssh heat-admin@192.168.0.47 "sudo cat /etc/corosync/corosync.conf"
这个命令会显示一个
nodelist
,它包括了被删除节点(overcloud-controller-1
)的 ID:nodelist { node { ring0_addr: overcloud-controller-0 nodeid: 1 } node { ring0_addr: overcloud-controller-1 nodeid: 2 } node { ring0_addr: overcloud-controller-2 nodeid: 3 } }
记录下被删除节点的
nodeid
值以供以后使用。在这个示例中,它的值是 2。从每个节点的 Corosync 配置中删除失败的节点,并重启 Corosync。对于这个示例,登录到
overcloud-controller-0
和overcloud-controller-2
并运行以下命令:[stack@director] ssh heat-admin@192.168.0.47 "sudo pcs cluster localnode remove overcloud-controller-1" [stack@director] ssh heat-admin@192.168.0.47 "sudo pcs cluster reload corosync" [stack@director] ssh heat-admin@192.168.0.46 "sudo pcs cluster localnode remove overcloud-controller-1" [stack@director] ssh heat-admin@192.168.0.46 "sudo pcs cluster reload corosync"
登录到剩下的节点之一,使用
crm_node
命令从集群中删除节点:[stack@director] 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 rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1
从 MongoDB 中删除失败的节点。首先,找到节点 Interal API 连接的 IP 地址。
[heat-admin@overcloud-controller-0 ~]$ sudo netstat -tulnp | grep 27017 tcp 0 0 192.168.0.47:27017 0.0.0.0:* LISTEN 13415/mongod
检查这个节点是否是
primary
副本:[root@overcloud-controller-0 ~]# echo "db.isMaster()" | mongo --host 192.168.0.47:27017 MongoDB shell version: 2.6.11 connecting to: 192.168.0.47:27017/echo { "setName" : "tripleo", "setVersion" : 1, "ismaster" : true, "secondary" : false, "hosts" : [ "192.168.0.47:27017", "192.168.0.46:27017", "192.168.0.45:27017" ], "primary" : "192.168.0.47:27017", "me" : "192.168.0.47:27017", "electionId" : ObjectId("575919933ea8637676159d28"), "maxBsonObjectSize" : 16777216, "maxMessageSizeBytes" : 48000000, "maxWriteBatchSize" : 1000, "localTime" : ISODate("2016-06-09T09:02:43.340Z"), "maxWireVersion" : 2, "minWireVersion" : 0, "ok" : 1 } bye
从输出中可以判断当前节点是否是 primary 节点。如果不是,使用
primary
所指定节点的 IP 地址。从 primary 节点连接到 MongoDB:
[heat-admin@overcloud-controller-0 ~]$ mongo --host 192.168.0.47 MongoDB shell version: 2.6.9 connecting to: 192.168.0.47:27017/test Welcome to the MongoDB shell. For interactive help, type "help". For more comprehensive documentation, see http://docs.mongodb.org/ Questions? Try the support group http://groups.google.com/group/mongodb-user tripleo:PRIMARY>
检查 MongoDB 集群的状态:
tripleo:PRIMARY> rs.status()
_id
代表节点,在删除失败的节点时需要使用name
。在这里,我们删除 Node 1,它的name
是192.168.0.45:27017
:tripleo:PRIMARY> rs.remove('192.168.0.45:27017')
重要您需要针对
PRIMARY
副本集运行这个命令。如果您可以看到以下信息:"replSetReconfig command must be sent to the current replica set primary."
重新登录到
PRIMARY
节点上的 MongoDB。注意在删除失败节点的副本集时出现以下输出是正常的:
2016-05-07T03:57:19.541+0000 DBClientCursor::init call() failed 2016-05-07T03:57:19.543+0000 Error: error doing query: failed at src/mongo/shell/query.js:81 2016-05-07T03:57:19.545+0000 trying reconnect to 192.168.0.47:27017 (192.168.0.47) failed 2016-05-07T03:57:19.547+0000 reconnect 192.168.0.47:27017 (192.168.0.47) ok
退出 MongoDB:
tripleo:PRIMARY> exit
在 Galera 集群中更新节点列表:
[heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2
-
配置新节点上的 Galera 集群检查。将现有节点的
/etc/sysconfig/clustercheck
复制到新节点的同一位置上。 -
配置新节点上
root
用户的 Galera 访问权限。将现有节点的/root/.my.cnf
复制到新节点的同一位置上。 为集群添加新节点:
[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3
检查每个节点上的
/etc/corosync/corosync.conf
文件。如果新节点的nodeid
和已删除节点的相同,则需要把它更新为一个新的 nodeid 值。例如,/etc/corosync/corosync.conf
文件包括一个新节点(overcloud-controller-3
)的项:nodelist { node { ring0_addr: overcloud-controller-0 nodeid: 1 } node { ring0_addr: overcloud-controller-2 nodeid: 3 } node { ring0_addr: overcloud-controller-3 nodeid: 2 } }
请注意,新节点使用和被删除节点相同的
nodeid
。把这个值更新为一个没有被使用过的节点 ID 值。例如:node { ring0_addr: overcloud-controller-3 nodeid: 4 }
在包括新节点在内的所有 Controller 节点的
/etc/corosync/corosync.conf
文件中更新这个nodeid
值。只在存在的节点上重启 Corosync 服务。例如,在
overcloud-controller-0
上:[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster reload corosync
在
overcloud-controller-2
上:[heat-admin@overcloud-controller-2 ~]$ sudo pcs cluster reload corosync
不要在新节点上运行这个命令。
启动新的 Controller 节点:
[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start overcloud-controller-3
通过 Pacemaker 启用并重启一些服务。集群当前处于维护模式,您需要临时禁用它来启用服务。例如:
[heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=false --wait
等待 Galera 服务在所有节点上都已启动。
[heat-admin@overcloud-controller-3 ~]$ sudo pcs status | grep galera -A1 Master/Slave Set: galera-master [galera] Masters: [ overcloud-controller-0 overcloud-controller-2 overcloud-controller-3 ]
如果需要,在新节点上执行
cleanup
:[heat-admin@overcloud-controller-3 ~]$ sudo pcs resource cleanup galera --node overcloud-controller-3
把集群切换为维护模式:
[heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=true --wait
手动配置已完成。重新运行 overcloud 部署命令来继续栈的更新:
[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]
如果在创建 overcloud 时传递了额外的环境文件或选项,现在请再次传递它们来避免对 overcloud 进行不必要的更改。但请注意,此时不再需要 remove-controller.yaml
文件。
8.4.4. 完成配置 Overcloud 服务
在 overcloud 栈更新完成后,还需要一些最终配置。登录到其中一个控制器节点,刷新 Pacemaker 中所有停止的服务:
[heat-admin@overcloud-controller-0 ~]$ for i in `sudo pcs status|grep -B2 Stop |grep -v "Stop\|Start"|awk -F"[" '/\[/ {print substr($NF,0,length($NF)-1)}'`; do echo $i; sudo pcs resource cleanup $i; done
执行最后的状态检查来确保服务在正确运行:
[heat-admin@overcloud-controller-0 ~]$ sudo pcs status
如果服务失败,在解决相关问题后使用 pcs resource cleanup
命令重启它们。
退出 director
[heat-admin@overcloud-controller-0 ~]$ exit
8.4.5. 完成 L3 代理路由器的配置
对 overcloudrc
文件执行 source 命令,从而可以和 overcloud 进行交互。检查您的路由器,确保 overcloud 环境中的 L3 代理正确托管了路由器。本例中使用了名为 r1
的路由器:
[stack@director ~]$ source ~/overcloudrc [stack@director ~]$ neutron l3-agent-list-hosting-router r1
这个命令可能仍然会显示旧节点而不是新节点。要替换它,列出环境中的 L3 网络代理:
[stack@director ~]$ neutron agent-list | grep "neutron-l3-agent"
找出新节点和旧节点上代理的 UUID。把路由添加到新节点上的代理,并从旧节点上删除。例如:
[stack@director ~]$ neutron l3-agent-router-add fd6b3d6e-7d8c-4e1a-831a-4ec1c9ebb965 r1 [stack@director ~]$ neutron l3-agent-router-remove b40020af-c6dd-4f7a-b426-eba7bac9dbc2 r1
在路由器上进行最后的检查,确认所有都已激活:
[stack@director ~]$ neutron l3-agent-list-hosting-router r1
删除那些指向旧的 Controller 节点的 Neutron 代理。例如:
[stack@director ~]$ neutron agent-list -F id -F host | grep overcloud-controller-1 | ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb | overcloud-controller-1.localdomain | [stack@director ~]$ neutron agent-delete ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb
8.4.6. 完成 Compute 服务配置
已删除节点的计算服务仍然存在于 overcloud 中,需要删除。对 overcloudrc
文件执行 source 命令,从而可以和 overcloud 进行交互。检查已删除节点的计算服务:
[stack@director ~]$ source ~/overcloudrc [stack@director ~]$ nova service-list | grep "overcloud-controller-1.localdomain"
删除节点的 compute 服务。例如,overcloud-controller-1.localdomain
节点的 nova-scheduler
服务的 ID 是 5,运行以下命令:
[stack@director ~]$ nova service-delete 5
针对被删除节点的每个服务执行这个操作。
在新节点上检查 openstack-nova-consoleauth
服务。
[stack@director ~]$ nova service-list | grep consoleauth
如果服务没有运行,登录到一个 Controller 节点并重启服务:
[stack@director] ssh heat-admin@192.168.0.47 [heat-admin@overcloud-controller-0 ~]$ pcs resource restart openstack-nova-consoleauth
8.4.7. 结果
失败的 Controller 节点和它的相关服务被一个新节点替代。
如果禁用了 Object Storage 的自动 ring 构建(如 第 8.6 节 “替换 Object 存储节点”),则需要手工为新节点构建 Object Storage ring 文件。如需了解更多与手工构建 ring 文件相关的信息,请参阅 第 8.6 节 “替换 Object 存储节点”。
8.5. 替换 Ceph 存储节点
director 提供了一个在 director 创建的集群中替换 Ceph 存储节点的方法。相关说明可通过适用于 Overcloud 的 Red Hat Ceph Storage找到。
8.6. 替换 Object 存储节点
要在 Object 存储集群中替换节点,您需要:
- 更新带有新对象存储节点的 overcloud,防止 Director 创建 ring 文件。
-
使用
swift-ring-builder
对节点手工添加或删除节点。
以下介绍了在保证集群正常的情况下,如何替换节点的方法。在这个示例中,有一个带有 2 个节点 的 Object 存储集群。我们需要添加一个额外的节点,然后替换有问题的节点。
首先,创建一个包括以下内容的环境文件(名为 ~/templates/swift-ring-prevent.yaml
):
parameter_defaults: SwiftRingBuild: false RingBuild: false ObjectStorageCount: 3
SwiftRingBuild
和 RingBuild
参数分别定义 overcloud 是否自动为对象存储和控制器节点构建 ring 文件。ObjectStorageCount
定义环境中有多少个对象存储节点。此处,我们把节点数从 2 个扩展为 3 个。
在 openstack overcloud deploy
命令中包含 swift-ring-prevent.yaml
文件及 overcloud 中的其余环境文件:
$ openstack overcloud deploy --templates [ENVIRONMENT_FILES] -e swift-ring-prevent.yaml
把这个文件添加到环境文件的最后,从而使它的参数可以覆盖前面的环境文件参数。
在部署完成后,overcloud 现已包含一个额外的对象存储节点。但是,这个节点的存储目录还没有创建,用于节点对象存储的 ring 文件也没有构建。这意味着,您必须手动创建存储目录并构建 ring 文件。
使用以下步骤在 Controller 节点上构建 ring 文件。
登录到新节点并创建存储目录:
$ sudo mkdir -p /srv/node/d1 $ sudo chown -R swift:swift /srv/node/d1
您还可以在这个目录中挂载一个外部存储设备。
把存在的 ring 文件复制到节点。以 heat-admin
用户身份登录到一个 Controller 节点,然后切换到超级用户(superuser)。例如,对于一个 IP 地址为 192.168.201.24 的 Controller 节点:
$ ssh heat-admin@192.168.201.24 $ sudo -i
把 /etc/swift/*.builder
文件从 Controller 节点复制到新的 Object 存储节点的 /etc/swift/
目录中。如果需要,把文件放到 director 主机上:
[root@overcloud-controller-0 ~]# scp /etc/swift/*.builder stack@192.1.2.1:~/.
然后,把文件放到新节点上:
[stack@director ~]$ scp ~/*.builder heat-admin@192.1.2.24:~/.
以 heat-admin
用户的身份登录到新的 Object 存储节点上,然后切换到超级用户。例如,对于 IP 地址为 192.168.201.29 的 Object 存储节点:
$ ssh heat-admin@192.168.201.29 $ sudo -i
把文件复制到 /etc/swift
目录:
# cp /home/heat-admin/*.builder /etc/swift/.
把新的 Object 存储节点添加到帐号、容器和对象 ring 中。为新节点运行以下命令:
# swift-ring-builder /etc/swift/account.builder add zX-IP:6002/d1 weight # swift-ring-builder /etc/swift/container.builder add zX-IP:6001/d1 weight # swift-ring-builder /etc/swift/object.builder add zX-IP:6000/d1 weight
在这些命令中替换以下值:
- zX
- 使用代表特定区的一个整数替换 X(例如,Zone 1 的值为 1)。
- IP
-
帐号、容器和对象服务要监听的 IP 地址。这应该和每个存储节点的 IP 地址相匹配,特别是和
/etc/swift/object-server.conf
、/etc/swift/account-server.conf
和/etc/swift/container-server.conf
中的DEFAULT
部分中的bind_ip
的值相匹配。 - weight
- 表示一个设备和其它设备相比较的相对权重。它的值通常是 100。
针对 rings 文件运行 swift-ring-builder
命令来检查当前节点存在的值:
# swift-ring-builder /etc/swift/account.builder
删除您需要从账户、容器和对象 ring 中替换的节点。为每个节点运行以下命令:
# swift-ring-builder /etc/swift/account.builder remove IP # swift-ring-builder /etc/swift/container.builder remove IP # swift-ring-builder /etc/swift/object.builder remove IP
使用节点的 IP 地址替换 IP
。
在所有节点间重新分布分区:
# swift-ring-builder /etc/swift/account.builder rebalance # swift-ring-builder /etc/swift/container.builder rebalance # swift-ring-builder /etc/swift/object.builder rebalance
把 /etc/swift/
的所有者设置改为 root
用户和 swift
组:
# chown -R root:swift /etc/swift
重启 openstack-swift-proxy
服务:
# systemctl restart openstack-swift-proxy.service
到此为止,ring 文件(*.ring.gz 和 *.builder)应该已在新节点上被更新:
/etc/swift/account.builder /etc/swift/account.ring.gz /etc/swift/container.builder /etc/swift/container.ring.gz /etc/swift/object.builder /etc/swift/object.ring.gz
把这些文件复制到 Controller 节点和存在的 Object Storage 节点(除去要删除的节点)的 /etc/swift/
目录中。如果需要,把文件放置到 director 主机:
[root@overcloud-objectstorage-2 swift]# scp *.builder stack@192.1.2.1:~/ [root@overcloud-objectstorage-2 swift]# scp *.ring.gz stack@192.1.2.1:~/
把这个文件复制到每个节点的 /etc/swift/
中。
在每个节点中,把 /etc/swift/
的所有者设置改为 root
用户和 swift
组:
# chown -R root:swift /etc/swift
新节点被添加并作为 ring 的一部分。在把旧节点从 ring 中删除前,请确认新节点已完成了一个完整的数据复制过程。
为了从 ring 中删除旧节点,减少 ObjectStorageCount
的值。在这个示例中,我们把它从 3 减为 2:
parameter_defaults: SwiftRingBuild: false RingBuild: false ObjectStorageCount: 2
创建一个环境文件(remove-object-node.yaml
)来指定并删除旧的 Object 存储节点。在这个示例中,我们删除 overcloud-objectstorage-1
:
parameter_defaults: ObjectStorageRemovalPolicies: [{'resource_list': ['1']}]
在部署命令中包括这两个环境文件:
$ openstack overcloud deploy --templates -e swift-ring-prevent.yaml -e remove-object-node.yaml ...
director 从 overcloud 中删除对象存储节点,并更新 overcloud 中的其他节点来使删除生效。