System-Level Fault Tolerance (Clustering/Network Load Balancing) - An MNS Cluster Scenario
(Page 7 of 26 )
An MNS cluster model supports geographically distributed clusters. This means that in a three-node cluster deployment, you can deploy two nodes in Site A and one node in Site B. A spare server will be kept at Site B to join the cluster if necessary. When a single node fails in Site A, the cluster remains up and running because the majority of the nodes are still running, even though they are running in separate sites. If the node in Site B fails, the cluster will remain running on the two nodes at Site A. If a major disaster or power outage is encountered at Site A, the cluster will fail because only one node is running at Site B. To bring the cluster back online, you can restore one of site A's nodes at the Site B location using the spare server. This gives you the two nodes you need to make the three-node MNS cluster operational.
In the same scenario, if you deploy a four-node cluster with two nodes at each site, a single site failure will result in the cluster failing and require an additional server to restore a third and required node. So, if you want to properly plan for a site outage using a four-node MNS cluster, you would need to have a spare server in each location, making the total six servers for a four-node cluster.
MNS is a great choice for geographically distributed clusters, but you must follow these rules to deploy the clusters properly:
The cluster nodes require less than a 500-millisecond response time between the private LAN adapters on each of the cluster nodes.
A VPN must be established between the sites to allow the clustered IP address to fail over across site boundaries while remaining accessible to clients. If the site's LANs are bridged across a WAN, this would also suffice. Also consider having redundant connections between those sites.
MNS can be deployed across only two sites.
Data other than the cluster quorum information does not automatically replicate between cluster nodes and needs to be replicated with software or replicated manually.
MNS clusters represent the future of clustering, and several developments will be made along the way to simplify installations and deployment. Microsoft recommends that MNS clusters be deployed only on hardware supported by the server and storage device vendors for use with geographically distributed MNS clusters.
Choosing Applications for Cluster Service
Many applications can run on Cluster Service, but it is important to choose those applications wisely. Although many can run on MSCS, the application might not be optimized for clustering. Work with the vendor to determine requirements, functionality, and limitations (if any). Other major criteria that should be met to ensure that an application can benefit and adapt to running on a cluster are the following:
Because clustering is IP-based, the cluster application or applications must use an IP-based protocol.
Applications that require access to local databases must have the option of configuring where the data can be stored.
Some applications need to have access to data regardless of which cluster node they are running on. With these types of applications, it is recommended that the data is stored on a shared disk resource that will fail over with the cluster group. If an application will run and store data only on the local system or boot drive, the Majority Node Set cluster configuration, along with a separate file replication mechanism, should be considered.
Client sessions must be able to re-establish connectivity if the application encounters a network disruption.
During the failover process, there is no client connectivity until an application is brought back online. If the client software does not try to reconnect and simply times out when a network connection is broken, this application may not be the best one to cluster.
Those cluster-aware applications meeting all the preceding criteria are usually the best applications to deploy in a cluster configuration. Many services built into Windows Server 2003 can be clustered and will fail over efficiently and properly. If a particular application is not cluster-aware, be sure to investigate all the implications of the application deployment on the Cluster server.
Note - If you're purchasing a third-party software package for MSCS, be sure that both Microsoft and the software manufacturer certify that it will work on a Windows Server 2003 cluster; otherwise, support will be limited when troubleshooting is necessary.
 This chapter is from Microsoft Windows Server 2003 Unleashed, by Rand Morimoto, et al. (Sams Publishing, 2004, ISBN: 0672326671). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Shared Storage Devices >>
More MS SQL Server Articles
More By Sams Publishing
/ 15 
