Skip to content

Commit 6ec039d

Browse files
Merge pull request #1316 from klgill/18.0-fr5-cherrypick
fixed broken links
2 parents a873d67 + 9b8f3b9 commit 6ec039d

6 files changed

Lines changed: 482 additions & 2 deletions

docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,8 @@ include::../modules/proc_adopting-the-compute-service.adoc[leveloffset=+1]
3434

3535
include::../modules/proc_adopting-the-block-storage-service.adoc[leveloffset=+1]
3636

37+
include::../modules/proc_adopting-block-storage-service-with-dcn-backend.adoc[leveloffset=+1]
38+
3739
include::../modules/proc_adopting-the-openstack-dashboard.adoc[leveloffset=+1]
3840

3941
include::../assemblies/assembly_adopting-the-shared-file-systems-service.adoc[leveloffset=+1]

docs_user/assemblies/assembly_adopting-the-image-service.adoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,8 @@ include::../modules/proc_adopting-image-service-with-nfs-backend.adoc[leveloffse
3131

3232
include::../modules/proc_adopting-image-service-with-ceph-backend.adoc[leveloffset=+1]
3333

34+
include::../modules/proc_adopting-image-service-with-dcn-backend.adoc[leveloffset=+1]
35+
3436
include::../modules/proc_verifying-the-image-service-adoption.adoc[leveloffset=+1]
3537

3638
ifdef::parent-context[:context: {parent-context}]

docs_user/modules/con_adopting-spine-leaf-networks.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -120,4 +120,4 @@ When you create routed provider networks in {rhos_acro}, you create network segm
120120

121121
[role="_additional-resources"]
122122
.Additional resources
123-
* xref:configuring-control-plane-networking-for-spine-leaf_troubleshooting-hsm[Configuring control plane networking for spine-leaf topologies]
123+
* xref:configuring-control-plane-networking-for-spine-leaf_hsm-integration[Configuring control plane networking for spine-leaf topologies]

docs_user/modules/con_dcn-adoption-overview.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -72,4 +72,4 @@ DCN Adoption workflow overview:: The adoption of a Distributed Compute Node (DCN
7272

7373
[role="_additional-resources"]
7474
.Additional resources
75-
* xref:adopting-spine-leaf-networks_planning[Configuring spine-leaf networks for the {rhos_long_noacro} deployment]
75+
* xref:adopting-spine-leaf-networks_configuring-network[Configuring spine-leaf networks for the {rhos_long_noacro} deployment]
Lines changed: 216 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,216 @@
1+
:_mod-docs-content-type: PROCEDURE
2+
[id="adopting-block-storage-service-with-dcn-backend_{context}"]
3+
4+
= Adopt the {block_storage} with multiple {Ceph} back ends (DCN)
5+
6+
[role="_abstract"]
7+
Adopt the {block_storage_first_ref} in a Distributed Compute Node (DCN) deployment where multiple {CephCluster} clusters provide storage at different sites. You can deploy multiple `CinderVolume` instances, one for each availability zone, with each volume service configured to use its local {Ceph} cluster.
8+
9+
During adoption, the {block_storage} volume services that ran on edge site Compute nodes are migrated to run on {rhocp_long} at the central site. Although the control path for API requests now traverses the WAN to reach the {block_storage} running on {rhocp_long}, the data path remains local. Volume data continues to be stored in the {Ceph} cluster at each edge site. When you create a volume or clone a volume from a snapshot, the operation occurs entirely within the local {Ceph} cluster. This preserves data locality.
10+
11+
.Prerequisites
12+
13+
* You have completed the previous adoption steps.
14+
* The per-site {Ceph} secrets (`ceph-conf-central`, `ceph-conf-dcn1`, `ceph-conf-dcn2`) exist and contain the configuration and keyrings for each site's {Ceph} cluster. For more information, see xref:configuring-a-ceph-backend_migrating-databases[Configuring a {Ceph} back end].
15+
* The `extraMounts` property of the `OpenStackControlPlane` custom resource (CR) is configured to mount the {Ceph} configuration to all {block_storage} instances.
16+
* You have stopped the {block_storage} on all DCN nodes. For more information, see xref:stopping-openstack-services_migrating-databases[Stopping {rhos_prev_long} services]. On edge sites, the {block_storage} volume service runs on Compute nodes with the service name `tripleo_cinder_volume.service`.
17+
18+
.Procedure
19+
20+
. Retrieve the `fsid` for each {Ceph} cluster in your DCN deployment. The `fsid` is used as the `rbd_secret_uuid` for libvirt integration:
21+
+
22+
----
23+
$ oc get secret ceph-conf-central -o json | jq -r '.data | to_entries[] | select(.key | endswith(".conf")) | "\(.key): \(.value | @base64d)"' | grep fsid
24+
----
25+
26+
. Create a patch file for the {block_storage} with multiple {Ceph} back ends. The following example shows a DCN deployment with a central site and two edge sites:
27+
+
28+
[subs="+quotes"]
29+
----
30+
$ cat << EOF > cinder_dcn_patch.yaml
31+
spec:
32+
cinder:
33+
enabled: true
34+
template:
35+
cinderAPI:
36+
customServiceConfig: |
37+
[DEFAULT]
38+
default_availability_zone = az-central
39+
cinderScheduler:
40+
replicas: 1
41+
cinderVolumes:
42+
central:
43+
networkAttachments:
44+
- storage
45+
replicas: 1
46+
customServiceConfig: |
47+
[DEFAULT]
48+
enabled_backends = central
49+
glance_api_servers = http://glance-central-internal.openstack.svc:9292
50+
[central]
51+
backend_host = hostgroup
52+
volume_backend_name = central
53+
volume_driver = cinder.volume.drivers.rbd.RBDDriver
54+
rbd_ceph_conf = /etc/ceph/central.conf
55+
rbd_user = openstack
56+
rbd_pool = volumes
57+
rbd_flatten_volume_from_snapshot = False
58+
report_discard_supported = True
59+
rbd_secret_uuid = *<central_fsid>*
60+
rbd_cluster_name = central
61+
backend_availability_zone = az-central
62+
dcn1:
63+
networkAttachments:
64+
- storage
65+
replicas: 1
66+
customServiceConfig: |
67+
[DEFAULT]
68+
enabled_backends = dcn1
69+
glance_api_servers = http://glance-dcn1-internal.openstack.svc:9292
70+
[dcn1]
71+
backend_host = hostgroup
72+
volume_backend_name = dcn1
73+
volume_driver = cinder.volume.drivers.rbd.RBDDriver
74+
rbd_ceph_conf = /etc/ceph/dcn1.conf
75+
rbd_user = openstack
76+
rbd_pool = volumes
77+
rbd_flatten_volume_from_snapshot = False
78+
report_discard_supported = True
79+
rbd_secret_uuid = *<dcn1_fsid>*
80+
rbd_cluster_name = dcn1
81+
backend_availability_zone = az-dcn1
82+
dcn2:
83+
networkAttachments:
84+
- storage
85+
replicas: 1
86+
customServiceConfig: |
87+
[DEFAULT]
88+
enabled_backends = dcn2
89+
glance_api_servers = http://glance-dcn2-internal.openstack.svc:9292
90+
[dcn2]
91+
backend_host = hostgroup
92+
volume_backend_name = dcn2
93+
volume_driver = cinder.volume.drivers.rbd.RBDDriver
94+
rbd_ceph_conf = /etc/ceph/dcn2.conf
95+
rbd_user = openstack
96+
rbd_pool = volumes
97+
rbd_flatten_volume_from_snapshot = False
98+
report_discard_supported = True
99+
rbd_secret_uuid = *<dcn2_fsid>*
100+
rbd_cluster_name = dcn2
101+
backend_availability_zone = az-dcn2
102+
EOF
103+
----
104+
+
105+
where:
106+
107+
`<central_fsid>`::
108+
Specifies the `fsid` of the central {Ceph} cluster, used as the libvirt secret UUID.
109+
110+
`<dcn1_fsid>`::
111+
Specifies the `fsid` of the DCN1 edge {Ceph} cluster.
112+
113+
`<dcn2_fsid>`::
114+
Specifies the `fsid` of the DCN2 edge {Ceph} cluster.
115+
116+
+
117+
[NOTE]
118+
====
119+
* You must configure each `CinderVolume` with the `backend_availability_zone` value that matches your {compute_service} availability zone for that site, because `cross_az_attach = False` is set in the {compute_service} configuration. If the names do not match, instances cannot attach volumes. Replace the examples (`az-central`, `az-dcn1`, `az-dcn2`) with the names used in your {rhos_prev_long} deployment.
120+
* Each `CinderVolume` points to its local {image_service} API endpoint through `glance_api_servers`. This ensures that volume creation from images uses the local {image_service} and {Ceph} cluster. The examples use `http://` for the {image_service} endpoints. If your {rhos_prev_long} deployment uses TLS for internal endpoints, use `https://` instead, and ensure that you have completed the TLS migration. For more information, see xref:migrating-tls-everywhere_configuring-network[Migrating TLS-e to the RHOSO deployment].
121+
* The `rbd_cluster_name` setting identifies which {Ceph} cluster configuration to use from the mounted secrets.
122+
* Adjust the number of edge sites and their names to match your DCN deployment.
123+
====
124+
125+
. Patch the `OpenStackControlPlane` CR to deploy the {block_storage} with multiple {Ceph} back ends:
126+
+
127+
----
128+
$ oc patch openstackcontrolplane openstack --type=merge --patch-file cinder_dcn_patch.yaml
129+
----
130+
131+
. Configure the {block_storage} backup service. In this example, the backup service runs at the central site and uses the central {Ceph} cluster. Add the `cinderBackups` section to your patch file and re-apply it:
132+
+
133+
[subs="+quotes"]
134+
----
135+
$ cat << EOF >> cinder_dcn_patch.yaml
136+
cinderBackups:
137+
central:
138+
networkAttachments:
139+
- storage
140+
replicas: 1
141+
customServiceConfig: |
142+
[DEFAULT]
143+
backup_driver=cinder.backup.drivers.ceph.CephBackupDriver
144+
backup_ceph_conf=/etc/ceph/central.conf
145+
backup_ceph_user=openstack
146+
backup_ceph_pool=backups
147+
storage_availability_zone=az-central
148+
EOF
149+
$ oc patch openstackcontrolplane openstack --type=merge --patch-file cinder_dcn_patch.yaml
150+
----
151+
+
152+
[NOTE]
153+
====
154+
Unlike a single-site {Ceph} deployment where the backup config references `/etc/ceph/ceph.conf`, in a DCN deployment the {Ceph} configuration files in the `ceph-conf-files` secret are named by cluster. Set `backup_ceph_conf` to the path of the {Ceph} configuration file for whichever cluster hosts your `backups` pool. In this example the file is named `central.conf`, so the path is `/etc/ceph/central.conf`. Using a path that does not match a file in the secret will cause the backup service to fail with a `conf_read_file` error.
155+
156+
Set `storage_availability_zone` to match the availability zone of the volumes you want to back up. The backup scheduler uses this to route backup requests to a service in the correct zone. If the backup service zone does not match the volume zone, backup creation fails with `Service not found for creating backup`.
157+
====
158+
159+
. Verify that the {block_storage} volume services are running for each availability zone:
160+
+
161+
----
162+
$ openstack volume service list --service cinder-volume
163+
164+
+------------------+---------------------+------------+---------+-------+----------------------------+
165+
| Binary | Host | Zone | Status | State | Updated At |
166+
+------------------+---------------------+------------+---------+-------+----------------------------+
167+
| cinder-volume | hostgroup@central | az-central | enabled | up | 2024-01-01T00:00:00.000000 |
168+
| cinder-volume | hostgroup@dcn1 | az-dcn1 | enabled | up | 2024-01-01T00:00:00.000000 |
169+
| cinder-volume | hostgroup@dcn2 | az-dcn2 | enabled | up | 2024-01-01T00:00:00.000000 |
170+
+------------------+---------------------+------------+---------+-------+----------------------------+
171+
----
172+
173+
. Verify that the {block_storage} backup service is running and in the correct availability zone:
174+
+
175+
----
176+
$ openstack volume service list --service cinder-backup
177+
178+
+---------------+-------------------------+------------+---------+-------+----------------------------+
179+
| Binary | Host | Zone | Status | State | Updated At |
180+
+---------------+-------------------------+------------+---------+-------+----------------------------+
181+
| cinder-backup | cinder-backup-central-0 | az-central | enabled | up | 2024-01-01T00:00:00.000000 |
182+
+---------------+-------------------------+------------+---------+-------+----------------------------+
183+
----
184+
185+
. Test the backup service by creating a volume, backing it up, and restoring the backup:
186+
+
187+
----
188+
$ openstack volume create --size 1 backup-test-vol
189+
190+
$ openstack volume backup create --name backup-test-backup backup-test-vol
191+
192+
$ openstack volume backup show backup-test-backup
193+
+-----------------------+--------------------------------------+
194+
| Field | Value |
195+
+-----------------------+--------------------------------------+
196+
| container | backups |
197+
| fail_reason | None |
198+
| name | backup-test-backup |
199+
| size | 1 |
200+
| status | available |
201+
+-----------------------+--------------------------------------+
202+
203+
$ openstack volume backup restore backup-test-backup backup-test-restore
204+
----
205+
+
206+
[NOTE]
207+
====
208+
Some versions of the {rhocp_long} client display a `cannot unpack non-iterable VolumeBackupsRestore object` error after the restore command. This is a known issue in the client, the restore operation might not have failed. Verify by checking the restored volume status directly.
209+
====
210+
+
211+
----
212+
$ openstack volume show backup-test-restore -c status -c availability_zone -c os-vol-host-attr:host -f value
213+
available
214+
az-central
215+
hostgroup@central#central
216+
----

0 commit comments

Comments
 (0)