How to Choose a SharePoint Farm Design

Although SharePoint 2013's social features and the FAST Search Server integration allow for greater scalability, they impose constraints when you're designing a farm. (See "Social feature support in SharePoint Server 2013.")

And there are other constraints (e.g., budgets, operational readiness, network bandwidth) that your SharePoint architecture team must consider too. To help identify those constraints, it's helpful to answer the following questions:

Note that the answers to these questions will likely be revised as the SharePoint architecture team learns more about the SharePoint technology, the organization's technical and business requirements, and those requirements' impact on IT operations.

As I described in "Architecting SharePoint: Building a Solid Foundation for SharePoint Farms," the process is like peeling through the layers of an onion. As you peel through the layers, you learn more, which means you can discuss and document the constraints in a more detailed manner.

Choosing an architectural model requires that you have a solid understanding of your organization's business and technical constraints. An example of a business constraint is the need to house content within countries' borders. An example of a technical constraint is the connectivity between data centers that reside within the countries in question.

The more distributed the farm, the greater the risk of the architecture not working or being an operational nightmare. At some point, common sense needs to take over and governance needs to be leveraged to make the stakeholders aware of the risks.

In any case, you'll likely be able to design a farm that meets most (if not all) of your organization's requirements as well as its constraints. However, meeting the requirements and constraints might mean major changes or additional funding. For example, if an organization has the business constraint of needing to house content within countries' borders, it might mean doing one of the following:

Needless to say, realizing that you require additional large capital expenses, additional staff, new outsourcing contracts, or policy changes late in a project is a major impediment to the perception of success. So, the sooner you find out the constraints, the better. 

Single-Farm Architecture

A single farm consists of a group of servers that are joined together using a tiered model to provide services and content. Specifically, single-farm environments consist of the traditional three-tier SharePoint model farm. According to Microsoft, the three tiers are:

All the services (e.g., search, profile import) and content (e.g., site collections, services, databases) reside within the farm as a logical unit. With a single medium or large farm, you have foundational services and as many content databases, web applications, and site collections as needed. In addition, with SharePoint 2013 and SharePoint 2010, you can add services to meet requirements. For example, if you require Business Connectivity Services, you can activate it on a server with enough capacity. Similarly, if you're reaching the limits of your indexer, you can add another index server.

Figure 1 (courtesy of Microsoft) depicts a single mid-sized farm, including the servers (hosts) and services they provide. This is a virtualized topology showing virtual machine (VM) servers sitting on top of physical hosts.

Figure 1: Single Mid-Sized Farm

You might want to deploy a single farm if one or some of the following conditions apply:

Multi-Farm Architecture

Multi-farm architectures consist of services farms, My Site farms, and content farms. In these farms, only certain functions are implemented or they're used for a specific service (e.g., basic collaboration). With multiple farms, you can provide specific services to the business based on scalability, function, and policy requirements. For example, you could have a central search farm that's consumed by regional collaboration farms. Or you could have a central My Sites (social) farm consumed by all users so that all the social features work.

Figure 2 (courtesy of Microsoft) depicts a multi-farm architecture that includes an enterprise services farm, a My Site farm, and a content farm. Note that SharePoint 2013's social features work best with one My Site farm. If multiple content farms are necessary, you should keep all the My Sites on one farm. Social features don't work across multiple My Site farms.

Figure 2: Multi-Farm Architecture That Includes an Enterprise Services Farm

You might want to deploy multiple farms if one or some of the following conditions apply:

Note that this isn't an exhaustive list. For more information about multi-farm architecture (as well as single farm architecture), see TechNet's Architecture design for SharePoint 2013 IT pros web page.

Decision Scenarios

When deciding whether to use a single-farm or multi-farm architecture, you should keep in mind the reasons for using each type of architecture. Here are some scenarios that walk you through this decision process, the reasons for the decision reached, and some design guidance.

Scenario 1. Suppose that your organization resides in various geographic regions in a country. The drivers for this scenario are the location of the users, network bandwidth and latency constraints, and SLAs.

