Las Solanas Consulting

Storage Virtualization | FAQs & Discussions

A Cost-Effective DR and Offsite Backup Solution Using Vizioncore's vRanger PRO and DataCore's SANmelody with Asynchronous Replication

A White Paper by Tim Warden (DataCore Software Corporation) and Joseph Ahn (Vizioncore, Inc.)

EXECUTIVE SUMMARY

Over the course of the last few years, implementing a Disaster Recovery project has become a priority for most businesses, regardless of their size. It is now commonly accepted that although the SMB may not have the same IT budget as large enterprises, they typically have the same imperatives in terms of data protection and availability. Countless studies conducted and articles published all conclude that businesses without a proven DR strategy usually do not survive a datacenter disaster.

With the advent of server virtualization, many smaller businesses have begun to rethink the feasibility of implementing a DR solution. However, they soon realize that server virtualization alone is not enough. An infrastructure must be put in place to replicate the data to the DR site and make it available for rapidly redeploying the applications.

Many of the hardware and software vendors offer products that can serve as tools to create the infrastructure, but the solutions vary in terms of complexity, completeness, and reliability.

In this white paper we present a complete solution for implementing an offsite backup that doubles as a DR solution that can be rapidly turned on. The solution combines two Best of Breed products. Vizioncore's vRanger PRO will be used for backing up virtual machines and their data at the primary datacenter. SANmelody from DataCore Software Corporation will be used as a SAN Storage Array, offering Asynchronous Replication to mirror the backups to the DR site.

The objective is to architect a solution that is elegant, automated, reliable, and cost-effective.

TOPICS DISCUSSED IN THIS WHITE PAPER

ASYNCHRONOUS MIRRORING DEFINED

Asynchronous Mirroring or Asynchronous Replication is a means of copying data from one server or storage array to another. The two systems are typically separated across different geographies and thus the distance and available network bandwidth between the two sites introduce latency that precludes the use of Synchronous Mirroring. Thus the servers use a "store and forward" mechanism, buffering the data locally until it can be sent across what is often a slow (e.g. DS3) link.

DataCore Software Corporation implements this feature in the AIM ("Asynchronous IP Mirroring") option for their SANmelody and SANsymphony products.

For an in-depth review of Asynchronous Replication and DR, please refer to the white paper DR and Asynchronous Replication - Tutorial and Best Practices

SOLUTION OVERVIEW

In this white paper we will be using VMWare ESX servers for our Server Virtualization environment, both at the datacenter in Tucson, Arizona and at the DR site in Austin, Texas.

The Vizioncore vRanger PRO product will take backups of the VMs on the ESX hosts in the datacenter.

DataCore's SANmelody product will be used to implement a SAN Storage Array, providing shared storage to any of the ESX hosts and enabling VMotion. We will provision a virtual volume for use by vRanger as a destination for the backups. SANmelody's AIM or "Asynchronous IP Mirroring" option will be used to replicate the vRanger backups to a SANmelody server at the DR site.

Network Diagram of DR Solution
Network Diagram of Solution

The replicated vRanger backup volume can serve as an offsite backup, or we can choose to use that datastore to implement a traditional backup according to our backup policy. We can even use SANmelody's Snapshot option to implement disk-to-disk backups, if required.

Finally, we will test our solution, restoring VMs from the replicated volume to our DR site's ESX server.

CREATING THE SAN VOLUMES

SANmelody is a software package that implements a SAN Storage Array with native Fibre Channel and iSCSI support. SANmelody runs on a standard Windows x86 platform and can "virtualize" any storage presented to the Windows LDM (Logical Disk Manager).

Commodity SAS or SATA drives can be pooled, from which virtual volumes (or LUNs) are taken and presented over iSCSI or Fibre Channel to the storage clients — our ESX hosts, SQL, Exchange and File servers, etc.

Discovering iSCSI LUNs in ESX
SANmelody Virtual SAN Storage is ideal for ESX Servers

The SANmelody GUI is an intuitive and easy-to-use set of snap-ins in the Windows Management Console. If you can manage a Windows server, you can manage SANmelody.

In the dialog below, a new Thin Provisioned virtual volume named "vRanger" is mapped to our VirtualCenter server which hosts vRanger PRO.

LUN Masking GUI
Screenshot of Volume Mapping

SANmelody implements the complete SCSI3 recommendation and is ideally suited to any SAN storage application, including its use for creating VMotion-enabled VMFS volumes for VMWare HA or DRS. Here, our "vRanger" volume will be used for saving vRanger PRO backups.

ESTABLISHING AN ASYNC MIRROR

Asynchronous IP Mirroring (AIM) is an optional licensed feature of SANmelody. It allows two cooperative SANmelody Storage Arrays to replicate SAN volumes over standard IP.

