第 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-kernelbm-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_kerneldeploy_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 节点:

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

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 中执行这些检查的所有命令。

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

    $ source stackrc
    $ openstack stack list --nested

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

  2. 对 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
  3. 确认您的 undercloud 拥有 10 GB 的可用存储空间,以容纳部署新节点期间的镜像缓存和转换。
  4. 在运行的 Controller 节点上检查 Pacemaker 的状态。例如,运行的 Controller 节点的 IP 地址是 192.168.0.47,使用以下命令获得 Pacemaker 的状态:

    $ 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):

      $ 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
  6. 检查 RabbitMQ 的状态。例如,一个运行节点的 IP 地址是 192.168.0.47,使用以下命令获得状态值

    $ ssh heat-admin@192.168.0.47 "sudo rabbitmqctl cluster_status"

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

  7. 如果启用了隔离服务,需要禁用它。例如,一个运行的 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"
  8. 在 director 节点上检查 nova-compute 服务:

    $ sudo systemctl status openstack-nova-compute
    $ openstack hypervisor list

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

  9. 确保所有 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 模块不支持节点替换。因此,这一时点上需要一些人工干预。请执行以下配置步骤:

  1. 获得 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   |
    ... +------------------------+ ... +-------------------------+
  2. 在一个存在节点的 /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。

  3. 从每个节点的 Corosync 配置中删除失败的节点,并重启 Corosync。对于这个示例,登录到 overcloud-controller-0overcloud-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"
  4. 登录到剩下的节点之一,使用 crm_node 命令从集群中删除节点:

    [stack@director] ssh heat-admin@192.168.0.47
    [heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force

    保持在这个节点的登录。

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

    [heat-admin@overcloud-controller-0 ~]$ sudo rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1
  6. 从 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,它的 name192.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
  7. 在 Galera 集群中更新节点列表:

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2
  8. 配置新节点上的 Galera 集群检查。将现有节点的 /etc/sysconfig/clustercheck 复制到新节点的同一位置上。
  9. 配置新节点上 root 用户的 Galera 访问权限。将现有节点的 /root/.my.cnf 复制到新节点的同一位置上。
  10. 为集群添加新节点:

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3
  11. 检查每个节点上的 /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 值。

  12. 只在存在的节点上重启 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

    不要在新节点上运行这个命令。

  13. 启动新的 Controller 节点:

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start overcloud-controller-3
  14. 通过 Pacemaker 启用并重启一些服务。集群当前处于维护模式,您需要临时禁用它来启用服务。例如:

    [heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=false --wait
  15. 等待 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
  16. 把集群切换为维护模式:

    [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

SwiftRingBuildRingBuild 参数分别定义 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 中的其他节点来使删除生效。