Deze inhoud is niet beschikbaar in uw taal, maar wel in het Engels.

Detailed design and system specification process for a virtual SharePoint 2013 farm

We are in the process of combining the SharePoint Server 2013 and SharePoint Server 2016 content into a single content set. We appreciate your patience while we reorganize things. See the Applies To tag at the top of each article to find out which version of SharePoint an article applies to.


Applies to: SharePoint Foundation 2013, SharePoint Server 2013

Topic Last Modified: 2016-12-16

Summary: Implement a process to create a detailed topology design and system requirements specification for the SharePoint 2013 farm and Hyper-V host computers.

This article contains an example that you can use to create a detailed architecture and system requirements for a virtualized SharePoint 2013 farm. This architecture consists of the virtual machines used for farm server roles, any physical computers that might be used as farm servers, and the virtualization host computers. Your detailed design is a reflection of the duality of a virtual environment and must accommodate the constraints and demands of the virtual machines, virtualization host computers, networking, and storage.

Your detailed design must meet all business and technical criteria (and expectations) for the new SharePoint farm in a production environment. A good design also considers operations support, ongoing maintenance activities, and future upgrades.

In this article:

This article follows accepted best practices to step through the process required to create a detailed farm topology, virtualization architecture, and a system requirements specification for the virtual machines and Windows Server 2008 Hyper-V technology computers. We recommend that you use the approach described in the Identify virtual farm requirements section of Create a virtualization plan for SharePoint 2013 — treat the topology and servers the same way that you would approach designing a farm deployed on a physical platform. Because SharePoint 2013 requirements are technology agnostic, there's no requirement to address virtualization elements until you have enough information to extend the topology and system specifications to the underlying virtual layer. We also recommend that you use an iterative process for creating and refining your design, which starts by identifying mandatory and important requirements, such as availability and performance. This is a frequently used and proven technique for getting the information that is needed to refine and complete a design.

As part of design process, you also have to establish evaluation criteria to determine whether the farm topology and system specifications are acceptable for the first pre-production deployment stage, which is usually a proof-of-concept (POC) or pilot environment.

With regards to performance, this article does not provide detailed information about how to create and run benchmark tests. Guidance for analyzing and interpreting benchmark data is also out of scope.

After you identify your requirements, continue the design and specification process using the following sequence of steps as a guide.

  1. Use the SharePoint 2013 solution and architecture guidance to create a topology that is best suited for the solution that you want to deploy.

  2. Use the draft topology design to identify the number of farm servers that are needed, and document the minimum configuration requirements for each server according to their role. Remember, this a starting point, not the final farm design and configuration specification.

  3. Extend your farm topology to include the virtualization infrastructure. Once again, use published guidance to determine the optimal distribution of farm server roles across virtualization host computers. As part of this step, estimate the resources that each host computer needs in order to support the virtual machines that you plan to deploy on the host.

    The capabilities and limits of the virtualization host computers must be reflected in the architecture.
  4. Continue to refine the topology until you have a design that is suitable to deploy a test farm in a pre-production environment. At the same time that you are refining the topology you can adjust system specifications if you get additional information about configuration requirements for the farm virtual machines or host computers. Unless you have benchmark data from a previous deployment, system specifications are an estimate and any meaningful adjustments will come from your benchmark tests.

The process and guidance in this article focuses on how to install and configure SharePoint products using a Windows Server 2008 Hyper-V technology solution. However, you can apply our strategy to any virtualization solution that the Server Virtualization Validation Program (SVVP) validates. For more information, see the Server Virtualization Program FAQ

This article does not provide detailed information about how to install and configure a virtualization host computer or the virtual machines that are required for a SharePoint products farm. For more information, see Use best practice configurations for the SharePoint 2013 virtual machines and Hyper-V environment.

For this release of the SharePoint 2013, the virtualization changes and features in Windows Server 2012 are not supported.

The following subjects are covered to varying degrees in this article, but detailed information about each subject area is provided in separate articles.

  • Business continuity - High availability and disaster recovery for a virtual environment

  • Security - Best practices for securing Hyper-V virtualization host computers

  • Performance and capacity

  • Maintenance and operations

