Todos los sistemas informáticos tienen un propósito. Para cumplir ese propósito, tiene que estar disponible para su uso. Algunos sistemas informáticos son fundamentales para una empresa y, por lo tanto, deben tener una alta disponibilidad sin periodos de tiempo, o con periodos mínimos, de indisponibilidad parcial o total. Otros sistemas son menos vitales y una cierta cantidad de tiempo de inactividad programado o no programado es aceptable, por ejemplo, si los usuarios pueden recurrir a flujos de trabajo alternativos o simplemente esperar hasta que el sistema vuelva a estar disponible. Muchos sistemas se sitúan en algún punto intermedio entre estos dos extremos.
La alta disponibilidad (HA) es un planteamiento de diseño que habilita un sistema para alcanzar un nivel preestablecido de rendimiento operativo durante un periodo de tiempo específico. Los sistemas de alta disponibilidad proporcionan a los clientes un sistema y un entorno fiables para satisfacer o superar sus requisitos empresariales de prestación de servicios y rendir al nivel de calidad esperado.
La alta disponibilidad, aunque está relacionada con la recuperación ante desastres (DR), es un concepto independiente. En general, la HA se enfoca en evitar tiempos de inactividad no planificados para la prestación de servicios, mientras que la DR se centra en conservar los datos y recursos necesarios para restaurar un sistema a un estado previo aceptable tras un desastre. Cuando se implementan los planes de DR, es habitual que la prestación de servicios se vea interrumpida hasta que se haya restaurado el sistema. Consulte Copias de seguridad y recuperación ante desastres para obtener más información.
Otro término de uso común en este espacio es la redundancia geográfica, que generalmente se refiere al objetivo de diseño de tener una aplicación o sistema que pueda sobrevivir a una interrupción completa del centro de datos teniendo sistemas adicionales o un sistema de copia de seguridad disponible en otra ubicación geográfica. Este planteamiento puede ayudar a protegerse contra catástrofes naturales, cortes de electricidad u otras interrupciones de la disponibilidad del centro de datos.
Muchos arquitectos utilizan un conjunto común de términos para referirse y describir en detalle un planteamiento de alta disponibilidad a nivel de sistema o de componente. Los términos más utilizados en esta área son:
Una métrica con la que se puede medir la disponibilidad es el tiempo de actividad, que generalmente se mide como el porcentaje de tiempo que un sistema ha estado «disponible» durante un periodo determinado. La definición de disponible es subjetiva y debe establecerse al principio del proceso de diseño del sistema para poder llegar a un acuerdo compartido sobre este objetivo. Un nivel deseado de disponibilidad se define con frecuencia como un tiempo de actividad objetivo, expresado a menudo en términos de nueves. Por ejemplo:
Los objetivos de disponibilidad pueden formalizarse en forma de un acuerdo de nivel de servicio (SLA) entre los usuarios de un sistema y la organización que opera dicho sistema. A menudo, los acuerdos de nivel de servicio incluyen otras métricas relacionadas con el rendimiento más allá de los objetivos de disponibilidad pura, como los tiempos de respuesta previstos, y pueden definir penalizaciones por cumplir esos objetivos si existe una relación entre el proveedor y el cliente. Los SLA internos también son igualmente importantes, aunque generalmente no incluyen los requisitos de penalización e información de un SLA de cara al cliente.
Otro planteamiento que adoptan las organizaciones en relación con la disponibilidad es establecer niveles de criticidad para los sistemas que mantienen, que van desde los no esenciales hasta los fundacionales, en función del impacto que pueda tener una interrupción en una organización. Las consideraciones pueden incluir la experiencia del usuario y el impacto financiero, reputacional y normativo; además, cada nivel de criticidad puede tener una definición de SLA objetivo diferente. Algunas organizaciones pueden referirse a un determinado sistema como de «nivel 1» o «fundamental para el negocio» mientras que otros sistemas son de «nivel 2» o menos fundamentales para el negocio y, por tanto, tienen menos restricciones o configuraciones diferentes.
El diseño y la construcción de un sistema para alcanzar un nivel de disponibilidad predefinido requiere un planteamiento holístico que tenga en cuenta muchos otros aspectos o áreas temáticas, entre ellos:
Crear un sistema que se adapte a las mayores exigencias de tiempo de actividad suele requerir una importante inversión inicial y continua de tiempo y recursos si se compara con una línea base que solo cumple un nivel normativo de disponibilidad. Sin embargo, la alta disponibilidad no es una proposición de todo o nada, y con frecuencia es útil considerar si hay subsistemas para los que los objetivos de disponibilidad pueden relajarse sin afectar significativamente al valor empresarial de un sistema informático.
El proceso de diseño de un sistema de alta disponibilidad no comienza con un lienzo en blanco. En la mayoría de los casos, la infraestructura informática, las políticas, los conocimientos y las preferencias existentes en una organización determinarán el marco general al que debe adaptarse un sistema SIG corporativo. Esto incluye las expectativas de tiempo de actividad o disponibilidad de los sistemas de apoyo y qué componentes de TI están disponibles para ayudar a lograr un alto nivel de disponibilidad. Considere las interdependencias entre las decisiones, donde una decisión de diseño con frecuencia engendra otra. Muchos de estos detalles pueden considerarse restricciones de diseño, que ayudan a guiar un proceso de diseño hacia un destino mutuamente aceptable, en el que el sistema cumpla los requisitos generales al tiempo que se ajusta a las normas ya establecidas por la organización y equilibra el coste, la manejabilidad y otros factores.
Con frecuencia, las limitaciones de diseño entran dentro de estas categorías:
Del mismo modo, las organizaciones de TI pueden limitar aún más el rango de opciones para la infraestructura, por ejemplo, marcas y modelos específicos para el hardware físico, capas de virtualización, sistemas de almacenamiento, equilibradores de carga, proxies inversos, etc.
Aprovechar la infraestructura como servicio (IaaS) comercial basada en la nube, ya sean equipos virtuales o clústeres de Kubernetes, también restringe sus opciones.
Con respecto a ArcGIS Enterprise, la alta disponibilidad se refiere a las medidas que aumentan la disponibilidad de una sola implementación de ArcGIS Enterprise. Las implementaciones replicadas, normalmente distribuidas geográficamente en otro centro de datos o en otra región de la nube, proporcionan una funcionalidad de recuperación ante desastres. Más información sobre Alta disponibilidad en ArcGIS Enterprise.
ArcGIS Enterprise proporciona mayores niveles de disponibilidad mediante la combinación de varios equipos en distintas configuraciones. Los componentes de ArcGIS Enterprise utilizan planteamientos distintos para lograr una alta disponibilidad:
Un sitio de portal de alta disponibilidad que consta de dos servidores que se unen para crear el sitio de HA. Cada uno de ellos es totalmente redundante, pero el sistema mantiene un equipo como nodo primario y el otro equipo es el nodo en espera. Si el equipo primario falla, el equipo en espera detectará el fallo y se promoverá a sí mismo para convertirse en el primario.
A nivel del servidor web, el sistema es activo-activo, ya que cada nodo del portal puede atender las solicitudes entrantes y los índices de búsqueda se mantienen sincronizados en ambos sistemas. Sin embargo, solo un nodo gestiona los cambios de estado, en los que las ediciones, las invitaciones a miembros y las configuraciones se guardan en la base de datos del portal, por lo que el sistema global se considera activo-pasivo.
Un portal de alta disponibilidad también requiere un equilibrador de carga para distribuir las peticiones entre los dos nodos, normalmente por turnos. Los nodos primario y en espera comparten el estado mediante la comunicación entre equipos a través de puertos y la sincronización de bases de datos, pero también dependen del almacenamiento compartido de archivos para el directorio de contenido del portal, que puede ser un archivo compartido NFS, un archivo compartido UNC o un almacenamiento de objetos nativo en la nube.
Más información sobre la Configuración de una implementación de Portal for ArcGIS de alta disponibilidad.
Un sitio de servidor SIG de alta disponibilidad consta de dos o más equipos totalmente redundantes, que se unen en un «sitio» de ArcGIS Server en el que las cargas de trabajo se equilibran entre todos los nodos, lo que constituye una configuración activo-activo. Un servidor SIG de alta disponibilidad también requiere un equilibrador de carga para dirigir las solicitudes a los equipos miembros, normalmente con un planteamiento por turnos, aunque el tráfico web también puede dirigirse de forma primario-en espera.
Los equipos de un sitio comparten estado principalmente a través de una ubicación de almacenamiento compartida para los directorios del servidor y el almacén de configuraciones, normalmente un archivo compartido de tipo NFS o basado en UNC. Para los sistemas en la nube, también existen opciones nativas de la nube para el almacén de configuración, como el almacenamiento DynamoDB y S3 en AWS o el almacenamiento Azure Files en Microsoft Azure.
Cabe señalar que algunos roles especializados del servidor SIG, como el GeoEvent Server, no pueden configurarse para ejecutarse en un sitio con varios equipos. Como resultado, se aplican consideraciones especiales para lograr niveles más altos de disponibilidad para esos roles de servidor SIG.
Obtenga más información sobre la configuración de un sitio con varios equipos para lograr una implementación de alta disponibilidad de ArcGIS Server. También hay disponibles recursos para implementaciones de alta disponibilidad de un solo equipo.
El adaptador web puede implementarse de forma redundante en dos o más equipos, siendo cada instancia totalmente redundante en una configuración activo-activo. Esta configuración requiere un equilibrador de carga frontal al que los clientes envían las solicitudes, que distribuye las solicitudes entre los dos hosts del adaptador web. Hay más recursos disponibles en la documentación.
Data store relacional Un data store relacional de alta disponibilidad consta de exactamente dos instancias totalmente redundantes en una configuración de clúster activo-activo. Si el equipo del data store principal falla, el equipo en espera detectará el error y pasará a ser el principal, lo que permitirá a los clientes seguir utilizando los servicios de entidades alojados sin interrupción.
Graph data store: un graph store de alto rendimiento consta de exactamente tres instancias totalmente redundantes en una configuración de clúster activo-activo.
Almacén de objetos: se admite una alta disponibilidad para el almacén de objetos en modo clúster, siendo necesarios al menos tres equipos para esta arquitectura. En el modo clúster, los datos se replican en los tres equipos para que el data store siga estando disponible en caso de avería de un solo equipo.
Big data store espaciotemporal: este tipo de data store también admite el modo clúster. Los clústeres deben contener un número impar de equipos, necesario para la búsqueda de consenso entre los miembros, así como un mínimo de tres equipos. Todas estas configuraciones son configuraciones de alta disponibilidad activo-activo.
El tema de la documentación Configurar data stores administrados de alta disponibilidad proporciona orientación, pasos y recomendaciones adicionales.
La disponibilidad de recursos de bases de datos es un campo especializado de la arquitectura con muchas opciones específicas de cada proveedor para cada oferta individual de base de datos, incluidos los patrones activo-activo y activo-pasivo. En general, ArcGIS puede conectarse a estas configuraciones cuando el proceso de registro de datos por el que se accede a los servicios o se publican utiliza un alias DNS o una IP flexible, a la que siempre se accede desde ArcGIS pero que podría apuntar a otro backend de base de datos si se produce una interrupción del sistema principal. En este escenario, los componentes de ArcGIS no son conscientes del cambio en la base de datos backend y siguen funcionando como es debido suponiendo que se dispone de las mismas credenciales, esquema y filas.
Para tomar decisiones educadas y eficaces relacionadas con la alta disponibilidad, tenga en cuenta estas recomendaciones de diseño: