Puede replicar su SIG web a 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 SIG web 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 el SIG web y los nombres de host del equipo deben ser iguales.
- Normalmente, la redundancia geográfica sigue un enfoque activo-pasivo; por lo tanto, los datos y el contenido se deben replicar al SIG web 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 altere las tareas de los usuarios de SIG web.
Para garantizar el menor tiempo posible de inactividad en caso de fallo o de catástrofe, podría implementar un SIG web redundante geográficamente de alta disponibilidad. 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 SIG web 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 SIG web. Las copias de seguridad del SIG web principal se crean coherentemente y la restauración al SIG web en espera en el centro de datos separado puede producirse de forma inmediata o cuando se produzca un fallo en el SIG web principal.
Planificar una implementación replicada
En primer lugar, debe determinar cuántos equipos necesita. A continuación, haga su planificación según estos requisitos sobre la recuperación en caso de desastres para un SIG web replicado:
- Duplicación: asegúrese de que los dos centros de datos e implementaciones de SIG web 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 SIG web o si va a conmutar por error todo el SIG web a otro centro de datos.
Determinar los requisitos de los equipos
La cantidad de equipos que necesita depende de cómo configure su SIG web. Necesita dos equipos como mínimo. Si su SIG web no almacena muchos datos y servicios y no acceden a él demasiadas personas, puede configurar una implementación principal formada por un sitio de ArcGIS Server con 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 SIG web tiene un uso más intensivo, por ejemplo, si muchas personas acceden a él, 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 ArcGIS Server con uno o varios equipos y deberá instalar Portal for ArcGIS y ArcGIS Data Store en equipos separados entre sí y de ArcGIS Server. Si publica varias capas de escena alojadas, puede que desee configurar ArcGIS Data Store para que almacene las bases de datos de la caché de escenas en otro equipo. En este caso, calcule el número de equipos necesario utilizando esta fórmula:
(<number of ArcGIS Server machines> + 1 Portal for ArcGIS machine + <number of machines in the data store>) X 2Tenga 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.
Duplicar implementaciones
Dentro de un SIG web 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 del SIG web se comunican entre ellos mediante direcciones URL específicas; por ejemplo, igual que ArcGIS Server y Portal for ArcGIS se comunican en un entorno federado. Por estos motivos, el SIG web de un sitio se debe duplicar en otro para que cada componente incluido en el SIG web de cada centro de datos sea el mismo (por ejemplo, el nombre de host, ubicación de la carpeta, nombre de la base de datos y dirección 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 el SIG web en espera pueda conectarse a los recursos correctamente. Todos los componentes del SIG web se deben instalar en los mismos directorios dentro de cada SIG web. 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 archivos host en los equipos para mantener la coherencia entre los nombres de host.
Replicar su SIG web
Portal for ArcGIS incluye la herramienta webgisdr, que le permite exportar contenido del portal, servidores SIG federados y contenido de ArcGIS Data Store (relacional y caché de teselas) 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 SIG 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 en el servidor SIG, por ejemplo, los datos de una base de datos o de una geodatabase de archivos. Depende de la organización replicar esos datos al SIG web en espera.
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 y los componentes del SIG web.
Es el usuario quien decide cuándo restaurar las copias de seguridad del SIG web en la implementación en espera. Si va a restaurar copias de seguridad en cuanto se exportan desde el SIG web principal, se producirá la implementación en espera, una pérdida mínima de datos o un tiempo de inactividad en el 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 al SIG web en espera. También debe tener en cuenta que, si algo falla en un SIG web al crear la copia de seguridad y existen procesos automáticos que importan la copia de seguridad al sistema de respaldo, estas configuraciones incorrectas también se importarán al SIG web en espera.
Consulte Configurar recuperación ante desastres para obtener instrucciones sobre cómo replicar una implementación de SIG web.
Supervisar su SIG web
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 en un SIG web falla, el software se conmuta por error inmediatamente al sistema en espera sin intervención por parte del usuario. De forma parecida, los componentes del servidor SIG y de 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 el SIG web, debería implementar mecanismos para notificar a los administradores los fallos que puedan producirse en cualquier componente del SIG web. Por ejemplo, las secuencias de comandos de Python se pueden configurar para que consulten periódicamente los registros de Portal for ArcGIS y ArcGIS Server a fin de comprobar si hay mensajes que indiquen un fallo de un determinado componente. Si se produce un fallo, se puede escribir la secuencia de comandos para que envíe correos electrónicos o notifique a los administradores que deben prestar atención. Consultar los registros mediante la API de administración de Portal for ArcGIS y la API de administración de ArcGIS for Server puede ser una forma eficaz de comprobar si hay algún problema.
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 deberá decidir si es necesaria una conmutación por error.
Conmutación por error
Dentro de un SIG web, Portal for ArcGIS, ArcGIS for Server y ArcGIS Data Store tienen sus propios mecanismos de conmutación por error. En un entorno de alta disponibilidad, cada componente puede conmutarse por error sin alterar de forma significativa el SIG web en general.
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. Normalmente, los miembros de una organización acceden a sus SIG web mediante unas cuantas direcciones URL; por ejemplo, https://my.organization.com/arcgis para la dirección URL del portal público y https://my.organization.com/server para la dirección URL de los servicios públicos. El GSS o GNS global puede asignar una dirección IP al nombre de host de my.organization.com. Si necesita realizar una conmutación por error a otro centro de datos, el GSS o DNS global volverá a asignar el nombre de host de my.organization.com a la dirección IP asociada 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 my.organization.com se puede reasignar a una dirección IP dentro del centro de datos original. En este momento debería conciliar los datos del sistema en espera al 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 SIG (geodatabase corporativa o base de datos), utilice las herramientas de replicación de bases de datos para asegurarse de que el SIG web principal original contiene esos datos actualizados. Si los datos de fuentes de datos basadas en archivos, como geodatabases de archivos, que están registrados en cualquiera de los servidores SIG del SIG web han cambiado, copie los archivos editados al directorio original donde se guardaron. Finalmente, use la utilidad webgisdr para exportar una copia de seguridad del SIG web desde el sistema en espera al sistema principal. La herramienta replicará al SIG web principal original el contenido del portal, incluidos los datos de la capa de entidad alojada asociada y los nuevos servicios no alojados que estén registrados en el portal.