Planification de l’architecture des services (SharePoint Server 2010)

 

S’applique à : SharePoint Foundation 2010, SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

Cet article décrit l’architecture des services pour le partage des applications de service et fournit des exemples d’architectures pour Microsoft SharePoint Server 2010.

Dans cet article :

• À propos des applications de service

• Infrastructure des services et principes de conception

• Déploiement des applications de service entre des batteries de serveurs

• Considérations relatives à la planification des services qui accèdent aux sources de données externes

• Exemples d’architectures

• Batterie de serveurs unique, groupe d’applications de service unique

• Batterie de serveurs unique, groupe d’applications de service multiples

• Batteries de serveurs de services d’entreprise

• Batteries de serveurs de services spécialisées

• Batteries de serveurs à l'échelle de l'organisation

Lorsque vous planifiez l’architecture des services, posez-vous les questions suivantes :

• Quelles sont les applications de service dont votre organisation a besoin ?

• Des équipes ont-elles besoin d’applications de service dédiées ?

• De combien de batteries de serveurs votre organisation a-t-elle besoin ?

• Est-il possible de partager les services entre des batteries de serveurs ?

• Les besoins de votre organisation justifient-ils une batterie de serveurs de services centralisée ?

Les modèles de format affiche suivants sont également disponibles pour une utilisation avec cet article. Vous pouvez modifier les diagrammes dans les modèles afin de représenter les plans conçus pour votre propre organisation :

