Now that you know about the basic service applications components, you need to understand how they are applied to scaling
out your SharePoint 2010 environment. SharePoint environments are
broken down into tiers, with Web front-end servers constituting the Web
tier, application servers included in the application tier, and database
servers in the database tier.
1. Web Tier
All single farm and
cross-farm services can reside on the Web tier, depending on the farm’s
topology. In small farms, it is likely that both the Web and application
tiers will reside on the same servers.
2. Application Tier
This tier is where you’ll
host your service applications. SharePoint 2010 is structured so that
users do not connect directly to an application in this middle tier.
Instead, users always connect to servers in the Web tier, and then their
calls are proxied to servers hosting the middle tier applications. In
cases in which both tiers are located physically on the same servers,
users still connect to the services in the Web tier and then are
connected to the service applications. Figure 1 illustrates the client-related services for a single farm implementation.
Figure 1. Client-related services
illustrates other services that can be installed in a single farm, but
these are not services that your users will consume directly. These
services support other applications that will produce information or a
stable context in which information is better managed.
Figure 2. Other services available within a single farm
Single-farm services cannot be used across farm boundaries.
There are some services that can be consumed either within a farm or
across a farm. For example, you can install the Managed Metadata Service
(MMS) and utilize that within a single farm or utilize it across
multiple farms. These services can also be consumed simultaneously
within a farm and across farm boundaries. Figure 3 and Figure 4 illustrates these services.
Figure 3. Cross-farm Search roles
Figure 4. Other cross-farm services
3. Database Tier
The volume of content and
business requirements for sizing will affect the number of content
databases. Capacity planning for content databases is a core design
function that you shouldn’t ignore. SharePoint 2010 utilizes a plethora
of databases for different tasks, and ensuring that your databases stay
within the size needed for efficient backup and restore operations is an
important aspect of your overall design considerations.
Figures Figure 5, Figure 6, and Figure 7
help illustrate how important it is to plan correctly for the capacity
your organization will require. You can see that you’ll have a number of
content databases to host content that users place in your SharePoint
implementation, plus other databases that will support your service applications. Figure 5 illustrates the content databases in your farm, Figure 6
illustrates the possibility of having more than one index (note that
each index has a separate property store for hosting the index’s
metadata), and Figure 7 illustrates other service databases that you will likely have in your deployment.
Figure 5. Content databases in SharePoint 2010
Figure 6. Search databases in SharePoint 2010
Figure 7. Other service databases in SharePoint 2010