Guide général pour hébergeurs SharePoint Server 2013
S’APPLIQUE À :
2013 
2016 2019 Subscription Edition SharePoint dans Microsoft 365
Cet article décrit des conseils et des concepts généraux liés à l’architecture mutualisée dans SharePoint Server 2013.
Pour plus d’informations sur l’architecture, la sécurité, l’exploitation et les conseils en matière de gestion pour aider les fournisseurs de services à acquérir une bonne connaissance de la mutualisation dans SharePoint Server 2013, reportez-vous à l’article relatif à l’architecture mutualisée dans Microsoft SharePoint Server 2013.
Principales caractéristiques et considérations sur l’architecture mutualisée
Lorsque vous envisagez la multilocation, il existe deux extrêmes pour le modèle d’implémentation d’une plateforme d’hébergement multilocataire :
Dédié
Partagé
Ces deux modèles se trouvent aux deux extrémités d’un spectre, comme illustré dans le diagramme suivant.
La décision d’implémenter une plateforme d’hébergement multilocataire se résume à la sélection entre ces deux modèles d’implémentation. La décision est généralement basée sur les composants fonctionnels requis et les attributs de niveau de service suivants qui influencent généralement le choix d’un modèle d’implémentation approprié pour une plateforme d’hébergement multilocataire.
Réduction des coûts
Gestion et exploitation simplifiée
Complexité de la personnalisation
Isolement des ressources
Qualité de Service
Ces attributs clés sont importants à prendre en compte lorsque vous prenez les décisions relatives à la sélection de l’architecture, de l’implémentation et du déploiement appropriés d’une plateforme d’hébergement SharePoint Server 2013 mutualisée. 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 service partagé a été implémenté. Ce nouveau modèle est appelé Applications de service. L’architecture d’application de service permet à un ensemble de services d’être associés à un groupe d’applications web et à un autre ensemble de services à associer à un autre groupe d’applications web. En outre, la même application de service peut être configurée différemment pour différents groupes d’applications web et un site web peut être configuré pour utiliser uniquement les services nécessaires, au lieu de la banque complète 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. Les services peuvent être créés en mode partitionné à l’aide de Microsoft PowerShell ou en mode non partitionné à l’aide de Microsoft PowerShell ou de l’Administration centrale. Une fois créé, le mode du service ne peut pas ê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. Les services qui ne stockent pas les données de locataire, tels que PowerPoint Automation Services, n’ont pas besoin d’ê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 Paramètres d’abonnement effectue le suivi des services multilocataires et des ID d’abonnement.
Voici le principe de fonctionnement :
Les administrateurs de batterie déploient des services sur la batterie de serveurs. Cela inclut le service Paramètres d’abonnement. Les applications de service peuvent être déployées en tant que partitionnés où les données sont isolées pour chaque locataire, ou non partitionnée où les données sont partagées entre tous les locataires. Certains services ne stockent pas de données de locataire et sont partagés entre tous les locataires sans partition.
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 d’autres collections de sites pour chaque locataire. Chaque collection de sites est liée à l'ID d'abonnement du client.
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.
Les administrateurs de clients gèrent leurs collections de sites à l’aide du site d’administration des clients qui leur a été affecté.
Les collections de sites pour les abonnements de sites multiples peuvent être hébergées dans une application web unique.
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.
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.
| Role | Type d’administrateur | Description |
|---|---|---|
| Administrateur du fournisseur de services |
Administrateur de batterie de serveurs |
Gère les paramètres et le matériel au niveau de la batterie de serveurs. Contrôle les configurations de base de données. Installe toutes les nouvelles fonctionnalités et solutions approuvées. Peut personnaliser les pages d’administration des clients. |
| Administrateur d’entreprise hébergée |
Administrateur des clients |
Achète de l’espace, des fonctionnalités et de la bande passante au fournisseur de services. Contrôle l’architecture des sites clients, mais pas leur contenu. Configure les paramètres des clients. Permet de consulter les statistiques d’utilisation. |
| Entreprise hébergée |
Administrateur de site |
Est responsable des collections de sites. Configure les paramètres de site exposés par les fonctionnalités et les services. Permet de consulter les statistiques d’utilisation. |
L’administration des locataires est fournie via le site Administration du locataire, qui est basé sur un modèle de site intitulé « Administration du locataire ». Un administrateur de batterie peut utiliser les applets de commande Microsoft PowerShell pour créer un site d’administration de locataire et accorder l’accès à un administrateur de locataire. 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 instructions, les futures mises à niveau de SharePoint peuvent être étendues à un seul locataire, s’il existe un locataire par base de données de contenu, ou à un petit groupe de locataires. Plutôt que d’avoir à mettre à niveau tous les locataires en même temps.
Partitionnement de données physique contre partitionnement de données logique
Le partitionnement des données joue un rôle important dans le choix de l’approche à adopter pour un déploiement SharePoint, alors qu’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 obligatoire et le sélecteur de personnes SharePoint est entièrement 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.
Notes
Les considérations qui précèdent sont valables pour les batteries à client unique ou à plusieurs clients.
Pour plus d’informations sur l’authentification SAML et l’authentification FBA dans SharePoint Server 2013, voir Configurer l’authentification par revendications SAML avec AD FS dans SharePoint Server et Configurer l’authentification basée sur les formulaires pour une application web basée sur des revendications dans SharePoint Server.
Expérience d’administrateur client
Selon la topologie, l’expérience d’administrateur peut être différente :
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’existe aucun moyen de déléguer des fonctionnalités spécifiques du site web Administration centrale de SharePoint à l’administrateur client pour provisionner 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 précédente, il existe des fonctionnalités spécifiques dans l’Administration centrale qui ne peuvent pas être effectuées sans provoquer de résultats inattendus potentiels. 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.
| Topologie | Description |
|---|---|
|
Isolation complète |
Cette topologie contient une batterie de serveurs SharePoint, une instance SQL Server et une forêt configurée par client ou par fournisseur d'identité. Cette configuration de topologie est la plus coûteuse, mais offre le degré de ségrégation de données et de services le plus élevé possible. |
|
Infrastructure partagée, batteries isolées |
Dans cette configuration, SQL Server, les services de domaine Active Directory et l'infrastructure du fournisseur d'identité sont partagés. Cependant il existe toujours une batterie de serveurs SharePoint par client. |
|
Partage complet |
Cette topologie est une infrastructure partagée pour SQL Server, les services de domaine Active Directory et l'infrastructure de fournisseur d'identité et est partagée pour SharePoint Server 2016, où une seule batterie de serveurs SharePoint peut héberger plusieurs clients. |
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. De nombreux aspects clés de la gestion des services opérationnels de SharePoint Server 2013 se comportent différemment lorsqu’ils utilisent la multilocataire et nécessitent donc une attention particulière. Ces aspects varient d'une entreprise à l'autre en fonction des niveaux de service et des capacités opérationnelles. Les partenaires d’hébergement doivent garantir que la planification satisfaisante de la personnalisation requise, avec des solutions personnalisées ou Microsoft PowerShell, est en place dès que possible, pour répondre aux attentes des clients. 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.
| Application de service | Enregistre les données du client | Prend en charge le partitionnement | Prise en charge pour l’architecture mutualisée |
|---|---|---|---|
| Métadonnées gérées |
Oui |
Oui |
Oui |
| Profils utilisateur |
Oui |
Oui |
Oui |
| Business Data Connectivity |
Oui |
Oui |
Oui |
| Recherche SharePoint |
Oui |
Oui |
Oui |
| Banque d'informations sécurisée |
Oui |
Oui |
Oui |
| Automatisation de Word |
Oui |
Oui |
Oui |
| Traduction automatique |
Oui |
Oui |
Oui |
| Gestion du travail |
Non |
Non |
Oui |
| Automatisation de PowerPoint |
Non |
Non |
Oui |
| Collecte de données relatives à l’utilisation et à l’état |
Oui |
Non |
Oui (obligatoire pour la recherche) |
| Paramètres d’abonnement |
Oui |
Non |
Oui (obligatoire) |
| Gestion des applications |
Non |
Non |
Oui |
| Services d’accès |
Non |
Non |
Oui |
| Access Services 2010 |
Non |
Non |
Oui |
| PowerPoint |
Non |
Non |
Oui |
| Graphiques Visio |
Non |
Non |
Oui |
| Calcul Excel |
Non |
Non |
Non |
| Point de performances |
Oui |
Non |
Non |
| Viva Engage |
Non |
Non |
Non |
| Intégration SharePoint pour OneDrive |
Non |
Non |
Non |
Remarque
[!REMARQUE] La colonne Prise en charge pour l'architecture mutualisée indique que vous ne pouvez pas procéder à une configuration avec architecture mutualisée. Vous obtenez un message d'erreur.
En plus des considérations précédentes, les processus et scripts d’approvisionnement et de déprovisionnement des locataires doivent prendre en compte chaque application de service qui stocke les données du locataire. 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.