• Services dans Produits Microsoft SharePoint 2010

  • Visio (https://go.microsoft.com/fwlink/?linkid=167090&clcid=0x40C) (éventuellement en anglais)

  • PDF (https://go.microsoft.com/fwlink/?linkid=167092&clcid=0x40C) (éventuellement en anglais)

  • XPS (https://go.microsoft.com/fwlink/?linkid=167091&clcid=0x40C) (éventuellement en anglais)

• Services entre batteries de serveurs dans Produits SharePoint 2010

  • Visio(https://go.microsoft.com/fwlink/?linkid=167093&clcid=0x40C) (éventuellement en anglais)

  • PDF (https://go.microsoft.com/fwlink/?linkid=167095&clcid=0x40C) (éventuellement en anglais)

  • XPS (https://go.microsoft.com/fwlink/?linkid=167094&clcid=0x40C) (éventuellement en anglais)

À propos des applications de service

SharePoint Server 2010 comprend un jeu de services pouvant être partagés entre plusieurs applications Web. Ces services sont appelés applications de service. Certaines applications de service peuvent être partagées entre des batteries de serveurs. Le partage d’applications de service entre des applications Web et des batteries de serveurs réduit considérablement les ressources requises pour fournir ces services sur plusieurs sites.

Le tableau suivant répertorie les applications de service qui sont incluses avec les Produits SharePoint 2010.

Applications de service	Description	SharePoint Foundation 2010	SharePoint Server 2010 Standard	SharePoint Server 2010 Enterprise
Access Services	Permet aux utilisateurs d’afficher, de modifier les bases de données Access 2010, et d’interagir avec celles-ci, dans un navigateur Web.			X
Service Connexion de données métiers	Permet d’accéder à des systèmes de données métier.	X	X	X
Application Excel Services	Permet aux utilisateurs d’afficher les fichiers Excel 2010, et d’interagir avec ceux-ci, dans un navigateur Web.			X
Service de métadonnées gérées	Gère les hiérarchies de la taxonomie, les mots clés et l’infrastructure de la liaison de mise en réseau, et publie les types de contenu dans les collections de sites.		X	X
Application de service PerformancePoint	Fournit les fonctionnalités de PerformancePoint.			X
Service de recherche	Analyse le contenu, génère des partitions d’index et sert les requêtes de recherche.		X	X
Service Banque d’informations sécurisé	Fournit une authentification unique pour l’accès à plusieurs applications ou services.		X	X
Service d’états temporaires	Permet le stockage temporaire des données de session utilisateur pour les composants SharePoint Server.		X	X
Service de collecte de données relatives à l’état et à l’utilisation	Collecte les données d’utilisation et d’intégrité à l’échelle de la batterie de serveurs et permet d’afficher différents rapports sur l’utilisation et l’intégrité.	X	X	X
Service de profil utilisateur	Permet la prise en charge des sites Mes sites, des pages de profil, de la liaison de réseau social et d’autres fonctionnalités d’informatique sociale.		X	X
Service graphique Visio	Permet aux utilisateurs d’afficher et d’actualiser dans un navigateur Web les diagrammes Visio 2010 publiés.			X
Service Web Analytics	Fournit des interfaces de service Web.		X	X
Services d’automatisation Word	Effectue des conversions en bloc de documents automatisées.		X	X
Service de paramètres d’abonnement Microsoft SharePoint Foundation	Fournit des fonctionnalités multi-client pour les applications de service. Effectue le suivi des ID d’abonnement et des paramètres pour les services déployés en mode partitionné. Déployé par le biais de Windows PowerShell uniquement.	X	X	X

Certains services sont fournis par d’autres produits Microsoft, notamment les services répertoriés dans le tableau suivant.

Application de service	Description
Services Office Web Apps : Service d’affichage Word Service PowerPoint Services de calcul Excel	Office Web Apps est une offre de productivité basée sur le Web et disponible dans les suites Microsoft Office 2010. Les services Office Web Apps comprennent des compagnons pour Microsoft Word 2010, Microsoft Excel 2010, Microsoft PowerPoint 2010 et Microsoft OneNote 2010. Ces applications Web sont des applications autonomes destinées à faciliter l’accès aux documents Word 2010, PowerPoint 2010, Excel 2010 et OneNote 2010 par le biais de n’importe quel navigateur indépendamment de la plateforme, à fournir des fonctionnalités légères de création et de modification dans les formats standard, à permettre le partage et la collaboration sur ces documents par le biais du navigateur, le tout dans le cadre de différents scénarios compatibles avec le Web. Les documents créés à l’aide d’Office Web Apps ne sont pas différents des documents qui étaient créés à l’aide des applications bureautiques correspondantes. Les services associés permettent de préparer les documents en vue de leur affichage et de leur modification dans un navigateur Web.
Microsoft Project Server 2010	Microsoft Project Server 2010 héberge une ou plusieurs instances Microsoft Project Web Access, expose des fonctionnalités de planification et autres calculs de niveau intermédiaire sur les données Microsoft Project et expose des services Web pour l’interaction avec les données Microsoft Project 2010.

Les applications de service diffèrent des services démarrés et arrêtés sur des serveurs spécifiques et répertoriés dans la page Services sur le serveur du site Web Administration centrale de SharePoint. Certains des services répertoriés dans cette page sont associés à des applications de service, mais les applications de service représentent des instances spécifiques de services pouvant être configurés et partagés selon des procédures spécifiques.

Infrastructure des services et principes de conception

Produits SharePoint 2010 améliore l’infrastructure de services introduite dans la version précédente. Dans les Produits SharePoint 2010, l’infrastructure de l’hébergement des services est déplacée dans SharePoint Foundation 2010 et la configuration des offres de services est beaucoup plus souple. Les services individuels peuvent être configurés indépendamment, et les sociétés tierces peuvent ajouter des services à la plateforme.

Le partage de services n’est plus l’exclusivité de SharePoint Server et les services ne sont plus contenus dans des fournisseurs de services partagés.

Déploiement des services

Vous déployez les applications de service dans une batterie de serveurs à l’aide de l’une des méthodes suivantes :

• sélection de services lorsque vous exécutez l’Assistant Configuration des produits SharePoint ;

• ajout des services un par un dans la page Gérer les applications de service sur le site Administration centrale ;

• utilisation de Windows PowerShell.

Configuration de services affinée

L’infrastructure de services mise à jour vous permet de contrôler davantage les services à déployer et la façon dont les applications de service sont partagées :

1. Vous pouvez déployer seulement les applications de service qui sont nécessaires à une batterie de serveurs.

2. Les applications Web peuvent être configurées de manière à utiliser uniquement les applications de service nécessaires, plutôt que tous les services qui ont été déployés.

3. 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.

4. Vous pouvez partager des applications de service entre plusieurs applications Web au sein de la même batterie de serveurs.

Vous pouvez choisir les applications de service pour une application Web lorsque vous créez celle-ci. Vous pouvez également modifier par la suite les applications de service associées à une application Web.

Groupes d’applications de service

Toutes les applications de service sont d’office incluses dans un groupe par défaut, sauf si vous modifiez ce paramètre pour une application de service lors de sa création. Vous pouvez à tout moment ajouter et supprimer des applications de service dans le groupe par défaut.

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é d’applications de service. Vous créez un groupe personnalisé d’applications de service en sélectionnant uniquement les applications de service que l’application Web doit utiliser.

La capture d’écran suivante montre une liste d’applications de service pour un exemple de batterie de serveurs qui peuvent être sélectionnées si l’option personnalisé est sélectionnée lorsqu’une application Web est créée. Seules les toutes premières applications de service apparaissent dans l’image.

Les groupes personnalisés créés dans l’Administration centrale ne sont pas réutilisables d’une application Web à l’autre. Chaque fois que vous sélectionnez l’option personnalisé lorsque vous créez une application Web, vous sélectionnez des applications de service uniquement pour l’application Web que vous êtes en train de créer.

Architecture logique

Les applications de service sont déployées dans un site Web IIS (Internet Information Services) unique. Il s’agit du comportement par défaut, qui ne peut pas être modifié. Toutefois, vous pouvez personnaliser la configuration des groupes d’applications de service et l’association des applications Web à ces groupes.

Le diagramme suivant représente l’architecture logique d’un déploiement de batterie de serveurs typique.

La batterie de serveurs illustrée dans le diagramme présente les caractéristiques suivantes :

• Toutes les applications de service se trouvent dans le même site Web IIS.

• Il existe deux groupes d’applications de service : le groupe par défaut et un groupe personnalisé. Toutes les applications de service ne sont pas nécessairement incluses dans le groupe par défaut. Dans le diagramme, l’application de service F n’est pas incluse dans le groupe par défaut. Elle est utilisée par une seule application Web.

• Les applications Web se connectent au groupe par défaut ou à un groupe personnalisé d’applications de service. Dans le diagramme, il existe un groupe personnalisé.

Les applications de service peuvent être déployées sur différents pools d’applications pour que les processus soient isolés. Toutefois, pour optimiser les performances de votre batterie de serveurs, il est recommandé de déployer les applications de service sur un seul pool d’applications.

Pour obtenir une isolation physique pour une application de service, choisissez ou créez un pool d’applications différent pour celle-ci, comme l’illustre le diagramme suivant.

Connexions pour les applications de service

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. Dans Windows PowerShell, ces connexions sont appelées proxys. Le terme « proxy » apparaît à la fin de la description type des connexions dans la page Gérer les applications de service de l’Administration centrale. Certaines connexions peuvent contenir des paramètres modifiables. Par exemple, les connexions pour l’application de service de métadonnées gérées comprennent plusieurs paramètres, tels qu’Administrateurs de magasin de termes et Langue par défaut.

Administration des applications de service

Les applications de service sont gérées directement dans l’Administration centrale plutôt que par le biais d’un site d’administration spécifique. Au besoin, les applications de service peuvent être surveillées et gérées à distance. Les applications de service peuvent également être gérées et scriptées à l’aide de Windows PowerShell.

Déploiement des applications de service entre des batteries de serveurs

Certaines applications de service peuvent être partagées entre des batteries de serveurs, tandis que d’autres ne peuvent être partagées que dans une même batterie de serveurs.

Le diagramme suivant indique les applications de service pouvant être partagées entre des batteries de serveurs et celles qui sont limitées à une seule batterie de serveurs.

Aide à la conception

L’aide suivante concerne le partage d’applications de service entre des batteries de serveurs :

• Les applications de service prenant en charge le partage entre des batteries de serveurs peuvent être exécutées dans une batterie de serveurs centrale et consommées à partir des autres batteries de serveurs.

• Chaque application Web peut être configurée de manière à utiliser des applications de service à partir de différentes batteries de serveurs. Par exemple, vous pouvez partager le service de profil utilisateur entre les applications Web dans plusieurs batteries de serveurs, tout en configurant certaines applications de service, telles que le service Connexion de données métiers, de manière à ce qu’elles soient utilisées localement.

• Dans les environnements de grande taille, vous pouvez exécuter les applications de service gourmandes en calculs dans une batterie de serveurs centrale afin de réduire au minimum les tâches d’administration et d’effectuer une montée en puissance parallèle facilement et efficacement à mesure que les besoins augmentent. Pour plus d’informations, voir Batteries de serveurs de services d'entreprise, plus loin dans cet article.

Environnements WAN

Il est déconseillé d’utiliser dans les environnements de réseau étendu (WAN) certaines applications de service partagées entre les batteries de serveurs. Le tableau suivant répertorie les recommandations actuelles pour le déploiement des applications de service dans ces environnements.

Application de service	Recommandée pour les environnements WAN ?	Remarques
Recherche	Oui
Métadonnées gérées	Oui
Business Data Connectivity	Dépend de l’environnement Business Data Connectivity.	Une fois le cache de données rempli, la liaison WAN n’est pas nécessaire. Les premiers accès aux pages sont lents et peuvent se traduire par des dépassements de délai d’attente. Les demandes ultérieures de données mises en cache sont plus rapides.
Profils utilisateur	Non pris en charge	Actuellement, l’utilisation de l’application de service de profil utilisateur via les liaisons WAN n’est pas prise en charge. Ce service requiert un accès direct à la base de données. Pour les environnements WAN, le moteur de réplication des profils utilisateur est recommandé à la place.
Service Banque d’informations sécurisé	Non	Le service Banque d’informations sécurisé fonctionne via les liaisons WAN, mais il n’est pas recommandé, car il peut affecter les performances d’autres services utilisant une liaison WAN.
Web Analytics	Non

Pour plus d’informations sur le déploiement des applications de service dans les environnements WAN, voir Solutions globales pour les Produits SharePoint 2010 (modèle).

Déploiement de services entre des batteries de serveurs

Le partage d’applications de service entre des batteries de serveurs se déroule en plusieurs étapes :

1. Configurez des batteries de serveurs approuvées.

   Vérifiez que les batteries de serveurs ont échangé des certificats afin de s’approuver les unes les autres. Exportez le certificat dans un fichier, puis sauvegardez le fichier avant de vous connecter aux services déployés entre les batteries de serveurs.

2. Publiez les applications de service.

   Pour partager une application de service entre des batteries de serveurs, vous devez d’abord publier le service.

3. Connectez-vous aux applications de service partagées entre les batteries de serveurs.

   Pour consommer un service publié par une batterie de serveurs distante, créez une connexion à ce service. Ce processus vous invite à entrer l’URL d’un service publié, qui apparaît pendant le processus de publication. Une connexion sur la batterie de serveurs locale est créée afin que soit établie la connexion à l’application de service sur la batterie de serveurs distante.

Si les batteries de serveurs se trouvent dans deux domaines, l’application de service de profil utilisateur requiert que les deux domaines s’approuvent l’un l’autre. Pour que les fonctionnalités d’administration des applications de service Connexion de données métiers et Banque d’informations sécurisé soient opérationnelles à partir de la batterie de serveurs consommatrice, il est nécessaire que le domaine de la batterie de serveurs qui effectue la publication approuve le domaine de la batterie de serveurs consommatrice. Les autres applications de service partagées entre les batteries de serveurs fonctionnent sans qu’il soit nécessaire d’établir une relation d’approbation entre les domaines.

Pour plus d’informations sur la configuration de services à utiliser entre des batteries de serveurs, voir Se connecter à une application de service sur une batterie de serveurs à distance (SharePoint Server 2010).

Considérations relatives à la planification des services qui accèdent aux sources de données externes

Certaines applications de service peuvent accéder à des sources de données externes. Ces applications qui utilisent une identité Windows déléguée pour accéder aux sources de données externes imposent des conditions supplémentaires sur l’environnement. Pour ces applications de service, les sources de données externes doivent résider dans le même domaine que la batterie de serveurs SharePoint Server 2010 où ces applications se trouvent, sinon l’application de service doit être configurée afin d’utiliser le service Banque d’informations sécurisé.

Les applications de service suivantes utilisent une identité Windows déléguée pour accéder aux sources de données externes :

• Excel Services

• PerformancePoint Services

• InfoPath Forms Services

• Visio Services

En guise d’alternative, les applications de service qui utilisent une identité Windows déléguée pour accéder aux sources de données externes peuvent être configurées afin d’utiliser le service Banque d’informations sécurisé. Le service Banque d’informations sécurisé stocke et maintient les informations d’identification d’utilisateur ou de service. Les applications de service peuvent utiliser les informations d’identification stockées pour s’authentifier auprès d’une source de données directement.

Si le service Banque d’informations sécurisé n’est pas utilisé et que les sources de données externes ne résident pas dans le même domaine, l’authentification auprès de ces sources de données est vouée à l’échec. Si les serveurs de la batterie sont répartis sur deux domaines, les serveurs d’applications doivent résider sur le même domaine que les sources de données externes.

Les applications de service et les produits suivants ne sont pas concernés par ces conditions :

• Service Business Data Connectivity et Services Microsoft Business Connectivity

• Services d’accès

• Microsoft SQL Server PowerPivot pour Microsoft SharePoint

• Microsoft SQL Server Reporting Services (SSRS)

• Microsoft Project Server 2010

Exemples d’architectures

Le reste de cet article fournit des exemples d’architectures pour des scénarios de déploiement courants.

Batterie de serveurs unique, groupe d’applications de service unique

Dans une architecture qui comprend une batterie de serveurs unique et un groupe d’applications de service unique, le groupe d’applications de service par défaut est utilisé pour toutes les applications Web dans la batterie de serveurs. Tous les sites ont accès à la totalité des applications de service déployées dans la batterie de serveurs.

Avantages

Cette architecture offre les avantages suivants :

• Il s’agit de l’architecture la plus simple à déployer.

• Toutes les applications de service sont disponibles pour toutes les applications Web.

• Les ressources de la batterie de serveurs sont utilisées de façon efficace.

• Toutes les applications de service sont gérées de façon centralisée.

Inconvénients

Par contre, cette architecture présente plusieurs inconvénients :

• Vous ne pouvez pas isoler les données des applications de service.

• Les différents départements ou équipes ne peuvent pas gérer eux-mêmes les applications de service.

Recommandations

L’architecture qui comprend une batterie de serveurs unique et un groupe d’applications de service unique est la configuration recommandée pour la plupart des organisations, au moins au départ. Cette configuration fonctionne correctement si vous souhaitez héberger de nombreux sites pour une même société sur la même batterie de serveurs.

Utilisez cette configuration pour atteindre les objectifs suivants :

• Vous souhaitez optimiser les ressources requises pour exécuter des applications de service dans une batterie de serveurs.

• Vous partagez les données du contenu et du profil sur des sites qui autrement requièrent l’isolation des processus, pour des raisons de performances ou de sécurité.

Batterie de serveurs unique, groupe d’applications de service multiples

Si des équipes requièrent des applications de service dédiées, créez une architecture à l’aide d’un ou plusieurs groupes personnalisés d’applications de service. Appuyez-vous sur les indications suivantes :

• Déployez des applications de service spécifiques, qui seront destinées à être utilisées par une ou plusieurs équipes au sein d’une organisation.

• Vérifiez que les applications de service dédiées ne font pas également partie du groupe par défaut.

• Créez une ou plusieurs applications Web qui utilisent un groupe personnalisé d’applications de service. L’administrateur SharePoint sélectionne les applications de service incluses dans le groupe personnalisé.

Dans le diagramme suivant, la batterie de serveurs B montre un exemple d’architecture comportant deux groupes d’applications de service. Dans cet exemple, l’équipe en charge des finances requiert une application Excel Services dédiée. Access Services est également déployé pour cette équipe.

Vous pouvez créer plusieurs groupes d’applications de service personnalisés. Dans le diagramme suivant, deux groupes personnalisés sont créés dans la batterie de serveurs C. À partir de l’architecture de la batterie de serveurs B, les applications de service Métadonnées gérées et Connexion de données métiers dédiées sont déployées sur la batterie de serveurs afin d’être utilisées par le département des ressources humaines. Cela aboutit à un deuxième groupe personnalisé d’applications de service, en plus du premier groupe d’application de service dédié précédemment créé pour l’équipe en charge des questions financières.

Les applications de service déployées pour une utilisation dédiée peuvent partager le même pool d’applications ou elles peuvent être déployées sur un pool d’applications distinct, ce qui permet d’accroître l’isolation. La conception de la batterie de serveurs B (deux diagrammes plus haut) parvient à isoler les processus liés aux applications de service déployées pour l’équipe en charge des questions financières en plaçant ces applications de service dans un pool d’applications dédié. Dans le cas de la batterie de serveurs C, illustrée dans le diagramme précédent, un même pool d’applications est utilisé pour toutes les applications de service ; dans cette architecture, le déploiement des applications de service vise plutôt à optimiser les performances.

Connexion à plusieurs applications de service de métadonnées gérées

Un groupe d’applications de service peut inclure plusieurs applications de service de métadonnées gérées. Par exemple, dans le diagramme de la batterie de serveurs C, le groupe personnalisé mis en surbrillance en vert comprend deux applications de service de métadonnées gérées.

Dans ce scénario, les sites au sein des applications Web affichent la taxonomie, la liaison de mise en réseau et d’autres fonctionnalités à partir des deux applications de service de métadonnées gérées. À la différence des autres services déployés entre des batteries de serveurs, les composants WebPart comprennent par défaut des données issues de plusieurs applications de service de métadonnées gérées.

Pour plus d’informations sur la gestion de plusieurs applications de service de métadonnées gérées, voir À propos de l’application de service de métadonnées.

Avantages

Les architectures qui comprennent plusieurs groupes d’applications de service offrent les avantages suivants :

• Elles permettent d’atteindre plusieurs objectifs d’organisation dans la même batterie de serveurs.

• Les données de service peuvent être isolées.

• Chaque équipe ou département peut gérer les applications de service dont l’utilisation leur a été dédiée.

• Les sites peuvent être configurés de manière à utiliser un sous-ensemble d’applications de service.

Inconvénients

Les architectures qui utilisent plusieurs groupes d’applications de service présentent les inconvénients suivants :

• Leur configuration et leur gestion sont plus complexes.

• Les ressources de la batterie de serveurs sont consommées afin que soient prises en charge plusieurs instances de certaines applications de service, ce qui peut affecter les performances.

Recommandations

Les architectures qui comprennent plusieurs groupes d’applications de service fonctionnent correctement dans le cas des sociétés dont les départements ou les équipes requièrent des applications de service dédiées ou des données de service isolées, de même que dans le cas des sites configurés avec une étendue plus étroite, à l’image de la collaboration avec des partenaires.

En outre, lorsque plusieurs groupes d’applications de service sont configurés, les équipes et les sites peuvent consommer des services proposés à l’échelle de l’entreprise, tels que les services de profil et de recherche, l’utilisation de services ciblés pouvant être parallèlement isolés pour des raisons de sécurité ou de performance.

Les applications de service qui sont généralement déployées pour une utilisation exclusive par une équipe ou un département spécifique sont les suivantes :

• Excel Services   Pour optimiser les performances pour une équipe ciblée ou pour isoler les données sensibles.

• Métadonnées gérées   Pour permettre à une équipe ou à un département de gérer ses propres taxonomie, hiérarchies, mots clés, etc. SharePoint Server 2010 combine les résultats de plusieurs applications de service de métadonnées gérées, ce qui permet de partager les taxonomies, les types de contenu et autres éléments au sein d’une organisation.

• Connexion de données métiers   Chaque équipe ou département peut réaliser une intégration à son propre système de données métier et maintenir les données isolées du reste de l’organisation.

Dans certains cas, un groupe dédié d’applications de service est configuré afin que le nombre de services utilisés par une application Web soit réduit. Par exemple, un site de collaboration avec des partenaires peut être configuré pour consommer un sous-ensemble des applications de service proposées par la batterie de serveurs.

Batteries de serveurs de services d’entreprise

Une batterie de serveurs de services d’entreprise est une batterie de serveurs dédiée à l’hébergement d’applications de service pour une organisation. Le diagramme suivant illustre une batterie de serveurs de services d’entreprise qui héberge les applications de service les plus fréquemment déployées entre les batteries de serveur. En outre, il montre plusieurs types courants de batteries de serveurs qui consomment des services à partir d’une batterie de serveurs de services d’entreprise.

Le reste de cette section décrit les autres batteries de serveurs du diagramme. Les batteries de serveurs 2, 3 et 4 représentent les types de batteries de serveurs qui sont les plus susceptibles de consommer des services à partir d’une batterie de serveurs de services d’entreprise.

Batteries de serveurs limitées au contenu publié (toutes les applications de service sont distantes)

Vous pouvez déployer une batterie de serveurs sans déployer d’application de service localement. Dans la batterie de serveurs 2, aucune application de service n’est hébergée localement. Toutes les applications de service sont consommées à partir d’une batterie de serveurs distincte.

Cette configuration fonctionne correctement pour le contenu publié. Elle réduit les tâches d’administration liées à l’hébergement d’une batterie de serveurs de contenu publié et permet à une organisation de tirer parti d’applications de service gérées de façon centralisée.

Utilisez cette configuration lorsque vos objectifs sont les suivants :

• Vous souhaitez optimiser les ressources au sein d’une batterie de serveurs pour héberger du contenu, plutôt que pour exécuter des applications de service.

• Vous opérez une intégration aux profils, aux métadonnées, à la recherche et aux autres ressources gérées de façon centralisée à l’échelle de l’organisation.

Batteries de serveurs de collaboration (combinaison d’applications de service locales et distantes)

La batterie de serveurs 3 représente une batterie de serveurs optimisée pour la collaboration. Toutes les applications de service qui ne peuvent pas être partagées entre les batteries de serveurs sont hébergées localement. Cela englobe les applications de service liées aux clients, qui sont importantes pour la collaboration. Les applications de service partagées entre les batteries de serveurs sont consommées à partir d’une batterie de serveurs de services d’entreprise (Batterie de serveurs 1).

Les batteries de serveurs peuvent consommer des services à partir de plusieurs batteries de serveurs distantes. Dans le diagramme, la batterie de serveurs 3 consomme également le service de métadonnées gérées à partir d’une batterie de serveurs de département spécialisée (Batterie de serveurs 4), ce qui permet d’opérer une intégration aux fonctionnalités de ce département gérées de façon autonome, telles que la taxonomie et la liaison de mise en réseau.

S’il existe plusieurs applications de service de métadonnées gérées, l’une de ces applications doit être désignée comme application de service principale hébergeant la taxonomie de l’entreprise. Toutes les autres instances de cette application de service sont secondaires et fournissent des données qui viennent compléter celles de l’application de service principale. À la différence des autres services déployés entre des batteries de serveurs, les composants WebPart comprennent par défaut des données issues de plusieurs applications de service de métadonnées gérées.

Cette configuration est recommandée pour les sociétés qui sont amenées à héberger plusieurs batteries de serveurs. Utilisez cette configuration pour atteindre les objectifs suivants :

• pour optimiser les ressources d’administration et de batterie de serveurs au niveau de l’entreprise en vue d’héberger des services (Batterie de serveurs 1) ;

• pour optimiser les ressources au niveau de la batterie de serveurs en vue d’héberger des sites de collaboration (Batterie de serveurs 3) ;

• pour opérer une intégration aux profils, aux métadonnées, à la recherche et à d’autres ressources gérées de façon centralisée à l’échelle de l’organisation ;

• pour opérer une intégration aux métadonnées générées par une équipe ou un département spécialisé (Batterie de serveurs 4).

Batteries de serveurs pour des départements spécialisés (combinaison d’applications de service locales et distantes)

Certaines équipes au sein d’une organisation peuvent avoir besoin d’un déploiement distinct de services spécifiques pour les raisons suivantes :

• pour garantir l’isolation des données (à l’image des données de connexion de données métiers) ;

• pour permettre de gérer les applications de service de façon autonome (à l’instar des métadonnées gérées).

La batterie de serveurs 4 fournit un exemple. Les caractéristiques de cette batterie de serveurs sont les suivantes :

• Elle consomme des applications de service gérées de façon centralisée, dont l’application de métadonnées gérées.

• Elle possède également sa propre application de service de métadonnées gérées, ce qui permet à cette équipe de gérer ses propres métadonnées de façon autonome. Étant donné que cette application de service est partagée, les métadonnées en provenance du reste de l’organisation peuvent être intégrées à ces métadonnées.

Utilisez cette configuration pour atteindre les objectifs suivants :

• permettre à une équipe ou à un département spécialisé de gérer eux-mêmes les métadonnées ;

• faire en sorte que des données de service spécifiques soient isolées et gérées indépendamment du reste de l’organisation.

Batteries de serveurs de services spécialisées

Envisagez de déployer des batteries de serveurs de services spécialisées afin d’optimiser les ressources de batterie de serveurs pour des applications de service spécifiques. Cela vous permet d’appliquer une montée en puissance parallèle à la batterie de serveurs et une montée en puissance par unité à la configuration matérielle afin d’optimiser les performances pour une application de service spécifique.

L’application de service principale qui peut justifier une batterie de serveurs de services dédiée est l’application de recherche. Celle-ci présente des contraintes spécifiques en termes de performance et de capacité. En basculant l’application de service de recherche vers une batterie de serveurs dédiée, vous pouvez optimiser les ressources pour les autres applications de service déployées entre les batteries de serveurs.

Le diagramme suivant illustre deux batteries de serveurs de services centralisées. L’une est optimisée pour la recherche, tandis que l’autre héberge toutes les autres applications de service déployées entre les batteries de serveurs.

Batteries de serveurs à l’échelle de l’organisation

Les applications de service peuvent être partagées dans toute batterie de serveurs, pas seulement dans les batteries de serveurs de services d’entreprise. Envisagez le partage des applications de service entre les batteries de serveurs dans les scénarios suivants.

Scénario A : fournir des applications de service à l’échelle de l’entreprise sans une batterie de serveurs de services d’entreprise dédiée, comme illustré dans le diagramme suivant.

Scénario B : partager des ressources entre les batteries de serveurs et éviter de déployer des applications de service redondantes, comme illustré dans le diagramme suivant.

See Also

Other Resources

Centre de ressources : conception d’architecture pour SharePoint Server 2010 (éventuellement en anglais)
Centre de ressources : sécurité et authentification pour SharePoint Server 2010 (éventuellement en anglais)