- 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
Scaling SQL Server with High Availability Alternatives
A high availability solution masks the effects of a hardware or software failure and maintains the availability of applications so that the perceived downtime for users is minimized. If there is a need for uninterrupted operation of an organization's SharePoint databases, it is recommended that the IT professional implementing SharePoint understands the high availability alternatives offered in SQL Server.
With regard to SharePoint, SQL Server 2005 offers three high availability alternatives: log shipping, failover clustering, and database mirroring. Peer-to-peer replication is another SQL high availability alternative; however, it is not applicable to SharePoint. It enables load-balancing and improved availability through scalability based on established transaction replication technology. The SQL Server 2005 high availability alternatives applicable to SharePoint will be described in the sections that follow.
Log Shipping
Log shipping is a recommended solution for creating redundant copies of databases from a source SQL Server to another target SQL Server, as illustrated in Figure 3.3. The normal procedure of log shipping involves the transaction logs being backed up from a source server (primary server), copied across to another target server (secondary server), and finally restored. Previously, log shipping was available only in the Enterprise Edition of SQL Server 2000. However, it is now included with SQL Server 2005 Standard and Enterprise Edition.
Figure 3.3 Understanding log shipping concepts.
To provide high availability for SharePoint mission-critical databases, log shipping is adequate because first, it is inexpensive, and second, it is relatively easy to administer. This is the most cost-effective method available for creating redundant databases compared to significantly higher costs associated with a hardware cluster. Unlike database mirroring, which is limited to a single destination server, when using log shipping, it is possible to configure more than one secondary server for redundancy.
On the other hand, log shipping offers a slower and manual failover process that is not seamless. Therefore, log shipping might not be the best solution for providing an organization with high availability when compared to the Windows clustering and database mirroring approaches. All SharePoint database connections will also have to be manually changed to reflect the name of the new target SQL Server.
Windows 2003 and SQL Server 2005 Clustering
Windows Server 2003 and SQL Server 2005 support the shared-nothing cluster model. In a shared-nothing cluster, each node of the cluster owns and manages its local resources and provides nonsharing data services. In case of a node failure, the disks and services running on the failed node will failover to a surviving node in the cluster. However, with high availability clustering, only one node is managing one particular set of disks and services at any given time.
SQL 2005 on Windows 2003 Enterprise or Windows 2003 Datacenter can support up to eight nodes within a single cluster. Failover clustering of SQL Server 2005 can be configured in two ways: a single-instance failover (Active/Passive) configuration or a multiple-instance failover (Active/Active) configuration.
Single-Instance Failover Configuration
In a SQL Server single-instance failover configuration, illustrated in Figure 3.4, the cluster runs a single instance of SQL Server on all nodes in the cluster. If the main SharePoint SQL Server instance fails on the primary node, the surviving node or nodes will run the same SQL Server instance. In this configuration, all the servers within a cluster share a master database along with a set of SharePoint databases, such as the configuration and content databases.
Figure 3.4 Understanding a single-instance failover configuration.
Multiple-Instance Failover Configuration
In the multiple-instance failover configuration, shown in Figure 3.5, each of the active nodes has its own instance of SQL Server. Each instance of SQL Server includes a separate installation of the full service and can be managed, upgraded, and stopped independently. To apply a multiple-instance failover configuration, at least two instances of SQL Server must be installed on the cluster and each instance should be configured to run on a certain node as its primary server.
Figure 3.5 Multiple-instance failover configuration.
It is then possible to separate SharePoint databases among the instances of SQL Server for scalability purposes. SharePoint databases that regularly refer to each other should be placed on the same SQL Server instance. Before implementing a multiple-instance failover configuration, the expected load on each of the database applications should first be evaluated, followed by a second evaluation to determine whether a single node can handle the combined load in a failover situation. If a single node cannot work, the use of two single-instance failover mode clusters should be considered.
Database Mirroring
Database mirroring is a new high availability alternative introduced in SQL Server 2005. This solution increases database availability by maintaining an up-to-date copy of the source database on a hot standby server in real-time.
Database mirroring consists of two mandatory roles and a third optional role. The first mandatory role is the Principal Server, which contains the source database and is the source of all transactions. The secondary mandatory role is the Mirror Server, which is another server, one that focuses on receiving transactions from the principal server. The Witness Server is the third and optional role, which detects and enables automatic failover between the principal and mirror servers in the event of a failure.
Figure 3.6 Understanding database mirroring.
Mirroring is implemented on a per-database basis and works only with databases that use the full recovery model. The simple and bulk-logged recovery models do not support database mirroring. Database mirroring is supported in SQL Server 2005 Standard Edition and Enterprise Edition.
Database mirroring offers a substantial improvement in availability over the previous high availability alternatives. Implementation is simplistic and it is straightforward to maintain. It is similar to log shipping; however, when a database mirroring session synchronizes, it provides a hot standby server that supports rapid failover with no loss of data from committed transactions. In addition, unlike log shipping, the failover is nearly seamless and client applications can recovery with minor interruption by reconnecting to the mirror server.