Execução de uma atualização lado a lado

Execute uma atualização lado a lado para o Automation Suite usando um ambiente paralelo para alternar o tráfego com segurança para um novo cluster.

A atualização lado a lado do Automation Suite permite que você execute operações de atualização com segurança usando um ambiente paralelo, em vez de atualizar no local.

Este método permite que os administradores alterem o tráfego do cluster antigo do Automation Suite (por exemplo, a implantação azul) para o novo cluster do Automation Suite (por exemplo, a implantação verde) após verificar a nova implantação. Se você detectar um problema, poderá reverter para a implantação antiga rapidamente.

Ao realizar uma atualização lado a lado, os dois clusters paralelos compartilham uma única licença.

Requisitos

• Se o AI Center estiver habilitado, certifique-se de atender aos requisitos do CUDA.
• Requisitos de hardware, dependendo do modelo que você escolheu:
  • Atualização lado a lado (cluster de destino de tamanho idêntico) - Tanto o ambiente de origem quanto o de destino devem atender aos mesmos requisitos de hardware e software.
  • Atualização lado a lado (início de nó único) - Você pode configurar um cluster de destino de nó único e, em seguida, dimensioná-lo. Certifique-se de atender aos requisitos de hardware sugeridos pela Calculadora de dimensionamento de instalação do Automation Suite com base em sua seleção de produtos e detalhes de uso.
• Requisitos de software: tanto o ambiente de origem quanto o de destino devem atender aos mesmos requisitos de hardware e software.

Migração de dados e responsabilidades

A tabela a seguir descreve o status da migração de dados e as responsabilidades de cada componente durante a atualização.

Dados	Status	Responsabilidade
Sql	Mantido	Cliente
FQDN	Mantido; opcional Você deve escolher um novo FQDN para o novo cluster. Opcionalmente, você pode reverter para o FQDN anterior se necessário.	Cliente
Pacotes sob demanda	Não migrado Execute um script para ver quais pacotes estão no cluster. É necessária a geração manual.	Cliente
Certificados	Não migrado Você deve trazer certificados como parte da nova instalação do cluster.	Cliente
Configuração de cluster	Não migrado Você deve gerar cluster_config.json a partir do cluster de origem original para mapear os mesmos serviços para a nova instalação do cluster.	Cliente
Alertas e painéis personalizados criados pelos usuários	Não migrado Você deve reconfigurar os alertas e painéis personalizados após a atualização.	Cliente
Logs do aplicativo/configuração de streaming do Prometheus criada por usuários	Não migrado Você deve reconfigurar o log do aplicativo e o streaming do Prometheus.	Cliente
Cargas de trabalho dinâmicas	Depende do aplicativo Os trabalhos de treinamento do AI Center são perdidos; As habilidades são mantidas.	Habilidades (o script precisava ser executado após a atualização): UiPath® / Trabalhos de treinamento: cliente
Armazenamento de objeto	Mantido	Objectstore no cluster (Ceph): UiPath® / Objectstore externo: Cliente
Insights	Mantido	UiPath®
Dados do MongoDB	Mantido Os dados do MongoDB são movidos para o SQL de destino.	UiPath®
RabbitMQ	Não é necessário	UiPath®
Monitoramento (dados)	Não é necessário Os dados de monitoramento não se aplicam ao novo cluster. Se você não usar os componentes de monitoramento integrados, você deve configurar componentes de monitoramento externos após a atualização da migração.	N/A
Registro do Docker	Não é necessário Você deve instalar um registro do docker no cluster ou trazer um registro do docker externo.	N/A

Visão geral do processo

Para realizar uma atualização lado a lado, conclua as seguintes etapas:

1. Prepare o novo cluster:

   • Prepare o arquivo cluster_config.json.
   • Instale seu novo cluster (infraestrutura e objectstore no cluster (se aplicável) apenas).
   • Configure os certificados de CA adicionais.

2. Migre os dados para o novo cluster:

   • Preencha o registro do docker com as informações das imagens de atualização offline.
   • Coloque o cluster no modo de manutenção.
   • Clone seus bancos de dados do cluster de origem.
   • Execute o script de migração de dados no cluster de origem.
   • Se você configurou um objectstore externo, clone os buckets do objectstore.

3. Conclua a atualização:

   • Edite o arquivo cluster_config.json para apontar para os bancos de dados e buckets clonados.
   • Execute o instalador no cluster de destino.
   • Se você não forneceu os certificados durante a instalação, atualize-os após a instalação.
   • Valide se o cluster de destino funciona conforme o esperado.
   • Se você optar pela atualização lado a lado (cluster de destino de tamanho idêntico), poderá atualizar opcionalmente o FQDN do cluster de destino para corresponder ao FQDN do cluster de origem ou usar um novo FQDN. Se você optar pela atualização lado a lado (início único do nó), você pode atualizar o FQDN posteriormente.
   • Habilite o backup no cluster de destino.

4. Dimensione o cluster de destino - aplicável apenas se você optou pela atualização lado a lado (início único do nó):

   • Faça o backup do cluster de origem (recomendado).
   • Adicione nós de servidor e agente semelhantes ao seu cluster de origem.
   • Edite o arquivo cluster_config.json .
   • Execute novamente o instalador para escalonar o cluster na configuração de alta disponibilidade.
   • Opcionalmente, atualize o FQDN do cluster de destino para corresponder ao FQDN do cluster de origem ou use um novo FQDN.

Modelos de atualização lado a lado

Oferecemos dois modelos para atualizações lado a lado:

1. Atualização lado a lado (cluster de destino de tamanho idêntico):
   • Requer que o cluster de destino tenha os mesmos recursos de hardware que o cluster de origem.
   • Pronto para o tráfego uma vez:
     • A migração de dados foi concluída.
     • As verificações de integridade foram bem-sucedidas.
2. Atualização lado a lado (início de nó único):
   • Inicia com uma configuração de nó único e, em seguida, escala até uma configuração de HA. Isso reduz os requisitos iniciais de hardware necessários para atualização lado a lado.
   • O hardware para a configuração de nó único deve atender às recomendações da Calculadora de capacidade para a configuração de nó único.
   • Para dimensionamento:
     • Os nós do cluster de origem podem ser descontinuados e adicionados ao cluster de destino.
   • Pronto para o tráfego uma vez:
     • A migração de dados foi concluída.
     • O cluster é dimensionado para vários nós.
     • As verificações de integridade foram bem-sucedidas.

Você pode encontrar uma comparação entre os dois modelos na tabela a seguir:

	Atualização lado a lado (cluster de destino de tamanho idêntico)	Atualização lado a lado (início de nó único)
Requisitos de Hardware	Requer hardware idêntico para clusters de origem e destino.	Começa com um hardware mínimo, escalando conforme necessário.
Downtime	Tempo de inatividade mínimo devido ao ambiente de destino totalmente redundante.	Maior tempo de inatividade devido a operações de dimensionamento dos nós.
Impacto no cluster de origem	Nenhum impacto.	Os nós de origem podem ser descontinuados e associados ao cluster de destino.
Processo de reversão	Reversão simples, pois a origem permanece intocada.	Se a operação de escalamento falhar no cluster de destino, a reversão envolverá a reintegração dos nós ao cluster de origem.
Impacto do custo	Custos mais altos devido à infraestrutura duplicada.	Custos mais baixos com requisitos iniciais de hardware reduzidos.