红帽全球峰会2.2. 迁移 Ceph RGW
在这种情况下，假设 Ceph 已经是 >= 5，对于 HCI 或专用存储节点，OpenStack Controller 节点中的 RGW 守护进程将迁移到现有的外部 RHEL 节点（通常是在剩余的用例中为 HCI 环境或 CephStorage 节点的 Compute 节点）。
2.2.1. 要求
- Ceph 是 >= 5，并由 cephadm/orchestrator 管理
- undercloud 仍然可用：节点和网络由 TripleO 管理
2.2.2. Ceph 守护进程卡
Ceph 5+ 以守护进程在同一节点上并置的方式应用 严格的限制。生成的拓扑取决于可用的硬件，以及将要停用的 Controller 节点中存在的 Ceph 服务数量。以下文档描述了在常见的 TripleO 场景中，迁移 RGW 组件所需的步骤（并保留 HA 模型），其中 Controller 节点代表部署该服务的 spec 放置。https://docs.ceph.com/en/latest/cephadm/services/rgw/#high-availability-service-for-rgw作为一般规则，可以迁移的服务数量取决于集群中的可用节点数量。以下示意图涵盖了 Ceph 存储节点上 Ceph 守护进程的分布，在这种情况下，仅看到 RGW 和 RBD （无仪表板）需要至少三个节点：
| | | | |----|---------------------|-------------| | osd | mon/mgr/crash | rgw/ingress | | osd | mon/mgr/crash | rgw/ingress | | osd | mon/mgr/crash | rgw/ingress |
| | | |
|----|---------------------|-------------|
| osd | mon/mgr/crash | rgw/ingress |
| osd | mon/mgr/crash | rgw/ingress |
| osd | mon/mgr/crash | rgw/ingress |使用仪表板，且没有 Manila 至少有四个节点（仪表板没有故障切换）：
至少需要仪表板和 Manila 5 节点（且仪表板没有故障转移）：
2.2.3. 当前状态
SSH 到 controller-0 并检查 pacemaker 状态。这有助于您在开始 RGW 迁移前识别您需要的信息。
使用 ip 命令识别存储网络的范围。
在本例中：
- vlan30 代表 Storage Network，其中新的 RGW 实例应在 CephStorage 节点上启动
- br-ex 代表外部网络，这是在当前环境中分配有前端 VIP 的外部网络
2.2.4. 先决条件：检查 frontend 网络(Controller 节点)
识别您之前在 haproxy 中具有的网络，并将它（通过 TripleO）传播到 CephStorage 节点。此网络用于保留供 Ceph 所有的新 VIP，并用作 RGW 服务的入口点。
SSH 到 controller-0 并检查当前的 HaProxy 配置，直到您找到 ceph_rgw 部分：
仔细检查用作 HaProxy frontend 的网络：
ip -o -4 a
[controller-0]$ ip -o -4 a
...
7: br-ex inet 10.0.0.106/24 brd 10.0.0.255 scope global br-ex\ valid_lft forever preferred_lft forever
...如上一节中所述，controller-0 的检查显示您使用外部网络( Ceph Storage 节点中不存在)公开服务，您需要通过 TripleO 传播它。
2.2.5. 将 HaProxy frontend 网络传播到 CephStorage 节点
更改用于定义 ceph-storage 网络接口并添加新 config 部分的 NIC 模板。
另外，将 外部网络 添加到 metalsmith 使用的 baremetal.yaml 文件中，并运行 overcloud node provision 命令传递 --network-config 选项：
检查 CephStorage 节点上的新网络：
现在，这是开始迁移 RGW 后端并在其上构建入口的时间。
2.2.6. 迁移 RGW 后端
要匹配卡图，您可以使用 cephadm 标签来引用应该部署给定守护进程类型的一组节点。
将 RGW 标签添加到 cephstorage 节点：
for i in 0 1 2; {
ceph orch host label add cephstorage-$i rgw;
}
for i in 0 1 2; {
ceph orch host label add cephstorage-$i rgw;
}
在 overcloud 部署期间，RGW 应用于 step2 (external_deployment_steps)，cephadm 兼容 spec 在 ceph_mkspec ansible 模块的 /home/ceph-admin/specs/rgw 中生成。查找并修补 RGW spec，使用标签方法指定正确的放置，并将 rgw 后端端口改为 8090，以避免与 Ceph Ingress Daemon packet 冲突
使用标签键对替换控制器节点进行补丁
使用编配器 CLI 应用新的 RGW spec：
cephadm shell -m /home/ceph-admin/specs/rgw cephadm shell -- ceph orch apply -i /mnt/rgw
$ cephadm shell -m /home/ceph-admin/specs/rgw
$ cephadm shell -- ceph orch apply -i /mnt/rgw触发重新部署：
此时，您需要确保新的 RGW 后端可在新端口上访问，但稍后您要在进程的端口 8080 上启用 IngressDaemon。因此，每个 RGW 节点( CephStorage 节点)上的 ssh 并添加 iptables 规则，以允许连接 Ceph 存储节点上的 8080 和 8090 端口。
从 Controller 节点（如 controller-0）尝试访问 rgw 后端：
您应该观察以下内容：
2.2.6.1. 注意
如果在 CephStorage 节点上迁移 RGW 后端，则没有 "internalAPI" 网络（如果是 HCI，则这不是 true）。重新配置 RGW keystone 端点，指向已传播的外部网络（请参阅上一节中）
[ceph: root@controller-0 /]# ceph config dump | grep keystone global basic rgw_keystone_url http://172.16.1.111:5000 [ceph: root@controller-0 /]# ceph config set global rgw_keystone_url http://10.0.0.103:5000
[ceph: root@controller-0 /]# ceph config dump | grep keystone
global basic rgw_keystone_url http://172.16.1.111:5000
[ceph: root@controller-0 /]# ceph config set global rgw_keystone_url http://10.0.0.103:50002.2.7. 部署 Ceph IngressDaemon
HAProxy 通过 Pacemaker 管理由 TripleO：此时运行的三个实例将指向旧的 RGW 后端，从而导致错误且无法正常工作。由于您要部署 Ceph Ingress Daemon，因此需要删除现有的 ceph_rgw 配置，清理由 TripleO 创建的配置，再重启服务以确保其他服务不受此更改的影响。
每个 Controller 节点上的 SSH，从 /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg 中删除以下内容：
重启 haproxy-bundle 并确保它已启动：
双检查不再绑定到 8080'"
ss -antop | grep 8080
[root@controller-0 ~]# ss -antop | grep 8080
[root@controller-0 ~]#此时，swift CLI 应该会失败：
swift list
(overcloud) [root@cephstorage-0 ~]# swift list
HTTPConnectionPool(host='10.0.0.103', port=8080): Max retries exceeded with url: /swift/v1/AUTH_852f24425bb54fa896476af48cbe35d3?format=json (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fc41beb0430>: Failed to establish a new connection: [Errno 111] Connection refused'))您可以在 CephStorage 节点上开始部署 Ceph IngressDaemon。
为 HaProxy 和 Keepalived 设置所需的镜像
[ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_haproxy registry.redhat.io/rhceph/rhceph-haproxy-rhel9:latest [ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_keepalived registry.redhat.io/rhceph/keepalived-rhel9:latest
[ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_haproxy registry.redhat.io/rhceph/rhceph-haproxy-rhel9:latest
[ceph: root@controller-0 /]# ceph config set mgr mgr/cephadm/container_image_keepalived registry.redhat.io/rhceph/keepalived-rhel9:latest准备 ingress 规格并将其挂载到 cephadm：
sudo vim /home/ceph-admin/specs/rgw_ingress
$ sudo vim /home/ceph-admin/specs/rgw_ingress粘贴以下内容：
挂载生成的 spec，并使用编配器 CLI 应用它：
cephadm shell -m /home/ceph-admin/specs/rgw_ingress cephadm shell -- ceph orch apply -i /mnt/rgw_ingress
$ cephadm shell -m /home/ceph-admin/specs/rgw_ingress
$ cephadm shell -- ceph orch apply -i /mnt/rgw_ingress等待入口部署并查询生成的端点：
[ceph: root@controller-0 /]# curl 10.0.0.89:8080 --- <?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>[ceph: root@controller-0 /]# —
[ceph: root@controller-0 /]# curl 10.0.0.89:8080
---
<?xml version="1.0" encoding="UTF-8"?><ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Owner><ID>anonymous</ID><DisplayName></DisplayName></Owner><Buckets></Buckets></ListAllMyBucketsResult>[ceph: root@controller-0 /]#
—以上结果显示，您可以从 IngressDaemon 访问后端，这意味着您几乎准备好使用 swift CLI 与之交互。
2.2.8. 更新 object-store 端点
端点仍然指向 pacemaker 拥有的旧 VIP，但因为它仍然被其他服务使用，并且您在同一网络上保留一个新的 VIP，然后再更新 object-store 端点。
列出当前的端点：
openstack endpoint list | grep object
(overcloud) [stack@undercloud-0 ~]$ openstack endpoint list | grep object
| 1326241fb6b6494282a86768311f48d1 | regionOne | swift | object-store | True | internal | http://172.17.3.68:8080/swift/v1/AUTH_%(project_id)s |
| 8a34817a9d3443e2af55e108d63bb02b | regionOne | swift | object-store | True | public | http://10.0.0.103:8080/swift/v1/AUTH_%(project_id)s |
| fa72f8b8b24e448a8d4d1caaeaa7ac58 | regionOne | swift | object-store | True | admin | http://172.17.3.68:8080/swift/v1/AUTH_%(project_id)s |更新指向 Ingress VIP 的端点：
并为 internal 和 admin 重复同样的操作。测试迁移的服务。
针对 object-storage 运行 tempest 测试：
2.2.9. 其它资源
提供 屏幕记录。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}