Visão geral

Arquitetura e configuração para implantações em vários locais Ativa/Passiva e Ativa/Ativa no Automation Suite no EKS/AKS.

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ó

Ambos os sites devem ter um número idêntico de nós. Para cada local, você deve configurar o cluster e os nós usando a documentação em Cluster e nós do Kubernetes. Para obter detalhes, consulte Calculador de dimensionamento de instalação do Automation Suite.

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.

Tanto os sites e clusters ativos (primário) e passivos (secundários) devem usar o endpoint do banco de dados primário para comunicação com banco de dados. No caso de um desastre, depois que a réplica de leitura for promovido a primário, seu ponto de extremidade deve ser atualizado em ambos os locais para servir como a nova string de conexão com banco de dados.

Para simplificar o gerenciamento de failover, você pode usar o Amazon Route 53 para criar um registro DNS para o banco de dados. Inicialmente, ele deve apontar para o endpoint do Banco de Dados Primário (ou ouvinte). Em caso de um failover, atualize o registro Route 53 para apontar para o banco de dados primário recém-provisionado (anteriormente a réplica de leitura).

banco de dados PostgreSQL

Process Mining, Autopilot™ para Developers e Temporal como serviço (TaaS) exigem um servidor PostgreSQL externo. Para disaster recovery, apenas o banco de dados Autopilot para Developers deve ser replicado 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)

Se o Maestro estiver habilitado, apenas um cluster poderá executar ativamente o TaaS por vez. No cluster passivo, dimensione todas as implantações do TaaS para réplicas zero. Se ambos os clusters se conectarem ao mesmo armazenamento de persistência do PostgreSQL simultaneamente, ocorrerá uma contenção de bloqueio e degradará o desempenho. Para obter detalhes, consulte Solução de problemas de Temporal como um Serviço.

Balanceador de carga e configuração de DNS

Esta seção descreve a configuração da infraestrutura, 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.

Visão geral da infraestrutura

Para suportar a alta disponibilidade e Disaster Recovery, o sistema requer uma configuração de balanceador de carga duplo:

• Balanceador de carga primário: atribuído ao cluster (primário) ativo para lidar com o tráfego de aplicativos padrão.
• Balanceador de carga secundário: atribuído ao cluster passivo (secundário), pronto para assumir em caso de falha no primário.

Cada balanceador de carga recebe um Elastic IP exclusivo (EIP), que serve como o endpoint para a resolução de DNS.

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: o FQDN do aplicativo é o domínio primário usado pelos usuários finais para acessar a interface do aplicativo. Esse valor corresponde ao campo fqdn em input.json. Para obter detalhes, consulte Configurações Ativas/Passivas.
• FQDNs específicos de cluster: além do FQDN do aplicativo principal, cada cluster requer seu próprio FQDN para ferramentas administrativas e de monitoramento. Esse valor é definido no campo cluster_fqdn no input.json de cada cluster. Para obter detalhes, consulte Configurações Ativas/Passivas.
• 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 clusters Ativo (primário) e Passivo (secundário).

    Todos os subdomínios são direcionados para o mesmo IP elástico (EIP) 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 apropriado 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)*