Composants de l’architecture logique (Windows SharePoint Services)
Mise à jour : 2009-04-23
Dans cet article :
Batteries de serveurs
Pools d’applications IIS
Applications Web.
Zones
Stratégie d'une application Web
Bases de données de contenu
Collections de sites
Sites
Collections de sites nommées par l’hôte
Il existe diverses façons d’organiser les composants dans la conception d’une architecture logique. Chacun des composants présente différentes opportunités pour le partage et l’isolation. Avant de commencer la conception de votre architecture logique, effectuez les opérations suivantes :
Déterminez vos objectifs en matière de partage et d’isolation.
Évaluez les compromis pour chaque choix.
Chaque section de cet article décrit un composant particulier de l’architecture logique et traite également des points suivants pour ce composant : capacité, partage et isolation, éléments configurables, administration et recommandations pour la planification.
Batteries de serveurs
D’un point de vue technique, les batteries de serveurs ne constituent pas un composant de l’architecture logique. Cependant, une batterie de serveurs représente l’élément de niveau supérieur d’une conception. Les batteries de serveurs individuelles assurent l’isolation physique.
Plusieurs critères déterminés par votre organisation peuvent affecter le nombre de batteries de serveurs requises, notamment les suivants :
divisions opérationnelles de responsabilité distinctes ;
sources de financement dédiées ;
emplacements de centre de données distincts ;
exigences sectorielles relatives à l’isolation physique entre les sites.
Toutefois, vous pouvez répondre à de nombreux besoins d’isolation dans une même batterie de serveurs. Par exemple, vous pouvez utiliser différents pools d’applications IIS (Internet Information Services) avec différentes identités de processus pour obtenir l’isolation au niveau du processus. Vous pouvez également utiliser des applications Web distinctes pour obtenir l’isolation au niveau de l’application Web.
Outre des exigences d’isolation qui peuvent requérir plus d’une batterie de serveurs, une organisation peut implémenter plusieurs batteries de serveurs pour satisfaire des objectifs en matière de performances et de mise à l’échelle.
Pools d’applications
Un pool d’applications est un regroupement d’une ou de plusieurs URL (ou sites Web tels que représentés dans IIS) pris en charge par un processus de traitement. Chaque pool d’applications possède ses propres processus de traitement et identité (compte de sécurité), ce qui empêche deux processus d’interagir.
Capacité
La mémoire dédiée à un pool d’applications est comprise entre 30 et 50 mégaoctets (Mo), à laquelle s’ajoute celle dédiée aux applications en cours d’exécution dans l’espace du processus de pool d’applications. Le nombre maximal de pools d’applications dépend de la mémoire disponible sur le système. Concrètement, le nombre de pools d’applications est tributaire des deux facteurs suivants :
mémoire adressable disponible ;
taille de l’application en cours d’exécution dans le pool d’applications.
Pour obtenir des performances acceptables, il est généralement recommandé d’utiliser au maximum huit pools d’applications.
Partage et isolation
Les pools d’applications IIS permettent à plusieurs sites de s’exécuter sur le même ordinateur serveur tout en disposant de leurs propres processus de traitement et identité. Cela peut aider à prévenir une agression contre un site par injection d’un code malveillant susceptible d’attaquer des sites dans différents pools d’applications.
Éléments configurables
Utilisez une identité de pool d’applications distincte pour chaque pool d’applications.
Administration
L’administration consiste à gérer des identités de pool d’applications distinctes pour chaque pool d’applications.
Recommandations pour la planification
D’un point de vue pratique, envisagez d’utiliser un pool d’applications dédié pour chacune des raisons suivantes :
pour séparer le contenu authentifié du contenu anonyme ;
pour isoler les applications qui stockent des mots de passe pour des applications de gestion externes et qui interagissent avec celles-ci ;
pour isoler les applications qui offrent aux utilisateurs de nombreuses possibilités pour créer et administrer des sites et pour collaborer au contenu.
Applications Web
Une application Web est un site Web IIS qui est créé et utilisé par les produits et technologies SharePoint. Chaque application Web est représentée par un site Web différent dans IIS. Vous affectez à chaque application Web un nom de domaine unique, ce qui facilite la prévention des attaques de script entre sites.
Capacité
Chaque page ASP.NET génère une bibliothèque de liens dynamiques bibliothèque (DLL, Dynamic-Link Library) distincte pour chaque application Web. Les différentes DLL consomment de la mémoire, ce qui limite le nombre d’applications Web pouvant s’exécuter sur un serveur. Pour obtenir des performances acceptables, il est recommandé d’implémenter au maximum 99 applications Web.
Partage et isolation
Les galeries et les modèles sont enregistrés dans la base de données de configuration de la batterie de serveurs. Vous pouvez spécifier les applications Web qui peuvent les utiliser.
Chaque application Web possède un nom de domaine unique, ce qui facilite la prévention des attaques de script entre sites.
Éléments configurables
Le tableau suivant répertorie les éléments configurables qui contribuent à l’isolation et au partage.
| Élément | Description |
|---|---|
Zones |
Dans une application Web, vous pouvez créer jusqu’à cinq zones. Les zones vous permettent d’appliquer différentes conditions d’accès et de stratégie à des classes d’utilisateurs volumineuses. |
Stratégie de l’application Web |
Créez une stratégie « Toutes les zones » pour appliquer une condition de stratégie à l’ensemble des zones de l’application Web. |
Administration
L’administration en cours des applications Web n’est pas significative.
Recommandations pour la planification
En règle générale, utilisez des applications Web dédiées pour effectuer les opérations suivantes :
Séparer le contenu accessible aux utilisateurs anonymes du contenu accessible aux utilisateurs authentifiés.
Isoler les utilisateurs. Par exemple, vous pouvez faire en sorte que les partenaires n’aient pas accès au contenu intranet en plaçant les sites partenaires dans une application Web distincte.
Appliquer des autorisations. Une application Web dédiée permet d’appliquer des autorisations par stratégies à l’aide de la page Stratégie de l’application Web de l’Administration centrale. Par exemple, vous pouvez créer une stratégie pour refuser explicitement l’accès en écriture à un ou plusieurs groupes d’utilisateurs. Les stratégies d’une application Web sont appliquées indépendamment des autorisations configurées sur les différents sites ou documents au sein de l’application Web.
Optimiser les performances de la base de données. Les applications obtiennent de meilleures performances si elles sont placées dans les applications Web en compagnie d’autres applications présentant des caractéristiques de données similaires. Par exemple, les caractéristiques de données de Mes sites englobent généralement un nombre élevé de sites de petite taille. En revanche, les sites d’équipe comprennent généralement un nombre réduit de sites très volumineux. Lorsque ces deux types différents de sites sont placés dans des applications Web distinctes, les bases de données obtenues sont composées de données qui présentent des caractéristiques similaires, ce qui optimise les performances des bases de données.
Optimiser la facilité de gestion. Étant donné que la création d’applications Web distinctes aboutit à des sites et à des bases de données distincts, vous pouvez implémenter des limites différentes pour la Corbeille, l’expiration et la taille de chaque site et négocier différents contrats de niveau de service. Par exemple, vous pouvez autoriser davantage de temps pour la restauration des sites qui ne sont pas critiques pour votre entreprise.
Zones
Les zones représentent différents chemins logiques (URL) d’accès à la même application Web. Dans chaque application Web, vous pouvez créer jusqu’à cinq zones à l’aide de l’un des noms de zone disponibles : Par défaut, Intranet, Internet, Personnalisée ou Extranet. Chaque zone est représentée par un site Web différent dans IIS.
La zone Par défaut est la première zone créée lors de la génération d’une application Web.
Capacité
Vous pouvez créer jusqu’à cinq zones au sein d’une application Web. Une batterie qui héberge plus d’une application Web peut prendre en charge les demandes utilisateur émanant de plus de cinq zones réseau différentes. En règle générale, les zones sont coordonnées dans l’ensemble des applications Web de manière à ce que les zones de même nom soient configurées pour les mêmes utilisateurs.
Partage et isolation
Les zones permettent de partitionner les utilisateurs selon les critères suivants :
**Type d’authentification **Chaque zone peut être configurée de manière à utiliser un fournisseur d’authentification distinct, ce qui vous permet de partager le même contenu entre les différentes sociétés partenaires.
**Zone réseau **Chaque zone peut être configurée de manière à prendre en charge les utilisateurs provenant d’une autre zone réseau, telle qu’un extranet or Internet.
Autorisations accordées par la stratégie Vous pouvez explicitement autoriser ou refuser l’accès en écriture ou en lecture au contenu par zone en fonction d’un compte d’utilisateur ou d’un compte de groupe.
Éléments configurables
Le tableau suivant répertorie les éléments configurables qui contribuent à l’isolation et au partage.
| Élément | Description |
|---|---|
Fournisseur d’authentification |
Chaque zone peut être configurée pour utiliser un fournisseur d’authentification distinct. |
SSL (Secure Sockets Layer) |
Activez ou désactivez SSL par zone. |
URL avec équilibrage de la charge réseau et mappage des accès de substitution |
Spécifiez le nom de domaine que les utilisateurs devront entrer pour accéder au contenu dans l’application Web. Vous pouvez également utiliser le mappage des accès de substitution pour mapper des URL conviviales ou appropriées pour une zone sur l’URL par défaut (nom de serveur et port) de chaque zone. Le mappage des accès de substitution prend en charge l’arrêt de SSL sur un autre ordinateur. L’arrêt de SSL sur un autre ordinateur intervient lorsqu’un serveur proxy met fin à une demande SSL, puis la transfère à un serveur Web à l’aide du protocole HTTP. Dans ce cas, des mappages des accès de substitution peuvent être configurés pour renvoyer ces demandes à l’aide de SSL, ce qui permet de maintenir une communication sécurisée entre le client et le serveur proxy. |
Stratégie de l’application Web |
Créez un jeu de stratégies unique pour chaque zone de l’application Web. Si vous avez un groupe spécial d’utilisateurs qui nécessitent des exceptions à votre stratégie de sécurité globale, pensez à utiliser une zone distincte pour prendre en charge ces utilisateurs. |
Administration
Si vous utilisez le mappage des accès de substitution, considérez que toutes les URL publiques nécessitent des entrées DNS (Domain Name System) pour mapper les URL publiques sur l’adresse IP de l’équilibreur de charge utilisé pour la batterie.
Recommandations pour la planification
Lorsque vous créez des zones, plusieurs décisions fondamentales déterminent la réussite du déploiement. Ces décisions concernent la conception et la configuration des zones suivantes :
zone Par défaut ;
zones pour l’accès externe.
Les sections suivantes décrivent certaines recommandations et exigences relatives à la planification des zones.
Exigences liées à la configuration de la zone Par défaut
La zone qui implique la plus grande attention est la zone Par défaut. Les exigences suivantes déterminent la configuration de la zone Par défaut :
La zone Par défaut doit être la zone la plus sécurisée. En effet, lorsqu’une demande utilisateur ne peut pas être associée à une zone, l’authentification et les stratégies de la zone Par défaut sont appliquées.
Le composant d’index doit pouvoir accéder au contenu via au moins une zone pour analyser celui-ci. Par défaut, le composant d’index utilise l’authentification NTLM. L’administrateur du service de recherche peut configurer des règles d’analyse afin que soit utilisé l’authentification de base ou un certificat client lors de l’analyse d’une plage d’URL spécifique. Par conséquent, pour l’analyse du contenu, au moins une des zones doit être configurée de manière à utiliser l’authentification NTLM, l’authentification de base ou des certificats. En outre, le robot interroge les zones dans l’ordre suivant jusqu’à ce qu’il rencontre une zone via laquelle il peut s’authentifier : zone Par défaut, intranet Zone, zone Internet, zone Personnalisée, zone Extranet. Toutefois, si le robot rencontre d’abord une zone configurée pour utiliser l’authentification Kerberos, il ne s’authentifie pas et ne tente pas d’accéder à la zone suivante. Par conséquent, assurez-vous que la configuration de zones utilisant l’authentification Kerberos n’empêche pas le composant d’index d’analyser le contenu. Pour plus d’informations sur les conditions requises d’authentification pour l’analyse du contenu, voir Planifier des méthodes d’authentification (Windows SharePoint Services).
Des messages électroniques d’administration contenant des liens sont envoyés à partir de la zone Par défaut. Cela inclut les courriers envoyés aux propriétaires de sites qui approchent les limites de quota. Par conséquent, les utilisateurs qui reçoivent des messages électroniques d’administration et des alertes doivent pouvoir accéder aux liens via la zone Par défaut. Cela est particulièrement important pour les propriétaires de sites.
Les collections de sites nommées par l’hôte sont uniquement disponibles via la zone Par défaut. Tous les utilisateurs susceptibles d’accéder aux collections de sites nommées par l’hôte doivent avoir accès à la zone Par défaut.
Configuration des zones pour un environnement extranet
Dans un environnement extranet, la conception de zones est essentielle pour deux raisons :
Les demandes des utilisateurs peuvent être lancées depuis plusieurs réseaux différents, tels que le réseau interne, un réseau de la société partenaire ou Internet.
Les utilisateurs consomment le contenu à travers plusieurs applications Web. Par exemple, un environnement intranet peut inclure les sites hébergés dans plusieurs applications Web différentes. En outre, les employés peuvent avoir accès à la fois au contenu Intranet et au contenu de collaboration avec les partenaires.
Dans un environnement extranet, assurez-vous que les principes de conception suivants sont suivis :
Configurez les zones dans différentes applications Web de façon à les mettre en miroir mutuellement. La configuration de l’authentification et les utilisateurs prévus doivent être identiques. Toutefois, les stratégies associées aux zones peuvent différer d’une application Web à l’autre. Par exemple, assurez-vous que la zone Intranet est utilisée pour les mêmes employés dans toutes les applications Web. En d’autres termes, ne configurez pas la zone Intranet pour les employés internes dans une application Web et pour les employés distants dans une autre.
Configurez les mappages des accès de substitution de manière appropriée et avec précision pour chaque zone et chaque ressource.
Stratégie d'une application Web
Une stratégie d'une application Web applique des autorisations sur tout le contenu dans une application Web, ce qui vous permet de définir la stratégie de sécurité pour les utilisateurs au niveau de l’application Web. Les autorisations dans une stratégie substituent tous les autres paramètres de sécurité qui sont configurés pour les sites et le contenu.
Vous pouvez configurer la stratégie en fonction des utilisateurs ou des groupes d’utilisateurs, mais pas en fonction des groupes SharePoint. Une stratégie peut être définie pour l’application Web en général ou uniquement pour une zone spécifique.
Capacité
Aucune restriction de capacité ne s’applique aux stratégies des applications Web.
Partage et isolation
Une stratégie d’une application Web permet de définir des autorisations basées sur les utilisateurs et sur la zone via laquelle ils accèdent au contenu.
Par exemple, à l’aide d’une stratégie, vous pouvez :
autoriser le personnel d’assistance à accéder à la totalité du contenu ;
refuser l’accès en écriture aux partenaires ou aux fournisseurs ;
refuser l’accès aux données sécurisées à une classe d’utilisateurs, quelle que soit la façon dont les propriétaires de sites configurent les autorisations ;
faire en sorte que l’accès dont dispose le compte d’analyse permette d’analyser tout le contenu.
Éléments configurables
Le tableau suivant répertorie les éléments configurables qui contribuent à l’isolation et au partage.
| Élément | Description |
|---|---|
Zone |
Appliquez une stratégie à une zone spécifique dans l’application Web, telle que la zone Intranet, ou à toutes les zones au sein de l’application Web. |
Utilisateurs |
Spécifiez les utilisateurs auxquels appliquer la stratégie en utilisant l’un des paramètres suivants :
|
Autorisations |
Choisissez les autorisations que vous souhaitez appliquer pour les utilisateurs :
Ces autorisations substituent les autorisations affectées dans l’application Web, y compris les autorisations définies pour les collections de sites, les sites, les listes, les documents, etc. |
Administration
L’administration en cours des stratégies des applications Web n’est pas significative.
Recommandations pour la planification
Étant donné que les stratégies sont gérées de manière centralisée, envisagez d’utiliser des stratégies pour gérer des classes d’utilisateurs volumineuses, plutôt que des utilisateurs individuels.
Bases de données de contenu
Par défaut, tout le contenu d’une application Web est stocké dans une base de données de contenu. Vous pouvez répartir le contenu dans plusieurs bases de données de contenu au niveau de la collection de sites. Une base de données de contenu peut inclure une ou plusieurs collections de sites. Une même collection de sites ne peut pas englober plusieurs bases de données. La sauvegarde et la restauration des sites ont lieu au niveau de la base de données de contenu.
Capacité
Pour obtenir des performances acceptables, il est recommandé d’implémenter au maximum 99 bases de données de contenu par application Web.
Partage et isolation
La planification des bases de données permet d’optimiser l’efficacité (plusieurs collections de sites partagent une base de données) ou l’isolation (une base de données par collection de sites).
Pour obtenir une efficacité de mise à l’échelle, gérez les bases de données en fonction de la taille cible maximale. En l’occurrence, vous configurez les paramètres de base de données de manière à ajouter de nouvelles collections de sites aux bases de données existantes jusqu’à ce que le nombre maximal de collections de sites ait été atteint. Vous calculez le nombre maximal de collections de sites en estimant la taille moyenne ou maximale des collections de sites divisée par la taille cible maximale de la base de données. Cette approche fonctionne correctement dans la perspective d’un nombre élevé de collections de sites de petite taille, tels que Mes sites.
Pour obtenir l’isolation du contenu entre les équipes ou les projets, limitez une base de données à une seule collection de sites. Cette approche vous permet de gérer le contenu des différentes équipes de manière indépendante. Par exemple, vous pouvez gérer de manière indépendante la base de données de chaque équipe pour les opérations de sauvegarde, de récupération et de migration. Cette approche offre la possibilité d’implémenter différents contrats de niveau de service pour différents projets ou équipes. Cette approche permet également de gérer du contenu tout au long du cycle de vie d’un projet. Par exemple, vous pouvez archiver une base de données une fois un projet terminé.
Éléments configurables
Le tableau suivant répertorie les éléments configurables qui contribuent à l’isolation et au partage.
| Élément | Description |
|---|---|
Serveur de bases de données |
Spécifiez l’ordinateur SQL Server sur lequel une base de données de contenu est créée. |
Serveur de recherche |
Associez un serveur de recherche à chaque base de données de contenu. |
Paramètres de capacité |
|
Administration
Un plan d’administration de base de données gérable trouve un point d’équilibre entre le nombre de bases de données et les ressources requises pour gérer les bases de données.
L’administration des bases de données comprend les opérations suivantes :
création de nouvelles bases de données pour de nouveaux sites d’équipes ou de nouvelles collections de sites qui nécessitent des bases de données dédiées ;
surveillance des tailles des bases de données et création de nouvelles bases de données à l’approche des tailles cibles ;
sauvegarde et restauration des bases de données.
Recommandations pour la planification
Choisissez l’une des deux approches suivantes :
Établissez les tailles cibles des bases de données de contenu en définissant des seuils d’avertissement correspondants appropriés. Créez de nouvelles bases de données lorsque ces seuils sont atteints. Grâce à cette approche, des collections de sites sont automatiquement ajoutées à la base de données ou aux bases de données disponibles, en fonction des tailles cibles uniquement.
Associez les collections de sites à des bases de données de contenu spécifiques. Cette approche vous permet de placer une ou plusieurs collections de sites dans une base de données dédiée qui peut être gérée indépendamment des autres bases de données.
Si vous souhaitez associer les collections de sites à des bases de données de contenu spécifiques, vous pouvez utiliser les méthodes suivantes pour effectuer cette opération :
Utilisez l’outil en ligne de commande Stsadm pour créer une collection de sites dans une base de données spécifique.
Dédiez une base de données à une collection de sites spécifique en appliquant les paramètres de capacité de base de données suivants dans la page Gérer les paramètres de la base de données de contenu du site Web Administration centrale de SharePoint :
Nombre de sites avant qu’un événement d’avertissement ne soit généré : 1
Nombre maximal de sites pouvant être créés dans cette base de données : 1
Ajoutez un groupe de collections de sites à une base de données dédiée en procédant comme suit :
Dans l’application Web, créez la base de données, puis dans la page Gérer les paramètres de la base de données de contenu de l’Administration centrale, définissez l’état de la base de données sur Prêt.
Définissez l’état de toutes les autres bases de données sur Déconnecté. Tant que les bases de données de contenu sont déconnectées, aucune collection de sites ne peut être créée. Toutefois, les collections de sites existantes dans les bases de données déconnectées demeurent accessibles en lecture et en écriture.
Créez les collections de sites. Celles-ci sont automatiquement ajoutées à la base de données.
Définissez de nouveau l’état de toutes les autres bases de données sur Prêt.
Collections de sites
Une collection de sites est un ensemble de sites Web qui ont le même propriétaire et partagent des paramètres d’administration. Chaque collection de sites contient un site Web de niveau supérieur et peut contenir un ou plusieurs sous-sites.
Capacité
Pour obtenir des performances acceptables, il est recommandé d’implémenter au maximum 50 000 collections de sites par application Web. Le fait de répartir les collections de sites sur plusieurs serveurs de base de données accroît les capacités de stockage et le débit.
Partage et isolation
Les collections de sites introduisent plusieurs possibilités de partage et d’isolation qui affectent les autorisations, la navigation et le déploiement des fonctionnalités.
Les éléments suivants peuvent être partagés au sein d’une collection de sites, mais pas entre des collections de sites :
pages maîtres ;
mises en page ;
images ;
modèles de sites.
En outre, les autorisations et la navigation sont isolées au niveau de la collection de sites de l’une des manières suivantes :
Les sous-sites au sein d’une collection de sites peuvent hériter les autorisations du site de niveau supérieur.
Une collection de sites ne peut pas hériter les autorisations d’une autre collection de sites.
Il n’existe pas de navigation intégrée d’une collection de sites vers une autre.
Enfin, les résultats de la recherche fournis par Windows SharePoint Services 3.0 ne concernent qu’une collection de sites spécifique. Les résultats de la recherche communiqués par Windows SharePoint Services 3.0 n’englobent pas plusieurs collections de sites.
Il est important de noter que même si les autorisations sont appliquées sur des sites individuels, les sites demeurent vulnérables aux attaques de script entre sites à partir d’autres sites du même domaine.
Éléments configurables
Le tableau suivant répertorie les éléments configurables de l’Administration centrale qui contribuent à l’isolation et au partage.
| Élément | Description |
|---|---|
Administrateur de collection de sites |
Vous pouvez définir un utilisateur en tant qu’administrateur principal de la collection de sites et un autre en tant qu’administrateur secondaire de la collection de sites. Dans l’Administration centrale, vous ne pouvez pas entrer plus d’un compte pour ces rôles, ni un compte de groupe pour ceux-ci. |
Modèle de quota |
Vous pouvez appliquer un modèle de quota pour limiter les ressources utilisées pour une collection de sites. Les modèles suivants sont fournis :
|
Le tableau suivant répertorie les éléments configurables au sein d’une collection de sites qui contribuent à l’isolation et au partage.
| Élément | Description |
|---|---|
Administrateurs de collections de sites |
Vous pouvez définir plusieurs comptes d’utilisateurs en tant qu’administrateurs de collections de sites. Vous ne pouvez pas ajouter de comptes de groupes. |
Niveau d’autorisation |
Ajoutez des comptes d’utilisateurs et de groupes aux collections de sites et spécifiez les niveaux d’autorisation correspondants. |
Administration
La création de collections de sites ne requiert pas d’entrées DNS et peut être facilement automatisée ou déléguée aux utilisateurs. Vous pouvez créer des collections de sites pour vos sites d’équipe de manière centralisée, ou vous pouvez permettre aux utilisateurs de créer leurs propres collections de sites à l’aide de la gestion de sites libre-service. L’affectation d’une collection de sites à une base de données spécifique offre la possibilité d’effectuer la sauvegarde et la récupération au niveau de la collection de sites.
Recommandations pour la planification
Les collections de sites relient l’architecture logique et l’architecture des informations. Lorsque vous élaborez vos collections de sites, envisagez les deux tâches de conception suivantes :
Concevez des URL cohérentes au sein de votre organisation.
Créez des divisions de contenu logiques.
À moins que vous n’utilisiez des collections de sites nommées par l’hôte, chaque application Web doit avoir une collection de sites de niveau racine unique. Cela fournit un chemin URL unique vers les sites qui se trouvent dans l’application Web. C’est également une condition requise si vous implémentez plusieurs zones au sein d’une application Web.
De nombreuses organisations envisagent d’implémenter plusieurs collections de sites dans une application Web pour une utilisation par différentes équipes ou divisions en leur sein. Parmi les objectifs conceptuels courants citons les suivants :
gérer une collection de sites distincte et indépendante pour chaque équipe ;
créer une URL unique pour chaque équipe.
Pour satisfaire ces objectifs, vous pouvez utiliser des chemins d’accès gérés afin d’incorporer plusieurs collections de sites de niveau supérieur dans une application Web. En définissant des chemins d’accès gérés, vous pouvez spécifier quels chemins d’accès dans l’espace de noms d’URL d’une application Web sont utilisés pour les collections de sites. Vous pouvez spécifier l’existence d’une seule collection de sites ou de plus d’une collection de sites sur un chemin d’accès distinct sous le site racine. En l’absence de chemins d’accès gérés, tous les sites créés sous la collection de sites racine font partie de celle-ci.
Vous pouvez créer les deux types de chemins d’accès gérés suivants :
Inclusion explicite Collection de sites comportant l’URL explicite que vous affectez. Une inclusion explicite est appliquée à une seule collection de sites. Vous pouvez associer chacune de ces collections de sites à une base de données de contenu différente si vous souhaitez gérer la croissance et permettre la sauvegarde et la restauration de ces sites séparément. http://fabrikam/hr est un exemple d’URL pour une collection de sites créée à l’aide de cette méthode. Le nombre maximal de collections de sites pouvant être créées avec une inclusion explicite est 100 environ. Si votre organisation requiert davantage de collections de sites, utilisez plutôt une inclusion générique.
Inclusion générique Chemin d’accès qui est ajouté à l’URL. Ce chemin d’accès indique que tous les sites qui sont spécifiés directement après le nom de chemin d’accès sont des collections de sites uniques. Cette option est généralement utilisée pour prendre en charge la gestion de sites libre-service, à l’image des sites créés pour la collaboration avec les partenaires. http://webpartenaire/sites/projet1 et http://webpartenaire/sites/projet2 sont des exemples d’URL pour les collections de sites créées à l’aide de cette méthode. Dans ces exemples, « http://webpartenaire » représente la collection de sites de niveau racine et « /sites » représente l’inclusion générique.
Sites
Un site est une ou plusieurs pages Web connexes qui sont hébergées à l’intérieur d’une collection de sites.
Capacité
Pour obtenir des performances acceptables, il est recommandé d’implémenter au maximum 250 000 sites par collection de sites. Vous pouvez créer un nombre total de sites Web très élevé en imbriquant les sous-sites. Par exemple, 100 sites, possédant chacun 1 000 sous-sites, constituent 100 000 sites Web. Le nombre de sites et sous-sites maximal recommandé est de 125 sites possédant chacun 2 000 sous-sites, soit un total de 250 000 sites.
Partage et isolation
Les sites permettent de naviguer d’un sous-site vers un autre au sein d’une même collection de sites. Il n’existe pas de navigation intégrée d’une collection de sites vers une autre.
À l’image des collections de sites, les différents sites sont vulnérables aux attaques de script entre sites à partir d’autres sites au sein du même domaine.
Éléments configurables
À partir de chaque site, vous pouvez ajouter des comptes d’utilisateurs ou de groupes au groupe Propriétaires correspondant.
Administration
Vous pouvez utiliser Microsoft Office SharePoint Designer 2007 pour sauvegarder et restaurer des sites spécifiques. Pour plus d’informations sur l’administration des sites, voir les articles suivants :
Sauvegarder, restaurer ou déplacer un site SharePoint (https://office.microsoft.com/fr-fr/sharepointdesigner/HA100699391036.aspx?pid=CH100667731036)
Planifier la création et la maintenance de sites (Windows SharePoint Services)
Recommandations pour la planification
Pour plus d’informations sur la planification des sites, voir l’article suivant : Planifier la structure et la publication d'un site Web (Windows SharePoint Services).
Collections de sites nommées par l’hôte
Vous pouvez recourir aux collections de sites nommées par l’hôte si vous souhaitez créer plusieurs collections de sites de niveau racine dans une application Web. Par exemple, les administrateurs d’organisations d’hébergement utilisent des collections de sites nommées par l’hôte pour créer plusieurs sites nommés par le domaine.
Aucun mode particulier, tel que le mode d’en-tête de l’hôte, n’est nécessaire pour créer des collections de sites nommées par l’hôte. Vous créez des collections de sites nommées par l’hôte à l’aide de l’outil en ligne de commande Stsadm.
Les collections de sites nommées par l’hôte vous permettent de contrôler davantage les URL. Cependant, en contrepartie, les contraintes suivantes s’appliquent aux collections de sites nommées par l’hôte :
Les collections de sites nommées par l’hôte sont uniquement disponibles via la zone Par défaut. Les comptes d’utilisateurs qui sont configurés pour s’authentifier via d’autres zones ne peuvent pas accéder aux collections de sites nommées par l’hôte.
La fonctionnalité de mappage des accès de substitution ne fonctionne pas avec les collections de sites nommées par l’hôte. La fonctionnalité de mappage des accès de substitution prend en charge l’arrêt de SSL sur un autre ordinateur, ce qui permet aux scénarios d’accès des employés distants et d’accès des partenaires d’utiliser SSL (HTTPS).
Capacité
Vous pouvez créer jusqu’à 100 000 collections de sites nommées par l’hôte au sein d’un même site Web IIS.
Partage et isolation
Les noms de domaines indépendants qui résultent des collections de sites nommées par l’hôte vous permettent de prévenir les attaques de script entre deux sites.
Administration
L’administration des collections de sites nommées par l’hôte comprend les tâches suivantes :
ajouter des collections de sites nommées par l’hôte à l’aide de l’outil en ligne de commande Stsadm ;
définir une entrée DNS distincte pour chaque collection de sites nommée par l’hôte.
Recommandations pour la planification
Pour plus d’informations sur la création de collections de sites nommées par l’hôte à l’aide de l’outil en ligne de commande Stsadm et sur l’utilisation de collections de sites nommées par l’hôte dans un environnement d’hébergement, voir Livre blanc : Créer des solutions d'hébergement partagées sur Windows SharePoint Services.
Télécharger ce livre
Cette rubrique est incluse dans le livre téléchargeable suivant pour une lecture et une impression plus faciles :
Consultez la liste des livres disponibles à l’adresse Livres à télécharger pour Windows SharePoint Services.