Deploying and Configuring VMware vSphere Replication Appliance 6.0

For most companies backups are not enough, because in case of a disaster they need to be online as fast as possible in order to serve clients and not loose revenue; so they built secondary datacenters for disaster recovery and bought expensive storage to manage and replicate VMs from the main site (production site) to the other site, also called disaster recovery site. This is working great for them since they have the budget for that expensive storage hardware, but small companies are left with no options. Even so, replicating at the storage layer requires dedicated LUNs for the VMs that need to be replicated because this will copy the entire LUN to the disaster recovery site. Since this was a real issue, VMware had to think of a solution, and starting with vSphere 5.1 they introduced the vSphere Replication Appliance which is an asynchronous replication of the VMs using ESXi as the main engine for moving data.

VMware vSphere Replication allows the replication of individual VMs on any datastore (local, FC, iSCSI,or NFS) to any other datastore at the disaster recovery site or local site for that matter. This is one of the main advantages that vSphere Replication (VR) offers, by being a storage protocol neutral and storage vendor neutral, and because of this, it’s a technology that is attractive to customers on many levels. As long as you’re using storage supported by VMware’s general HCL everything will work fine. Small businesses will be tempted by it because it removes the requirement for matching storage arrays at both sites, and enterprises will want to use it because it is sometimes difficult to resolve array firmware compatibility requirements. The product will be most attractive to organizations that offer disaster recovery services since most of the time they do not share a common storage array to get the replication going.

As you can see, VMware has achieved with vSphere Replication to remove some of the hardware and firmware compatibility limitations that often caused a lot of problems into their implementations. As for the price, the product is free, but it’s only included with VMware vSphere Essentials Plus Kit and higher editions of VMware vSphere.

Now, the first virtual appliance that we are going to deploy is called the vSphere Replication Management server (VRMS) which handles integration with the vCenter server, authentication, replicates data and keeps a database of what VMs need to be replicated to the disaster recovery site. This is mandatory to have at both locations, main site and disaster recovery site. For most of the times deploying this one appliance is enough, but for large environments additional vSphere Replication server appliances will need to be deployed in order to balance the load. A vSphere Replication server will not do the management stuff that VRMS does, it only helps balance the VMs replication load.

Until now I’ve been telling you all the goods about vSphere Replication, but as every software, the product also has some limitations:

• ISOs and physical RDMs cannot be replicated. In my opinion this is not necessarily a limitation, because it will be crazy to copy over the WAN link an ISO that was forgotten attached to a VM.
• The snapshot hierarchy is not replicated. Since is not recommended to have snapshots in a production environment I guess this works for most environments.
• FT-protected VM templates and linked clones are not supported.
• There is no automated failback of VMs. This has to be done manually.
• Powered-off VMs are not replicated by vSphere Replication. They can be protected tough.

Deploying the vSphere Replication Management Appliance (VRMA)

Before moving to the actual deployment and configuration of VMware vSphere Replication, I trust you already have your site-to-site VPN connection running and the required ports for replication opened in firewall. Also the necessary A and PTR records need to be created in your DNS zone for the vSphere Replication Management Appliances.

The requirement is to have one vSphere Replication management appliance per vCenter, and now that we have everything in place let’s start by deploying the first VRMA in the main site, or protected site if you wish to call it so.

Right-click the cluster or ESXi host where you want to deploy the VRMA and choose Deploy OVF Template.

Select the Local file radio button then click Browse. Locate the .OVF file (the one without the AddOn word in the name) in the bin folder that you downloaded from the VMware’s site then click Next to continue the wizard.

                  

Review the virtual appliance details and click Next.

Accept the EULA and continue the wizard.

Here, name the appliance and choose a folder or a datacenter where to deploy it then click Next.

Select the number of CPUs to assign to the appliance based on the load it will have. By default the appliance is configured with four CPUs, and this what we are going to use for this lab also. Click Next.

Select the disk format type for the appliance virtual disks then select the datastore or datastore cluster where to put these virtual disks. In a production environment I recommend you go for Thin Provisioned Eager Zeroed disk type since it provides better performance and only use Thin Provision in a lab environment, like we are right now. Click Next when you are done with your selections.

Since most of the management applications are recommended to be set up with a static IP address, VRMA is no different. Select a port group from the Destination drop-down box then from the IP address one, choose Static – Manual. In the bellow boxes type in your network address information then continue the wizard. Make sure that trough the port group you select here the appliance can communicate with your vCenter server, or the deployment will fail.

For some reason VMware decided to make a separate wizard screen for the IP address of the appliance; so in the Management Network IP Address box, type in the IP address for the appliance. Also, we need to provide a password and an NTP server. The NTP server is very important because the appliance needs to be in sync with your ESXi servers and the vCenter server. If it’s not, a lot of problems will arise when trying to join it to the domain later on.

This screen just informs us that the appliance requires a binding to the vCenter Extension Service in order to register itself as a vCenter Extension. Since there is nothing to configure here just click Next to continue the wizard.

On the Ready to complete page, click the Finish button to deploy the appliance. If you check the box Power on after deployment, the VM will be automatically started after the deployment is finished.

