Visão geral

Arquitetura e topologia para implantações Ativo/Passivo e Ativo/Ativo do Automation Suite.

Diagramas

O diagrama a seguir apresenta uma implantação Ativo/Passivo regular do Automation Suite:

Requisitos

Os componentes de hardware e infraestrutura a seguir são necessários para uma implantação em vários locais.

Gerenciador de Tráfego Global (GTM)

O GTM distribui o tráfego pela sua implantação multi-local do Automation Suite. Ele deve estar altamente disponível e imune a falhas em qualquer local de implantação único. O GTM também deve oferecer suporte a verificações de integridade que isolam rapidamente um local com falha. O GTM não é obrigatório, mas é recomendado para uma transição rápida.

Ao configurar o GTM para implantações Ativas/Passivas, use /orchestrator_/api/status como o ponto de extremidade de integridade. Isso é fundamental para o gerenciamento eficaz do Disaster Recovery.

Load balancer

Cada site precisa de um balanceador de carga local que possa equilibrar a carga do tráfego para qualquer nó configurado no mesmo site.

Nó

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.

banco de dados SQL

Um servidor SQL externo é necessário para armazenar os dados. Para disaster recovery, você precisa de Grupos de disponibilidade Sempre ativada (ou MSSQL do Amazon RDS com ReadReplica) com um servidor SQL primário no Site 1 e pelo menos um servidor SQL secundário (ReadReplica) localizado fisicamente no Site 2, com sincronização de dados habilitada. Um receptor SQL é implantado além do servidor SQL, e ambos os clusters são configurados para usar o endereço do mesmo receptor.

banco de dados PostgreSQL

Process Mining, Autopilot™ para Developers e Temporal como serviço (TaaS) exigem um servidor PostgreSQL externo. Para disaster recovery, apenas os bancos de dados do Autopilot para Developers devem ser replicados para o site secundário. O banco de dados do Process Mining/Airflow não requer replicação entre locais, mas uma instância PostgreSQL ainda é necessária em cada local. O TaaS não é compatível no cluster secundário; é suportado apenas no local primário em uma implantação Ativa/Passiva.

Configure um servidor PostgreSQL primário no Local 1 com replicação de streaming físico para pelo menos uma réplica somente leitura no Local 2, ou use a funcionalidade de replicação do provedor gerenciado, como Amazon RDS Read Replicas, Atividades Réplicas geográficas do servidor.

O PostgreSQL é compatível com apenas um primário gravável de cada vez, portanto, tanto o cluster ativo quanto o passivo devem usar o endpoint do banco de dados primário atual. Durante a disaster recovery, assim que a réplica do Site 2 for promovido para primário, atualize o ponto de extremidade do banco de dados em ambos os sites para apontar para o primário recém-provisionado. Para simplificar o failover, use um registro DNS para o ponto de extremidade do banco de dados e atualize-o durante o failover.

Armazenamento de objeto

Quaisquer arquivos ou pacotes carregados para produtos são armazenados no objectstore.Para maior resiliência à falha, as implantações do Automation Suite exigem um objectstore externo.

Para uma disaster recovery eficaz, duas instâncias objectstore são necessárias, uma em cada data center. A qualquer momento, apenas uma instância do objectstore deve ser usada ativamente para leitura e gravação por ambos os clusters, complementada pela replicação assíncrona para a instância secundária.

Temporal como um serviço (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.

Balanceador de carga e configuração de DNS

Esta seção descreve a arquitetura de DNS e a lógica de roteamento para um sistema projetado para operar em cenários normais e de recuperação de desastres.

Arquitetura do DNS

Para facilitar o gerenciamento do tráfego e a acessibilidade a serviços específicos do cluster, são empregados dois níveis de configuração 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.
• Subdomínios: para acesso abrangente ao serviço, um conjunto de subdomínios é configurado para o FQDN do aplicativo e cada FQDN específico do cluster. Elas incluem:
  • FQDN:
    • apps.<domain> — usado pelo Apps.
    • insights.<domain> — usado por para o Insights.
  • FQDN específico do cluster:
    • alm.<domain> - usado pelo ArgoCD e para gerenciamento de implantação. Isso é necessário para clusters Ativo (primário) e Passivo (secundário).
    • monitoring.<domain> - usado para capacidade de observação e alertas. Isso é necessário para os clusters Ativo (primário) e Passivo (secundário). Todos os subdomínios são direcionados para o mesmo balanceador de carga que seu respectivo domínio raiz para manter a consistência e facilitar o roteamento.

Lógica de roteamento de DNS

A lógica de roteamento de DNS garante que o tráfego do usuário seja direcionado para o balanceador de carga adequado, dependendo do estado do sistema

• seja durante a operação normal ou a recuperação de desastres.

• Operações normais (o cluster primário está ativo) No modo de operação padrão, o DNS roteia o tráfego conforme descrito na tabela a seguir:

  Tipo de FQDN	Destino de roteamento
  FQDN	Balanceador de carga do cluster primário
  FQDN do cluster primário	Balanceador de carga do cluster primário
  FQDN do cluster secundário	Balanceador de carga do cluster secundário

• Recuperação de desastre (o cluster secundário está ativo) Se o cluster primário falhar, o sistema entra no modo de recuperação de desastres. Nesse estado, o DNS é ajustado para garantir a continuidade do serviço:

  Tipo de FQDN	Destino de roteamento
  FQDN	Balanceador de carga do cluster secundário
  FQDN do cluster primário	Balanceador de carga do cluster primário*(inalterado)*
  FQDN do cluster secundário	Balanceador de carga do cluster secundário*(inalterado)*