Paul Robichaux commented on Geoclustering in last week's edition of the Exchange and Outlook Update. He points out that it can be quite expensive, but that it can also be a very good (and this is key: Supported/Tested) way to span your Exchange servers across multiple sites to prepare for disaster avoidance.
There was some discussion in the comments area of a previous message on this blog about some alternate ways to do “hotspare”-type disaster recovery environments as a method of avoiding the costs and limitations of geospan clustering. There's still some internal investigations going on about just what non-standard sorts of recovery environments can be supported by Microsoft PSS, so that comment thread isn't really totally dead yet, I suppose.
That said, I'm curious to hear from you in the comments: What sort of geo-clustering or clustered-Exchange disaster-recovery concerns do you have that affect your planning of these scenarios?
About a month ago I implemented an NSI GeoCluster solution for the company i work for. Its basically an Exchange 2003 cluster of 3 nodes spread out through a 30 mile radius. They are all interconnected via a 100GIG fiber backbone, with an OC3 BGP as a backup, along with 3 other failover methods behind that. Needless to say this is a very expensive and elaborate solution. The Exchange Database in itself is a small 10GIGs but the amount of traffic that goes through the servers is quite high on a daily basis. The geocluster solutions has proven to be quite effective in that if an active node becomes unavailable, the failover is a mere 5 seconds. Because the NSI geocluster does not use a single physically shared Database, mantainance ican be done without users experiencing any downtime, well maybe a hickup for a few seconds on outlook.
I've also looked at Evergreen's clustering solution, but my company is totally against having outsourcing our exchange backup services.
We are looking into this as we speak. We need to provide site redundancy for 50,000 mailboxes. We're an EMC customer with SRDF already in place for a database application so this is technology we know. Our concern is the additional I/O latency imposed by a synchronous replication mechanism. We will be testing this in the coming months to see how viable this solution can be.