Stratégies de migration

Dans ArcGIS Enterprise, le terme migration décrit les exigences d’une organisation relatives au déplacement d’un déploiement existant, ou de parties de celui-ci, vers un autre déploiement. Ce déploiement alternatif peut être plus récent, se trouver sur un autre système d’exploitation ou se trouver dans une autre infrastructure. Des stratégies de migration peuvent être utilisées pour déplacer un contenu existant depuis le déploiement d’origine vers un déploiement alternatif.

Stratégies fréquentes

Les besoins en matière d’architecture et de migration varient d’une organisation à l’autre, tout comme les stratégies et solutions respectives. La stratégie choisie pour migrer le contenu peut varier selon des facteurs spécifiques. Lorsque vous choisissez la stratégie de migration, prenez en compte les facteurs suivants :

• Quel est le contenu à migrer ? Il peut s’agir de l’intégralité du contenu, de l’intégralité du contenu ainsi que des utilisateurs et des groupes, ou d’un sous-ensemble spécifique du contenu.
• Quels sont les systèmes d’exploitation impliqués ? Lorsque vous procédez au déplacement depuis le même type de système d’exploitation, par exemple de Windows Server 2019 vers Windows Server 2022, vous devez tenir compte de considérations différentes de celles que vous prenez en compte lorsque vous procédez au déplacement depuis un déploiement Windows vers un déploiement Linux.
• Quel est le type d’infrastructure impliqué ? Les considérations à prendre en compte varient selon que vous migrez du contenu de ArcGIS Enterprise vers ArcGIS Enterprise ou de ArcGIS Enterprise vers ArcGIS Online. De plus, vous devez tenir compte d’autres considérations lorsque vous migrez depuis un déploiement sur site vers le cloud et inversement.

Les sections ci-dessous décrivent des stratégies de migration fréquentes et comprennent des liens vers des outils, de la documentation d’aide, des blogs et d’autres ressources pour épauler votre travail dans ces domaines.

Migrer du contenu d’une organisation ArcGIS vers une autre

Cette stratégie peut être utile si votre organisation a l’intention de faire ce qui suit :

• Promouvoir le contenu à travers des organisations individuelles, par exemple du développement à un site intermédiaire et à la production.
• Gérez une sélection de contenu dans ArcGIS Enterprise tout en migrant une sélection vers ArcGIS Online ou inversement (par exemple, pour fournir une combinaison d’éléments privés et publics).
• Gérez une sélection de contenu dans un déploiement ArcGIS Enterprise tout en migrant une sélection vers un autre déploiement ArcGIS Enterprise (par exemple, dans des environnements déconnectés).

Migrer un contenu hébergé

Lorsque vous copiez ou migrez des couches hébergées, des cartes Web et des éléments, vous pouvez utiliser des outils et des ressources dans ArcGIS API for Python ou ArcGIS REST API. Il sera plus facile pour vous d’utiliser les outils et les ressources ci-après si vous connaissez déjà ArcGIS API for Python :

• Le guide Cloning Content explique comment utiliser la fonction clone_items() dans les différents environnements. La fonction clone_items() prend en charge les services hébergés, les cartes et les applications Web, ainsi que d’autres types d’élément. Vous devez prendre en compte ce type de stratégie de migration lorsque vous migrez l’intégralité du contenu d’une organisation vers une autre.
• Depuis la version 10.8.1, la fonction arcgis.gis.GroupMigrationManager.create() est disponible pour exporter le contenu de groupe d’une organisation ArcGIS Enterprise sous forme de paquetage. Les administrateurs peuvent utiliser cette fonction pour extraire le contenu du groupe sélectionné et l’importer dans le groupe d’une autre organisation. Cette fonction permet de prendre en charge les couches d’entités hébergées, les cartes et les applications Web, ainsi que d’autres éléments textuels. Les ID d’élément sont conservés pendant la migration. Vous devez prendre en compte ce type de stratégie de migration lorsque vous migrez un sous-ensemble du contenu d’une organisation vers une autre.
• Depuis la version 10.8.1, la fonction arcgis.gis.GroupMigrationManager.load() est disponible pour importer un paquetage exporté vers une organisation ArcGIS Enterprise en tant que contenu de groupe. Une fois importée, la propriété des éléments revient par défaut à l’administrateur qui a importé le paquetage. Les éléments peuvent ensuite être attribués à d’autres propriétaires selon les besoins. Vous devez prendre ce type de stratégie de migration en compte lorsque vous migrez un sous-ensemble du contenu d’une organisation vers une autre.

• Si vous ne connaissez pas ArcGIS API for Python, vous pouvez utiliser les opérations d’exportation et d’importation de contenu de groupe dans ArcGIS REST API pour déplacer le contenu d’une organisation ArcGIS Enterprise vers une autre. Ces opérations sont utiles pour déplacer le contenu d’un environnement de développement vers un environnement intermédiaire ou à travers des environnements déconnectés. Vous devez prendre en compte ce type de stratégie de migration lorsque vous migrez un sous-ensemble du contenu d’une organisation vers une autre.