The starting point in creating a detailed design is to establish, review, and prioritize the functional, technical and operational requirements for SharePoint 2013 and the supporting virtualization infrastructure. You must establish priorities because there will be competing priorities from your stakeholders. There will be significant gaps between the requirements, expectations actually, between different organizational units. For example, users have always expected fast response time whereas the IT security group requires a design that reduces the risk of a system breach.

As you work through the process to identify and prioritize requirements, you must also develop scoring criteria in order to determine when the design is suitable for a farm that you can deploy in a pre-production environment.

There are many approaches and tools that you can use for prioritizing your requirements, and there is no best way or right way for any given scenario. For example, one popular approach to the problem is to categorize requirements as mandatory, very important and so on. Another approach is to use a weighting system or ranking scale to establish priorities. Regardless of the method, choose an approach that enables you to establish credible priorities and apply it consistently as you identify and refine your requirements.

We recommend that you group your requirements into major categories and then subdivide each category in order to provide more details about specific requirements. For example, security is very broad category— detailed information about necessary user permission levels or who should be able to access to farm features or components is very important for understanding, designing and implementing a secure system.

The benefits of compartmentalizing requirements are that you are able focus better on relevant details and it helps reduce the possibility of missing something. However, categories are not isolated. There are always overlaps or dependencies. You must take a holistic design approach that recognizes and incorporates these overlaps and key dependencies.

In this article we use four major categories for grouping design requirements. These categories, in order of priority are as follows:

  • High availability

  • Security

  • Performance

  • Capacity

We recognize the interdependence of performance and capacity but decided to separate these two categories for the convenience of readers.

The first step in designing for high availability is to determine the level of SharePoint availability that your organization must have in order to support the business. Typically, an organization's high availability requirement is defined by the type of business, the degree of globalization, customers, and partners. From an internal perspective, you must document the level of availability needed for the organization as whole in addition to individual business units.

High availability (HA) and disaster recovery (DR) are subsets of a broader Business Continuity Management (BCM) strategy and process. This article focuses on the immediate design elements that are required to put a farm into production. Disaster recovery requirements are very important and are should not be ignored during the architecture design process. We decided to treat disaster recovery as a separate, post deployment activity in order provide more focus and details about DR requirements, best practices, and options.

The next steps are to assess all the farm components to determine their potential effect on availability, review the options for providing highly available components, and then decide which option is the best for your architecture.

Cost is always a factor for organizations. However,, you must weigh these costs against the potential effect of reduced availability on your business.

We recommend that, as a minimum, you evaluate the following farm components from a high availability perspective:

  • SharePoint databases

  • application servers

  • front-end web servers

  • SharePoint services and features such as Search

  • virtual machines used for the farm

  • distribution of farm server roles across virtualization host computers

  • virtualization host computers

  • infrastructure elements such as routers and power load balancers

Virtualization introduces another layer of security that must be addressed. The virtualization host computer provides a single access point to the virtual machines it hosts, which widens the attack surface. In addition, virtual networking presents additional challenges for securing the farm network.

Your organization already has policies, procedures, and tools in place to manage security and authentication for the IT systems and infrastructure. You should secure your virtualization server by using the same measures that you would take to safeguard any server that is running Windows Server 2008 or Windows Server 2008 R2. You must also implement additional measures to help secure the virtual machines, configuration files, and data. For more information about how to help secure Windows Server 2008 workloads, see the Windows Server 2008 Security Guide).

SharePoint 2013 provides new, re-designed, and expanded features and therefore,, farm server performance characteristics and resource requirements differ from the requirements for SharePoint 2010 Products. An in-depth understanding of the changes that are introduced in SharePoint 2013 is necessary for understanding each farm server's resource requirements. Understanding the effect of these changes is especially important in a scenario where you intend to base farm server system specifications on historical data: either usage profiles or performance data. For more information about performance, see Plan for performance and capacity management in SharePoint Server 2013.

Usage data

