Migrar ArcGIS Enterprise con WebGISDR

Es posible que las organizaciones quieran migrar una organización de ArcGIS Enterprise existente de un equipo (o conjunto de equipos) a otro. Uno de los motivos para hacer esto es migrar a un hardware o sistema operativo más reciente. Existen unos cuantos métodos comunes para hacer este tipo de migración, incluidos los siguientes:

• La operación Unirse a un sitio

• La herramienta de recuperación ante desastres SIG web (WebGISDR)

La herramienta WebGISDR suele utilizarse porque no afecta al trabajo en su entorno de producción. Aunque los pasos de este método probablemente tarden más en realizarse que los del método Unirse a un sitio, se considera que este método es más seguro.

Examine detenidamente las consideraciones siguientes y las estrategias de migración para asegurarse de elegir el método que más se adecue a su implementación.

Consideraciones de uso de la herramienta WebGISDR

Antes de tomar la decisión de migrar con la herramienta WebGISDR, es importante asegurarse de que es el mejor método en el caso de su organización. Revise detenidamente lo siguiente:

• Los administradores pueden migrar los equipos existentes a otros nuevos sin hacer cambios en su entorno de producción.

• El éxito de una migración puede constatarse antes de cambiar al entorno nuevo.

• La herramienta permite moverse entre cualquier combinación de implementaciones de un equipo y altamente disponibles.

• Este método de migración no puede utilizarse para migrar a un sistema operativo diferente.

• El entorno original y el nuevo deben satisfacer los requisitos preliminares para ejecutar la herramienta WebGISDR. La URL de la organización y las URL de los servicios deben ser idénticas en los diferentes entornos, lo que se aborda en los métodos de resolución de nombre de host.

Para utilizar la herramienta WebGISDR para migrar su organización, primero determine su flujo de trabajo. Los pasos dependerán de los tipos de implementación actual y deseado y las necesidades de la organización. El método elegido de resolución de nombre de host afectará a su flujo de trabajo, por lo que debe asegurarse de revisar cada método antes de empezar.

Métodos de resolución de nombre de host

Para configurar un segundo entorno, los componentes del nuevo entorno deben configurarse con las mismas URL públicas como entorno principal. Existen una cuantas maneras de hacerlo:

• Utilizar una entrada \etc\hosts para vincular el nombre de dominio completo (FQDN) de las URL públicas a un extremo diferente

• Redirigir el tráfico hasta que el software se configure

• Configurar el DNS para que los equipos en espera vinculen la URL pública a una dirección IP diferentes de los equipos principales

Los flujos de trabajo incluidos para migrar equipos seguirán la primera opción, que consiste en utilizar el archivo \etc\hosts. Consulte las secciones siguientes para obtener más información sobre cada método.

Opción 1: Modificar el archivo \etc\hosts

Es posible utilizar el archivo \etc\hosts regional en los nuevos equipos para controlar cómo se resuelven las URL públicas durante la migración. Esto permite que el nombre de dominio totalmente calificado (FQDN) de la URL pública se resuelva en un extremo diferente, como un nuevo adaptador web o proxy inverso, sin actualizar el DNS.

El archivo \etc\hosts resuelve nombres de host mediante la representación cartográfica de direcciones IP a nombres de host. Las entradas de este archivo tienen prioridad sobre las DNS y se aplican solo al equipo en el que están configuradas.

El archivo \etc\hosts se encuentra en C:\Windows\System32\drivers\etc.

Por ejemplo, se accede al entorno primario utilizando la URL pública enterprise.example.com, que se resuelve a través de DNS. En los equipos nuevos, es posible agregar una entrada al archivo \etc\hosts que asigne la dirección IP del nuevo entorno a un nombre de host alternativo, como enterprise1.example.com.

Cuando se accede aenterprise1.example.com, el archivo \etc\hosts resuelve el nombre de host localmente a la dirección IP del nuevo entorno. Si un servidor web se está ejecutando en el equipo, se puede acceder a él a través de enterprise1.example.com, mientras enterprise.example.com continúa resolviendo al entorno primario a través de DNS.

Opción 2: Redirigir el tráfico hasta que el software se configure

Si puede redirigir el trabajo fuera del entorno de producción durante un breve intervalo de tiempo, configure el componente que está redirigiendo el tráfico a su entorno de producción para enviar el tráfico a su entorno que no es de producción.

Esto puede suponer la necesidad de volver a registrar Web Adaptor en los equipos nuevos o actualizar su proxy inverso o su equilibrador de carga para enviar el tráfico a equipos nuevos del entorno que no es de producción. Esto solo tiene que hacerse cuando se esté preparado para federar y configurar el servidor como servidor de alojamiento.

Podría considerarse que este método es el más sencillo, pero puede plantear problemas en el caso de las organizaciones que no pueden hacer cambios en su entorno de producción con facilidad.

Para seguir este flujo de trabajo, debe haber aprovisionado los equipos nuevos con el entorno de no producción, además de haber instalado y configurado Portal for ArcGIS, ArcGIS Server y ArcGIS Data Store. Tras registrar ArcGIS Data Store en el sitio del servidor, puede realizar los siguientes pasos:

1. Redirija el tráfico al entorno de no producción.

   • Si está usando ArcGIS Web Adaptor, regístrelo en los equipos nuevos.

   • Si está usando un proxy inverso o un equilibrador de carga, actualice la configuración para enviar el tráfico a los equipos nuevos.

2. Federe el portal y los sitios del servidor en el entorno de no producción utilizando la misma URL pública para la URL de los servicios que en el entorno de producción.

   La dirección URL de administración utilizada durante la federación debe ser una URL que solo se vincula a equipos de no producción. La URL de administración también se puede actualizar después de la migración sin interrumpir el servicio.

3. Configure el servidor federado como servidor de alojamiento en el portal de destino.

4. Redirija el tráfico otra vez al entorno de producción.

   • Si está usando Web Adaptor, regístrelo en los equipos originales.

   • Si está usando un proxy inverso o un equilibrador de carga, actualice la configuración para enviar el tráfico a los equipos originales.

   

Opción 3: Configurar el DNS para que los equipos en espera vinculen la URL de la organización a una dirección IP diferentes de los equipos principales

Como alternativa, puede configurar el DNS del entorno en espera para resolver el FQDN de las URL públicas de forma diferente dependiendo de si está en los equipos principales o los equipos en espera. Esto se denomina comúnmente como DNS dividido o DNS de horizonte dividido. Este método requiere un Web Adaptor, un proxy inverso o un equilibrador de carga adicional debido a que la URL pública debe estar accesible para federar el portal y el sitio del servidor.

Este método es funcionalmente equivalente a la modificación de los archivos \etc\hosts, pero que se gestionan a través del DNS en lugar de un archivo \etc\hosts.