Arquitetura de implantação

Modos de implantação compatíveis, conceitos de arquitetura e opções de topologia de nó para o Automation Suite.

Terminologia

Para obter detalhes sobre os conceitos principais usados em uma implantação do Automation Suite, consulte Glossário.

Modos de implantação e casos de uso

O Automation Suite oferece suporte aos seguintes modos de implantação:

Modo de implantação	Description
Nó único	Compatível com cenários de avaliação e demonstração. Para obter detalhes, consulte Implantação de avaliação de nó único. Também pode ser usado na produção sob condições específicas. Para obter detalhes, consulte Implantação de produção de nó único.
Vários Nós	Suportado para uso em produção. Os seguintes modos estão disponíveis: - Modo Lite: implantação leve com configuração de HA seletiva. Para obter detalhes, consulte Implantação do modo Lite. - Modo HA: HA totalmente habilitado. Para obter detalhes, consulte Implantação de produção pronta para HA de vários nós.

Observação:

As implantações de nó único podem ser convertidas em configurações de alta disponibilidade (HA) adicionando o hardware adicional necessário para implantações de vários nós. Para obter detalhes, consulte a página Escalando uma implantação de nó único (avaliação) para uma implantação de vários nós (HA) .

O Automation Suite usa uma arquitetura nativa de nuvem baseada em Kubernetes. Ele fornece todos os benefícios em escala, gerenciamento automático de recursos e confiabilidade que vêm com o Kubernetes.

Para oferecer esses benefícios, o design do Kubernetes é baseado nos seguintes aspectos fundamentais:

• Executando em um número ímpar de várias máquinas (3, 5, 7, etc.);
• Usando o princípio de quorum para lidar com falhas de nós independentes e corrupção de dados. Para um cluster de N máquinas, desde que ainda haja um número de N/2 + 1 máquinas que representem o quorum, o cluster é funcional e pode se recuperar normalmente sem falhas observadas.

Arquitetura de implantação

Esta página oferece informações sobre a arquitetura do Automation Suite e descreve os componentes agrupados no instalador.

Tipos de nó

O diagrama a seguir mostra os tipos de nó disponíveis em uma implantação do Automation Suite.

Um nó de servidor hospeda serviços de gerenciamento de cluster (plano de controle) que executam importantes operações de cluster, como orquestração de carga de trabalho, gerenciamento de estado de cluster, balanceamento de carga de solicitações de entrada etc. O Kubernetes também pode executar alguns dos produtos UiPath® e componentes compartilhados com base na disponibilidade de recursos subjacentes.

Um nó de agente é responsável apenas por executar os produtos UiPath® e componentes compartilhados.

Um nó de agente especializado executa cargas de trabalho especiais, como pipelines do Document Understanding que exigem capacidade de GPU ou Automation Suite Robots. No entanto, os principais serviços do Document Understanding ou do Automation Suite Robots ainda são executados nos nós do servidor ou do agente. Os nós de agentes especializados não hospedam nenhum produto UiPath® ou componentes compartilhados.

Importante:

O Automation Suite não pode garantir qual produto UiPath é executado em cada nó. Isso é gerenciado exclusivamente pelo Kubernetes.

Implantação de avaliação de nó único

Uma implantação de avaliação de nó único aqui significa um nó de servidor único. Isso não implica na implantação de todo o Automation Suite em uma única máquina. Pode ser necessário adicionar nós de agente adicionais ou agentes especializados se todo o conjunto de produtos não couber em um único nó do servidor ou se você quiser executar tarefas especiais, como pipelines do Document Understanding, que exigem recursos de GPU.

O diagrama a seguir mostra a implantação de avaliação de nó único.

Implantação de produção de nó único

Uma implantação de nó único normalmente é usada para cenários de avaliação ou demonstração. Em casos limitados, ela também pode ser usada para produção, mas somente se todas as condições a seguir forem atendidas:

