概述

EKS/AKS 上 Automation Suite 中的主动/被动和主动/主动多站点部署的架构和配置。

图表

下图描述了 Automation Suite 的常规主动/被动部署：

要求

多站点部署需要以下硬件和基础架构组件。

全局流量管理器 (GTM)

GTM 在 Automation Suite 多站点部署之间分配流量。它必须在任何单个部署站点上具有高可用性并且不受故障。GTM 还必须支持运行状况检查，以快速隔离故障站点。GTM 并非必需项，但建议您使用 GTM 以便快速切换。

为主动/被动部署配置 GTM 时，请使用 /orchestrator_/api/status 作为运行状况端点。这对于有效的灾难恢复管理至关重要。

Load balancer

每个站点都需要一个本地负载均衡器，该负载均衡器可以将流量负载均衡到同一站点中配置的任何节点。

节点

两个站点必须具有相同数量的节点。对于每个站点，您必须使用Kubernetes 集群和节点中的文档配置集群和节点。有关详细信息，请参阅Automation Suite 安装大小调整计算器。

SQL 数据库

需要使用外部 SQL Server 来存储数据。对于 Disaster Recovery，您需要“始终开启”可用性组（或 Amazon RDS 的 MSSQL 与只读副本），其中站点 1 中有一个主 SQL 服务器，并且至少有一个辅助 SQL 服务器（只读副本）实际位于站点 2 中，并启用了数据同步。在 SQL Server 之外，我们已部署 SQL 侦听器，并将两个集群配置为使用同一侦听器的地址。

主动（主）和被动（辅助）站点和集群都必须使用主数据库端点进行数据库通信。如果发生灾难，将只读副本提升为主节点后，必须在两个站点中更新其端点，以用作新的数据库连接字符串。

为了简化故障转移管理，您可以使用 Amazon Route 53 为数据库创建 DNS 记录。最初，它必须指向主数据库端点（或侦听器）。如果进行故障转移，请更新 Route 53 记录，使其指向新提升的主数据库（以前称为只读副本）。

PostgreSQL 数据库

Process Mining、Autopilot for Developers 和 Temporal 即服务 (TaaS) 需要外部 PostgreSQL 服务器。对于 Disaster Recovery，只需将 Autopilot for Developers 数据库复制到辅助站点。Process Mining/Airflow 数据库不需要跨站点复制，但每个站点仍需要一个 PostgreSQL 实例。辅助集群不支持 TaaS；仅在主动/被动部署的主站点中受支持。

在站点 1 中配置主 PostgreSQL 服务器，并通过物理流复制到站点 2 中的至少一个只读副本，或使用托管提供程序的复制功能，例如 Amazon RDS 只读副本、Aurora PostgreSQL 全局数据库或 Azure Database for PostgreSQL Flexible服务器异地副本。

PostgreSQL 一次仅支持一个可写主数据库端点，因此主动集群和被动集群都必须使用当前的主数据库端点。在 Disaster Recovery 期间，将站点 2 副本提升为主副本后，请更新两个站点中的数据库端点，以指向新提升的主副本。为了简化故障转移，请对数据库端点使用 DNS 记录，并在故障转移期间进行更新。

对象存储

上传到产品的任何文件或包都存储在对象存储中。为了增强对故障的恢复能力，Automation Suite 部署需要外部对象存储。

为了有效进行灾难恢复，需要两个对象存储实例，每个数据中心各有一个。在任何给定时间，两个集群只能主动使用一个对象存储实例进行读取和写入，并异步复制到辅助实例。

时间即服务 (TaaS)

如果启用了 Maestro，则一次只能有一个集群主动运行 TaaS。在被动集群上，将所有 TaaS 部署扩展至零副本。如果两个集群同时连接到同一个 PostgreSQL 持久性存储，则会发生锁争用并降低性能。有关详细信息，请参阅Temporal as a Service 故障排除。

负载均衡器和 DNS 配置

本节概述了设计为在正常和灾难恢复场景中运行的系统的基础架构设置、DNS 架构和路由逻辑。

基础架构概述

为支持高可用性和 Disaster Recovery，系统需要双负载均衡器设置：

• 主负载均衡器：分配给活动（主）集群，用于处理标准应用程序流量。
• 辅助负载均衡器：已分配给被动（辅助）集群，准备在主集群发生故障时进行接管。

为每个负载均衡器分配了一个唯一的弹性 IP (EIP)，用作 DNS 解析的端点。

DNS 架构

为了便于流量管理和特定于集群的服务可访问性，采用两层 DNS 配置。

• FQDN ：应用程序 FQDN 是最终用户用于访问应用程序界面的主要域。该值对应于fqdn中的input.json字段。有关详细信息，请参阅主动/被动配置。
• 特定于集群的 FQDN ：除了主应用程序 FQDN 外，每个集群都需要有自己的 FQDN，用于管理和监控工具。此值在每个集群的cluster_fqdn中的input.json字段下定义。有关详细信息，请参阅主动/被动配置。
• 子域：对于全面的服务访问权限，为应用程序 FQDN 和每个特定于集群的 FQDN 配置了一组子域。其中包括：

  • FQDN：

    • apps.<domain> - 由 Apps 使用。
    • insights.<domain> - 由 Insights 使用。

  • 集群特定的 FQDN：

    • alm.<domain> - 由 ArgoCD 用于部署管理。主动（主）和被动（辅助）集群都需要执行此操作。
    • monitoring.<domain> - 用于可观察性和警示。主动（主）和被动（辅助）集群都需要执行此操作。

    所有子域都定向到相同的弹性 IP (EIP) 作为各自的根域，以保持一致性和路由易用性。

DNS 路由逻辑

DNS 路由逻辑可确保在正常操作或灾难恢复期间根据系统状态将用户流量定向到适当的负载均衡器。

• 正常操作（主集群处于活动状态） 在标准操作模式下，DNS 会按下表中所述路由流量：

  FQDN 类型	路由目标
  FQDN	主集群负载均衡器
  主集群 FQDN	主集群负载均衡器
  辅助集群 FQDN	辅助集群负载均衡器

• 灾难恢复（辅助集群处于活动状态）如果主集群发生故障，系统将进入灾难恢复模式。在此状态下，系统会调整 DNS 以确保服务连续性：

  FQDN 类型	路由目标
  FQDN	辅助集群负载均衡器
  主集群 FQDN	主集群负载均衡器*（不变）*
  辅助集群 FQDN	辅助集群负载均衡器*（不变）*