vCloud Availability for vCloud Director: Part 7-Deploy vSphere Replication Manager

By | 09/09/2018

In last post of this series we deployed RabbitMQ and integrated it with vCD.

In this post we will deploy and configure vSphere Replication Manager aka VRMS. But before we go ahead and kick the VRMS deployment, lets discuss in brief about what is the role of VRMS in a VCAV stack.

If you are not following along this series, then I recommend reading earlier posts of this series from below links:

1: vCloud Availability Introduction

2: vCloud Availability Architecture & Components

3: VCAV Deployment

4: Install Cloud Proxy for vCD

5: Deploy Cassandra Cluster

6: RabbitMQ Cluster Deployment and vCD Integration

vSphere Replication Manager manages and monitors the replication process from tenant VMs to the cloud provider environment. A vSphere Replication management service runs for each vCenter Server and tracks changes to VMs and infrastructure related to replication.

VRMS when deployed is integrated with the resource vCenter Server which is in turn is registered to vCloud Director and made available to tenants. You can deploy more than one VRMS server for HA and load balancing.

There are 2 ways to deploy VRMS:

1: Deploy an OVF template directly in your management vCenter.

2: Kick the VRMS deployment from VCAV appliance.

In this post we will be following second method.

The ovf templates for VRMS deployment are located in directory /opt/vmware/share/vCAvForVCD/latest on the VCAV appliance and we need not to download it separately.

Before we kick the deployment, we need to define few variables as shown below:

Note: Compute-vc01 is my resource vCenter server.

Now to kick the VRMS deployment, run the below command. Change NTP IP and VM Name as per your environment. 

And if you have not done any mistake in defining the variables, you should see the deployment kicking in


Configure trust between VCAV and VRMS.  

Connect to VCAV appliance and run below commands on VCAV appliance

If you see an OK message in return, it means VCAV will now start trusting the VRMS.

Before ending this post I want to discuss a gotcha with VRMS deployment. 

I deployed my VRMS appliance in resource vCenter instead of management vCenter and that’s why it got registered to vCenter easily. But ideally VRMS should be sitting at management stack, but if you deploy it there then VRMS will register as an extension to the instance of vSphere it is deployed to. This model is called in inventory deployment.

For in inventory deployments, the vSphere Replication Manager manages the replications to the vSphere instance it is deployed to.

So if you have deployed your VRMS in management stack, you need to unregister it from management vCenter by running command: vcav hms unregister-extension –vsphere-address=$VSPHERE01_ADDRESS –vsphere-user=$SSO_USER –vsphere-password-file=~/.ssh/.sso

So how to deal with this situation? 

Either you can deploy the VRMS appliance to a separate resource pool (that tenants are not using) in resource vCenter and then register it with the vCenter. This model is called out of inventory deployment.

Or you can deploy it in your management VC and later unregister the extension using the command discussed above.

And that’s it for this post. In next post of this series we will deploy vSphere Replication Cloud Service.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable :)