Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem


Leave a comment

SharePoint: Comparatif architectural des solutions de migration de contenu

Introduction

La parution récente de l’excellente présentation de B. Jester ci-dessous,

me donne l’opportunité de commenter les solutions de migration de contenu d’un point de vue architectural (composants, flux…) car celui-ci peut s’avérer être un facteur déterminant dans le cadre du choix de l’outil de migration dans les environnements complexes. Vous l’aurez compris, ce comparatif ne traitera donc ni les aspects fonctionnels ni financiers.

2 types architectures s’opposent:

  • Les Clients lourds (ShareGate ou Metalogix)
  • Les Infrastructure Serveurs (DocAve)

Les Clients lourds (ShareGate ou Metalogix)

Aperçu

Comme le montre le schéma ci-dessous, ce type d’architecture s’avère particulièrement simple. Elle s’articule autour d’un client lourd, tout la logique de migration résidant au sein de celui-ci, interagissant avec les API distantes SharePoint (web services etc.). Pour SharePoint (ou O365), ces solutions se comportent rigoureusement comme n’importe quelle application cliente (navigateur, suite Office, SharePoint Designer, client OneDrive for Business…). Note: Les extensions « serveurs » optionnelles proposées par ces solutions revêtent également la forme de web service.

spmigfatclient

Deux variations possibles :

  • L’hébergement de l’application sur un serveur « de migration »
  • L’accès direct aux bases de données source en lecture, contournant ainsi le modèle de sécurité SharePoint

Principaux facteurs limitant la performance:

  • Les infrastructures serveur SharePoint source et destination (ou O365)
  • Le poste client
  • Le lien réseau client vers infrastructure SharePoint source et destination

Les Pours

  • Simplicité et facilité de déploiement : l’installation prend quelques secondes. Après cela, la migration peut immédiatement commencer.
  • Insensibilité au changement d’infrastructure : peu importe les modifications de topologie des infrastructures SharePoint et pour autant que l’accès au service soit maintenu, il n’y aura aucune incidence sur l’application de migration en elle-même
  • Facilité de délégation : Déléguer la fonction de migration, même de manière granulaire, s’avère particulièrement simple, tout en s’appuyant entièrement sur le modèle de sécurité SharePoint (voir ci-dessous)
  • Honore entièrement le modèle de sécurité SharePoint : Les limites de l’outil dérivent directement du niveau d’habilitation de l’utilisateur qui en fait usage. Cela peut permettre éviter bon nombre de dérapages ». Les accès seront également retracés côté SharePoint (Audits, traçabilité etc…)
  • Aucune modification de l’infrastructure requise. Note : à l’exception des extensions « serveur » qui restent toutefois optionnelles. Cela peut également facilité l’intervention des prestataires externes, par exemple, dans le cas d’une migration “tactique”
  • Facilité d’identification et de suivi des flux réseau : en cas de sécurisation des infrastructures à l’aide de pare-feu de périmètre, ceux-ci sont très certainement déjà adaptés à l’usage des outils de migration car identiques à ceux requis par l’utilisation de SharePoint
  • Possibilité de limiter l’impact des activités migration sur le service SharePoint par le biais de fonctionnalités natives comme par ex. le Request Management
  • Le suivi technique des migrations s’effectue par des log côté client, ce qui facilite leur accessibilité et leur lecture
  • Cette solutions, même combinées à d’autres produits du même éditeur, reste isolée, ce qui prévient des effets de bord éventuels en cas de déploiement de correctifs etc.

Les Contres

  • Permet les déploiements non contrôlés : ces solutions n’étant pas verrouillables de manière centralisée (SharePoint ou outil serveur), un utilisateur, pour autant qu’il dispose de privilèges administrateur sur son poste de travail, sera en mesure d’installer et d’utiliser le client lourd sans aucune restriction à l’exception des permissions dont il dispose dans les sites SharePoint auquel il a accès.
  • Sensibilité à l’authentification en place sur les web applications SharePoint : bien que compatible avec l’éventail des authentifications standards, ces solution rencontrerons des problèmes avec les authentifications customisées ou les pré-authentifications (clé RSA, certificats client, certains types de cookies…). C’est inhérent à leur architecteur client lourd adressant les API distantes SharePoint.
  • Dépendance vis-à-vis des API SharePoint distantes: Si celles-ci sont désactivée (pour des raisons de sécurité notamment), l’application sera incapable de communiquer avec SharePoint
  • Paramétrage de l’outil (incluant les scénarios de migration) qui réside sur le poste client. En cas de paramétrage complexe à répéter régulièrement, il peut s’avérer intéressant d’en prendre une sauvegarde afin de faire face à la perte du poste
  • L’impact en terme d’utilisation de ressources système sur le poste client et la mobilisation de celui-ci peut s’avérer importante voire bloquante pour d’autres applications. Il existe évidemment une solution de contournement consistant à installer l’application sur un serveur dit « de migration ». Dans ce cas, il doit également être dimensionné en fonction du nombre d’utilisateurs concurrent et de la lourdeur de la migration. Ce contournement pourrait également entrainer des surcouts en termes de licences (RDP, Citrix ou autre). Par voie de conséquence, il est difficile de prévoir la durée exacte d’exécution d’une tâche de migration. Le facteur réseau (type de raccordement, bande passante, latence) est particulièrement déterminant
  • Il peut s’avérer nécessaire d’installer les extensions sur les serveurs SharePoint afin de tirer parti des toutes les fonctionnalités proposées
  • Lors de longs projets de migration requérant des interventions du support produit, il ne sera pas rare de devoir, à plusieurs reprises, déployer des correctifs. Il est donc recommander de tenir un inventaire des sièges ou l’application de migration est installée afin de faciliter les mises à jour

