Multi-Tenancy with SharePoint 2010

Session animée par Spencer Harbar (Entreprise Architect)

Nous commençons par introduire la notion de multi-tenancy qui revient à vouloir isoler les données, les services et la gestion de plusieurs clients mais sur un environnement mutualisé.

Si on comparait cela à la vie de tous les jours, ce serait un immeuble avec des parties communes (escaliers, portes…) et des éléments propres à chaque personne (l’appartement).

Office 365, des hébergeurs classiques et des Clouds privés proposent ce genre de service mais il est possible de le faire OnPremise (very risky indeed comme l’indique le speaker dans son slide).

La notion de multi-tenancy dans SharePoint 2010 a été implémentée pour être utilisée dans Office 365 à la base.

Le multi-tenancy n’est pas juste une Feature à activer mais beaucoup d’éléments sont impactés (authentification, abonnements, profils…).

Un premier concept qui existait déjà sur SharePoint 2007, les Host Named Site Collection, a été enrichi sur SharePoint 2010 pour supporter les chemins d’accès gérés, les certificats SSL, etc…

Pour séparer les collections des clients, il faut créer des groupes logiques (appelés des Subscriptions) qui ne peuvent être activés que via l’API ou Powershell. Chaque Subscription possède un identifiant unique de type GUID pour l’identifier dans le système.

Les services applicatifs de SharePoint peuvent être partitionnés pour gérer le multi-tenancy mais il faut le faire lors de la configuration de la ferme car cela ne peut être changé ultérieurement (sauf en détruisant et recréant les services).

Les services devant être partitionnés sont ceux stockant des données (recherche, profils…). Ceux ne stockant pas de données n’ont pas besoin d’être partitionnés voir ne supportent pas le partitionnement (cf. photo).

Dans la mesure du possible, il vaut mieux désactiver les développements spécifiques voir les interdire. Le mode sandbox est là pour couvrir certains besoins et tout ce qui ne rentre pas dans une sandbox pourra poser des soucis sur un environnement mutualité.

Les grandes étapes de configuration sont :

  • Configurer les pré-requis côté infrastructure
  • Créer les WebApplications
  • Provisionner les services Applications
  • Créer des lots de Features
  • Provisionner les tenants

1ère démo pour montrer comment configurer la ferme qui a été installée au préalable.

Pour cela on commence par passer en revue un script Powershell qui va se charger de créer une WebApplication avec tous les éléments nécessaires (authentification, base de données, collection de site racine…).

D’autres scripts Powershell finisse de créer les éléments avec dans l’ordre les services Applications, le BCS, le Secure Store et Word Automation.

On voit que depuis l’administration centrale, certains services applications ne sont pas administrantes via les menus classiques, il faut aller dans l’administration des tenants pour accéder aux infos (ex: BCS et Metadata Store).

On passe ensuite à la définition des permissions sur les services applications (toujours via Powershell), on démarre le service de profils utilisateurs et on fini par configurer la recherche.

Retour aux slides pendant que la recherche se configure car cela prend plusieurs minutes.

Les pré-requis côté infrastructure concernent le réseau, le DNS, ActiveDirectory (notamment une OU pour chaque client), la ferme SharePoint et les comptes de services.

Les slides montrent les extraits importants des scripts Powershell qui ont été exécutés dans la démo précédente (les slides seront sur le réseau MCNEXT dans le courant de la semaine prochaine).

Retour à la démo pour vérifier que la recherche a finie d’être configurée, ce qui est le cas vu que la démo a bien été préparée   😉

On créer maintenant un Feature Pack dans lequel on défini toutes les features qui seront disponibles pour le tenant auquel sera affecté le pack.

On termine la configuration par le provisioning du tenant en spécifiant le nom, le mail, le feature pack devant être utilisé, la WebApplication associée, les MySite, un Content Type Hub…

Une fois que tout est configuré, on voit que l’on peut accéder aux services sans soucis (le people picker ne fait apparaître que les gens de l’OU du tenant, le TermStore est vide et on peut commencer à créer des termes, etc…).

On voit notamment qu’un site a été créé lors du processus de configuration des tenants (1 site par client), pour accéder aux options d’administration propres à chaque société.

Retour aux slides pour donner quelques trucs et astuces.

Le mode multi-tenancy ayant été à la base pensé pour Office 365, il faut suivre les mêmes recommandations d’usage pour l’implémenter OnPremise sinon il y aura de gros soucis.

Parmi les choses à ne pas faire, utiliser le multi-tenancy parce qu’on a vu que ça existait que ça a l’air cool. Il faut en avoir l’utilité avant de le mettre en œuvre.

De fortes contraintes sont imposées pour installer le multi-tenancy donc il faut bien réfléchir aux éléments qui impacteront le réseau de l’entreprise (ex: la structure AD) avant de se lancer dans l’installation.

FAST, PerformancePoint et Project Server ne sont pas supportés.

L’utilisation du mode d’authentification par Claims et plus que recommandée (voir obligatoire).

Il faut aussi savoir que l’implémentation du multi-tenancy requiert souvent du développement additionnel pour par exemple créer des interfaces permettant d’administrer la solution (plutôt que de tout faire via Powershell).

Service Application Partitioning

Service Application Partitioning

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s