Overview

Architecture and configuration for Active/Passive and Active/Active multi-site deployments in Automation Suite on EKS/AKS.

Diagrams

The following diagram depicts a regular Active/Passive deployment of Automation Suite:

Requirements

The following hardware and infrastructure components are required for a multi-site deployment.

Global Traffic Manager (GTM)

The GTM distributes traffic across your Automation Suite multi-site deployment. It must be highly available and immune to failure at any single deployment site. The GTM must also support health checks that isolate a faulty site quickly. The GTM is not mandatory, but it is recommended for a quick switchover.

When configuring the GTM for Active/Passive deployments, use /orchestrator_/api/status as the health endpoint. This is critical for effective disaster recovery management.

Load balancer

Every site needs a local load balancer that can load-balance traffic to any node configured in the same site.

Node

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.

SQL database

An external SQL server is required to store the data. For disaster recovery, you need Always On Availability Groups (or Amazon RDS's MSSQL with ReadReplica) with a primary SQL server in Site 1 and at least one secondary SQL server (ReadReplica) physically located in Site 2, with data sync enabled. A SQL listener is deployed on top of the SQL server, and both clusters are configured to use the address of the same listener.

Both the active (primary) and passive (secondary) sites and clusters must use the Primary Database endpoint for database communication. In the event of a disaster, once the read replica is promoted to primary, its endpoint must be updated in both sites to serve as the new database connection string.

To simplify failover management, you can use Amazon Route 53 to create a DNS record for the database. Initially, it must point to the Primary Database endpoint (or listener). In case of a failover, update the Route 53 record to point to the newly promoted primary database (formerly the read replica).

PostgreSQL database

Process Mining, Autopilot for Developers, and Temporal as a Service (TaaS) require an external PostgreSQL server. For disaster recovery, only the Autopilot for Developers database must be replicated to the secondary site. The Process Mining/Airflow database does not require cross-site replication, but a PostgreSQL instance is still required at each site. TaaS is not supported in the secondary cluster; it is supported only in the primary site in an Active/Passive deployment.

Configure a primary PostgreSQL server in Site 1 with physical streaming replication to at least one read-only replica in Site 2, or use the managed provider's replication feature, such as Amazon RDS Read Replicas, Aurora PostgreSQL Global Database, or Azure Database for PostgreSQL Flexible Server geo-replicas.

PostgreSQL supports only one writable primary at a time, so both the active and passive clusters must use the current primary database endpoint. During disaster recovery, once the Site 2 replica is promoted to primary, update the database endpoint in both sites to point to the newly promoted primary. To simplify failover, use a DNS record for the database endpoint and update it during failover.

Objectstore

Any files or packages uploaded to products are stored in the objectstore. For greater resilience to failure, Automation Suite deployments require an external objectstore.

For effective disaster recovery, two objectstore instances are required, one in each data center. At any given time, only one objectstore instance must be actively used for reading and writing by both clusters, complemented by asynchronous replication to the secondary instance.

Temporal as a Service (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.

Load balancer and DNS configuration

This section outlines the infrastructure setup, DNS architecture, and routing logic for a system designed to operate in both normal and disaster recovery scenarios.

Infrastructure overview

To support high availability and disaster recovery, the system requires a dual-load-balancer setup:

• Primary Load Balancer: Assigned to the active (primary) cluster for handling standard application traffic.
• Secondary Load Balancer: Assigned to the passive (secondary) cluster, ready to take over in case of a failure in the primary.

Each load balancer is assigned a unique Elastic IP (EIP), which serves as the endpoint for DNS resolution.

DNS architecture

To facilitate traffic management and cluster-specific service accessibility, two tiers of DNS configuration are employed.

• 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.
• Subdomains: For comprehensive service access, a set of subdomains is configured for both the application FQDN and each cluster-specific FQDN. These include:

  • FQDN:

    • apps.<domain> - used by Apps.
    • insights.<domain> - used by for Insights.

  • Cluster-specific FQDN:

    • alm.<domain> - used by ArgoCD and for deployment management. This is required for both Active (primary) and Passive (secondary) clusters.
    • monitoring.<domain> - used for observability and alerts. This is required for both Active (primary) and Passive (secondary) clusters.

    All subdomains are directed to the same Elastic IP (EIP) as their respective root domain to maintain consistency and ease of routing.

DNS routing logic

The DNS routing logic ensures that user traffic is directed to the appropriate load balancer depending on the system state, either during normal operation or disaster recovery.

• Normal Operations (Primary Cluster is Active) In standard operation mode, DNS routes traffic as described in the following table:

  FQDN type	Routing target
  FQDN	Primary Cluster Load Balancer
  Primary Cluster FQDN	Primary Cluster Load Balancer
  Secondary Cluster FQDN	Secondary Cluster Load Balancer

• Disaster Recovery (Secondary Cluster is Active) If the primary cluster fails, the system enters disaster recovery mode. In this state, DNS is adjusted to ensure service continuity:

  FQDN type	Routing target
  FQDN	Secondary Cluster Load Balancer
  Primary Cluster FQDN	Primary Cluster Load Balancer*(unchanged)*
  Secondary Cluster FQDN	Secondary Cluster Load Balancer*(unchanged)*