Note : Metalogix propose également un accès direct en lecture aux bases de données. Cela permet d’augmenter sensiblement les performances en lecture, se s’affranchir des contrainte d’authentification SharePoint et de l’exploitation des API distante mais aura pour conséquence de contourner la sécurité SharePoint. Pour rappel : Article de KB MS Prise en charge des modifications apportées aux bases de données qui sont utilisés par les produits Office server et Windows SharePoint Services

Les infrastructures serveurs (DocAve)

Aperçu

L’architecture de ce type de solution s’appuie sur 2 composants-clé :

  • Le manager : expose l’interface web d’administration et d’utilisation du produit
  • Les agents : installés sur un ou plusieurs serveurs SharePoint et sur le serveur hébergeant le manager, ils ont pour fonction d’exécuter les demandes saisies dans celui-ci par le flux de contrôles. Ensuite, les agents communiquent entre eux pour transmettre les données. Le service Windows constituant l’élément actif de l’agent nécessite des privilèges élevés au niveau Windows, SharePoint et SQL (proches de ceux requis par le compte de la ferme).

spmigsrvinfra

La solution DocAve se base, dans sa globalité, sur ces composants, aussi bien pour la migration que pour d’autres usages. L’activation de chaque module se faisant par la mise en place des licences appropriées.

Principaux facteurs limitant la performance:

  • Les infrastructures serveur SharePoint source et destination (ou O365)
  • Le lien réseau client vers infrastructure SharePoint source et destination

Les Pours

  • Prérequis postes clients réduits : une fois en place côté serveur, la solution ne demandera, dans la plupart des cas, aucune intervention sur le poste client
  • Solution insensible aux configurations spécifiques de l’authentification SharePoint. Elle fonctionnera dans tous les cas de figures, mêmes les plus exotiques, car elle ne dépend pas de ce composant
  • Aucune mobilisation de ressources sur les postes clients lors des exécutions des tâches de migration. Cela permet de lancer des tâches de migration et d’attendre la fin de leur exécution tout en continuant d’utiliser les applications bureautiques sans dégradation ni interruption
  • Solution potentiellement la plus performance : si le lien réseau entre l’infrastructure SharePoint et la destination est rapide, peu chargé et sujet à peu de latence, le résultat sera supérieur à celui proposé par l’approche client lourd
  • Peut s’inscrire dans une solution complète de gestion de SharePoint de bout-en-bout par le biais d’une seule interface homogène et d’une seule instanciation

Les Contres

  • Déploiement côté serveur assez lourd (applications, compte technique, modifications de sécurité etc). Peut également requérir un serveur dédié pour le rôle de manager (voir point d’attention plus loin dans cet article)
  • Contournement du modèle de sécurité SharePoint : l’outil contourne entièrement le modèle de sécurité SharePoint par le biais d’un compte technique aux privilèges particulièrement élevés. Note : une habilitation spécifique au module de migration peut-être prévue mais elle ne couvre pas 100% des cas de figure
  • Risque d’erreur humaine avec de lourdes conséquences (voir points précédents et suivants) : le niveau d’autorisation n’étant pas granulaire, il est possible de migrer le “mauvais » contenu sur la “mauvaise” destination. Il est impératif de s’en protéger grâces à des techniques de restaurations adaptée (du même fournisseur, notamment
  • Très peu de traçabilité des actions : bien que chaque tâche de migration soit rattachée à l’utilisateur qui l’a initiée, la plupart des actions techniques sous-jacentes seront ensuite exécutée par le biais du compte technique. Cela empêchera donc toute traçabilité de celles-ci. Note : le manque de traçabilité s’applique également à l’usage de la volumétrie de migration liée à la licence
  • Fonctionnement “semi boîte noire” : Une fois une tâche de migration lancée, il faut attendre la fin de celle-ci pour en mesurer réellement le résultat
  • Aucun mécanisme de limitations de l’impact sur les ressources serveur: si les serveurs SharePoint sont proches de la saturation, l’exécution de tâches de migration pourrait potentiellement les achever
  • Suivi technique des migrations qui peut s’avérer compliqué car les informations sont éparpillées : rapport de migration par le biais du manager, fichier log sur les agents (donc sur les serveurs SharePoint) et log SharePoint. Pas de consolidation de ceux-ci
  • Complexité liée au déploiement des correctifs: Les correctifs livrés par le support sont souvent spécifiques au client et non cumulatifs. Il revient donc au client de les consolider dans les déploiements (par ex ajout d’un serveur à la batterie et par conséquent, d’un agent)

Point d’attention : DocAve vs. O365 vs. Windows Server 2003

Imaginons le scénario suivant : une infrastructure SharePoint 2007 sur Windows Server 2003 devant être migrée vers Office 365.

Pour rappel, les flux se font d’agent à agent. Dans ce cas-ci toutefois, il n’y a pas d’agent DocAve sur Office 365, il y aura donc une communication agent vers Internet. Or celle-ci va devoir se conformer avec les standard Office 365 (sur l’authentification par WS-Federation…) et malheureusement, les composants Windows requis ne sont pas disponibles pour Windows Server 2003 (Framework .Net 4.5, WIF…).

Il faudra donc mettre en place un serveur de rebond (Windows Server 2008 à minima) afin d’en bénéficier. Ce serveur, bien que n’hébergeant aucun composant SharePoint, sera équipé d’un agent DocAve connecté au même manager que ceux de la ferme dont le contenu doit être migré. Le schéma ci-dessous reflète l’architecture à mettre en place.

spmigsrvinfrao365

Merci à AvePoint pour le support technique et à @J3rrr3 pour la mise en place.

Liens Utiles

Advertisements