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.

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.
Shut down the system:
1. From the primary database node: cluster run notme system shutdown
2. Then system shutdown
Make a restore point as per the guidelines for the infrastructure on which the VOSS Automate platform is deployed.
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.
Power up the VMs.
Run app remove-role database on UN2, UN4 and UN6.
Run app remove-role application on UN1, UN3 and UN5.
Do not modify the web proxy nodes WP1, WP2.
Run cluster provision on UN1.
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
```
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.
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.
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.
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:~$

Migrate a Unified Node Cluster to a Modular Cluster

On this page

Migrate a Unified Node Cluster to a Modular Cluster#

Considerations and Prerequisites#

Steps#

Removing Database Drives and Volumes#