Historical usage data makes it easier to derive test parameters that you can use for baseline tests. However, when you evaluate this data do so in the context of the new SharePoint 2013 features. Determine how these features might affect user behavior patterns. For example:

  • A typical result of improvements to an existing feature is that more people will use the feature more often and for longer periods.

  • New or extended features have the same effect as improved features, and in some cases, notably when highly requested features weren't available; the increase in SharePoint usage is very significant.

  • A significant increase in the size of the user base, the result of a merger or acquisition for example, will also affect the usage profile.

Changes in use patterns such as the number of concurrent connections or average connection time can have a significant effect on overall system requirements.

Performance data

Performance data provides a measure of how well a server handles the SharePoint workload according to its role in addition to the computer resources (such as CPU usage or memory) used while the system is performing its tasks. (You can also use overall throughput for a group of farm servers as another performance measure.) In order to achieve optimal performance there must enough computer resources that are available to handle the workload. The system requirements specification, excluding software prerequisites, has to identify the configuration for each server in order to handle the load that you expect for the server role. The final configuration is the result of iterative tests (benchmarks) that collect performance data when pre-determined tasks are performed under different loads. Your project team testers compare the benchmark data to the baseline in order to see the effect of load and tasks affect performance. If historical data is available it is easier to create the baseline for performance tests.

Make sure that the performance characteristics of all the re-designed or updated features tested thoroughly and that their effect on overall system performance is understood. Some of these features may not significantly or visibly increase performance demands. However,, the load imposed by a feature may be shifted to different farm server role. Any assumptions you have for a particular role must be validated by conducting new benchmark tests.

If the SharePoint farm is the first deployment in your organization you do not have the option of using historical data as a reference point for establishing a performance baseline. You have to create the baseline using the guidelines and limits provided for SharePoint 2013. Regardless of how you establish your baseline you must run different benchmark tests designed to collect specific data in order to refine your architecture design and system requirements specifications.

Performance testing and analysis for each server role must be combined to create a performance profile for overall farm performance, which makes it easier to identify performance bottlenecks in the farm.

After you determine the capacity requirements of a SharePoint 2013 farm the next step is sizing the farm, its servers and the virtualization infrastructure. The two key areas that farm architects focus on are content storage and farm performance. For more information about capacity, see Capacity management and sizing for SharePoint Server 2013.

SharePoint 2013 is noted for its capability to handle a diverse cross section of content types, ranging from simple text files to large media files. This capability includes, and is not limited to, content creation and editing, sharing for collaboration, short and long term storage, and archiving. From a sizing perspective, your design should be sufficient to handle near term requirements—as the content database grows you can scale up the farm to accommodate this growth.

A farm's ability to consistently meet or exceed the required level of performance is the second important aspect of capacity. Performance capacity is typically defined and evaluated as the kind of load that is put on farm servers compared to a pre-defined set of thresholds. Thresholds are configurable limits that are used to define acceptable loads and also for loads that will put the farm into an unhealthy state when a limit is exceeded. For more information, see Software boundaries and limits for SharePoint 2013.

Performance capacity typically includes content delivery measurements also, such as page load time.

The performance capacity of the farm is determined by the size of the farm, based on the solution(s) it supports, and the characteristics of many farm components. Some examples of these components include the following: the farm servers themselves, network bandwidth and latency, page design, and custom code, to name some.

As is the case with performance, whether this farm is the first SharePoint 2013 deployment for your organization or one already exists shapes your strategy for capacity planning.

A well-defined architecture for a virtual farm, starting from hardware layer up, consists of the virtualization host computers, the network infrastructure, the storage system, and the virtual machines that are part of the SharePoint 2013 environment. (A heterogeneous architecture design includes the physical farm servers.) Use the design illustration that we provide as a guide to set up your own process and criteria for creating a detailed architecture and system specifications. Tailor your approach to reflect your organization’s requirements and also for the requirements of the SharePoint products solution that you plan to deploy in a virtual environment.

Our design strategy uses modeling and iteration to arrive at a virtual farm architecture and system specifications that is ready for live testing.

