How upgrade affects search system architecture (Search Server 2010)

 

Applies to: Search Server 2010

Topic Last Modified: 2010-07-09

The information in the following table describes how features and functions of the search system architecture are affected when you upgrade from Microsoft Search Server 2008 to Microsoft Search Server 2010.

Feature or function Feature or function in Search Server 2008 Corresponding feature or function in Search Server 2010

Search service

A Shared Services Provider (SSP) hosts one or more centrally managed, reusable services. These services can be consumed by multiple Web applications in a farm. One of the services is the Office SharePoint Server Search service (OSearch). The OSearch service is used to crawl content repositories, index the crawled content, and serve search queries that are issued by end-users.

However, an administrator might want to define more than one group of search settings for a farm-wide search configuration. For example, for security reasons the administrator might want to dedicate one content index to one set of content sources, and another content index to another set of content sources. To define an additional group of settings for a farm-wide search system, the search administrator must configure the OSearch service in a different SSP. If there is no other SSP in the farm that can be used for this purpose, the farm administrator must create a new SSP. However, each SSP requires maintenance and can consume system resources in addition to those that are used for the OSearch service.

For each SSP that existed in the farm before upgrade, the upgrade process automatically creates a Search service application. At upgrade time, the administrative settings from the OSearch service in an SSP are copied to the corresponding new Search service application. For example, the new Search service application contains the content sources, scopes, and crawl rules from the OSearch service in the corresponding SSP.

Search service configuration dependencies

In an SSP, the search administrator configures the OSearch service to define one group of settings (such as content sources and scopes) for a farm-wide search system. Each SSP can contain only one OSearch service. Therefore, an SSP can contribute only one group of settings to the farm-wide search system.

Each Search service application contributes one group of settings (such as content sources and scopes) for a farm-wide search system. A Search service application requires no host such as an SSP. To add a new group of settings to a farm-wide search system, the search administrator merely creates and configures an additional Search service application.

Databases

For each SSP, there are two databases:

  • The SSP database. This database contains administrative settings for search, such as content sources and scopes.

  • The search database. This database:

    • Crawler internal data, such as crawl logs.

    • The property store, which includes the metadata from crawled documents.

For each SSP that existed before upgrade, the following three databases are created and associated with the corresponding Search service application:

  • The search administration database. This database contains the administrative settings for search that were stored in the SSP database.

  • The crawl database. This database contains the crawler internal data that was stored in the SSP database.

  • The property database. This database is largely the same as the search database that existed before upgrade. (Some information that was in the search database before upgrade is moved into the search administration database and crawl database.)

There is only one search administration database per Search service application. After an upgrade, however, the crawl database and property database can be scaled out.

Crawling

An index server has a single crawler.

A crawl server contains one or more crawl components that can crawl content independently of one another.

Serving queries

A query server has only one component to serve search queries.

A query server can host one or more query components, each of which serves search queries.

Content index

Each SSP can contain only one OSearch service, and there is one corresponding content index.

For each SSP that existed before upgrade, one index partition is created with one query component. An in-place upgrade copies the entire content index from the SSP to the new index partition. After upgrade, the administrator can scale out to multiple index partitions. Each index partition contains a discrete part of the index. For example, in a topology with two index partitions, each partition contains half of the index.

In a database-attach upgrade, the old content index is not retained. To create an index, it is necessary to perform a full crawl after the upgrade.

Propagation of content index

The search system stores the content index in the file system of the index server. The search system also propagates a copy of the content index to the file system of each query server.

Each crawl component propagates the content index to the index partitions on the query servers. The search system stores the content index in the file systems of the query servers. The crawl server does not keep a copy of the content index.

Naming of SSP and Search service application

Each SSP in a server farm has a unique name — for example, SharedServices1.

Each Search service application that is created during the upgrade process has a default name that is based on the name of the corresponding SSP from Microsoft Search Server 2008. For example, if the SSP was named SharedServices1, by default the corresponding Search service application is named SharedServices1_Search. However, the administrator can customize these database names with an XML file that is used at upgrade time.