At our DR facility, we install a second SANmelody Storage Array, creating virtual volumes that will receive the replication from the SANmelody server at our datacenter. In this example, we create a single virtual volume which will receive the replication of our "vRanger" volume. We name the virtual volume "AD-vRanger", an arbitrary prefix to remind us that the volume is an active AIM Destination volume. We then add it to the AIM Destination Manager's list of replication volumes, as shown in the following screenshot.

Replication Destination Volume
AIM Destination Virtual Volume

At the source site, we establish an AIM relationship between the two SANmelody servers, creating a new "Destination Node". We specify the name and IP address or our SANmelody server at the DR site.

Setting Up DR Site Connection
Specifying the AIM Destination Node

We then create the AIM relationship between our source "vRanger" virtual volume and the replication target, our "AD-vRanger" virtual volume.

Setting Up Volume Replication Relationships
Creating The AIM Volume Relationships

Useful Tip: Normally at this point, we would need to "initialize" our mirror to bring the source and destination into synch. However, in this case, we have not yet formatted the source "vRanger" volume on the vRanger PRO server, so in effect the two volumes are in an unknown state. Formatting the volume (e.g. creating an NTFS file system) will result in the NTFS catalog being replicated to the DR site, effectively synching the two volumes.

We are now actively replicating our vRanger backup volume to the DR site.

SETTING UP THE vRANGER VOLUME

Thus far we have mapped a LUN from SANmelody to our vRanger PRO server and are actively replicating to the DR site. After a "Rescan Disks" in the Windows LDM, we discover our SANmelody volume, format it and mount it.

SAN Disk Properties
The Disk Properties Dialog of a SANmelody Disk

Just for the sake of clarity and organization, we create a folder called "vRanger" on the volume. This folder will be used to hold our backups.

TAKING THE BACKUPS

We install Vizioncore's vRanger PRO product on our Virtual Center server and use it to backup our VMs for replication to the DR site. vRanger features an intuitive, easy-to-use GUI, complemented by a CLI interface.

Launching the GUI, we click the "Backup VM(s)" button to prepare our backups. The Backup interface involves three screens titled "Source", "Destination" and "Options".

In the "Source" screen, we select those VMs and/or their disks that we wish to backup. For instance, we could decide to backup the relatively static "C:" drive .vmdk files for the VMs once every 2 weeks, and backup their "D:" data drive .vmdk files nightly.

vRanger Backup Screenshot
Selecting VM's to Backup

After selecting the VMs targeted for backup, we navigate to the "Destination" tab to select the volume on which we want the archives to be placed — in this case, the "vRanger" folder we created on our SANmelody vRanger volume.

vRanger Backup Destination
Selecting the vRanger Destination Datastore

