Effectuer une migration ArcGIS Enterprise avec WebGISDR

Les organisations peuvent vouloir migrer une organisation ArcGIS Enterprise existante d’une machine (ou d’un ensemble de machines) vers une autre. Il se peut par exemple qu’une organisation veuille migrer vers du matériel ou un système d’exploitation plus récent. Certaines méthodes sont couramment utilisées pour effectuer ce type de migration, parmi lesquelles :

L’opération Join Site (Se joindre au site)
L’outil de récupération d’urgence du SIG web (WebGISDR)

L’outil WebGISDR est fréquemment utilisé, car il n’a pas d’incidence sur le travail dans votre environnement de production. Bien que les étapes de cette méthode prennent généralement plus de temps que l’approche Join Site (Se joindre au site), elle est considérée comme étant plus sûre.

Étudiez minutieusement les points suivants et consultez la rubrique Stratégies de migration pour vous assurer que vous choisissez la méthode la plus adaptée à votre déploiement.

Éléments à prendre en compte pour l’utilisation de l’outil WebGISDR

Avant de décider d’effectuer une migration à l’aide de l’outil WebGISDR, il est important de vous assurer qu’il s’agit de la méthode la plus adaptée pour votre organisation. Étudiez soigneusement les informations suivantes :

Les administrateurs peuvent effectuer la migration de machines existantes vers de nouvelles machines sans apporter de modification à leur environnement de production.
Vous pouvez valider la réussite d’une migration avant de passer à un nouvel environnement.
L’outil prend en charge le déplacement entre n’importe quelle machine individuelle et les déploiements hautement disponibles.
Cette méthode de migration ne peut pas être utilisée pour effectuer une migration vers un autre système d’exploitation.
Votre environnement d’origine et votre nouvel environnement doivent respecter les conditions préalables de l’exécution de l’outil WebGISDR. L’URL de l’organisation et les URL des services doivent être identiques dans les deux environnements. Reportez-vous à la section Méthodes de résolution du nom de l’hôte.

Pour utiliser l’outil WebGISDR afin d’effectuer la migration de votre organisation, déterminez d’abord votre processus. Les étapes dépendront de vos types de déploiement actuel et souhaité, ainsi que des besoins de votre organisation. La méthode de résolution du nom de l’hôte que vous choisissez aura un impact sur votre processus. Assurez-vous de bien étudier toutes les méthodes avant de commencer.

Méthodes de résolution du nom de l’hôte

Pour configurer un second environnement, les composants du nouvel environnement doivent être configurés avec les mêmes URL publiques que l’environnement principal. Plusieurs méthodes sont possibles :

Utiliser une entrée \etc\hosts pour résoudre le nom de domaine complet (FQDN) des URL publiques vers un autre point de terminaison
Rediriger le trafic jusqu’à ce que le logiciel soit configuré
Configurer votre DNS de sorte que les machines de secours résolvent l’URL publique vers une adresse IP différente des machines principales

Les processus inclus pour la migration des machines suivront la première option, c’est-à-dire l’utilisation du fichier \etc\hosts. Reportez-vous aux sections ci-après pour en savoir plus sur chaque méthode.

Option 1 : modifier le fichier \etc\hosts

Vous pouvez utiliser le fichier local \etc\hosts sur les nouvelles machines pour contrôler le mode de résolution des URL publiques lors de la migration. Cela permet de résoudre le nom de domaine complet (FQDN) de l’URL publique vers un autre point de terminaison, tel qu’un nouveau composant Web Adaptor ou un proxy inverse, sans mettre à jour le DNS.

Le fichier \etc\hosts résout les noms d’hôte en associant les adresses IP aux noms d’hôte. Les entrées de ce fichier ont priorité sur le DNS et ne s’appliquent qu’à la machine sur laquelle elles sont configurées.

Le fichier \etc\hosts se trouve dans C:\Windows\System32\drivers\etc.

$Résoudre les noms d’hôte avec le fichier \etc\hosts$

Par exemple, l’environnement principal est accessible via l’URL publique enterprise.example.com, laquelle est résolue via le DNS. Sur les nouvelles machines, vous pouvez ajouter une entrée au fichier \etc\hosts qui associe l’adresse IP du nouvel environnement à un autre nom d’hôte, comme enterprise1.example.com.

Lors de l’accès à enterprise1.example.com, le fichier \etc\hosts résout localement le nom d’hôte vers l’adresse IP du nouvel environnement. En cas d’exécution d’un serveur Web sur la machine, il est possible de l’atteindre via enterprise1.example.com, pendant que enterprise.example.com continue la résolution vers l’environnement principal via le DNS.

Option 2 : rediriger le trafic jusqu’à ce que le logiciel soit configuré

Si vous ne parvenez pas à rediriger le trafic hors de votre environnement de production pendant une courte période, configurez le composant qui redirige le trafic vers votre environnement de production de sorte qu’il envoie le trafic vers votre environnement hors production.

Pour cela, vous devrez peut-être réinscrire l’instance Web Adaptor auprès des nouvelles machines ou mettre à jour votre proxy inversé ou l’équilibreur de charges de sorte à envoyer le trafic vers les nouvelles machines dans l’environnement hors production. Vous devez effectuer cette action uniquement lorsque vous êtes prêt à fédérer le serveur et à le définir comme serveur d’hébergement.

Cette approche peut être considérée comme étant la plus simple, mais elle peut être à l’origine de problèmes pour les organisations qui ne peuvent pas facilement apporter des modifications à leur environnement de production.

Pour suivre ce processus, vous devez avoir approvisionné vos nouvelles machines avec l’environnement hors production, et installé et configuré Portal for ArcGIS, ArcGIS Server et ArcGIS Data Store. Une fois ArcGIS Data Store inscrit auprès du site de serveur, vous pouvez effectuer les actions suivantes :

Redirigez le trafic vers l’environnement hors production.
- Si vous utilisez l’instance ArcGIS Web Adaptor, inscrivez-la auprès des nouvelles machines.
- Si vous utilisez un proxy inversé ou un équilibreur de charge, mettez à jour la configuration pour envoyer le trafic vers les nouvelles machines.
Fédérez le portail et les sites de serveur dans l’environnement hors production en utilisant la même URL publique pour l’URL des services que dans l’environnement de production.

L’URL d’administration utilisée pendant l’opération de fédération doit être une URL qui effectue la résolution uniquement vers les machines hors production. L’URL d’administration peut également être mise à jour après la migration, sans interruption de service.
Définissez le serveur fédéré comme serveur d’hébergement sur le portail cible.
Redirigez le trafic vers l’environnement de production.
- Si vous utilisez l’instance Web Adaptor, inscrivez-la auprès des machines d’origine.
- Si vous utilisez un proxy inversé ou un équilibreur de charge, mettez à jour la configuration pour envoyer le trafic vers les machines d’origine.

Option 3 : configurer votre DNS de sorte que les machines de secours résolvent l’URL de l’organisation vers une adresse IP différente des machines principales

Vous pouvez également configurer le DNS de l’environnement de secours de sorte qu’il résolve le FQDN des URL publiques différemment selon si vous utilisez les machines principales ou les machines de secours. Ce type de DNS est souvent appelé DNS partagé ou DNS à horizon partagé. Une autre instance Web Adaptor, un autre proxy inversé ou un autre équilibreur de charge est requis pour cette méthode, car l’URL publique doit être accessible pour fédérer le portail et le site du serveur.

D’un point de vue fonctionnel, cette approche est équivalente à la modification des fichiers \etc\hosts, mais la gestion se fait via un DNS et non via un fichier \etc\hosts.