In this tutorial, you used the Metaswitch Rhino VM automation solution to create, deploy, and test a simple VM. As described in the Introduction section, upgrades and MDM are out of scope of this tutorial. This page only gives a high-level overview of how you deploy MDM, how you connect the VMs to MDM, and how you perform rolling upgrades.
Deploying and connecting to MDM
While VMs can optionally be deployed in a lab environment without the use of MDM, Metaswitch mandates the use of MDM in production environments. MDM is an essential component of the lifecycle management in the Metaswitch Rhino VM automation solution. VMs cannot be upgraded without MDM. For more details, see the Rhino VM Automation Overview.
|
Once a VM is deployed, its MDM connection cannot be reconfigured. Therefore, it is essential that you deploy MDM prior to deploying your application into your production environment. |
We recommend that you first familiarize yourself with the steps required to deploy MDM and configure your VMs to connect to MDM in your lab environment. Follow the instructions in the Install MDM section of the Custom VM Install Guide to install MDM and instructions in the MDM service group section of the guide to configure your VMs to connect to MDM.
Upgrading VMs
The Metaswitch Rhino VM automation solution supports upgrading VMs using rolling replacement. That is, one by one, a downlevel (that is to say old version VM) gets shut down, followed by an uplevel (that is to say new version VM) being deployed. The architecture is described in the VM life cycle management section of the Rhino VM Automation Overview document, while the process to do the upgrades is documented in the Custom VM Install Guide (Rolling upgrade of custom nodes).
If your application is stateful, this could cause in-progress calls or sessions to fail, as the node that was handling it could have been deleted. To minimise this risk, enable replication in the node-parameters.yaml file.
|
If your VMs are clustered, during the upgrade, the downlevel and uplevel Rhino nodes will be split into separate clusters. This means that if your application architecture depends on all VMs being in a single Rhino cluster, upgrades will not be hitless. |
Quiesce hooks
Before a downlevel VM is deleted, it goes through a quiesce process, which cleans up any state relating to a VM that would otherwise persist outside of said VM. For example, for a clustered VM, the quiesce process removes the VM from the Rhino cluster.
If your initconf hooks created any side effects that need to be cleaned up when said VM is deleted, outside of the VM it ran on, you must use Quiesce hooks to achieve this.
As an example, you could add an initconf hook that registers the VM with an external load balancer. That would need an accompanying quiesce hook that unregisters the VM from the load balancer.
