Exemple de conception d'architecture logique : sites de collaboration
Mise à jour : 2009-04-23
Dans cet article :
À propos du modèle
Objectifs de la conception globale
Batteries de serveurs
Utilisateurs, zones et authentification
Sites d’administration
Pools d’applications
Applications Web
Collections de sites
Bases de données de contenu
Zones et URL
Stratégies de zone
Sauvegarde et restauration de sites de collaboration
Conception de la collaboration externe sécurisée
Cet article décrit une implémentation pratique des composants de l’architecture logique en vue d’obtenir une conception exploitable. Il est destiné à être utilisé avec le modèle suivant Exemple de conception d'architecture logique : collaboration Windows SharePoint Services (en anglais) (https://go.microsoft.com/fwlink/?linkid=124861&clcid=0x40C) (en anglais) .
À propos du modèle
Le modèle illustre le déploiement d'une société fictive appelée Fabrikam, Inc. Si vous planifiez une solution avec un ou plusieurs des types de sites de collaboration représentés dans ce modèle, vous pouvez vous servir du modèle comme base pour votre propre conception.
Le modèle illustre un déploiement générique de Windows SharePoint Services 3.0 avec trois types de sites de collaboration représentés :
sites d’équipe ;
sites libre-service ;
sites de collaboration entre partenaires.
Il s’applique à presque tous les composants de l’architecture logique et illustre la manière dont ceux-ci sont intégrés à la conception globale. Cet article décrit les objectifs de conception du modèle et explique comment ces objectifs sont atteints à l’aide des composants de l’architecture logique illustrés dans le modèle.
Les différents types de site de collaboration :
hébergent des données présentant différentes caractéristiques ;
sont associés à un profil d’utilisation spécifique ;
nécessitent une stratégie de gestion des autorisations spécifique.
Par conséquent, les choix en matière de conception du modèle sont destinés à optimiser les performances et la sécurité des différentes applications.
Sites d’équipe
Les sites d'équipe représentent des sites de collaboration très structurés et gérés, dans lesquels :
il y a un nombre réduit de collections de sites de niveau supérieur et ces collections de sites sont destinées à inclure une grande quantité de données (contrairement aux sites libre-service) ;
les URL de niveau supérieur sont significatives pour chaque équipe ;
les hiérarchies, taxonomies et personnalisations du site sont davantage planifiées.
Le contenu de chaque équipe se trouve dans une base de données distincte et peut être géré séparément.
Le schéma ci-dessous représente la hiérarchie de site pour les sites d'équipe :
.gif "Organisation des sites d’équipes")
Sites libre-service
Les sites libre-service constituent une alternative aux sites d'équipe qui demandent une gestion importante. Vous pouvez permettre aux utilisateurs et aux équipes de créer leurs propres collections de sites à l'aide de la gestion de sites libre-service. Vous activez la gestion de sites libre-service dans l'Administration centrale. Cette méthode est plus utilisée lorsque vous souhaitez autoriser des groupes ou des communautés à créer des sites. Cette méthode fonctionne également si vous hébergez des sites et que vous souhaitez permettre aux utilisateurs de créer des sites sans avoir à attendre un processus détaillé.
Les caractéristiques des sites libre-service sont généralement différentes des sites qui demandent une gestion importante. Ces caractères sont, par exemple, les suivantes :
un grand nombre de collections de sites de niveau supérieur ;
une petite quantité de données par collection de sites ;
des URL générées automatiquement, mais généralement sans signification.
Le schéma ci-dessous représente les sites libre-service tels qu'ils sont implémentés dans l'exemple de conception :
.gif "Sites pour la création de sites libre-service")
Il existe plusieurs inconvénients dans le fait de savoir à quel moment planifier d'implémenter des sites libre-service et ces inconvénients affectent la manière dont vous gérez ces types de site :
Au lieu d'implémenter une taxonomie réfléchie, les sites sont créés à souhait sans principe d'organisation entre les sites. Dans la mesure où chaque nouveau site est une collection de sites, les modèles et la navigation ne peuvent pas être partagés entre des sites libre-service.
Comme chaque collection de sites propose une fonction de recherche de contenu uniquement sur cette collection de sites, il n'y a pas d'agrégation des résultats de recherche entre les collections de sites.
Les collections de sites peuvent varier considérablement en termes de taille et d'utilisation.
Les sites peuvent être facilement abandonnés.
La gestion de sites libre-service peut inclure la gestion du stockage de contenu en fonction de la taille des bases de données de contenu cible et la suppression régulière des sites inutilisés.
Pour plus d'informations sur l'implémentation de la gestion de sites libre-service, reportez-vous à la rubrique Plan process for creating sites (Windows SharePoint Services).
Sites de collaboration de partenaires
L’application Web partenaire héberge des sites disponibles de manière externe pour la collaboration sécurisée avec les employés de sociétés partenaires. Cette application permet aux employés de créer facilement des sites sécurisés en vue d’une collaboration. Les facteurs clés qui déterminent le choix de cette application sont les suivants :
Isolation de contenu : les partenaires ne sont pas autorisés à accéder aux autres types de contenu hébergés sur la batterie de serveurs.
Authentification distincte des comptes des partenaires : les comptes des partenaires sont gérés par le biais de l’authentification par formulaires. Ils ne sont pas ajoutés à l’annuaire d’entreprise.
Gestion des autorisations : les différents propriétaires de sites gèrent les autorisations sur leurs sites, en invitant à collaborer uniquement les participants nécessaires.
Le schéma ci-dessous représente des sites de collaboration de partenaires.
.gif "Hiérarchie des sites de projet dans un Web partenaire")
Objectifs de la conception globale
Le modèle présente une implémentation pratique des fonctionnalités Windows SharePoint Services 3.0 dans différents types d'application de collaboration (sites d'équipe, sites libre-service et sites partenaires). L'implémentation de la conception de chacune des applications de site est abordée dans cet article. Les principaux objectifs de conception du modèle sont les suivants :
Créez un cadre permettant de concevoir un environnement susceptible de croître. Les décisions en matière de conception pour les applications de collaboration n'empêchent pas d'ajouter d'autres applications. Par exemple, un déploiement initial peut inclure des sites d'équipe de collaboration ou uniquement des sites partenaires. En utilisant une conception d'architecture logique, vous pouvez ajouter d'autres types de sites de collaboration à la solution sans affecter la conception des sites de collaboration initiaux. En d’autres termes, la conception n’incorpore pas de choix de conception qui limitent l’utilisation de l’environnement.
Permettez l'accès à plusieurs classes d'utilisateurs sans compromettre la sécurité du contenu dans différentes applications de collaboration. Les utilisateurs provenant de différentes zones réseau (internes et externes) auxquelles sont associés différents fournisseurs d’authentification peuvent participer à la collaboration. En outre, les utilisateurs peuvent uniquement accéder au contenu qui les concerne. En suivant une conception d’architecture logique similaire, vous pouvez accorder l’accès à des utilisateurs situés à différents endroits et poursuivant des objectifs différents. Par exemple, votre conception initiale peut être conçue uniquement pour l’accès des employés internes. Cependant, en utilisant une conception identique, vous pouvez permettre l'accès aux employés distants, aux employés partenaires et même aux clients.
Faites en sorte que la conception soit utilisable dans un environnement extranet. Vous pouvez effectuer des choix de conception délibérés pour vous assurer que les batteries de serveurs peuvent être déployées en toute sécurité dans un réseau de périmètre ou dans l'une des topologies extranet décrites dans la rubrique Design extranet farm topology (Windows SharePoint Services).
Le reste de cet article décrit chacun des composants logiques qui apparaissent dans le modèle (du haut vers le bas), ainsi que les choix de conception appliqués au modèle. Cette approche vise à montrer les différentes façons de configurer les composants de l’architecture logique en fonction de l’application.
Batteries de serveurs
Le modèle présente une batterie à cinq serveurs. Cependant, il peut être implémenté dans une batterie de n'importe quelle taille, y compris une batterie comportant un seul serveur. La batterie de serveurs du modèle se compose de cinq serveurs avec la topologie suivante :
deux serveurs Web frontaux ;
un serveur d'application pour le serveur de recherche ;
deux serveurs de base de données en cluster ou en miroir.
D’après le modèle qui illustre l’architecture logique d’Windows SharePoint Services 3.0 :
tous les sites sont mis en miroir sur les serveurs Web frontaux ;
le site Administration centrale est installé sur un serveur d’applications afin qu’il ne soit pas directement accessible aux utilisateurs.
En réalité, le nombre d’ordinateurs serveurs et la topologie de la batterie de serveurs ne sont pas importants pour l’architecture logique, sauf lorsqu’il s’avère nécessaire d’augmenter la capacité et les performances. L’architecture logique peut être conçue indépendamment de la topologie de la batterie de serveurs. Le processus de planification des performances et de la capacité facilite le dimensionnement de la batterie de serveurs en fonction des objectifs en termes de performances et de capacité. Pour plus d’informations, voir Plan for performance and capacity (Windows SharePoint Services).
Utilisateurs, zones et authentification
Le modèle illustre cinq classes d’utilisateurs différentes, chacune affectée à une zone spécifique. 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. Une batterie de serveurs qui héberge plus d’une application Web peut prendre en charge les demandes utilisateur provenant de plus de cinq zones réseau (jusqu’à cinq zones par application Web). Toutefois, le modèle montre uniquement cinq zones.
Utilisateurs et authentification
Le modèle présente la manière dont l'authentification est appliquée entre utilisateurs de différentes zones réseau. Le tableau ci-dessous présente également l'authentification appliquée à chaque type d'utilisateur et de zone.
| Zone | Utilisateurs | Authentification |
|---|---|---|
Intranet |
Employés internes |
NTLM (Windows intégré) |
Par défaut |
Employés distants |
NTLM (Windows intégré) ou authentification par formulaires avec LDAP (Lightweight Directory Access Protocol) |
Extranet |
Employés partenaires |
Authentification par formulaires |
Employés internes
La zone Intranet est utilisée pour l’accès des employés internes. L’authentification Windows intégrée est utilisée.
Employés distants
La zone Par défaut est utilisée pour l’accès des employés distants. Les objectifs de conception de la zone Par défaut sont les suivants :
Effectuez l’authentification auprès de l’environnement de service d’annuaire Active Directory interne.
Simplifier la gestion des autorisations en utilisant l’authentification Windows pour les employés internes et les employés distants. Cet objectif est important parce que si les utilisateurs se connectent aux sites par le biais de deux fournisseurs d’authentification différents, Windows SharePoint Services 3.0 crée deux comptes différents pour chaque utilisateur, et chacun des deux comptes doit disposer d’autorisations.
Le modèle présente deux options pour l’authentification des employés distants. Avec la première option (authentification Windows intégrée avec utilisation de NTLM), les deux objectifs de conception sont atteints. La deuxième option (authentification par formulaires LDAP) satisfait le premier objectif, mais pas le second. Par conséquent, la première option est la méthode recommandée pour les employés distants.
Le tableau ci-dessous résume les différences entre ces deux options d'authentification.
| Type de comparaison | Authentification Windows intégrée avec utilisation de NTLM | Authentification par formulaires avec utilisation d’un fournisseur LDAP |
|---|---|---|
Fonctionnalité |
Cette méthode s'appuie sur l'utilisation d'Internet Security and Acceleration (ISA) Server 2006 ou d'Intelligent Application Gateway (IAG 2007) pour authentifier les utilisateurs, puis envoyer les informations d'identification dans Windows SharePoint Services 3.0. Ces serveurs utilisent l'authentification pour authentifier des utilisateurs dans l'environnement Active Directory. Ensuite, ils transfèrent les informations d'identification Windows dans Windows SharePoint Services 3.0. Pour plus d’informations, reportez-vous aux ressources suivantes :
Étant donné que la zone est la zone Par défaut, l’authentification NTLM permet de satisfaire un besoin du composant d’index. Pour plus d’informations, voir « Contraintes liées à la configuration de la zone Par défaut » plus loin dans cet article. |
Windows SharePoint Services 3.0 utilise l’authentification par formulaires avec un fournisseur LDAP pour authentifier les employés distants auprès de l’environnement Active Directory interne. |
Avantages |
Windows SharePoint Services 3.0 ne crée pas deux comptes différents pour les utilisateurs qui travaillent à la fois en interne et à distance. Cela simplifie considérablement la gestion des autorisations. |
Ne requiert pas un serveur proxy pour l’authentification des utilisateurs et le transfert des informations d’identification. |
Inconvénients |
Requiert une coordination supplémentaire avec ISA Server 2006, IAG 2007 ou avec un autre produit de serveur proxy ou une configuration supplémentaire d’ISA Server 2006 ou d’un autre produit de serveur proxy. |
Si les utilisateurs se connectent à Windows SharePoint Services 3.0 à la fois en interne et à distance, deux comptes d’utilisateurs différents sont créés dans Windows SharePoint Services 3.0. Par conséquent, les deux comptes requièrent des autorisations sur les sites et les documents. Les employés doivent gérer les autorisations sur leurs propres sites et documents pour les deux comptes d’utilisateurs s’ils envisagent de travailler à la fois à partir du réseau interne et à distance. |
Employés partenaires
Les employés partenaires accèdent au réseau par le biais de la zone extranet et sont authentifiés à l’aide de l’authentification par formulaires. Cela requiert un annuaire et un fournisseur distincts, comme une base de données et un fournisseur Microsoft SQL Server, pour le stockage des comptes des partenaires sur le réseau extranet. Grâce à cette approche, vous pouvez gérer les comptes des partenaires séparément et vous n’avez pas besoin de les ajouter à l’annuaire des employés internes.
Si vous préférez, vous pouvez utiliser l’authentification Web unique pour effectuer l’authentification auprès de l’annuaire d’un partenaire. Toutefois, cette approche nécessite une zone distincte pour chaque annuaire du partenaire.
Étant donné que le modèle implique que Fabrikam fonctionne avec des partenaires de plusieurs sociétés différentes dans la même application partenaire, l’authentification par formulaires est utilisée. L’annuaire et le fournisseur ne sont pas spécifiés.
Zones
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 ci-dessous décrivent les décisions qui caractérisent le modèle.
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. Windows SharePoint Services 3.0 impose les contraintes suivantes quant à la configuration de la zone Par défaut :
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. Par conséquent, la zone Par défaut doit être la zone la plus sécurisée.
Le composant d’index doit pouvoir accéder au contenu via au moins une zone pour analyser celui-ci. Le composant d'index utilise l'authentification NTLM. Par conséquent, pour analyser le contenu, au moins l'une des zones doit être configurées de manière à utiliser l'authentification NTLM. De même, le robot interroge les zones dans l'ordre ci-dessous, jusqu'à ce qu'il détecte une zone par le biais de laquelle il peut s'authentifier : zone Par défaut, zone Intranet, zone Internet, zone Client et zone Extranet. Cependant, si le robot détecte d'abord une zone configurée de manière à utiliser l'authentification Kerberos, standard ou Digest, le robot ne s'authentifie pas et ne tente pas d'accéder à la zone suivante. Par conséquent, assurez-vous que la configuration des zones n'empêche pas au composant d'index d'analyser le contenu. Pour plus d’informations sur les conditions requises d’authentification pour l’analyse du contenu, reportez-vous à la rubrique Plan authentication methods.
Des messages électroniques d’administration contenant des liens sont envoyés à partir de la zone Par défaut. Ces messages comprennent des courriers électroniques envoyés aux propriétaires de sites qui approchent les limites de quota. Par conséquent, les utilisateurs qui reçoivent ces types de messages électroniques 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 qui doivent accéder aux collections de sites nommées par l’hôte doivent avoir accès à la zone Par défaut.
Dans le modèle, la zone Par défaut est utilisée pour l’accès des employés distants pour les raisons suivantes :
Les employés peuvent accéder aux liens dans les courriers électroniques d'administration, indépendamment de la manière dont ils accèdent aux sites : interne ou à distance.
Les URL et les noms de serveurs internes sont protégés contre une exposition éventuelle lorsque la zone associée à une demande utilisateur ne peut pas être déterminée. Étant donné que la zone Par défaut est déjà configurée pour les employés distants, les URL n’exposent pas de données sensibles lorsque cette zone est appliquée.
Configuration des zones pour un environnement extranet
Dans un environnement extranet, la conception de zones est essentielle pour les deux raisons suivantes :
Les demandes des utilisateurs peuvent être émises à partir de plusieurs réseaux différents. Dans le modèle, les utilisateurs émettent les demandes à partir du réseau interne, d’Internet et de sociétés partenaires.
Les utilisateurs peuvent participer à la collaboration entre plusieurs applications Web. Par exemple, les employés internes et distants peuvent potentiellement contribuer au contenu et l'administrer entre plusieurs applications Web : sites d'équipe, sites libre-service et site Web partenaire.
Dans un environnement extranet, assurez-vous que les principes de conception ci-dessous 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.
Dans le modèle, la zone Par défaut pour chacune des applications Web est configurée de manière identique pour l’accès des employés distants. En outre, la zone Intranet est configurée de manière identique pour toutes les applications Web pour l’accès des employés internes. La zone Extranet est configurée pour une seule application Web.
Des mappages des accès de substitution sont automatiquement générés lorsque vous créez la zone. Cependant, si vous utilisez un serveur proxy ou un produit de passerelle pour mettre les sites disponibles à partir d'Internet, vous devez ajouter une entrée de mappage d'accès de substitution supplémentaire pour chaque zone. Cela permet de s'assurer que les URL renvoyées aux utilisateurs en dehors du réseau interne sont disponibles pour les utilisateurs en fonction du contexte de leur zone. Pour plus d'informations, reportez-vous à la rubrique Plan alternate access mappings.
Si les zones entre les applications Web ne sont pas mises en miroir mutuellement et que les liens vers les ressources externes ne sont pas appropriés, les risques sont les suivants :
Les noms de serveurs, les noms DNS (Domain Name System) et les adresses IP peuvent éventuellement être exposées à l’extérieur du réseau interne.
Les utilisateurs peuvent ne pas avoir accès aux sites Web et aux autres ressources.
Sites d’administration
Dans le modèle, le site Administration centrale est hébergé sur le serveur de recherche. Cela protège le site d’un contact direct avec l’utilisateur. Si un goulot d’étranglement au niveau des performances ou un risque pour la sécurité affecte la disponibilité des serveurs Web frontaux, le site Administration centrale demeure disponible. De plus, le site Administration centrale est hébergé à l'intérieur d'un pool d'applications et d'une application Web dédiés.
Les URL avec équilibrage de la charge réseau pour les sites d’administration ne sont pas détaillées dans le modèle ou dans cet article. Les recommandations sont les suivantes :
Si des numéros de port sont utilisés dans les URL d’administration, utilisez des ports non standard. Par défaut, des numéros de port sont inclus dans les URL. Bien que les URL destinées aux clients ne comportent généralement pas de numéro de port, l’utilisation de numéros de port pour les sites d’administration peut renforcer la sécurité en limitant l’accès à ces sites aux ports non standard.
Créez des entrées DNS distinctes pour les sites d’administration.
Pools d’applications
En règle générale, différents pools d’applications des services Internet (IIS) sont implémentés afin que les processus soient isolés d’un contenu à l’autre. Les pools d’applications 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 permet de réduire le risque d’une attaque sur un site par injection de code sur le serveur en vue d’attaquer d’autres sites.
D’un point de vue pratique, envisagez d’utiliser un pool d’applications dédié pour chacun des scénarios suivants :
séparer le contenu authentifié du contenu anonyme ;
isoler des sites destinés principalement à la collaboration avec des partenaires externes ou des clients. Cela permet d'isoler les comptes externes des sites dans un seul pool d'applications.
isoler des sites sur lesquels les utilisateurs ont la liberté de créer et d'administrer des sites, et de collaborer au contenu.
Le modèle utilise des pools d’applications de la manière suivante :
Le site d’administration est hébergé dans un pool d’applications dédié. Il s’agit d’une exigence d’Windows SharePoint Services 3.0.
Les sites de collaboration internes (sites d'équipe et sites libre-service) sont hébergés dans un seul pool d'applications.
L’application Web partenaire est hébergée dans un pool d’applications dédié.
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.
En règle générale, utilisez des applications Web dédiées pour effectuer les opérations suivantes :
Séparer le contenu anonyme du contenu authentifié.
Isoler les utilisateurs. Dans le modèle, l’application Web partenaire est hébergée dans une application Web et dans un pool d’applications dédiés afin que les partenaires n’aient pas accès au contenu de collaboration.
Appliquer des autorisations. Une application Web dédiée permet d'appliquer des autorisations en utilisant la page Stratégie de l'application Web de l'Administration centrale. Par exemple, vous pouvez créer une stratégie sur les sites de collaboration internes pour refuser explicitement l'accès aux comptes partenaires. 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. Les sites bénéficient de meilleures performances s'ils sont placés avec d'autres applications de caractéristiques de données similaires. Par exemple, les caractéristiques de données des sites libre-service incluent un grand nombre de sites de taille réduite. 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. Dans le modèle, les sites d'équipe et les sites libre-service ne possèdent pas d'exigences spécifiques en matière d'isolement des données : ils partagent le même pool d'applications. Néanmoins, les sites d'équipe et les sites libre-service sont placés dans des applications Web distinctes pour optimiser les performances.
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 de site différentes (Corbeille, expiration et taille de chaque site) et négocier différents contrats de niveau de service. Par exemple, vous pouvez accorder plus de temps pour la restauration des sites libre-service s’il ne s’agit pas du type de contenu le plus important au sein de votre organisation. Cela vous permet de restaurer le contenu plus important avant de restaurer ces sites. Dans le modèle, les sites libre-service sont placés dans une application Web distincte afin que les administrateurs puissent gérer la croissance de manière plus dynamique par rapport aux autres applications.
Collections de sites
Les collections de sites relient l’architecture logique et l’architecture des informations. Dans le modèle, les objectifs de conception des collections de sites consistent à satisfaire les contraintes liées à la conception des URL et à créer des divisions de contenu logiques.
Pour satisfaire les contraintes liées à la conception des URL, chaque application Web comprend une collection de sites de niveau racine unique. Les chemins d’accès gérés permettent d’incorporer un second niveau de collections de sites de niveau supérieur. Pour plus d’informations sur les contraintes liées aux URL et sur l’utilisation des chemins d’accès gérés, voir « Zones et URL » plus loin dans cet article. Au-delà du deuxième niveau de collections de sites, chaque site est un sous-site.
La figure ci-dessous indique la hiérarchie de sites d'équipe.
.jpg "Architecture logique pour des sites de collaboration")
Étant donné la nécessité d’une collection de sites de niveau racine, les décisions en matière de conception sont articulées autour du second niveau de collections de sites. Le modèle intègre des choix basés sur la nature de l’application.
Sites libre-service
Dans le modèle, les sites libre-service intègrent un site de niveau supérieur avec l'URL http://sites./ Un chemin d’accès géré est incorporé (à l’aide d’une inclusion générique), ce qui autorise un nombre illimité de sites créés par l’utilisateur. Tous les sites situés sous le chemin d'accès géré sont indépendants des collections de sites qui héritent du modèle de site utilisé pour créer le site de niveau supérieur. La figure ci-dessous représente des sites libre-service.
Pour plus d’informations, reportez-vous à la rubrique Plan process for creating sites (Windows SharePoint Services)
Sites d’équipe
Lors de la conception de collections de sites dans une application de site d'équipe, il est recommandé de créer un nombre fini de collections de sites pour votre organisation en fonction du mode de fonctionnement de votre organisation. Dans cette approche, les collections de sites sont créées par un administrateur Windows SharePoint Services 3.0. Une fois la collection de sites créée, les équipes peuvent créer des sites dans la collection de sites en fonction de leurs besoins.
Cette approche permet d’implémenter une taxonomie réfléchie qui structure la gestion et la croissance des sites d’équipe. En outre, il est plus facile de partager les modèles et la navigation entre projets et équipes qui partagent une collection de sites. Le défi pour les concepteurs du système d’information consiste à créer un deuxième niveau de collections de sites qui soit logique pour l’organisation. Le tableau ci-dessous répertorie des suggestions pour différents types d’organisations.
| Type d’organisation | Taxonomies de collections de sites suggérées |
|---|---|
Développement de produits |
|
Recherche |
|
Établissement d’enseignement supérieur |
|
Bureau des affaires législatives |
|
Cabinet d’avocats en droit des sociétés |
|
Production |
|
Web partenaire
L’application Web partenaire est destinée à être utilisée pour la collaboration avec des partenaires externes sur des projets dont l’étendue ou la durée est arrêtée. En raison de leur conception, les sites au sein de l’application Web partenaire ne sont pas destinés à être liés. L’application Web partenaire doit répondre aux exigences suivantes :
Les propriétaires de projets peuvent facilement créer des sites pour la collaboration avec des partenaires.
Les partenaires et les autres collaborateurs ont accès uniquement aux projets sur lequel ils travaillent.
Les autorisations sont gérées par les propriétaires de sites.
Les résultats d’une recherche au sein d’un projet n’exposent pas le contenu d’autres projets.
Les administrateurs peuvent facilement identifier les sites qui ne sont plus utilisés et les supprimer.
Pour satisfaire à ces exigences, le modèle comprend une collection de sites par projet, qui offre les avantages suivants :
Les différentes collections de sites fournissent le niveau d’isolation approprié entre les projets.
La création de sites libre-service peut être implémentée.
Bases de données de contenu
Vous pouvez utiliser les deux méthodes ci-dessous pour inclure des bases de données de contenu dans la conception (le modèle intègre les deux approches) :
Établissez les tailles cibles des bases de données de contenu en définissant des seuils d’avertissement correspondants appropriés. Créez une nouvelle base 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.
Si vous choisissez d’associer les collections de sites à des bases de données de contenu spécifiques, vous pouvez utiliser les méthodes ci-dessous 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 unique en appliquant les paramètres de capacité de la base de données suivants :
Nombre de sites avant qu’un événement d’avertissement 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 et définissez son état 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.
Sites d’équipe
Le modèle intègre une base de données dédiée pour chacune des collections de sites d'équipe. Cette approche vous permet de gérer la base de données de chaque équipe de manière indépendante pour les opérations de sauvegarde, de restauration et de migration. En outre, lorsqu’un projet est terminé, vous pouvez facilement archiver la base de données qui lui est associée.
Sites libre-service
Pour les sites libre-service, le modèle optimise la mise à l’échelle en gérant les bases de données en fonction de la taille cible maximale. Les paramètres suivants sont configurés pour atteindre cet objectif :
Limiter le stockage du site à une valeur maximale de Ce paramètre, que vous configurez dans la page Modèles de quotas de l’Administration centrale, limite la taille d’un site personnel.
Corbeille secondaire Ce paramètre, que vous configurez dans la page Paramètres généraux de l’application Web, détermine la quantité d’espace supplémentaire allouée à la corbeille secondaire.
Nombre maximal de sites pouvant être créés dans cette base de données Ce paramètre est configuré lorsque vous créez une base de données. Calculez la taille autorisée totale des sites à partir des valeurs que vous avez définies pour les deux paramètres précédents. Ensuite, en fonction de l’objectif de taille pour une base de données spécifique, déterminez le nombre de sites que celle-ci pourra accueillir.
Le modèle fournit les exemples de paramètres de taille suivants, en prenant pour référence une taille de base de données cible de 100 gigaoctets (Go) et d’une taille cible pour le site Mon site de 500 mégaoctets (Mo) :
Taille de site limite par site = 500 Mo
Taille cible de la base de données = 100 Go
Nombre maximal de sites = 20
Avertissement relatif au niveau du site = 175
Lorsque l’avertissement relatif au niveau du site est atteint, créez une nouvelle base de données. Ensuite, de nouveaux sites libre-service sont ajoutés alternativement à la nouvelle base de données et à la base de données existante jusqu’à ce que le nombre maximal de sites pour l’une des bases de données soit atteint.
Web partenaire
Similaire aux sites libre-service, l’application Web partenaire optimise la mise à l’échelle en gérant les bases de données en fonction de la taille cible maximale.
Étant donné que l’application Web partenaire est hébergée dans une application Web dédiée, vous pouvez créer des limites de taille plus appropriées pour les types de tailles générés. Le modèle fournit les exemples de paramètres de taille suivants :
Taille cible de la base de données = 100 Go
Quota de stockage par site = 5 Go
Nombre maximal de sites = 20
Zones et URL
Le modèle illustre la façon de coordonner les URL entre plusieurs applications dans un déploiement d’entreprise.
Objectifs de conception
Les objectifs ci-dessous déterminent les décisions de conception prises pour les URL :
Les conventions d’URL ne limitent pas les zones d’accès au contenu.
Les ports HTTP et HTTPS standard (80 et 443) peuvent être utilisés pour toutes les applications dans le modèle.
Les numéros de port ne sont pas inclus dans les URL. Dans la pratique, ils ne sont généralement pas utilisés dans les environnements de production.
Principes de conception
L’application des principes de conception suivants permet d’atteindre ces objectifs de conception :
Les collections de sites nommées par l’hôte ne sont pas utilisées. Notez qu’elles diffèrent des en-têtes d’hôte IIS. Les collections de sites nommées par l’hôte sont incompatibles avec la fonctionnalité des mappages des accès de substitution. Cette fonctionnalité permet d’accéder au même contenu via plusieurs URL de domaine. Par conséquent, lorsque des sites nommés par l’hôte sont utilisés, ces sites sont disponibles uniquement via la zone Par défaut. En outre, la fonctionnalité de mappage des accès de substitution prend en charge l’arrêt de SSL (Secure Sockets Layer) hors ordinateur, ce qui permet aux scénarios d’accès des employés distants et d’accès des partenaires d’utiliser SSL (HTTPS). Pour plus d'informations sur l'utilisation de collections de sites nommées par l'hôte, reportez-vous à la rubrique White paper: Create shared hosting solutions on Windows SharePoint Services
Chaque application comprend une collection de sites racine unique. Cela est indispensable pour utiliser les mappages des accès de substitution. Si plusieurs collections de sites racines sont nécessaires dans une application Web et que vous envisagez d’utiliser uniquement la zone Par défaut pour l’accès des utilisateurs, le recours à des collections de sites nommées par l’hôte constitue un choix adéquat.
Dans le cas des applications qui comprennent plusieurs collections de sites de niveau supérieur et dans lesquelles chaque collection de sites représente une équipe ou un projet de niveau supérieur (par exemple, des sites d’équipe), le modèle comporte des chemins d’accès gérés. Ceux-ci permettent de mieux contrôler les URL de ces types de sites.
Compromis de conception
La satisfaction des objectifs de conception aboutit à certains compromis, notamment les suivants :
Les URL sont plus longues.
Les collections de sites nommées par l’hôte ne sont pas utilisées.
Concevoir des URL avec équilibrage de la charge réseau
Lorsque vous créez une application Web, vous devez choisir l’URL avec équilibrage de la charge réseau à affecter à l’application. En outre, vous devez créer une URL avec équilibrage de la charge réseau pour chaque zone que vous créez dans une application Web. L’URL avec équilibrage de la charge réseau inclut le protocole, le schéma, le nom d’hôte et le numéro de port, si celui-ci est utilisé. L’URL avec équilibrage de la charge réseau doit être unique sur l’ensemble des applications Web et des zones. Par conséquent, chaque application et chaque zone au sein de chaque application requièrent une URL unique dans le modèle.
Sites de collaboration internes
Les deux types de sites de collaboration internes nécessitent une URL unique. Dans le modèle, le public cible de ces sites est constitué des employés internes et des employés distants. Le tableau ci-dessous répertorie les URL qui permettent aux employés internes et aux employés distants d’accéder à chaque application.
| Application | URL pour les employés internes | URL pour les employés distants |
|---|---|---|
Sites d’équipe |
http://teams/ |
https://teams.fabrikam.com/ |
Sites libre-service |
http://sites |
https://sites.fabrikam.com/ |
Web partenaire
Dans le modèle, l’application Web partenaire est accessible aux employés internes, aux employés distants et aux employés partenaires. Bien que les employés distants et les employés partenaires accèdent à l’application Web partenaire de manière externe à l’aide de SSL (HTTPS), les uns comme les autres nécessitent une URL spécifique pour tirer parti de l’utilisation de zones distinctes, ce qui suppose l’utilisation de méthodes d’authentification et de stratégies de zone distinctes. Le tableau ci-dessous répertorie les URL que les employés internes, les employés distants et les partenaires utilisent pour accéder à l’application Web partenaire.
| Zone | URL |
|---|---|
URL pour les employés internes |
http://partnerweb/ |
URL pour les employés distants |
https://remotepartnerweb.fabrikam.com/ |
URL pour les partenaires |
https://partnerweb.fabrikam.com |
Utiliser des inclusions explicites et des inclusions génériques pour les chemins d’URL
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 à laquelle est associée l’URL explicite que vous attribuez. Une inclusion explicite est appliquée à une seule collection de sites. Vous pouvez créer de nombreuses inclusions explicites sous une collection de sites racine. http://team/Team1 est un exemple d'URL d'une collection de sites créée en utilisant cette méthode.
Inclusion générique : chemin d’accès ajouté à l’URL. Ce chemin d’accès indique que tous les sites spécifiés directement après le nom du chemin d’accès sont des collections de sites uniques. Cette option est généralement utilisée pour les applications qui prennent en charge la création de sites libre-service. http://sites/site1 est un exemple d'URL d'une collection de sites créée en utilisant cette méthode.
Le modèle intègre l’utilisation de ces deux types, comme le décrivent les sections suivantes.
Inclusions explicites : sites d'équipe
Dans le modèle, les deux applications de site d'équipe intègrent l'utilisation d'inclusions explicites.
Sites d’équipe
Dans l'application de site d'équipe, une inclusion explicite est utilisée pour chaque collection de sites d'équipe. La limite de mise à l’échelle sur les collections de sites créées avec une inclusion explicite est d’environ 100 sites. Il est recommandé de limiter le nombre de sites d'équipe de niveau supérieur à une quantité gérable. Par ailleurs, la taxonomie des sites d’équipe doit être logique par rapport au fonctionnement de votre entreprise. De nombreuses organisations s’accommodent facilement de la limite recommandée de 100 sites. Si votre organisation requiert une mise à l’échelle supérieure pour les sites d’équipe, utilisez plutôt une inclusion générique.
Dans le modèle, l’utilisation d’inclusions explicites aboutit aux URL indiquées dans le tableau suivant.
| Employé interne (zone Intranet) | Employé distant (zone Par défaut) |
|---|---|
http://team/Team1 |
https://team.fabrikam.com/Team1 |
http://team/Team2 |
https://team.fabrikam.com/Team2 |
http://team/Team3 |
https://team.fabrikam.com/Team3 |
Dans cet exemple, la collection de sites racine, http://team, n’héberge pas nécessairement de contenu pour des utilisateurs.
Inclusions génériques : applications Web partenaire et sites libre-service
Les applications Web partenaire et les sites libre-service intègrent l’utilisation d’une inclusion générique. Les inclusions génériques sont idéales pour les applications qui permettent aux utilisateurs de créer leurs propres collections de sites. Une inclusion générique indique que l’élément situé juste après le caractère générique est un site racine d’une collection de sites.
Sites libre-service
Dans le modèle, les sites libre-service comprennent une inclusion générique nommée /sites (http://partnerweb//sites).
Cela se traduit par des URL dont le format est indiqué dans le tableau suivant.
| Employé interne (zone Intranet) | Employé distant (zone Par défaut) |
|---|---|
http://selfservice/sites/site1 |
https://selfservice.fabrikam.com/sites/site1 |
http://selfservices/sites/site2 |
https://selfservice.fabrikam.com/sites/site2 |
http://selfservice/sites/user3 |
https://selfservices.fabrikam.com/personal/user3 |
Web partenaire
L’application Web partenaire est conçue pour permettre aux employés de créer facilement des sites sécurisés en vue d’une collaboration avec des partenaires externes. Pour que cet objectif puisse être atteint, la création de sites libre-service est autorisée.
Dans le modèle, l’application Web partenaire comprend une inclusion générique nommée /sites (http://partnerweb//sites). Cela se traduit par des URL dont le format est indiqué dans le tableau suivant.
| Employé interne (zone Intranet) | Employé distant (zone Par défaut) |
|---|---|
http://partnerweb//sites/project1 |
https://remotepartnerweb.fabrikam.com//sites/project1 |
http://partnerweb//sites/project2 |
https://remotepartnerweb.fabrikam.com//sites/project2 |
http://partnerweb//sites/project3 |
https://remotepartnerweb.fabrikam.com//sites/project3 |
Les collaborateurs partenaires peuvent accéder aux sites Web partenaires à l’aide des URL répertoriées dans le tableau suivant.
| Partenaire (zone Extranet) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
Stratégies de zone
Vous pouvez créer une stratégie pour une application Web afin d’appliquer des autorisations au niveau de celle-ci. Une stratégie peut être définie pour l’application Web en général ou uniquement pour une zone spécifique. Une stratégie applique des autorisations à la totalité du contenu au sein de l’application Web ou de la zone. Les autorisations d’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.
Le modèle fournit un exemple : refus de l'accès des comptes d'utilisateurs aux sites de collaboration internes.
Sauvegarde et restauration des sites de collaboration
Il existe plusieurs options pour la sauvegarde et la restauration de contenu qui sont appropriées aux sites de collaboration :
Outils de sauvegarde et de récupération intégrés : utilisez les outils fournis avec Windows SharePoint Services 3.0 si la taille des bases de données est inférieure à 100 Go et qu'il n'y a pas de nombreuses personnalisations ou que les personnalisations sont regroupées sous forme de solution.
Outils de sauvegarde et de récupération Microsoft SQL Server 2005 : utilisez ces outils si vous disposez d'un administrateur de base de données SQL.
Pour plus d’informations, reportez-vous à la rubrique Choose backup and recovery tools (Windows SharePoint Services).
Conception d'une collaboration externe sécurisée
L'affiche d'exemple de conception inclut une présentation de la planification de la collaboration sécurisée externe. Cette section inclut le texte d'introduction pour chaque élément et des liens vers les articles correspondants dans la bibliothèque TechNet.
| Recommandation de conception | Instruction |
|---|---|
Sélectionnez une topologie extranet |
Protégez la batterie de serveurs en utilisant un pare-feu de pointe ou en plaçant la batterie de serveurs dans un réseau de périmètre. Pour plus d'informations, reportez-vous aux articles ci-dessous sur TechNet :
|
Sécuriser les communications client-serveur |
La collaboration sécurisée dans un environnement extranet s’appuie sur une communication sécurisée entre les ordinateurs clients et l’environnement de batterie de serveurs. Le cas échéant, utilisez SSL (Secure Sockets Layer) pour sécuriser la communication entre les ordinateurs clients et serveurs. Pour plus d’informations, reportez-vous aux articles ci-dessous sur TechNet : |
Protéger les serveurs frontaux et le site Administration centrale |
La collaboration sécurisée externe nécessite des serveurs Internet. Vous pouvez limiter l'exposition au trafic provenant d'Internet en plaçant un pare-feu entre les serveurs Web et les autres serveurs, et en hébergeant le site Administration centrale sur le serveur frontal. Pour plus d’informations, voir les articles ci-dessous sur TechNet :
|
Configurer les mappages des accès de substitution |
Des mappages d'accès de substitution prennent en charge des scénarios de déploiement dans lesquels l'URL d'une demande Web reçue par les services Internet (IIS) n'est pas identique à l'URL tapée par un utilisateur. Ceci se produit plus généralement dans des scénarios de déploiement qui intègrent la publication proxy inverse et l'équilibrage de charge. Par exemple, les serveurs proxy inverses peuvent exécuter des fonctionnalités avancées, comme la réception d'une demande Web sur Internet en utilisant SSL (HTTPS), mais transfèrent la demande au serveur en utilisant le protocole HTTP. Cette fonction est appelée « Arrêt de SSL hors ordinateur ». Pour plus d'informations, reportez-vous à la rubrique Plan alternate access mappings. |
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.