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

  1. Lock the active controller.

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

  2. Change the class attribute to ‘none’ for the loopback interface.

    ~(keystone_admin)$ system host-if-modify controller-0 lo -c none

  3. 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

  4. 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

  1. 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.

  2. 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.

  3. 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

  1. If not already locked, lock the active controller.

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

    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

  2. Change the system mode to ‘duplex’.

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

  3. 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)$ system oam-modify oam_subnet=10.10.10.0/24 oam_gateway_ip=10.10.10.1 oam_floating_ip=10.10.10.12 oam_c0_ip=10.10.10.13 oam_c1_ip=10.10.10.14

  4. Unlock the controller.

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

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

  5. 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

  6. 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.