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.

Latência

A latência tem importância crucial no projeto de um modelo Ativo/Ativo. Ele denota o tempo de ida e volta (RTT) entre os dois clusters do Automation Suite. Um nível de latência mínimo entre os dois sites é ideal, pois reduz muito o risco de perda de dados durante uma interrupção. O RTT deve ficar abaixo de um limite de 10 ms.

Você deve testar com rigor o RTT antes de passar para o estágio de produção, devido ao seu efeito direto nas métricas de desempenho. Se a latência exceder o benchmark de 10 ms entre os dois sites, recomendamos considerar uma configuração Ativo/Passivo em vez de uma configuração Ativo/Ativo.

Observação:

Qualquer componente que necessite de sincronização deve ter um RTT inferior a 10 ms. Isso inclui servidores SQL, HAA, objectstore, etc.

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

Para desbloquear todo o potencial de ambos os clusters, é crucial configurar o Traffic Manager adequadamente. A configuração deve facilitar de forma ideal a distribuição de tráfego para ambos os clusters. Essa estratégia não só garante uma distribuição de carga equilibrada, mas também protege a continuidade dos negócios, mitigando qualquer possível disrupção se algum dos sites sofrer um desligamento completo.

Disponibilidade de nós

No caso de um desastre que faça com que um site fique totalmente não operacional, o outro site deve ter capacidade suficiente para garantir que a automação de negócios não seja impactada. A incapacidade do local em funcionamento pode afetar negativamente a execução dos negócios e potencialmente ocasionar problemas operacionais significativos.

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 um dos clusters deve ser executada no outro cluster a tempo de reduzir o desvio. Isso garante que ambos os clusters possuam configurações semelhantes e que nenhum esforço adicional seja necessário durante a 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

Nem toda recuperação de desastres fornece imunidade total à perda de dados. No entanto, você pode implantar uma estratégia de backup regular e periódica para minimizar o impacto do desastre na recuperação de dados. Para detalhes, consulte Backup e restauração do cluster.