• Você deve comprar um pacote de suporte da UiPath.
• Você deve usar um objectstore externo. Para obter detalhes, consulte Configurar um objectstore externo.
• Você precisa habilitar o backup. Para detalhes, consulte Backup e restauração do cluster.
• Você deve configurar soluções de monitoramento compatíveis para habilitar a solução de problemas eficaz. Para obter detalhes, consulte Monitoramento do Automation Suite.

Mais tarde, você pode passar para uma implantação de vários nós adicionando novos nós de servidor ao cluster e convertendo a implantação para implantação de vários nós (HA). Para obter etapas detalhadas, consulte a página Escalonamento de uma implantação de nó único (avaliação) para uma página de implantação de vários nós (HA) .

Importante:

Essa configuração não fornece alta disponibilidade e deve ser considerada apenas quando uma configuração de vários nós não for possível. Uma implantação pronta para HA de vários nós continua sendo a opção recomendada de longo prazo.

Implantação de modo Lite

O modo Lite é uma implantação leve que exige menos de seus recursos de infraestrutura. Fornece flexibilidade com sua alta configurabilidade para serviços que exigem alta disponibilidade. Por padrão, a infraestrutura e os componentes compartilhados são implantados no modo de alta disponibilidade e todos os serviços estão no modo Lite (o escalonamento automático de pod horizontal é habilitado com um mínimo de uma réplica).

Você pode alternar serviços específicos para o modo HA. Você também tem a opção de executar configurações adicionais pós-implantação para obter recursos completos de HA.

Importante:

Você pode usar o modo Lite em produção, mas deve estar ciente das implicações e riscos de ter serviços sem alta disponibilidade habilitados.

Implantação de produção pronta para HA de vários nós

Uma implantação de produção pronta para HA de vários nós envolve 3 ou mais nós de servidor atrás de um balanceador de carga. Isso é para garantir que, em caso de desastre, quando qualquer um dos nós do servidor ficar inativo, o Automation Suite ainda esteja disponível para executar fluxos de trabalho críticos de negócios. Ele é compatível com alta disponibilidade no cluster e externa. O número de nós de agente é opcional e é baseado no uso real.

O diagrama a seguir mostra a implantação de produção pronta para alta disponibilidade de vários nós.

High Availability Add-on

Em uma configuração de vários nós, a Alta Disponibilidade (HA) é habilitada por padrão. No entanto, o cache de memória baseado em Redis usado pelos serviços de cluster está sendo executado em um único pod e representa um único ponto de falha. Para mitigar o impacto de uma falha ou reinicialização do nó de cache, você pode adquirir o High Availability Add-on (HAA), que permite a implantação redundante de vários pods do cache.

Para obter detalhes sobre como habilitar o HAA em uma configuração de vários nós, consulte Habilitação do High Availability Add-on para o cluster .

Implantação online

Uma implantação online significa que o Automation Suite requer acesso à Internet durante a instalação e o tempo de execução. Todos os produtos UiPath® e bibliotecas de suporte são hospedados no registro UiPath® ou em um armazenamento de terceiros de confiança da UiPath.

Você pode restringir o acesso à Internet com a ajuda de um firewall restrito ou de um servidor proxy, bloqueando todo o tráfego da Internet além do exigido pelo Automation Suite. Esse tipo de configuração também é conhecido como implantação semi-online. Para obter detalhes, consulte Como configurar o firewall e Como configurar o servidor proxy.

Esses tipos de implantações são mais fáceis, rápidos e exigem menos recursos de hardware para instalar e gerenciar em comparação com implantações offline.

O diagrama a seguir mostra o modelo de implantação online.

Implantação offline

Uma implantação offline (isolada) é uma configuração completamente isolada, sem acesso à Internet. Esse tipo de configuração requer a instalação de um registro adicional para armazenar todas as imagens e binários de contêiner dos produtos UiPath® que são enviados na forma de tarball.

O diagrama a seguir mostra o modelo de implantação isolado offline.

Observação:

O carregamento de binários (Hidratação) para o registro introduz requisitos de hardware adicionais e complexidade de instalação, aumentando o tempo necessário para realizar uma instalação em comparação com uma implantação online.

