Composants de l’architecture logique
Mise à jour : 2009-04-23
In this article:
Server farms
Shared Services Providers
IIS application pools
Web applications
Zones
Policy for Web applications
Content databases
Site collections
Sites
Host-named site collections
My Sites
There are a variety of ways you can arrange the components in a logical architecture design. Each of the components presents different opportunities for sharing and isolation. Before you begin your logical architecture design:
Know what your sharing and isolation goals are.
Evaluate the tradeoffs for each choice.
Each section in this article describes a particular logical architecture component and discusses the following considerations for that component: capacity, sharing and isolation, configurable items, administration, and planning recommendations.
For information about implementing logical architecture components in a sample design, see Modèle d’architecture logique : déploiement d’entreprise.
Server farms
Technically, server farms are not a logical architecture component. However, a server farm represents the top-level element of a design. Individual server farms provide physical isolation.
Several criteria that are determined by your organization might affect the number of server farms that are required, including:
Separate operational divisions of responsibility.
Dedicated funding sources.
Separate datacenter locations.
Industry requirements for physical isolation between sites.
However, you can satisfy many isolation requirements on a single server farm. For example, you can use different Internet Information Services (IIS) application pools with different process identities to achieve isolation at the process level. You can also use separate Web applications to achieve isolation at the Web application level.
In addition to isolation requirements that might require more than one server farm, an organization might implement multiple server farms to satisfy performance and scale goals.
In Microsoft Office SharePoint Server 2007, there are other factors that might lead to deploying multiple server farms. For example, multiple server farms might be necessary to satisfy licensing requirements or to implement a publishing environment. For more information, see Planifier des batteries de serveurs.
Shared Services Providers
A Shared Services Provider (SSP) provides a common set of services and service data to a logical grouping of Web applications and their associated sites. Services and service data include:
Personalization services, including My Sites
Audiences
Business Data Catalog
Excel Services
Office SharePoint Server Search
Usage reporting
SSPs are associated with Web applications. All sites within a Web application are served by the SSP that is assigned to the Web application. An SSP can host services for multiple Web applications.
Capacity
You can create up to 20 SSPs per farm. For acceptable performance, we recommend that you use three or fewer SSPs per farm.
Sharing and isolation
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.
Configurable items
The following table lists configurable items that contribute to isolation and sharing.
| Item | Description |
|---|---|
Shared service permissions |
You can delegate management of shared services to others by granting permissions to one or more of the shared services. Users must also have permissions to the Shared Services Administration Web site to view and manage shared services. |
Trusted My Site locations |
In organizations where multiple SSPs provide My Sites, this feature ensures that users create a My Site in the SSP that is intended for their profile. This feature prevents users from creating multiple My Sites across an organization. For more information, see "Coordinate My Sites across your organization" in Concevoir l’architecture de Mes sites. |
Administration
Configuration and management of SSPs can be delegated to administrators who specialize in providing shared services, such as search and audiences.
In a hosted environment, administrators can configure one SSP per customer and allow the customers to manage their own shared services.
For more information about planning for SSP administration roles, see Planifier les rôles de sécurité (Office SharePoint Server).
Planning recommendations
Configure SSPs either to enhance information sharing across multiple Web applications or to further isolate content within a single Web application.
For example, multiple sites that reside in different Web application and application pools can be unified under one SSP to provide content and profile sharing across an intranet. This provides for personalization and enterprise-wide search across many sites and applications. This choice provides 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 collaboration ensures that partner users cannot search on or access sensitive information within your intranet 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 that 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.
Application pools
An application pool is a grouping of one or more URLs (or Web sites as they are represented in IIS) served by a worker process. Each application pool has its own worker process and identity (security account) which prevents two processes from interacting.
Capacity
The memory overhead of an application pool is 30-50 megabytes (MB) plus any memory for the applications running in the application pool process space. The limit for the number of application pools is influenced by the available memory on the system. That is, the number of application pools is dictated by the following two factors:
Available addressable memory.
The size of the application running in the application pool.
The general guideline for acceptable performance is to use eight or fewer application pools.
Sharing and isolation
IIS application pools provide a way for multiple sites to run on the same server computer but still have their own worker processes and identity. This can help to prevent an exploit on one site which enables the attacker to inject malicious code that can attack sites in different application pools.
Configurable items
Use a separate application pool identity for each application pool.
Administration
Administration includes maintaining separate application pool identities for each application pool.
Planning recommendations
Practically speaking, consider using a dedicated application pool for each of the following reasons:
To separate authenticated content from anonymous content.
To isolate applications that store passwords for and interact with external business applications, for example, Business Data Catalog connections.
To isolate applications with which users have great liberty to create and administer sites and to collaborate on content.
Web applications
A Web application is an IIS Web site that is created and used by SharePoint Products and Technologies. Each Web application is represented by a different Web site in IIS. You assign each Web application a unique domain name, which helps to prevent cross-site scripting attacks.
Capacity
Each ASP.NET page generates a separate dynamic-link library (DLL) for each Web application. The separate DLLs consume memory, limiting the number of Web applications that can run on a server. The guideline for acceptable performance is to implement 99 or fewer Web applications per SSP.
Sharing and isolation
Galleries and templates are registered in the configuration database for the server farm. You can specify which Web applications can use these.
Each Web application has a unique domain name, which helps to prevent cross-site scripting attacks.
Configurable items
The following table lists configurable items that contribute to isolation and sharing.
| Item | Description |
|---|---|
Shared Services Providers |
SSPs are associated with Web applications. All sites within a Web application consume services from the same SSP. An SSP can provide services for more than one Web application, thus sharing content and profile data across the Web applications. |
Zones |
Within a Web application, you can create up to five zones. Use zones to enforce different access and policy conditions for large classes of users. |
Policy for Web application |
Create an "All Zones" policy to enforce a policy condition that applies across all zones in the Web application. |
Administration
Ongoing administration of Web applications is not significant.
Planning recommendations
Generally speaking, use dedicated Web applications to:
Separate content available to anonymous users from content available to authenticated users.
Isolate users. For example, you can ensure that partners do not have access to intranet content by placing partner sites in a separate Web application.
Enforce permissions. A dedicated Web application provides the opportunity to enforce permissions by policies by using the Policy for Web Application page in Central Administration. For example, you can create a policy to explicitly deny write access to one or more groups of users. Policies for a Web application are enforced regardless of permissions configured on individual sites or documents within the Web application.
Optimize database performance. Applications achieve better performance if they are placed in Web applications with other applications of similar data characteristics. For example, the data characteristics of My Sites typically include a large number of sites that are small in size. In contrast, team sites typically encompass a smaller number of very large sites. By placing these two different types of sites in separate Web applications, the resulting databases are composed of data with similar characteristics, which optimizes database performance.
Optimize manageability. Because creating separate Web applications results in separate sites and databases, you can implement different limits for each site's Recycle Bin, expiration, and size, and negotiate different service-level agreements. For example, you might allow more time to restore sites that are not critical to your business.
Zones
Zones represent different logical paths (URLs) of gaining access to the same Web application. Within each Web application, you can create up to five zones using one of the available zone names: Default, Intranet, Internet, Custom, or Extranet. Each zone is represented by a different Web site in IIS.
The Default zone is the zone that is first created when a Web application is created.
Capacity
You can create up to five zones within a Web application. Typically, zones are coordinated across Web applications so that zones of the same name are configured for the same users.
Sharing and isolation
Zones provide a method of partitioning users by:
**Authentication type **Each zone can be configured to use a different authentication provider, enabling you to share the same content across partner companies.
**Network zone **Each zone can be configured to accommodate users entering from a different network zone, such as an extranet or the Internet.
Policy permissions You can explicitly allow or deny read or write access to content per zone based on a user account or a group account.
Configurable items
The following table lists configurable items that contribute to isolation and sharing.
| Item | Description |
|---|---|
Authentication provider |
Each zone can be configured to use a different authentication provider. |
Secure Sockets Layer (SSL) |
Turn SSL on or off per zone. |
Load-balanced URL and alternate access mapping |
Specify the domain name users will type to access content in the Web application. Alternatively, use alternate access mapping to map user-friendly or zone-appropriate URLs to the default URL (server name and port) for each zone. Alternate access mapping provides support for off-box termination of SSL. Off-box termination of SSL is when a proxy server terminates an SSL request and then forwards the request to a Web server by using HTTP. In this case, alternate access mappings can be configured to return these requests using SSL, thus maintaining secure communication between the client and the proxy server. |
Policy for Web application |
Create a unique set of policies for each zone within the Web application. If you have a special group of users that require exceptions to your overall security policy, consider using a separate zone to accommodate these users. |
Administration
If you use alternate access mapping, consider that all public URLs require Domain Name System (DNS) entries to map the public URLs to the IP address of the load balancer used for the farm.
Planning recommendations
When you design zones, several key decisions are critical to the success of the deployment. These decisions include design and configuration decisions for the following zones:
The Default zone
Zones for external access
The following sections describe some of the planning recommendations and requirements for zones.
Configuration requirements of the Default zone
The zone that involves the greatest consideration is the Default zone. The following requirements apply to how the Default zone is configured:
The Default zone must be the most secure zone. This is because when a user request cannot be associated with a zone, the authentication and policies of the Default zone are applied.
The index component requires access to content through at least one zone to crawl content. By default, the index component uses NTLM authentication. The search service administrator can configure crawl rules to use either basic authentication or a client certificate when crawling a particular range of URLs. Consequently, to crawl content, at least one of the zones must be configured to use NTLM authentication, basic authentication, or certificates. Also, the crawler will poll zones in the following order until it encounters a zone that it can authenticate through: Default zone, Intranet zone, Internet zone, Custom zone, Extranet zone. However, if the crawler first encounters a zone that is configured to use Kerberos authentication and that is not configured to use a standard port (either port 80 or 443), the crawler will not authenticate and will not attempt to access the next zone. Therefore, ensure that the configuration of zones using Kerberos authentication does not prevent the index component from crawling content. For more information about authentication requirements related to crawling content, see Planifier des méthodes d’authentification (Office SharePoint Server).
Administrative e-mail is sent with links from the Default zone. This includes e-mail to owners of sites that are approaching quota limits. Consequently, users who receive administrative e-mail messages and alerts must be able to access links through the Default zone. This is especially important for site owners.
Host-named site collections are only available through the Default zone. All users who are intended to access host-named site collections must have access through the Default zone.
Configuring zones for an extranet environment
In an extranet environment, the design of zones is critical for two reasons:
User requests can be initiated from several different networks, such as the internal network, a partner company network, or the Internet.
Users consume content across multiple Web applications. For example, an intranet environment might include sites that are hosted in several different Web applications. Additionally, employees might have access to both the intranet content and to partner collaboration content.
In an extranet environment, ensure that the following design principles are followed:
Configure zones across multiple Web applications to mirror each other. The configuration of authentication and the intended users should be the same. However, the policies associated with zones can differ across Web applications. For example, ensure that the Intranet zone is used for the same employees across all Web applications. In other words, do not configure the Intranet zone for internal employees in one Web application and remote employees in another.
Configure alternate access mappings appropriately and accurately for each zone and each resource.
Policy for a Web application
A policy for a Web application enforces permissions on all content within a Web application, enabling you to set security policy for users at the Web application level. The permissions in a policy override all other security settings that are configured for sites and content.
You can configure policy based on users, or user groups, but not SharePoint groups. A policy can be defined for the Web application in general or just for a specific zone.
Capacity
There are no capacity restrictions that apply to policies for Web applications.
Sharing and isolation
A policy for a Web application provides a method of setting permissions based on users and the zone that they access content through.
For example, by using a policy, you can:
Allow Help desk staff access to all content.
Deny write access to partners or vendors.
Deny access to secure data to a class of users regardless of how site owners configure permissions.
Ensure that the crawl account has access to crawl all content.
Configurable items
The following table lists configurable items that contribute to isolation and sharing.
| Item | Description |
|---|---|
Zone |
Apply a policy to a specific zone within the Web application — for example, the Intranet zone — or to all zones within the Web application. |
Users |
Specify users to whom to apply the policy by using one of the following:
|
Permissions |
Choose the permissions that you want to enforce for the users:
These permissions override any permissions assigned within the Web application, including permissions set for site collections, sites, lists, documents, and so on. |
Administration
Ongoing administration of policies for Web applications is not significant.
Planning recommendations
Because policies are managed centrally, consider using policies to manage large classes of users, rather than individual users.
Content databases
By default, all content for a Web application is stored in one content database. You can separate content into multiple content databases at the site collection level. A content database can include one or more site collections. A single site collection cannot span multiple databases. Backing up and restoring sites takes place at the content database level.
Capacity
The guideline for acceptable performance is to implement 99 or fewer content databases per Web application.
Sharing and isolation
Planning for databases enables you to either optimize for efficiency (multiple site collections sharing a database) or isolation (one database per site collection).
Achieve scale efficiency by managing databases to the maximum target size. In this case, you configure database settings to add new site collections to existing databases until the maximum number of site collections has been reached. You calculate the maximum number of site collections by estimating the average or maximum size of site collections divided into the maximum size target for the database. This approach works well when you expect a large number of small site collections, such as My Sites.
Achieve isolation of content between teams or projects by limiting a database to one site collection. This approach enables you to independently manage the content of individual teams. For example, you can independently manage each team's database for backup, recovery, and migration. This approach provides the opportunity to implement different service-level agreements for different teams or projects. This approach also enables you to manage content to the life cycle of a project. For example, you can archive a database when a project is completed.
Configurable items
The following table lists configurable items that contribute to isolation and sharing.
| Item | Description |
|---|---|
Database server |
Specify which SQL Server computer a content database is created on. |
Capacity settings |
|
Administration
A manageable database administration plan balances the number of databases with the resources required to manage the databases.
Administration of databases includes:
Creating new databases for new team sites or site collections that require dedicated databases.
Monitoring database sizes and creating new databases when size targets are approached.
Backing up and restoring databases.
Planning recommendations
Choose one of the following two approaches:
Establish target sizes for content databases with appropriate size-warning thresholds. Create new databases when size-warning thresholds are reached. With this approach, site collections are automatically added to the available database or databases, based on size targets alone.
Associate site collections with specific content databases. This approach enables you to place one or more site collections in a dedicated database that can be managed independently from other databases.
If you want to associate site collections to specific content databases, you can use the following methods to accomplish this:
Use the Stsadm command-line tool to create a site collection in a specific database.
Dedicate a database to a single site collection by applying the following database capacity settings on the Manage Content Database Settings page on the SharePoint Central Administration Web site:
Number of sites before a warning event is generated = 1
Maximum number of sites that can be created in this database = 1
Add a group of site collections to a dedicated database by performing the following steps:
Within the Web application, create the database, and then on the Manage Content Database Settings page in Central Administration, set the database status to Ready.
Set the status of all other databases to Offline. While content databases are offline, new site collections cannot be created. However, existing site collections in offline databases are still accessible for both read and write operations.
Create the site collections. They are automatically added to the database.
Set the status of all other databases back to Ready.
Site collections
A site collection is a set of Web sites that have the same owner and share administration settings. Each site collection contains a top-level Web site and can contain one or more subsites.
Capacity
The recommended guideline for acceptable performance is to implement fewer than 50,000 site collections per Web application. Scaling out by distributing site collections across multiple database servers provides additional storage capacity and throughput.
Sharing and isolation
Site collections introduce several sharing and isolation opportunities that affect permissions, navigation, and feature deployment.
The following items can be shared within a site collection and cannot be shared across site collections:
Master pages
Page layouts
Images
Site templates
Additionally, permissions and navigation are isolated at the site collection level in the following ways:
Subsites within a site collection can inherit permissions from the top-level site.
Site collections cannot inherit permissions from other site collections.
There is no built-in navigation from one site collection to another.
Finally, Office SharePoint Server 2007 aggregates search results across site collections based on a user’s permissions, regardless of the number of site collections or databases (depending on search scopes).
It is important to note that although permissions are enforced on individual sites, the sites are still vulnerable to cross-site scripting attacks from other sites within the domain.
Configurable items
The following table lists configurable items in Central Administration that contribute to isolation and sharing.
| Item | Description |
|---|---|
Site collection administrator |
You can specify one user to be the primary site collection administrator and one user to be the secondary site collection administrator. In Central Administration, you cannot enter more than one account for these roles, nor can you enter a group account for these roles. |
Quota template |
You can apply a quota template to limit resources used for a site collection. The following templates are provided:
|
The following table lists configurable items within a site collection that contribute to isolation and sharing.
| Item | Description |
|---|---|
Site collection administrators |
You can specify multiple user accounts to be site collection administrators. You cannot add group accounts. |
Permission level |
Add user and group accounts to site collections and specify permission levels for each. |
Administration
Site collection creation does not require DNS entries and can be easily automated or delegated to users. You can create site collections for your team sites centrally, or you can allow users to create their own site collections by using Self-Service Site Management. Assigning a site collection to a single database provides the ability to perform backup and recovery at the site collection level.
Planning recommendations
Site collections bridge logical architecture and information architecture. When you design your site collections, consider the following two design tasks:
Design consistent URLs across your organization.
Create logical divisions of content.
Unless you are using host-named site collections, each Web application must have a single root-level site collection. This provides a single URL path into the sites that reside in the Web application. This is also a requirement if you are implementing multiple zones within a Web application.
Many organizations plan to implement multiple site collections within a Web application for use by different teams or divisions within the organization. Common design goals include the following:
Maintain a separate and independent site collection for each team.
Create a unique URL for each team.
To satisfy these goals, you can use managed paths to incorporate multiple top-level site collections within a Web application. By defining managed paths, you can specify which paths in the URL namespace of a Web application are used for site collections. You can specify that one site collection or more than one site collection exists at a distinct path below the root site. Without managed paths, all sites created below the root site collection are part of the root site collection.
You can create the following two types of managed paths:
Explicit inclusion A site collection with the explicit URL that you assign. An explicit inclusion is applied to only one site collection. You can associate each of these site collections with a different content database if you want to manage growth and to provide the opportunity to back up and restore these sites separately. An example URL for a site collection created by using this method is http://fabrikam/hr. The limit on site collections created with an explicit inclusion is approximately 100 site collections. If your organization requires a greater number of site collections, use a wildcard inclusion instead.
Wildcard inclusion A path that is added to the URL. This path indicates that all sites that are specified directly after the path name are unique site collections. This option is typically used to support Self-Service Site Management, such as My Sites or sites created for partner collaboration. Example URLs for site collections created by using this method are http://partnerweb/sites/project1 and http://partnerweb/sites/project2. In these examples, "http://partnerweb" represents the root-level site collection and "/sites" represents the wildcard inclusion.
For more information about designing URLs and using managed paths, see "Zones and URLs" in the following planning article: Modèle d’architecture logique : déploiement d’entreprise.
Sites
A site is one or more related Web pages that are hosted inside a site collection.
Capacity
The guideline for acceptable performance is to implement fewer than 250,000 sites per site collection. You can create a very large total number of Web sites by nesting the subsites. For example, 100 sites, each with 1000 subsites, is 100,000 Web sites. The maximum recommended number of sites and subsites is 125 sites with 2,000 subsites each, for a total of 250,000 sites.
Sharing and isolation
Sites include built-in navigation from one subsite to another within a site collection. There is no built-in navigation from one site collection to another.
As with site collections, separate sites are vulnerable to cross-site scripting attacks from other sites within the domain.
Configurable elements
From within each site, you can add user or group accounts to the Owners group for that site.
Administration
You can use Microsoft Office SharePoint Designer 2007 to back up and restore individual sites. For more information about site administration, see the following articles:
Back up, restore, or move a SharePoint site (https://go.microsoft.com/fwlink/?LinkId=85710)
Planifier la création et la maintenance de sites (Office SharePoint Server)
Planning recommendations
For information about planning sites, see the following articles:
Host-named site collections
Host-named site collections are an option if you want to create multiple root-level site collections within a Web application. For example, administrators for hosting organizations use host-named site collections to create multiple domain-named sites.
There is no special mode, such as host header mode, that is required to create host-named site collections. You create host-named site collections by using the Stsadm command-line tool.
Host-named site collections give you more control over URLs. However, there are tradeoffs. The following caveats apply to host-named site collections:
Host-named site collections are only available through the Default zone. User accounts that are configured to authenticate through other zones cannot access host-named site collections.
The alternate access mapping feature does not work with host-named site collections. The alternate access mapping feature provides support for off-box termination of SSL, which enables the remote employee access and partner access scenarios to use SSL (HTTPS).
Capacity
You can create up to 100,000 host-named site collections within a single IIS Web site.
Sharing and isolation
The independent domain names that result from host-named site collections help to prevent cross-site scripting attacks between two sites.
Administration
Administrative tasks for host-named site collections include the following:
Add host-named site collections by using the Stsadm command-line tool.
Each host-named site collection requires a separate DNS entry.
Planning recommendations
For information about creating host-named site collections by using the Stsadm command-line tool and using host-named site collections in a hosting environment, see White paper: Create shared hosting solutions on Windows SharePoint Services.
My Sites
In Office SharePoint Server 2007, My Sites are special SharePoint sites that are personalized for each user. My Sites are enabled by default, and every user in an organization has a unique My Site. For information about capacity, sharing and isolation, and administration, see "Sites" earlier in this article.
For information about planning for My Sites, see the following resources:
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Office SharePoint Server 2007.