A Cunning First?

I read this: http://www.infostor.com/index/articles/display/0355658971/articles/infostor/backup-and_recovery/disaster-recovery/2010/march-2010/emc-integrates_replication.html today and at first it seems like a great idea but then I got to thinking.

In summary there are APIs that you can leverage in Exchange to replicate the databases from primary to secondary sites - or even within sites if you want - rather than leverage the DAG in the conventional manner. Well, that's great, up to a point.

As you know I work for NetApp and EMC came out with something first so it's bound to be bad, right? Well, sometimes they just package up stuff we do and re-invent it like Microsoft do on occasion (virtualization, OCS to mention but two). But this is genuine and something we don't (yet?) do. Whether we intend to do it in the future is not for this blog or for me to discuss - even if I knew.

The use case here is going to be marginal at best. Why?

1. The Exchange guys are best when their egos are massaged and if you play to that you're far more likely to sell them on the idea of NetApp, performance guarantees, snapshots in the "DR" site, single mail item recovery without major restoration work and getting rid of tape.

2. If you use a 1+1 or 2+1 DAG you can implement Exchange in a manner where DR planning (almost) goes away. That's a great boon to the planners and whilst you might think that improves the case for DAS you should read (1)

3. Everyone is doing virtualization. Yes, everyone. Yes, even the mailbox. If you have a 2+1 DAG you have to disable all client side HA features on the host but that's not a real problem to the VMware guys and frankly, they all seem to like the idea of not having to worry about keeping space somewhere for the DR boxes to run etc. It also allows you to worry far less about DR: see (2) and because you're virtualizing you need a SAN (and there's no better SAN/VMware solution than NetApp due to the multi-protocol capability, dynamic caching (PAM2) and sundy other technologies.

4. If latency is over 25ms or there are no servers at the DR location then I'm in to sell customers SnapMirror (EMC will do the exact same thing so I'm not claiming superiority there (although I am because I am reliably informed that SnapMirror is easier than competing technologies)) because no destination server means a requirement to do Database Portability. This happens a lot more than you might imagine. I can tell you that there are a lot of NetApp systems in 401 North Broad but there are nowhere near as many servers plugged into them as you might think! SnapMirror is a massive market for NetApp.

The API replication technology is certainly great. SAN vendors wanted the technology in there to do the replication but given advances in the last year or so I'm now pretty convinced it's going to be a corner case solution.

So if I was EMC walking into a crowd of ambivalent and pro-Microsoft kool-aided Exchange guys I think that I'd be choosing my battles. I'd let the Exchange guys do their stuff with the DAG. I'd let them have total control about what went where. I'd sell them on the idea of snapshot retention and tape elimination. Why? Because it's worked - to the tune of a half million mailboxes this calendar year alone.

*update*
Dustin mentioned "choice" and I thought a little more. There are going to be times when you're in a 2+1 situation, or rather would like to be, and you find yourself constrained by network capabilities. There is nothing to stop you leveraging normal Exchange replication on-premis and then handing the off-site replication to the array. Obviously I'd like you to use SnapMirror but since this is a pro Exchange and (kinda, sorta) kudos to EMC you can use their new announcement for it.
Either way, the customer gets additional flexibility and can do so much more with the technology at their disposal.