Migrer un contenu référencé

Lorsque vous migrez un contenu référencé, les services SIG qui référencent des data stores gérés par l’utilisateur doivent être publiés ou partagés dans chaque déploiement de ArcGIS Enterprise. Vous pouvez partager des services référencés comme suit :

• Publiez votre couche Web depuis ArcGIS Pro. Les services publiés depuis ArcGIS Pro référencent la source de données utilisée lors du partage de la couche Web. Cela signifie qu’il peut être nécessaire de créer de nouvelles cartes si vous voulez référencer d’autres sources de données.
• Publiez un fichier de définition de service (.sd) dans ArcGIS Server Manager. Tous les services publiés depuis cette connexion à la base de données référenceront les mêmes données source.
• Procédez à la publication par lots sur le portail ArcGIS Enterprise. Tous les services publiés depuis cette connexion à la base de données référenceront les mêmes données source.

De plus, les services peuvent être automatisés à l’aide du module de partage ArcPy, arcpy.sharing. Envisagez cette stratégie de migration lorsque vous partagez le même service SIG dans plusieurs déploiements ArcGIS Enterprise en une seule opération.

Remarque :

Bien que les scénarios ci-dessus décrivent le déplacement d’éléments d’un environnement à un autre, le partage d’éléments entre organisations est également courant. Dans ce cas, les éléments peuvent être répliqués entre les environnements, par exemple pour livrer et distribuer des éléments publics et privés dans différentes organisations. Pour cette stratégie, vous pouvez utiliser la collaboration distribuée. Bien que la collaboration distribuée puisse être utilisée pour partager du contenu entre plusieurs environnements, elle ne permet pas de migrer du contenu d’un environnement vers un autre.

Migrer un déploiement existant d’une machine vers une autre

Cette stratégie peut être utile si votre organisation doit déplacer des composants logiciels existants vers du matériel ou un système d’exploitation plus récents. Vous pouvez utiliser cette stratégie pour des déploiements sur une ou plusieurs machines hébergées sur site ou dans le cloud. Prenez en compte ces types de stratégie de migration lorsque vous migrez d’un système d’exploitation vers un autre système d’exploitation du même type :

• Pour remplacer une machine dans votre déploiement sans perdre de contenu ou interrompre le service, utilisez l’opération Join Site (Rejoindre le site) et migrez les composants logiciels vers une autre machine. L’opération Join Site (Rejoindre le site) est disponible depuis le répertoire administrateur du portail et le répertoire administrateur du serveur. Des détails supplémentaires sont présentés dans ce blog et comprennent les étapes à suivre pour migrer un ArcGIS Data Store.
• Un processus légèrement plus complexe consiste à se servir de l’utilitaire webgisdr. Vous préférerez peut-être ce processus, car il n’a pas d’incidence sur le travail dans votre environnement de production. Des détails supplémentaires sont présentés dans ce blog.

Migrer un déploiement sur site existant vers un déploiement dans le Cloud

Cette stratégie peut être utile si votre organisation a l’intention de faire ce qui suit :

• Ajouter de nouvelles fonctions.
• Améliorer les performances et les capacités du système.
• Réduire le coût du système.
• Améliorer ou respecter les normes de sécurité.

Pour déterminer si cette stratégie de migration est appropriée pour votre organisation, passez en revue les points suivants :

• Page Enterprise and Cloud Migration : découvrez la migration vers un déploiement dans le cloud.
• Guide ArcGIS Enterprise and Cloud Migration : ce guide propose une approche détaillée qui vous permettra de comprendre les besoins de votre organisation en matière de migration, de les planifier et d’agir en conséquence.
• Blog ArcGIS Enterprise in the cloud : ce blog présente le déploiement dans le cloud.
• AWS CloudFormation et ArcGIS : familiarisez-vous avec les outils de déploiement disponibles pour les déploiements AWS.
• Déployer ArcGIS Enterprise sur Microsoft Azure : familiarisez-vous avec les outils de déploiement dans le cloud disponibles pour les déploiements Microsoft Azure.

Mises à niveau et migration

La mise à niveau du logiciel ArcGIS Enterprise n’est pas une stratégie de migration. Lorsque vous mettez à niveau ArcGIS Enterprise (y compris les composants de déploiement de base, les rôles serveur, etc.), l’objectif est généralement de pouvoir accéder à de nouvelles fonctions, capacités et applications. Par exemple, une organisation qui utilise la version 11.1 peut envisager de la mettre à niveau pour avoir accès aux nouvelles fonctions ou applications disponibles dans la version 11.2. Dans ce cas, le déploiement existant est sauvegardé et la nouvelle version du logiciel est installée en plus du logiciel existant pour le mettre à niveau.

Toutefois, la nécessité de mettre à niveau les logiciels est souvent associée à la mise en œuvre d’une stratégie de migration, comme la migration vers un nouveau système d’exploitation ou depuis un déploiement sur site vers un déploiement dans le cloud.