Plan virtual architectures (SharePoint Server 2010)

Article
07/22/2014

Applies to: SharePoint Server 2010

This article discusses key considerations for planning virtual architectures by using Microsoft SharePoint Server 2010 server roles. This article does not include performance or capacity planning data or recommendations. It describes general guidance for planning virtual environments and includes example architectures for small, medium, and large size farms.

In this article:

Virtual versus physical architectures
Example virtual architectures for small to medium size farms
Example virtual architectures for medium to large size farms

Virtual versus physical architectures

Typically, an organization considers a move to virtual architectures because it wants to reduce the number of servers that are required to host a solution, to more efficiently use existing hardware, or to save energy and space. The ability to automate server deployment is also a primary motivation to deploy a virtual server environment.

Virtualizing Web servers and application servers

The Web server and application server roles are good candidates for virtualization. When you plan a virtual environment, a reasonable approach is to apply topology, performance, and capacity guidance to plan the physical environment, and then use the resulting number of Web servers and application servers — including specific application server roles — as a starting point for the virtual environment.

In a virtual environment; however, more virtual servers might be required to provide the same level of service and performance during peak times as are provided by physical servers. The results will depend on the specific services and the usage patterns of these services.

That said, running in a virtual environment provides the flexibility of re-allocating resources across virtual machines as necessary to tune performance. You can also more easily add and remove virtual servers to address spikes in usage of specific services that occur at predictable times throughout a year.

Virtualizing SQL Server

The question of whether to virtualize Microsoft SQL Server is debatable and depends on the overall goals of a deployment. A virtual SQL Server environment typically performs slower than a physical environment, although performance is improving as new versions are released. By using the most recent version of the Hyper-V role (included in Windows Server 2008 R2), SQL Server performance tests indicate that the same throughput (compared to a physical server) can be achieved in a guest virtual machine at a cost of slightly increased CPU usage.

There are other things to consider before you plan to virtualize SQL Server, such as the number of CPU cores required by SQL Server, the failover and availability plan, and the options for optimizing storage. Regardless, the benefits of deploying SQL Server to a virtual environment might outweigh the performance cost. For example, virtualizing SQL Server might be useful in a temporary or transitional solution, for example when combining multiple farms into an enterprise farm and retiring hardware. Organizations that make the most of limited hardware will gain the most by deploying SQL Server to physical servers. The examples in this article include environments that take both approaches.

For more information, see Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Recommendations (https://go.microsoft.com/fwlink/p/?LinkID=134106).

Virtualizing other servers in the environment

SharePoint 2010 Products solutions rely on other servers in the environment. This section provides general guidance on factoring these into a virtual architecture.

Active Directory

We recommend that — at a minimum — the root domain controller for an Active Directory directory services environment be hosted on a physical server outside of virtual environments. If needed, additional domain controllers can be deployed as virtual servers.

For more information about how to deploy Active Directory to virtual environments, see the following resources:

Gateway products

Gateway products include the following:

Microsoft Forefront Unified Access Gateway (UAG)
Microsoft Forefront Threat Management Gateway (TMG)

For high availability, we recommend that you position these products outside the SharePoint 2010 Products virtual environment. For more information about how to set up virtual environments for these gateway products, refer to the product documentation.

Testing side by side

If you are concerned about how deploying SharePoint 2010 Products server roles in a virtual environment might affect performance, consider testing the specific roles that you plan to deploy. You can use the results to decide how many virtual servers to deploy for a specific role, or even whether to deploy a specific role to the virtual environment. For example, if your farm will crawl lots of content, the results of your tests might lead you to deploy the crawl role to a dedicated physical server.

One way to test a virtual environment is to deploy a specific role both virtually and physically, and compare benchmark data for network, memory, disk, and CPU. The following illustration provides an example of how to test specific server roles by using a limited number of servers.

Rotate roles for side-by-side testing

In this illustration, specific roles are deployed to the virtual environment. A physical test server is set up to test each role, one at a time, so that side-by-side benchmark data can be collected. Be sure to account for differences between the physical and virtual environments that will affect test results, such as different hardware specifications.

If you have an existing farm, you can add a virtual host and swap in virtual machines that have equivalent roles to see how the virtual performance for each role is affected. You can also see how different combinations of roles affect the overall performance of the farm. The following example illustrates this idea.

Swap roles in and out of the virtual environment

Example virtual architectures for small to medium size farms

The starting point for replacing a physical farm by using a virtual farm is to use two to four physical host servers. For each host, the number of servers that can be deployed is dictated by available memory, CPU, disk, and network resources.

The following two illustrations provide example deployments in which the Web server and application server roles are deployed to a virtual environment.

Use fewer virtual machines for proof of concept

In this example, be aware of the following:

The minimum resources for CPUs and RAM represent starting points for the farm. Because only two cores are reserved for each virtual image, this example is only appropriate for proof-of-concept or development environments in which performance is not an issue. Reserve enough spare resources to reallocate based on performance monitoring.
SQL Server is deployed to physical servers, instead of to virtual servers.
Web servers and application servers are redundant across the two host servers.
Three Web servers are deployed to the virtual environment for high availability.
The Active Directory domain controllers are deployed to physical servers.

For pilot testing and production environments, four cores is the minimum recommended starting point for virtual machines. The following virtual environment uses fewer virtual machines to achieve this objective.

Use fewer virtual machines for a pilot environment

This example represents a starting-point environment. You might have to add resources, depending on the usage pattern of the farm.

Example virtual architectures for medium to large size farms

By using larger host servers, you can allocate more resources to virtual images. The following illustration provides an example implementation that uses more CPUs and RAM.

Using more CPUs and RAM

If the benefits of virtualizing SQL Server outweigh the performance tradeoffs, SQL Server can be deployed as a guest also, as shown in the following illustration.

Deplyoying SQL Server as a guest

In this example, be aware of the following:

Only one instance of SQL Server is deployed to each host. In small and medium size virtual environments, we recommend that you do not deploy more than one SQL Server guest per host.
Both host servers include more memory to accommodate the number of virtual servers, including SQL Server.

If a particular server role consumes so many resources that it adversely affects the overall performance of the virtual environment, consider dedicating a physical server to this role. Depending on the usage patterns of an organization, these roles might include crawl servers, the server that imports profiles, Excel Services Application, or other services that are used heavily. The following illustration provides an example.

Dedicate a physical server to a role

In this example:

SQL Server is deployed to physical servers. Remove SQL Server from the virtual environment before you remove application server roles.
The crawl role is deployed to a physical server. In some environments, a different role might be a candidate for deploying to a physical server, depending on usage.