Modeling is a very useful visualization tool that enables you to see all the components of a SharePoint products farm deployment for your solution. If the model includes system specifications it also enables you to do a check to verify that all the required specifications are identified and documented. Because the model is a small document, it is easy to circulate to stake holders, and easy for the stakeholders to review and provide feedback on.

It’s your choice when it comes to how much detail that you use in a model. The model that we use to show the design process consists of the farm servers, the SharePoint products components that are installed and configured on each server, and the system specifications for each server. We decided not to include SharePoint products processing workflows or the network infrastructure in order to keep the model as simple as possible and still be useful.

The iterative design process is a well-known and proven approach for application and systems design. Iterative design provides several benefits, such as the following:

  • It enables you to identify missing or incorrect information.

  • It makes it easier to identify questionable design elements or system specifications that require more investigation.

The following list of tasks describes the key steps to create, configure and deploy a virtual farm and the supporting infrastructure:

  1. Create an architecture model and system specifications for a farm deployed on physical servers

  2. Use the physical architecture and system specifications as a template to create the preliminary virtual farm architecture and the required supporting physical platform.

    Collect detailed technical reference material (for example, technical white papers, and KB articles) for SharePoint 2013, SQL Server and Hyper-V. Use this information to create a technical knowledge base that you can use as a design tool. This knowledge base is very useful during pre-production testing when the test team has to determine the best way to resolve a performance issue and identify the best solution.
  3. Add the virtualization host computers and their system specifications to the model.

  4. Start the iterative design process. Analyze the architecture model to verify that the model identifies all the elements that are required for the farm solution. Conduct a reasonableness test against each farm server’s the system specifications. Identify and obtain missing or incomplete information so you can use it for adjusting the farm design or specifications.

  5. Refine the architecture based on the result of your analysis and by incorporating new or updated information.

  6. Start another iterative loop: review, revise, review. Continue to evaluate and refine the architecture and specifications until you feel confident that all aspects of the virtual farm meet your criteria to deploy and test the farm in a pre-production environment such as proof-of-concept (POC) or a limited pilot.

  7. Deploy the farm.

Create a model of the physical architecture either by using historical data if it available, or by using the requirements and guidance that is provided for SharePoint 2013. If you use historical data we recommend that you supplement this data with any new information about requirements and updated guidance to that your design covers all the new or updated features.

As a best practice, invest the same time and apply the same rigor that you would use to install and configure SharePoint products on physical servers. This investment pays off when you translate the physical design and system specifications to a virtual environment. It also eliminates unnecessary topology changes and sizing changes to the virtual machines and virtualization host computers.

After you are confident that this model is sound and adequately addresses the requirements for the new farm, you can map the physical view to a virtual environment.

Our example farm

In order to show the process of creating and refining a farm design and system specifications we use a small-medium farm that is configured to use Search. For the sake of clarity we did not include any of the other service applications that you need to consider for your own design.

The following figure shows our example farm deployed on physical computers. This is our starting point for the process of developing a virtual farm architecture and system specifications that are suitable to deploy as a proof-of -concept or pilot farm.

Figure 1. A small-medium size farm deployed on physical computers

Architecture for farm on physical servers
The numbered labels (1X - 6X) in Figure 1 identify farm components or server configurations that have to be investigated.

Use the physical farm topology design and system specifications as a guide for modeling the virtual environment, which includes the Hyper-V host computers.

Ensure that the capabilities and potential limitations of the virtualization host computers are fully understood and are part of your design plan.

