vSphere Replication-Part 5: Replicating and Recovering VM’s using VR


In last post of this series we saw how to deploy vSphere Replication appliance. In this appliance we will see the basic configurations of the replication appliance and will replicate a VM from source site to DR site. Also we will see how to recover VM on target (DR) site when your primary site has gone down.

If you have missed earlier posts of this series then you can access the same by clicking on below links:

1:Introduction to vSphere Replication

2: Lab Setup

3: Preparing vCenter for Replication

4: Deploying vSphere Replication Appliance

Let’s jump into lab and see things into action.

1: Configure vSphere Replication Appliance

a: To start configuring vSphere Replication appliance, login to the VAMI console of the appliance. This is typically accessible over URL https://VRA_FQDN:5480

Login to appliance with user root and password set during deploying vSphere Replication appliance.

config-1

b: Review your Network configuration by clicking on Network tab.

config-2

c: To add/modify Network parameters, switch to Address tab and punch in the required info. In my example I have updated my search path of my domain  in the appliance settings. Click on save settings to save the changes made.

config-3

d: Now switch over to VR page and click on Configuration tab to do the necessary configuration.

By default vSphere replication appliance will use the embedded postgres database. If you dont want to chose the embedded database and have a SQL or Oracle database, you can choose the Manual Configuration option and configure your database settings.

First punch in the password of the SSO administrator. Verify the VRM host and VRM site name, this should reflect to vCenter FQDN where you want to register your replication appliance.

If you are running replication appliance in your production environment, then you might want to segregate the management traffic and the storage traffic (Network over which your files will be transferred over to your DR site when you choose a VM for the replication). You can punch in the IP address of the secondary network adapter which will carry your storage traffic.

Once you have entered all the information, click on Save and Restart Service. This is when integration between your replication appliance and your vCenter server happens. This might take a couple of minutes to complete

config-4

d: You will be presented with the SSL thumbprint of your vCenter Server. Click on Accept to complete the integration process.

config-5

Once your VR appliance is registered to your vcenter Server you will see a message in green that your configuration has been successfully saved.

config-6

e: If you are already login to your web-client then logout and login back. You will see the vSphere Replication plugin in home page of your vcenter Server.

config-7

Repeat the same steps for deploying and configuring vSphere Replication appliance on your target/DR site.

Once it’s done click on vSphere Replication plugin on your homepage to navigate to the vSphere Replication page. If both of your replication appliance is registered to different PSC then you have to add your DR site as target site by clicking on Configure button.

In my case, both of my vcenter Server is using same PSC, so I can see Replication appliance status as Enabled and OK in below screen without doing any additional configuration.

config-8

Replicating VM using vSphere Replication

At this point both our primary site and DR site is ready. The next task is replicating a VM from source site to the target site.

A: Navigate to VM and template view in vCenter server in your source site and select the VM which you want to replicate to the DR site. Right click on the VM and chose All vSphere Replication Actions > Configure replication

config-9

B:vSphere Replication can be used to replicate VM’s to the local DR site as well as to a cloud provider side such as vCloud Air . In our example we are going for a local DR site replication so I chose Replicate to a vCenter Server. Hit Next to continue.

config-10

C: Choose the target site where you want to replicate your VM. Make sure your target site should report as connected here. If it is showing as disconnected then fix the issue first else you will not be able to continue from here.

If your target site is showing as connected. hit Next to continue.

config-11

D: On replication server page, choose the replication appliance that will be handling the replication process. In a production environment, you may have multiple replication servers deployed, to handle all the VM replication traffic.  In most cases, leaving it on “auto-select” is best.

In my case I choose the destination site replication appliance. Hit Next to continue.

config-12

E: On Target location page, select the storage where the VM will reside post replication. Click on Edit button to configure the appropriate datastore for your replicated VM.

config-13

F: Make your selection and hit OK.

config-14

After your selection, your screen will look like as shown below. Hit Next to continue.

config-15

G: On Replication Options page, select the appropriate option of whether or not you want Guest OS to be quiesced on your VM when replication will be triggered.

Also you can choose Network Compression option to compress the data which will be replicated by the VR appliance. This a new feature that has been added to VR6 6 and to use this feature, you should have Esxi host v6 at both your primary and your target site.

Please check the compatibility matrix before using this option. In my lab I have my Esxi host and VR appliance at v6 at both sites, so I went ahead with this option.

