Visão geral

Topologias de implantação Ativa/Passiva e Ativa/Ativa no Automation Suite, incluindo diagramas e requisitos de hardware.

Diagramas

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

O seguinte diagrama descreve uma implantação Ativo/Ativo regular do Automation Suite:

Requisitos

Os componentes de hardware a seguir são necessários para implantações Ativo/Passivo e Ativo/Ativo.

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 Ativo/Passivo ou Ativo/Ativo, use /orchestrator_/api/status como endpoint 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. Para obter detalhes, consulte Configuração do balanceador de carga.

Nó

Cada local deve ter pelo menos três servidores; os nós de agentes são opcionais. O número exato de máquinas depende do tamanho da máquina e dos requisitos gerais de capacidade. Você não precisa levar o mesmo conjunto de nós para cada cluster.

Para configurações Ativo/Ativo, o cluster secundário pode ser menor, pois pode ser que você instale apenas alguns produtos. 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 com um servidor SQL primário no Site 1 e pelo menos um servidor SQL secundário 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

O PostgreSQL é usado apenas pelo Process Mining. O Process Mining não é compatível no modo Ativo/Passivo ou Ativo/Ativo, portanto, seu banco de dados Airflow não precisa ser persistente no local secundário. Nenhuma replicação do PostgreSQL entre locais é necessária para a recuperação de desastres.

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.

High Availability Add-on

Para Ativo/Ativo, o High Availability Add-on deve ser externo ao Automation Suite e instalado em máquinas separadas. Um mínimo de três nós é necessário para cada instância do High Availability Add-on em ambos os data centers, configurado em diferentes clusters e sincronizado por meio da replicação do CRDB. Para instalar o High Availability Add-on, consulte o Guia de instalação do High Availability Add-on.

Para Ativo/Passivo, o High Availability Add-on é instalado dentro do cluster do Automation Suite. Você ainda deve habilitá-lo em ambos os clusters fornecendo a licença do HAA. Para obter detalhes, consulte Habilitação do High Availability Add-on do Redis para o cluster.

Elasticsearch (opcional)

O Elasticsearch é necessário para enviar os logs do robô. Você pode configurar a replicação entre sites do Elasticsearch conforme descrito pelo Elasticsearch.