Use the following sequence of tasks as a guide for developing your virtual model:

  1. Conduct a final review of the physical model and system specifications to verify that you are basing the virtual model on sound design and sizing.

    Before you transfer specifications from the physical model note any configurations that stand out so you can check the SharePoint 2013 requirements in order to verify configurations or missing information. Using our example, note the following:

    1. Each of the front-end web servers (FE-1, FE-2) is configured to use 24 GB of RAM. At first read, this memory configuration seems high, especially when you compare them to the application servers that host search components.

    2. Two of the application servers (SA-1 and SA-2) are dedicated to hosting search components. The RAM configuration seems reasonable. However, the hard disk capacity for the index might not be sufficient.

    3. The third application server (AP-1) hosts the remaining search components in addition to the other application roles for the farm. There is no provision for high availability.

    4. The AP-1 application server has sufficient memory. However, the hard disk capacity might be insufficient.

    5. The database servers (SQ-1 and SQ-2) lack information about hard disk requirements and the memory configuration seems to be too low.

    6. A requirement for highly available databases is noted, but specific information about the high availability solution is not provided.

  2. Identify the number of virtual machines that are needed and map the role of each virtual machine to the corresponding server in the physical model.

  3. Use the physical server specifications to document the configuration for each virtual machine (number of processors, amount of memory, and disk space). While you’re transferring specifications from the physical model note any configurations that stand out so you can check the SharePoint 2013 requirements in order to verify questionable configurations.

    Remember to verify SQL Server requirements while you are checking the specifications for the servers in the SharePoint 2013 farm.
  4. Determine the distribution of virtual machines on the host computers. Consider the following factors when you are determining how to distribute the virtual machines across the host computers: farm availability requirements, best practice role distribution for optimal performance, the minimum number of host computers, and host capacity (if known.)

  5. Examine the distribution of farm services across the virtualization host computers to see whether any of these services are at risk if a host computer fails.

  6. Use the virtual machine capacity requirements to determine the minimum host computer system specifications (number of cores, memory, local hard disks or network storage).

    Use best practice configurations for the virtual machines and virtualization host computers. For more information, see Use best practice configurations for the SharePoint 2013 virtual machines and Hyper-V environment .
  7. Identify general networking requirements, storage requirements, and power requirements considering these design goals: availability, performance, and capacity.

    As we indicated in the “Choose a design strategy and identify the key tasks” section, we are keeping the model as simple as possible. Therefore networking and storage requirements are not addressed or covered at any level of detail.

  8. Review the architecture and system specifications and identify the uncommitted resources on each of the Hyper-V host computers. Additional host computer capacity determines the extent to which you can scale up virtual machines on a host computer, or if you can scale out the farm by adding a virtual machine to a host computer.

After you finish the first version of the virtual architecture model and system specifications, we recommend that you start the iterative process to refine the architecture and system specifications. The goal is to validate design requirements and any assumptions used to create the design. This process also enables you to review the functional requirements (for the solution and the farm) to verify that there are no changes that have to be considered before refining the model. Finally, if there is new benchmark data or updated product specifications, you can incorporate this information in a revised model.

During the process of analyzing the SharePoint 2013 farm architecture and system specifications it's important to remember that the farm topology and server configurations will change before, and to a degree, after you deploy the farm in the production environment. The extent and degree of change will vary according to the solution, but realize the fact that there will be changes and this should be part of your design review strategy.

The following illustration shows the first draft of our virtual architecture using the topology and system specifications created for the physical farm. The same numbers of farm servers are implemented as virtual machines and are assigned the same roles as the physical servers. The virtual machines are distributed on two Hyper-V host servers. A minimum of two Hyper-V hosts is required in order to be consistent with the high availability design used in the physical model.

The system specifications for the virtual machines and Hyper-V host computers shown in the following diagram are only for illustration, they are not prescriptive.
The virtual machines are configured according to the minimum requirements for each server role, as stated in the Hardware and software requirements for SharePoint 2013 article.

Figure 2. Virtual farm topology with two Hyper-V host computers

Initial architecture for virtualized farm
The numbered labels (1X - 5X) in Figure 2 identify farm components or server configurations that have to be investigated.

Our approach to the design review in this article consists of three phases (or categories), which provides a basic framework for the design. Use the following steps as a guide for developing your own design review process.

  1. Conduct a design review of the virtual farm architecture and supporting physical platform.

  2. Analyze the system specifications for the virtual machines and virtualization host computers.

  3. Review the architecture and system specifications as a single entity.

    Subdivide major review steps or categories as much as is necessary to get the level of detail that you must have to refine the architecture or system specifications.

Virtual and physical architecture design assessment

The virtual architecture implements the availability strategy for specific farm server roles as the physical model. The front-end web server redundancy is retained in addition to the high availability requirement for the databases. Availability is also maintained for the two application servers (SA-1, SA-2) that host search query and search index components.

