1. Initialize snapmirrors back to the "home" site

2. Reconfigure the SRA to determine replication relationships

3. Build protection groups

4. Build recovery plans

5. Execute recovery plans.

With Metrocluster it's basically:

1. Wait for resync

2. Issue giveback.

3. Vmotion VMs back home or just wait for secondary site to fail (or not fail)

In either event you're going to want someone with authority to tell you its okay to "push the button"; wether you're kicking off a script to ssh into the filer or pressing the "run" button in SRM. The environment itself is going to dictate which of the two options will be more elegant.

For example, when there is a layer2 network connection (Same VLAN exists in both sites) with a low latency link (DWDM?) then Metrocluster would probably be the best choice.

When the DR site is on a separate network space and there is a higher latency connection between sites, then SRM becomes the better solution.

On the different technologies, Metrocluster is effectively good up to 100km (~60 miles), which is right around where we find a lot of DR sites these days. Additional protection can be provided by snapmirroring data to yet a 3rd site even further away in the event of a massive regional outage. Perhaps your primary site is located in your office complex which is fed by the city grid while your secondary head is in a datacenter on dedicated power feeds? In that situation your secondary metrocluster node could be across the street and still running while your office building is pitch black.

Regarding failures, lets suppose your blade chassis has a major component issue (all the PSUs fail for whatever reason, or perhaps someone unplugged them by accident) or a switch module misconfiguration that disconnects them from the network/SAN.

On switch failures, its not terribly uncommon for network/SAN fabric to be powered by DC infrastructure while your actual servers are being fed via AC. I've been in datacenters where all the AC had dropped off and the DC is running strong (this would provide the superman switch scenario). Losing power is a form of component failure.

" To this point I have to disagree. I'd rather use an
automated tool such as VMware SRM to semi-automate the recovery
end-to-end (from storage to VMs) of an otherwise more complex storage
solution .... rather than issuing manually a single easy command at the
storage level .... and facing the challenge of restarting hundreds of
VMs in the proper order w/o a tool that helps me doing that."

With propper planning you can get the same if not more granular controls. PowerCLI provides us the optiont to quickly build solutions to solve problems just like this and still provide the illusion of automation (admittedly requires scripting but thats what consultants and professionals are for!)

In a way, Metrocluster provides an overall more simple design at the expense of more infrastructure dollars allowing you to quickly recover AND provide the option for pro-active disaster avoidance.

Going back to the hurricane example, if I have my office in Galveston Texas using metrocluster with the secondary head/shelves in a datacenter in houston on higher ground (hosted for example at level3), I have the option of VMotioning my entire workload to another datacenter when I get notice of a hurricane warning. You could even go so far as to initiate failover prior to the disaster (without bothering to vmotion beforehand) so that if power IS lost then HA will automatically recover the virtual machines at the secondary site.

It also conveniently provides failover from your DR site back to your primary site without having to configure bi-directional snapmirrors and dealing with 2 sets of protection groups with X number of recovery plans on both sides.

SRM has its virtues and is a great tool but availability, flexibility, and agility might drive someone to consider metrocluster, especially if they have the requisite infrastructure in place. If your requirements say "hey my DR site is across the country on a whole other subnet" then SRM is going to be the better tool. In fact, I could think of some "clever' things to do with SRM to help automate pieces/parts of a metrocluster failover solution.

The guranteed RPO of the metroCluster based solution is bound to be better.

I definitely agree about the hybrid approach, it violates my core design principle K.I.S.S.

PowerCLI scripts are pretty easy to write though and very easy to read. I think most enterprise administrators would not have issues automating parts of the BC/DR workflow through scripting even when using SRM.

• site B can't see site A, but can see a tie-breaker, which sees site A => comms problem between B & A => no fail-over
• site B can't see site A & can't see a tie-breaker => likely comms problem between B & A & between B & tie-breaker => no fail-over
• site B can't see site A, but can see a tie-breaker which confirms site A is down => disaster declared => automated fail-over issued