This section covers available topologies, Microsoft-approved assumptions, server roles, and a simplified scenario that provides you with an example of how you could scale out a farm.
SharePoint 2010 topologies can be broken into a limited deployment farm, small farm, medium farm, and large farm. These topologies allow SharePoint 2010 to be deployed on a single server or on many servers. SharePoint 2010 is designed to be scaled out using a three-tier system for its server roles, using server groups to build out your farm.
This section does not cover the large farm topology. A large farm is just a medium farm topology in which Search functionality is in a separate farm and the remaining servers are grouped by function.
Topologies and scaling are closely associated: you must understand your topology to be able to scale efficiently and accommodate different scenarios and organizational requirements. The following are some best practices to use when scaling out your farms.
- Limited deployments are up to 10,000 users (single box and 2 tier)
- Small farms.
b) Break out the application server due to moderate user usage.
c) Break out Search databases if optimizing for Search.
d) Search used for up to 10 million documents.
- Medium farms
b) Break out application servers due to services using resources disproportionately. Examples might include Dedicated Excel Services or PowerPoint Services boxes.
c) Break out and combine query and crawl functions on a dedicated server and add a redundant query and crawl server.
d) Break out Search databases if optimizing for Search and add redundant SQL boxes for Search.
e) Search used for up to 40 million documents.
- Large farms
b) Group servers by function.
As part of managing a server farm, you need to understand the basic roles that various servers perform in your farm. The following sections introduce you to the roles of the Web server, application servers, and database servers.
1.1. Web Server
A Web server is used to host Web pages, Web services, and Web Parts that are necessary to process requests served by the farm. A Web server directs requests to the appropriate application server. This is a necessary role for farms that include other SharePoint 2010 capabilities. In dedicated search service farms, this role is not necessary, because Web servers at remote farms contact query servers directly. In small farms, this role can be shared on a server with the query role.
When working with SharePoint, users connect only to the Web server—they do not connect directly to an application or database server. This is why the Web server is the most heavily utilized server in your farm. Client calls go in and out of the Web server, and that can represent a significant load during peak usage.
1.2. Application Server
Application server roles are associated with services that can be deployed to a physical computer. Each service represents a separate application service that can potentially reside on a dedicated application server. You can group services with similar usage and performance characteristics on a server, and you can scale out services onto multiple servers together. For example, client-related services can be combined into a service group. After deployment, look for services that consume a disproportionate amount of resources and consider placing these services on dedicated hardware when you decide to scale out your services and farms.
1.3. Database Server
In a small-farm environment, all databases can be deployed to a single server. In larger environments, group databases by roles and deploy these to multiple database servers. You might want to group and scale out Search and content databases to their own servers starting as early as the small farm, depending on usage requirements.
2. Scaling Out a Farm with Server Groups
The number of services and corresponding databases in SharePoint 2010 is greater than in the previous SharePoint Server 2007 releases. The recommendation for scaling out a farm is to group services or databases with similar performance characteristics onto dedicated servers and then scale out the servers as a group. This group is not enforced in the SharePoint Central Administration interface but instead is a logical group that you create on paper as you build out your farm.
For example, group all Search-related services onto one or two servers and then add servers to this group as needed to satisfy user demand for these services. In some cases, you might need to create a dedicated server group for a single service, such as Search or PerformancePoint services.
Combine service applications and related components (for example, databases) into several different logical groupings that can be used as a starting point; for scaling in large environments, the specific server group that evolves for a farm depends on the specific demands for each service.
Remember that a server group is a planning concept—you will not find this term or concept in SharePoint Central Administration.
The remainder of this article introduces a scenario involving a company called Contoso Pharmaceutical, to provide you with an example of how the process of scaling out a farm can work. This company started out small, making only one product, then grew to a midsize company with several hundred products. The company’s SharePoint farm also grew to accommodate Contoso Pharmaceutical’s physical growth.
2.1. Contoso Pharmaceutical Small Farm Topologies
The IT department at Contoso Pharmaceutical installed a single farm SharePoint 2010 as a proof of concept. Most companies, when first deploying SharePoint 2010, take the single farm, single group approach. This is the default settings, and thus all the services are deployed in one default group. Even when using a small farm topology, however, the deployment has room to grow from a two-tier to a three-tier approach, as you can see in the following examples.
2.1.1. Description of the two-Tier Approach
When Contoso Pharmaceutical deployed SharePoint 2010 originally, all services were activated within the default group of services used for all Web applications in a farm. All sites had access to all of the service applications deployed in the farm. Contoso deployed a two-tier approach, with a Web tier and a database tier, as shown in Figure.1
Figure 1. Two-tier small farm topology
Eventually, several department-wide collaborative initiatives created more of a demand for SharePoint 2010 within the corporate environment as well as more end-user adoption. These initiatives used services such as Excel Services, Access Services, and Search Services, which increased demand on the two-tier farm. As performance decreased due to this increase in usage, it was time to scale out this farm.
2.1.2. Description of the three-Tier Approach
Increased demand for application services and more end-user usage meant Contoso needed to separate the WFE and application server roles. In doing so, the farm was scaled out successfully to a three-tier configuration, with the query service remaining in the Web tier layer, but with a new dedicated application server providing services to all the departments within the enterprise. Figure 2 provides a view of this configuration with the newest server shown in the middle tier.
Figure 2. Three-tier small farm topology
Contoso took advantage of some key factors in moving into this new configuration. This provides the simplest architecture, with no server sharing roles. All the services on this farm are available to all Web applications, and this is the most efficient use of the farm’s resources. Lastly, all of the service applications are managed centrally.
This environment does have a couple of disadvantages, however. It does not allow for the isolation of service data, and no departments or groups have been given permissions to manage their own isolated service applications.
This is the recommended configuration for most companies, at least initially. This configuration works well for hosting a large number of sites for a single company on the same farm and provides well for a limited number of intranet deployments and collaboration initiatives.
Use this configuration if you want to optimize the resources required to run services within a farm or you want to share content and profile data across sites that otherwise require process isolation for performance or security reasons.
Real World: Small Farms
A small farm environment can consist of three servers: one Web front-end server, one Web front-end/application server, and one database server. Although this configuration is successful, it is also limited—it can handle up to 20,000 users. If your farm should have a mission critical application, you are faced with having no redundancy and additional points of failure in your design.
Points of failure include a single database server and a single server housing the service applications. This may be adequate to fulfill your business requirements, but if one of those boxes goes down, you will lose either your farm environment or that service application. If the service application is a cross-farm service being consumed by another farm, you now have a loss of functionality on not just one farm but on two farms.
Having one service application server is fine, depending on your usage demands, but if you have search requirements, you should think about scaling out that service to multiple servers to provide redundancy to your partitioned index and Search service. You already have redundancy with your query service because it is residing on your WFE.
This real world example would be suitable for a remote location using local services and consuming cross-farm services from a remote farm elsewhere.
2.2. Contoso Medium Farm Topology
Several years later, Contoso has become a midsize company with over 20,000 users and 30 terabytes of data in their SharePoint databases. The company’s enterprise search requirements have increased, both in frequency of use by end users and in the size of the index. They are now handling more than 30 million documents.
At this point, Contoso has optimized their farm to accommodate the large number of documents and the associated increased search and indexing requirements. Departments and divisions also have isolated service applications serving them.
Contoso can keep performance from declining by using dedicated application servers to handle query and crawling during searches. This approach is also useful because you can break off the index to have multiple fault-tolerant partitions. Departments can now isolate their service data, which will allow them to remain compliant with various regulations.
This configuration works well for companies that require services to be isolated, whether for security or performance reasons. It also allows those services to be consumed enterprise wide. This configuration is optimized with Search in mind, as Figure 3 shows.
Figure 3. Medium farm topology
Real World: Large-Scale Farms
For an enterprise-level organization, a medium farm may not be big enough to handle the increased demands on SharePoint, and you might find that you need to scale out even more into a large-scale farm configuration.
The majority of production SharePoint environments will not reach this size, however. Recommended best practice is to continue grouping services and databases with similar performance characteristics onto dedicated servers and then scale out those servers into server groups. Figure 4 illustrates a practical example of this concept.
Figure 4. One example of a large farm topology
In this example, the Web tier consists of redundant WFE and Administration. The application tier breaks crawl and query into separate groups and also includes a sandbox code group. All other services are grouped together. Finally, on the database tier, search databases and content databases are clustered and grouped. All other databases are clustered on their own groups.
In this example, Search is included in the database tier; however, it is a recommended practice to break out Search at this level to its own farm. This recommended practice can be applied to all other cross-farm services. Scaling out a SharePoint 2010 environment is always dependent on the requirements and goals of your organization.