.. _migrate-to-modular: Migrate a Unified Node Cluster to a Modular Cluster -------------------------------------------------------- .. _21.1|VOSS-837: .. _21.1|VOSS-837|EKB-8170: .. _21.1|VOSS-837|EKB-8171: .. index:: app;app remove-role .. index:: cluster;cluster primary role .. index:: drives;drives remove_logical .. index:: drives;drives remove_volume 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 an overview of this topology, see: :ref:`modular-deployment-topology`. * For details on *installing* with this topology, see the Installation Guide topics: .. raw:: html Multinode Modular Cluster with Application and Database Nodes .. raw:: latex Multinode Modular Cluster with Application and Database Nodes .. raw:: html Multinode Modular Cluster Hardware Specification .. raw:: latex Multinode Modular Cluster Hardware Specification .. raw:: html Modular Architecture Multinode Installation .. raw:: latex Modular Architecture Multinode Installation 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``. #. Shut down the system: a. From the primary database node: **cluster run notme system shutdown** b. 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: a. Log into VMWare GUI. b. 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: :ref:`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) a. 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. b. Remove the database drives and volumes. Use the following commands to check and carry out the tasks. See the output example: :ref:`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. a. Run **drive list** and confirm that LVM volume is shown as ``available``. Make note of VG size. b. Log into VMWare GUI. c. Look at disks attached to system, and specifically ones that are the size noted above. d. Remove that disk from the system. e. On the CLI, rerun **drive list** to confirm that LVM and VG are removed. .. _removing-database-drives-and-volumes: 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:~$