Sample Deployment Scenarios

This section provides an overview of the various ways you can deploy Search technologies in your environment. These examples are merely illustrations of what you can do. Because there is no enforced, prescribed server matrix as in SharePoint Portal Server 2003, your design becomes both more simple and more complex. In this section, you'll see how this works in the various scenarios presented.

Collaboration Sites

The simplest deployment option is a Windows SharePoint Services 3.0-only deployment. This deployment is illustrated in Figure 17-5. Note that there is at least one, and perhaps more, WFE servers that offer NLB access to the content in the SQL databases. However, because a Windows SharePoint Services 3.0-only implementation cannot crawl any content outside the farm deployment, and because it lacks many of the aggregation and scoping features that ship with SharePoint Server 2007, you'll likely need only one server to crawl and index content.

Figure 17-5: A Windows SharePoint Services 3.0-only search implementation

Enterprise Portal Deployments

There are different configurations that you can consider, but all can be reduced to two simple role combinations:

• Index and query roles on one server

• Index on one server, query on another server

Remember, the index role is the role that crawls content. The query role is the roles that executes user queries against the search database. You can run both of these roles on the same server, or you can split them onto different servers.

In a single SSP environment, this is certainly not difficult to design and deploy. Either install one server as an index/query server or install two servers-one as the index server and the other as the query server (assuming one SSP). The complexity occurs when you have multiple SSPs. If you have several SSPs, your server-to-role possibilities increase as the number of SSPs in your deployment increases. For example, if you have two SSPs, you can deploy any of the following combinations (and this is not an exhaustive list):

• Both roles for both SSPs on one server

• The query role for both SSPs on one server, and each indexing role for each SSP on another server

• The query role for both SSPs on one server, and each indexing role for each SSP on an individual server

Figure 17-6 illustrates two SSPs, each with their own index server and two query servers working together to field client requests for indexed content.

Figure 17-6: Multi-SSP, multi-server illustration

Note that the query role, unlike the indexing role, is not assignable to an SSP. So your query servers will handle all user search queries and will automatically know to which SSP to route the query. Because indexing and query demand will likely not be proportional or related (statistically speaking), you'll need to ensure that you have enough query servers to service peak demand for user queries. But don't worry about trying to ensure that you have one query server per SSP or any other type of query server-to-SSP mapping. That is not an issue in this version of SharePoint Server 2007.

Internet-Facing Site

Depending on the purpose of the Internet-facing site, you might find yourself offering search services to an undefined set of users (generically referred to here as the "Internet") or a predefined set of users who are known to you (generically referred to here as the "extranet").

You can certainly deploy farm that accepts requests from your intranet, extranet, and Internet zones. But in many deployments, the index that intranet users search will be different and distinct from the index that extranet or Internet users search. For Internet-facing sites, your concern is much more about index isolation-ensuring the content that Internet users can search does not include sensitive or protected information that your intranet users might be able to search.

The number of servers you'll need and their role assignment will become more clear to you as you work out the logical SSP and index topology for your overall environment. In most cases where there are extranet and Intranet users, you'll find yourself designing a multi-SSP topology. But don't automatically assume that you'll need one server per SSP. The number of servers you'll need is not related to the SSP topology as much as it is related to your overall crawling schedules for all of your SSPs and the number of user queries against all the SSP indexes combined. You'll need to ensure that you're monitoring your query and index servers to ensure they have sufficient resources to meet peak demand for your environment.