Migrate an AIO-SX to an AIO-DX Subcloud¶

About this task

You can migrate an AIO-SX subcloud to an AIO-DX subcloud without reinstallation. This operation involves updating the system mode, adding the OAM unit IP addresses of each controller, and installing the second controller.

Prerequisites

A distributed cloud system is setup with at least a system controller and an AIO-SX subcloud. The subcloud must be online and managed by dcmanager. Both the management network and cluster-host network need to be configured and cannot be on the loopback interface.

Reconfigure the Cluster-Host Interface¶

If the cluster-host interface is on the loopback interface, use the following procedure to reconfigure the cluster-host interface on to a physical interface.

Procedure

Lock the active controller.

~(keystone_admin)$ system host-lock controller-0

Change the class attribute to ‘none’ for the loopback interface.
```
~(keystone_admin)$ system host-if-modify controller-0 lo -c none
```

Delete the current cluster-host interface-network configuration

~(keystone_admin)$ IFNET_UUID=$(system interface-network-list controller-0 | awk '{if ($8 =="cluster-host") print $4;}')
~(keystone_admin)$ system interface-network-remove $IFNET_UUID

Assign the cluster-host network to the new interface. This example assumes the interface name is mgmt0.
```
~(keystone_admin)$ system interface-network-assign controller-0 mgmt0 cluster-host
```

Postrequisites

Continue with the AIO-SX to AIO-DX subcloud migration, using one of the following procedures:

Use Ansible Playbook to Migrate a Subcloud from AIO-SX to AIO-DX, or Manually Migrate a Subcloud from AIO-SX to AIO-DX.

Use Ansible Playbook to Migrate a Subcloud from AIO-SX to AIO-DX¶

Use the following procedure to migrate a subcloud from AIO-SX to AIO-DX using the ansible playbook.

Prerequisites

the subcloud must be online and managed from the System Controller
the subcloud’s controller-0 may be locked or unlocked; the ansible playbook will lock the subcloud controller-0 as part of migrating the subcloud

Procedure

Use the ansible-vault create migrate-subcloud1-overrides-EXAMPLE.yml command to securely specify the OAM unit IP addresses and the ansible ssh password. The existing OAM IP address of the AIO-SX system will be used as the OAM floating IP address of the new AIO-DX system.

In the following example, 10.10.10.13 and 10.10.10.14 are the new OAM unit IP addresses for controller-0 and controller-1 respectively.
```
{
 "ansible_ssh_pass": "St8rlingXCloud*",
 "external_oam_node_0_address": "10.10.10.13",
 "external_oam_node_1_address": "10.10.10.14",
 }
```
Use the ansible-vault edit migrate-subcloud1-overrides-EXAMPLE.yml command if the file needs to be edited after it is created.
On the system controller, run the ansible playbook to migrate the AIO-SX subcloud to an AIO-DX.

Note

Run the following command on an AIO-SX system before changing to AIO-DX, as this does not apply to AIO-DX systems.
```
~(keystone_admin)$ system storage-backend-modify ceph-store replication=2
```
For example, if the subcloud name is ‘subcloud1’, enter:
```
~(keystone_admin)$ ansible-playbook --ask-vault-pass /usr/share/ansible/stx-ansible/playbooks/migrate_sx_to_dx.yml -e @migrate-subcloud1-overrides-EXAMPLE.yml -i subcloud1, -v
```
The ansible playbook will lock the subcloud’s controller-0, if it not already locked, apply the configuration changes to convert the subcloud to an AIO-DX system with a single controller, and unlock controller-0. Wait for the controller to reset and come back up to an operational state.
Software install and configure the second controller for the subcloud.

From the System Controller, reconfigure the subcloud, using dcmanager. Specify the sysadmin password and the deployment configuration file, using the dcmanager subcloud deploy config command.
```
~(keystone_admin)$ dcmanager subcloud deploy config --sysadmin-password <sysadmin_password> --deploy-config deployment-config-subcloud1-duplex.yaml <subcloud1>
```
where <sysadmin_password> is assumed to be the login password and <subcloud1> is the name of the subcloud

