Puede replicar su implementación de ArcGIS Enterprise en una implementación en espera desconectada. Si su implementación principal falla o deja de estar accesible, puede conmutar por error a la implementación en espera.
Normalmente, las implementaciones en espera se ejecutan en una red o subred diferente, o incluso en una ubicación separada geográficamente de su implementación principal. Independientemente de dónde coloque la implementación en espera, asegúrese de que sus clientes de ArcGIS Enterprise puedan acceder a ella cuando lo necesiten.
Redundancia geográfica
Puede implementar la redundancia geográfica si su centro de datos principal y en espera se encuentran en ubicaciones separadas geográficamente. Si en uno de los centros de datos se produce un evento catastrófico, como un huracán u otro desastre natural, puede activar el centro de datos en espera para reanudar las operaciones.
Para que la redundancia geográfica se desarrolle correctamente existen los siguientes requisitos específicos:
- Los entornos principal y en espera deben estar duplicados. Cada centro de datos debe tener el mismo número de equipos en la implementación de ArcGIS Enterprise y las direcciones URL usadas para acceder a los componentes deben ser las mismas.
- Los directorios de ArcGIS Server deben tener el mismo nombre. Las rutas del directorio pueden ser diferentes, pero el nombre de la carpeta debe ser el mismo en los entornos principal y de respaldo.
- Las carpetas registradas en los sitios de ArcGIS Server de los entornos principal y de respaldo pueden tener rutas diferentes, pero los nombres de carpeta deben ser iguales, además de contener copias exactas de los mismos datos de origen.
- Normalmente, la redundancia geográfica sigue un enfoque activo-pasivo; por lo tanto, los datos y el contenido se deben replicar en la implementación de ArcGIS Enterprise en espera de forma coherente.
- Para que la redundancia geográfica se desarrolle correctamente, se basa en componentes externos. Por ejemplo, es importante contar con un selector de sitios globales o con un servidor de sistema de nombres de dominio (DNS) para que cuando se deba pasar del centro de datos principal al de espera, no se alteren las tareas de los usuarios de ArcGIS Enterprise.
Para garantizar el menor tiempo posible de inactividad en caso de fallo o de catástrofe, podría realizar una implementación de ArcGIS Enterprise de alta disponibilidad y geográficamente redundante. Esta es la implementación más compleja de lograr, dado que requiere la mayor cantidad de equipos y de mantenimiento. Configure dos centros de datos separados, cada uno con su propia implementación de ArcGIS Enterprise de alta disponibilidad. En cada centro de datos, los nombres de todos los equipos están configurados de forma idéntica y no existen puntos de fallo únicos. Aquí se incluyen los datos, tanto si se encuentran en un servidor de archivos o en una base de datos de alta disponibilidad, todos los servidores web y equilibradores de carga, así como los componentes de ArcGIS Enterprise. Las copias de seguridad de la implementación principal se crean coherentemente y la restauración en la implementación en espera en el centro de datos separado puede producirse de forma inmediata o cuando se produzca un fallo en la implementación principal.
Planificar una implementación replicada
En primer lugar, determine cuántos equipos necesita. A continuación, haga su planificación según estos requisitos sobre la recuperación en caso de desastres para una implementación de ArcGIS Enterprise replicada:
- Duplicación: asegúrese de que los dos centros de datos e implementaciones de ArcGIS Enterprise contienen la misma arquitectura.
- Replicación: realice una copia de seguridad del contenido y los datos del centro de datos principal y restáurelos en el de espera.
- Supervisión: revise los registros para determinar cuándo se produce un fallo y determine la gravedad del fallo que le obliga a conmutar por error al centro de datos en espera.
- Conmutación por error: decida si va a conmutar por error a otro componente dentro de ArcGIS Enterprise o si va a conmutar por error toda la implementación de ArcGIS Enterprise en otro centro de datos.
Tenga en cuenta también lo siguiente al planificar su implementación replicada:
- La utilidad webgisdr no mueve las teselas de la caché del servicio de mapas. Si incluye las cachés de servicios de mapas o de capas de teselas alojadas utilizadas por el sitio de GIS Server en su implementación, haga una copia de seguridad de todos los directorios donde se almacenen las teselas de caché (por ejemplo, el directorio arcgiscache completo de C:\arcgisserver\directories\ o <ArcGIS Server installation directory>/arcgis/server/usr/directories). Coloque manualmente las copias en el directorio arcgiscache correspondiente o en la implementación en espera.
- No se admite el uso de varios clústeres de ArcGIS Server al usar la utilidad webgisdr para replicar ArcGIS Enterprise en una implementación de espera desconectada.
- Todos los equipos de ambas implementaciones deben utilizar el mismo sistema operativo. Por ejemplo, no es posible que la implementación principal se realice en equipos Windows y la implementación en espera en equipos Linux.
- La utilidad webgisdr registra las versiones de software de los componentes de ArcGIS Enterprise cuando crea un archivo de copia de seguridad. La implementación en espera en la que importa el archivo debe estar en la misma versión que la implementación principal.
Determinar los requisitos de los equipos
La cantidad de equipos que necesita depende de cómo configure ArcGIS Enterprise. Necesita dos equipos como mínimo. Si su implementación de ArcGIS Enterprise no almacena una gran cantidad de datos y servicios, no incluye un big data store espaciotemporal y no acceden a ella muchas personas, puede configurar una implementación principal compuesta por un sitio de GIS Server de un solo equipo e instalar Portal for ArcGIS y ArcGIS Data Store en el mismo equipo. Necesita un segundo equipo para almacenar la implementación en espera replicada.
Si su implementación de ArcGIS Enterprise tiene un uso más intensivo, por ejemplo, si muchas personas acceden a ella, si su organización almacena una gran cantidad de elementos o si su implementación se ha editado mucho, puede que necesite un sitio de GIS Server con uno o varios equipos y deberá instalar Portal for ArcGIS y ArcGIS Data Store en equipos separados entre sí y separados de los equipos de GIS Server. Si publica varias capas de escenas alojadas, puede que desee configurar ArcGIS Data Store (data store de caché de teselas) para almacenar las bases de datos de la caché de escenas en otro equipo. Si va a usar un big data store espaciotemporal, necesitará al menos otro equipo. En este caso, calcule el número de equipos necesario utilizando la siguiente fórmula:
(<number of GIS Server machines> + 1 Portal for ArcGIS machine + <number of machines in the data store>) X 2
Tenga en cuenta que no se necesitan licencias de ArcGIS adicionales para la implementación en espera, dado que no se accede de forma activa, sino que solo se activa en caso de que falle el sistema principal.
Configuración necesaria para implementaciones duplicadas
Para que una implementación replicada de ArcGIS Enterprise garantice una recuperación eficaz en caso de desastre, la implementación de respaldo debe duplicar la totalidad de los ajustes del sistema, configuraciones de seguridad y ubicaciones de almacenamiento empleados en la implementación principal. Crear copias de seguridad de forma periódica y garantizar la uniformidad entre las implementaciones replicadas son las mejores formas de minimizar las paradas en caso de avería. Se trata de consideraciones que deben hacerse en toda la implementación. Algunos ejemplos son los siguientes:
- Los servicios de mapa se basan en los datos de una carpeta compartida o usan una conexión de base de datos.
- Los equipos de una implementación de ArcGIS Enterprise se comunican entre sí mediante direcciones URL específicas.
Sugerencia:
Utilice entradas de DNS o modifique los archivos de hosts de su implementación replicada para mantener la coherencia en los nombres de host.
- Las ubicaciones de los directorios de instalación deben ser idénticas entre dos implementaciones replicadas.
- El número de equipos de sus centros de datos debe coincidir, para así evitar problemas de rendimiento ante la carga de los usuarios.
Los siguientes ajustes del sistema y de seguridad no se deben replicar de una implementación a otra, dado que son específicos de cada implementación:
- Información de proxy de reenvío, incluidos los nombres de los servidores, las URL de cara a los usuarios y los números de puerto
- Ajustes de seguridad, incluida la lista de direcciones aprobadas por la capacidad de proxy del portal
- Propiedades de configuración de almacenes de identidades para almacenamiento de usuarios y grupos, si corresponde
- Ajustes de proveedores de identidad SAML y LDAP
A partir de la versión 10.4, se ha acortado la lista de elementos y ajustes que deben ser idénticos en sus implementaciones de origen y destino al ejecutar la utilidad webgisdr. La siguiente tabla resume estos cambios en las versiones recientes de Portal for ArcGIS y ArcGIS Server:
¿Debe este elemento o ajuste ser idéntico en todas las implementaciones al ejecutar la utilidad webgisdr?
| Elemento o ajuste | 10.4.x | 10.5.x, 10.6 | 10.6.1, 10.7 |
|---|---|---|---|
URL públicas del portal | Sí | Sí | Sí |
URL de servicios de servidores federados | Sí | Sí | Sí |
Data stores registrados distintos de ArcGIS Data Store | Sí | Sí | Sí |
Rutas de directorio de ArcGIS Server (por ejemplo, arcgisjobs) | Sí | Sí | No |
Información de seguridad (URL de LDAP, información de proxy) | Sí | Sí | No |
Tipo de implementación (un solo equipo o alta disponibilidad) | Sí | No | No |
URL privada del portal | Sí | No | No |
URL de administrador de servidores federados | Sí | No | No |
Nombres de equipo | Sí | No | No |
Directorio de contenido del portal | No | No | No |
Almacén de configuración de ArcGIS Server | No | No | No |
Replicar ArcGIS Enterprise
La utilidad webgisdr permite exportar contenido del portal, sitios de ArcGIS Server federados y contenido de data store relacional y de caché de teselas de ArcGIS Data Store a un archivo que puede mover al equipo de respaldo para restaurarlo. La utilidad mantiene la configuración definida para Portal for ArcGIS, ArcGIS Server y ArcGIS Data Store y copia todo el contenido creado en el portal, así como los datos que se han copiado en el servidor de alojamiento y en el data store durante la publicación.
La utilidad no copia datos de bases de datos ni de carpetas que estén registradas con el servidor de alojamiento o con sitios de ArcGIS Server federados. Es responsabilidad del administrador replicar esos datos en la implementación en espera de ArcGIS Enterprise y asegurarse de que los servicios del equipo de respaldo pueden acceder a los datos replicados.
Al registrar fuentes de datos con sitios de ArcGIS Server, proporciona información específica sobre cómo acceder a los datos. Esa información debe ser la misma para la implementación en espera y para la implementación principal. Por ejemplo, si copia geodatabases de archivos usadas como datos de origen para la implementación en espera, las rutas del directorio a las geodabases de archivos deben ser las mismas que en la implementación principal. Asimismo, la implementación en espera debe poder acceder a una base de datos usando la misma información de conexión que proporcionó al registrar la base de datos con el sitio de ArcGIS Server en la implementación principal.
Puede ejecutar la utilidad webgisdr como un trabajo de cron en un entorno de Linux. Además, la utilidad se puede mover y ejecutar desde un equipo distinto a la instalación del portal, siempre que la comunicación esté abierta entre el equipo donde se ejecuta la utilidad y los componentes de ArcGIS Enterprise.
Debe restaurar las copias de seguridad de ArcGIS Enterprise en la implementación en espera tan pronto como se hayan exportado desde la implementación principal. De esta forma se evita restaurar las copias de seguridad incrementales en el orden incorrecto, lo que significa que se producirá una pérdida de datos o un tiempo de inactividad mínimos en caso de que falle la implementación principal. Si no va a restaurar las copias de seguridad de forma inmediata, puede producirse una sobrecarga a la hora de importar la copia de seguridad y de realizar la conmutación por error a la implementación en espera.
También debe tener en cuenta que si hay algo incorrecto en la implementación principal al crear la copia de seguridad y existen procesos automáticos que importan la copia de seguridad en el sistema en espera, estas configuraciones incorrectas también se importarán en la implementación en espera.
Consulte Configurar recuperación ante desastres para obtener instrucciones sobre cómo replicar una implementación de ArcGIS Enterprise.
Supervisar ArcGIS Enterprise
La supervisión es importante tanto en un entorno replicado como de alta disponibilidad. En un entorno de alta disponibilidad, hay determinadas partes de la implementación que se conmutan por error sin intervención del usuario. Por ejemplo, si el portal principal de ArcGIS Enterprise falla, el software se conmuta por error inmediatamente al sistema en espera sin intervención por parte del usuario. De forma parecida, los componentes de ArcGIS Server y ArcGIS Data Store pueden fallar y el sistema puede seguir funcionando de la forma habitual porque no hay puntos únicos de fallo. Teniendo en cuenta que puede haber interrupciones no visibles en ArcGIS Enterprise, debe implementar mecanismos para notificar a los administradores los fallos que puedan producirse en cualquier componente de la implementación deArcGIS Enterprise.
Puede utilizar ArcGIS Monitor para analizar el estado de los componentes de Portal for ArcGIS, ArcGIS Server y ArcGIS Data Store relacional de su implementación. También puede utilizar la tarea Índice de portal para consultar el estado del indexador en el equipo principal del portal antes de replicar su implementación. Si utiliza una base de datos de PostgreSQL, Oracle o Microsoft SQL Server con su implementación, puede utilizar una de las tareas Egdb disponibles en la galería de ArcGIS Monitor para supervisar las estadísticas para dichas bases de datos.
Deberá utilizar Python o el lenguaje de script de su elección con la API REST de ArcGIS Server para automatizar la validación de conexiones a carpetas registradas, recursos compartidos de archivos de big data, data stores ráster, cachés de teselas y big data stores espaciotemporales.
En un entorno replicado, la conmutación por error requiere la intervención del usuario; por lo tanto, debe supervisar su implementación para determinar cuándo se producen los fallos y decidir si es necesaria una conmutación por error.
Si automatiza la replicación de su implementación principal en la implementación en espera, también tendrá que supervisar estos procesos para asegurarse de que las copias de seguridad, el movimiento de los archivos y las operaciones de restauración se completan correctamente.
Acerca de la conmutación por error
ArcGIS Enterprise, Portal for ArcGIS, ArcGIS Server y ArcGIS Data Store tienen sus propios mecanismos internos de conmutación por error. En un entorno de alta disponibilidad, cada componente puede conmutarse por error sin alterar de forma significativa la implementación general de ArcGIS Enterprise.
En la conmutación por error de una implementación replicada desde el centro de datos principal al de espera normalmente interviene el departamento de TI de la organización y se puede conseguir mediante un selector de sitios globales (GSS) o un DNS global. Los miembros de una organización normalmente acceden a su implementación de ArcGIS Enterprise a través de unas cuantas direcciones URL, por ejemplo, https://myportalwa.organization.com/portal para la URL del portal y https://myserverwa.organization.com/server para la URL de los servicios de ArcGIS Server. El GSS o GNS global puede asignar una dirección IP a cada nombre de host. Si necesita realizar una conmutación por error a otro centro de datos, el GSS o DNS global volverá a asignar los nombres de host myportalwa.organization.com y myserverwa.organization.com a las direcciones IP asociadas al centro de datos en espera. Esto no afectará a los clientes ni a los usuarios, pero todas las solicitudes se enviarán al centro de datos en espera. Una vez que el centro de datos principal vuelva a estar activo, la dirección IP de los host del sitio principal se pueden reasignar a direcciones IP dentro del centro de datos original. En este momento debería conciliar los datos del sistema en espera con el principal para asegurarse de que el centro de datos principal contiene todo el contenido nuevo y los datos que se crearon cuando el sistema en espera estaba activo.
En el caso de que se hubiera editado alguna de las bases de datos registradas del servidor de alojamiento o del sitio de ArcGIS Server federado (geodatabase o base de datos corporativa), utilice las herramientas de replicación de bases de datos para asegurarse de que la implementación principal de ArcGIS Enterprise contiene esos datos actualizados. Si los datos de fuentes de datos basadas en archivos como, por ejemplo, geodatabases de archivos, que están registrados en cualquiera de los sitios de ArcGIS Server en la implementación de ArcGIS Enterprise han cambiado, copie los archivos editados en el directorio original donde se guardaron. Finalmente, use la utilidad webgisdr para exportar una copia de seguridad de ArcGIS Enterprise desde la implementación en espera e importarla en la implementación principal. La utilidad replicará en la implementación principal de ArcGIS Enterprise original el contenido del portal, incluidos los datos de las capas de escenas y de entidades alojadas asociadas y los nuevos servicios registrados con el portal.