By Kevin Komiega
Disaster preparedness has raced to the top of the IT to-do list for many large companies since 2001, and as companies move more data between multiple locations, the cost and latency issues inherent in wide area network (WAN) connectivity have become a thorn in the side of many business continuity (BC) and disaster-recovery (DR) planners.
It is in this area where WAN acceleration technologies may serve as the cure for ever-increasing cost and declining efficiency of replicating data over distances.
Stephanie Balaouras, a senior analyst at Forrester Research, says her research shows that business continuity and disaster-recovery projects currently account for a significant chunk of the IT budget among large enterprises.
“People are spending a lot of money. Upgrading business continuity and disaster-recovery processes has been a top priority over the last few years. And these projects tend to get funded more quickly and get a lot of the IT budget because they are high profile within organizations,” says Balaouras.
According to a recent disaster-recovery and data replication study conducted by Forrester Consulting and commissioned by WAN acceleration vendor F5 Networks, the average spent on DR and BC amounts to approximately 21% of the enterprise IT budget. Of that percentage almost one-third goes directly toward buying bandwidth for a data-replication solution for DR.
Forrester’s data is based on a survey of more than 500 IT decision-makers. The research shows that multiple data-center locations are now the norm among large enterprises, with 67% of respondents in North America saying they have two or more backup data centers or recovery sites. Sixty-one percent of North American respondents had distances between sites of 1,243 miles to 3,728 miles.
These enterprises are trying to stretch the distance between data-center sites without sacrificing performance or, more importantly, the time it takes to recover data in the event of a disaster.
According to Balaouras, most enterprises can recover from a data-center failure in five hours or less. “Some enterprises could recover in as few as two hours, but very few could get below that. Enterprises are struggling to maintain their current recovery time objectives. They are not happy with their current performance, and everybody wants to improve their RTO and RPO,” says Balaouras. “They are going to be forced to spend more money on bandwidth or find a more-efficient way of replicating data.”
The Forrester study shows that 45% of North American respondents could be back up and running in five hours or less, while just 8% say they can hit a mark of two hours.
Balaouras says the challenge is to figure out a way to optimize DR solutions so that recovery time and recovery point objectives can be measured on an egg timer.
The Forrester survey shows that WAN connectivity issues such as latency, reliability, limited service options, and limited bandwidth each make an impact on recovery objectives. A majority of those surveyed say their current bandwidth limitations prevent them from increasing the distance between DR sites, extending replication to more applications within the organization and extending remote replication protection to remote sites.
So why isn’t a recovery time of two-to-five hours good enough? Time is money. The study revealed that half of North American enterprises consider speeding the time to recovery as critical to their businesses because the cost of downtime and data loss has a direct impact on the bottom line.
There is, however, a potential ray of light at either end of the IP tunnel with the advent of the WAN acceleration technology market. A number of start-up vendors and a few bigger names in the storage industry are shipping appliances capable of optimizing traffic over existing connections for less than it would cost to buy more bandwidth.
“Replication has been so expensive in the past because it typically required high-priced connectivity options like synchronous optical network [SONET]. WAN acceleration technology can allow enterprises to expand replication to other operationally critical applications and increase overall efficiency without significantly increasing the overall cost,” says Balaouras.
She says vendors such as Cisco, Expand Networks, F5 Networks, Juniper, Packeteer, Riverbed Technology, and SilverPeak Systems all have compelling offerings aimed at boosting WAN performance for replication. But the market itself has yet to reach critical mass.
“The key to the market really taking off is the development of the entire ecosystem. WAN acceleration vendors need to develop partnerships and go to market with the tier-one storage vendors and independent replication vendors,” says Balaouras. “Things will really accelerate once all of the players are involved.”
One thing is certain: Most of the end users surveyed say the need to boost RTO and RPO without paying more for bandwidth would be extremely beneficial.
Balaouras has a number of recommendations for improving the DR process, not the least of which is to improve your existing replication infrastructure by considering WAN acceleration technology.
She says enterprises should evaluate WAN acceleration technologies before they invest in additional bandwidth to support remote replication. But Balaouras advises end users to focus on vendors that have demonstrated their commitment to playing nice with other vendors. “When evaluating WAN acceleration appliances, focus on the vendors that have made the time and investment to test the interoperability of their appliance with independent software vendors, storage vendors, and storage networking vendors,” she advises.
WAN acceleration appliances and software can boost throughput and offset the latency issues of today’s networks using a myriad of compression and optimization techniques. The rate of data growth and the pressure to maintain or even cut IT costs while streamlining the DR process may catapult WAN acceleration technologies to the top of enterprise’s IT wish list, but it could happen faster if the software and array-based replication vendors get on the bandwidth wagon.