Note

--deploy-config must reference a deployment configuration file for a AIO-DX subcloud.

For example, deployment-config-subcloud1-duplex.yaml should only include changes for controller-1 as changing fields for other nodes/ resources may cause them to go out of sync.

Manually Migrate a Subcloud from AIO-SX to AIO-DX¶

As an alternative to using the Ansible playbook, use the following procedure to manually migrate a subcloud from AIO-SX to AIO-DX. Perform the following commands on the AIO-SX subcloud.

Procedure

If not already locked, lock the active controller.

~(keystone_admin)$ system host-lock controller-0

Run the following command on an AIO-SX system before changing to AIO-DX:

For Ceph installation:

~(keystone_admin)$ system storage-backend-modify ceph-store replication=2

For Rook Container-based Ceph installation:

~(keystone_admin)$ system storage-backend-modify ceph-rook-store replication=2

Change the system mode to ‘duplex’.

~(keystone_admin)$ system modify --system_mode=duplex

Add the OAM unit IP addresses of controller-0 and controller-1.

For example, the OAM subnet is 10.10.10.0/24 and uses 10.10.10.13 and 10.10.10.14 for the unit IP addresses of controller-0 and controller-1 respectively. The existing OAM IP address of the AIO-SX system will be used as the OAM floating IP address of the new AIO-DX system.

Note

Only specifying oam_c0_ip and oam_c1_ip is necessary to configure the OAM unit IPs to transition to Duplex. However, oam_c0_ip and oam_c1_ip cannot equal the current or specified value for oam_floating_ip.
```
~(keystone_admin)$ OAM_POOL=$(system network-list --nowrap | awk '$8 == "oam" { print $12 }') && system addrpool-modify "${OAM_POOL}" --controller0-address 10.10.10.13 --controller1-address 10.10.10.14
```
If the OAM interface is dual-stack (IPv4 and IPv6), perform the same configuration on the secondary pool. To get the pool’s UUID, run the following command:
```
~(keystone_admin)$ system network-addrpool-list | grep "oam"
| e2052bfe-e17e-4a5c-888c-cf4c96593aa6 | oam    | oam-ipv6  |
| 7307b3e2-037a-44f3-a589-11aaa7ff4f11 | oam    | oam-ipv4  |
```
The primary pool name can be identified with:
```
~(keystone_admin)$ OAM_POOL=$(system network-list --nowrap | awk '$8 == "oam" { print $12 }') && system addrpool-show "${OAM_POOL}" | grep "name"
| name    | oam-ipv4  |
```
In the following example, you need to edit oam-ipv6:
```
~(keystone_admin)$ OAM_POOL=$(system addrpool-list --nowrap | awk '$4 == "oam-ipv6" { print $2 }') && system addrpool-modify "${OAM_POOL}" --controller0-address fd00::a14:104 --controller1-address fd00::a14:105
```
Unlock the controller.
```
~(keystone_admin)$ system host-unlock controller-0
```
Wait for the controller to reset and come back up to an operational state.

Config and enable IPsec on the controller.

~(keystone_admin)$ sudo ipsec-client pxecontroller

This is only needed on controller-0. The command should complete successfully as following:

~(keystone_admin)$ sudo ipsec-client pxecontroller