vRanger PRO can backup the VMs to VMFS volumes, or to NFS or CIFS (i.e. SMB or Windows) shares. Backing up to a VMFS volume eliminates LAN traffic as it is a block level operation using the SAN. vRanger PRO also integrates with VCB (VMware's Consolidated Backup framework). Using vRanger with VCB will yield even faster LAN-free backups.

vRanger with VMWare VCB Integration
vRanger Includes VMWare VCB Integration

Nonetheless, most vRanger customers prefer using Windows shares as it permits taking differential backups. It also offers performance advantages over backing up to a console-based VFMS datastore.

Clicking the Options tab, we can control aspects of the backups. For instance, we can choose to automate full vs. differential backups. Taking differentials will radically improve the utilization of our inter-site bandwidth.

In the screenshot below, this vRanger backup job will take a full backup every 14 days, and take differentials in between.

vRanger Backup Options
Selecting vRanger Backup Options

Notice the "Encrypt Data Transfer" flag. We may use this feature to secure our data against hackers when, for example, we are backing up over an unsecured link. We'll talk more about this when we discuss offsite backups.

vRanger can also install and enable VSS agents in Windows VMs. VSS will provide application "quiescing" prior to taking the snapshot of a running VM.

After selecting options and clicking "Run Backup", the resulting archives and their associated "info" files will be placed on the SANmelody virtual volume and thus replicated via AIM to the DR center.

Monitoring Async Data Replication
Active Data Replication

AUTOMATING THE BACKUP PROCESS

The vRanger PRO GUI facilitates creating CLI scripts. The selections we make in the GUI result in command lines which can easily be put into scripts and scheduled.

Automating Backups With CLI Scripts
Copying the CLI Command to Build a Script

DataCore also provides scripting to drive its snapshot and AIM commands. We can use the AIM Snapshot command after our backups have completed to insert an in-band snapshot request into the data stream. In this way, once our backups have been replicated to the DR site, a snapshot will be enabled or incremented. We can use the snapshot to run a backup, or to set a coherency point should we need to test or use the DR site.

The batch file will look something like this:


"C:\Program Files\vizioncore\esxRanger Professional\esxRangerProCli.exe" -virtualcenter vc2://Folder=group-d1 -copylocal V:\vRanger -drives:all -totalasync 10 -hostasync 2 -lunasync 3 -vmnotes -diffratio 50 -maxfullage 14 -retendays 31 -zipname [config]_[year][month][day][hour][minute][second] -autodiff -mailonerror -vss

DCSAppRCmd -c \\tussmya "AIMSnapshot vRanger"

The last command instructs our TUSSMYA SANmelody server to send a snapshot request to the AUSSMYB SANmelody server at the DR site in Austin following the transfer of the replicated backups.

USING THE REPLICATED BACKUPS

In the previous section we alluded to using snapshots at the DR facility. Snapshots allow us to make a usable coherency point on our AD-vRanger volume. This is advisable, because when our backups occur and the data is replicated to the DR site, the AD-vRanger volume will be changing as the replicated writes are "de-staged" into their corresponding locations.

In SANmelody, snapshots are a relationship between a "source" volume and a snapshot "destination" volume. SANmelody snapshots use "Copy On First Write" technology, and when based on Thin Provisioned volumes, the snapshots are not storage-costly.

Using Snapshots On DR Volumes
A Snapshot Relationship for the Daily Backup

TURNING ON THE DR SITE

To use the replicated volume at the DR site, we map a snapshot of the "AD-vRanger" volume from our AUSSMYB SANmelody server to the DR site's Virtual Center / vRanger server.

LUN Masking Snapshots of DR Volumes
LUN Masking The Snapshot of AD-vRanger

We then discover the volume on the server with a "Rescan". Opening it, we find the vRanger PRO backup archives in tact, ready for use.

Mounted Snapshot on vRanger Server
Mounted Snapshot of the Replicated Volume Ready For Use

RESTORING A REPLICATED VM

Although we have replicated our vRanger PRO archives, we've not replicated the vRanger PRO database which lists all the available archives. Obviously, the list of available archives will appear empty, as in the screenshot below. To restore our VM's, we will use the "Restore from Info" feature of vRanger PRO.

Restoring VMs at the DR Site
Restoring our VM's by Browsing For Info Files

Select VM To Restore Selecting "Restore From Info" produces a dialog with three screens. Our first step is to browse for our VM archives on the AD-Ranger snapshot volume. We select a differential backup of SQL01.

Select Destination Host And VMFS After selecting the VMs we wish to restore, we navigate to the second screen where we select the destination ESX host and associated VMFS datastore.

Select Restore Options Navigating to the third screen, we accept the default options, and arbitrarily decide to rename the restored VM "DR-SQL01".

As you can see, vRanger PRO allows you to capture the commands for scripting the restoration process. If we are replicating a large number of VMs, this can facilitate bringing our DR site live.

vRanger CLI Executing

Once the restore has completed, we successfully power on the VMs at the DR site. The ESX server will notice that the machine files have been moved and will recommend we create a new Unique Identifier (UUID). Selecting "Create", we dismiss the dialog.

VMWare Create New UUID

The VM boots up. We're prepared... ready for a disaster.

Restored VM Running
Console of a Replicated VM at the DR Site

THE OFFSITE BACKUP

A business can spend a small fortune in backup services, transporting tapes offsite to a "secure" facility. Alas, if those tapes were hijacked en route and their contents have not been encrypted, the resulting situation can be as big a disaster as the one we're developing our DR site for. We might be better off using our replicated volumes to implement the offsite backups at our presumably secure DR site.

If the data connection between the two sites is secure, we won't have to worry about encryption. Nonetheless, as we have seen, vRanger PRO offers a data encryption feature.

Given the rash of recent incidents suffered by the large backup services companies and their customers, our vRanger / AIM internet highway solution clearly offers a more secure means of getting our backups offsite than using the traditional asphalt highway approach.

Once the vRanger backup files are at the DR site, we in effect have our "offsite backup". However, we have several options for what we do with those files. Clearly, we can present a snapshot of the replicated vRanger volume to our backup server and run a traditional backup to a tape library at the DR facilty. Additionally — or alternatively — we can simply use SANmelody's Complete Image Snapshot to make a clone of the snapshot onto a physically separate set of disks — in effect, a disk-to-disk backup.

CONCLUSION

SANmelody and vRanger PRO products each offer powerful solutions for the datacenter. SANmelody is an outstanding software solution for implementing full-featured SANs and allows IT professionals to custom build their storage infrastructure according to their needs. vRanger PRO is the essential backup / restore tool for virtual server environments.

Bringing the two products together in an integrated DR / backup and offsite backup solution provides an elegant, reliable and cost effective means for businesses to protect their data and keep their applications available.