Storage replication is a popular method for synchronising production and disaster recovery (DR) sites in virtual server environments. If you're either using array-based replication or leveraging a storage virtualisation appliance for replication, there are several variables that will influence the efficiency of your storage topology as it relates to DR.
When you're sizing up storage solutions for DR, you should consider five issues:
- Vendor support - Storage architecture - Replication options - Deduplication or single instance storage support - Recovery options
Of course, there are several ways to get data from a production site to a DR site. Rather than simply give a high-level overview of these alternative virtual machine (VM) replication methods, this article will take a deeper look at specific storage array considerations. However, when it comes to architecting replication for virtual environments, this article can only scratch the surface. Many storage and DR optimisation tricks are vendor-specific. Be sure to check your storage and server virtualisation vendors' documentation and architecture guides for details relevant to your particular environment.
Let's set a baseline by assuming the general storage replication architecture shown below. Note: The network storage could be network attached storage (NAS) or either a Fibre Channel (FC) or iSCSI storage array.
All major network storage vendors offer tools for replicating data on an array from one site to another. Most of them use asynchronous replication for site-to-site network storage synchronisation, since the WAN network throughput or distance between sites is usually inadequate for synchronous replication. With asynchronous replication, writes are committed to primary storage, then replicated based on the replication policy set by the storage administrators.
Vendor support
Although most storage array vendors offer some form of asynchronous replication, the choice of array vendor nevertheless usually matters. When evaluating storage options, vendor support is a key criteria. A storage array should be supported on products from your environments virtualisation vendor and OS vendor. Support should also be considered for enterprise application vendors that name supported storage platforms. Storage platforms that leave a portion of your infrastructure unsupported constitute a risk.
You should also look at your backup vendor's list of supported storage platforms. Many enterprise backup products are capable of managing snapshots on most popular network storage platforms. A storage platform that integrates with your existing data protection software should be given more consideration than one that that does not.
Storage architecture
The way in which storage is architected to support virtualisation can have a dramatic effect on replication performance, and thus DR response. Fault-tolerant capabilities via RAID support are required, as any storage array should be deployed as RAID level 5 at a minimum.
In terms of DR response, you need to look at how each VM's virtual disk storage is allocated, as well as how temporary file locations are configured in each VM's guest operating system. When a storage array is configured to support virtualisation, you should set aside a volume set for transient or temporary data. How you deal with transient data should be determined by the service level requirements of the VMs you support. For VM data that is synchronously mirrored over dark fiber between two locations, certain application- or service-centric temporary files may be critical and will need to be replicated too. However, for VMs that are asynchronously replicated to a DR site, in most cases replicating temp files would be a waste of bandwidth and storage space. |