How to manage transient data and replication

Managing transient data (data that is created within an application session that is not saved in the database after the application is terminated) is important, but all backup and disaster recovery tools may not support transient data.

In this tip, Mike Laverick identifies the issues around transient data and examines strategies for managing it using DR technologies including VMware Site Recovery Manager, VirtualSharp and Zerto.

By transient data we usually mean temporary system information such as the Windows swap file or TempDB that is found in products like Microsoft SQL Server.

These data sets are often important to the operation of applications and services but generally do not hold non-reproducible data that an end user would find useful. In some cases, this temporary data is actually destroyed when these systems are rebooted.

All in all, this would seem to suggest that it would always be a good idea to relocate these files to virtual disks and data stores that are not replicated. After all, this saves precious bandwidth on the WAN for more important traffic.

It’s also a reasonable strategy with VMware VMkernel swap file that is created for every virtual machine (VM) that is powered on. VMware has made it very easy to relocate these files to cheaper, non-replicated storage -- and in most cases, it makes no impact on the recoverability of the VM. 

The process is very simple. Select each ESX host, and configure the new location for the VMkernel swapfile, and then enable the policy on the property of a DRS enabled cluster. That's much easier than configuring each and every Windows VM to store its swapfile on a different virtual disk on a non-replicated data store. 

Managing “tricky” transient data
However, the situation turns thornier once we start dealing with data that is held within the guest operating system. The official recommendation from VMware and from most storage vendors is to separate out the Windows swap file onto a different virtual disk and then store that virtual disk on a non-replicated location. However, in my research I’ve found the impact of this on technologies like Site Recovery Manager (SRM) might have undesirable consequences.

The main reason for this recommendation is to improve performance for the guest operating system. In the context of replication it saves bandwidth by not unnecessarily replicating redundant data. Remember, by default, when Windows boots for the first time, it automatically re-creates the swap file on the C: drive anyway. 

More hurdles dealing with transient data
When a VM is protected in SRM where one of its virtual disks is not replicated, the administrator will receive a warning that the VM is not protected.

Fig 1: Here’s the detach button that indicates that the virtual disk should not be recovered.

This type of alert is meant to warn the administrator of possible misconfiguration. In other words, not all of the VM files are being replicated to the disaster recovery location. In this case, that’s caused deliberately by our efforts to exclude transitory data from the normal cycle of replication.

An appropriate response to this situation would be to use the detach button (seen in Figure 1) to indicate that this virtual disk should not be recovered. Failure to do this would mean the VM would not be powered on at the recovery site and so detaching the disk is not optional.

SRM limitations
At this point, you’ll see the sting in a product like SRM. There is no global way to handle this detaching process, nor is there a command-line tool, such as VMware PowerCLI, to help the administrator handle the issue. For every VM that has its swap file relocated, the administrator would have to manually detach the disk. This manual labour is a time-consuming and error-prone process.

There’s more trouble. Let’s say a user performs real failover of a VM to the DR location -- the VM that lived in Site A now resides at Site B. When the recovery happens, Windows would put the swap file on the C: drive. This is default behaviour when it cannot find the original swap drive and means if you were at the DR location for some time, your configuration would be materially different from the production location. Additionally, if you decided to fail back the VM later on, the swap file would remain on the C: drive. Some legwork would be needed to return the virtual machine to its original location where the swap file was on some other drive.

Messy, eh? All that leaves me to think that best practice tips outlined by some vendors to relocate the swap file to avoid chewing up bandwidth might not be the best practise for all customers -- especially those who have very rich site-to-site bandwidth.

To relocate the guest operating system swap file, you must exchange free bandwidth for more complicated configuration right at the time when you want things to be as simple as possible -- during a disaster. And, if you are in the middle of a major disaster -- fire, flood, or some other act of God -- that’s no time to be worrying about a Windows swap file.  

My tip for managing transient data is to use a pre-configured virtual disk that's populated upfront before you run a recovery plan.  By cloning a virtual disk with the correct settings, the recovered VM should be able to mount its temporary data store location at power on.

Mike Laverick is a former VMware instructor with 17 years of experience in technologies such as Novell, Windows, Citrix and VMware. Since 2003, he has been involved with the VMware community. Laverick is a VMware forum moderator and member of the London VMware User Group. He is also the man behind the virtualisation website and blog RTFM Education, where he publishes free guides and utilities for VMware customers. Laverick received the VMware vExpert award in 2009, 2010 and 2011.

Since joining TechTarget as a contributor, Laverick has also found the time to run a weekly podcast called the Chinwag and the Vendorwag. He helped found the Irish and Scottish VMware user groups and now speaks regularly at larger regional events organised by the global VMware user group in North America, EMEA and APAC. Laverick published books on VMware Virtual Infrastructure 3, vSphere4, Site Recovery Manager and View.