Es posible que las organizaciones quieran migrar una organización ArcGIS Enterprise de 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
Puede aprovechar el archivo \etc\hosts de los equipos nuevos para vincular el FQDN de la URL pública deseada a un componente diferente, como otro Web Adaptor o proxy inverso. El archivo \etc\hosts se utiliza para resolver nombres de host mediante la introducción de direcciones IP y la asociación de la dirección IP a nombres de host.
Por ejemplo, si el nombre del equipo tiene una dirección IP de 10.0.0.1 y se vincula a enterprise.domain.com por medio del DNS, puede agregar una entrada al archivo \etc\hosts del equipo para vincular la IP del equipo a un nombre de host diferente, 10.0.0.1 alias.domain.com.
Si hace ping a alias.domain.com en una ventana de comandos, el archivo \etc\hosts vincula alias.domain.com a 10.0.0.1, que es enterprise.domain.com. Si un servidor web se está ejecutando en el equipo, se puede acceder a él por medio de alias.domain.com o enterprise.domain.com.
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:
- Redirija el tráfico al entorno de no producción.
- Si está usando ArcGIS Web Adaptor, registre Web Adaptor 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.
- 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.
- Configure el servidor federado como servidor de alojamiento en el portal de destino.
- 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.