The operation will take a few minutes to complete and by looking at the progress bar in the Tasks section we can see the deployment progress.

Now go ahead and do the same thing on the Disaster Recovery site, by following the above steps. I’m not going to repeat myself here, but in the end you should have a vSphere Replication Management Appliance (VRMA) deployed in both sites.

Configuring the vSphere Replication Management Appliance (VRMA)

Now that the VRMAs are deployed in both sites, the next steps are to attach them to our vCenter servers and to configure the type of database the VRMAs should use. To begin, open a web browser of your choice and type in the IP address or FQDN of the virtual appliance followed by port 5480 (https://<VRMA IP ADDRESS>:5480). This is the IP address that we set up during the deployment wizard. One thing I need to mention is that a VRMA can only be attached to a single vCenter server, so in our case we will attach the VMRA from the production environment to the production vCenter server and the VRMA form the DR site to the vCenter server in that site.

Once the portal opens log in using the root account follow by the password that you set during the deployment wizard.

Click the VR tab then Configuration. Here is where we attach the vSphere Replication Management Appliance to our vCenter server and configure its database.

To configure the appliance with a remote database, just select the Manual configuration radio button then select the type of database you want to use, SQL server or Oracle. In this example however, we are going to use the default option and go with the embedded database since it works and scales just great even for large environments.

In the Password box, type a password for the SSO service then click the Save and Restart Service button. If vCenter does not have a trusted certificate from a trusted Certification Authority we will get a window with a certificate error message. Hit Accept to continue.

                   

If everything goes well we get a nice green successful message in the top of the page.

Now if we log in to the vCenter server we can see that a new icon appeared on the Home page. By clicking it we get redirected to the vSphere Replication configuration section where everything should look functional.

                    

Repeat these steps to configure the VRMA in the Disaster Recovery site because it’s needed for the next section. If the two appliances are not correctly configured, pairing the sites will fail, which in terms results by not being able to protect and replicate the virtual machines.

Pairing the two sites for replication

Before starting to replicate VMs, the virtual appliance from the production site must be connected to the Disaster Recovery vCenter server. This is a simple operation and it starts by clicking the vSphere Replication icon from the Home page of the vSphere Web client, then hit the Manage button.

Once redirected to the vSphere Replication management page, click on Target Sites then on Connect to target site to configure replication.

In the window that pops-up type the FQDN of your Platform Service Controller or vCenter server if the two are deployed on the same machine from the disaster recovery site, then provide the proper credentials to connect to the remote site. The account needs to have administrative privileges on the disaster recovery site vCenter server, or the connection will not succeed. Also, the password for the account needs to be set so it does not expire. Once the boxes are completed click the Log In button to test the connection.

If the Platform Service Controller does not have a trusted certificate, a security alert window will pop up in order for us to confirm the trust. Click Yes to continue.

To save the changes and connect the VRMA to the DR site click OK.

After a few seconds the connection should show up in the Target Sites section as Connected.

 

Configure virtual machines replication

Now that we are done with the VRMAs configurations, it’s time to test and see how replication is going for our virtual machines. I’ll write about it briefly and in a future article I will treat the subject in depth.

To configure replication for a VM or VMs in the production site, all we have to do is select the VM, right-click it, and choose All vSphere Replication Actions > Configure Replication.

The Configure Replication wizard opens. In the first screen of the wizard choose the option to replicate to a vCenter server and click Next.

From the Target Site list, select the disaster recovery site and continue the wizard. If the vCenter session is not authenticated to the remote site, you will be asked to authenticate as soon as you click Next. Provide the credentials of an account that has administrator rights on the disaster recovery vCenter server then click OK.

                  

Leave the default option to Auto-assign the vSphere Replication server and continue the wizard.

Here, click the first Edit button and select a datastore where the replicated VM files will be stored. Once you’re done, click Next.

Again, go with the defaults and click Next. Right now we don’t need any compression or quiescing, we just want to see if the replication is working.

Set the RPO time to a value that fits your network. The often the VM gets replicated,  the more bandwidth it will use, so choose carefully.

In the Ready to Complete page, click Finish to start replicating the VM to the disaster recovery site.

We can monitor the replication status from the production site, or from the disaster recovery site, and depending on the size of the VM and the network bandwidth you have between sites this could take from a few minutes to a few hours.

                    

In the end, the VM should be ready for recovery in case of a disaster on the production site. The replicated VMs can’t be seen in the vCenter inventory, only in the vSphere Section of the portal. They will appear in the inventory once they are recovered.

Summary

I know that maybe you were expecting more from the product, like doing things automatically, or at least some customizations, but for more you need to pay extra, like VMware vCenter Site Recovery Manager. Still…vSphere Replication is a great option to replicate the production VMs since it doesn’t need to much configuration, plus it uses the hypervisor layer to do all this. Another feature that puts it in the top, is how easy it makes the job for administrators to configure replication for virtual machines. Now off course, it has some limitations as I described at the beginning of the article, but it’s still worth trying, especially if you have storage incompatibilities. Like always…try it, test it, deploy it.