- Understanding Scalability for SharePoint
- Scaling Logical SharePoint Components
- Utilizing and Understanding Clustering for SharePoint
- Choosing the Right Clustering Technology for SharePoint
- Scaling SQL Server with High Availability Alternatives
- Choosing the Appropriate SQL Server High Availability Alternative
- Scaling Across a SharePoint Farm
- Justifying and Deploying Business Portals
- Addressing Common Business Issues with SharePoint Features
- Deploying a Team Collaboration Solution with SharePoint
- Deploying a Corporate Intranet Solution with SharePoint
- Deploying a Customer Extranet Solution with SharePoint
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Choosing the Right Clustering Technology for SharePoint
For these fault-tolerant clustering technologies to be most effective, administrators must carefully choose which technology and configuration best fits their specific SharePoint needs. NLB is best suited to provide connectivity to stateless SharePoint front-end web servers. This provides scalability, and the amount of redundancy it provides depends on the number of systems in the NLB set. The Windows Server 2003 Cluster Service provides server failover functionality for mission-critical applications such as SharePoint's SQL database servers.
Although Microsoft does not support using both NLB and MSCS on the same server, multitiered applications can take advantage of both technologies by using NLB to load-balance front-end application servers and using MSCS to provide failover capabilities to back-end SQL databases that contain data too large to replicate during the day.
Choosing Microsoft Cluster Service for SharePoint
Microsoft Cluster Service is a clustering technology that provides system-level fault tolerance by using a process called failover. MSCS is used best in SharePoint to provide access to the SQL database server or servers. Applications and network services defined and managed by the cluster, along with cluster hardware including shared disk storage and network cards, are called cluster resources. Cluster Service monitors these resources to ensure proper operation.
When a problem occurs with a cluster resource, Cluster Service attempts to fix the problem before failing the resource completely. The cluster node running the failing resource attempts to restart the resource on the same node first. If the resource cannot be restarted, the cluster fails the resource, takes the cluster group offline, and moves it to another available node, where it can then be restarted.
Several conditions can cause a cluster group to fail over. Failover can occur when an active node in the cluster loses power or network connectivity, or suffers a hardware failure. In addition, when a cluster resource cannot remain available on an active node, the resource's group is moved to an available node, where it can be started. In most cases, the failover process either is noticed by the clients as a short disruption of service or causes no disruption at all.
To avoid unwanted failover, power management should be disabled on each of the cluster nodes in the motherboard BIOS, on the network interface cards, and in the Power applet in the operating system's Control Panel. Power settings that allow a monitor to shut off are okay, but the administrator must make sure that the disks are configured to never go into Standby mode.
Cluster nodes can monitor the status of resources running on their local system, and can keep track of other nodes in the cluster through private network communication messages called heartbeats. Heartbeats determine the status of a node and send updates of cluster configuration changes to the cluster quorum resource.
The quorum resource contains the cluster configuration data necessary to restore a cluster to a working state. Each node in the cluster needs to have access to the quorum resource; otherwise, it will not be able to participate in the cluster. Windows Server 2003 provides three types of quorum resources, one for each cluster configuration model.
Clustering using MSCS is most often used in SharePoint configurations to provide for server redundancy on SQL database servers. By implementing MSCS clustering on SharePoint SQL database servers, the server components themselves become more redundant, but not the actual database itself because it is stored on the shared storage component.
Choosing Network Load Balancing for SharePoint
The second clustering technology available with Windows Server 2003 is NLB. NLB clusters provide high network performance and availability by balancing client requests across several servers. When client load increases, NLB clusters can easily be scaled out by adding more nodes to the cluster to maintain or provide better response time to client requests.
Two great features of NLB are that no proprietary hardware is needed, and an NLB cluster can be configured and running in minutes. NLB clusters can grow to 32 nodes, but if larger cluster farms are necessary, DNS (domain name server) round robin or a third-party solution should be investigated to meet this larger demand.
One important point to remember is that within NLB clusters, each server's configuration must be updated independently. The NLB administrator is responsible for making sure that application configuration and data are kept consistent across each node. Applications such as Microsoft's Application Center can be used to manage content and configuration data among those servers participating in the NLB cluster.
NLB is the mechanism used most commonly in SharePoint to provide for load-balanced access to multiple SharePoint front-end servers. Organizations seeking to scale up SharePoint front-end capabilities should consider use of this technology for an environment.