Visão geral

Visão geral das arquiteturas de implantação em vários locais Ativa/Passiva e Ativa/Ativa, requisitos de hardware e roteamento DNS no 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ó

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 mais 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.

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.

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: o FQDN do aplicativo é o domínio primário usado por usuários finais para acessar a interface do aplicativo. Este valor corresponde ao campo fqdn em input.json. Para obter mais detalhes, consulte Configurações Ativas/Passivas.
• FQDNs específicos do 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 em input.json de cada cluster. Para obter mais 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 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)*