config-16

H: This is probably the most important page for configuring the replication options for a VM.

The first setting is the RPO  setting and defines how often vSphere Replication replicates data from source site VM to target site VM. This can be a time range between 15 Minutes to 24 Hours. The RPO settings depends on a number of factor and to know more about it I would recommend reading this article by Jon Kohler.

The other option is Point in time instances. This setting allow for some snapshots to be maintained at the DR site for this VM at certain intervals.  The benefit being that if a guest is corrupted, we have multiple points in time to failover from in case the corruption already replicated across sites.

config-17

I: On ready to complete page review your settings and hit finish.

config-18

J: You will see a task “Configure a VM for replication” triggered in vCenter server.

config-19

K: You can verify the presence of your replicated VM by going into the target site vCenter and browsing the datastore where your VM is getting replicated.

config-20

L: You can monitor the status of the replication task by selecting the Monitor > vSphere Replication tab in vCenter Server on both source and target site. At the target site, replication statistics will be visible under Incoming Replication, and at the source site it will be visible under Outgoing Replications.

When replication is kicked off first time on a VM, it will be always a full sync task. Once a VM is replicated to DR site, only delta changes of source VM will be pushed to target site and this push depends on the RPO value you set earlier.

config-21

config-22

M: Once a VM is replicated completely on DR site, you will see the VM status as OK on both sites.

config-23

Recovering a VM at target site

When disaster happens in your source site, you can go to your DR site and recover your VM which is being replicated over there. To perform recovery of  a VM, login to vCenter Server of target site and select the replicated VM right click on it.

You will be presented with multiple options like Pause the replication, Stop the replication or perform a manual sync of the replicated VM to get the delta changes from source VM. If you want to move this VM to other VR appliance you can choose to do so (if you have more than one VR appliance deployed on target site)

We will choose Recovery option here.

config-24

On Recovery Options page you will see various settings. The first setting is:

Synchronize recent changes: This is only available if the primary site is up and running however this settings require source VM to be in powered off state.

Use latest available data:  This option can be used even if the source VM is up and running.

Point in time recovery: Since I did not choose to keep any snapshot of my VM in DR site so this option is not available for me. In production environment it is advisable to configure Point in time instances option while configuring replication on a VM, so that your DR site can have multiple snapshots on the replicated VM and  you can simply choose in the snapshot manager if we need to go back in time a little with our recovery.  This is a very useful feature if you are failing over due to corruption, and need to roll back before it occurred.

In my case my source site is up and the source VM is running, and that’s why Synchronize recent changes is bitching about that in Recovery option validation window.

config-25

The moment I switched to use latest available data, validation succeeded.

config-26

 

To use the synchronize option I had to shutdown my VM on the source site. Replication status changed to Not Active due to this.

config-27

This time I did not got any validation issues. Hit next to continue.

config-28

Select the destination where the VM will be recovered on target site. Hit Next to continue.

config-29

If you have more than one cluster at the DR site, choose the right cluster where the replicated VM will be registering itself.

config-30

On ready to complete page review your settings and hit finish to start recovering the VM at DR site. You can choose to power on the VM after recovery.

config-31

You will see the recovery task in vCenter server. Once the task is completed, the VM state will report as Recovered in vSphere Replication page bon DR site.

config-32

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

 

About Alex Hunt

Hi All I am Manish Kumar Jha aka Alex Hunt. I am currently working in VMware Software India Pvt Ltd as Operations System Engineer (vCloud Air Operations). I have around 5 Years of IT experience and have exposure on VMware vSphere, vCloud Director, RHEL and modern data center technologies like Cisco UCS and Cisco Nexus 1000v and NSX. If you find any post informational to you please press like and share it across social media and leave your comments if you want to discuss further on any post. Disclaimer: All the information on this website is published in good faith and for general information purpose only. I don’t make any warranties about the completeness, reliability and accuracy of this information. Any action you take upon the information you find on this blog is strictly at your own risk. The Views and opinions published on this blog are my own and not the opinions of my employer or any of the vendors of the product discussed.
This entry was posted in Vmware, vSphere Replication. Bookmark the permalink.

One Response to vSphere Replication-Part 5: Replicating and Recovering VM’s using VR

  1. Pingback: Disaster Recovery with vCloud Air | Virtual Reality

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s