Composants de l’architecture logique (SharePoint Server 2010)
S’applique à : SharePoint Foundation 2010, SharePoint Server 2010
Dernière rubrique modifiée : 2016-11-30
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.
Dans cet article :
Batteries de serveurs
Applications de service
Pools d’applications
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
Sites Mon site
Batteries de serveurs
Une batterie de serveurs représente l’élément de plus haut niveau 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 :
l’utilisation intensive de services peut justifier une ou plusieurs batteries de services dédiées ;
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.
Vous pouvez cependant 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 des processus à la fois pour les sites et pour les applications de service.
Outre des spécifications en termes d’isolation qui peuvent requérir plusieurs batteries de serveurs, une organisation peut implémenter plusieurs batteries de serveurs pour satisfaire des objectifs en matière de performances et d’évolutivité, de spécifications en termes de licences ou de contraintes liées à un environnement de publication.
Applications de service
Une application de service fournit une ressource qui peut être partagée entre les sites au sein d’une batterie de serveurs ou, dans certains cas, entre plusieurs batteries de serveurs.
Dans SharePoint Server 2010, les services ne figurent plus dans un fournisseur de services partagés (SSP). Au lieu de cela, l’infrastructure des services d’hébergement est déplacée dans Microsoft SharePoint Foundation 2010 et la configuration des offres de services est beaucoup plus souple. Les services individuels peuvent être configurés indépendamment et des fournisseurs tiers peuvent ajouter des services à la plateforme.
Vous pouvez déployer seulement les services qui sont nécessaires à une batterie de serveurs. Les services qui sont déployés sont appelés « applications de service ».
Les applications de service sont associées à des applications Web. Chaque application de service peut être configurée différemment :
Les applications Web peuvent être configurées pour utiliser uniquement les services qui sont nécessaires, et non pas l’ensemble des services qui sont déployés.
Vous pouvez déployer plusieurs instances du même service dans une batterie de serveurs et affecter des noms uniques aux applications de service qui en résultent.
Vous pouvez partager des applications de service entre plusieurs applications Web au sein de la même batterie de serveurs.
Certaines applications de service peuvent être partagées entre des batteries.
Capacité
Il n’y a pas de limite recommandée quant au nombre d’applications de service dans une même batterie de serveurs.
Partage et isolation
Les applications de service peuvent être partagées de deux manières :
Partage de l’application de service et des données du service. Il s’agit du comportement par défaut pour les services qui sont partagés par plusieurs applications Web. Par exemple, les résultats de la recherche sont partagés par des applications Web qui utilisent la même application de recherche.
Partage de l’application de service seulement, mais isolation des données en déployant le service en mode partitionné. Dans un environnement hébergé, vous pouvez déployer des applications de service en mode partitionné à l’aide de Windows PowerShell. Les données de chaque client sont stockées dans une partition distincte de la base de données pour le service. Un ID d’abonnement du client est utilisé pour mapper les données de service du client à ses sites. Par exemple, si vous déployez le service de recherche en mode partitionné, chaque client verra uniquement les résultats de la recherche pour son propre contenu.
Notes
Certaines applications de service ne prennent pas en charge le partitionnement.
Inversement, les applications de service peuvent être isolées de deux manières :
Déploiement de plusieurs applications de service dans des pools d’applications distincts pour obtenir l’isolation des processus des services et des données de service. Par exemple, une équipe d’un département Finances peut justifier une application Business Data Connectivity distincte et dédiée.
Déploiement des services en mode partitionné. Cette approche fonctionne bien dans des environnements hébergés où les clients ne partageront jamais les données de service. Toutefois, il peut ne pas être pratique dans les environnements où il y a une combinaison de besoins de données de service partagées et isolées.
Si nécessaire, vous pouvez aussi isoler des applications de service en les déployant sur des pools d’applications distincts pour obtenir l’isolation des processus.Toutefois, les pools d’applications constituent une ressource limitée, et les performances de la batterie de serveurs sont affectées si trop de pools d’applications sont utilisés. Pour plus d’informations, voir Application pools dans cet article.
Éléments configurables
Le tableau suivant montre les éléments configurables qui contribuent à l’isolation et au partage.
Élément |
Description |
Groupe par défaut |
Par défaut, toutes les applications de service sont incluses dans le groupe par défaut. Vous pouvez ajouter et supprimer à tout moment des applications de service dans le groupe par défaut, notamment lorsque vous en créez une. Lorsque vous créez une application Web, vous pouvez sélectionner le groupe par défaut ou bien vous pouvez créer un groupe personnalisé de services. Vous créez un groupe personnalisé de services en sélectionnant uniquement les applications de service que l’application Web doit utiliser. |
Connexion (proxy) |
Lorsque vous créez une application de service, une connexion est créée en même temps pour l’application de service. Une connexion est une entité virtuelle qui connecte des applications Web à des applications de service. Certaines applications de service, telles que le service de métadonnées gérées, stockent des paramètres dans les connexions. Dans Windows PowerShell, les connexions sont appelées des proxys. |
Autorisations des applications de service |
Vous pouvez déléguer la gestion des applications de service à d’autres utilisateurs en leur accordant des autorisations sur une ou plusieurs applications de service. |
Emplacements d’hébergement de sites Mon site approuvés |
Dans les organisations où plusieurs applications de service de profil utilisateur sont déployées, cette fonctionnalité garantit que les utilisateurs créent un site Mon Site à l’emplacement prévu pour leur profil. Cette fonctionnalité empêche les utilisateurs de créer plusieurs sites Mon Site au sein d’une organisation. |
Administration
La configuration et la gestion des applications de service peuvent être déléguées à des administrateurs spécialisés dans la gestion des services individuels, tels que la recherche, les profils utilisateur et les métadonnées gérées.
Dans un environnement hébergé, les clients peuvent gérer certains des paramètres du service pour leur organisation.
Recommandations pour la planification
Configurez les applications de service pour qu’elles partagent les ressources entre plusieurs applications Web ou pour qu’elles isolent le contenu.
Par exemple, plusieurs sites qui se trouvent dans différentes applications Web et différents pools d’applications peuvent être unifiés en partageant des services dans le groupe de proxys par défaut pour fournir une taxonomie, un type de contenu et le partage de profils sur un intranet. Ceci permet la personnalisation et la normalisation à l’échelle de l’entreprise pour de nombreux sites et applications. Ce choix offre un exemple d’équilibre entre l’isolation des processus (en implémentant des applications Web distinctes et des pools d’applications distincts) et le besoin pour l’entreprise de partager des informations et de tirer profit des données de profil dans les applications.
Vous pouvez également configurer des applications de service pour améliorer vos objectifs d’isolation globale. Par exemple, l’utilisation d’un ensemble dédié de services de collaboration des partenaires garantit que les utilisateurs partenaires ne peuvent pas effectuer de recherches sur des informations sensibles ni y accéder dans votre environnement d’intranet. Vous pouvez configurer des services particuliers afin d’isoler davantage le contenu entre les collections de sites. Par exemple, vous pouvez :
Limiter les étendues de recherche aux collections de sites individuelles.
Configurer le service de profil utilisateur pour afficher uniquement les utilisateurs qui font partie de la même unité d’organisation dans les services de domaine Active Directory (AD DS).
Utiliser l’outil en ligne de commande Stsadm pour configurer le sélecteur de personnes afin d’afficher uniquement les utilisateurs qui sont membres de la collection de sites.
Lors de la conception de votre stratégie de services pour une organisation, réfléchissez aux différentes façons de configurer les services individuels pour améliorer vos objectifs globaux d’isolation ou de partage de contenu.
Lorsque vous concevez une stratégie de services pour un environnement d’hébergement, déterminez quels services seront disponibles et partitionnés.
Pools d’applications
Dans Internet Information Services (IIS) 7.0, un pool d’applications est un groupe d’une ou plusieurs URL servies par un processus ou un ensemble de processus de traitement.
Lorsque vous créez des collections de sites et des services dans les produits SharePoint 2010, vous sélectionnez un pool d’applications à utiliser, ou bien vous pouvez créer un nouveau pool d’applications. Chaque pool d’applications a son propre processus de traitement et peut avoir une identité distincte (compte de sécurité), ce qui empêche l’interaction de deux processus.
Capacité
La mémoire dédiée à un pool d’applications est comprise entre 30 et 50 mégaoctets (Mo), à laquelle s’ajoute celle qui est dédiée aux applications en cours d’exécution dans l’espace du processus de pool d’applications. En général, les différentes demandes des applications conduisent rapidement un pool d’applications à utiliser un espace en mémoire de 800 Mo ou davantage. 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 plus huit pools d’applications.
Partage et isolation
Les pools d’applications IIS permettent à plusieurs sites de s’exécuter sur le même serveur tout en disposant de leurs propres processus de traitement et de leur propre identité. Ceci 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. Plus important encore, cette stratégie isole le code qui provoque des problèmes de mémoire ou d’autres problèmes, de sorte que le code posant problème n’affecte pas toutes les applications.
Éléments configurables
L’utilisation d’une identité de pool d’applications distincte pour chaque pool d’applications est recommandée si elle est nécessaire pour des raisons de sécurité et d’isolation.
Administration
Si des identités distinctes sont utilisées pour chaque pool d’applications, chaque identité devra être conservée.
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 qui est principalement anonyme ;
pour isoler les applications qui stockent des mots de passe pour des applications métiers externes et interagissent avec celles-ci, par exemple des connexions Business Data Connectivity.
Applications Web
Une application Web est un site Web IIS qui est créé et utilisé par les produits SharePoint 2010. Une application Web peut être étendue jusqu’à quatre fois pour créer quatre zones supplémentaires dans les produits SharePoint 2010, aboutissant à un maximum de cinq sites Web IIS qui sont associés à une même application Web, chaque site Web IIS étant associé à une zone différente. Vous pouvez affecter un nom de domaine unique à chaque application Web. Pour plus d’informations, voir Zones dans cet article.
Partage et isolation
Chaque application Web a un nom de domaine unique, ce qui facilite la prévention des attaques de script entre sites.
Éléments configurables
Le tableau suivant montre les éléments configurables qui contribuent à l’isolation et au partage.
Élément |
Description |
Applications de service |
Les applications de service sont associées à des applications Web. Lorsque vous créez une application Web, vous pouvez sélectionner le groupe de proxy par défaut (option par défaut pour les applications de service), ou bien vous pouvez spécifier un ensemble personnalisé d’applications de service pour l’application Web. Tous les sites au sein d’une application Web consomment des services des mêmes applications de service. Une application de service peut fournir des services pour plusieurs applications Web, partageant ainsi le contenu et les données de profil entre les applications Web. |
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 pour des grands groupes d’utilisateurs. |
Stratégie de l’application Web |
Créer une stratégie pour appliquer des autorisations sur une ou plusieurs zones dans une application Web. Il est possible de créer une stratégie pour un utilisateur ou un groupe d’utilisateurs spécifique. Pour plus d’informations, voir Stratégie d’une application Web dans cet article. |
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 via l’utilisation de stratégies. 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 des bases de données de contenu avec d’autres applications ayant des caractéristiques de données similaires. Par exemple, les caractéristiques des données de sites Mon site comprennent généralement un grand nombre 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 d’accès logiques (URL) à 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 nom ne peut être sélectionné qu’une seule fois par application Web. 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. Les autres zones sont créées par extension d’une application Web.
Capacité
Vous pouvez créer jusqu’à cinq zones au sein d’une application Web. 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 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 ou 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 montre 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. |
Accès anonyme |
Activer ou désactiver l’accès anonyme par zone. |
SSL (Secure Sockets Layer) |
Activer ou désactiver SSL par zone. |
URL publique 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 requièrent 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 des recommandations en termes de planification et des spécifications requises pour les zones, y compris la zone par défaut.
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. Ceci 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.
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.
Dans un environnement extranet, la conception des 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 respectés :
Configurez les zones dans différentes applications Web de façon à les mettre en miroir les unes des autres. 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 application Web.
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 d’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 d’une stratégie remplacent tous les autres paramètres de sécurité qui sont configurés pour les sites et pour le contenu.
Vous pouvez configurer la stratégie en fonction des utilisateurs ou des groupes d’utilisateurs des services de domaine Active Directory, 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.
À l’aide d’une stratégie, vous pouvez par exemple :
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 à un groupe 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 montre les éléments configurables qui contribuent à l’isolation et au partage.
Élément |
Description |
Stratégie de l’utilisateur |
Créer une stratégie qui s’applique à des utilisateurs ou à des groupes d’utilisateurs :
Vous pouvez modifier les niveaux d’autorisation par défaut ou créer de nouveaux niveaux d’autorisation en cliquant sur Stratégie d’autorisation lorsque vous créez la stratégie dans l’Administration centrale. |
Stratégie anonyme |
Si l’accès anonyme est activé pour l’application Web ou pour une ou plusieurs zones, vous pouvez créer une stratégie qui s’applique à tous les utilisateurs anonymes. Les paramètres de stratégie par défaut sont les suivants :
Les niveaux de stratégie d’utilisateur anonyme ne peuvent pas être modifiés. |
Stratégie d’autorisation |
Modifiez les autorisations spécifiques associées à l’un des niveaux d’autorisation par défaut, ou bien créez un nouveau niveau de stratégie d’autorisation. En outre, vous pouvez spécifier les autorisations particulières qui sont accordées ou refusées pour les collections de sites et les sites. Après avoir créé un nouveau niveau de stratégie d’autorisation, vous pouvez créer une stratégie de l’utilisateur qui utilise la stratégie d’autorisation. |
Administration
Les tâches routinières d’administration des applications Web sont minimes.
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 les groupes importants d’utilisateurs au lieu de gérer 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 plus 100 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 un dimensionnement efficace, 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 le cadre d’un nombre élevé de collections de sites de petite taille, tels que des sites Mon site.
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 montre les éléments configurables qui contribuent à l’isolation et au partage.
Élément |
Description |
Serveur de base de données |
Spécifiez l’ordinateur SQL Server sur lequel une base de données de contenu est créée. |
Serveur de basculement |
Vous pouvez choisir d’associer une base de données de contenu à un serveur de basculement spécifique utilisé conjointement avec la mise en miroir de base de données SQL Server. |
Paramètres de capacité |
Vous pouvez spécifier le nombre de sites qui peuvent être créés avant qu’un événement d’avertissement soit généré, ainsi que le nombre maximal de sites qui peuvent être créés dans chaque base de données. |
Administration
Un plan d’administration de base de données gérable se 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 de la taille des bases de données et création de nouvelles bases de données lorsque les tailles cibles sont en passe d’être atteintes ;
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 Windows PowerShell pour créer une collection de sites dans une nouvelle base de données.
Appliquez 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é = 0
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 :
Ajoutez une base de données de contenu pour l’application Web et assurez-vous que l’état de la base de données est défini à Prêt.
Définissez l’état de toutes les autres bases de données à Hors connexion. Tant que les bases de données de contenu sont hors connexion, aucune collection de sites ne peut être créée. Toutefois, les collections de sites existantes dans les bases de données hors connexion restent accessibles en lecture et en écriture.
Créez les collections de sites. Celles-ci sont automatiquement ajoutées à la base de données en ligne.
Définissez à nouveau l’état de toutes les autres bases de données à 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 base de données de contenu ; cependant, les performances peuvent être affectées à partir d’environ 10 000 collections de sites. 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 (à l’exception des éléments qui sont stockés dans un système de fichiers, tels que des fonctionnalités dans le répertoire _layouts) :
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 des autorisations du site de plus haut niveau.
Une collection de sites ne peut pas hériter des 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, SharePoint Server 2010 agrège les résultats de la recherche dans les collections de sites en fonction des autorisations de l’utilisateur, quel que soit le nombre de collections de sites ou de bases de données (selon les étendues de recherche).
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 montre les éléments configurables qui contribuent à l’isolation et au partage.
Élément |
Description |
Administrateur de collections 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 site |
Un modèle de site détermine les listes et les fonctionnalités qui seront disponibles sur votre nouveau site. De nombreux aspects d’un site peuvent être personnalisés après la création.Toutefois, le modèle de site ne peut pas être modifié une fois que le site est créé. |
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 indique les éléments configurables au sein d’une collection de sites qui contribuent à l’isolation et au partage. Ces paramètres sont disponibles après la création de la collection de sites à l’aide des paramètres du tableau précédent.
É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 (sauf si vous créez des collections de sites nommées par l’hôte) et peut être facilement automatisée ou déléguée à des 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’utilisation d’une base de données dédiée pour une collection de sites 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 représentent le lien entre l’architecture logique et l’architecture des informations. Lorsque vous concevez vos collections de sites, considérez les deux tâches de conception suivantes :
Concevez des URL cohérentes au sein de votre organisation.
Créez des divisions de contenu logiques.
Sauf si vous utilisez des collections de sites nommées par l’hôte, chaque application Web doit avoir une collection de sites de niveau racine unique. Ceci 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. Pour plus d’informations, voir Host-named site collections dans cet article.
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 de conception 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 ;
isoler le contenu entre les équipes.
Pour atteindre 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 plusieurs collections 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 d’environ 100 dans une application Web ; 20 collections de sites constituent cependant un maximum pour un bon fonctionnement. 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 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, tels que les sites Mon site ou les 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 au niveau racine et « /sites » représente l’inclusion générique.
Sites
Un site consiste en une ou plusieurs pages Web connexes et d’autres éléments (tels que des listes, des bibliothèques et des documents) qui sont hébergés à 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. Cependant, un grand nombre de sous-sites imbriqués peut grandement affecter le temps nécessaire pour mettre les sites à jour. 5 000 sites dans une collection de sites constituent un seuil correct pour un bon fonctionnement.
Partage et isolation
Les sites permettent de naviguer d’un sous-site à l’autre au sein d’une même collection de sites. Il n’existe pas de navigation intégrée d’une collection de sites à l’autre.
À l’instar des collections de sites, les sites séparés 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 différents outils pour sauvegarder et restaurer des sites individuels.
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 Windows PowerShell. De plus, avec Windows PowerShell, vous pouvez utiliser des chemins d’accès gérés avec des collections de sites nommés par l’hôte (New-SPManagedPath –HostHeader).
Les collections de sites nommées par l’hôte vous offrent un meilleur contrôle sur les URL. Toutefois, les collections de sites nommées par l’hôte sont disponibles seulement via la zone Par défaut. Les comptes d’utilisateur qui sont configurés pour s’authentifier par l’intermédiaire d’autres zones ne peuvent pas accéder à des collections de sites nommés par l’hôte.
Dans les produits SharePoint 2010, des collections de sites nommées par l’hôte prennent en charge l’arrêt de SSL hors zone. Toutefois, seul le schéma de protocole peut être modifié hors zone (http:// ou https://). Le serveur proxy inverse ne peut pas modifier le nom d’hôte ou le numéro de port (sauf pour passer du port SSL par défaut au port HTTP par défaut).
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 Windows PowerShell ;
définir une entrée DNS distincte pour chaque collection de sites nommée par l’hôte.
Sites Mon site
Les sites Mon site sont des sites SharePoint spéciaux qui sont personnalisés pour chaque utilisateur. Ils sont activés par défaut dans le cadre du service de profil utilisateur, et chaque utilisateur d’une organisation peut créer un site Mon site unique. Pour plus d’informations sur la capacité, le partage, l’isolation et l’administration, voir Sites plus haut dans cet article.