Overview of farm virtualization and architectures for SharePoint 2013
Applies to: SharePoint Foundation 2013, SharePoint Server 2013
Topic Last Modified: 2013-12-18
Summary: Determine a high level architectural configuration for a virtual SharePoint 2013 farm that is based on your business requirements and available options.
This article discusses the key design considerations and options for a virtual architecture that can support your SharePoint 2013 farm. This article includes examples of architectures for small, medium, and large farms.
Regardless of the reasons for virtualizing SharePoint 2013 or the stage of adopting virtualization, the design of a virtual SharePoint 2013 architecture has to support your long term and immediate business and IT goals and accommodate future changes.
Architects who plan a virtual environment often apply the requirements for a SharePoint solution that was deployed in a physical environment to the virtual environment. This includes elements such as farm topology, capacity and performance requirements, and business continuity. You can use the number of database servers, front end web servers, and application servers — including specific application server roles — to determine the number of virtual machines and virtualization host server computers that a virtualized farm requires.
|A virtual environment requires additional virtual servers to achieve the same overall performance as physical servers that serve the same roles. This is a reality of virtualization. Because of hypervisor overhead, a virtual machine that is configured the same as a physical computer (for example, same number of processors, same amount of memory, and same hard disk configuration) cannot match the performance of a physical computer.|
This article does not include prescriptive guidance for server size and performance, availability, or growth. It describes the key considerations and general guidance to help you plan a preliminary, high-level architecture that you can use to develop a detailed architecture design. Prescriptive guidance and topology analysis is in Detailed design and system specification process for a virtual SharePoint 2013 farm.
Before you design a virtual architecture and the supporting infrastructure, you have to identify system requirements. In many instances, you can use an existing or planned SharePoint solution, and the physical infrastructure that supports the solution.
Whether SharePoint Server or SharePoint Foundation is already deployed can affect the process of determining requirements and making design decisions. The current state of virtualization technology in an organization is another factor.
If you have an existing SharePoint farm, you can use historical benchmark data and usage profiles as a starting point to determine virtual machine configurations for the different server roles in the farm. For example, concurrent connections, types of requests, and peaks in demand are useful types of data. After you have the virtual machine requirements, you then determine the number and capacity of the host servers that you require to support the virtual farm servers.
If you are upgrading an existing farm, remember that you have to have new benchmark data to validate your assumptions. This is a requirement because customers typically clean up and architect their SharePoint solutions again as part of the upgrade, which we recommend. Another reason to collect new data is that you might add functionality to the farm. SharePoint 2013 also provides new features and redesigned features, such as Search.
For new deployments, you have to base your starting requirements on the SharePoint 2013 planning, design, and sizing documents that are available in the Microsoft TechNet Library. After that you have to test, resize, and retest until you feel comfortable with your farm design.
If virtualization is a mature technology in your organization then you have the experience and resources to develop fairly accurate picture of the physical infrastructure requirements for the farm. This includes host sizing, virtual machine distribution across the hosts to meet expected performance demands, and high availability.
If your organization is just starting to adopt virtualization for applications such as SharePoint 2013, then you probably have a shortage of resources and expertise to implement a virtual farm. You would have to plan and complete several pre-production phases to collect benchmark data and tune configurations until they are ready for a pilot project.
It is important to remember that at this point your requirements and proposed design are preliminary. You will have to adjust the design as you develop a detailed design to deploy a farm in a proof-of-concept (optional), pre-production (pilot), and production environment.
Identifying the server roles that you want to virtualize is related to the broader virtualization goals and objectives of your organization. Clearly, if the goal is implement an architecture where all the SharePoint farm servers are virtual, then the pros and cons of server selection is not an issue. In a homogeneous environment, the criteria for the design of the architecture are based on operational requirements such as performance and capacity and the host infrastructure that is needed to support the farm.
Although server virtualization is fully supported for all the server roles of SharePoint 2013, the server role alone is not the determining factor in deciding whether to virtualize some farm servers or all of the farm servers. Several factors will affect your virtualization strategy and architecture: IT constraints, host server capacity, and operations.
Many organizations do not support or allow IT departments to virtualize database servers. This policy is typical in organizations that have dedicated database teams that tightly manage and maintain SQL Server. In these controlled deployments, the database team has to create all databases. Virtualizing SQL Server is not an option.
Host server capacity
The availability of host hardware than can adequately support the requirements of all the roles is something else to consider. For example, the CPU and memory requirements of a virtual database server are greater than a web server or application server. The issue of host hardware capabilities happens when you re-purposing existing hardware as part of a virtualization strategy.
Managing and maintaining a virtual farm environment is complex and requires specific skills and tools. You have to manage the farm on the virtual level and the physical host level. If you deploy SharePoint 2013 in a partly virtualized environment, you have to deal with the virtual machines and their hosts. Additionally you have to maintain the physical computers that are used for specific roles. The result is that you must have three sets of skills, tools, and procedures to support the farm. Full virtualization reduces the support requirements and simplifies support for the operations team.
If there aren't any constraints about virtualizing specific server roles, and you don't know whether to virtualize some or all of the servers, the next step is to review all of the server roles and decide which ones to virtualize.
The front end web server and application server roles are usually the first choices for virtualization.
The web server role is usually the first choice for virtualization because the workload demand on these servers is usually much lower than on other servers in a farm. As a result you can configure the virtual machine for this role to use fewer processors, less memory and fewer (and smaller) hard disks. The smaller resource footprint means that you can deploy more front end web servers on a single host than a highly specialized and resource-intensive system such as a database server, and in some cases, an application server. For organizations that are just starting to move to virtualization, virtual machines for the Web server role are easier to plan for than the other roles, have the lowest virtualization host requirements, and are perceived as having the lowest risk in a production environment
Application servers are also good initial candidates for virtualization. Depending on the degree of specialization, which is reflected by services they provide, they do not always have low resource requirements. A good example is an application server that hosts the search crawl component.
IT professionals vigorously debate whether to virtualize SQL Server. Until recently the conventional wisdom was to avoid virtualizing the database server. As is the case for other farm servers, hypervisor imposes a performance cost. You have to define your performance goals and collect benchmark data before you decide whether to virtualize SQL Server. Even with SQL Server optimizations for virtualization and performance improvements in the Windows Server 2008 R2 Hyper-V role, a virtual database server will not outperform a physical server that uses the same configuration. However, if you scale up the virtual database server configuration, you can achieve the same overall throughput at a slightly increased CPU usage cost.
We recommend that your database virtualization decision also accounts for virtual processor requirements in relation to the number of host server cores, high availability, and options for optimizing storage. In the final analysis, the benefits of deploying SQL Server on a virtual machine can often outweigh the performance cost.
For more information, see Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Recommendations.
SharePoint 2013 solutions usually rely on other servers in the IT environment. This section provides general guidance about how to factor these dependencies into your virtual architecture.
We recommend that you host the root domain controller for an Active Directory Domain Services (AD DS) environment on a physical server outside the virtual environment. If needed, you can deploy additional domain controllers as virtual servers.
For more information about how to deploy AD DS in a virtual environment, see the following resources:
Gateway products for SharePoint 2013 include the following:
Forefront Unified Access Gateway 2010 (UAG) delivers comprehensive, secure remote access to corporate resources for employees, partners, and vendors on both managed and unmanaged PCs and mobile devices.
Forefront Threat Management Gateway 2010 (TMG) is a secure web gateway that provides comprehensive protection against web-based threats by integrating multiple layers of protections into a unified solution.
For high availability, we recommend that you position these products outside the SharePoint 2013 virtual environment. For more information about how to set up virtual environments for these gateway products, refer to the product documentation.
After you've collected information and created a draft design, you still may have concerns about performance if specific SharePoint 2013 server roles are virtualized. If performance is still a major factor in completing your architecture, then consider testing specific roles that are candidates for virtualization. You can use the test results to decide how many virtual servers to deploy for a specific role, or even whether to deploy a specific role in the virtual environment. For example, if your farm crawls a high volume of content, the results of your tests may indicate that you should leave the crawl role on a physical server or install the role several virtual machines.
One way to conduct your tests is to deploy a specific role on a virtual machine and on a physical computer. The tests that you use are very important because they have to adequately measure the role. For example, tests that measure the number of requests and types of content that is served are meaningful for a front end web server but not for an application server that is dedicated to crawling content. After you finish your tests compare the benchmark data for the performance counters that are meaningful as a performance measure. These counters are typically one or more of the following: memory consumption, CPU utilization and Input/Output Operations Per Second (IOPS). For some scenarios network throughput is also an important performance indicator. The following illustration provides an example of how to test specific server roles by using a limited number of servers.
How to test specific server roles
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 you can collect side-by-side benchmark data. Be sure to account for the differences between the physical and virtual environments that might 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 shows this idea.
How to swap roles in the physical and virtual environments
To start to use a virtual farm to replace a physical farm, use two to four physical host servers. For each host, available memory, CPU, disk, and network resources dictate the number of servers that you can be deploy.
The following two illustrations provide example deployments in which the web server and application server roles are deployed to a virtual environment.
Web server and application server roles in a proof-of-concept virtual environment
In the previous example, you should be aware of the following:
The minimum resources for CPUs and RAM are 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 AD DS domain controllers are deployed to physical servers.
For pilot testing and production environments, four cores are the minimum recommended starting point for virtual machines. The following virtual environment uses fewer virtual machines to achieve this objective.
Web server and application server roles in a pilot testing virtual environment
This example represents a starting-point environment. You might have to add resources, depending on the usage pattern of the farm.
You can allocate more resources to virtual images if you use larger host servers. The following illustration provides an example implementation that uses more CPUs and RAM.
Web server and application server roles with increased RAM and more CPUs in a virtual environment
If the benefits of virtualizing SQL Server outweigh the performance tradeoffs, you can deploy SQL Server as a guest also, as shown in the following illustration.
SQL Server deployed in a virtual environment
In the previous example, you should 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.
Use a physical server for a role to improve performance
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 to deploy to a physical server, depending on usage.