Uma instalação offline aumenta não apenas a complexidade durante a instalação, mas também as operações de gerenciamento do cluster, como manutenção da máquina, Disaster Recovery, atualização para versões mais recentes, aplicação de patches de segurança, etc.

Você não tem permissão para alterar o método de implantação após a instalação. Isso significa que você não pode alterar para o método offline se a instalação for feita online e vice-versa. É recomendável escolher sua estratégia de implantação após uma análise cuidadosa.

Arquitetura do Automation Suite

O diagrama a seguir descreve a arquitetura do Automation Suite. Observe que o registro do Docker e o Objectstore compatível com S3 também podem ser hospedados externamente.

A tabela a seguir lista os componentes de terceiros fornecidos com o Automation Suite:

Component	Opcional/Necessário	Description
RKE2	Required	Distribuição do Kubernetes, fornecido pelo Rancher. É a plataforma de orquestração de contêineres que executa todos os componentes e serviços de arquitetura.
Armazenamento de objeto CEPH	Opcional (se você tiver um objectstore externo)	Provedor de armazenamento de código aberto que expõe o armazenamento de objetos/blob compatível com o Amazon S3. Ele permite que os serviços usem o armazenamento de blob como funcionalidade para suas operações.
ArgoCD	Required	Ferramenta de CD declarativo de código aberto para Kubernetes. Ele segue o padrão GitOps de usar repositórios Git como fonte de comprovação para definir o estado do aplicativo desejado. Fornece recursos de gerenciamento do ciclo de vida do aplicativo (ALM) para componentes do Automation Suite e serviços UiPath® executados em um cluster Kubernetes.
Registro do Docker	Opcional (se você tiver um registro externo)	Ele fornece recursos de gerenciamento do ciclo de vida do aplicativo (ALM) para componentes do Automation Suite e serviços UiPath executados em um cluster Kubernetes.
Istio	Required	Malha de serviço de código aberto que fornece funcionalidades como entrada, roteamento de solicitação, monitoramento de tráfego etc., para os microsserviços executados dentro do cluster Kubernetes.
Prometheus	Opcional (você pode excluir componentes de monitoramento integrados)	Kit de ferramentas de monitoramento de sistema de código aberto para Kubernetes. Ele pode extrair ou aceitar métricas de componentes do Kubernetes, bem como cargas de trabalho em execução nos clusters e armazená-las no banco de dados de séries temporais.
Grafana	Opcional (você pode excluir componentes de monitoramento integrados)	Ferramenta de visualização de código aberto usada para consultar e visualizar dados armazenados no Prometheus. Você pode criar e enviar uma variedade de painéis para monitoramento de cluster e serviço.
AlertManager	Opcional (você pode excluir componentes de monitoramento integrados)	Ferramenta de código aberto que ajuda a lidar com alertas enviados por aplicativos cliente, como o servidor Prometheus. Ele é responsável por desduplicar, agrupar e roteá-los para as integrações corretas do receptor, como e-mail, PagerDuty ou OpsGenie.
Redis	Required	Redis Enterprise não HA (fragmento único) usado por alguns serviços UiPath® para obter a funcionalidade de cache centralizada.
FluentD e Fluentbit	Required	Solução de coleta de log confiável de código aberto. O operador de registro em log implanta e configura um processo em segundo plano em cada nó para coletar logs de contêiner e aplicativo do sistema de arquivos do nó.
Gatekeeper	Required	Ferramenta de código aberto que permite que um administrador do Kubernetes implemente políticas para garantir a conformidade e as melhores práticas em seu cluster.
velero	Obrigatório1	Ferramenta de código aberto que permite fazer backup instantâneos e restaurá-los.
Thanos	Required	Ferramenta de código aberto para enviar por push a matriz do Prometheus para um Objectstore para persistência.

¹ Instalada apenas durante o backup e a restauração.

Componentes externos

Você também precisa trazer alguns componentes externos, como balanceadores de carga externos e um servidor SQL. Observe que o pacote fornece alguns pontos de extensão.