Información general

Diagramas

El siguiente diagrama representa una implementación activa/pasiva regular de Automation Suite:

Requisitos

Hardware	Requisitos
Gestor de tráfico global (GTM)	Distribuye el tráfico a tu implementación multisitio de Automation Suite. El servicio debe estar disponible y ser inmune a cualquier sitio de implementación. Además, GTM debe poder configurar la comprobación de estado para aislar rápidamente el sitio defectuoso. GTM no es obligatorio, pero se recomienda para un cambio rápido. Al configurar Global Traffic Manager (GTM) para implementaciones activas/pasivas, asegúrate de utilizar /orchestrator_/api/status como punto final de estado. Esto es fundamental para una gestión eficaz de la recuperación ante desastres.
Load balancer	Cada sitio necesita un equilibrador de carga local que pueda equilibrar la carga del tráfico en cualquier nodo configurado en el mismo sitio.
Nodo	Ambos sitios deben tener un número idéntico de nodos y para cada sitio debes configurar el clúster y los nodos utilizando la documentación proporcionada en la página Clúster y nodos de Kubernetes . Para obtener más información, consulta Calculadora de tamaño de instalación de Automation Suite.
Base de datos SQL	Se requiere un servidor SQL externo para almacenar los datos. Para la recuperación ante desastres, necesitas grupos de disponibilidad AlwaysOn (o MSSQL de Amazon RDS con ReadReplica) con un servidor SQL principal en el sitio 1 y al menos un servidor SQL secundario físicamente (ReadReplica) ubicado en el sitio 2 con la sincronización de datos habilitada. También hay un escucha SQL implementado en la parte superior del servidor SQL. Ambos clústeres están configurados para utilizar la dirección del mismo listener.
Almacén de objetos	Cualquier archivo o paquete cargado en productos se almacena en el almacén de objetos. Para una mayor resistencia a los fallos, las implementaciones de Automation Suite requieren un almacén de objetos externo. Para una recuperación de desastres eficaz, se requieren dos instancias de almacén de objetos; debe estar situada una instancia en cada centro de datos. En cualquier momento, solo debe utilizarse activamente una instancia de almacén de objetos para la lectura y escritura por ambos clústeres. Este proceso debe complementarse con la replicación asíncrona en la instancia secundaria.

Equilibrador de carga y configuración de DNS

Esta sección describe la arquitectura DNS y la lógica de enrutamiento para un sistema diseñado para funcionar tanto en escenarios normales como de recuperación ante desastres.

Arquitectura DNS

Para facilitar la gestión del tráfico y la accesibilidad de los servicios específicos del clúster, se emplean dos niveles de configuración de DNS.

• FQDN: el FQDN de la aplicación es el dominio principal utilizado por los usuarios finales para acceder a la interfaz de la aplicación. Este valor corresponde al campo fqdn en input.json. Para obtener más información, consulta Configuraciones activas/pasivas.
• FQDN específicos del clúster: además del FQDN de la aplicación principal, cada clúster requiere su propio FQDN para las herramientas administrativas y de supervisión. Este valor se define en el campo cluster_fqdn en el input.json de cada clúster. Para obtener más información, consulta Configuraciones activas/pasivas.
• Subdominios: para un acceso completo al servicio, se configura un conjunto de subdominios tanto para el FQDN de la aplicación como para cada FQDN específico del clúster. Estos incluyen:
  • FQDN:
    • apps.<domain> : utilizado por Apps.
    • insights.<domain> : utilizado por para Insights.
  • FQDN específico del clúster:
    • alm.<domain> : utilizado por ArgoCD y para la gestión de la implementación. Esto es necesario tanto para los clústeres activos (primarios) como para los pasivos (secundarios).
    • monitoring.<domain> : se utiliza para la observabilidad y las alertas. Esto es necesario tanto para los clústeres activos (primarios) como para los pasivos (secundarios).

  Todos los subdominios se dirigen al mismo equilibrador de carga que su respectivo dominio raíz para mantener la coherencia y facilitar el enrutamiento.

Lógica de enrutamiento de DNS

La lógica de enrutamiento de DNS garantiza que el tráfico de usuario se dirija al equilibrador de carga adecuado en función del estado del sistema, ya sea durante el funcionamiento normal o durante la recuperación ante desastres.

• Operaciones normales (el clúster principal está activo)

  En el modo de funcionamiento estándar, el DNS enruta el tráfico como se describe en la siguiente tabla:

  Tipo de FQDN	Destino de enrutamiento
  FQDN	Equilibrador de carga del clúster principal
  FQDN del clúster principal	Equilibrador de carga del clúster principal
  FQDN del clúster secundario	Equilibrador de carga de clúster secundario

• Disaster Recovery (el clúster secundario está activo)

  Si el clúster principal falla, el sistema entra en modo de recuperación ante desastres. En este estado, el DNS se ajusta para garantizar la continuidad del servicio:

  Tipo de FQDN	Destino de enrutamiento
  FQDN	Equilibrador de carga de clúster secundario
  FQDN del clúster principal	Equilibrador de carga del clúster principal(sin cambios)
  FQDN del clúster secundario	Equilibrador de carga de clúster secundario(sin cambios)