2024-08-07 20:43:28.622 182204 INFO sysinv.ipsec_auth.client.client [-] Connecting to pxecontroller port 64764
2024-08-07 20:43:28.630 182204 INFO sysinv.ipsec_auth.client.client [-] Sending IPSec Auth request
2024-08-07 20:43:36.521 182204 INFO sysinv.ipsec_auth.client.client [-] Received IPSec Auth response
2024-08-07 20:43:36.765 182204 INFO sysinv.ipsec_auth.client.client [-] Generate RSA Private Key (PRK2).
2024-08-07 20:43:37.029 182204 INFO sysinv.ipsec_auth.client.client [-] Generate AES Key (AK1).
2024-08-07 20:43:37.029 182204 INFO sysinv.ipsec_auth.client.client [-] Generate Certificate Signing Request (CSR).
2024-08-07 20:43:37.033 182204 INFO sysinv.ipsec_auth.client.client [-] Encrypt CSR w/ AK1.
2024-08-07 20:43:37.035 182204 INFO sysinv.ipsec_auth.client.client [-] Encrypt AK1 and IV w/ PUK1
2024-08-07 20:43:37.038 182204 INFO sysinv.ipsec_auth.client.client [-] Hash OTS Token, eAK1 and eCSR.
2024-08-07 20:43:37.041 182204 INFO sysinv.ipsec_auth.client.client [-] Sending IPSec Auth CSR request
2024-08-07 20:43:38.541 182204 INFO sysinv.ipsec_auth.client.client [-] Received IPSec Auth CSR response
2024-08-07 20:43:38.544 182204 INFO sysinv.ipsec_auth.client.client [-] Generating config files and restart ipsec
2024-08-07 20:43:53.141 182204 INFO sysinv.ipsec_auth.client.client [-] Shutting down

Software install and configure the second controller for the subcloud.

For instructions on installing and configuring controller-1 in an AIO-DX setup to continue with the migration, see StarlingX Installation.

Additional Steps for Ceph Installation¶

It is necessary to add OSDs for controller-1. Both controllers must have the same number of OSDs (and also the same disk specs) to work properly. When you migrate an AIO-SX subcloud to an AIO-DX subcloud with Ceph installations, follow the additional steps below:

List host’s disks and identify disks you want to use for Ceph OSDs. Ensure that you note the UUIDs.
```
~(keystone_admin)$ system host-disk-list controller-1
```

Add disk as an OSD storage.

~(keystone_admin)$ system host-stor-add controller-1 osd <disk-uuid>

List OSD storage devices.

~(keystone_admin)$ system host-stor-list controller-1

Additional Steps for Rook Container-based Ceph Installation¶

When you migrate an AIO-SX subcloud to an AIO-DX subcloud with Rook container-based Ceph installations, follow the additional steps below:

After configuring controller-1:

Add a new Ceph monitor on controller-1.

~(keystone_admin)$ system host-fs-add controller-1 ceph=<size>

Add an OSD on controller-1.

List host’s disks and identify disks you want to use for Ceph OSDs. Ensure you note the UUIDs.
```
~(keystone_admin)$ system host-disk-list controller-1
```

Add disk as an OSD storage.

~(keystone_admin)$ system host-stor-add controller-1 osd <disk-uuid>

List OSD storage devices.

~(keystone_admin)$ system host-stor-list controller-1

After unlocking controller-1:

Wait until Ceph has two active monitors. To verify, run ceph -s and ensure that the output shows mon: 2 daemons, quorum a,b. This confirms that both the local monitors are active.

~(keystone_admin)$ ceph -s
 cluster:
   id:     c55813c6-4ce5-470b-b9f5-e3c1fa0c35b1
   health: HEALTH_WARN
           insufficient standby MDS daemons available

 services:
   mon: 2 daemons, quorum a,b (age 2m)
   mgr: a(active, since 114s), standbys: b
   mds: 1/1 daemons up
   osd: 4 osds: 4 up (since 46s), 4 in (since 65s)

Add the floating monitor.

~(keystone_admin)$ system host-lock controller-1
~(keystone_admin)$ system controllerfs-add ceph-float=<size>
~(keystone_admin)$ system host-unlock controller-1

Wait for the controller to reset and come back up to an operational state.

Re-apply the rook-ceph application.

~(keystone_admin)$ system application-apply rook-ceph