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
4: Install Cloud Proxy for vCD
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
root@mgmt-vcav [ /opt/vmware/share/vCAvForVCD/latest ]# ls -l total 815068 -rw-r--r-- 1 root vmware 382976 Feb 15 2018 vCloud_Availability_4vCD-support.vmdk -rw-r--r-- 1 root vmware 832709120 Feb 15 2018 vCloud_Availability_4vCD-system.vmdk -rw-r--r-- 1 root vmware 1935 Feb 15 2018 vCloud_Availability_4vCD_AddOn_OVF10.cert -rw-r--r-- 1 root vmware 260 Feb 15 2018 vCloud_Availability_4vCD_AddOn_OVF10.mf -rw-r--r-- 1 root vmware 17923 Feb 15 2018 vCloud_Availability_4vCD_AddOn_OVF10.ovf -rw-r--r-- 1 root vmware 1943 Feb 15 2018 vCloud_Availability_4vCD_Cloud_Service_OVF10.cert -rw-r--r-- 1 root vmware 268 Feb 15 2018 vCloud_Availability_4vCD_Cloud_Service_OVF10.mf -rw-r--r-- 1 root vmware 324743 Feb 15 2018 vCloud_Availability_4vCD_Cloud_Service_OVF10.ovf -rw-r--r-- 1 root vmware 1929 Feb 15 2018 vCloud_Availability_4vCD_OVF10.cert -rw-r--r-- 1 root vmware 254 Feb 15 2018 vCloud_Availability_4vCD_OVF10.mf -rw-r--r-- 1 root vmware 325475 Feb 15 2018 vCloud_Availability_4vCD_OVF10.ovf |
Before we kick the deployment, we need to define few variables as shown below:
|
1 2 3 4 5 6 7 8 9 10 11 |
root@mgmt-vcav [ ~ ]# echo 'vmware' > ~/.ssh/.root root@mgmt-vcav [ ~ ]# export SSO_USER=administrator@alex.lab root@mgmt-vcav [ ~ ]# export VSPHERE01_PLACEMENT_NETWORK=Mgmt-PG root@mgmt-vcav [ ~ ]# export VSPHERE01_PLACEMENT_DATASTORE=iSCSI-4 root@mgmt-vcav [ ~ ]# export VSPHERE01_ADDRESS=compute-vc01.alex.local root@mgmt-vcav [ ~ ]# export VSPHERE01_PLACEMENT_LOCATOR=Cloud-DC01/host/Compute-Cluster |
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.
|
1 2 3 4 5 6 7 8 9 10 11 |
# vcav hms create --vsphere-address=$VSPHERE01_ADDRESS --vsphere-user=$SSO_USER --vsphere-password-file=~/.ssh/.sso "--network=$VSPHERE01_PLACEMENT_NETWORK" "--vsphere-locator=$VSPHERE01_PLACEMENT_LOCATOR" --datastore=$VSPHERE01_PLACEMENT_DATASTORE --ntp=pool.ntp.org --root-password-file=~/.ssh/.root --vm-name=mgmt-vrms01 --vm-address=192.168.109.40 |
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
|
1 2 3 4 5 6 7 |
# vcav vsphere trust-ssh --vsphere-address=$VSPHERE01_ADDRESS --vsphere-user=$SSO_USER --vsphere-password-file=~/.ssh/.sso --root-password-file=~/.ssh/.root --vm-name=mgmt-vrms01 --vm-address=192.168.109.40 |
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 