- 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
- Best Practices
Utilizing and Understanding Clustering for SharePoint
The operating system for SharePoint—Windows Server 2003—provides two clustering technologies: Network Load Balancing (MSCS). NLB is available on all version of the platform, including the Standard Edition, whereas MSCS is only available on the Enterprise and Datacenter server platforms. Clustering is the grouping of independent server nodes accessed and viewed on the network as a single system. When an application is run from a cluster, the end user can connect to a single cluster node to perform his work, or each request can be handled by multiple nodes in the cluster. In cases where data is read-only, the client may request data and receive the information from all the nodes in the cluster, improving overall performance and response time.
Clustering technologies in Windows Server 2003 can help to scale SharePoint by allowing more resources to assist in the overall environment. For example, multiple network load-balanced SharePoint front-end servers can distribute traffic to a clustered set of SQL database servers, as illustrated in Figure 3.2.
Figure 3.2 NLB-enabled front-end servers and clustered SQL database servers.
The first Windows Server 2003 clustering technology is NLB and is best suited to provide fault tolerance for front-end SharePoint web servers. NLB provides fault tolerance and load balancing by having each server in the cluster individually run the network services or applications, removing any single points of failure.
The second clustering technology Windows Server 2003 provides is Cluster Service, also known as Microsoft Cluster Service or simply MSCS. Cluster Service provides system fault tolerance through a process called failover. When a system fails or is unable to respond to client requests, the clustered services are taken offline and moved from the failed server to another available server, where they are brought online and begin responding to existing and new connections and requests. Cluster Service is best used to provide fault tolerance for file, print, enterprise messaging, and database servers.
Understanding Active/Passive Clustering
Active/passive clustering occurs when one node in the cluster provides clustered services while the other available node or nodes remain online but do not provide services or applications to end users. When the active node fails, the cluster groups previously running on that node fail over to the passive node, causing the node's participation in the cluster to go from passive to active state to begin servicing client requests.
This configuration is usually implemented with database servers that provide access to data that is stored in only one location and is too large to replicate throughout the day. One advantage of Active/Passive mode is that if each node in the cluster has similar hardware specifications, there is no performance loss when a failover occurs. The only real disadvantage of this mode is that the passive node's hardware resources cannot be leveraged during regular daily cluster operation.
Understanding the Active/Active Clustering Mode
Active/active clustering occurs when one instance of an application runs on each node of the cluster. When a failure occurs, two or more instances of the application can run on one cluster node. The advantage of Active/Active mode over Active/Passive mode is that the physical hardware resources on each node are used simultaneously. The major disadvantage of this configuration is that if you are running each node of the cluster at 100% capacity, in the event of a node failure, the remaining active node assumes 100% of the failed node's load, greatly reducing performance. As a result, it is critical to monitor server resources at all times and ensure that each node has enough resources to take over the other node's responsibilities if the other should fail over.