While the virtual architecture maintains the availability design of the physical architecture, it does not improve availability, which should be part of a virtualization strategy.

The decision to use two host computers and distribute farm server roles across these hosts achieves two things. First, it makes sure that most of the farm servers are not vulnerable to a single point of failure. Second, by distributing roles, it also distributes the workload which contributes to better overall farm performance.

Design flaws

The following aspects of the design must be addressed:

  • The level of redundancy for the front-end servers is suitable for pre-production environments but should be re-evaluated before putting the farm in production. The loss of one front-end web server reduces the farm’s ability to serve content by 50%. There is no high availability option for the virtualization host computers. If HOST-2 failed the farm might continue to function. However, this is not the case if HOST-1 failed.

  • There is no high availability provided for all the application servers. The Search Administration component and Search analytics component on AP-1 are vulnerable because both instances are running on the same Hyper-V host.

  • There is no high availability option for the virtualization host computers. If Host-2-fails the farm will continue to function without a loss of services. However, if Host-1 fails, key services such as crawling the content or analytics processing will not be available.

Virtual machine system specification analysis

The virtual machine system specifications are based on the server configurations in the physical model. After reviewing these specifications there are two configurations that don’t pass our reasonableness test. More information is required for the following servers:

  • The front-end web servers. After rechecking the SharePoint 2013 requirements we reduced the memory configuration to 8 GB, which is the recommended minimum for a system that serves content. Another aspect of the web server configuration is the number of virtual processors—we need to verify that these servers require four virtual processors.

  • The database servers. The memory specification seems low for these servers. However, the model doesn’t provide any information about the expected volume or types of database transactions.

  • Storage is another area that warrants more investigation. For the database servers the only stated required if for the system disk. There is no information about capacity requirements for the other database hard disks.

Hyper-V host computer system specification analysis

