Información general

Arquitectura y topología para implementaciones activas/pasivas y activas/activas de Automation Suite.

Diagramas

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

Requisitos

Los siguientes componentes de hardware e infraestructura son necesarios para una implementación en varios sitios.

Gestor de tráfico global (GTM)

GTM distribuye el tráfico en tu implementación multisitio de Automation Suite. Debe ser de alta disponibilidad e inmune a fallos en cualquier sitio de implementación único. GTM también debe admitir comprobaciones de estado que aíslen rápidamente un sitio defectuoso. El GTM no es obligatorio, pero se recomienda para un cambio rápido.

Al configurar GTM para implementaciones activas/pasivas, utiliza /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 a cualquier nodo configurado en el mismo sitio.

Nodo

Both sites must have an identical number of nodes. For each site, you must configure the cluster and nodes using the documentation in Kubernetes cluster and nodes. For details, refer to Automation Suite Install Sizing Calculator.

Base de datos SQL

Se requiere un servidor SQL externo para almacenar los datos. Para la recuperación ante desastres, necesitas grupos de disponibilidad siempre disponibles (o MSSQL de Amazon RDS con ReadReplica) con un servidor SQL principal en el sitio 1 y al menos un servidor SQL secundario (ReadReplica) ubicado físicamente en el sitio 2, con la sincronización de datos habilitada. Se implementa un agente de escucha SQL en la parte superior del servidor SQL y ambos clústeres están configurados para utilizar la dirección del mismo agente de escucha.

Base de datos PostgreSQL

Process Mining, Autopilot™ para Developers y Temporal como servicio (TaaS) requieren un servidor PostgreSQL externo. Para la recuperación ante desastres, solo las bases de datos de Autopilot™ para Developers deben replicarse en el sitio secundario. La base de datos de Process Mining/Airflow no requiere replicación entre sitios, pero sigue siendo necesaria una instancia de PostgreSQL en cada sitio. TaaS no es compatible con el clúster secundario; solo se admite en el sitio principal en una implementación activa/pasiva.

Configure un servidor PostgreSQL principal en el sitio 1 con replicación de transmisión física a al menos una réplica de solo lectura en el sitio 2, o utilice la característica de replicación del proveedor administrado, como Réplicas de lectura de Amazon RDS, Base de datos global de Aurora PostgreSQL o Base de datos de Azure para PostgreSQL Flexible Réplicas geográficas del servidor.

PostgreSQL solo admite un primario de escritura a la vez, por lo que tanto el clúster activo como el pasivo deben utilizar el punto final de la base de datos principal actual. Durante la recuperación de desastres, una vez que la réplica del sitio 2 se promueve a principal, actualiza el punto final de la base de datos en ambos sitios para que apunte al principal recién promovido. Para simplificar la conmutación por error, utiliza un registro DNS para el punto final de la base de datos y actualízalo durante la conmutación por error.

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 ante desastres efectiva, se requieren dos instancias de almacén de objetos, una en cada centro de datos. En cualquier momento, solo una instancia de almacén de objetos debe utilizarse activamente para leer y escribir por ambos clústeres, complementada con la replicación asíncrona en la instancia secundaria.

Temporal como servicio (TaaS)

If Maestro is enabled, only one cluster can actively run TaaS at a time. On the passive cluster, scale all TaaS deployments to zero replicas. If both clusters connect to the same PostgreSQL persistence store simultaneously, lock contention occurs and degrades performance. For details, refer to Temporal as a Service troubleshooting.

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: The application FQDN is the primary domain used by end users to access the application interface. This value corresponds to the fqdn field in input.json. For details, refer to Active/Passive configurations.
• Cluster-specific FQDNs: In addition to the main application FQDN, each cluster requires its own FQDN for administrative and monitoring tools. This value is defined under the cluster_fqdn field in each cluster's input.json. For details, refer to Active/Passive configurations.
• 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 del 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 operación 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 de 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 del clúster secundario*(sin cambios)*