SharePoint Farm Configurations

SharePoint Server provides a ton of features and capabilities that are used by many organizations in many different ways. The SharePoint farm should be configured to meet the needs of the business, whether that is a small, medium, or large farm deployment. Regardless of the size of the farm and depending on the needs of the business, configuring the farm following best practices can eliminate a lot of headaches down the road. Because SharePoint 2010 has a services-based architecture, adapting to change and changing configurations has never been easier.

While hardware and software requirements are outside the scope of this book, all the configuration information is based on recommendations from Microsoft at the following link: http://technet.microsoft.com/en-us/library/cc262485.aspx. Determining the configuration of the farm greatly depends on its intended use. If the farm is going to focus on collaboration and content management, more resources should be focused in the web tier, such as having a Network Load Balancer (NLB) to route traffic appropriately and provide redundancy. If the farm is going to be used primarily for business intelligence (BI) purposes, it's important to have additional servers in the application tier as this is where the BI services live. Understanding the business needs and configuring a farm to map to these needs is the key. However, SharePoint is flexible and additional servers can be added and configured without rework.

Limited Deployments

Microsoft defines a limited deployment as an evaluation environment or an environment that is meant to support fewer than 100 users. A limited deployment could include a single server (standalone installation), where all the roles, including SQL Server, reside on the one machine. A potential challenge when using the standalone installation is the use of SQL Server Express 2008 and the limitation of a 4-GB database. SQL Server Express also does not provide a GUI-based management tool, such as SQL Server Management Studio. This is a separate download that is not installed and configured as part of the standalone configuration. This approach also limits the ability to add an additional server down the road if more resources are needed to meet user demand. However, installing SharePoint 2010 on a server that contains a full version of SQL or SQL Server 2005 SP2 or higher, from a SQL perspective, mitigates a lot of the risk encountered when using the standalone configuration. Keep in mind that even if a full SQL Server instance is available, installing SharePoint in the standalone mode will still utilize SQL Server Express. (See Figure 8-1.)

A limited deployment could also include a two-tier farm. A two-server farm is normally considered the minimum when implementing a production environment. This approach would split SQL Server out onto its own server, with the Web and application roles on the other. This approach can support up to 10,000 non-concurrent users, and has the ability to expand if needed to better support future growth. However, keep in mind that all SharePoint web requests and services utilize a single server. Continuous monitoring of the farm and its ability to meet user demand should be performed. If SharePoint becomes a business-critical application within the organization, the farm should be scaled out to support a high availability solution. This farm configuration would include a redundant front end as well as a redundant back end.

Figure 8-1. Limited deployment

It's not uncommon for a successful SharePoint Proof of Concept (POC) to end up as a production SharePoint farm. This is strongly discouraged, because the POC most likely didn't follow best practices during installation and configuration, and doesn't contain the hardware or redundancy to support a production environment. We recommend that a new SharePoint farm be rolled out and the POC farm be either decommissioned or used as a demo or development environment.

Small Farm Topologies

A small farm is a good entry point as it can serve a large number of users and scale out based on utilization of the SharePoint services. This type of topology generally has three to five servers in the farm. This topology typically includes two web servers, which can support 10,000–20,000 non-concurrent users as well as provide redundancy if a Network Load Balancer is routing traffic appropriately. The application layer typically has one to two servers, depending on which SharePoint services are being utilized.

Determining up front how SharePoint is going to be used will help define the farm topology needed. How heavily are the services going to be used? How heavily is search going to be used? How many concurrent users are expected? If the SharePoint farm is going to utilize many of the services, a dedicated application server to host these services is recommended. A SharePoint farm that is utilized heavily for search would include a dedicated server hosting the search databases. This approach would be recommended for those environments with up to 10 million items in the index.

As you can see in Figure 8-2, the key is to understand the needs of the business and build the farm appropriately. The small farm topology provides a great base to build on as the needs of your SharePoint farm increase. The beauty of SharePoint from an architecture perspective—especially in SharePoint 2010 with the introduction of the services vs. the Shared Service Provider—is that it's easy to scale as the use of SharePoint increases.

Figure 8-2. Example small farm

Medium Farm Topologies

A medium farm topology typically has five or more servers, with defined web, application, and data tiers. (See Figure 8-3.) A general rule is that each web server can handle 10,000 non-concurrent users, or 100 concurrent users. However, this will depend greatly upon the client services utilized on these machines. The application tier typically has a dedicated search server, running the Search Query and Site Settings service. Another server, or possibly two, may be present in this layer to run different SharePoint services.

If the business intelligence–related services are going to be utilized, we recommend they be broken out onto a separate server as well. These services would include Excel Calculation Services, PerformancePoint Service, and Visio Graphics Service. The data tier might also include two servers, one for the search databases and the other for all the other SharePoint databases. This approach would be typical in an environment with heavy search utilization.

Figure 8-3. Example medium farm

Much as with the small farm topology, it is important to understand the business needs and configure the farm to exceed those needs. Having already defined web, application, and data tiers, the farm can be upgraded within the appropriate tier based on the needs of the business. Table 8-1 shows all the SharePoint 2010 services that are available and the Microsoft recommendation for which tier in the farm the service should run.

Large Farm Topologies

A large server farm is normally implemented to handle a large amount of web requests, heavy utilization of many of the SharePoint services, with numerous databases in the data tier to support everything in the web and application tier. High availability is also a concern in each tier in these types of configurations. An NLB is used to route traffic between the web servers not only for load balancing, but also in case one web server goes offline, so that the other web server can pick up the requests. Redundancy is also normally present in the application tier. Those services that are heavily utilized or business critical are often load balanced as well. It's also possible that a single server in the farm will host a single service based on user demand.

The data tier will include numerous databases to support the many services being used in the application tier. These databases are normally grouped together based on their purpose and then the groups are broken out onto different SQL Servers. (See Figure 8-4.)

Figure 8-4. Example large farm