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 determinados requisitos.
- 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.
- 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ónasegú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.
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 un equipo adicional. 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.
La utilidad webgisdr registra las versiones de software de los componentes de ArcGIS Enterprise cuando crea una 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.
Duplicar implementaciones
Dentro de ArcGIS Enterprise, hay varias dependencias que debe tener en cuenta y que están relacionadas con la accesibilidad. Los servicios de mapa se basan en los datos de una carpeta compartida o se accede a ellos mediante una conexión de base de datos. Los equipos de ArcGIS Enterprise se comunican entre sí mediante direcciones URL específicas. Por estos motivos, una implementación de ArcGIS Enterprise de un sitio se debe duplicar en otro para que cada componente incluido en la implementación de cada centro de datos sea el mismo (por ejemplo, las ubicaciones de la carpeta, los nombres de la base de datos y las direcciones URL). Los dispositivos de almacenamiento conectado a la red (NAS) que almacenan geodatabases de archivos o los archivos de configuración de Portal for ArcGIS y ArcGIS Server se deben llamar igual para que la implementación en espera pueda conectarse a los recursos correctamente. Todos los componentes de ArcGIS Enterprise se deben instalar en los mismos directorios dentro de cada implementación. Finalmente, la cantidad de equipos debe ser idéntica entre los centros de datos, dado que podrían producirse problemas de rendimiento si hubiera menos equipos disponibles para responder a la carga del usuario. Recuerde que puede utilizar entradas de DNS o modificar los hosts files on the machines to achieve host name consistency.
Replicar ArcGIS Enterprise
Portal for ArcGIS incluye la herramienta webgisdr, que le 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 en espera para restaurarlo. La herramienta 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.
Tenga en cuenta que la herramienta 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, por ejemplo, los datos de una base de datos o de una geodatabase de archivos. Es responsabilidad de la organización replicar esos datos en la implementación en espera de ArcGIS Enterprise y asegurarse de que los servicios en espera 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 herramienta webgisdr como una tarea programada en el Programador de tareas de Windows o como un trabajo de cron en un entorno de Linux. Además, la herramienta 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 herramienta 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. Use Python (o el lenguaje de secuencia de comandos que prefiera) con la API REST de ArcGIS Server y Portal for ArcGIS para automatizar la supervisión de partes de su implementación como las que se indican a continuación:
- Consultar los registros de Portal for ArcGIS y ArcGIS Server periódicamente para comprobar si hay mensajes que indiquen un fallo de un determinado componente. Si se produce un fallo, se puede escribir una secuencia de comandos para que envíe correos electrónicos o notifique a los administradores que deben prestar atención.
- Usar las funciones de verificación de estado en las API de administración de Portal for ArcGIS y ArcGIS Server para consultar los registros y comprobar si hay problemas.
- Validar todos los servidores federados para garantizar que están funcionando y que el portal puede acceder a ellos.
- Validar las conexiones a todos los data stores. Esto incluye las conexiones a big data stores relacionales, de caché de teselas y espaciotemporales, así como a carpetas y bases de datos registradas, archivos compartidos de Big Data y el data store de ráster.
- Consultar periódicamente servicios y mapas web importantes para asegurarse de que funcionan.
- Consultar Indexer Status en el equipo principal antes de la replicación para asegurarse de que todo lo que hay en el portal está indexado en el principal. Consultar Indexer Status en ambos equipos una vez que se haya completado la replicación para confirmar que coinciden los valores de índice entre la implementación en espera y la principal. Los valores de databaseCount y indexCount para cada name deben ser los mismos dentro y entre las dos implementaciones. Por ejemplo, cuando consulta Indexer Status, se muestran cuántos elementos hay en la base de datos en comparación con el número de elementos que están indexados. Lo que hay en la base de datos (databaseCount) debe coincidir con lo que está indexado (indexCount) para cada tipo de elemento (name), como se muestra en el ejemplo siguiente. Si databaseCount y indexCount no coinciden en un tipo de elemento, es necesario que vuelva a indexar el portal. Esta salida debe ser igual tanto en el equipo principal como en el equipo en espera.
{"indexes": [ { "name": "users", "databaseCount": 42, "indexCount": 42 }, { "name": "groups", "databaseCount": 21, "indexCount": 21 }, { "name": "search", "databaseCount": 8499, "indexCount": 8499 } ]}
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.
Conmutación por error
Dentro de 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 host 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 desde la implementación de ArcGIS Enterprise en espera e importarla en la implementación principal. La herramienta replicará el contenido en el portal, incluidos los datos de las capas de escenas y de entidades alojadas asociadas y los nuevos servicios no alojados registrados con el portal en la implementación principal de ArcGIS Enterprise.