Migrer votre ArcGIS Server "Standalone" vers ArcGIS Enterprise - 2/2
Dans la première partie de cet article, nous avons décrit les grandes différences entre un déploiement d'ArcGIS Server "Standalone" tel qu'il se faisait avant les versions 10.5/10.6 et un déploiement d'ArcGIS Enterprise (anciennement ArcGIS Server) avec ses nouvelles capacités et ses nouveaux composants. Dans cette seconde partie, je vous propose de voir 3 scénarii de migration possibles pour passer d'un serveur de données et de services SIG à un SIG web collaboratif.
Option 1:
Dans ce scénario, l'administrateur réalise une mise à jour de son ArcGIS Server (et du Web Adaptor) vers la version 10.5 (ou supérieure) en suivant la procédure de migration de la documentation. Une fois l'installation terminée, le composant ArcGIS Server sera fédéré au portail (partage du même système d'authentification des utilisateurs) et sera désigné comme serveur d'hébergement (prise en charge de la publication des services hébergés sur le portail).
L'intérêt de cette option est de conserver l'infrastructure existante et de ne pas avoir à republier les services. Ces derniers conserveront également leur URL ce qui simplifie le portage éventuel des applications clientes.
Option 2:
Ce second scénario consiste à migrer votre ArcGIS Server mais également à faire évoluer votre infrastructure (qu'elle se compose d'une ou plusieurs machines). L'idée consiste à installer un déploiement de base d'ArcGIS Enterprise sur une nouvelle machine. Si le nouveau site ArcGIS Enterprise est composé d'une seule machine vous pourrez utiliser l'assistant ArcGIS Enterprise Builder pour une installation simple et rapide (compter environ 20 minutes).
Une fois ArcGIS Enterprise installé, vous devrez republier les services web sur le portail ArcGIS Enterprise. Cette opération peut être en partie automatisée, notamment avec des scripts Python (ArcPy et API ArcGIS for Python). On notera que les licences d'ArcGIS Enterprise permettent d'exécuter en parallèle les deux serveurs pour une durée de 6 mois.
Lorsque la republication des services est terminée, vous pouvez supprimer l'instance de votre ArcGIS Server "Standalone".
Option 3:
Le dernier scénario est le plus complet et apporte un compromis par rapport aux deux précédents. Il consiste tout d'abord à mettre à jour votre ArcGIS Server "Standalone" en version 10.5 ou supérieure. Ensuite, l'idée est de créer un nouveau déploiement de base ArcGIS Enterprise sur une nouvelle infrastructure (une ou plusieurs machines). La dernière étape consiste à fédérer l'ArcGIS Server "Standalone" à votre site ArcGIS Enterprise afin d'utiliser le même système d'identification des utilisateurs et partager ainsi les ressources de votre ArcGIS Server "Standalone" sur le portail ArcGIS.
Cette option est intéressante car elle ne nécessite pas de republication des services web et donc pas de changements d'URLs de ces derniers. En revanche, il convient de noter que dans ce scénario vous continuer à utiliser ArcGIS Server sur l'infrastructure d'origine ce qui veut dire qu'en termes de licences, l'acquisition de coeurs supplémentaires sera nécessaires.
Conclusion:
Le tableau suivant récapitule les 3 options avec leurs avantages et leurs inconvénients.
Il est important de noter qu'un déploiement de base d'ArcGIS Enterprise (c'est à dire les 4 composants: Portal, Server, Data Store et Web Adaptor) peut se faire sur une seule et même machine mais également en éclatant chacun de ces composants sur des machines différentes (physiques ou virtuelles). Le nombre de coeurs CPU des machines hébergeant la partie Portal, Data Store et Web Adaptor n'a aucune incidence sur les licences.
Si vous avez besoin de conseil ou d'accompagnement sur ces sujets de migration de vos sites ArcGIS Server "Standalone", n'hésitez pas à contacter votre interlocuteur Esri France.
2 comments :
Bonjour
L'arcgis server standalone est en général connecté à une base de données contenant les données publiées. Il manque dans ton article des considérations sur la migration de données :
- Option 1 & 2 : l'arcgis server d'hébergement peut être connecté à la base de donnée. Il diffuse alors des Map ou Feature Services classiques et de services d'entités hébergées. Cette cohabitation est possible mais risqué car on maîtrise moins le nombre de services hébergés pouvant être créés par les utilisateurs du portal.
En option 1 & 2 , en fonction du nombre de données de la base initiale, on peut se poser la question du transfert de celle-ci dans le datastore.
- Option 3 : Permet d'éviter la cohabitation des services d'entités hébergées et les services classiques. C'est une solution plus propre mais plus coûteuse en terme de licence , ressource, maintenance,...
Cordialement
Bonjour Xavier,
Merci pour tes remarques, elles sont tout à fait pertinentes. L'option 3 est la plus "propre" notamment parce qu'elle permet de séparer les services "classiques" d'ArcGIS Server des services plus simple (et donc moins consommateur) du Data Store. Les services "classiques" nécessitent, pour une partie d'entre eux, des données stockées dans une Géodatabase Enterprise (entités complexes, workflows de versionnement, données raster, volonté de gérer le SGBD, ...). Il est donc intéressant de faire la distinction dans son architecture mais si, comme je l'indique, elle peut nécessiter des coeurs supplémentaires en termes de licences.
Aujourd'hui, ArcGIS Enterprise permet l'utilisation d'une Géodatabase Enterprise (Oracle, PostgreSQL, SQlServer, ...) comme Data Store pour le serveur d'hébergement. Cela pourrait ne plus être le cas dans les versions futures.
Enregistrer un commentaire