The economic climate has forced businesses to focus on running on a tighter budget. Disaster recovery (DR) is not immune from the budget crunch (although DR practitioners will preach that it is the one area that should never face cuts). So what lower-cost options are available for building and maintaining DR site-to-site replication solutions?
First off, server virtualization has been shown again and again to save DR time and money across organizations. Last year, I wrote a tech tip on the top DR budget wasters, in which I shared a customer story about virtualization and disaster recovery. Over the past year, as I've spoken with many more IT organizations on this subject, the response has been consistent: Virtualization has decreased the amount of time required to perform DR tests by more than 50% and has decreased the number of staff required to perform the DR tests by slightly less than 50%.
However, in this article, I'd like to focus on another aspect of DR -- replication using open source tools and lower-cost storage for your Linux/Solaris solutions. A typical enterprise Linux distribution includes around 2,500 packages with hundreds of useful tools. However, there are tens of thousands of additional open source tools available that may allow you to achieve DR goals at a lower cost. Let's talk about two popular tools for replication: rsync and distributed replicated block device.
What is rsync?
Rsync is included with most enterprise Linux distributions and is supported on all of them. It is a file-level replication tool maintained under the umbrella of the Samba project and can be found here. Version 3.0 was released just over a year ago, adding incremental recursion scan to improve replication of large file systems that contain lots of files (rsync must keep track of all files being replicated, and too many files caused older versions to run out of memory. The new version fixes this problem).
Rsync has been used for years by many Linux and Solaris administrators for replicating configuration files and non-mission-critical application data. However, its recent improvements, including support for extended access control lists (XAttrs), recursive scan and years of production deployments have elevated it to be considered a DR solution for the higher tier of Linux/Solaris-based data center workloads.
What is DRBD?
Distributed replicated block device (DRBD) is a block-level open source replication technology maintained by Linbit. It can be found here. DRBD is included in all distributions except Red Hat Enterprise Linux (RHEL). However, the version included with CentOS is binary compatible with RHEL and may be used with RHEL.
DRBD replicates block writes in a primary-secondary disk configuration across a TCP/IP network. Only the primary disk, or active disk, may be accessed by the file system. The replicated, or secondary, disk cannot be accessed until it is promoted to primary (at which time the mirror is broken). DRBD can be configured for either synchronous or asynchronous mirroring. In synchronous mode, the file system issuing the data write does not receive the write complete until both the local and remote disks have been written to. As a result, distance and latency limit the use of synchronous mode. Asynchronous mode works best for replicating long distances; however, if the bandwidth of the TCP/IP link is less than the bandwidth of the data writes on the primary disk, the primary system's performance will be throttled to the bandwidth of the link when all of DRBD's network buffers have been consumed.
Shrink storage cost with JBODs
"Just a bunch of disks" (JBOD) arrays are much less expensive than commercial storage arrays. Many second-tier or less mission-critical applications may be served well with an inexpensive JBOD array filled with Serial Advanced Technology Attachment (SATA) disks. While SATA disks do not offer the same speed and bandwidth compared with more expensive storage array disks, they can be good enough to meet the needs of most applications, especially during DR operations at a recovery site. Using the replication technologies such as rsync and DRBD as described above, a high-performing primary system can be inexpensively replicated to a cheaper JBOD system. Such a configuration assumes that degraded service levels during recovery site operations are acceptable to the business.
Disaster recovery cost savings versus risk
The suggestions laid out above effectively boil down to a tradeoff of cost versus risk. Often, companies faced with tightening budgets discover that taking on some additional risk to reduce costs is acceptable, especially for certain applications and business processes that pose less risk to the company. The risks incurred by moving to open source from commercial tools for replication include lack of vendor support in addition to the risk from making changes to a functioning system. However, some IT organizations have the skills in-house to mitigate that risk, or they may find that purchasing a support subscription from a Linux distribution vendor still offers savings over commercial products but maintains the peace of mind of having somewhere to turn to in case problems arise.
However, those mission-critical applications that form the backbone of the business should not be exposed to risk. Most IT organizations push that risk onto commercial vendors at greater expense to achieve the service level and peace of mind required to operate the business.
ABOUT THE AUTHOR: Richard Jones is vice president and service director for Data Center Strategies at Midvale, Utah-based Burton Group. He can be reached at email@example.com.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at firstname.lastname@example.org.