Migrate a Unified Node Cluster to a Modular Cluster#

From release 21.1 onwards, a new Modular Architecture deployment is available.

Important

Since individual requirements and topologies differ, contact VOSS for guidance and assistance before migrating.

Note

  • A topology migration from a unified node cluster topology to a modular cluster is recommended under certain circumstances to improve the system behaviour at scale and under load.

  • Since the minimum number of nodes in a modular architecture is 8 (2 web proxy and 6 application/database), only a migration of a unified node deployment of 8 nodes is supported.

  • The migration to a modular architecture deployment is a one-way process. A migrated system cannot be migrated back to a unified node cluster topology.

  • The migration process requires a maintenance window to complete, since a VM power down is needed for the migration of some nodes.

  • For details on installing with this topology, see the Architecture and Hardware Specification Guide and Installation Guide:

Commands are available to migrate unified nodes from the unified node cluster topology. Since unified nodes combine database and application roles, the commands remove one of these roles. The commands are:

  • app remove-role db: remove the database role from a unified node, leaving the application role.

  • app remove-role app remove the application role from a unified node, leaving the database role.

Considerations and Prerequisites#

  • VOSS has been contacted and is assisting.

  • The migration requires a maintenance window.

  • The new topology should be decided, in other words, which nodes take the db and app roles in the database centers.

  • Backups before restarting:

    As part of the rollback procedure, ensure that a suitable restore point is obtained prior to the start of the activity, as per the guidelines for the infrastructure on which the VOSS Automate platform is deployed.

    Database backups from the Primary Unified node cannot be used to restore the database on the new primary database node after migration.

    Note

    If you need to roll back from the migration using the restore points, first revert all the cluster nodes to the correct restore point, then power the nodes on. Do not revert the restore point and power on each node in sequence.

  • Hardware impact:

    • Conversion from unified to app node - has disk space impact (db space unused and can be removed in the VM)

    • Conversion from unified to database node - unified node requirement on VM of 16GB RAM needs to be changed to 32GB RAM for database node.

  • Schedules:

    • system

    • admin created

    • application related: NBI

Steps#

The example and steps below shows a migration from a unified node cluster topology with 6 unified nodes in 2 data centers to modular topology with 3 database nodes and 3 application nodes:

Data Center 1

Unified Node Topology

Migration Command

Modular Topology

UN1

app remove-role application

db node (primary db)

UN2

app remove-role database

app node

UN3

app remove-role application

db node

UN4

app remove-role database

app node

WP1

N/A

WP1

Data Center 2 (Data Recovery site)

Unified Node Topology

Migration Command

Modular Topology

UN5

app remove-role application

db node

UN6

app remove-role database

app node

WP2

N/A

WP2

Before you start, verify that the nodes on which you run the migrate commands are unified nodes.

  1. Check the memory of the nodes that will have application roles removed (the nodes: UN1, UN3 and UN5) to identify those with memory less than 32GB.

    You can run diag mem on the nodes to verify this and add Mb used and Mb free.

  2. Shut down the system:

    1. From the primary database node: cluster run notme system shutdown

    2. Then system shutdown

  3. Make a restore point as per the guidelines for the infrastructure on which the VOSS Automate platform is deployed.

  4. For the VMs of unified nodes that:

    • will become db nodes and

    • have less than 32GB memory (from the nodes: UN1, UN3 and UN5),

    resize the VM memory to 32GB as follows:

    1. Log into VMWare GUI.

    2. Adjust the Memory assigned to the system to 32GB.

  5. Power up the VMs.

  6. Run app remove-role database on UN2, UN4 and UN6.

  7. Run app remove-role application on UN1, UN3 and UN5.

  8. Do not modify the web proxy nodes WP1, WP2.

  9. Run cluster provision on UN1.

  10. Run cluster status to ensure the cluster roles are as expected.

    Note

    When the deployment is migrated to a modular system, the cluster provision command will run a check to verify that all nodes have been migrated, in other words, that no “hybrid” system is present.

    An error message is displayed otherwise:

    Cluster provisioning not allowed on cluster with mixed unified and db or app nodes

  11. Run database config on the first new database node and ensure the database nodes are in the correct state. In this example it would be UN1.

  12. Verify the primary application node (UN2) with the cluster primary role application command run on the node. The output should be true, for example:

    platform@UN2:~$ cluster primary role application
is_primary: true

    See: Commands to Determine the Primary Node Role in a Cluster.

  13. For the new application nodes (nodes where the database role has been removed, in other words UN2, UN4 and UN6)

    1. Check the number of queues using voss queues and if the number is less than 2, set the queues to 2 with voss queues 2.

      Note

      Applications are reconfigured and the voss-queue process is restarted.

    2. Remove the database drives and volumes. Use the following commands to check and carry out the tasks. See the output example: Removing Database Drives and Volumes.

      • drives list

      • drives remove_logical voss dbroot

      • drives remove_volume voss

      Important

      Ensure the nodes are application nodes: you can run app status and verify no mongodb service is running on them.

  14. You can remove disks from VMs of nodes with application roles (UN2, UN4 and UN6).

    Important

    Ensure the nodes you remove VM disks are application nodes: run app status and verify no mongodb service is running on them.

    If disks are hot-mounted, a system restart may be needed.

    1. Run drive list and confirm that LVM volume is shown as available. Make note of VG size.

    2. Log into VMWare GUI.

    3. Look at disks attached to system, and specifically ones that are the size noted above.

    4. Remove that disk from the system.

    5. On the CLI, rerun drive list to confirm that LVM and VG are removed.

Removing Database Drives and Volumes#

Example of commands and output when removing database drives and volumes.

platform@UN2:~$ drives list
Used disks and mountpoints:
    sdc1 -  services:backups

Unused disks:
dm-0

Unused mountpoints:
    services:SWAPSPACE

Volume Groups
    voss - 25.0 GB free, 250.0 GB total
      Physical volumes:
        sdd1
      Logical volumes:
        dbroot/dm-0 - 225.0 GB
platform@UN2:~$

platform@UN2:~$ drives remove_logical voss dbroot
Logical volume dbroot has been removed from voss
platform@UN2:~$ drives list
Used disks and mountpoints:
    sdc1 -  services:backups

Unused disks:
    none - if disks have been hot-mounted, it may be necessary to reboot the system

Unused mountpoints:
    services:SWAPSPACE

Volume Groups
    voss - 250.0 GB free, 250.0 GB total
      Physical volumes:
        sdd1
      Logical volumes:
platform@UN2:~$

platform@UN2:~$ drives remove_volume voss
Volume group voss has been removed
platform@UN2:~$ drives list
Used disks and mountpoints:
    sdc1 -  services:backups

Unused disks:
sdd

Unused mountpoints:
    services:SWAPSPACE

platform@UN2:~$