Deploying SharePoint Server Farms

You can choose from a multitude of farm deployment scenarios to include as part of your design. In this section, you'll become familiar with some of the more common scenarios and presented with a roadmap for deploying SharePoint Server 2007. The classifications given here to these farm topologies is rather arbitrary; none of the topologies are enforced in the user interface. You can craft any combination of server you want in a SharePoint Server 2007 farm. These classifications are for discussion purposes only, and you can use them as starting points for planning the right topology for your environment.

Single-Server Deployment

In a single-server deployment scenario (shown in Figure 3-7), a single server services all the client's needs and offers all the needed services to the network. This topology also uses the SQL Express database engine and installs it on this server. A single server is assigned all the farm roles, including the following ones:

• Web front-end The role to which users always connect to access all farm services, including search and indexing, Excel Calculation Services, collaboration, portals, and more

• Query server The role that allows users to query the index to find content

• Search server The role that crawls and indexes content from content sources

• Excel Calculation The role that hosts complex queries for end-user Excel spreadsheets and helps users maintain persistent connections to data points

• Forms Server The role that offers InfoPath forms to the users on your network

• Web content management The role that allows staging and publishing of Web content

Figure 3-7: Single-server topology

Single-server roles are best suited for environments with a small user base or for testing labs.

Small Server Farms

A small-farm environment (shown in Figure 3-8) is a two-tiered environment in which one server is running SQL Server and the other server is running all the roles in the SharePoint farm.

Figure 3-8: Small-farm topology

If performance becomes an issue, you can always add another WFE server to the farm. If data redundancy becomes an issue, you can always cluster your SQL servers. If both increased performance and data redundancy are needed, you can add servers to your SharePoint farm as needed and cluster your SQL Server server. Both actions will help ensure that users can access their data quickly and easily.

Medium Server Farms

We move to a three-tier topology with a medium server farm. This topology places the application services-such as search, query, Excel calculation, Office Forms Server and other services-on the middle tier (as shown in Figure 3-9). In this topology, two servers are dedicated to being WFE servers: one application server in the middle tier, and a clustered SQL Server deployment for data redundancy. The most likely reason you'd add a second server to the middle tier is to isolate the search function on a single server, because that activity is very processor and RAM intensive.

Figure 3-9: Medium server farm topology

In addition, by modifying this topology and adding another server to the middle tier, you can achieve maximum redundancy with the fewest number of servers, which is six. (See Figure 3-10.) Each tier has two servers offering the same services, thereby giving you the greatest opportunity for redundancy with the fewest number of servers. Most environments for small and medium servers will be similar to what I've described in this section.

Figure 3-10: Medium server farm topology with redundancy

Large Server Farms

A large farm merely builds on the medium farm topology and allows us to scale out servers for any combination of services that are needed. Figure 3-11 offers one illustration of a large server farm for SharePoint Server 2007. Note that there is redundancy at each tier and for each service. Notice also that you're writing content to multiple SQL clusters. Finally, notice that as you need to, you can scale out any tier and service you need with additional servers. The only servers that need NLB are the WFE servers. All other servers merely have their services started or stopped and SharePoint Server 2007 does the rest to ensure they are all utilized properly.

Figure 3-11: Large server farm topology

Multiple Farms

At times, you will find that multiple SharePoint Server 2007 server farms are required. (Figure 3-12 shows content deployment in a multiple-farm environment.) As an example, software development requires development, test, and production environments. SharePoint Server 2007 perfectly meets this need by using multiple farms, which allows development and test environments to be on intranets and schedules the publishing of production content to a screened subnet. Geographically dispersed organizations and implementations with unique legal and regulatory requirements will require multiple farms as well.

Figure 3-12: Content deployment in a multifarm environment

Using Interfarm Shared Services

If you have several SharePoint Server 2007 server farms, you should leverage SharePoint Server 2007 capabilities of interfarm shared services. Interfarm shared services reduce the administrative and operating overhead by limiting custom Shared Services development to one server farm. A single Business Data Catalog connector, a single MySites namespace, and centralized search and indexing are the most common reasons for a unified Shared Services implementation. There are some limitations to be aware of when designing this model, the most obvious being bandwidth limitations. Interfarm shared services are generally not supported over WAN links. Robust search and indexing, Business Data Catalog, and My Sites can require huge amounts of expensive bandwidth. However, with the advent of large, high-speed optical carrier (OC) backbones, an exception might be made in some large organizations. Refer to Chapter 18, "Administrating Shared Services Providers," for information on integrating interfarm and intrafarm Shared Services.

Note 

To avoid My Site URL collisions between multiple domains, be sure to select Domain and User Name when defining Site Naming Format.