Guide général pour hébergeurs SharePoint Server 2013

**Sapplique à :**SharePoint Server 2013

**Dernière rubrique modifiée :**2017-09-06

Résumé : Guide de l’administrateur pour les hôtes mutualisés dans SharePoint Server 2013.

Cet article décrit l’orientation et les concepts généraux associés à l’architecture mutualisée dans SharePoint Server 2013

Pour plus d’informations sur l’architecture, la sécurité, l’exploitation et le conseil en matière de gestion pour aider les fournisseurs de services à acquérir une bonne connaissance de la mutualisation dans SharePoint Server 2013, voir Architecture mutualisée SharePoint Server 2013.

Principales caractéristiques et considérations sur l’architecture mutualisée

Lorsque vous envisagez l’architecture mutualisée, il existe deux modèles radicalement différents de mise en œuvre d’une Plateforme d’hébergement mutualisée :

• Dédié

• Partagé

Ces deux modèles se trouvent aux deux extrémités d’un spectre, comme illustré dans le diagramme suivant.

Décider de mettre en œuvre une Plateforme d’hébergement mutualisée revient à faire un choix entre ces deux modèles. La décision dépend en généraldes composants fonctionnels requis et des attributs relatifs au niveau de service qui suivent, qui d’ordinaire influencent le choix d’un modèle de mise en œuvre d’une Plateforme d’hébergement mutualisée.

• Réduction des coûts

• Gestion et exploitation simplifiée

• Complexité de la personnalisation

• Isolement des ressources

• Qualité de Service

Il est important de prendre ces attributs clés en compte lorsque vous prenez des décisions en matière de sélection de l’architecture, de mise en œuvre et de déploiement d’une architecture de plateforme d’hébergement mutualisée SharePoint Server 2013. Le schéma suivant montre comment ces attributs clés varient d’un modèle de mise en œuvre à l’autre.

Comment l’architecture mutualisée fonctionne-t-elle dans SharePoint Server 2013 ?

L’architecture mutualisée native a été introduite dans SharePoint Server 2010 pour faire de SharePoint une plateforme mutualisée valide. SharePoint Server 2013 hérite des mêmes fonctionnalités et conception d’architecture mutualisée et de l’ajout de nouvelles fonctionnalités prenant en charge les déploiements d’architecture mutualisée.

Dans SharePoint Server 2010, un nouveau modèle de services partagés connu sous le nom d’Applications de service a été mis en œuvre. L’architecture d’application de service permet à un ensemble de services d’être associé à un groupe d’applications web et à un autre ensemble de services d’être associé à un groupe d’applications web distinct. En outre, il est possible de configurer différemment une application de service pour les différents groupes d’applications web et de configurer un site web pour utiliser uniquement les services nécessaires, et non la totalité de la banque de services.

Dans SharePoint, l’architecture mutualisée fait référence à la capacité de partitionner les données de services partagés autrement pour servir plusieurs clients. Cela est différent de la configuration de matériel dédié ou même, de l’exécution de plusieurs instances d’un service donné.

Les services peuvent être configurés pour partager les données entre tous les clients ou pour partitionner les données pour chacun d’eux, par exemple, en offrant l’isolation de certaines données. Chaque service peut être configuré différemment. Des services peuvent être créés en mode partitionné avec Microsoft PowerShell ou en mode non partitionné avec Microsoft PowerShell ou Administration centrale. Une fois créé, le mode de fonctionnement du service ne peut plus être modifié. Pour obtenir le partitionnement, le service et la connexion de service doivent tous les deux être déployés en mode partitionné. La connexion de service est appelée proxy dans Microsoft PowerShell.

Tous les services ne peuvent pas être partitionnés. Des services ne stockant pas de données client, tels que les services d’automatisation de PowerPoint, n’ont pas à être partitionnés. Ces services peuvent être partagés entre plusieurs clients sans risque d’exposition des données de clients spécifiques.

Le diagramme suivant montre la façon dont les données de service sont partitionnées :

