SQL Server Database Mirroring High-Availability Options
In addition to traditional clustering, the database role can also take advantage of SQL Server database mirroring and log shipping to make mirrored copies of SharePoint databases on another SQL Server instance.
While often used to provide for disaster recovery of SharePoint content, one form of database mirroring, known as synchronous mirroring, can be used for high availability of the databases in a SharePoint farm. In this scenario, SharePoint databases are synchronously mirrored from a principal SQL Server server to a mirror server, while a third server, the witness server, stands by, waiting to fail over the databases to the mirror server in the event of an outage.
Database mirroring is supported in SQL Server 2005 SP1 and greater, including SQL Server 2008. High-protection database mirroring is available with both the Standard and Enterprise editions of SQL Server, whereas the high-performance option is only available with the Enterprise edition. SQL Server database mirroring can be set up in three ways depending on specific needs, available bandwidth between servers, and the SQL Server version used:
High protection—With high protection, all SharePoint databases can be synchronously mirrored to a second SQL Server instance and made available in the event of an outage of the principal server. Failover isn’t automatic with this model, so it’s not a true high-availability solution.
High availability—The only database-mirroring option that provides high availability for SharePoint, this option performs synchronous mirroring and also allows for automatic failover of the databases to the mirror server with the addition of a witness server. This option provides high availability of SharePoint content when used in conjunction with a SQL Server alias configured on the SharePoint servers and is available with SQL Server 2005 Standard and Enterprise editions.
High performance—The high-performance option is available only with SQL Server Enterprise Edition and uses asynchronous mirroring, which doesn’t wait for the data to be written into the mirrored server before it’s committed. While this can result in data loss, it’s the only scenario that’s feasible if the mirrored SQL Server instance is located across a WAN link with high latency or low bandwidth.
The only databases that asynchronous mirroring supports are the SharePoint content databases, which limits this option to a disaster-recovery–only solution. Failover using the high-availability option is handled by the witness server, which automatically senses the failure of the principal server and enables the mirrored versions of the databases. Since SharePoint is not mirroring-aware, the witness server must subsequently act to modify the SQL Server client alias on the SharePoint servers to point them to the new SQL Server location.
The high-availability option can be used for local failover scenarios, where both principal and mirror session are in the same datacenter, or it can be used in remote failover datacenter scenarios, such as what is illustrated in Figure 1, but only if there is very low latency (less than 1 millisecond) and very high bandwidth (1Gb or greater). These scenarios are discussed in more detail in the Microsoft whitepaper "Using database mirroring."
Highly Available Farm Architecture
The smallest SharePoint farm that’s fully highly available (i.e., the loss of any one server doesn’t noticeably affect clients) is a five-server farm composed of the following server roles:
• Server 1—Web/Query/Inbound Email/Central Admin #1
• Server 2—Web/Query/Inbound Email/Central Admin #2
• Server 3—Index
• Server 4—SQL Server Database Cluster Node #1
• Server 5—SQL Server Database Cluster Node #2
Because they’re load-balanced, the web/query servers continue to operate for web requests, inbound email to document libraries, and search queries. The SQL Server environment clustering handles failover of the database role. The index role, as mentioned earlier, can’t be made highly available, but since a failure isn’t visible to the end user it’s not required to be made available.
Server Virtualization Options
Server virtualization technologies can help organizations that can’t deploy five physical servers or want to take advantage of virtualization improvements and cost savings. Microsoft fully supports MOSS running on server virtualization software that has been validated as part of the Server Virtualization Validation Program (SVVP), outlined in detail at the Microsoft support site.
This includes virtual solutions such as Windows Server 2008 Hyper-V, VMware ESX, Citrix XenServer, and many others. That said, certain SharePoint roles such as the database role aren’t the best candidates for virtualization, though with proper attention to disk infrastructure and CPU allocation, all components can be virtualized.
Virtualization provides flexibility in a SharePoint environment, allowing for full high availability to be built for organizations that normally wouldn’t be able to afford it. Figure 2 illustrates a two-virtual host environment.
This environment lets an organization make web/query servers highly available and take advantage of the high-availability mirroring option to provide full failover between virtual hosts. This architecture has the added advantage of letting an organization deploy multiple SharePoint farms, including farms for testing and development.
Virtualization software such as VMware VMotion, Citrix XenMotion, or the soon-to-be released Windows Server 2008 Hyper-V Live Migration let you add an additional high availability layer to a SharePoint environment. They work in similar ways, automatically moving a virtual guest from a failed virtual host to another host, providing for high availability of the server session itself.
Many organizations are adding this additional layer to SharePoint high availability solutions. For more information on virtualizing a SharePoint environment, see Microsoft’s white paper, "Virtualization of Microsoft SharePoint Products and Technologies" [downloadable PDF] and the Windows IT PRO article “Coordinate a Virtualized Environment for SharePoint.”
Third-Party Replication High-Availability Options
Some organizations have enhanced their SharePoint high-availability options by deploying third-party replication solutions that replicate SharePoint documents, lists, and libraries to multiple locations, as Figure 3 shows. By replicating content to these locations and utilizing global load balancers such as Citrix NetScalers, Cisco Content Switches, F5, and others, requests to a single SharePoint FQDN can be directed to a local copy of the content.
When changes are made to the content, the third-party software replicates them to all other farms. If a single farm fails, requests can be automatically referred to another farm within the organization, allowing for instant failover across sites. Multiple third-party vendors providing replication software include AvePoint, CASAHL, echoTechnology, Infonic, Syntergy, and others.
Making SharePoint Bulletproof
It’s not immediately obvious how to make SharePoint architecture highly available, but armed with the proper knowledge of SharePoint role availability and the best practices outlined in this article, SharePoint admins can design a bulletproof SharePoint environment without breaking the bank. Out-of-the-box features such as NLB, clustering, and high-availability mirroring can be combined with other high-availability solutions such as virtualization or third-party replication to meet the Service Level Agreements of any organization.
Related Reading: