FAST Search Server 2010 for SharePoint (FAST Search for SharePoint) is an alternative to the out-of-box SharePoint Server search (the built-in enterprise search solution in SharePoint Server 2010). It utilizes the same Search Service Application framework
as SharePoint Server search, including most integration points. The back-end architecture, however, is rather different.
You can find more information about the functional differences between the two enterprise search solutions in the following white paper: Getting started with enterprise search in SharePoint
A SharePoint Server farm is one SharePoint deployment sharing one Central Administration. In a standard SharePoint deployment the search capabilities (SharePoint Server search) are part of the SharePoint farm out-of-box.
The FAST Search for SharePoint back-end is not part of the SharePoint farm itself, but is deployed and configured as a separate farm – the
FAST Search for SharePoint farm (FAST farm).
The FAST farm can be seen as an extension to the parent SharePoint farm. The FAST farm cannot exist without the parent SharePoint farm. When deployed, FAST Search for SharePoint replaces the out-of-box SharePoint Server search as the search provider in the
SharePoint farm. The SharePoint farm and the FAST Search for SharePoint farm is connected via the concept of
Search Service Applications (SSAs).
Plan search topology.
A good reference to the Search Service Application framework is SharePoint Service Application Framework Object Model.
In a SharePoint Server deployment, when using the standard SharePoint Server search, there is one SSA (often denoted “the SSA”), which represents the grouping of the search components of the farm. This SSA consists of one or more crawl components and one or
more query components.
Note: In SharePoint Server search terminology the crawl component also includes the indexer. This is not the case in FAST Search for SharePoint.
In a FAST Search for SharePoint deployment, the users interact with the SharePoint farm via two SSAs, the
FAST Search Query SSA and the FAST Search Content SSA.
Note: In an FAST Search for SharePoint deployment, you may still see an SSA named “Search Service Application” from SharePoint Central Admin. This is actually the SharePoint Server search SSA that was created when the SharePoint farm was deployed
in the first place, and will not be used after you have deployed FAST Search for SharePoint. This may be confusing for commands that is associated with service applications.
More information: Plan search service applications (TechNet).
The following figure shows how FAST Search for SharePoint fits into a SharePoint Server farm:
The Content SSA provides the crawl/connector interface for FAST Search for SharePoint. The Query SSA provides the query side integration between FAST Search for SharePoint and the query interfaces as exposed in SharePoint.
The following figure shows the multiple farm architecture when using FAST Search for SharePoint:
In this deployment there is one centralized search farm that index content from multiple SharePoint farms, and also serves queries for these farms.
Note: The SSAs are located in the parent SharePoint farm, not the child farms. You should not configure more than one SSA of each type associated with the FAST Search for SharePoint farm.
The query SSA provides the query side integration between FAST Search for SharePoint and the query interfaces as exposed in SharePoint (Web parts, Query Web Service, Query OM and Federation OM).
The key differences from the SharePoint Server search SSA are:
The Query SSA contains an instance of SharePoint Server search that handles People Search. This one operates rather independently of the FAST Search Server back-end, and the front-end federates people search results with other results in the web parts. This
instance of SharePoint Server search includes a crawl component that crawls user profile data from SharePoint, and a query component that responds to people search queries.
If you need to change the People Search configuration (scopes, customizing ranking, etc.) it is important to understand that this must be done using the SharePoint Server search admin interfaces, not the FAST Search admin interfaces!
People Search has its own scaling model. Normally you do not need to scale out People Search for performance, but you may want to have an end-to-end fault-tolerance. To achieve that, you need to configure two query components, and two crawl components in the
Query SSA (the crawl components will only crawl user profile data).
Note: You scale out the Query SSA by adding query components, not by adding multiple SSAs!
There is an important difference in how you configure features for people search and non-people search. Example: If you want to change managed properties configuration for people search, you do that from Queries and Results --> Metadata Properties:
For non-people search content, you change the configuration from FAST Search Administration --> Managed Properties:
The Content SSA behaves in the same way as the SharePoint Server search crawler from a content retrieval point of view (content sources, crawl rules, etc.). The crawl DB is used for content retrieval (crawling) housekeeping in the same way.
Definition and handling of content sources are handled in mainly the same way as for SharePoint Server search.
The key difference from how SharePoint Server search performs crawling is:
The main integration points are the same for SharePoint Server search and FAST Search for SharePoint:
Some integration points and customization options are specific to FAST Search for SharePoint:
Also see this useful blog post that explains the query integration points:
The Search Developer Story in SharePoint 2010 - Query Interfaces
Is the Multiple Farm architecture supported my Microsoft?
The multiple farm scenario represents a "Federated services farm" setup which is indeed supported.
Really good list of links Knut! I just grouped them together in a See Also section.