Why is multi-subnet failover clustering important?

My network team did not like the way SQL 2008 R2 and previous versions of SQL handled failover clustering.  We were comfortable with setting up active/passive failover clusters and were attempting to place a second node in a disaster recovery site located half a mile or so away from our primary.  By mirroring the SAN storage, we had a good way to set up a simple active/passive failover cluster that would be usable in case of a disaster.

However, previous versions of SQL did not support setting up the second node in a subnet different than the first.  We could still set up a second node in the DR site by extending the subnet between the two physical locations, but this was a work-around -- not ideal according to our network engineers.  It required stretching a V-LAN across locations to expose a single IP address across the two sites.

The key feature that was missing was multi-subnet failover clustering.  With Denali's multi-subnet failover clustering, we can now configure SQL Server failover clusters across multiple sites to create stretch clusters without implementing stretch V-LAN technology.

This is why I am so excited to see this feature in SQL 2012.  In future posts, I will investigate to see if this feature solves our problem.