Using Double-Take Software and the Virtual Recovery Appliance

When considering a BCP (Business Continuity Planning) solution for your application server environment, one product that you should definitely consider is Double-Take Availability from Vision Solutions. I’ve been using the Double-Take product suite since its earliest days when the company was originally NSI Software. Over recent years the company became branded as Double-Take Software to highlight their flagship product and recently merged with Vision Solutions.

While there are many tools which can achieve application and server protection, I’d like to show you how I use Double-Take software and the Virtual Recover Appliance for protection of a server. This post doesn’t delve into the deep technical content on how Double-Take works as I just chose to review the specific task of protecting a server with VRA.

For my example I am using a BlackBerry Enterprise Server (BES). The design of my server is a stand-alone configuration with the BlackBerry Enterprise 5.x server and Microsoft SQL Server 2008 R2 co-located on the same device. The hosting infrastructure is a virtual server running on VMware vCenter 5 server managed cluster.

The recovery environment is also a VMware vCenter 5 managed cluster in a secondary site which is connected via the WAN. You can use a standalone ESXi for recover or a vCenter instance; either will suffice.

Double-Take is able to protect an entire physical or virtual server into a virtual target system by using what is called a Virtual Recovery Appliance (VRA). The VRA I’ve configured is running on a Windows Server 2008 R2 instance in my target location. The VRA is actually protecting more than one server which is where this is a spectacular product.

The licensing is simple. You will need one license for your source machine and one for your VRA. Because you can protect more than one source server with the VRA you will find that the win is both technical and financial by using this configuration. If your source server is a virtual server you can also leverage the Virtual 5-pack licensing bundle which makes the cost per server much more attractive.

Protection of the server is done by creating an asynchronously replicated disk image of each volume of the server including the active system volume. Each volume is mounted against the VRA as a disk volume. During the process of protecting the source server the wizard defines the destination virtual hardware which can also differ from the source server which can be advantageous for a variety of reasons.

The data is sent as byte-level replicated data with ordered unpacking at the destination which ensures that you have data and system integrity at the destination. You can also use scheduled snapshots at the target to maintain multiple recovery points in the case where your source server is temporarily out of sync at a time where you need to failover to the target.

Let’s walk through the configuration of the product. I’ve assumed that you have installed the Double-Take Availability on your source server and your VRA already. Other pre-requisites are that you have credentials to be able to protect the server which has local administrative privileges to both the source server (BES) and the target (VRA).

Make sure that you use a domain account that does not expire. Because you will use this for ongoing protection you will need to ensure that there are no issues with the account.

On your VRA server, launch the Double-Take Console and click the Get Started button

Next choose the Double-Take Availability option and click Next

Choose Protect an entire server using Hyper-V or ESX virtual machine and click Next

Type in the source server information and the credentials of the account to be used to protect it

Select the volumes you will be protecting. By default only the system volume is selected so choose all that are required and click Next

Now choose your Target Server is the VRA server. Enter the credentials (ideally same as source server) and click Next

Next we configure the target environment by clicking the Add vCenter Server link

Enter your vCenter server and the credentials to be used to provision the recover server then click Add

Now you will see your vCenter server and an available ESX server in the screen. Click Next

Choose the datastore target for the disk images. Because your source may dynamically grow you will want to ensure that you have growth space. You will have an opportunity to select different target Volumes for each source disk in a couple of steps if you would prefer to. Click Next to continue

Choose the name of the virtual machine. NOTE: This is only the name of the registered machine in the VMware vCenter environment. The server itself will have the same name as the source server when it is failed over. The default is SERVERNAME_Replica

Choose the virtual network that the server will attach to and scroll down to set the IP information

You may enter the IP address, mask, gateway and DNS servers which will be set in the server on failover. Click Next

Choose the replica disk configuration. You may now select the size (must be larger than source), the type (thick or thin) and the Datastore which will hold each source disk. Click Next when ready

Under Protection Options you can choose the level of compression. While higher compression may be more CPU intensive, I have personally found that High is the best option and it does not adversely affect my source server.

The default target route is the IP address of the VRA. This need only be changed if you have multiple NICs in the VRA.

You may also choose the auto-failover option which will monitor the source server for outages and provision the target based on a set of criteria. For my configuration I have opted for manual failover. There have been enough cases where WAN loss would have triggered a failover which may not have been necessary.

Click Next to complete your configuration and begin the protection process. This will take a while to complete as it seeds the data to the target. While it is mirroring it will also queue changed data on the source server and send it to the target in order. This is also the behaviour during brief outages.

Just like on a TV cooking show we jump to the already completed replica to save on the wait. Once the data is synchronized the connection shows as fully protected and you can right click for options.

In my context menu one of the options is Failover which allows you to provision the target server from the disk images.

In the Failover option screen you can opt to failover the server using live data which will provision the server and configure the network as you’ve defined during the protection configuration earlier. If the server is still on, it will prompt you to shut down the source server as part of the failover.

You may also run a test failover which will provision the virtual target but leave the virtual network card disconnected so that you can get onto the server console for testing or for other offline tasks.

It’s actually that easy. The total setup time including product installation and configuring the replication was approximately 30 minutes. The mirroring of the server took approximately 10 hours all totalled and that is where we get to the fun part:

RPO: < 1 minute

RTO: 10 minutes

Once the source network and infrastructure is available we simply reverse the process through the interface. I would love to dive deeper but I will leave that for another post.