The following table (System specifications for the Hyper-V host computers (Host-1 and Host-2) shows an analysis of the virtualization host computers' performance capacity using memory, processor configuration and scalability as criteria.

System specifications for the Hyper-V host computers (Host-1 and Host-2)

Specifications Analysis


Host-1: 96 GB RAM

The total memory requirement is 68 GB (allowing 4 GB for overhead and 64 GB for the virtual machines), which leaves 28 GB of RAM available for scaling up virtual machines or scaling out the farm.

The memory overhead allowance for a Hyper-V virtualization host computer is typically estimated at 2 GB. However,, for a virtualized SharePoint products environment we recommend that you use 4 GB as overhead when calculating memory requirements.

Host-2: 96 GB RAM

The total memory requirement is 48 GB (allowing 4 GB for overhead and 44 GB for the virtual machines), which leaves 48 GB of RAM available for scaling up virtual machines or scaling out the farm.


The virtual to logical CPU ratio is 2:1 on Host-1 and 1.5:1 on Host-2. These ratios are within acceptable limits.

In a virtualized SharePoint products environment, virtual machine memory allocation has a significantly greater effect on performance than an oversubscribed CPU on the virtualization host computer.


Both host computers have sufficient resources to scale up virtual machines or scale out by adding virtual machines.

Hyper-V host computer CPU architecture
Oversubscribing the CPU on the Hyper-V hosts is not a concern. However, it would be useful to know whether the virtualization host CPU architecture supports hyper-threading technology (HT) because this feature does improve performance.

Our review highlights the requirement to obtain more information before we can update the architecture and system specifications. The next step is to obtain information about the following aspects of the farm:

  • Database capacity requirements

    The size of the farm database, the content database in particular, is a determining factor for estimating the number of databases files to use and their distribution on the storage system. Other valuable pieces of information include the following: the types of data that will be stored (documents, media), the pre-dominant database activities (e.g., read, update, etc.), governance, and expected growth requirements.

  • Local and shared storage requirements

    More information is needed to address the storage generally. At this point we don’t know whether all the storage is local or if the intent is to use local and shared network storage. The front-end web servers and the search application (SA-1, SA-2) servers seem to have enough storage for SharePoint products binaries and the Index, but storage requirements for the search components and all the other services on the other application server (AP-1) has to be verified.

    We also have to understand the overall storage strategy in order to determine storage requirements for the virtualization host computers (Host-1, Host-2). Based on the model it seems that only local storage is used, which will affect hard disk layout and virtual machine placement.

  • Virtual hard disk configurations

    Virtual hard disk configurations directly affect host computer storage requirements and configurations. For example, if a host is using local storage, a directly attached physical disk (also known as a pass-through disk) configuration reserves all the hard disk for the virtual machine. Virtual machine hard disk configurations also affect backup and restore options such as SAN snapshots and can affect virtualization host computer high availability configuration.


  • High availability

    We need more information in order to address the lack of high availability for the application servers. High availability is identified as a requirement for the database servers but we need specific details about the solution that will be used (for example, clustering vs. mirroring) because this will affect the architecture and most likely the database system specifications.

Additional changes to the model

The scope of and extent of changes to the architecture and system specifications is determined by the results of the initial design review and analysis of the system specifications.

Your implementation plan can also play a role in the process because it can be used to determine what changes to implement, and also the priority of each change. The following scenarios may not require any changes, especially if there are no significant and quantifiable benefits. For example:

  • The preliminary architecture is suitable for early testing in the proof-of-concept or pilot deployment stages.

  • The virtualization host computers are only for testing and the plan is to replace them for the user acceptance testing. This eliminates the requirement to address scalability or availability issues.

  • The farm is intended to be used for testing or evaluation and it will be decommissioned when these activities are finished.

Consider archiving the virtual machines so you can re-create the farm for future test activities.

After following up on the recommendations and requests for information that were a result of the design and system specification review we can update the model and system specifications.

The following illustration shows a revised model that incorporates the recommended changes in addition to missing information and details. The following illustration shows a revised architecture that is better suited for a production farm.

Figure 3. The revised architecture for the virtual farm

Revised architecture for virtualized farm

Virtual and physical architecture design assessment

The revised virtual and physical architecture implements several changes in response to the concerns that were raised during the previous review. In the revised architecture, we decided to scale out the virtualization host platform instead of scaling up the two hosts in the first model.

The decision to scale out or scale up the virtualization host computers is determined by your organization’s hardware strategy, which is based on factors such as IT standards, business objectives and budget. Both approaches to providing more capacity are valid and there are positive and negative aspects for each scalability choice.

The new architecture is also designed to meet the following objectives:

  • Provide high availability for all the farm servers and increase the level of availability.

  • Improve scalability by enabling scale up or scale up for the farm and its components.

  • Provide more flexibility for moving virtual machines between the Hyper-V hosts in order to re-balance workload if it is necessary and to enable live migration if there is diminished virtual host computer capability because of capacity or a hardware failure.

The following changes meet our objectives:

  • The number of front-end web servers is increased to four for better load balancing and to provide a more availability for that particular farm role.

  • The number of virtualization host computers is increased to four. In addition, the capacity for each of these computers is increased by using the following configurations:

    • CPU: 16 cores plus hyper-threading

    • Memory: 96 GB

  • High availability for the database server is implemented by using SQL Server 2012 AlwaysOn Availability Groups.

    With two more host computers there is enough capacity to dedicate one Hyper-V host (Host-3) to the primary replica (PR) for the AG-1 availability group. The secondary replica (SR) is installed on Host-2, which is also dedicated to running SQL Server 2012. This strategy increases the capacity and performance of the farm database servers. However, the result is under-used virtualization host computers. After increasing the memory on the database virtual machine to 32 GB, there is still 60 GB of unallocated memory. The virtual processor to logical processor ratio is only 1:4, leaving both virtualization host computers significantly undersubscribed.

    We decided to use a database configuration that made better use of the Hyper-V hosts, improved database performance by balancing workload better, and provided more availability. This configuration uses two availability groups (AG-1 and AG-2). The primary replica for AG-2 shares Host-2 with the secondary replica for AG-1 and the secondary replica for AG-2 shares Host-3 with the primary replica for AG-1.

    Another aspect of the revised architecture and system specifications is the decision to use pass-through disks for the database virtual machines. This configuration follows the best practice guidance for configuring hard disks for a virtual machine that is running SQL Server. The recommended Hyper-V disk configuration for database servers is the pass-through disk. Although pass-through disks offer only slightly better performance than fixed size disks, pass-through disks are a better option for large disks and applications that are disk I/O intensive, a well-known characteristic of SharePoint products databases. In addition, pass-through disks eliminate disk contention because other virtual hard disks cannot access the physical disk.

  • Scaling out the virtualization hosts provides more flexibility for virtual machine workload balancing.

  • Using four virtualization host computers provides a good foundation for implementing failover clustering in addition to quick migration and live migration for the virtual machines. For more information, see Understanding Hyper-V and Virtual Machines in the Context of a Cluster (http://technet.microsoft.com/en-us/library/dd759249).

Virtualization host computer system specification analysis

The following table (Revised system specifications for virtualization host computers (Host-1, Host-2, Host-3, Host-4) shows an analysis of the virtualization host computers' performance capacity using memory, processor configuration and scalability as criteria.

Revised system specifications for virtualization host computers (Host-1, Host-2, Host-3, Host-4)

Specifications Analysis


After allowing 4 GB of RAM on each virtualization host computer, the unallocated memory on the Hyper-V host computers is as follows:

  • Host-1: 36 GB

  • Host-2: 28 GB

  • Host-3: 28 GB

  • Host-4: 36 GB

The unallocated memory on all the host computers leaves sufficient capacity for scaling or for live migration.


As a result of the revised architecture the virtual to logical processor ratios are as follows:

  • Host-1: The virtual to logical ratio is 1:1.

  • Host-2: The virtual to logical ratio is 1:2.

  • Host-3: The virtual to logical ratio is 1:2.

  • Host-4: The virtual to logical ratio is 1:1.

These ratios are within acceptable limits.


The revised architecture supports scalability across the farm and for all the farm components.

The changes to the architecture design and system specifications are an improvement over the first model. However, an additional iteration would be necessary in order to:

  • Provide more detailed specifications for the storage strategy (local or shared network) for the database server virtual machines. In order to do this, more information about the volume and type of content that the farm is expected to store is required.

  • Refine the specifications for the front-end web servers. This requires obtaining information about expected use, such as the number of concurrent connections or the average length of connection time.

There are not a mandatory or optimal number of review and revision iterations; continue the cycle until you reach a stage where additional revisions don't significantly improve the design or system specifications. This is the point where you must test the farm in a live environment.

Regardless of your diligence, the reality is that all the architecture and system specifications are theoretical until you deploy the farm in a pre-production test environment and run a series of benchmarks. The number of benchmarks that are needed depend on your hardware strategy. If this strategy is based on over specified requirements then benchmark requirements are reduced.

Weigh the cost and time that is required to conduct extensive benchmarks against the cost of hardware that provides more than the required capacity and performance capability. Depending on your situation, the hardware investment might be a better option.

Benchmarks provide the data that you must have in order to evaluate and then implement good cross-platform changes. The first set of benchmark data enables you to identify the scope, nature and extent of the changes that are required. Typically the first changes that deployment teams consider are as follows (not listed in order of priority):

  • Change the farm topology architecture in order to distribute workloads.

  • Scale up the virtual machines or scale out the farm by adding virtual machines.

  • Scale up the Hyper-V host computers or scale out the hardware platform by adding more host computers.

The deployment team has to determine the priority, potential gain, and effect of these changes. The available data may not be sufficient to make these determinations and therefore, additional benchmarks might be required and you might have to change the benchmarks in order to get the data that that you want.

We recommend that you test the monitoring and reporting strategy (and tools) that you intend to use for the production environment. Testing against pre-production farms enables you have fully operation monitoring and reporting in place when the farm goes into production.

In conclusion, your architecture and system specifications will continue to evolve as you move the pre-production stages and into production. As a best practice we recommend that you continue to run benchmarks until the farm is stabilized in the production environment.