Home
> Continuous Access, Site Recovery Manager, VMware > Site Recovery Manager and HP Continuous Access DR Group design
Site Recovery Manager and HP Continuous Access DR Group design
Hi I have moved this blog to the new site frankdenneman.nl.
The new home for this article is: http://frankdenneman.nl/2009/02/site-recovery-manager-and-hp-continuous-dr-group-design-2/
Apologies for the inconvenience!
Frank Denneman 
I wouldn’t mirror CA DR Groups to Protection Groups. I would mirror Datastores to Protection Groups. You want to have the option to fail-over as granular as possible. So best situation would be:
1 datastore = 1 datastore group = 1 protection group
Fail-over per service would also allow you to define and meet your SLA and test it per service.
I wouldn’t mirror DR groups to a protection groups either, or at least that the point I was trying to make.
You can create a single DR group per datastore.
The new eva’s support up to 256 single members DR groups.(Eva 4400 has a maximum of 16 DR groups)
But you will run into the maximum amount of LUN ID’s (256) on ESX if you want to connect to the failover LUNs and the normal source LUNs of the site.
so ESX will limit you to 128 LUNs per site.
Although it is a good thing to want to have as much granularity as possible, too many DR groups will strain the array controllers.
A maximum of 4 paths can be opened per storage processor port .
A DR group will have one active path so a maximum of 4 DR groups can be serviced per port.
The 8×000 series use 2 ports for replication. That means that 8 paths per controller can be opened, 16 per array.
The XCS 6.x firmware selects the “same” controller when creating a Storage system replication pair,
that means that a DR group managed by controller A on Array 1 will pair up with controller A on Array B.
Limiting the amount of replication pairs.
16 replication ports can be active, that means if you have more than 16 DR groups,
tunnels needs to be closed and DR groups must wait for their active path.
So to much granularity on large sites can create unnessecary latency as well.
This latency is not a show stopper, but introducing extra latency is not optimal. 🙂
why not use HP storage works storage mirroring which is the OEM version of Double-Take Software. Then you could replicate the entire VM host or just single files if needed.
Hi Brennels,
Could you elaborate your comment a bit more?
Hi Frank, after reviewing it looks like there are a couple of challenges that are presenting problems. First the I/O or bandwidth utilization and then second is the grouping of the data sets and integrity with the write order of the transactions. If this was all on the same LAN it may be less of an issue but I am making the assumption this is over a WAN to another facility. If that is the case then here are some caveats of hardware replication which I think you are finding out. There are basically two types of replication, Hardware which is at the block level and host based with is at the byte level. The difference is that byte level sends smaller transactional replication throughput than block level but it is performed at the host or server level versus replicating from the disk device. The Storage works storage mirroring product is byte level and runs on the individual server or in this example an entire virtual host with multiple vm’s. As the data is replicated it is applied in write order preservation when it reaches the target server ensuring the integrity of the application data. This also provides you greater flexibility of performing business continuity testing as you don’t have to recover an entire LUN you can test the entire data center or just a single machine and all while the production systems remain online so you don’t interrupt business operations. Hardware replication with SRM is a good solution but may not fit this particular customers current infrastructure and or requirements. Unfortunately there isn’t usually one size fits all type of solution when it comes to disaster recovery.
Hope this helps,