In this case, you need to decide whether it's more financially and technically effective to deploy multiple farms rather than upgrade the network bandwidth, WAN compression, and cache technology devices, which would be needed if you deployed only one farm. When making this decision, you need to consider that you're going to have at least one more farm to manage if you decide to use a multi-farm architecture. Generally, a mid-sized farm is at least five servers, which means there will be additional costs associated with staffing (i.e., the time and labor needed to administer, monitor, and report on the farm), software licensing, and hardware licensing.

No matter whether you decide on a single centrally located farm or multiple farms, you need to make sure the SLAs will be met. If data center space and resources aren't available, you might consider using SharePoint Online or an IaaS solution. Note that externally hosted environments are subject to your organization's record-management, regional, and data-security policies. In this case, you'd need to work with your legal counsel and records management team. Finally, you should publish standards and practices for this solution for others to follow, which will help with governance.

Scenario 2. Suppose that your organization has offices located in different countries throughout the world. Several of those countries (e.g., Canada, Germany) have laws that companies must meet when the companies' data contains FOIP information regarding their citizens. As a result, the driver for this scenario is the compliance requirement dictated by your organization's legal counsel. This requirement mandates that each country's data must reside in a farm that's located within the borders of that country.

To meet this compliance requirement, you must deploy multiple farms. This means you'll have additional farms to manage and subsequently additional costs, as described in Scenario 1. Using SharePoint Online or an IaaS solution might be an option if the vendor can meet the terms dictated by your legal counsel. You should publish standards and practices for this solution for others to follow.

Note that if your organization doesn't have the funds and resources to deploy and manage multiple farms, you could eliminate the FOIP data from SharePoint so that the compliance requirement is no longer a driver. In addition to removing the existing FOIP data, you'd need to change your SharePoint data policy and implement training programs to avoid the inclusion of FOIP data in the future.

Scenario 3. Suppose that your organization resides in several geographic regions. The organization's financial resources are constrained, but you're still required to deliver a solution that meets the SLAs of each region (which is the driver).

To meet the SLAs, you need to deploy more farms, which means you'll have additional farms to manage and subsequently additional costs, as described in Scenario 1. If you don't have data centers in the areas where the additional farms are needed, you can use governance to escalate the need for data center space and staffing. Your options include allocating new space, leasing space in a third-party data center, using SharePoint Online, or using an IaaS solution. You'll likely need the help of a financial analyst to determine which approach is the best to use, given the capital and operational costs associated with adding more data centers and farms. You should publish standards and practices for this solution for others to follow.

Scenario 4. Suppose that your organization is considering deploying another farm for disaster recovery (DR) purposes. Specifically, your primary farm would fail over to the DR farm in case of failure or disaster. The drivers are meeting the SLAs and addressing audit requirements.

By deploying a DR farm, you'll be able to meet the SLAs and address audit requirements, but you'll have another farm to manage. Besides the time and labor needed to administer, monitor, and report on the additional farm, additional time and labor will be needed to run failover and failback tests, resulting in additional costs.

If your organization has been audited for DR, you should use the auditors' recommendations and guidelines to begin designing the DR farm. The biggest challenge will likely be data replication. There are a few options, such as SAN-level replication, SQL Server 2012 AlwaysOn Availability Groups, or a third-party replication product. So, when designing the DR farm, you'll need to work with your server, storage, and network vendors as well as with Microsoft. Make sure that you have the proper amount of network bandwidth. The DR farm shouldn't saturate the switches, lines, and routers, thereby hurting the performance of neighboring applications.

After you decide on the best farm design, you need to develop processes for building and rebuilding your farms or components in them (e.g., servers, storage) as well as processes for failing over and failing back. You also need to develop comprehensive test procedures that will ensure the DR farm will work properly during a failure. You should test the failover and failback processes annually and after any major changes to the environment. Finally, you should publish standards and practices for this solution for others to follow.

The Next Steps

Once the SharePoint architecture team has chosen the best farm design for your organization, the team needs to decide whether or not to virtualize SharePoint and whether or not to use a hosted solution. I discuss what you need to know to make these decisions as well as how to prove your design with a working model in "Architecting SharePoint: Virtualization and Cloud Decisions."