City of Pittsburgh rolls out VMware disaster recovery |
 |
By Beth Pariseau, Senior News Writer
13 Feb 2009 | SearchDisasterRecovery.com |
|
|
Virtualizing servers and connecting them between primary and secondary data centers turned out to be the only affordable way for the City of Pittsburgh to offer multisite disaster recovery (DR) last year. However, the city's network analysts said integrating VMware's Site Recovery Manager (SRM) with its Hewlett-Packard (HP) Co. EVA6000 arrays was harder than anticipated.
The city's servers have been about 80% virtualized since the summer of 2007, estimated the city's network analyst Alex Musicante. But it wasn't until last December when SRM was integrated with HP's replication software that Pittsburgh could implement a disaster recovery plan.
Musicante said using virtual servers instead of physical servers and running HP's Continuous Access replication on the EVA arrays let the city set up a secondary data center for disaster recovery at approximately 50% of the original estimated cost. "The virtualization process in general has been very positive for us," he said. "It has also allowed us to get rid of some legacy systems and modernize the network."
VMware's Site Recovery Manager, released last year, is designed to help server virtualization customers automate their disaster recovery checklists. These were often kept on paper and checked off manually before. The failover software also helps them figure out how storage and server resources correspond between primary and secondary sites, alerting administrators to inconsistencies that can cause disaster recovery plans to fail. It is integrated with array-based replication products from vendors such as EMC Corp., Dell/EqualLogic, Hitachi Data Systems, HP, IBM Corp. and NetApp.
But although the vendors had done integration work so Site Recovery Manager and Continuous Access could "see" each other, Musicante said deploying SRM and successfully failing over involved some painstaking work to reconfigure the storage environment.
Prior to deploying SRM, the company had set up the EVA array as two DR groups recognized by Continuous Access. But SRM's fine print called for a 1:1 relationship between each LUN on the array and its DR group. "HP told us we could just move the LUNs into new DR groups, but that wasn't exactly true," Musicante said. The city had to destroy and re-create LUNs and DR groups by hand. "It's a slow process with a lot of layers of complexity."
Once the DR groups have been reconfigured, the city will have to undergo a full re-sync of the 12 TB it replicates. Another surprise came when the city realized it needed HP Business Copy software to do the snapshots required to take advantage of the ability to test a failover without affecting production with SRM. "That's something we thought should've been included with either Continuous Access or SRM," Musicante said.
Still, the city has been able to successfully test a full failover during off hours. The next hurdle is automated failback, which has yet to make its way into SRM. "I'm sure they'll address that soon," Musicante said.
An HP spokesperson wrote in an email to SearchStorage.com, "In setting up an environment involving multisite failover, there are often complexities involved. HP continually attempts to improve the communication vehicles used to address these implementations, including extensive field and services training and preparedness, as well as thorough product documentation. If the customer is having difficulty, we understand and regret any inconvenience."
|
|
|
|