Dans SharePoint, l’architecture mutualisée est liée à l’abonnement à un site. Un abonnement à un site est un groupe logique de collections de sites pouvant partager des paramètres, des fonctions et des données de service. Les collections de sites de chaque client sont réunies dans un ID d’abonnement. L’ID d’abonnement est utilisé pour mapper des fonctionnalités, services et sites sur des clients, et pour partitionner les informations de service en fonction de ce dernier. Le service de paramètres d’abonnement assure le suivi des services avec architecture mutualisée et des ID d’abonnement.

Voici comment cela fonctionne :

1. Les administrateurs de batterie de serveurs déploient des services dans la batterie, notamment le service de paramètres d’abonnement. Les applications de service peuvent soit être déployées au format partitionné lorsque les données de chacun des clients sont isolées, soit ne pas être partitionnées lorsque les données sont partagées entre tous les clients. Certains services n’enregistrent pas les données de clients et sont partagés entre tous les clients sans partition.

2. Les administrateurs de batterie de serveurs mettent en œuvre un site d’administration des clients pour chaque client à l’aide de Microsoft PowerShell. Le site d’administration des clients est associé à un ID d’abonnement. Les administrateurs peuvent déployer des collections de sites supplémentaires pour chaque client. Chaque collection de sites est liée à l’ID d’abonnement du client.

3. Toutes les applications de service connectées au niveau de l’application web peuvent être utilisées par des collections de sites au sein de l’application web. Les administrateurs choisissent les services à offrir et à activer pour chaque client. L’ID d’abonnement d’un client est utilisé pour mapper des services sur les collections de sites.

4. Les administrateurs de clients gèrent leurs collections de sites à l’aide du site d’administration des clients qui leur a été affecté.

5. Les collections de sites pour les abonnements de sites multiples peuvent être hébergées dans une application web unique.

6. Les abonnements de sites multiples peuvent partager une base de données de contenu, ou un abonnement à un site peut inclure le contenu de plusieurs bases de données.

7. Toutes les collections de sites d’un abonnement unique doivent résider sur la même batterie de serveurs, mais peuvent être propagées par le biais d’applications web.

Les administrateurs de batterie peuvent héberger plusieurs clients sur la même batterie et gérer de manière centralisée le déploiement de services et de fonctionnalités. Ils peuvent gérer la configuration des fonctions déléguées de l’administrateur délégué et contrôler le fonctionnement de leurs sites.

SharePoint configure ses fonctionnalités d’administration en fonction des rôles d’hébergement communs, comme l’indique le tableau suivant.

L’administration des clients s’effectue via le site d’administration des clients réalisé à partir d’un modèle de site intitulé « Administration des clients ». Un administrateur de batterie peut utiliser des cmdlets Microsoft PowerShell pour créer un site d’administration des clients et octroyer un accès à un administrateur client. Le diagramme qui suit affiche la page d’accueil du site d’administration des clients.

Un administrateur client peut utiliser le site d’administration des clients pour gérer de nombreux aspects de l’abonnement. Par exemple, il peut gérer l’ensemble des collections de sites de l’abonnement à partir d’un même emplacement. Le diagramme suivant affiche la page Gestion des collections de site du site d’administration des clients.

Base de données de contenu partagée ou base de données de contenu isolée

Pour faciliter la gestion des mises à niveau futures, utilisez les instructions suivantes pour gérer les clients dans les bases de données de contenu :

• Si un client doit englober plusieurs base de données de contenu, il doit être le SEUL locataire de ces bases de données de contenu. Cette dernière est alors de type dédié.

• Si un client partage une base de données de contenu ayant un autre client, ces locataires ne doivent pas englober les bases de données de contenu.

En suivant ces directives, les mises à niveau futures de SharePoint peuvent être attribuées à un seul client, s’il n’en existe qu’un par base de données de contenu, ou à un petit groupe de clients au lieu d’avoir à mettre à niveau tous les locataires en même temps.

Partitionnement de données physique contre partitionnement de données logique

