Building a simple failover cluster with Windows Server 2008 isn't for the faint of heart, even considering Microsoft's new validation features built right into its management interface. Creating a multi-site, geographically-dispersed cluster – often called a GeoCluster – involves a whole new level of challenge.
The first article of this series described the various reasons an IT organization might consider adding clustering to an existing service. Protecting that service against a hardware outage or the effects of the regular patching process are both excellent reasons to implement.
Adding clustering to a critical service significantly reduces the loss of service associated with these types of events. It does not, however, protect the environment from the loss of an entire site. The reason for this lies in the length between the cables that connect each cluster node to its shared storage. Traditional forms of Windows failover clustering require each node to connect to shared storage in a single location. Lose the location, and you've lost the cluster.
Stretched storage
If you want disaster recovery for your clustered services, your solution will be to "stretch" them across two different sites. Doing this involves at a minimum creating two separate but replicated shared storage locations one at each site. The biggest problem here is that Microsoft does not provide the mechanism to do this replication right out of the box. Doing so requires third-party support (Microsoft provides a list of supported vendors here).
Depending on the characteristics of your connection between sites, there are options for how replication works. Storage replication between nodes of a multi-site cluster can leverage block-level replication using storage hardware or file system-level replication using software. The replication can either occur synchronously, where individual changes are
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
');
// -->

acknowledged by nodes before moving to the next change, or asynchronously, which speeds data transfer but adds the risk of data loss in the case of a failure. Each third-party replication tool vendor on Microsoft's website -- Double-Take Software, Neverfail and SteelEye Technology -- offers a different mechanism to accomplish this data replication and Microsoft discusses them all.
New networking
Dealing with the vagaries of storage replication is only your first architectural decision. Connecting clusters across long distances requires a hard look at the network as well. In this space, Microsoft has improved the process somewhat through the addition of two new capabilities:
No matter which quorum model you choose for your cross-site cluster, be careful how you set up dependencies between cluster resources. Since it is likely that cluster addresses can differ across sites, you will need to modify your resource dependencies so they are aware of both sets of addresses.
DNS dependencies
Lastly are the problems associated with clients that are attempting to get to cluster resources. When services are hosted atop a cluster, the cluster itself assumes the naming and addressing required to get to those services over the network. When a client attempts to reach a service, it does so to a clustered network name and IP address. Because that name and IP can be logically located on any of the cluster nodes at any point, the cluster works with DNS to ensure that records are always pointing to the right location.
When considering multi-site clusters, you must also be aware of the impact of DNS resolution at the client. When a cluster resource fails over to an alternate node in a new physical location, DNS must get updated with that new location. If DNS between the two sites does not quickly replicate the change out to all clients, clients will take longer to "find" the relocated service.
There are surprisingly few resources available on the Internet today that provide specific step-by-step instructions for setting up GeoClusters. If you plan to implement one, you'll have to dig deep to find the information you need. The best place to start may actually not be on Microsoft's website, but instead at the sites of third-party vendors that build the necessary replication software.
[TABLE]