Planifier l'architecture SSP

Mise à jour : 2009-04-23

This article describes Shared Services Providers (SSPs) and provides examples of how to build SSPs into the architecture of your overall solution design for Shared Services Providers (SSPs) in Microsoft Office SharePoint Server 2007.

In this article:

• About SSPs

• Building SSPs into your solution design

• Single farm SSP examples

• Planning SSPs for an inter-farm environment

• Inter-farm SSP examples

• Capacity planning related to SSPs

• Planning administration roles for SSPs

The following poster-size models are also available to use with this article:

• Office SharePoint Server 2007 Shared Services Providers (https://go.microsoft.com/fwlink/?LinkID=73166&clcid=0x409)

• Office SharePoint Server 2007 Inter-Farm Shared Services (https://go.microsoft.com/fwlink/?LinkID=73155&clcid=0x409)

About SSPs

Office SharePoint Server 2007 includes a set of services that can be shared across Office SharePoint Server Web applications. The set of services are contained within and provided by an SSP. Using shared services greatly reduces the resources required to provide these services across multiple sites. By default, a single SSP shares these services across all sites within a server farm.

The following table lists the services that are provided by an SSP.

Shared services	Description
Personalization services	Provides user profiles based on data imported from directory services; My Sites with personal information that can be shared by all users in the SSP and managed by privacy policies; and content targeting by audience, Office client application, or personalization site links.
Business Data Catalog	Provides a single, unified schema for data stored in line-of-business applications.
Excel Services	Provides shared worksheets and a way to analyze business data from data-connection libraries by using reports in dashboard pages.
Office SharePoint Server Search	Crawls all sites of Web applications using the SSP to create a single index of all content, data, and metadata.
Portal and search usage reporting	Enables shared services administrators to view aggregated information about site usage across the entire site hierarchy. Shared services administrators can also enable usage reporting for administrators of individual sites and site collections.
Project Server	This service is available if Microsoft Office Project Server 2007 is installed on the farm. Hosts one or more Project Web Access instances, exposing scheduling functionality and other middle-tier calculations on Office Project data, and exposes Web services for interacting with Office Project data. A Project Web Access instance is created to expose Office Project Server functionality to end users in a Web application that consumes this shared service.

Building SSPs into your solution design

When a farm is first installed, you create the default SSP as one of the first post-setup tasks. SSPs work in the following ways:

• Each SSP contains all of the available (installed) shared services.

• You associate SSPs with specific Office SharePoint Server Web applications.

• A Web application can only be associated with one SSP.

• All site collections and sites within a Web application consume services from the same SSP.

Creating additional SSPs

You can create additional SSPs, if needed, based on your solution requirements. Separate SSPs provide process isolation of profiles, content, and search results. Process isolation is accomplished in the following ways:

• Each SSP resides in a separate IIS application pool.

• Each SSP uses a unique set of service accounts to run the services provided by the SSP, such as search, content crawling, and profile importing.

The most important criteria that determine the number of SSPs in your logical architecture are:

• The need to share content and profile data across sites that reside in separate Web applications and IIS application pools. For example, you can share My Sites, team sites, and published content across an intranet by bringing these sites together under one SSP.

• The need to isolate content and audiences to specific sites. For example, if your server farm hosts applications for more than one class of users, separate SSPs can help create isolation between these classes.

When you create a new Web application, by default the new Web application is associated with the default SSP. If you want to associate the Web application with a different SSP, you must change the association manually.

The following diagram illustrates the logical architecture of a server farm with two SSPs.

Although not pictured, multiple Web applications within a single application pool can consume services from different SSPs. For example, in the previous diagram there is no technical limitation that prevents the two Web applications in Application Pool A from consuming shared services from different SSPs. However, Web applications that are grouped in the same application pool typically share similar isolation and security requirements, which makes it more likely that they will consume services from the same SSP.

SSP architecture

Each SSP uses the following three types of shared services resources:

• Databases (SSP database, search database)

• Shared Services Administration site (including the site’s content database)

• Web service hosting site (IIS Web site that hosts shared Web services for the SSP)

The SSP database includes the following types of data:

• SSP configuration data and site usage data

• People profiles and audience data

• Business data catalog metadata

Each SSP also includes a search database that includes all configuration and data associated with search.

The following diagram illustrates the logical architecture of a farm with emphasis on the farm resources used by SSPs.

Single farm SSP examples

This section provides several example architectures for building SSPs into a single farm and includes some additional planning recommendations.

Example 1—Single farm, single SSP

A single SSP works well for an organization that hosts a large number of sites on one farm.

A single SSP is used across the entire farm:

• All sites use the same set of shared services.

• All sites can be created within a single Web application or across multiple Web applications (shown).

• Web applications can be associated with the same application pool (shown) or with different application pools.

Recommendations

This is the recommended configuration for most companies. Use this configuration if:

• You want to optimize the resources required to run shared services within a farm.

• Your farm does not require isolation of Web applications.

Example 2—Single farm, multiple SSPs

In some organizations, there are isolation requirements that can be satisfied by implementing an additional SSP.

Multiple SSPs are used to enhance both sharing and isolation goals:

• A single SSP provides services for sites that are spread across multiple Web applications. This strategy allows sharing of content and services while maintaining process isolation between sites in different Web applications.

• Using a dedicated SSP for targeted sites provides isolation of processes, content, and services.

Recommendations

This configuration is recommended for the following scenarios:

• Sharing content and profile data across sites that otherwise require process isolation, for performance or security reasons.

• Accommodating a group or department within a company that requires secure and isolated data.

• Hosting sites for external access by partners on the same farm as your internal collaboration sites

Example 3—Hosting with a single farm

You can host multiple customers or departments on the same farm and ensure isolation of data by dedicating an SSP to each customer. A dedicated SSP also allows you to delegate ownership and configuration of services to the specific organizations. For example, you can configure a dedicated SSP for a department that requires ownership of its search configuration or profile data.

Multiple SSPs are used to isolate services within a single farm.

• Each company or department receives a dedicated SSP.

• Using separate application pools to host separate departments or companies provides process isolation at the application pool level (in addition to shared services isolation).

• An application pool can include one or more Web applications.

• Administration of shared services can be delegated to the organizations that an SSP provides services for.

Recommendations

This configuration is recommended for the following scenarios:

• Hosting sites for multiple companies or multiple independent departments within a single organization.

• Providing flexibility for each company or department to further isolate content or optimize performance by using multiple Web applications or application pools.

• Delegating administration of services.

• Accommodating a huge amount of data. There are some capacity guidelines that apply to how much data the search service of a single SSP can accommodate. For example, the recommended limit for number of documents indexed by a single SSP is 50,000,000. For more information about capacity guidelines, see Capacity planning related to SSPs later in this article.

Example 4—Hosting with multiple farms

Some organizations require physical isolation of data in addition to process isolation. For these organizations, a separate farm might be the solution.

Additionally, some organizations might include further requirements that indicate that more than one SSP is necessary on the farm, similar to Example 2 (previously pictured).

Multiple farms are used to provide physical isolation between departments or companies:

• Each department or company receives a dedicated farm and SSP.

• All hardware is dedicated based on department or customer.

• Each farm is completely isolated, resulting in no possibility of cross-portal data access.

Recommendations

This configuration is recommended for the following scenarios:

• Isolating departments within a single organization, where physical isolation of hardware, data, or applications is a requirement.

• Hosting SharePoint sites for multiple companies, where physical isolation is necessary for:

  • Tracking resource utilization

  • Securing applications and data

  • Optimizing performance

  • Satisfying licensing requirements

Additional planning recommendations for SSPs

You can configure SSPs either to enhance information-sharing across multiple Web applications or to further isolate content within a single Web application. For example, sites that reside in different Web applications and application pools can be unified under one SSP to share content and profiles across an intranet. This provides for personalization and enterprise-wide search across many sites and applications. This configuration is an example of balancing process isolation (by implementing separate Web applications and application pools) with the business need to share information and leverage profile data across the applications.

You can also configure SSPs to enhance your overall isolation goals. For example, using a dedicated SSP for partner sites ensures that partner users cannot search on or access other sites within your environment. You can configure the SSP to further isolate content between site collections in the following ways:

• Limit search scopes to the individual site collections.

• Use audiences to target content to certain groups of users.

• Use the Stsadm command-line tool to configure the People Picker to display only users who are members of the site collection.

When you design your SSP strategy, consider the ways in which you can configure the individual services within an SSP to enhance your overall content-sharing or isolation goals. For examples of these strategies, see the following design sample: Modèle d’architecture logique : déploiement d’entreprise.

Planning SSPs for an inter-farm environment

A single SSP can be configured to provide services to multiple Office SharePoint Server 2007 farms. Using an SSP across farms provides centralized administration of services and also reduces the number of services providing the same role. This can also dramatically reduce the amount of hardware and other resources that are required to provide services.

The guidance in the rest of this article describes and refers to the following diagram. This diagram illustrates a parent farm sharing services with three child farms that are each configured for different purposes. Each of the child farms are described later in this article.

Important :

Inter-farm SSPs do not work with single-server deployments that use the default Setup settings. If you deploy Office SharePoint Server 2007 on a single server using the default settings, the Setup program automatically installs Microsoft SQL Server 2005 Express Edition and uses it to create the configuration database and content database for your SharePoint sites. In addition, the Setup program creates a Shared Services Provider (SSP), installs the SharePoint Central Administration Web site, and creates your first SharePoint site collection and site.

Parent and child farms

Inter-farm shared services are offered by a parent farm to one or more child farms:

• A parent farm is configured to provide shared services to other child farms.

• Child farms are configured to consume shared services from the parent farm.

• A farm cannot be both a parent farm and a child farm.

• Only one SSP per farm can participate in inter-farm shared services:

  • Parent farms can only share one SSP to child farms. However, a parent farm can include more than one SSP for its own use (see the Parent Farm in the previous diagram).

  • Child farms can only consume services from one parent SSP. However, a child farm can provide more than one SSP for its own use (see Child Farm 2 in the previous diagram).

Switching between inter-farm SSPs and stand-alone SSPs

Shared services consumption for child farms can be reconfigured at any time:

• A child farm can disassociate from a parent farm and be configured to either consume shared services from a different parent farm or use its own local SSP.

• Child farms can consume shared services from a parent farm when connected to the central network and then switch to consume services from their own local SSP when they are disconnected. Child Farm 3 (in the previous diagram) illustrates a farm with a standby local SSP that is used when the farm is disconnected.

• Parent farms can be reconfigured as stand-alone farms at any time. Parent farm administrators should alert the child farm administrators of affected child farms before reconfiguring the SSP as a stand-alone SSP.

Inter-farm SSP limitations

The following limitations apply to inter-farm shared services:

• If the parent and child farms reside in different domains or forests, there must be a trust relationship configured between the domains or the forests. Additionally, if the two farms reside in different forests, Active Directory replication between the separate and trusted forest must be working correctly.

• Inter-farm SSPs are not supported across a WAN. A child farm cannot be associated with an SSP of a parent farm if the two farms are separated by WAN links.

• Parent farms must have all Office server products installed that are used by child farms. For example, if a child farm includes Office Project Server, then Office Project Server must be installed on the parent farm for shared services to work correctly. If a child farm uses the Enterprise Edition of the Client Access License (CAL), then the parent farm must also use the Enterprise Edition CAL (as opposed to the Standard Edition). The one exception to this design requirement is the Excel Services service.

• The Excel Services service cannot be provided by an SSP of a parent farm and must be provided by an SSP that is local to the child farm. A Web application can be configured to consume all other services from a parent farm while consuming the Excel Services service from a local SSP. This is the only circumstance in which a Web application can consume services from two different SSPs. For an illustration of this scenario see Combined inter-farm and local SSPs (Child Farm 2) later in this article.

Scripting inter-farm SSP configuration

You can create a script to duplicate the manual processes required to associate a child farm to a parent farm. Scripting the setup process:

• Reduces the amount of time required to deploy shared services across multiple farms.

• Ensures that configuration settings (directory, configuration, search index, etc.) are applied consistently across farms.

For more information, see Fournisseur de services partagés : opérations Stsadm (Office SharePoint Server).

Inter-farm SSP examples

This section describes the three child farms illustrated in the previous diagram.

Inter-farm shared services only (Child Farm 1)

Child Farm 1 consumes only shared services that are hosted by a parent farm. This scenario allows you to optimize the hardware, network, and administrative resources required to provide shared services across farms. You can either designate an existing farm to serve as the parent farm or you can create a farm dedicated to hosting shared services only.

Recommendations

This configuration is recommended for the following scenarios:

• Providing shared services to multiple farms within a company.

• Hosting Office SharePoint Server solutions for companies that require farm isolation but that do not require isolation of services.

Combined inter-farm and local SSPs (Child Farm 2)

Child Farm 2 consumes services from two different SSPs:

• Consumes inter-farm shared services from the parent farm.

• Hosts its own SSP and consumes services from this SSP.

Farms configured in this way can leverage corporate-wide shared services but can also function independently, if needed. A child farm can switch from consuming inter-farm shared services to consuming its own shared services.

The combined inter-farm and local SSP configuration is also required if a child farm is using Excel Services. If Excel Services is required by a farm, the farm must host shared services locally. In this configuration, Web applications in the child farm consume Excel Services from a local SSP and all other services from a parent SSP, as illustrated in the following diagram.

Recommendations

This configuration is recommended for the following scenarios:

• A department within a company requires farm isolation to protect sensitive data or to dedicate physical resources, and also needs to be included in company-wide portals and sites.

• A company or division is acquired and you want to provide access to company-wide resources without otherwise disrupting the farm. This scenario allows the child farm to take advantage of shared services that are available corporate-wide, such as search and crawling.

• A division or group within a company is sold or reassigned to another Office SharePoint Server environment, and you want to configure the farm to operate independently as a step toward transitioning the farm to the new environment.

• Excel Services is required by a child farm.

Standby SSP (Child Farm 3)

Child Farm 3 is configured to switch between consuming inter-farm shared services and its own shared services. The SSP within the child farm serves as a standby provider. The child farm switches to the standby SSP when disconnected from the parent farm.

Recommendations

This configuration is recommended for farm deployments that are temporarily dispatched to different geographic locations.

Capacity planning related to SSPs

When planning your SSP architecture, consider the software boundaries that are recommended for logical architecture elements and the effect they might have on your SSP configuration.

The following table lists the recommended guidelines for logical architecture components.

Logical architecture object	Guidelines for acceptable performance	Notes
Shared Services Provider (SSP)	3 per farm (20 per farm maximum)
Web application	99 per SSP	This limit includes the number of Web applications on child farms consuming resources of this SSP.
Internet Information Services (IIS) application pool	8 per Web server	The maximum number is determined by hardware capabilities.
Site collection	50,000 per Web application

In addition to the logical architecture components, the search service also includes recommended software boundaries that can affect the number and configuration of SSPs in your environment. The following table lists the specific search objects with recommended boundaries that affect SSP planning.

Search object	Guidelines for acceptable performance	Notes
Search indexes	One per SSP; maximum of 20 per farm	Office SharePoint Server 2007 supports one content index per SSP. Given that we recommend a maximum of 20 SSPs per farm, a maximum of 20 content indexes is supported. Note that an SSP can be associated with only one index server and one content index. However, an index server can be associated with multiple SSPs and have a content index for each SSP.
Indexed documents	50,000,000 per content index (one index per SSP)	Office SharePoint Server 2007 supports 50 million documents per index server. This could be divided up into multiple content indexes based on the number of SSPs associated with an index server.
Content sources	500 per SSP	This is a hard limit enforced by the system.
Alerts	1,000,000 per SSP	This is the tested limit.
Crawl rules	10,000 per SSP	We recommend a maximum 10,000 crawl rules irrespective of type.
Crawled properties	500,000 per SSP	These are properties that are discovered during a crawl.
Managed properties	100,000 per SSP	These are properties used by the search system in queries. Crawled properties are mapped to managed properties. We recommend a maximum of 100 mappings per managed property.

For more information about software boundaries, see Planifier les limites des logiciels (Office SharePoint Server).

Planning administration roles for SSPs

The shared services model in Office SharePoint Server 2007 provides the ability to centralize administration of services as a whole while delegating administration of specific services, as desired. The following table lists the primary SSP roles.

Role	Responsibilities
Farm administrator	Create or delete SSPs.
Shared services administrator (administrator of the Shared Services Administration site collection)	Configure permissions for specific services or assign administration of shared services to other users.
Shared services administrator	Configure and administer specific shared services, such as the search service or Excel Services.

One person can perform all of these roles. However, in many medium and large organizations administration of specific services is often delegated. The following table lists the specific service administration roles that can be delegated.

Service administration role	Responsibilities
Search service administrator	Administer all search settings in the SSP.
User profiles manager	Add import connections, manage user profiles, and configure My Site settings.
Audiences manager	Manage audience settings in the SSP.
Business Data Catalog manager	Import application definitions to the Business Data Catalog, select entities and properties for use in SharePoint sites and lists, and optionally execute methods against entity instances.
Permissions manager for the Business Data Catalog	Manage permissions for the Business Data Catalog.
Permissions manager for Profile Services	Manage permissions for Profile Services.
Excel Services administrator	Administer all Excel Services settings in the SSP.
Usage reporting manager	Administer usage reporting settings in the SSP.

For more information about these roles and how to configure them, see Planifier les rôles de sécurité (Office SharePoint Server).

Inter-farm SSP administration

In environments where inter-farm shared services are implemented, the responsibilities of the farm administrator differ, depending on whether the farm is a parent farm or a child farm. The following chart summarizes the administrative tasks that are performed by each administrator in an inter-farm SSP environment.

Farm administrator	Responsibilities
Parent farm administrator	Create SSPs and modify settings. Configure parent farm shared services settings. Manage shared resources on the parent farm, such as the SSP database. Manage credentials associated with SSPs. Manage shared services settings that affect all farms and sites that consume the parent SSP.
Child farm administrator	Configure child farms to consume shared services from a parent farm. Associate Web applications in child farms to the parent SSP. Disassociate from the parent farm.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

• Planning and architecture for Office SharePoint Server 2007, part 2

See the full list of available books at Downloadable content for Office SharePoint Server 2007.

Voir aussi

Concepts

Planifier des fournisseurs de services partagés
Composants de l’architecture logique
Modèle d’architecture logique : déploiement d’entreprise
Créer et configurer des fournisseurs de services partagés