MS SQL Server
  Home arrow MS SQL Server arrow Page 6 - System-Level Fault Tolerance (Clustering/N...
ASP Free Forums 
.NET  
ASP  
ASP Code  
ASP.NET  
ASP.NET Code  
BrainDump  
C#  
Code Examples  
Database  
Database Code  
IIS  
Microsoft Access  
MS SQL Server  
Visual Basic.NET  
Windows Scripting  
Windows Security  
XML  
ASP Web Hosting  
ASP.NET Web Hosting 
Mobile Linux 
App Generation ROI 
Windows Web Hosting
 
IBM® developerWorks 
Sun Developer Network 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
MS SQL SERVER

System-Level Fault Tolerance (Clustering/Network Load Balancing)
By: Sams Publishing
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 15
    2004-09-22

    Table of Contents:
  • System-Level Fault Tolerance (Clustering/Network Load Balancing)
  • Choosing Networking Hardware for Fault Tolerance
  • Examining Windows Server 2003 Clustering Technologies
  • Active and Passive Clustering Modes
  • Choosing the Right Clustering Technology
  • Implementing Cluster Service
  • An MNS Cluster Scenario
  • Shared Storage Devices
  • Installing Cluster Service
  • Installing the First Node in the Cluster
  • Adding Additional Nodes to a Cluster
  • Cluster Group Failover Configuration
  • Testing Clusters
  • Maintaining Cluster Nodes
  • Creating Additional Cluster Groups and Resources
  • Removing a Node from a Cluster
  • Cluster Node Backup Best Practices
  • Backing Up the Cluster Node System State
  • Restoring a Single-Node Cluster When the Cluster Service Fails
  • Restoring a Single Node After a Complete Server Failure
  • Restoring an Entire Cluster to a Previous State
  • Restoring Cluster Nodes After a Cluster Failure
  • Installing Network Load Balancing Clusters
  • Using the Network Load Balancing Manager to Create a Cluster
  • Managing NLB Clusters
  • Summary and Best Practices

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    System-Level Fault Tolerance (Clustering/Network Load Balancing) - Implementing Cluster Service


    (Page 6 of 26 )

    After an organization decides to cluster an application or service using Cluster Service, it must then decide which cluster configuration model best suits its needs.

    MSCS can be deployed in three different configuration models that will accommodate most deployment scenarios and requirements. The three configuration models include the single-quorum device cluster, single-node cluster, and the majority node set cluster. The typical and most common cluster deployments are configured using the single-quorum device cluster.

    The Single-Quorum Device Cluster

    The single-quorum device cluster configuration model is composed of two or more server nodes that are all connected to a shared storage device. In this model, only one copy of the quorum data is maintained and is housed on the shared storage device, as shown in Figure 31.1. All cluster nodes have access to the quorum data, but the quorum disk resource runs only on one node of the cluster at a time.

     Morimoto

    Figure 31.1 Two-node single-quorum device cluster.

    This configuration model is best suited for applications and services that provide access to large amounts of mission-critical data and require high availability. When the cluster encounters a problem on a cluster group containing a shared storage disk resource, the cluster group is failed over to the next node and made available with almost no disruption. When the cluster group is back online, all the data is once again available after a short disruption in service. Typical services deployed using this cluster configuration model include file, messaging, and database servers.

    The Single-Node Cluster

    The single-node cluster configuration model was created to serve many purposes. First, a single-node cluster can run solely on local disks, but it can also use shared storage. When creating a single-quorum cluster, the administrator must first create a single-node cluster but with a shared disk quorum. The single-node cluster can also use the local quorum resource, which is usually located on internal disk storage. The local quorum resource is a great benefit for cluster application development because only a single server with internal disk storage is needed to test cluster applications.

    One last point to add about this model is that because there is only one node, the cluster will not use or provide failover. If the single node is down, all the cluster groups are unavailable.

    The Majority Node Set Cluster

    The Majority Node Set (MNS) cluster is the third configuration model and represents the future of clustering, as shown in Figure 31.2. MNS can use shared storage devices, but this capability is not a requirement. In an MNS cluster, each node maintains a local copy of the quorum device data in a specific Majority Node Set resource. Windows Server 2003 Enterprise supports up to four nodes per cluster, and Datacenter supports up to eight nodes. Because each node maintains a local copy of the quorum and a shared storage device is not necessary, MNS clusters can be deployed across a WAN in a geographically distributed environment. Windows Server 2003 supports up to two separate sites for MNS, and because the cluster IP will need to fail over across sites, the sites either need to be bridged or a virtual private network (VPN). Another viable option is having Network Address Translation (NAT) installed and configured for failover for proper IP recovery to occur. The latency between the cluster nodes for private communication must not exceed 500 milliseconds; otherwise, the cluster can go into a failed state.

    Morimoto

    Figure 31.2 Two-site, four-node Majority Node Set cluster.

    An MNS cluster will remain up and running as long as the majority of the nodes in the cluster are available. In other words, to remain operational, more than half of the nodes must be up and running. For instance, in a four-node cluster, three nodes must remain available, or the cluster will fail. If an administrator configures a three-node cluster, two nodes must remain up and running. Both the three-node and four-node clusters can tolerate only a single node failure.

    If you are considering or requiring availability provided by MNS, it is recommended to always purchase at least one additional node when planning for an MNS cluster. This node can be used in the lab for application testing, including testing patches and application updates, or it can be configured in a cold-standby state that can be added to a cluster when a single node fails.

    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.

    More MS SQL Server Articles
    More By Sams Publishing


     

    MS SQL SERVER ARTICLES

    - Completing the Introduction to Transact-SQL
    - A Brief Introduction to Transact-SQL
    - Lookups and Blocking Bad Data
    - Field Validation Rules for Blocking Bad Data
    - Using Masks to Block Bad Data
    - Blocking Bad Data
    - Using @@ROWCOUNT and TABLE Variables for Dat...
    - How to Use Variables, IF and CASE in Databas...
    - Creating Important Aspects of Notification S...
    - Working wth Variables in Database Interactio...
    - Delving Deeper into Notification Services
    - Notification Services
    - Building a Multi-table Report with SQL 2005 ...
    - A Secure Way of Building Connection Strings
    - Transferring a Database Using the SSIS Desig...





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 5 hosted by Hostway
    Stay green...Green IT