In-Depth
Ensuring SharePoint 2010 Availability with Virtualization
Careful consideration and implementation of virtualization technologies can make protecting SharePoint Server 2010 potentially cheaper, but not always easier.
By Bob Roudebush, Vice President of Marketing, Neverfail
With SharePoint 2010, Microsoft created a collaboration platform worthy of addressing multiple markets. Because of Microsoft's reach into the typical enterprise, this platform has experienced rapid growth. When the latest version of SharePoint was unveiled in late 2009, it was already one of the fastest-growing products in Microsoft's history, with more than $1.3 billion in revenue, and it experienced more than 20 percent growth year over year.
Clearly, SharePoint is becoming a critical application within the enterprise with its significant market momentum. Such widespread adoption comes with great responsibility that sits squarely on the shoulders of IT. As organizations grow to depend on SharePoint, ensuring its place within the confines of the organization's business continuity and disaster recovery strategy becomes paramount.
There are a variety of third-party high-availability and disaster-recovery solutions available for SharePoint on the market. Microsoft itself provides a plethora of deployment strategies to assist in ensuring the availability of critical SharePoint services. Within recent years, virtualization's foray into the space with some of its unique business-continuity, high-availability, and disaster-recovery capabilities provides additional options. This, however, only adds confusion for most IT organizations and can result in undue cost and complexity if IT doesn't take the correct approach.
Uptime SLA |
Downtime per Year |
Downtime per Month |
99% |
18.26 days |
36 hours |
99.9% |
8.76 hours |
43.8 minutes |
99.99% |
52.6 minutes |
4.38 minutes |
99.999% |
5.26 minutes |
0.438 minutes |
What Should Companies Look for in Protection?
To understand the considerations for protecting SharePoint, it's important to examine the underlying architecture. Like many modern, multi-tier, Web-based applications, SharePoint consists of multiple tiers of services, including a client/server tier, a middle business logic tier and a back-end database tier.
The SharePoint client/server tier is implemented as one or more Windows-based Web servers that respond to end-user requests. The middle tier consists of one or more SharePoint service applications running on Windows-based servers that provide application services such as search, business data connectivity, and user-profile management. Finally, the back-end database tier is powered by Microsoft SQL Server and is comprised of several databases that store both the configuration for SharePoint itself as well as any contents within the SharePoint farm such as lists and documents.
Which approaches provide the best protection for a complex application with multiple components such as SharePoint? The answer varies by organization and is based almost entirely on the organization's tolerance for downtime, the kind of data and services being provided by SharePoint, and whether that data falls within the scope of any number of industry or government regulations.
For most organizations, if the overall availability requirement for SharePoint is 99 percent or below, traditional backup solutions combined with basic load balancing for front-end Web servers will likely enable them to meet their uptime service-level agreements (SLAs). If the availability of the data within SharePoint is not critical to the business, or the organization can tolerate temporary loss of data, then advanced availability investments also generally aren't warranted.
If the business dictates that SharePoint must have 99.9 percent availability or higher, though, organizations should make additional investments to ensure protection against planned and unplanned downtime. Availability is one of the more expensive requirements for any IT system. The higher the level of availability and the more systems involved, the more complex and costly it will be. Traditionally, these costs have included additional hardware and software along with the operational complexity that comes with technologies such as network load balancing, fault tolerance, shared storage, and clustering. It is for this reason that IT organizations have increasingly looked to virtualization to improve SharePoint's availability.
Protecting SharePoint through Virtualization
One approach is to rely solely on hypervisor capabilities such as hardware independence and encapsulation to achieve higher levels of availability. The entire contents of a workload (including the operating system, application, and data) are encapsulated within one or more virtual disk files that can easily be moved between different physical hosts and restarted with relatively minor effort. This process is manual and requires a diligent backup and recovery regimen, but could potentially meet stringent recovery-time objectives. Though organizations that implement this approach don't benefit from automation of the recovery process, they can potentially save money by reducing the hardware and software costs associated with Microsoft's recommended "scale-out" strategy for SharePoint availability.
A "scale-out" strategy dictates that once IT has met basic capacity requirements (for example, adding front-end Web servers for performance reasons), it should add servers to increase overall availability. Virtualization combined with scaling out makes sense because it allows organizations to consolidate and reduce the physical footprint of the SharePoint environment, thereby reducing costs.
Increasing server redundancy for the client/server tier of SharePoint might include deploying multiple front-end Web servers within a SharePoint farm and using either Windows-based Network Load Balancing (NLB) or a physical or virtual NLB appliance to ensure redundancy. In a virtualized environment, it's also possible to leverage hypervisor-level failover features such as VMware HA or VMware FT (or other similar features on Hyper-V and XenServer) to provide automated availability capabilities for front-end Web servers. In this case, the basic availability features of the virtualization platform help provide automated failover rather than depending on a separate solution solely for load balancing.
Next, IT must deploy multiple application servers to support redundancy for SharePoint application services. In the 2010 release of SharePoint Server, you can install a service application on multiple application servers. You should keep in mind, though, that doing this keeps the service application running but doesn't provide any protection for any session or state data for that application. This isn't an issue for most services that store their data in a database (as long as SQL is protected), but it can become an issue for service applications that store data outside a database such as Access Services and the Excel Services Application.
Finally, there must be some level of availability and protection for the back-end SQL databases in any sound SharePoint "scale-out" strategy. There are a variety of options available, including built-in SQL features such as Microsoft SQL Server failover clustering or Microsoft SQL Server database mirroring. Within a virtual environment, it's sometimes difficult to attempt to install and run Windows Failover Clustering within a VM due to the shared storage requirements and the additional complexity that it introduces, especially in combination with hypervisor availability features like VMware HA or Hyper-V Live Migration. Because of this, SQL Server database mirroring or many third-party, host-based replication and failover technologies are usually more appropriate.
One drawback to the "scale-out" approach is the cost of additional operating system and SharePoint application licenses. Even without the additional cost of licensing for the virtualization platform, this approach might become cost prohibitive, especially for smaller organizations. Adding additional moving parts increases the overall complexity of the environment, and increased system complexity often leads to lower service availability due to operator error (a leading cause of availability issues), increased number and types of system components, and additional configuration and management complexity.
Conclusion
Careful consideration and implementation of virtualization technologies can make protecting SharePoint Server 2010 potentially cheaper, but not always easier. When considering SharePoint availability, the right architecture with the appropriate mix of off-the-shelf and third-party capabilities alongside thoughtful implementation of virtualization technologies will ensure that all critical elements remain highly available and can withstand a variety of failures.
Some organizations may choose to combine OS-level availability features with SharePoint application redundancy; others may opt to deploy advanced high-availability and disaster-recovery solutions from third-party vendors specifically for SharePoint. Before choosing any option, evaluate your business requirements to determine which scenario meets your organization's needs. The option you choose should certainly take into account the cost, complexity, hardware requirements and software licensing considerations we've outlined.
Bob Roudebush is the vice president of marketing for Neverfail, a global software company specializing in continuous availability software for disaster recovery and high availability. Bob can be reached at [email protected]