SharePoint 2010 farms usually consist of multiple SharePoint and SQL Server systems all working together to provide the necessary processing capabilities. Because so many different servers can be involved in a SharePoint farm, the collaboration platform is a prime candidate for server virtualization. SharePoint virtualization can dramatically cut hardware and data center costs, but there are some considerations that should be taken into account prior to virtualizing a SharePoint installation.
The first thing that you need to do is determine whether Microsoft will support your intended virtualization software on the guest server configuration you have in mind. Microsoft’s official support policy for SharePoint Server 2010 embraces the company’s own Hyper-V virtualization technology, as you’d expect, and then states that the collaboration software isn’t supported in other environments unless they are “explicitly referenced” as part of its server virtualization validation program.
That means you can run SharePoint 2010 on Hyper-V without any support problems – but if you’re thinking about using another virtualization platform, you have to check to see if it’s officially supported. Thankfully, Microsoft offers an online support-policy wizard that you can use to do so.
Once you’ve accessed the wizard, choose your SharePoint version from the Product drop-down list on the first screen. The following screen asks you to specify the server virtualization technology that you plan to use, along with your proposed choice of guest operating system and system architecture, as shown in Figure 1. Click Next to find out whether your specified configuration is supported. You’ll notice in Figure 2 that the one I entered isn’t supported; that’s because I selected the 32-bit x86 architecture, and SharePoint 2010 requires a 64-bit operating system. (Click images to enlarge.)
Don’t put your SharePoint virtualization eggs in one basket
Once the support issue is settled, it’s time to move on to the meat of the SharePoint virtualization process. Regardless of whether your virtualized SharePoint deployment will be large or small, it’s important to remember that SharePoint is often considered to be a mission-critical application. Therefore, it’s critical that you avoid configurations that potentially could result in a single point of failure. The following sections discuss how to steer clear of such problems in both large and small organizations.
For smaller companies, hardware and software licensing costs may put fault-tolerant SharePoint configurations based entirely on physical servers out of reach. Such organizations can benefit greatly from virtualizing SharePoint systems: Virtualization platforms enable you to build fault-tolerant clusters at the hypervisor level.
Find out more about SharePoint 2010 collaboration
Read about enterprise SharePoint management strategy
Learn about adding virtualization to SharePoint governance
Find out about backups for SharePoint-related databases
While there are financial costs incurred in the creation of such clusters, there are a couple of important benefits, especially for organizations with limited budgets. First, creating a hypervisor-level cluster means that you don’t have to build a separate cluster for each individual SharePoint application. In addition, hypervisor-level clusters can provide fault-tolerance to applications that normally don’t support true failover clustering, such as domain name system (DNS) services.
That second benefit is particularly important for organizations that are running SharePoint 2010 in the “standalone” deployment mode. Standalone deployments aren’t true SharePoint farms, so you can’t add additional SharePoint servers to them. Likewise, the fact that standalone deployments use an integrated SQL Server Express database installed directly on the SharePoint server means that it’s impossible to take advantage of failover clustering at the SQL Server level. However a hypervisor-level cluster will allow a standalone SharePoint server to failover to a different cluster node in the event of a hardware failure.
Incidentally, Microsoft recommends that organizations needing a single SharePoint server create a single server farm instead of using the standalone deployment option because of the issues discussed above. Standalone deployments usually should be reserved for laboratory and testing environments.
Most large organizations with virtualized data centers already have hypervisor-level clusters in place. Even so, it’s still important to take architecture into account when planning a virtualized SharePoint farm to avoid potential issues with performance and fault tolerance.
Avoiding performance breakdowns on SharePoint virtualization
From a performance perspective, there are two main guidelines you need to follow. First, you must make sure to either balance a host server’s workloads or allocate resources in a way that will prevent one virtual machine from affecting other VMs that are running on the same server.
Workload balancing means pairing high-demand VMs together with lower-demand ones on a host server. For example, if your SQL Server system consumes a lot of CPU time and disk I/O bandwidth, you might put it on a host that runs low-demand services such as DNS or Dynamic Host Configuration Protocol services. Of course, it’s generally better to allocate resources specifically to a virtual machine so that it won’t deprive other VMs of the resources they need. Normally, that means avoiding the use of dynamic memory and not over-committing the host server’s CPU cores. It also means using dedicated storage (and possibly even dedicated network adapters) for high-demand VMs.
The other thing to keep in mind on SharePoint virtualization performance is that you can’t skimp on the system resources you assign to virtual servers. That’s especially true of memory: SharePoint 2010 is a very memory-intensive application, and if you fail to allocate enough to your virtualized SharePoint servers, memory contents that aren’t being used will be written to disk to free up RAM. The process of moving data back and forth between memory and disk, known as paging, will negatively affect VM performance.
When it comes to fault tolerance, the most important thing to remember is that you should spread your VMs around in a way that will ensure that a virtualized SharePoint farm will continue to function even in the event that an entire hypervisor-level server cluster fails.
For example, even if all of your virtual machines are running on top of clustered host servers, you can still create virtualized cluster nodes for your applications. Microsoft’s recommendation for providing fault tolerance to SharePoint application servers is to build a farm with multiple servers, which could be scattered across VMs running within different hypervisor-level clusters.
Generally speaking, creating a virtualized SharePoint environment isn’t really all that different from setting up one based entirely on physical servers. However, you must configure your virtual machines in a way that ensures adequate performance for each server while also providing fault tolerance to protect against system failures. And, of course, don’t forget to make sure that the technology you’re looking to deploy won’t break your SharePoint support contract.
About the author
Brien M. Posey is a seven-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Posey worked as CIO for a national chain of hospitals and health care facilities and as a network administrator for insurance companies and the Department of Defense.