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 rubrique Méthodes de résolution du nom de l’hôte.
Pour utiliser l’outil WebGISDR pour 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 une autre extrémité
- 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 \etc\hosts sur les nouvelles machines pour résoudre le FQDN de l’URL publique de votre choix vers un autre composant, par exemple une autre instance Web Adaptor ou un proxy inversé. Le fichier \etc\hosts, situé sous C:\Windows\System32\drivers\etc, est utilisé pour résoudre les noms d’hôte en saisissant les adresses IP et en associant l’adresse IP et le nom de l’hôte.
Par exemple, si le nom de la machine est associée à l’adresse IP 10.0.0.1 et qu’elle est résolue vers enterprise.domain.com par le DNS, vous pouvez ajouter une entrée au fichier \etc\hosts sur la machine pour résoudre l’adresse IP de la machine vers un autre nom d’hôte, 10.0.0.1 alias.domain.com.
Si vous interrogez alias.domain.com dans une invite de commande, le fichier \etc\hosts résout alias.domain.com vers 10.0.0.1, qui est enterprise.domain.com. En cas d’exécution d’un serveur web sur la machine, il est possible de l’atteindre via alias.domain.com ou enterprise.domain.com.
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 ArcGIS Web Adaptor, inscrivez l’instance Web Adaptor 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.
Vous avez un commentaire à formuler concernant cette rubrique ?