红帽全球峰会部署分布式 Compute 节点(DCN)架构
Openshift 上 Red Hat OpenStack Services 的边缘和存储配置
摘要
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。
使用 Create Issue 表单在 OpenShift (RHOSO)或更早版本的 Red Hat OpenStack Platform (RHOSP)上提供有关 Red Hat OpenStack Services 文档的反馈。当您为 RHOSO 或 RHOSP 文档创建问题时，这个问题将在 RHOSO Jira 项目中记录，您可以在其中跟踪您的反馈的进度。
要完成 Create Issue 表单，请确保您已登录到 JIRA。如果您没有红帽 JIRA 帐户，您可以在 https://issues.redhat.com 创建一个帐户。
- 点击以下链接打开 Create Issue 页面： Create Issue
- 完成 Summary 和 Description 字段。在 Description 字段中，包含文档 URL、章节号以及问题的详细描述。不要修改表单中的任何其他字段。
- 点 Create。
第 1 章 了解 DCN
目前，分布式 Compute 节点(DCN)部署不支持从 Red Hat OpenStack Platform (RHOSP) 17.1 升级到 OpenShift (RHOSO) 18.0.3 上的 Red Hat OpenStack Services。
分布式计算节点(DCN)架构适用于需要远程部署计算和存储节点的边缘用例，同时共享集中式 control plane。使用 DCN 架构，您可以战略性地将工作负载定位到操作需求，以获得更高的性能。
中央位置至少由 Red Hat OpenShift Container Platform (RHOCP)集群上安装的 RHOSO control plane 组成。Compute 节点也可以部署到中央位置。边缘位置由 Compute 和可选的存储节点组成。
DCN 架构由多个可用区(AZ)组成，以确保 OpenStack 资源的每站点调度进行隔离。
您使用唯一的 AZ 配置每个站点。在本指南中，中央站点使用 az0，第一个边缘位置使用 az1 等等。您可以使用任何命名约定来确保 AZ 名称在每个站点都是唯一的。
DCN 架构是一个 hub 和spoke 的路由网络部署。DCN 与用于路由置备和使用 RHOSO 的控制平面网络的 spine-leaf 部署相当。
- hub 是带有核心路由器和数据中心网关(DC-GW)的中央站点。hub 托管管理地理位置分散的站点的 control plane。
-
spoke 是远程边缘站点。每个站点通过使用
OpenStackDataPlaneNodeSet自定义资源定义。Red Hat Ceph Storage (RHCS)用作存储后端。您可以在超融合配置中或独立存储后端部署 RHCS。
当您在边缘站点启动实例时，所需的镜像会自动复制到本地镜像服务(glance)存储中。您可以使用 glance 多存储在实例启动期间节省时间，从而将镜像从中央镜像存储复制到边缘站点。
1.1. DCN 架构所需的软件
下表显示了在分布式计算节点(DCN)架构中部署 Red Hat OpenStack Services (RHOSO)所需的软件和最低版本：
| 平台 | 版本 | 选填 |
|---|---|---|
| Red Hat OpenShift Container Platform | 4.16 | 否 |
| Red Hat Enterprise Linux | 9.2 | 否 |
| Red Hat OpenStack Platform | 18.0.3 | 否 |
| Red Hat Ceph Storage | 7 或 8 | 是 |
1.2. DCN 存储
您可以在三个配置之一中部署中央位置或任何边缘站点：
- 没有存储。
- 使用超融合 Ceph 存储.
- 使用 Red Hat Ceph Storage (RHCS)作为独立存储后端。
您部署的存储专用于部署它的站点。DCN 架构使用镜像服务(glance) pod 和每个站点（部署在 Red Hat OpenShift Container Platform (RHOCP)集群上的中央位置部署的块存储服务(cinder) pod。
对于在没有存储的情况下部署的边缘站点，您可以使用 aggregate cache 命令将镜像存储在计算服务(nova)缓存中。通过避免通过 WAN 链接下载镜像的过程，计算服务中的缓存镜像为实例提供更快的引导时间。
示例:
$ openstack aggregate cache image <dcn0> <myimage>-
将
<dcn0> 替换为您的可用区的名称。 -
将
<myimage> 替换为您的镜像的名称。
Red Hat OpenStack Services on OpenShift (RHOSO)支持外部部署 Red Hat Ceph Storage 7 和 8。引用 Red Hat Ceph Storage 的配置示例使用版本 7 信息。如果您使用 Red Hat Ceph Storage 8，请相应地调整配置示例。
第 2 章 规划分布式 Compute 节点(DCN)部署
在规划 DCN 架构时，请检查您需要的技术是否可用并提供支持。
2.1. DCN 架构上的存储注意事项
与更常见的架构相比，附加到带有分布式计算节点(DCN)架构的 Red Hat OpenStack Services (RHOSO)部署的存储具有特定的功能和支持差异。
DCN 架构目前不支持以下功能：
- 在边缘站点间复制卷。您可以通过从卷创建镜像并使用镜像服务(glance)来复制镜像来解决此问题。复制镜像后，您可以从其中创建卷。
- 边缘站点上的 Ceph Rados 网关(RGW)。
- 边缘站点上的 CephFS。
- 边缘站点的实例高可用性(HA)。
- 边缘站点之间的 RBD 镜像功能。
-
实例迁移、实时或冷迁移，可以在边缘站点之间，或者从中央位置到边缘站点。您只能迁移站点边界中的实例。要在站点之间移动镜像，必须对镜像进行快照，并使用
glance image-import。
另外，您必须考虑以下几点：
- 在将镜像复制到边缘站点之前，您必须将镜像上传到中央位置。每个镜像的副本必须存在于中央位置的镜像服务中。
- 您必须将 RBD 存储驱动程序用于镜像、计算和块存储服务。
- 对于每个站点，包括中央位置，分配一个唯一的可用区。
- 您可以将离线卷从边缘站点迁移到中央位置，反之亦然。您无法直接在边缘站点之间迁移卷。
2.2. DCN 架构上的网络的注意事项
与更常见的架构相比，带有分布式计算节点(DCN)架构的 RHOSO 部署具有特定的特性和支持差异。
DCN 架构目前不支持以下功能：
- DPDK 节点上的 DHCP
- TC Flower Hardware Offload
以下 ML2/OVN 网络技术被完全支持：
- 路由提供商网络
- 支持 Neutron AZ 的 OVN GW （网络节点）
另外，您必须考虑以下几点：
- 网络延迟：平衡往返时间(RTT)的延迟，以及预期的并发 API 操作数，以保持可接受的性能。最大 TCP/IP 吞吐量与 RTT 相反。您可以通过调整内核 TCP 参数来缓解高带宽的高延迟连接的问题。如果跨站点通信超过 100 毫秒，请联系红帽支持团队。
- Network outs: 如果边缘站点临时丢失与中央站点的连接，则在中断期间，不会在受影响的边缘站点执行 control plane API 或 CLI 操作。例如，边缘站点中的 Compute 节点无法创建实例的快照、签发身份验证令牌或删除镜像。常规 control plane API 和 CLI 操作在此中断期间仍然可以正常工作，并可继续提供具有工作连接的其他边缘站点。
- Image type：在部署带有 Ceph 存储的 DCN 架构时，您必须使用 raw 镜像。
镜像大小：
- 计算镜像：计算镜像从中央位置下载。在置备过程中，这些镜像可能是在所有必要的网络中传输的大型文件，从中央站点传输到边缘站点。
- 实例镜像：如果边缘没有块存储，则镜像服务镜像会先遍历 WAN。镜像在本地复制或缓存到目标边缘节点，供以后使用。镜像没有大小限制。传输时间因可用带宽和网络延迟而异。
- 提供商网络是 DCN 部署的最常见方法。请注意，网络服务(neutron)不会验证您可以在何处附加可用网络。例如，如果您在边缘站点 A 中使用名为"site-a"的提供商网络，网络服务不会验证并防止您将 "site-a" 附加到站点 B 中的实例，这不起作用。
- 特定于站点的网络：如果您使用特定于某个站点的网络，则 DCN 网络中的一个限制：当您使用 Compute 节点部署集中式 neutron 控制器时，网络服务中没有触发器将特定的 Compute 节点识别为远程节点。因此，Compute 节点接收其他 Compute 节点列表，并互相自动形成隧道。隧道通过中央站点从边缘到边缘。如果您使用 VXLAN 或 GENEVE，则每个站点中的每个 Compute 节点都会形成一个隧道，无论是本地的还是远程的。如果您在任何地方使用相同的网络，则这不是问题。使用 VLAN 时，网络服务要求所有 Compute 节点都有相同的网桥映射，并且所有 VLAN 都位于每个站点。
- 如果没有预置备边缘服务器，您必须配置 DHCP 转发，以便在路由片段上内省和调配。
- 路由必须在云或将每个边缘站点连接到 hub 的网络基础架构中配置。您应该实施一个网络设计，用于为每个 RHOSO 集群网络（外部、内部 API 等）分配 L3 子网，每个站点都是唯一的。如果使用 BGP，您必须在这些位置的路由器上配置 BGP，以了解 RHOSO control plane 和数据平面节点公告的路由。
2.3. internalapi 网络的 IP Address 池大小
Image service operator 为每个镜像服务 pod 创建一个端点，并带有自己的 DNS 名称，如 glance-az0-internal.openstack.svc:9292。每个可用区中的每个 Compute 服务和块存储服务都使用同一可用区中的镜像服务(glance) API 服务器。例如，当您更新 OpenStackControlPlane 自定义资源(CR)中的 cinderVolumes 字段时，在 customServiceConfig 下添加名为 glance_api_servers 的字段：
cinderVolumes:
az0:
customServiceConfig: |
[DEFAULT]
enabled_backends = az0
glance_api_servers = https://glance-az0-internal.openstack.svc:9292
镜像服务端点 DNS 名称映射到 internalapi 地址池中的负载均衡器 IP 地址，如内部元数据注解所示：
[glance_store]
default_backend = ceph
[ceph]
rbd_store_ceph_conf = /etc/ceph/ceph.conf
store_description = "ceph RBD backend"
rbd_store_pool = images
rbd_store_user = openstack
rbd_thin_provisioning = True
networkAttachments:
- storage
override:
service:
internal:
metadata:
annotations:
metallb.universe.tf/address-pool: internalapi
metallb.universe.tf/allow-shared-ip: internalapi
metallb.universe.tf/loadBalancerIPs: 172.17.0.80
此地址池中的地址范围应该根据 DCN 站点的数量进行大小。例如，下面显示了 internalapi 网络中有 10 个可用地址。
$ oc get ipaddresspool -n metallb-system
NAME AUTO ASSIGN AVOID BUGGY IPS ADDRESSES
ctlplane true false ["192.168.122.80-192.168.122.90"]
internalapi true false ["172.17.0.80-172.17.0.90"]
storage true false ["172.18.0.80-172.18.0.90"]
tenant true false ["172.19.0.80-172.19.0.90"]在更新 OpenStackControlPlane CR 的 glance 部分后，使用以下命令确认 Glance Operator 已创建了服务端点和路由。
$ oc get svc | grep glance
glance-az0-internal LoadBalancer 172.30.217.178 172.17.0.80 9292:32134/TCP 24h
glance-az0-public ClusterIP 172.30.78.47 <none> 9292/TCP 24h
glance-az1-internal LoadBalancer 172.30.52.123 172.17.0.81 9292:31679/TCP 23h
glance-c1ca8-az0-external-api ClusterIP None <none> 9292/TCP 24h
glance-c1ca8-az0-internal-api ClusterIP None <none> 9292/TCP 24h
glance-c1ca8-az1-edge-api ClusterIP None <none> 9292/TCP 23h
$ oc get route | grep glance
glance-az0-public glance-az0-public-openstack.apps.ocp.openstack.lab glance-az0-public glance-az0-public reencrypt/Redirect None
glance-default-public glance-default-public-openstack.apps.ocp.openstack.lab glance-default-public glance-default-public reencrypt/Redirect None第 3 章 安装和准备 Operator
您可以在 OpenShift (RHOSO) OpenStack Operator (openstack-operator)上安装 Red Hat OpenStack Services，并在可正常工作的 Red Hat OpenShift Container Platform (RHOCP)集群上创建 RHOSO 控制平面。您可以使用 RHOCP Web 控制台安装 OpenStack Operator。您可以在可访问 RHOCP 集群的工作站上执行 control plane 安装任务和所有数据平面创建任务。
有关将 RHOSO 版本映射到 OpenStack Operator 和 OpenStackVersion 自定义资源(CR)的信息，请参阅红帽知识库文章 https://access.redhat.com/articles/7125383。
3.1. 先决条件
一个可正常工作的 RHOCP 集群，版本 4.18。有关 RHOCP 系统要求，请参阅规划部署 中的 Red Hat OpenShift Container Platform 集群要求。
- 有关托管 RHOSO 控制平面的最低 RHOCP 硬件要求，请参阅 最小 RHOCP 硬件要求。
- 有关最低 RHOCP 网络要求，请参阅 RHOCP 网络要求。
-
有关安装
openstack-operator之前必须安装的 Operator 列表，请参阅 RHOCP 软件要求。
-
oc命令行工具已安装在您的工作站上。 -
以具有
cluster-admin权限的用户身份登录 RHOCP 集群。
3.2. 安装 OpenStack Operator
您可以在 Red Hat OpenShift Container Platform (RHOCP) Web 控制台上使用 OperatorHub 在 RHOCP 集群上安装 OpenStack Operator (openstack-operator)。安装 Operator 后，您可以配置 OpenStack Operator 初始化资源的单一实例来在集群中启动 OpenStack Operator。
流程
-
以具有
cluster-admin权限的用户身份登录 RHOCP Web 控制台。 - 选择 Operators → OperatorHub。
-
在 Filter by keyword 字段中，键入
OpenStack。 -
点带有
Red Hatsource 标签的 OpenStack Operator 标题。 - 阅读 Operator 信息并单击 Install。
- 在 Install Operator 页面中，从 Installed Namespace 列表中选择 "Operator recommended Namespace: openstack-operators"。
- 在 Install Operator 页面中，从 Update approval 列表中选择 "Manual"。有关如何手动批准待处理的 Operator 更新的详情，请参考 RHOCP Operator 指南中的手动批准待处理的 Operator 更新。
-
点 Install 使 Operator 可供
openstack-operators命名空间使用。当 Status 为Succeeded时，会安装 OpenStack Operator。 - 单击 Create OpenStack 以打开 Create OpenStack 页面。
-
在 Create OpenStack 页面中，点 Create 来创建 OpenStack Operator 初始化资源的实例。当
openstack实例的 Status 为Conditions: Ready时，OpenStack Operator 已就绪。
第 4 章 部署 DCN control plane
要使用分布式计算节点(DCN)架构在 OpenShift (RHOSO)上部署 Red Hat OpenStack Services，您需要从安装 Red Hat OpenShift Container Platform (RHOCP)开始并安装 RHOSO control plane。有关准备 RHOSO control plane 的详细信息，请参阅在 OpenShift 上为 Red Hat OpenStack Services 准备 Red Hat OpenShift Container Platform。
在部署 control plane 之前，还必须配置 RHOCP 网络。RHOSO 的 DCN 部署需要管理大量子网。您使用的子网特定于您的环境。本文档在每个示例中都使用以下配置。
| 中央位置(AZ-0) | AZ-1 | AZ-2 | |
|---|---|---|---|
| Control plane（控制平面） | 192.168.122.0/24 | 192.168.133.0/24 | 192.168.144.0/24 |
| 外部 | 10.0.0.0/24 | 10.0.10.0/24 | 10.0.20.0/24 |
| 内部 | 172.17.0.0/24 | 172.17.10.0/24 | 172.17.20.0/24 |
| Storage | 172.18.0.0/24 | 172.18.10.0/24 | 172.18.20.0/24 |
| 租户 | 172.19.0.0/24 | 172.19.10.0/24 | 172.19.20.0/24 |
| 存储管理 | 172.20.0.0/24 | 172.20.10.0/24 | 172.20.20.0/24 |
4.1. 为 DCN 创建 spine-leaf 网络拓扑
分布式计算节点(DCN)架构中的地理分布式节点通过路由 spine-leaf 网络拓扑进行互连。
您必须配置以下 CR：
- NodeNetworkConfigurationPolicy
-
使用
NodeNetworkConfigurationPolicyCR 在 RHOCP 集群中每个 worker 节点上为每个隔离网络配置接口。 - NetworkAttachmentDefinition
-
根据需要，使用
NetworkAttachmentDefinitionCR 将服务 pod 附加到隔离的网络中。 - L2Advertisement
-
使用
L2Advertisement资源来定义如何宣布虚拟 IP (VIP)。 - IPAddressPool
-
使用
IPAddressPool资源来配置哪些 IP 可用作 VIP。 - NetConfig
-
使用
NetConfigCR 指定 data plane 网络的子网。 - OpenStackControlPlane
-
使用
OpenStackControlPlane在 OpenShift 中定义和配置 OpenStack 服务。
4.2. 准备 DCN 网络
当您部署分布式计算节点架构时，您首先部署中央位置 control plane。Red Hat OpenStack Services on OpenShift (RHOSO)服务作为 Red Hat OpenShift Container Platform (RHOCP)工作负载运行。
先决条件
- 已安装 OpenStack Operator
流程
-
在工作站上为托管 OpenStack 服务的每个 worker 节点创建一个
NodeNetworkConfigurationPolicy(nncp) CR 定义文件。 在每个
nncpCR 文件中，为每个隔离网络配置接口。每个服务接口必须具有自己的唯一地址：apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: labels: osp/nncm-config-type: standard name: worker-0 namespace: openstack spec: desiredState: dns-resolver: config: search: [] server: - 192.168.122.1 interfaces: - description: internalapi vlan interface ipv4: address: - ip: 172.17.0.10 prefix-length: "24" dhcp: false enabled: true ipv6: enabled: false mtu: 1496 name: internalapi state: up type: vlan vlan: base-iface: enp7s0 id: "20" - description: storage vlan interface ipv4: address: - ip: 172.18.0.10 prefix-length: "24" dhcp: false enabled: true ipv6: enabled: false mtu: 1496 name: storage state: up type: vlan vlan: base-iface: enp7s0 id: "21" - description: tenant vlan interface ipv4: address: - ip: 172.19.0.10 prefix-length: "24" dhcp: false enabled: true ipv6: enabled: false mtu: 1496 name: tenant state: up type: vlan vlan: base-iface: enp7s0 id: "22" - description: ctlplane interface mtu: 1500 name: enp7s0 state: up type: ethernet - bridge: options: stp: enabled: false port: - name: enp7s0 vlan: {} description: linux-bridge over ctlplane interface ipv4: address: - ip: 192.168.122.10 prefix-length: "24" dhcp: false enabled: true ipv6: enabled: false mtu: 1500 name: ospbr state: up type: linux-bridge将
route-rules属性和路由配置添加到每个远程位置中的网络到每个nncpCR 文件：route-rules: config: [] routes: config: - destination: 192.168.133.0/24 next-hop-address: 192.168.122.1 next-hop-interface: ospbr table-id: 254 - destination: 192.168.144.0/24 next-hop-address: 192.168.122.1 next-hop-interface: ospbr table-id: 254 - destination: 172.17.10.0/24 next-hop-address: 172.17.0.1 next-hop-interface: internalapi table-id: 254 - destination: 172.18.10.0/24 next-hop-address: 172.18.0.1 next-hop-interface: storage table-id: 254 - destination: 172.19.10.0/24 next-hop-address: 172.19.0.1 next-hop-interface: tenant table-id: 254 - destination: 172.17.20.0/24 next-hop-address: 172.17.0.1 next-hop-interface: internalapi table-id: 254 - destination: 172.18.20.0/24 next-hop-address: 172.18.0.1 next-hop-interface: storage table-id: 254 - destination: 172.19.20.0/24 next-hop-address: 172.19.0.1 next-hop-interface: tenant table-id: 254 nodeSelector: kubernetes.io/hostname: worker-0 node-role.kubernetes.io/worker: ""注意每个服务网络会路由到每个远程位置的同一网络。例如，
internapi网络(172.17.0.0/24)通过 172.17.0.1 的本地路由器在每个远程位置(172.17.10.0/24 和 172.17.20.0/24)上到internalapi网络的路由。在集群中创建
nncpCR：$ oc create -f worker0-nncp.yaml $ oc create -f worker1-nncp.yaml $ oc create -f worker2-nncp.yaml为每个网络创建一个
NetworkAttachmentDefinitionCR 定义文件。包括到同一功能网络的每个远程位置的路由。例如，internalapiNetworkAttachmentDefinition 指定自己的子网范围，以及远程站点上的internalapi网络的路由。为
internalapi网络创建NetworkAttachmentDefinitionCR 定义文件：apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: internalapi osp/net-attach-def-type: standard name: internalapi namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "internalapi", "type": "macvlan", "master": "internalapi", "ipam": { "type": "whereabouts", "range": "172.17.0.0/24", "range_start": "172.17.0.30", "range_end": "172.17.0.70", "routes": [ { "dst": "172.17.10.0/24", "gw": "172.17.0.1" }, { "dst": "172.17.20.0/24", "gw": "172.17.0.1" } ] } }为控制网络创建
NetworkAttachmentDefinitionCR 定义文件：apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: ctlplane osp/net-attach-def-type: standard name: ctlplane namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "ctlplane", "type": "macvlan", "master": "ospbr", "ipam": { "type": "whereabouts", "range": "192.168.122.0/24", "range_start": "192.168.122.30", "range_end": "192.168.122.70", "routes": [ { "dst": "192.168.133.0/24", "gw": "192.168.122.1" }, { "dst": "192.168.144.0/24", "gw": "192.168.122.1" } ] } }为存储网络创建
NetworkAttachmentDefinitionCR 定义文件：apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: storage osp/net-attach-def-type: standard name: storage namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "storage", "type": "macvlan", "master": "storage", "ipam": { "type": "whereabouts", "range": "172.18.0.0/24", "range_start": "172.18.0.30", "range_end": "172.18.0.70", "routes": [ { "dst": "172.18.10.0/24", "gw": "172.18.0.1" }, { "dst": "172.18.20.0/24", "gw": "172.18.0.1" } ] } }为
租户网络创建NetworkAttachmentDefinitionCR 定义文件：apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: labels: osp/net: tenant osp/net-attach-def-type: standard name: tenant namespace: openstack spec: config: | { "cniVersion": "0.3.1", "name": "tenant", "type": "macvlan", "master": "tenant", "ipam": { "type": "whereabouts", "range": "172.19.0.0/24", "range_start": "172.19.0.30", "range_end": "172.19.0.70", "routes": [ { "dst": "172.19.10.0/24", "gw": "172.19.0.1" }, { "dst": "172.19.20.0/24", "gw": "172.19.0.1" } ] } }
创建
NetworkAttachmentDefinitionCR：$ oc create -f internalapi-net-attach-def.yaml $ oc create -f control-net-attach-def.yaml $ oc create -f storage-net-attach-def.yaml $ oc create -f tenant-net-attach-def.yaml创建 NetConfig CR 定义文件，以定义哪些 IP 可用作虚拟 IP (VIP)。在
dnsDomain字段下定义的每个网络，每个地理位置的allocationRanges都有 allocationRanges。这些范围不能与abouts IPAM范围的位置重叠。使用为 control plane 网络添加的分配范围创建该文件，如下所示：
apiVersion: network.openstack.org/v1beta1 kind: NetConfig metadata: name: netconfig namespace: openstack spec: networks: - dnsDomain: ctlplane.example.com mtu: 1500 name: ctlplane subnets: - allocationRanges: - end: 192.168.122.120 start: 192.168.122.100 - end: 192.168.122.170 start: 192.168.122.150 cidr: 192.168.122.0/24 gateway: 192.168.122.1 name: subnet1 routes: - destination: 192.168.133.0/24 nexthop: 192.168.122.1 - destination: 192.168.144.0/24 nexthop: 192.168.122.1 - allocationRanges: - end: 192.168.133.120 start: 192.168.133.100 - end: 192.168.133.170 start: 192.168.133.150 cidr: 192.168.133.0/24 gateway: 192.168.133.1 name: subnet2 routes: - destination: 192.168.122.0/24 nexthop: 192.168.133.1 - destination: 192.168.144.0/24 nexthop: 192.168.133.1 - allocationRanges: - end: 192.168.144.120 start: 192.168.144.100 - end: 192.168.144.170 start: 192.168.144.150 cidr: 192.168.144.0/24 gateway: 192.168.144.1 name: subnet3 routes: - destination: 192.168.122.0/24 nexthop: 192.168.144.1 - destination: 192.168.133.0/24 nexthop: 192.168.144.1为
internalapi网络添加分配范围：- dnsDomain: internalapi.example.com mtu: 1496 name: internalapi subnets: - allocationRanges: - end: 172.17.0.250 start: 172.17.0.100 cidr: 172.17.0.0/24 name: subnet1 routes: - destination: 172.17.10.0/24 nexthop: 172.17.0.1 - destination: 172.17.20.0/24 nexthop: 172.17.0.1 vlan: 20 - allocationRanges: - end: 172.17.10.250 start: 172.17.10.100 cidr: 172.17.0.0/24 name: subnet2 routes: - destination: 172.17.0.0/24 nexthop: 172.17.10.1 - destination: 172.17.20.0/24 nexthop: 172.17.10.1 vlan: 30 - allocationRanges: - end: 172.17.20.250 start: 172.17.20.100 cidr: 172.17.20.0/24 name: subnet3 routes: - destination: 172.17.0.0/24 nexthop: 172.17.20.1 - destination: 172.17.10.0/24 nexthop: 172.17.20.1 vlan: 40为外部网络添加分配范围：
- dnsDomain: external.example.com mtu: 1500 name: external subnets: - allocationRanges: - end: 10.0.0.250 start: 10.0.0.100 cidr: 10.0.0.0/24 name: subnet1 vlan: 22 - dnsDomain: external.example.com mtu: 1500 name: external subnets: - allocationRanges: - end: 10.0.10.250 start: 10.0.10.100 cidr: 10.0.10.0/24 name: subnet2 vlan: 22 - dnsDomain: external.example.com mtu: 1500 name: external subnets: - allocationRanges: - end: 10.0.20.250 start: 10.0.20.100 cidr: 10.0.20.0/24 name: subnet3 vlan: 22 - dnsDomain: storage.example.com mtu: 1496 name: storage subnets: - allocationRanges: - end: 172.18.0.250 start: 172.18.0.100 cidr: 172.18.0.0/24 name: subnet1 routes: - destination: 172.18.10.0/24 nexthop: 172.18.0.1 - destination: 172.18.20.0/24 nexthop: 172.18.0.1 vlan: 21 - allocationRanges: - end: 172.18.10.250 start: 172.18.10.100 cidr: 172.18.10.0/24 name: subnet2 routes: - destination: 172.18.0.0/24 nexthop: 172.18.10.1 - destination: 172.18.20.0/24 nexthop: 172.18.10.1 vlan: 31 - allocationRanges: - end: 172.18.20.250 start: 172.18.20.100 cidr: 172.18.20.0/24 name: subnet3 routes: - destination: 172.18.0.0/24 nexthop: 172.18.20.1 - destination: 172.18.10.0/24 nexthop: 172.18.20.1 vlan: 41为
租户网络添加分配范围：- dnsDomain: tenant.example.com mtu: 1496 name: tenant subnets: - allocationRanges: - end: 172.19.0.250 start: 172.19.0.100 cidr: 172.19.0.0/24 name: subnet1 routes: - destination: 172.19.10.0/24 nexthop: 172.19.0.1 - destination: 172.19.20.0/24 nexthop: 172.19.0.1 vlan: 22 - allocationRanges: - end: 172.19.10.250 start: 172.19.10.100 cidr: 172.19.10.0/24 name: subnet2 routes: - destination: 172.19.0.0/24 nexthop: 172.19.10.1 - destination: 172.19.20.0/24 nexthop: 172.19.10.1 vlan: 32 - allocationRanges: - end: 172.19.20.250 start: 172.19.20.100 cidr: 172.19.20.0/24 name: subnet3 routes: - destination: 172.19.0.0/24 nexthop: 172.19.20.1 - destination: 172.19.10.0/24 nexthop: 172.19.20.1 vlan: 42为
storagemgmt网络添加分配范围：- dnsDomain: storagemgmt.example.com mtu: 1500 name: storagemgmt subnets: - allocationRanges: - end: 172.20.0.250 start: 172.20.0.100 cidr: 172.20.0.0/24 name: subnet1 routes: - destination: 172.20.10.0/24 nexthop: 172.20.0.1 - destination: 172.20.20.0/24 nexthop: 172.20.0.1 vlan: 23 - allocationRanges: - end: 172.20.10.250 start: 172.20.10.100 cidr: 172.20.10.0/24 name: subnet2 routes: - destination: 172.20.0.0/24 nexthop: 172.20.10.1 - destination: 172.20.20.0/24 nexthop: 172.20.10.1 vlan: 33 - allocationRanges: - end: 172.20.20.250 start: 172.20.20.100 cidr: 172.20.20.0/24 name: subnet3 routes: - destination: 172.20.0.0/24 nexthop: 172.20.20.1 - destination: 172.20.10.0/24 nexthop: 172.20.20.1 vlan: 43
创建 NetConfig CR：
oc create -f netconfig
4.3. 创建 DCN control plane
OpenShift (RHOSO)控制平面上的 Red Hat OpenStack Services 包含用于管理云的 RHOSO 服务。RHOSO 服务作为 Red Hat OpenShift Container Platform (RHOCP)工作负载运行。
先决条件
-
已安装 OpenStack Operator (
openstack-operator)。 - RHOCP 集群为 RHOSO 网络做好准备。
RHOCP 集群没有配置任何防止
openstack-operators命名空间和 control plane 命名空间（默认openstack）之间的通信的网络策略。使用以下命令检查集群中的现有网络策略：$ oc get networkpolicy -n openstack-
以具有
cluster-admin权限的用户身份登录到可访问 RHOCP 集群的工作站。
流程
在工作站上创建一个名为
openstack_control_plane.yaml的文件，以定义OpenStackControlPlaneCR：apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack-control-plane namespace: openstack使用
spec字段指定您创建的SecretCR 来提供对 pod 的安全访问，以及您为 Red Hat OpenShift Container Platform (RHOCP)集群存储后端创建的storageClass：apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack-control-plane namespace: openstack spec: secret: osp-secret storageClass: <RHOCP_storage_class>- 将 <RHOCP_storage_class> 替换为您为 RHOCP 集群存储后端创建的存储类。
添加服务配置。包括所有所需服务的服务配置：
块存储服务(cinder)：
cinder: uniquePodNames: false apiOverride: route: {} template: customServiceConfig: | [DEFAULT] storage_availability_zone = az0 databaseInstance: openstack secret: osp-secret cinderAPI: replicas: 3 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer cinderScheduler: replicas: 1 cinderVolumes: az0: networkAttachments: - storage replicas: 0注意在 RHOSO 18.0.3 中，您必须将
uniquePodNames字段设置为false，以允许传播 Secret。如需更多信息，请参阅 OSPRH-11240。注意-
将
replicas字段设置为0的值。副本数已更改，并在配置存储后添加额外的cinderVolume服务。 -
将 template 部分中的
storage_availability_zone字段设置为az0。所有块存储服务(cinder) pod 都会继承这个值，如cinderBackup、cinderVolume等。您可以通过指定backend_availability_zone来为cinderVolume服务覆盖此 AZ。
-
将
计算服务(nova)：
nova: apiOverride: route: {} template: apiServiceTemplate: replicas: 3 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer metadataServiceTemplate: replicas: 3 override: service: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer schedulerServiceTemplate: replicas: 3 override: service: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer cellTemplates: cell0: cellDatabaseAccount: nova-cell0 cellDatabaseInstance: openstack cellMessageBusInstance: rabbitmq hasAPIAccess: true cell1: cellDatabaseAccount: nova-cell1 cellDatabaseInstance: openstack-cell1 cellMessageBusInstance: rabbitmq-cell1 noVNCProxyServiceTemplate: enabled: true networkAttachments: - ctlplane hasAPIAccess: true secret: osp-secretdata plane 的 DNS 服务：
dns: template: options: - key: server values: - 192.168.122.1 - key: server values: - 192.168.122.2 override: service: metadata: annotations: metallb.universe.tf/address-pool: ctlplane metallb.universe.tf/allow-shared-ip: ctlplane metallb.universe.tf/loadBalancerIPs: 192.168.122.80 spec: type: LoadBalancer replicas: 2galera
galera: templates: openstack: storageRequest: 5000M secret: osp-secret replicas: 3 openstack-cell1: storageRequest: 5000M secret: osp-secret replicas: 3Identity 服务 (keystone)
keystone: apiOverride: route: {} template: override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer databaseInstance: openstack secret: osp-secret replicas: 3镜像服务(glance)：
glance: apiOverrides: default: route: {} template: databaseInstance: openstack storage: storageRequest: 10G secret: osp-secret keystoneEndpoint: default glanceAPIs: default: replicas: 0 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer networkAttachments: - storage注意您最初必须将
replicas字段设置为 0。副本数已更改，并在配置存储后添加额外的glanceAPI服务。密钥管理服务(barbican)：
barbican: apiOverride: route: {} template: databaseInstance: openstack secret: osp-secret barbicanAPI: replicas: 3 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer barbicanWorker: replicas: 3 barbicanKeystoneListener: replicas: 1Memcached
memcached: templates: memcached: replicas: 3Networking 服务(neutron)：
neutron: apiOverride: route: {} template: customServiceConfig: | [DEFAULT] network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler default_availability_zones = az0 [ml2_type_vlan] network_vlan_ranges = datacentre:1:1000 [neutron] physnets = datacentre replicas: 3 override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer databaseInstance: openstack secret: osp-secret networkAttachments: - internalapi-
如果部署了 DHCP 代理，则将
network_scheduler_driver设置为neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler。 OVN
ovn: template: ovnController: external-ids: availability-zones: - az0 enable-chassis-as-gateway: true ovn-bridge: br-int ovn-encap-type: geneve system-id: random networkAttachment: tenant nicMappings: datacentre: ospbr ovnDBCluster: ovndbcluster-nb: replicas: 3 dbType: NB storageRequest: 10G networkAttachment: internalapi ovndbcluster-sb: replicas: 3 dbType: SB storageRequest: 10G networkAttachment: internalapi ovnNorthd: networkAttachment: internalapi放置服务(placement)
placement: apiOverride: route: {} template: override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer databaseInstance: openstack replicas: 3 secret: osp-secretRabbitMQ
rabbitmq: templates: rabbitmq: replicas: 3 override: service: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.85 spec: type: LoadBalancer rabbitmq-cell1: replicas: 3 override: service: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.86 spec: type: LoadBalancer
创建 control plane：
oc create -f openstack_control_plane.yaml -n openstack
4.4. Ceph secret 密钥站点分发
当您使用多个 Ceph 后端部署分布式计算节点(DCN)环境时，您可以为每个后端创建一个 Ceph 密钥。为了安全起见，请将最少的 Ceph 密钥数量分发到每个站点。为每个位置创建一个 secret。
- 将每个 Ceph 后端的密钥添加到默认位置的 secret 中。
- 为默认 Ceph 后端添加密钥，以及每个额外位置的本地 ceph 后端。
对于三个位置： az0、 az1 和 az2，您必须有三个 secret。位置 az1 和 az2 各自都有本地后端的密钥以及 az0 的密钥。位置 az0 包含所有 Ceph 后端密钥。
您可以在 Ceph 部署到每个边缘位置后创建所需的 secret，并收集每个 secret 的密钥环和配置文件。或者，您可以根据需要部署每个 Ceph 后端，并使用每个边缘部署更新 secret。
流程
为位置
az0创建 secret。如果您在所有需要存储的边缘站点部署了 Red Hat Ceph Storage (RHCS)，请为
az0创建一个 secret，其中包含所有密钥环和conf文件：oc create secret generic ceph-conf-az-0 \ --from-file=az0.client.openstack.keyring \ --from-file=az0.conf \ --from-file=az1.client.openstack.keyring \ --from-file=az1.conf \ --from-file=az2.client.openstack.keyring \ --from-file=az2.conf -n openstack如果您还没有在所有边缘站点上部署 RHCS，请为
az0创建一个 secret，其中包含az0的密钥环和conf文件：oc create secret generic ceph-conf-az-0 \ --from-file=az0.client.openstack.keyring \ --from-file=az0.conf -n openstack
当您在可用区 1 (z1)的边缘位置部署 RHCS 时，为位置
az1conf文件，以及默认后端：oc create secret generic ceph-conf-az-1 \ --from-file=az0.client.openstack.keyring \ --from-file=az0.conf \ --from-file=az1.client.openstack.keyring \ --from-file=az1.conf -n openstack如果需要，为中央位置更新 secret：
oc delete secret ceph-conf-az-0 -n openstack oc create secret generic ceph-conf-az-0 \ --from-file=az0.client.openstack.keyring \ --from-file=az0.conf \ --from-file=az1.client.openstack.keyring \ --from-file=az1.conf -n openstack当您在可用区 2 (z2)的边缘位置部署 RHCS 时，为位置
az2conf文件，以及默认后端：oc create secret generic ceph-conf-az-2 \ --from-file=az0.client.openstack.keyring \ --from-file=az0.conf \ --from-file=az2.client.openstack.keyring \ --from-file=az2.conf -n openstack如果需要，为中央位置更新 secret：
oc delete secret ceph-conf-az-0 -n openstack oc create secret generic ceph-conf-az-0 \ --from-file=az0.client.openstack.keyring \ --from-file=az0.conf \ --from-file=az1.client.openstack.keyring \ --from-file=az1.conf \ --from-file=az1.client.openstack.keyring \ --from-file=az1.conf \ --from-file=az2.client.openstack.keyring \ --from-file=az2.conf[可选] 完成创建所需密钥后，您可以验证它们是否出现在
openstack命名空间中：oc get secret -n openstack -o name | grep ceph-conf输出示例：
secret/ceph-conf-az-0 secret/ceph-conf-az-1 secret/ceph-conf-az-2创建
OpenStackDataPlaneNodeSet时，请使用extraMounts字段下的适当的键：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet metadata: name: openstack-edpm-dcn-0 namespace: openstack spec: ... nodeTemplate: extraMounts: - extraVolType: Ceph volumes: - name: ceph secret: secretName: ceph-conf-az-0 mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true在创建 data plane NodeSet 时，还必须使用 secret 名称更新
OpenStackControlPlane自定义资源(CR)：apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane spec: extraMounts: - name: v1 region: r1 extraVol: - propagation: - az0 - CinderBackup extraVolType: Ceph volumes: - name: ceph secret: name: ceph-conf-az-0 mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true - propagation: - az1 extraVolType: Ceph volumes: - name: ceph secret: name: ceph-conf-az-1 mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true ...注意如果
CinderBackup服务是部署的一部分，则必须将其包含在传播列表中，因为它在其 pod 名称中没有可用区。当您更新
OpenStackControlPlaneCR 中的glanceAPIs字段时，Image 服务(glance) pod 名称与extraMounts 传播实例匹配：glanceAPIs: az0: customServiceConfig: | ... az1: customServiceConfig: | ...当您更新
OpenStackControlPlaneCR 中的cinderVolumes字段时，块存储服务(cinder) pod 名称也必须与extraMounts 传播实例匹配：kind: OpenStackControlPlane spec: <...> cinder <...> cinderVolumes: az0: <...> az1: <...>
第 5 章 部署 DCN 节点集
节点集使用相同的流程部署，无论是否将其部署在中央位置，还是在远程位置进行部署。在单独的可用区部署每个边缘位置。例如，在 az0 上部署中央位置节点集，在 az1 上部署第一个边缘站点，等等。
5.1. 配置数据平面节点网络
您必须配置 data plane 节点网络，以适应 Red Hat Ceph Storage 网络要求。
先决条件
- control plane 部署已完成，但尚未修改以使用 Ceph Storage。
- data plane 节点已预置备操作系统。
- data plane 节点可以通过 Ansible 可以使用的 SSH 密钥访问。
- 如果您使用 HCI，则 data plane 节点具有可供用作 Ceph OSD 的磁盘。
- 至少三个可用的数据平面节点。Ceph Storage 集群必须至少有三个节点以确保冗余。
流程
在工作站上创建一个名为
dcn-data-plane-networks.yaml的文件，以防御OpenStackDataPlaneNodeSetCR，以配置 dataplane 节点网络：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet metadata: name: dcn-data-plane-networks namespace: openstack spec: env: - name: ANSIBLE_FORCE_COLOR value: "True"指定要应用到节点的服务：
spec: ... services: - bootstrap - configure-network - validate-network - install-os - ceph-hci-pre - configure-os - ssh-known-hosts - run-os - reboot-os在 data plane 中设置 edpm_enable_chassis_gw 和 edpm_ovn_availability_zones 字段：
spec: env: - name: ANSIBLE_FORCE_COLOR value: "True" networkAttachments: - ctlplane nodeTemplate: ansible: ansiblePort: 22 ansibleUser: cloud-admin ansibleVars: edpm_enable_chassis_gw: true edpm_ovn_availability_zones: - az0可选：
ceph-hci-pre服务准备 data plane 节点，以便在网络配置使用edpm_ceph_hci_pre edpm-ansible角色后托管 Red Hat Ceph Storage 服务。默认情况下，此角色的edpm_ceph_hci_pre_enabled_services参数仅包含RBD、RGW和NFS服务。DCN 只在 DCN 站点支持RBD服务。如果您要部署 HCI，请通过添加edpm_ceph_hci_pre_enabled_services参数来禁用 RGW 和 NFS 服务，并仅添加 ceph RBD 服务。apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet metadata: name: openstack-edpm namespace: openstack spec: env: - name: ANSIBLE_FORCE_COLOR value: "True" networkAttachments: - ctlplane nodeTemplate: ansible: ansiblePort: 22 ansibleUser: cloud-admin ansibleVars: edpm_ceph_hci_pre_enabled_services: - ceph_mon - ceph_mgr - ceph_osd ...注意如果其他服务（如 Dashboard）部署有 HCI 节点，则必须将它们添加到
edpm_ceph_hci_pre_enabled_services参数列表中。有关此角色的更多信息，请参阅 edpm_ceph_hci_pre 角色。配置 Red Hat Ceph Storage 集群网络以进行存储管理。
以下示例有 3 个节点。它假定存储管理位于
VLAN23上：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet metadata: name: openstack-edpm namespace: openstack spec: env: - name: ANSIBLE_FORCE_COLOR value: "True" networkAttachments: - ctlplane nodeTemplate: ansible: ansiblePort: 22 ansibleUser: cloud-admin ansibleVars: edpm_ceph_hci_pre_enabled_services: - ceph_mon - ceph_mgr - ceph_osd edpm_fips_mode: check edpm_iscsid_image: {{ registry_url }}/openstack-iscsid:{{ image_tag }} edpm_logrotate_crond_image: {{ registry_url }}/openstack-cron:{{ image_tag }} edpm_network_config_hide_sensitive_logs: false edpm_network_config_os_net_config_mappings: edpm-compute-0: nic1: 52:54:00:1e:af:6b nic2: 52:54:00:d9:cb:f4 edpm-compute-1: nic1: 52:54:00:f2:bc:af nic2: 52:54:00:f1:c7:dd edpm-compute-2: nic1: 52:54:00:dd:33:14 nic2: 52:54:00:50:fb:c3 edpm_network_config_template: | --- {% set mtu_list = [ctlplane_mtu] %} {% for network in nodeset_networks %} {{ mtu_list.append(lookup(vars, networks_lower[network] ~ _mtu)) }} {%- endfor %} {% set min_viable_mtu = mtu_list | max %} network_config: - type: ovs_bridge name: {{ neutron_physical_bridge_name }} mtu: {{ min_viable_mtu }} use_dhcp: false dns_servers: {{ ctlplane_dns_nameservers }} domain: {{ dns_search_domains }} addresses: - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }} routes: {{ ctlplane_host_routes }} members: - type: interface name: nic2 mtu: {{ min_viable_mtu }} # force the MAC address of the bridge to this interface primary: true {% for network in nodeset_networks %} - type: vlan mtu: {{ lookup(vars, networks_lower[network] ~ _mtu) }} vlan_id: {{ lookup(vars, networks_lower[network] ~ _vlan_id) }} addresses: - ip_netmask: {{ lookup(vars, networks_lower[network] ~ _ip) }}/{{ lookup(vars, networks_lower[network] ~ _cidr) }} routes: {{ lookup(vars, networks_lower[network] ~ _host_routes) }} {% endfor %} edpm_neutron_metadata_agent_image: {{ registry_url }}/openstack-neutron-metadata-agent-ovn:{{ image_tag }} edpm_nodes_validation_validate_controllers_icmp: false edpm_nodes_validation_validate_gateway_icmp: false edpm_selinux_mode: enforcing edpm_sshd_allowed_ranges: - 192.168.111.0/24 - 192.168.122.0/24 - 192.168.133.0/24 - 192.168.144.0/24 edpm_sshd_configure_firewall: true enable_debug: false gather_facts: false image_tag: current-podified neutron_physical_bridge_name: br-ex neutron_public_interface_name: eth0 service_net_map: nova_api_network: internalapi nova_libvirt_network: internalapi storage_mgmt_cidr: "24" storage_mgmt_host_routes: [] storage_mgmt_mtu: 9000 storage_mgmt_vlan_id: 23 storage_mtu: 9000 timesync_ntp_servers: - hostname: pool.ntp.org ansibleSSHPrivateKeySecret: dataplane-ansible-ssh-private-key-secret managementNetwork: ctlplane networks: - defaultRoute: true name: ctlplane subnetName: subnet1 - name: internalapi subnetName: subnet1 - name: storage subnetName: subnet1 - name: tenant subnetName: subnet1 nodes: edpm-compute-0: ansible: host: 192.168.122.100 hostName: compute-0 networks: - defaultRoute: true fixedIP: 192.168.122.100 name: ctlplane subnetName: subnet1 - name: internalapi subnetName: subnet1 - name: storage subnetName: subnet1 - name: storagemgmt subnetName: subnet1 - name: tenant subnetName: subnet1 edpm-compute-1: ansible: host: 192.168.122.101 hostName: compute-1 networks: - defaultRoute: true fixedIP: 192.168.122.101 name: ctlplane subnetName: subnet1 - name: internalapi subnetName: subnet1 - name: storage subnetName: subnet1 - name: storagemgmt subnetName: subnet1 - name: tenant subnetName: subnet1 edpm-compute-2: ansible: host: 192.168.122.102 hostName: compute-2 networks: - defaultRoute: true fixedIP: 192.168.122.102 name: ctlplane subnetName: subnet1 - name: internalapi subnetName: subnet1 - name: storage subnetName: subnet1 - name: storagemgmt subnetName: subnet1 - name: tenant subnetName: subnet1 preProvisioned: true services: - bootstrap - configure-network - validate-network - install-os - ceph-hci-pre - configure-os - ssh-known-hosts - run-os - reboot-os应用 CR：
$ oc apply -f <dataplane_cr_file>将
<dataplane_cr_file> 替换为您的文件的名称。注意Ansible 在创建
OpenStackDataPlaneDeploymentCRD 之前，不会配置或验证网络。
-
创建
OpenStackDataPlaneDeploymentCRD，如在 OpenShift 上部署 Red Hat OpenStack Services on OpenShift 指南中的创建 data plane 所述，它定义了OpenStackDataPlaneNodeSetCRD 文件，以便 Ansible 配置 data plane 节点上的服务。 要确认网络配置，请完成以下步骤：
- SSH 到数据平面节点。
-
使用
ip a命令显示配置网络。 - 确认存储网络位于配置网络列表中。
5.2. 配置和部署超融合 Red Hat Ceph Storage
以下步骤专门用于 Red Hat Ceph Storage (RHCS)的超融合配置，如果您部署了外部 RHCS 集群，则不需要以下步骤。
通过编辑配置文件和使用 cephadm 实用程序来配置和部署 Red Hat Ceph Storage。
流程
- 编辑 Red Hat Ceph Storage 配置文件。
添加
Storage和Storage Management网络范围。Red Hat Ceph Storage 使用Storage网络作为 Red Hat Ceph Storagepublic_network，Storage Management网络作为cluster_network。以下示例是
Storage网络范围为172.18.0.0/24的配置文件条目，Storage Management网络范围为172.20.0.0/24：[global] public_network = 172.18.0.0/24 cluster_network = 172.20.0.0/24在 Compute 服务和 Ceph OSD 服务之间添加并置界限。应在并置计算服务和 Ceph OSD 服务之间设置界限，以减少 CPU 和内存争用。
以下是设置了这些边界的 Ceph 配置文件条目的示例：
[osd] osd_memory_target_autotune = true osd_numa_auto_affinity = true [mgr] mgr/cephadm/autotune_memory_target_ratio = 0.2在本例中，
osd_memory_target_autotune参数设置为true，以便 OSD 守护进程根据osd_memory_target选项调整内存消耗。autotune_memory_target_ratio默认为 0.7。这意味着系统总 RAM 的 70% 是非自动调优 Ceph 守护进程所消耗的内存的起点。剩余的内存在 OSD 之间划分；假设所有 OSD 的osd_memory_target_autotune设置为 true。对于 HCI 部署，您可以将mgr/cephadm/autotune_memory_target_ratio设置为 0.2，以便计算服务有更多内存可用。有关服务并置的更多信息，请参阅 在 NUMA 节点的 HCI 环境中并置服务。
注意如果需要在部署后调整这些值，请使用
ceph config set osd <key> <value>命令。使用 data plane 节点上编辑的配置文件部署 Ceph Storage：
$ cephadm bootstrap --config <config_file> --mon-ip <data_plane_node_ip> --skip-monitoring-stack-
将
<config_file> 替换为 Ceph 配置文件的名称。 将
<data_plane_node_ip> 替换为安装 Red Hat Ceph Storage 的 data plane 节点的 Storage 网络 IP 地址。注意cephadm bootstrap命令中使用--skip-monitoring-stack选项，以跳过监控服务的部署。如果之前已作为上述其他流程的一部分部署了监控服务，则确保 Red Hat Ceph Storage 部署成功完成。如果还没有部署监控服务，请参阅 Red Hat Ceph Storage 文档来了解启用监控服务的信息和流程。
-
将
- 在第一个 EDPM 节点上启动 Red Hat Ceph Storage 集群后，请参阅 Red Hat Ceph Storage 安装指南中的 Red Hat Ceph Storage 安装，将其他 EDPM 节点添加到 Ceph 集群。
5.3. 配置 DCN 数据平面
在 data plane 节点可以使用前，必须将 Red Hat Ceph Storage 配置为存储解决方案。
先决条件
- 完成 集成 Red Hat Ceph Storage 中的步骤。
流程
-
编辑
OpenStackDataPlaneNodeSetCR。 要使
cephx密钥和配置文件可用于计算服务(nova)，请使用extraMounts参数。以下是为此目的使用
extraMounts参数的示例：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet spec: ... nodeTemplate: extraMounts: - extraVolType: Ceph volumes: - name: ceph secret: secretName: ceph-conf-files mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true创建
ConfigMap，将所需的配置详情添加到计算服务(nova)。创建名为ceph-nova-az0.yaml的文件，并添加类似以下内容的内容：您必须为本地可用区添加 Image 服务(glance)端点，并将cross_az_attach参数设置为 false ：apiVersion: v1 kind: ConfigMap metadata: name: ceph-nova-az0 namespace: openstack data: 03-ceph-nova.conf: [libvirt] images_type = rbd images_rbd_pool = vms images_rbd_ceph_conf = /etc/ceph/az0.conf images_rbd_glance_store_name = az0 images_rbd_glance_copy_poll_interval = 15 images_rbd_glance_copy_timeout = 600 rbd_user = openstack rbd_secret_uuid = 9cfb3a03-3f91-516a-881e-a675f67c30ea hw_disk_discard = unmap volume_use_multipath = False [glance] endpoint_override = http://glance-az0-internal.openstack.svc:9292 valid_interfaces = internal [cinder] cross_az_attach = False catalog_info = volumev3:cinderv3:internalURL创建
ConfigMap：oc create -f ceph-nova-az0.yaml创建自定义 Compute (nova)服务以使用 ConfigMap。创建名为
nova-custom-az0.yaml的文件，并添加类似以下内容的内容：您必须在dataSources字段中添加您刚才创建的ConfigMap的名称：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneService metadata: name: nova-custom-ceph-az0 spec: addCertMounts: false caCerts: combined-ca-bundle dataSources: - configMapRef: name: ceph-nova-az0 - secretRef: name: nova-cell1-compute-config - secretRef: name: nova-migration-ssh-key edpmServiceType: nova playbook: osp.edpm.nova tlsCerts: default: contents: - dnsnames - ips edpmRoleServiceName: nova issuer: osp-rootca-issuer-internal networks: - ctlplane创建自定义服务：
oc create -f nova-custom-ceph-az0.yaml注意您必须为每个可用区创建一个唯一的
ConfigMap和自定义 Compute 服务。如前面的步骤所示，将可用区附加到这些文件名的末尾。-
在 CR 中找到
服务列表。 编辑
服务列表，以恢复 配置 data plane 节点网络 中描述的所有服务。恢复完整服务列表可让剩余的作业完成 HCI 环境的配置。以下是一个完整
服务列表的示例，其额外服务以粗体显示：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet spec: ... services: - bootstrap - configure-network - validate-network - install-os - ceph-hci-pre - configure-os - ssh-known-hosts - run-os - reboot-os - install-certs - ceph-client - ovn - neutron-metadata - libvirt - nova-custom-ceph-az0注意除了恢复默认服务列表外，
ceph-client服务也会在run-os服务后添加。ceph-client服务将 EDPM 节点配置为 Red Hat Ceph Storage 服务器的客户端。此服务分发客户端连接到 Red Hat Ceph Storage 服务器所需的文件。只有在部署 HCI 时，才需要ceph-hci-pre服务。可选： 您可以将计算节点分配给 Compute 服务(nova)单元，与在任何其他环境中相同的单元。将
OpenStackDataPlaneNodeSetCR 中的nova服务替换为您的自定义nova服务：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet metadata: name: openstack-cell2 spec: services: - download-cache - bootstrap - configure-network - validate-network - install-os - configure-os - ssh-known-hosts - run-os - ovn - libvirt - *nova-cell-custom*如需更多信息，请参阅 将 OpenStackDataPlaneNodeSetSR 连接到计算单元。
注意如果您使用单元，则
neutron-metadata服务为每个单元是唯一的，并单独定义。例如，neutron-metadata-cell1：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneService metadata: labels: app.kubernetes.io/instance: neutron-metadata-cell1 app.kubernetes.io/name: openstackdataplaneservice app.kubernetes.io/part-of: openstack-operator name: neutron-metadata-cell1 ...nova-custom-ceph服务对于每个可用区是唯一的，并单独定义。例如，nova-custom-ceph-az0：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneService metadata: labels: app.kubernetes.io/instance: nova-custom-ceph-az0 app.kubernetes.io/name: openstackdataplaneservice app.kubernetes.io/part-of: openstack-operator name: nova-custom-ceph-az0 namespace: openstack可选： 如果您要将 Red Hat Ceph Storage (RHCS)部署为超融合解决方案，请完成以下步骤：
创建一个
ConfigMap，将reserved_host_memory_mb参数设置为适合您配置的值：以下是用于此目的的 ConfigMap 示例：
apiVersion: v1 kind: ConfigMap metadata: name: reserved-memory-nova data: 04-reserved-memory-nova.conf: | [DEFAULT] reserved_host_memory_mb=75000注意可以设置
reserved_host_memory_mb参数的值，以便计算服务调度程序不会将内存提供给同一服务器上的 Ceph OSD 所需的虚拟机。除了虚拟机监控程序的默认保留内存外，示例还为每个主机保留 5 GB 的 OSD 为 10 个 OSD。在 IOPS 优化的集群中，您可以通过为每个 OSD 保留更多内存来提高性能。5 GB 数字作为起点提供，必要时可以进一步调整。编辑
OpenStackDataPlaneService/nova-custom-ceph-az文件。将reserved-memory-nova添加到之前创建的OpenStackDataPlaneServiceCR 中的configMaps列表中，名为ceph-nova-az0：kind: OpenStackDataPlaneService <...> spec: configMaps: - ceph-nova - reserved-memory-nova
应用 CR 更改。
$ oc apply -f <dataplane_cr_file>将
<dataplane_cr_file> 替换为您的文件的名称。注意Ansible 在创建
OpenStackDataPlaneDeploymentCRD 之前，不会配置或验证网络。
-
创建
OpenStackDataPlaneDeploymentCRD，如在 OpenShift 上部署 Red Hat OpenStack Services on OpenShift 指南中的创建 data plane 所述，它定义了OpenStackDataPlaneNodeSetCRD 文件，以便 Ansible 配置 data plane 节点上的服务。
example-node-set-resource
5.4. 节点设置资源示例
以下示例有三个节点。它假定存储管理网络范围为 172.20.0.0/24，并且它位于 vlan23 上。
apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneNodeSet
metadata:
name: openstack-edpm
namespace: openstack
spec:
env:
- name: ANSIBLE_FORCE_COLOR
value: "True"
networkAttachments:
- ctlplane
nodeTemplate:
ansible:
ansiblePort: 22
ansibleUser: cloud-admin
ansibleVars:
edpm_ceph_hci_pre_enabled_services:
- ceph_mon
- ceph_mgr
- ceph_osd
edpm_fips_mode: check
edpm_iscsid_image: {{ registry_url }}/openstack-iscsid:{{ image_tag }}
edpm_logrotate_crond_image: {{ registry_url }}/openstack-cron:{{ image_tag }}
edpm_network_config_hide_sensitive_logs: false
edpm_network_config_os_net_config_mappings:
edpm-compute-0:
nic1: 52:54:00:1e:af:6b
nic2: 52:54:00:d9:cb:f4
edpm-compute-1:
nic1: 52:54:00:f2:bc:af
nic2: 52:54:00:f1:c7:dd
edpm-compute-2:
nic1: 52:54:00:dd:33:14
nic2: 52:54:00:50:fb:c3
edpm_network_config_template: |
---
{% set mtu_list = [ctlplane_mtu] %}
{% for network in nodeset_networks %}
{{ mtu_list.append(lookup(vars, networks_lower[network] ~ _mtu)) }}
{%- endfor %}
{% set min_viable_mtu = mtu_list | max %}
network_config:
- type: ovs_bridge
name: {{ neutron_physical_bridge_name }}
mtu: {{ min_viable_mtu }}
use_dhcp: false
dns_servers: {{ ctlplane_dns_nameservers }}
domain: {{ dns_search_domains }}
addresses:
- ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }}
routes: {{ ctlplane_host_routes }}
members:
- type: interface
name: nic2
mtu: {{ min_viable_mtu }}
# force the MAC address of the bridge to this interface
primary: true
{% for network in nodeset_networks %}
- type: vlan
mtu: {{ lookup(vars, networks_lower[network] ~ _mtu) }}
vlan_id: {{ lookup(vars, networks_lower[network] ~ _vlan_id) }}
addresses:
- ip_netmask:
{{ lookup(vars, networks_lower[network] ~ _ip) }}/{{ lookup(vars, networks_lower[network] ~ _cidr) }}
routes: {{ lookup(vars, networks_lower[network] ~ _host_routes) }}
{% endfor %}
edpm_neutron_metadata_agent_image: {{ registry_url }}/openstack-neutron-metadata-agent-ovn:{{ image_tag }}
edpm_nodes_validation_validate_controllers_icmp: false
edpm_nodes_validation_validate_gateway_icmp: false
edpm_selinux_mode: enforcing
edpm_sshd_allowed_ranges:
- 192.168.111.0/24
- 192.168.122.0/24
- 192.168.133.0/24
- 192.168.144.0/24
edpm_sshd_configure_firewall: true
enable_debug: false
gather_facts: false
image_tag: current-podified
neutron_physical_bridge_name: br-ex
neutron_public_interface_name: eth0
service_net_map:
nova_api_network: internalapi
nova_libvirt_network: internalapi
storage_mgmt_cidr: "24"
storage_mgmt_host_routes: []
storage_mgmt_mtu: 9000
storage_mgmt_vlan_id: 23
storage_mtu: 9000
timesync_ntp_servers:
- hostname: pool.ntp.org
ansibleSSHPrivateKeySecret: dataplane-ansible-ssh-private-key-secret
managementNetwork: ctlplane
networks:
- defaultRoute: true
name: ctlplane
subnetName: subnet1
- name: internalapi
subnetName: subnet1
- name: storage
subnetName: subnet1
- name: tenant
subnetName: subnet1
- name: external
subnetName: external1
nodes:
edpm-compute-0:
ansible:
host: 192.168.122.100
hostName: compute-0
networks:
- defaultRoute: true
fixedIP: 192.168.122.100
name: ctlplane
subnetName: subnet1
- name: internalapi
subnetName: subnet1
- name: storage
subnetName: subnet1
- name: storagemgmt
subnetName: subnet1
- name: tenant
subnetName: subnet1
- name: external
subnetName: external1
edpm-compute-1:
ansible:
host: 192.168.122.101
hostName: compute-1
networks:
- defaultRoute: true
fixedIP: 192.168.122.101
name: ctlplane
subnetName: subnet1
- name: internalapi
subnetName: subnet1
- name: storage
subnetName: subnet1
- name: storagemgmt
subnetName: subnet1
- name: tenant
subnetName: subnet1
- name: external
subnetName: external1
edpm-compute-2:
ansible:
host: 192.168.122.102
hostName: compute-2
networks:
- defaultRoute: true
fixedIP: 192.168.122.102
name: ctlplane
subnetName: subnet1
- name: internalapi
subnetName: subnet1
- name: storage
subnetName: subnet1
- name: storagemgmt
subnetName: subnet1
- name: tenant
subnetName: subnet1
- name: external
subnetName: external1
preProvisioned: true
services:
- bootstrap
- configure-network
- validate-network
- install-os
- ceph-hci-pre
- configure-os
- ssh-known-hosts
- run-os
- reboot-os不需要将存储管理网络添加到 networkAttachments 键。
5.5. 更新 control plane
在中央位置部署了数据平面后，您必须更新 control plane。
先决条件
- 您已在 OpenShift 中使用 Red Hat OpenStack 服务在中央位置部署了节点集。
- 您已部署了 Red Hat Ceph Storage (RHCS)。
流程
可选：在
openstack_control_plane.yaml文件中配置块存储备份服务：cinderBackup: customServiceConfig: | [DEFAULT] backup_driver = cinder.backup.drivers.ceph.CephBackupDriver backup_ceph_pool = backups backup_ceph_user = openstack有关配置块存储备份服务的更多信息 ，请参阅配置块存储备份服务。
更新
openstack_control_plane.yaml文件中的 Block Storage cinder 卷服务：cinderVolumes: az0: customServiceConfig: | [DEFAULT] enabled_backends = ceph glance_api_servers = https://glance-az0-internal.openstack.svc:9292 [ceph] volume_backend_name = ceph volume_driver = cinder.volume.drivers.rbd.RBDDriver rbd_ceph_conf = /etc/ceph/az0.conf rbd_user = openstack rbd_pool = volumes rbd_flatten_volume_from_snapshot = False rbd_secret_uuid = 795dcbca-e715-5ac3-9b7e-a3f5c64eb89f rbd_cluster_name = az0 backend_availability_zone = az0有关配置块存储卷服务的更多信息 ，请参阅配置卷服务。
在
openstack_control_plane.yaml文件中添加 extraMounts 字段，以定义需要访问 Red Hat Ceph Storage secret 的服务：extraMounts: - extraVol: - extraVolType: Ceph mounts: - mountPath: /etc/ceph name: ceph readOnly: true propagation: - az0 - CinderBackup volumes: - name: ceph projected: sources: - secret: name: ceph-conf-az-0更新
openstack_control_plane.yaml文件中的 Image 服务(glance)，将块存储服务配置为后端：glanceAPIs: az0: customServiceConfig: | [DEFAULT] enabled_import_methods = [web-download,copy-image,glance-direct] enabled_backends = az0:rbd [glance_store] default_backend = az0 [az0] rbd_store_ceph_conf = /etc/ceph/az0.conf store_description = "az0 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True应用对
OpenStackControlPlaneCR 所做的更改：oc apply -f openstack_control_plane.yaml将 AZ 添加到主机聚合中。这使得 OpenStack 管理员能够根据镜像元数据将工作负载调度到地理位置。
打开终端到
openstackclientpod:# oc rsh openstackclient创建新的 OpenStack 聚合：
$ openstack aggregate create <aggregate_name>使用 AZ 名称标记 OpenStack 聚合：
$ openstack aggregate set --zone <availability_zone> <aggregate_name>将 AZ 中的每个主机添加到聚合中：
$ openstack aggregate add host <aggregate_name> <compute_node_1> $ openstack aggregate add host <aggregate_name> <compute_node_2> ...
5.6. 在部署 DCN 边缘位置后更新 control plane
您可以使用 OpenStackDataPlaneNodeSet 自定义资源(CR)创建额外的节点集。使用唯一的可用区，以及特定于您要部署的站点的 VLAN、NIC 映射和 IP 地址。如需有关部署 OpenStackDataPlaneNodeSet 的更多信息，请参阅创建数据平面。
当使用存储部署 DCN 节点集时，您必须在中央位置更新 OpenStackControlPlane CR 的两个字段：
-
cinderVolumes -
glanceapis - Neutron
- OVN
如果使用单元，还必须为新的 DCN 站点配置单元。
先决条件
- 您已部署了中央位置。
-
您已部署了额外的
OpenStackDataPlane节点集。
流程
在 neutron 服务配置中，更新 customServiceConfig 字段，以添加新的可用区和网络叶：
customServiceConfig: | [DEFAULT] router_scheduler_driver = neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler default_availability_zones = az0,az1 [ml2_type_vlan] network_vlan_ranges = datacentre:1:1000,leaf1:1:1000 [neutron] physnets = datacentre,leaf在 OVN 服务配置中，更新可用区：
ovnController: external-ids: availability-zones: - az0 - az1 enable-chassis-as-gateway ovn-bridge: br-int onv-enap-type: geneve system-id: random networkAttachment: tenant nicMappings: datacentre: ospbr更新
OpenStackControlPlaneCR 中的cinderVolumes字段，以添加远程位置的可用区定义。每个可用区中的每个 Cinder 卷服务使用 Glance API 服务器作为其可用区。例如，glance_api_servers = https://glance-az1-internal.openstack.svc:9292：cinderVolumes: az0: customServiceConfig: | [DEFAULT] .... az1: customServiceConfig: | [DEFAULT] enabled_backends = ceph glance_api_servers = https://glance-az1-internal.openstack.svc:9292 [ceph] volume_backend_name = az1 volume_driver = cinder.volume.drivers.rbd.RBDDriver rbd_ceph_conf = /etc/ceph/az1.conf rbd_user = openstack rbd_pool = volumes rbd_flatten_volume_from_snapshot = False rbd_secret_uuid = 19ccdd60-79a0-5f0f-aece-ece700e514f8 rbd_cluster_name = az1 backend_availability_zone = az1将镜像服务(glance) pod 注册到 Identity Service (keystone)目录：
在 DCN 中，为每个节点部署了一个镜像服务 pod。单个镜像服务 pod 注册到 Identity service (keystone)目录。因此，在顶级 Glance CR 中，定义并公开 keystoneEndpoint 参数。除非部署了单个实例，否则可以在应用主 OpenStackControlPlane CR 之前选择 human 操作符，哪些实例应在 keystone 中注册。因为我们的默认端点是
az0glance API，所以 keystoneEndpoint 被设置为 az0 ：spec: <...> glance: enabled: true keystoneEndpoint: az0 glanceAPIs: az0: apiTimeout: 60更新
glanceAPIs字段：对于位于
az0的节点集，glanceAPIs字段为中央位置配置镜像服务 pod。当您添加 AZ1 中设置的额外节点时，OpenStackControlPlaneCR 会被更新，以便glanceAPIs字段包含 AZ0 和 AZ1 的镜像服务(glance) pod 定义。另外，AZ1 的镜像服务 pod 定义了 ceph 作为中央位置的后端，以及中央位置的 AZ0 镜像服务 pod 已更新，使其具有 AZ1 的 ceph 后端定义。glanceAPIs: az1: customServiceConfig: | [DEFAULT] enabled_import_methods = [web-download,copy-image,glance-direct] enabled_backends = az0:rbd,az1:rbd [glance_store] default_backend = az1 [az1] rbd_store_ceph_conf = /etc/ceph/az1.conf store_description = "az1 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True [az0] rbd_store_ceph_conf = /etc/ceph/az0.conf store_description = "az0 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True networkAttachments: - storage override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.81 spec: type: LoadBalancer replicas: 2 type: edge az0: customServiceConfig: | [DEFAULT] enabled_import_methods = [web-download,copy-image,glance-direct] enabled_backends = az0:rbd,az1:rbd [glance_store] default_backend = az0 [az0] rbd_store_ceph_conf = /etc/ceph/az0.conf store_description = "az0 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True [az1] rbd_store_ceph_conf = /etc/ceph/az1.conf store_description = "az1 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True networkAttachments: - storage override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer replicas: 3 type: split注意可用域
az0类型为split，所有其他可用区都类型为edge。分割类型是云用户在上传镜像时使用。创建边缘类型，以便在 Cinder 或 Nova 与 Glance 交互时，可以将它们配置为 glance 是本地的。对默认分割 glance pod 使用至少 3 个副本，为 edge glance pod 使用 2 个副本，并将副本按比例增加到工作负载。
可选：更新 Cell 配置。
默认情况下，所有可用区(AZ)之间的计算节点放置在一个名为
cell1的通用单元中。您可以通过将计算节点分区到单独的单元来提高大型部署的性能。对于 DCN 部署，将每个可用区放在自己的单元中。如需更多信息，请参阅在 control plane 中添加计算单元。应用对
OpenStackControlPlaneCR 所做的更改：oc apply -f openstack_control_plane.yaml继续为添加的每个额外边缘站点更新 control plane。根据需要，将 Red Hat Storage Service (RHCS)添加到 OpenShift secret 中。
在 neutron 服务配置中，更新 customServiceConfig 字段，以添加新的可用区和网络叶：
customServiceConfig: | [DEFAULT] router_scheduler_driver = neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler default_availability_zones = az0,az1,az2 [ml2_type_vlan] network_vlan_ranges = datacentre:1:1000,leaf1:1:1000,leaf2:1:1000 [neutron] physnets = datacentre,leaf1,leaf2在 OVN 服务配置中，更新可用区
ovnController: external-ids: availability-zones: - az0 - az1 - az2 enable-chassis-as-gateway ovn-bridge: br-int onv-enap-type: geneve system-id: random networkAttachment: tenant nicMappings: datacentre: ospbr在
cinderVolumesservice 字段添加一个额外的可用区：cinderVolumes: az0: customServiceConfig: | [DEFAULT] ... az1: customServiceConfig: | [DEFAULT] ... az2: customServiceConfig: | [DEFAULT] enabled_backends = ceph glance_api_servers = https://glance-az2-internal.openstack.svc:9292 [ceph] volume_backend_name = ceph volume_driver = cinder.volume.drivers.rbd.RBDDriver rbd_ceph_conf = /etc/ceph/az2.conf rbd_user = openstack rbd_pool = volumes rbd_flatten_volume_from_snapshot = False rbd_secret_uuid = 5c0c7a8e-55b1-5fa8-bc5c-9756b7862d2f rbd_cluster_name = az2 backend_availability_zone = az2在
glanceAPIs字段中添加额外的可用区：在添加额外的 AZ 时，您必须确保每个镜像服务 pod 定义都包含中央位置(AZ0)的存储配置，以及自己的本地 ceph 配置。您还必须确保中央位置具有所有其他站点的存储定义。这会在中央位置镜像服务 pod 和分布的节点集合的镜像服务 pod 之间创建一个 hub 和 spoke 关系：
glanceAPIs: az0: customServiceConfig: | [DEFAULT] enabled_import_methods = [web-download,copy-image,glance-direct] enabled_backends = az0:rbd,az1:rbd,az2:rbd [glance_store] default_backend = az0 [az0] rbd_store_ceph_conf = /etc/ceph/az0.conf store_description = "az0 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True [az1] rbd_store_ceph_conf = /etc/ceph/az1.conf store_description = "az1 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True [az2] rbd_store_ceph_conf = /etc/ceph/az2.conf store_description = "az2 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True networkAttachments: - storage override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.80 spec: type: LoadBalancer replicas: 3 type: split az1: customServiceConfig: | [DEFAULT] enabled_import_methods = [web-download,copy-image,glance-direct] enabled_backends = az0:rbd,az1:rbd [glance_store] default_backend = az1 [az1] rbd_store_ceph_conf = /etc/ceph/az1.conf store_description = "az1 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True [az0] rbd_store_ceph_conf = /etc/ceph/az0.conf store_description = "az0 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True networkAttachments: - storage override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.81 spec: type: LoadBalancer replicas: 2 type: edge az2: customServiceConfig: | [DEFAULT] enabled_import_methods = [web-download,copy-image,glance-direct] enabled_backends = az0:rbd,az2:rbd [glance_store] default_backend = az2 [az2] rbd_store_ceph_conf = /etc/ceph/az2.conf store_description = "az2 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True [az0] rbd_store_ceph_conf = /etc/ceph/az0.conf store_description = "az0 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True networkAttachments: - storage override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.82 spec: type: LoadBalancer replicas: 2 type: edge
应用对
OpenStackControlPlaneCR 所做的更改：oc apply -f openstack_control_plane.yaml将 AZ 添加到主机聚合中。这允许 OpenStack 管理员通过传递-
availabliity-zone参数将工作负载调度到地理位置：打开终端到
openstackclientpod:# oc rsh openstackclient创建新的 OpenStack 聚合：
$ openstack aggregate create <aggregate_name>使用 AZ 名称标记 OpenStack 聚合：
$ openstack aggregate set --zone <availability_zone> <aggregate_name>将 AZ 中的每个主机添加到聚合中：
$ openstack aggregate add host <aggregate_name> <compute_node_1> $ openstack aggregate add host <aggregate_name> <compute_node_2> ...
5.7. 在 DCN 站点中添加节点到节点集
您可以通过将新节点添加到现有 OpenStackDataPlaneNodeSet 自定义资源(CR)的 nodes 部分，在站点扩展数据平面。
先决条件
- 您要添加的节点是预置备的。如需有关 预置备的更多信息，请参阅使用预置备节点创建 OpenStackDataPlaneNodeSet CR。
流程
-
为您要更新的节点集打开
OpenStackDataPlaneNodeSet清单文件，如openstack_data_plane.yaml。 将新节点添加到节点集中：
apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet metadata: name: openstack-node-set spec: preProvisioned: True nodes: ... edpm-compute-3: hostName: edpm-compute-3 ansible: ansibleHost: 192.168.122.103 networks: - name: CtlPlane subnetName: subnet1 defaultRoute: true fixedIP: 192.168.122.103 - name: InternalApi subnetName: subnet1 - name: Storage subnetName: subnet1 - name: Tenant subnetName: subnet1 ...在
OpenStackDataPlaneNodeSet清单文件中，编辑edpm_network_config_os_net_config_mappings，以添加新主机的 mac 地址：... edpm_network_config_os_net_config_mappings: edpm-compute-0: nic1: 52:54:00:1e:af:6b nic2: 52:54:00:d9:cb:f4 edpm-compute-1: nic1: 52:54:00:f2:bc:af nic2: 52:54:00:f1:c7:dd edpm-compute-2: nic1: 52:54:00:dd:33:14 nic2: 52:54:00:50:fb:c3 edpm-compute-3: nic1: 52:54:12:8b:be:9a nic2: 52:54:12:8b:be:9b（可选）如果要使用 HCI 将节点添加到数据平面部署中，您必须完成以下内容：
必须存在
extraMounts参数，以定义 Compute 服务(nova)的cephx密钥和配置文件。确保OpenStackDataPlaneNodeSet清单文件中存在extraMounts配置：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet spec: ... nodeTemplate: extraMounts: - extraVolType: Ceph volumes: - name: ceph secret: secretName: ceph-conf-files mounts: - name: ceph mountPath: "/etc/ceph" readOnly: true指定要应用到节点的其他服务：
apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneNodeSet spec: ... services: - bootstrap - configure-network - validate-network - install-os - ceph-hci-pre - configure-os - ssh-known-hosts - run-os - reboot-os - install-certs - ceph-client - ovn - neutron-metadata - libvirt - nova-custom-ceph-az0注意在配置 DCN 数据平面时，
nova-custom-ceph-az0服务会被创建，应在这一步中出现。如需更多信息 ，请参阅配置 DCN 数据平面。
-
保存
OpenStackDataPlaneNodeSet清单文件。 应用更新的
OpenStackDataPlaneNodeSetCR 配置：$ oc apply -f <data-plane-custom-resource-file>-
将
<data-plane-custom-resource-file> 替换为您编辑的清单文件的名称。
-
将
通过确认状态为
SetupReady来验证 data plane 资源是否已更新：$ oc wait openstackdataplanenodeset <node-set-name> --for condition=SetupReady --timeout=10m-
将
<node-set-name> 替换为您要将节点添加到的OpenStackDataPlaneNodeSetCR 的名称。
当状态是
SetupReady时，命令会返回一个condition met消息，否则会返回超时错误。如需有关 data plane 条件和状态的信息，请参阅 在 OpenShift 上部署 Red Hat OpenStack Services 中的 Data plane 条件 和状态。-
将
在工作站上创建一个文件来定义
OpenStackDataPlaneDeploymentCR：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneDeployment metadata: name: <node_set_scaling_deployment_name>-
将
<node_set_scaling_deployment_name> 替换为OpenStackDataPlaneDeploymentCR 的名称。名称必须是唯一的，且无法与之前创建的OpenStackDataPlaneDeployment匹配。您选择的名称必须包含小写字母数字字符(hyphen)或.（句点），且必须以字母数字字符开头和结尾。
提示为定义文件和
OpenStackDataPlaneDeploymentCR 提供唯一和描述性名称，以指示修改的节点集的用途。-
将
添加您修改的
OpenStackDataPlaneNodeSetCR：spec: nodeSets: - <nodeSet_name>-
保存
OpenStackDataPlaneDeploymentCR 部署文件。 部署修改后的
OpenStackDataPlaneNodeSetCR：$ oc create -f openstack_data_plane_deploy.yaml -n openstack您可以在部署执行时查看 Ansible 日志：
$ oc get pod -l app=openstackansibleee -w $ oc logs -l app=openstackansibleee -f --max-log-requests 10如果
oc logs命令返回类似以下错误的错误，请提高--max-log-requests值：error: you are attempting to follow 19 log streams, but maximum allowed concurrency is 10, use --max-log-requests to increase the limit验证修改后的
OpenStackDataPlaneNodeSetCR 是否已部署：$ oc get openstackdataplanedeployment -n openstack NAME NODESETS STATUS MESSAGE openstack-data-plane ["openstack-data-plane"] True Setup Complete $ oc get openstackdataplanenodeset -n openstack NAME STATUS MESSAGE openstack-data-plane True NodeSet Ready有关返回状态的含义的信息，请参阅 在 OpenShift 上部署 Red Hat OpenStack Services 中的 Data plane 条件和状态。
如果状态表示 data plane 尚未部署，则对部署进行故障排除。有关故障排除的更多信息，请参阅在 OpenShift 上部署 Red Hat OpenStack Services 中的 对 data plane 创建和部署进行故障排除。
（可选）：如果要使用 HCI 将节点添加到数据平面部署中，则必须将节点配置为 Ceph OSD 节点，并将其配置为使用并置 Red Hat Ceph Storage 集群。如需更多信息，请参阅以下资源：
如果新节点是 Compute 节点，则必须在线它们：
将 Compute 节点映射到它们连接的 Compute 单元：
$ oc rsh nova-cell0-conductor-0 nova-manage cell_v2 discover_hosts --verbose如果您没有创建额外的单元，这个命令会将 Compute 节点映射到
cell1。访问
openstackclientpod 的远程 shell，并验证部署的 Compute 节点是否在 control plane 上可见：$ oc rsh -n openstack openstackclient $ openstack hypervisor list注意在后端中将 Ceph 编排器与 Cephadm 搭配使用，将主机添加到现有的 Red Hat Ceph Storage 集群中。有关更多信息，请参阅 [使用 Ceph 编排器] 添加主机。
将新主机添加到与节点集或其所在地理位置对应的可用区(AZ)：
打开终端到
openstackclientpod:$ oc rsh openstackclient将主机添加到 AZ 聚合中：
$ openstack aggregate add host <availability_zone> <compute_node_3>-
将
<availability_zone> 替换为新主机所在 AZ 的名称。 -
将 <
compute_node_3> 替换为您要添加到节点集合中的主机的名称。
-
将
第 6 章 从 RHOSO DCN 部署中删除 DCN 站点
您可以从 DCN 配置中删除未使用的边缘位置和可用区。
6.1. 从 RHOSO DCM 部署中停用边缘站点
从部署的节点集合回收硬件不再需要的边缘站点。
先决条件
DCN 站点上的所有数据和工作负载都已迁移。
重要在完成此步骤后，未保存的数据和未迁移的工作负载将会丢失。
流程
删除您要删除的 DCN 站点的主机聚合，例如 "az2"：
从您的工作站访问 OpenStackClient pod 的远程 shell：
$ oc rsh -n openstack openstackclient可选：查看分配给主机聚合的 Compute 节点：
# openstack aggregate show <aggregate_name>要从主机聚合中删除分配的 Compute 节点，为每个 Compute 节点输入以下命令：
# openstack aggregate remove host <aggregate_name> \ <host_name>-
将
<aggregate_name> 替换为与要删除的 DCN 站点对应的聚合，如 "az2"。 -
将
<host_name> 替换为要删除的聚合中的每个主机。
-
将
删除聚合：
openstack aggregate delete <aggregate_name>-
将
<aggregate_name> 替换为与要删除的 DCN 站点对应的聚合，如 "az2"。
-
将
退出 openstackclient pod:
$ exit
可选：删除单元：
- 在工作站上打开 OpenStackControlPlane CR 文件 openstack_control_plane.yaml。
从
cellTemplates中删除单元定义：cellTemplates: cell0: hasAPIAccess: true.. cellDatabaseAccount: nova-cell0 cellDatabaseInstance: openstack cellMessageBusInstance: rabbitmq cell1: hasAPIAccess: true cellDatabaseAccount: nova-cell1 cellDatabaseInstance: openstack-cell1 cellMessageBusInstance: rabbitmq-cell1 cell2: hasAPIAccess: true cellDatabaseAccount: nova-cell2 cellDatabaseInstance: openstack-cell2 cellMessageBusInstance: rabbitmq-cell2 - cell3: - hasAPIAccess: true - cellDatabaseAccount: nova-cell3 - cellDatabaseInstance: openstack-cell3 - cellMessageBusInstance: rabbitmq-cell3从 OpenStackControlPlane CR 中删除特定于单元的 RabbitMQ 定义：
spec: ... rabbitmq: templates: ... rabbitmq-<cellname>: ...从 'OpenStackControlPlane CR 文件中删除特定于单元的 Galera 定义：
spec: ... galera: templates: ... openstack-<cellname>: ...更新 control plane：
$ oc apply -f openstack_control_plane.yaml -n openstack
删除 DCN 站点的 Block storage (cinder) pod：
获取卷列表：
$ openstack volume service listExample
+------------------+--------------------------+------+---------+-------+----------------------------+ | Binary | Host | Zone | Status | State | Updated At | +------------------+--------------------------+------+---------+-------+----------------------------+ | cinder-scheduler | cinder-e479e-scheduler-0 | nova | enabled | down | 2024-11-10T16:29:40.000000 | | cinder-scheduler | cinder-scheduler-0 | nova | enabled | up | 2024-11-12T19:11:08.000000 | | cinder-volume | cinder-volume-az0-0@ceph | az0 | enabled | up | 2024-11-12T19:11:09.000000 | | cinder-backup | cinder-backup-0 | nova | enabled | up | 2024-11-12T19:11:08.000000 | | cinder-backup | cinder-backup-1 | nova | enabled | up | 2024-11-12T19:11:13.000000 | | cinder-backup | cinder-backup-2 | nova | enabled | up | 2024-11-12T19:11:16.000000 | | cinder-volume | cinder-volume-az1-0@ceph | az1 | enabled | up | 2024-11-12T19:11:15.000000 | | cinder-volume | cinder-volume-az2-0@ceph | az2 | enabled | up | 2024-11-12T17:28:28.000000 | +------------------+--------------------------+------+---------+-------+----------------------------+禁用要删除的可用区(AZ)的块存储卷服务：
$ openstack volume service set \ --disable cinder-volume-az2-0@ceph cinder-volume验证块存储卷是否已禁用：
openstack volume service listExample
+------------------+--------------------------+------+----------+-------+----------------------------+ | Binary | Host | Zone | Status | State | Updated At | +------------------+--------------------------+------+----------+-------+----------------------------+ | cinder-scheduler | cinder-e479e-scheduler-0 | nova | enabled | down | 2024-11-10T16:29:40.000000 | | cinder-scheduler | cinder-scheduler-0 | nova | enabled | up | 2024-11-12T19:23:38.000000 | | cinder-volume | cinder-volume-az0-0@ceph | az0 | enabled | up | 2024-11-12T19:23:29.000000 | | cinder-backup | cinder-backup-0 | nova | enabled | up | 2024-11-12T19:23:38.000000 | | cinder-backup | cinder-backup-1 | nova | enabled | up | 2024-11-12T19:23:33.000000 | | cinder-backup | cinder-backup-2 | nova | enabled | up | 2024-11-12T19:23:36.000000 | | cinder-volume | cinder-volume-az1-0@ceph | az1 | enabled | up | 2024-11-12T19:23:35.000000 | | cinder-volume | cinder-volume-az2-0@ceph | az2 | disabled | up | 2024-11-12T19:23:24.000000 | +------------------+--------------------------+------+----------+-------+----------------------------+打开 OpenStackControlPlane 清单文件
openstack_control_plane.yaml。删除要删除的站点的CinderVolumepod，如下例所示：cinderVolumes: az2: customServiceConfig: | [DEFAULT] enabled_backends = ceph glance_api_servers = https://glance-az2-internal.openstack.svc:9292 [ceph] volume_backend_name = ceph volume_driver = cinder.volume.drivers.rbd.RBDDriver rbd_ceph_conf = /etc/ceph/az2.conf rbd_user = openstack rbd_pool = volumes rbd_flatten_volume_from_snapshot = False rbd_secret_uuid = 795dcbca-e715-5ac3-9b7e-a3f5c64eb89f rbd_cluster_name = az2 backend_availability_zone = az2
为您要删除的 DCN 站点删除 cinder 卷服务：
打开 Cinder 调度程序 pod 的 shell：
oc rsh cinder-scheduler-0删除 cinder 卷服务：
cinder-manage service remove cinder-volume cinder-volume-az2-0@ceph退出 shell
$ exit
移除正在移除的站点的
GlanceAPIpod：在 openstack-control-plane.yaml 自定义资源(CR)文件中，删除 az2 字段及其下的所有字段：
glanceAPIs: az0: <...> az1: <...> az2: apiTimeout: 60 customServiceConfig: | [DEFAULT] enabled_import_methods = [web-download,copy-image,glance-direct] enabled_backends = az0:rbd,az2:rbd [glance_store] default_backend = az2 [az0] rbd_store_ceph_conf = /etc/ceph/az0.conf store_description = "az0 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True [az2] rbd_store_ceph_conf = /etc/ceph/az2.conf store_description = "az2 RBD backend" rbd_store_pool = images rbd_store_user = openstack rbd_thin_provisioning = True imageCache: cleanerScheduler: '*/30 * * * *' prunerScheduler: 1 0 * * * size: "" networkAttachments: - storage override: service: internal: metadata: annotations: metallb.universe.tf/address-pool: internalapi metallb.universe.tf/allow-shared-ip: internalapi metallb.universe.tf/loadBalancerIPs: 172.17.0.82 spec: type: LoadBalancer replicas: 1 resources: {} storage: {} tls: api: internal: {} public: {} type: edge重新应用 control plane：
oc apply -f openstack-control-plane.yaml确保 Image 服务(glance) pod 已被删除：
$ oc get pods | grep glance | grep -v purgeExample
glance-e479e-az0-external-api-0 3/3 Running 0 2d glance-e479e-az0-external-api-1 3/3 Running 0 2d glance-e479e-az0-external-api-2 3/3 Running 0 2d glance-e479e-az0-internal-api-0 3/3 Running 0 2d glance-e479e-az0-internal-api-1 3/3 Running 0 2d glance-e479e-az0-internal-api-2 3/3 Running 0 2d glance-e479e-az1-edge-api-0注意glance-e4793-az2-edge-api-0不会出现在此列表中。确保 az2 pod 已被删除：
$ oc get pods | grep cinder-volumeExample
cinder-volume-az0-0 2/2 Running 0 2d cinder-volume-az1-0 2/2 Running 0 2d
从 DCN 站点中删除 Ceph 集群：
关闭 Ceph 集群，但不要关闭主机。有关更多信息，请参阅" 使用 Ceph 编排器关闭并重启集群 "。
注意主机必须保持开机，才能完成以下步骤。
删除用于访问已删除 Ceph 集群的 secret：
$ oc delete secret ceph-conf-az-2 -n openstack为中央站点重新创建 secret，使其不包含 az2 上 ceph 集群的 secret。例如，如果您有三个可用区
az0、az1和az2，并且您要删除与az2对应的边缘位置，请运行以下命令：oc delete secret cent-conf-az-0 -n openstack oc create secret generic ceph-conf-az-0 \ --from-file=az0.client.openstack.keyring \ --from-file=az-.conf \ --from-file=az1.client.openstack.keyring \ --from-file=az1.conf -n openstack编辑 OpenStackControlPlane 中的
extraMounts，以删除对正在移除的 AZ 的引用，以及移除的 secret。例如，对于 AZ2，删除 follosing list 元素：- propagation: - az2 extraVolType: Ceph volumes: - name: ceph secret: name: ceph-conf-az-2
-
删除节点集。要删除与
az2可用区对应的节点集，请完成 删除 OpenStackDataPlaneNodeSet 资源 中的步骤。
第 7 章 删除 DCN 节点
如果不再需要，您可以从 DCN 站点中删除节点，允许您重新使用硬件。
- 从主机迁移所有实例。如需更多信息，请参阅 冷迁移实例。
- 从其主机聚合中移除计算节点。有关更多信息 ，请参阅从主机聚合中删除计算节点。
- 如果您正在运行 HCI，则必须从 Ceph 集群中删除主机。有关更多信息 ，请参阅使用 Ceph 编排器删除主机。
- 从数据平面中删除 Compute 节点。如需更多信息 ，请参阅从数据平面中删除计算节点。
7.1. 冷迁移实例
冷迁移实例涉及停止实例并将其移动到另一个 Compute 节点。冷迁移有助于实时迁移无法促进的迁移方案，如迁移使用 PCI 直通的实例。调度程序自动选择目标 Compute 节点。如需更多信息，请参阅 迁移限制。
流程
从您的工作站访问
OpenStackClientpod 的远程 shell：$ oc rsh -n openstack openstackclient要冷迁移实例，请输入以下命令关闭并移动实例：
$ openstack server migrate <instance> --wait-
将
<instance> 替换为要迁移的实例的名称或 ID。 -
如果迁移本地存储的卷，则指定
--block-migration标记。 -
指定
--wait标志，以指示您必须等待迁移完成。
-
将
- 等待实例迁移完成后，您可以打开另一个终端窗口并检查迁移状态。如需更多信息，请参阅 检查迁移状态。
检查实例的状态：
$ openstack server list --all-projects"VERIFY_RESIZE"状态表示您需要确认或恢复迁移：
如果迁移按预期工作，请确认它：
$ openstack server resize --confirm <instance>将
<instance> 替换为要迁移的实例的名称或 ID。"ACTIVE"状态表示实例已就绪。如果迁移无法正常工作，请恢复它：
$ openstack server resize --revert <instance>将
<instance> 替换为实例的名称或 ID。
重启实例：
$ openstack server start <instance>将
<instance> 替换为实例的名称或 ID。可选：如果您为维护禁用了源 Compute 节点，您必须重新启用该节点，以便可以把新实例分配给该节点：
$ openstack compute service set <source> nova-compute --enable将
<source> 替换为源 Compute 节点的主机名。退出
OpenStackClientpod：$ exit
7.2. 从主机聚合中删除计算节点
您可以使用 OpenStackClient pod 从主机聚合中删除计算节点。
流程
从您的工作站访问 OpenStackClient pod 的远程 shell：
$ oc rsh -n openstack openstackclient查看分配给主机聚合的所有 Compute 节点列表：
# openstack aggregate show <aggregate_name>要从主机聚合中删除分配的 Compute 节点，请输入以下命令：
# openstack aggregate remove host <aggregate_name> <host_name>-
将
<aggregate_name> 替换为主机聚合的名称，以便从中删除 Compute 节点。 -
将
<host_name> 替换为要从主机聚合中删除的 Compute 节点的名称。
-
将
7.3. 使用 Ceph Orchestrator 删除主机
在运行超融合基础架构(HCI)时，您可以从 DCN 集群中删除节点。
先决条件
- 您在 DCN 集群上运行 HCI
- 您有对所有节点的 Root 级别访问权限。
- 要删除的主机被添加到存储集群中。
- Cephadm 部署在要移除该服务的节点上。
流程
登录到 Cephadm shell：
[root@host01 ~]# cephadm shell获取主机详情：
[ceph: root@host01 /]# ceph orch host ls排空主机中的所有守护进程：
[ceph: root@host01 /]# ceph orch host drain <hostname>将 <hostname> 替换为您要删除的主机的名称。有关管理 Red Hat Ceph Storage 服务的更多信息，请参阅 Red Hat Ceph Storage 7 的 管理指南。
检查移除 OSD 的状态：
[ceph: root@host01 /]# ceph orch osd rm status当 OSD 上没有剩余的放置组(PG)时，该 OSD 会停用并从存储集群中移除。
检查所有守护进程是否已从存储集群中移除：
[ceph: root@host01 /]# ceph orch ps <hostname>-
将 <hostname> 替换为您要删除的主机的名称。
-
删除主机：
[ceph: root@host01 /]# ceph orch host rm <hostname>-
将 <hostname> 替换为您要删除的主机的名称。
-
7.4. 从数据平面中删除 Compute 节点
您可以从数据平面上的节点集合中删除 Compute 节点。如果从节点集合中删除所有节点，则还必须从 data plane 中删除节点集。
先决条件
-
以具有
cluster-admin权限的用户身份登录 RHOCP 集群。 - Compute 节点上的工作负载已迁移到其他 Compute 节点。
流程
访问
openstackclientpod 的远程 shell：$ oc rsh -n openstack openstackclient检索您要删除的 Compute 节点的 IP 地址：
$ openstack hypervisor list检索 Compute 节点列表，以识别您要删除的节点的名称和 UUID：
$ openstack compute service list禁用要删除的 Compute 节点上的
nova-compute服务：$ openstack compute service set <hostname> nova-compute --disable提示使用
--disable-reason选项添加有关为何要禁用该服务的简短说明。如果您打算重新部署 Compute 服务，这很有用。退出
OpenStackClientpod：$ exitSSH 到要删除的 Compute 节点，并停止
ovn和nova-compute容器：$ ssh -i <key_file_name> cloud-admin@<node_IP_address> [cloud-admin@<hostname> ~]$ sudo systemctl stop edpm_ovn_controller [cloud-admin@<hostname> ~]$ sudo systemctl stop edpm_ovn_metadata_agent [cloud-admin@<hostname> ~]$ sudo systemctl stop edpm_nova_compute-
将 <
key_file_name> 替换为您创建的 SSH 密钥对文件的名称和位置，以便 Ansible 管理 RHEL 节点。 -
将
<node_IP_address> 替换为在第 2 步中获取的 Compute 节点的 IP 地址。
-
将 <
删除管理
ovn和nova-compute容器的systemd单元文件，以防止在删除的节点重启时自动启动和注册代理：[cloud-admin@<hostname> ~]$ sudo rm -f /etc/systemd/system/edpm_ovn_controller [cloud-admin@<hostname> ~]$ sudo rm -f /etc/systemd/system/edpm_ovn_metadata_agent [cloud-admin@<hostname> ~]$ sudo rm -f /etc/systemd/system/edpm_nova_compute断开与 Compute 节点的连接：
$ exit访问
openstackclient的远程 shell：$ oc rsh -n openstack openstackclient删除要删除的 Compute 节点的网络代理：
$ openstack network agent list [--host <hostname>] $ openstack network agent delete <agent_id>删除要删除的 Compute 节点的
nova-compute服务：$ openstack compute service delete <node_uuid>-
将
<node_uuid> 替换为您要删除在第 3 步中检索的节点 UUID。
-
将
退出
OpenStackClientpod：$ exit从
OpenStackDataPlaneNodeSetCR 中删除节点：$ oc patch openstackdataplanenodeset/<node_set_name> --type json --patch '[{ "op": "remove", "path": "/spec/nodes/<node_name>" }]'-
将
<node_set_name> 替换为节点所属的OpenStackDataPlaneNodeSetCR 的名称。 -
将
<node_name> 替换为OpenStackDataPlaneNodeSetCR 的nodes部分中定义的节点名称。
-
将
在工作站上创建一个文件，以定义
OpenStackDataPlaneDeploymentCR，以便在移除 Compute 节点的情况下更新节点集：apiVersion: dataplane.openstack.org/v1beta1 kind: OpenStackDataPlaneDeployment metadata: name: <node_set_deployment_name>-
将
<node_set_deployment_name> 替换为OpenStackDataPlaneDeploymentCR 的名称。名称必须是唯一的，必须包含小写字母数字字符(hyphen)或.（句点），且必须以字母数字字符开头和结尾。
提示为定义文件和
OpenStackDataPlaneDeploymentCR 提供唯一和描述性名称，以指示修改的节点集的用途。-
将
添加从中删除节点的
OpenStackDataPlaneNodeSetCR：spec: nodeSets: - <nodeSet_name>指定
OpenStackDataPlaneDeploymentCR 应该仅在部署列出的节点集合时运行ssh-known-hosts服务：spec: servicesOverride: - ssh-known-hosts-
保存
OpenStackDataPlaneDeploymentCR 部署文件。 部署
ssh-known-hosts服务，以从剩余的节点上的已知主机列表中删除删除的节点：$ oc create -f openstack_data_plane_deploy.yaml -n openstack您可以在部署执行时查看 Ansible 日志：
$ oc get pod -l app=openstackansibleee -w $ oc logs -l app=openstackansibleee -f --max-log-requests 10如果
oc logs命令返回类似以下错误的错误，请提高--max-log-requests值：error: you are attempting to follow 19 log streams, but maximum allowed concurrency is 10, use --max-log-requests to increase the limit验证修改后的
OpenStackDataPlaneNodeSetCR 是否已部署：$ oc get openstackdataplanedeployment -n openstack NAME NODESETS STATUS MESSAGE openstack-data-plane ["openstack-data-plane"] True Setup Complete $ oc get openstackdataplanenodeset -n openstack NAME STATUS MESSAGE openstack-data-plane True NodeSet Ready有关返回状态的含义的信息，请参阅 在 OpenShift 上部署 Red Hat OpenStack Services 中的 Data plane 条件和状态。
如果状态表示 data plane 尚未部署，则对部署进行故障排除。如需更多信息，请参阅在 OpenShift 上部署 Red Hat OpenStack Services 中的对 data plane 创建和部署进行故障排除。
第 8 章 验证边缘存储
为确保部署中央和边缘站点正常工作，可测试 glance 多存储和实例创建。您可以使用 openstackclient pod 以 OpenStack 管理员身份测试命令。
您可以将镜像导入到可在本地文件系统中可用的 glance 中，或者在 web 服务器上可用。
始终将镜像副本存储在中央站点，即使没有在中央位置使用该镜像的实例。
8.1. 查看 DCN 环境中的镜像服务存储
在测试 glance multi-store 前，请确保镜像服务存储可用。
流程
使用
glance stores-info命令，检查可通过镜像服务提供的存储。在以下示例中，有三个存储可用： central、dcn1 和 dcn2。它们分别对应于中央位置和边缘站点中的 glance 存储：$ glance stores-info +----------+----------------------------------------------------------------------------------+ | Property | Value | +----------+----------------------------------------------------------------------------------+ | stores | [{"default": "true", "id": "az0", "description": "central rbd glance | | | store"}, {"id": "az1", "description": "z1 rbd glance store"}, | | | {"id": "az2", "description": "az2 rbd glance store"}] | +----------+----------------------------------------------------------------------------------+
8.2. 从本地文件导入
您必须首先将镜像上传到中央位置的存储，然后将镜像复制到远程站点。
确保您的镜像文件采用 RAW 格式。如果镜像不是 raw 格式，则必须在将镜像导入到镜像服务前转换它：
$ file cirros-0.5.1-x86_64-disk.img cirros-0.5.1-x86_64-disk.img: QEMU QCOW2 Image (v3), 117440512 bytes $ qemu-img convert -f qcow2 -O raw cirros-0.5.1-x86_64-disk.img cirros-0.5.1-x86_64-disk.raw将镜像导入到中央站点的默认后端：
openstack image create \ --disk-format raw --container-format bare \ --name cirros --file cirros-0.5.1-x86_64-disk.raw \ --store central
8.3. 从 Web 服务器导入镜像
如果镜像托管在 web 服务器上，您可以使用 GlanceImageImportPlugins 参数将镜像上传到多个存储中。
此流程假设默认 Image Conversion 插件已在镜像服务(glance)中启用。此功能自动将 QCOW2 文件格式转换为 RAW 镜像，它们是 Ceph RBD 的最佳选择。您可以通过运行 glance image-show ID | grep disk_format 来确认 glance 镜像采用 RAW 格式。
流程
使用
glance命令的image-create-via-import参数从 Web 服务器导入镜像。使用--stores参数。# glance image-create-via-import \ --disk-format qcow2 \ --container-format bare \ --name cirros \ --uri http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img \ --import-method web-download \ --stores az0,az1在本例中，qcow2 cirros 镜像从官方 Cirros 站点下载，由 glance 转换为 RAW，并导入到中央站点和边缘站点 1 （由-
stores参数指定）。注意或者，您可以将
---，将镜像上传到所有存储。stores替换为--all-stores True
8.4. 将镜像复制到新站点
您可以将现有镜像从中央位置复制到边缘站点，这可让您在新创建的位置访问之前创建的镜像。
将 glance 镜像的 UUID 用于复制操作：
ID=$(openstack image show cirros -c id -f value) glance image-import $ID --stores az1,az2 --import-method copy-image注意在本例中，--
stores选项指定将cirros镜像从中央站点(z0)复制到边缘站点az1和az2。或者，您可以使用--all-stores True选项，将镜像上传到目前没有该镜像的所有存储中。确认镜像的副本位于每个存储中。请注意，store 键是属性映射中的最后一个项，设置为
az0,az1,az2。$ openstack image show $ID | grep properties | properties | os_glance_failed_import=', os_glance_importing_to_stores=', os_hash_algo=sha512, os_hash_value=6b813aa46bb90b4da216a4d19376593fa3f4fc7e617f03a92b7fe11e9a3981cbe8f0959dbebe36225e5f53dc4492341a4863cac4ed1ee0909f3fc78ef9c3e869, os_hidden=False, stores=az0,az1 |
始终将镜像副本存储在中央站点中，即使该站点中没有使用它的虚拟机。
8.5. 确认边缘站点中的实例可以使用基于镜像的卷引导
您可以使用边缘站点的镜像来创建持久的根卷。
流程
识别要作为卷创建的镜像的 ID，并将该 ID 传递给
openstack volume create命令：IMG_ID=$(openstack image show cirros -c id -f value) openstack volume create --size 8 --availability-zone az1 pet-volume-az1 --image $IMG_ID确定新创建的卷的卷 ID，并将其传递给
openstack server create命令：VOL_ID=$(openstack volume show -f value -c id pet-volume-az1) openstack server create --flavor tiny --key-name az1-key --network az1-network --security-group basic --availability-zone az1 --volume $VOL_ID pet-server-az1您可以通过在
az1边缘站点的 ceph-mon 容器中运行 rbd 命令，以验证卷是否基于镜像，以列出 volumes 池。$ sudo cephadm shell -- rbd -p volumes ls -l NAME SIZE PARENT FMT PROT LOCK volume-28c6fc32-047b-4306-ad2d-de2be02716b7 8 GiB images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076@snap 2 excl $确认您可以创建实例的 root 卷的 cinder 快照。确保服务器停止停止以静止数据以创建干净的快照。使用-- force 选项，因为实例关闭时卷状态为
in-use。openstack server stop pet-server-az1 openstack volume snapshot create pet-volume-az1-snap --volume $VOL_ID --force openstack server start pet-server-az1列出
az1Ceph 集群上 volumes 池的内容，以显示新创建的快照。$ sudo cephadm shell -- rbd -p volumes ls -l NAME SIZE PARENT FMT PROT LOCK volume-28c6fc32-047b-4306-ad2d-de2be02716b7 8 GiB images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076@snap 2 excl volume-28c6fc32-047b-4306-ad2d-de2be02716b7@snapshot-a1ca8602-6819-45b4-a228-b4cd3e5adf60 8 GiB images/8083c7e7-32d8-4f7a-b1da-0ed7884f1076@snap 2 yes
8.6. 确认可以在站点之间创建和复制镜像快照
重新快照，并确认您可以使用 glance image-import 将其复制到中央位置。
验证您可以在
az1位置创建新镜像。确保服务器停止静止数据以创建清理快照：NOVA_ID=$(openstack server show pet-server-az1 -f value -c id) openstack server stop $NOVA_ID openstack server image create --name cirros-snapshot $NOVA_ID openstack server start $NOVA_ID将镜像从
az1边缘站点复制回中央位置，这是 glance 的默认后端：IMAGE_ID=$(openstack image show cirros-snapshot -f value -c id) glance image-import $IMAGE_ID --stores az0 --import-method copy-image
8.7. 在边缘站点测试备份和恢复
您可以在边缘站点可用区(AZ)和中央 AZ 中备份和恢复块存储服务(cinder)卷。cinder-backup 服务在中央 AZ 中运行，备份存储在中央 AZ 中。块存储服务不会在边缘站点存储备份，且不支持在边缘站点间直接备份和恢复操作。
先决条件
- 块存储备份服务部署在中央 AZ 中。如需更多信息 ，请参阅更新 control plane。
- Block Storage (cinder) REST API 微版本 3.51 或更高版本。
-
所有站点都使用常见的
openstackcephx 客户端名称。
流程
在第一个 DCN 站点中创建卷的备份：
$ openstack --os-volume-api-version 3.51 volume backup create \ --name <volume_backup> --availability-zone <az0> <edge_volume>-
将
<volume_backup> 替换为卷备份的名称。 -
将
<az0> 替换为托管cinder-backup服务的中央可用区的名称。 将 <
edge_volume> 替换为您要备份的卷的名称。注意如果您在 Ceph 密钥环时遇到问题，您可能需要重启
cinder-backup容器，以便主机中的密钥环从主机复制到容器。
-
将
将备份恢复到第二个 DCN 站点中的新卷：
$ openstack --os-volume-api-version 3.47 volume create \ --backup <volume_backup> --availability-zone <az_2> <new_volume>-
将 <
;az_2> 替换为您要恢复备份的可用区的名称。 -
将
<new_volume> 替换为新卷的名称。 -
将 <
;volume_backup> 替换为您在上一步中创建的卷备份的名称。
-
将 <
'%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}