Le partitionnement de données joue un grand rôle dans la décision de l’approche à adopter pour le déploiement de SharePoint, et une partition physique est requise. La solution consiste à disposer d’une batterie de serveurs et même d’un fournisseur d’identité unique par client. Cependant, si certaines données peuvent être partagées, il est possible par la suite de passer au partage d’éléments de l’infrastructure entre plusieurs clients, serveurs de base de données, certains services SharePoint, et sur la batterie.

Quel modèle d’identité et d’authentification voulez-vous ?

Selon les conditions d’authentification requises, un code personnalisé peut être requis. Lorsque vous utilisez l’authentification Windows, le code n’est pas requis et le sélecteur SharePoint est parfaitement fonctionnel. Security Assertion Markup Language (SAML) ou Forms Based Authentication (FBA) requièrent un fournisseur de revendications personnalisé mettant en œuvre des recherches et validant des procédures.

Pour plus d’informations sur l’authentification SAML et l’authentification FBA dans SharePoint Server 2013, voir Configurer l’authentification basée sur les revendications SAML avec les services ADFS dans SharePoint 2013 et Configurer l’authentification basée sur les formulaires pour une application web basée sur les revendications dans SharePoint 2013.

Expérience d’administrateur client

Selon la topologie, l’expérience de l’administrateur peut varier sensiblement :

• Dans l’approche un client par batterie, il n’y a pas de possibilité inhérente au produit permettant de séparer l’expérience de gestion administrative des serveurs de l’expérience de gestion de client. En d’autres termes, il n’y a aucun moyen de déléguer des fonctionnalités spécifiques de l’le site Web Administration centrale de SharePoint à l’administrateur des clients pour mettre en service de nouvelles collections de sites. Il est également impossible de configurer un centre de recherche par défaut pour le client sans permettre la modification d’une topologie de batterie ou de la configuration de service.

• Dans l’approche plusieurs clients par batterie, le produit fournit une console d’administration interne au produit. La collection de sites permet aux administrateurs de clients d’exécuter des fonctionnalités spécifiques. Dans la configuration qui précède, il existe des fonctionnalités spécifiques de l’Administration centrale qui ne peuvent pas être exécutées sans produire des résultats inattendus. Par exemple, ne créez pas de collections de sites dans Administration centrale.

Différents types de topologies

Cette section décrit les différents types de topologies pouvant être déployés pour un environnement d’hébergement SharePoint Server 2016.

Trois topologies peuvent être hébergées dans SharePoint Server 2016 dans un environnement local, et elles figurent dans le tableau qui suit.

Services et fonctionnalités

La collection de fonctionnalités et de services permettant l’architecture mutualisée avec SharePoint Server 2013 se compose d’une plateforme de base, qui est en général étendue pour offrir des services de bout en bout par les entreprises spécialisées dans l’hébergement. Certains aspects de gestion de services opérationnels clés de SharePoint Server 2013 se comportent différemment selon qu’ils utilisent une architecture mutualisée, et donc, doivent être soigneusement étudiés. Ces aspects varient d’une entreprise à l’autre en fonction des niveaux de service et des capacités opérationnelles. Pour satisfaire les clients, les partenaires en charge de l’hébergement doivent mettre en place un calendrier adapté pour la personnalisation supplémentaire requise, soit grâce à des solutions personnalisées, soit grâce à Microsoft PowerShell. Voici quelques exemples dans cet espace :

• Mise en service initiale du client

• Personnalisation du modèle de site d’administration des clients

• Extension des quotas de la collection de site

• Logique de mise en service et de facturation

Les applications de service dans SharePoint Server 2013 se comportent différemment lorsque vous les configurez pour utiliser des solutions à architecture mutualisée, et certaines ont des impératifs uniques en matière de service et d’exploitation.

Les applications de service disponibles dans l’environnement SharePoint Server 2013 local apparaissent dans le tableau suivant.

Outre les considérations qui précèdent, il existe des procédures et des scripts de mise en service et hors service à prendre en compte pour chaque application de service stockant des données de client. Pour certaines applications de service, l’ensemble de la gestion des données du client est transféré à des éléments du site d’administration d’éléments, tandis que dans d’autres, une administration combinant le niveau de batterie de serveurs et de client est requise.