Basic architecture considerations

Assim como em qualquer implantação em vários locais, as principais considerações de arquitetura para o Automation Suite incluem infraestrutura, latência, fonte de dados, gerenciamento, objetivo de tempo de recuperação, objetivo de ponto de recuperação etc.

Infraestrutura

Recomendamos usar o mesmo hardware para ambos os clusters. No entanto, o cluster do Automation Suite provavelmente funcionará com configurações de hardware semelhantes com pouca diferença. O hardware heterogêneo pode aumentar a complexidade e retardar a solução de problemas.

Gerenciamento

Os dois clusters do Automation Suite são independentes e não compartilham qualquer configuração. Portanto, qualquer atividade de gerenciamento ou manutenção deve ser feita individualmente nesses clusters. Por exemplo, você deve atualizar as strings de conexão SQL em ambos os clusters, configurar certificados separadamente, etc. Além disso, você deve monitorar os dois clusters de forma independente, atualizá-los individualmente, etc.

Origem de dados

O objectstore, combinado com o banco de dados SQL, forma o estado de um produto instalado no Automation Suite.

A configuração do SQL Server desempenha um papel vital em uma implantação em vários locais.Embora o SQL Server seja um componente externo ao Automation Suite, algumas etapas adicionais são necessárias para garantir HA verdadeiro ao trabalhar com o Automation Suite.

O SQL Server deve ser configurado no grupo de disponibilidade Always On ou em grupos de failover. Isso deve ser distribuído em ambos os locais para garantir Alta Disponibilidade precisa quando um local estiver inativo. Ambos os clusters devem usar o mesmo ponto de extremidade do receptor SQL na string de conexão. Além disso, é recomendável definir a propriedade MultiSubnetFailover=True na string de conexão quando o servidor/banco de dados SQL estiver distribuído em várias sub-redes.

Para obter mais detalhes, consulte Grupos de disponibilidade Always On e Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On.

O objectstore externo é imune a possíveis danos devido à falha do nó. A replicação de dados e a disaster recovery podem ser realizadas independentemente do Automation Suite. Como o SQL Server, o objectstore externo deve ser definido em uma configuração de Disaster Recovery de alta disponibilidade. A instância primária do objectstore está localizada fisicamente no datacenter primário e pelo menos uma instância secundária está localizada no datacenter secundário com sincronização de dados habilitada. Você pode configurar um balanceador de carga no objectstore para garantir que ambos os clusters do Automation Suite referem-se aos mesmos endpoints. Isso torna a implantação independente do modo como o objectstore é configurado internamente.

Importante:

Para AWS S3, o ponto de acesso multirregional não oferece suporte a todas as APIs s3 exigidas por todos os produtos em execução no Automation Suite. Para obter detalhes sobre a lista de APIs de suporte, consulte Usando pontos de acesso multirregionais com operações de API compatíveis.

Você pode criar dois buckets por produto/conjunto em ambas as regiões e habilitar a sincronização. O cluster do Automation Suite em execução na mesma região fará referência aos buckets na mesma região.

Objetivo de tempo de recuperação

A política da sua organização em relação ao RTO é vital ao projetar seu cluster do Automation Suite de vários locais. Para atingir o RTO desejado, leve em consideração os seguintes aspectos:

• Design do Gerenciador de Tráfego;
• Disponibilidade dos nós no cluster secundário/passivo;
• Disponibilidade de carga de trabalho dinâmica no cluster secundário; por exemplo, HabilidadeDeML;
• Gerenciamento de configurações.

Gerenciador de tráfego

Você pode reduzir o tempo de recuperação configurando o Gerenciador de Tráfego para sempre rotear o tráfego para o cluster primário quando disponível. O redirecionamento para o cluster secundário deve ser feito somente quando o cluster primário estiver inativo. Isso garante que a troca de tráfego seja automática e reduz o tempo para uma troca manual. Você pode usar os pontos de extremidade de integridade de ambos os clusters para fazer isso.

Disponibilidade de nós

Se todos os nós no cluster secundário estiverem em execução, você poderá economizar tempo ativando os nós e aguardando a ativação do cluster. No entanto, isso pode aumentar o custo de sua infraestrutura em quase duas vezes.

Disponibilidade de carga de trabalho dinâmica

Alguns produtos, como o AI Center, implantam as habilidades de ML dinamicamente em runtime. A implantação das habilidades em outro cluster é sempre assíncrona. Isso não pode garantir sua disponibilidade. Para garantir que sua solução de automação volte a ficar online no tempo desejado, você pode sincronizar periodicamente as habilidades em outro cluster.

Gerenciamento de configurações

Como as implantações do Automation Suite em vários locais consistem em dois clusters distintos, qualquer operação executada em qualquer cluster deve ser executada no outro cluster a tempo de reduzir o desvio. Isso garante que ambos os clusters possuam configurações semelhantes e nenhum esforço adicional seja necessário durante a fase de recuperação.

Objetivo do ponto de recuperação

A política da sua organização em relação ao Objetivo do Ponto de Recuperação (RPO) é vital ao projetar seu cluster do Automation Suite de vários locais. Para atingir o RPO desejado, você deve levar em consideração os seguintes aspectos:

• Sincronização de dados;
• Backup agendado.

Sincronização de dados

Quando gravados na fonte de dados primária, os dados também devem ser sincronizados com o cluster secundário. No entanto, há risco de perda de dados quando o datacenter está inoperante e os dados não são sincronizados. Configurações de rede exemplares, como alta largura de banda e baixa latência entre os dois centros de dados, podem acelerar a sincronização.

Backup agendado

Not all disaster recovery provides complete immunity to data loss. However, you can deploy a regular and periodic backup strategy to minimize the impact of the disaster on data recovery. For details, see Backing up and restoring the cluster.