Skip to content

Commit 5b46197

Browse files
openshift-merge-bot[bot]openshift-merge-bot[bot]
authored
Merge pull request #1210 from rheslop/dcn_docs
Dcn docs
2 parents 1695ea6 + 609ce16 commit 5b46197

9 files changed

Lines changed: 885 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
@@ -20,6 +20,8 @@ include::../assemblies/assembly_adopting-key-manager-service-with-hsm.adoc[level
2020

2121
include::../modules/proc_adopting-the-networking-service.adoc[leveloffset=+1]
2222

23+
include::../modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc[leveloffset=+1]
24+
2325
include::../modules/proc_adopting-the-object-storage-service.adoc[leveloffset=+1]
2426

2527
include::../assemblies/assembly_adopting-the-image-service.adoc[leveloffset=+1]

‎docs_user/assemblies/assembly_adopting-the-data-plane.adoc‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -24,6 +24,8 @@ include::../modules/proc_stopping-infrastructure-management-and-compute-services
2424

2525
include::../modules/proc_adopting-compute-services-to-the-data-plane.adoc[leveloffset=+1]
2626

27+
include::../modules/proc_configuring-dcn-data-plane-nodesets.adoc[leveloffset=+1]
28+
2729
include::../modules/proc_performing-a-fast-forward-upgrade-on-compute-services.adoc[leveloffset=+1]
2830

2931
include::../modules/proc_adopting-networker-services-to-the-data-plane.adoc[leveloffset=+1]

‎docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -24,12 +24,16 @@ include::../modules/con_adoption-guidelines.adoc[leveloffset=+1]
2424

2525
include::../modules/con_adoption-process-overview.adoc[leveloffset=+1]
2626

27+
include::../modules/con_dcn-adoption-overview.adoc[leveloffset=+1]
28+
2729
include::../modules/proc_installing-the-systemd-container-package-on-compute-hosts.adoc[leveloffset=+1]
2830

2931
include::../modules/con_identity-service-authentication.adoc[leveloffset=+1]
3032

3133
include::../assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc[leveloffset=+1]
3234

35+
include::../modules/con_adopting-spine-leaf-networks.adoc[leveloffset=+1]
36+
3337
include::../assemblies/assembly_storage-requirements.adoc[leveloffset=+1]
3438

3539
include::../assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc[leveloffset=+1]

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

Lines changed: 123 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
1+
:_mod-docs-content-type: CONCEPT
2+
[id="adopting-spine-leaf-networks_{context}"]
3+
4+
= Configuring spine-leaf networks for the {rhos_long_noacro} deployment
5+
6+
[role="_abstract"]
7+
When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, like a Distributed Compute Node (DCN) architecture, you must each L2 network segment with a separate IP subnet and create create routed provider networks. Traffic between sites is routed at L3 through spine routers or similar network infrastructure.
8+
9+
You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured.
10+
11+
[NOTE]
12+
====
13+
DHCP relay is not supported in adopted {rhos_long} environments with spine-leaf topologies. This affects bare-metal provisioning scenarios that use PXE boot.
14+
15+
If you need to provision bare-metal nodes at edge sites, use Redfish virtual media or similar BMC virtual media features instead of PXE boot.
16+
====
17+
18+
.Example routes required on DCN1 Compute nodes
19+
[options="header"]
20+
|===
21+
| Destination network | Next hop | Purpose
22+
| 172.17.0.0/24 | 172.17.10.1 | Route to central internalapi
23+
| 172.17.20.0/24 | 172.17.10.1 | Route to DCN2 internalapi
24+
| 172.18.0.0/24 | 172.18.10.1 | Route to central storage
25+
| 172.18.20.0/24 | 172.18.10.1 | Route to DCN2 storage
26+
|===
27+
28+
You configure these routes in the `edpm_network_config_template` within the `OpenStackDataPlaneNodeSet` custom resource (CR) for each site.
29+
30+
.Example network topology for a three-site DCN deployment
31+
[options="header"]
32+
|===
33+
| Network | Central site | DCN1 site | DCN2 site
34+
| Control plane | 192.168.122.0/24 | 192.168.133.0/24 | 192.168.144.0/24
35+
| Internal API | 172.17.0.0/24 | 172.17.10.0/24 | 172.17.20.0/24
36+
| Storage | 172.18.0.0/24 | 172.18.10.0/24 | 172.18.20.0/24
37+
| Tenant | 172.19.0.0/24 | 172.19.10.0/24 | 172.19.20.0/24
38+
|===
39+
40+
When you adopt a spine-leaf deployment, you configure the `NetConfig` CR with multiple subnets for each service network. Each subnet represents a different site.
41+
42+
.Example NetConfig with multiple subnets per network
43+
[source,yaml]
44+
----
45+
apiVersion: network.openstack.org/v1beta1
46+
kind: NetConfig
47+
metadata:
48+
name: netconfig
49+
spec:
50+
networks:
51+
- name: ctlplane
52+
dnsDomain: ctlplane.example.com
53+
subnets:
54+
- name: subnet1 # Central site
55+
allocationRanges:
56+
- end: 192.168.122.120
57+
start: 192.168.122.100
58+
cidr: 192.168.122.0/24
59+
gateway: 192.168.122.1
60+
- name: ctlplanedcn1 # DCN1 site
61+
allocationRanges:
62+
- end: 192.168.133.120
63+
start: 192.168.133.100
64+
cidr: 192.168.133.0/24
65+
gateway: 192.168.133.1
66+
- name: ctlplanedcn2 # DCN2 site
67+
allocationRanges:
68+
- end: 192.168.144.120
69+
start: 192.168.144.100
70+
cidr: 192.168.144.0/24
71+
gateway: 192.168.144.1
72+
- name: internalapi
73+
dnsDomain: internalapi.example.com
74+
subnets:
75+
- name: subnet1 # Central site
76+
allocationRanges:
77+
- end: 172.17.0.250
78+
start: 172.17.0.100
79+
cidr: 172.17.0.0/24
80+
vlan: 20
81+
- name: internalapidcn1 # DCN1 site
82+
allocationRanges:
83+
- end: 172.17.10.250
84+
start: 172.17.10.100
85+
cidr: 172.17.10.0/24
86+
vlan: 30
87+
- name: internalapidcn2 # DCN2 site
88+
allocationRanges:
89+
- end: 172.17.20.250
90+
start: 172.17.20.100
91+
cidr: 172.17.20.0/24
92+
vlan: 40
93+
----
94+
95+
* Each network defines multiple subnets, one for each site.
96+
* Each site uses unique VLAN IDs. In this example, central uses VLANs 20-23, DCN1 uses VLANs 30-33, and DCN2 uses VLANs 40-43.
97+
* The subnet naming convention typically uses `subnet1` for the central site and site-specific names like `internalapidcn1` for edge sites.
98+
99+
Because the sites are geopgraphically distributed, each site requires its own provider network (physnet). The {networking_first_ref} must be configured to recognize all physnets.
100+
101+
.Example Neutron ML2 configuration for multiple physnets
102+
[source,yaml]
103+
----
104+
[ml2_type_vlan]
105+
network_vlan_ranges = leaf0:1:1000,leaf1:1:1000,leaf2:1:1000
106+
107+
[neutron]
108+
physnets = leaf0,leaf1,leaf2
109+
----
110+
111+
* `leaf0` corresponds to the central site.
112+
* `leaf1` corresponds to the DCN1 site.
113+
* `leaf2` corresponds to the DCN2 site.
114+
115+
When you create routed provider networks in {rhos_acro}, you create network segments that map to these physnets:
116+
117+
* Segment for central: `physnet=leaf0`, subnet=192.168.122.0/24
118+
* Segment for DCN1: `physnet=leaf1`, subnet=192.168.133.0/24
119+
* Segment for DCN2: `physnet=leaf2`, subnet=192.168.144.0/24
120+
121+
[role="_additional-resources"]
122+
.Additional resources
123+
* xref:configuring-control-plane-networking-for-spine-leaf_troubleshooting-hsm[Configuring control plane networking for spine-leaf topologies]

‎docs_user/modules/con_adoption-limitations.adoc‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ Unsupported features::
2929
+
3030
The adoption process does not support the following features:
3131
+
32-
* Distributed Compute node architecture (DCN)
32+
* Distributed Compute Node (DCN) architecture with storage services at remote or edge sites
3333
* DNS-as-a-service (designate)
3434
* {loadbalancer_first_ref}
3535
* Adopting Border Gateway Protocol (BGP) environments to the {rhos_acro} data plane

‎docs_user/modules/con_dcn-adoption-overview.adoc‎

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
:_mod-docs-content-type: CONCEPT
2+
[id="dcn-adoption-overview_{context}"]
3+
4+
= Overview of Distributed Compute Node adoption
5+
6+
[role="_abstract"]
7+
The process to adopt Distributed Compute Node (DCN) deployment from {rhos_prev_long} ({OpenStackShort}) to {rhos_long} requires additional adoption tasks:
8+
9+
* You must map a multi-stack deployment to multiple node sets.
10+
* You must map additional networking configurations.
11+
12+
Multi-stack to multi-node set mapping:: In {OpenStackPreviousInstaller} deployments, DCN environments use multiple Heat stacks:
13+
+
14+
** The Central stack is templating for Controllers and central Compute nodes.
15+
** An edge stack is templating for Edge Compute nodes in a stack. There is one stack per DCN site.
16+
+
17+
When you perform an adoption, map {OpenStackPreviousInstaller} stacks to `OpenStackDataPlaneNodeSet` custom resources (CRs):
18+
+
19+
.Mapping {OpenStackPreviousInstaller} stacks to {rhos_acro} nodesets
20+
[options="header"]
21+
|===
22+
| {OpenStackPreviousInstaller} stack | {rhos_acro} nodeset | Availability zone
23+
| Central stack (Compute role) | `openstack-edpm` or `openstack-cell1` | az-central
24+
| DCN1 stack (ComputeDcn1 role) | `openstack-edpm-dcn1` or `openstack-cell1-dcn1` | az-dcn1
25+
| DCN2 stack (ComputeDcn2 role) | `openstack-edpm-dcn2` or `openstack-cell1-dcn2` | az-dcn2
26+
|===
27+
+
28+
[NOTE]
29+
====
30+
Keep all node sets in the same Nova cell to maintain unified scheduling through a shared cell. The default cell is `cell1`.
31+
====
32+
33+
Key differences from standard adoption:: The following table summarizes the differences between standard adoption and DCN adoption:
34+
+
35+
.Comparison of standard and DCN adoption
36+
[options="header"]
37+
|===
38+
| Aspect | Standard adoption | DCN adoption
39+
| Director stacks | Single stack | Multiple stacks (central + edge sites)
40+
| Network topology | Flat L2 networks | Routed L3 networks with multiple subnets
41+
| Data plane node sets | Single node set | Multiple node sets (one per site minimum)
42+
| Network routes | Usually not required | Required for inter-site connectivity
43+
| Physnets | Single physnet (e.g., `datacentre`) | Multiple physnets (e.g., `leaf0`, `leaf1`, `leaf2`)
44+
| Availability zones | Often single AZ | Multiple AZs (one per site)
45+
| OVN bridge mappings | Single mapping | Site-specific mappings
46+
| Provider networks | Single segment | Multi-segment routed provider networks
47+
|===
48+
49+
Requirements for DCN adoption:: Before adopting a DCN deployment, ensure you have:
50+
+
51+
** Network topology information for all sites (IP ranges, VLANs, gateways)
52+
** Inter-site routing configuration (routes between site subnets)
53+
** Mapping of {OpenStackPreviousInstaller} roles to availability zones
54+
** OVN bridge mapping configuration for each site
55+
56+
[IMPORTANT]
57+
====
58+
The adoption of the control plane must complete before adopting any data plane nodes. However, once the control plane is adopted, the edge site data plane adoptions can proceed in parallel with the central site data plane adoption.
59+
====
60+
61+
DCN Adoption workflow overview:: The adoption of a Distributed Compute Node (DCN) deployment from {rhos_prev_long} ({OpenStackShort}) to {rhos_long}
62+
+
63+
. **Control plane adoption**: Adopt all control plane services from the central {OpenStackPreviousInstaller} stack to the {rhos_acro} control plane. This is identical to standard adoption.
64+
. **Network configuration**: Configure multi-subnet `NetConfig` and `NetworkAttachmentDefinition` CRs to support all site networks.
65+
. **Data plane node set creation**: Create separate `OpenStackDataPlaneNodeSet` CRs for each site, each with site-specific network configurations:
66+
+
67+
** Network subnet references
68+
** OVN bridge mappings (physnets)
69+
** Inter-site routing configuration
70+
. **Data plane deployment**: Deploy all node sets. The edge site node sets can be deployed in parallel after the central site control plane is adopted.
71+
72+
73+
[role="_additional-resources"]
74+
.Additional resources
75+
* xref:adopting-spine-leaf-networks_planning[Configuring spine-leaf networks for the {rhos_long_noacro} deployment]

0 commit comments

Comments
 (0)