- Visão geral
- Requisitos
- Recomendado: modelos de implantação
- Manual: preparando a instalação
- Manual: preparando a instalação
- Etapa 1: Configuração do registro compatível com OCI para instalações offline
- Etapa 2: configuração do objectstore externo
- Etapa 3: configuração do High Availability Add-on
- Etapa 4: configuração do Microsoft SQL Server
- Etapa 5: configuração do balanceador de carga
- Etapa 5: configuração do DNS
- Etapa 7: configuração dos ajustes do nível do kernel e do sistema operacional
- Etapa 8: configuração dos discos
- Etapa 9: configuração das portas do nó
- Etapa 10: aplicação de configurações diversas
- Etapa 12: validação e instalação dos pacotes RPM necessários
- Etapa 13: geração de cluster_config.json
- Configuração de Certificados
- Configuração do Banco de Dados
- Configuração externa do Objectstore
- Configuração de URL pré-assinada
- Configuração de registro externo compatível com OCI
- Disaster Recovery: configurações Ativo/Passivo e Ativo/Ativo
- Configuração do High Availability Add-on
- Configuração específica do Orchestrator
- Configuração específica do Insights
- Process Mining-specific configuration
- Configuração específica do Document Understanding
- Automation Suite Robots-specific configuration
- Configuração do monitoramento
- Opcional: configuração do servidor proxy
- Opcional: habilitação da resiliência a falhas zonais em um cluster de produção pronto para alta disponibilidade de vários nós
- Opcional: transmitindo resolv.conf personalizado
- Optional: Increasing fault tolerance
- Parâmetros do install-uipath.sh
- Adicionando um nó de agente dedicado com suporte a GPU
- Adição de um nó de agente dedicado ao Task Mining
- Conexão do aplicativo Task Mining
- Adicionando um nó de agente dedicado para robôs do Automation Suite
- Etapa 15: configuração do registro temporário do Docker para instalações offline
- Etapa 16: validação dos pré-requisitos para a instalação
- Manual: realizando a instalação
- Pós-instalação
- Administração de cluster
- Gerenciando produtos
- Introdução ao portal de administração do cluster
- Migrating objectstore from persistent volume to raw disks
- Migração do High Availability Add-on no cluster para externo
- Migrating data between objectstores
- Migrating in-cluster objectstore to external objectstore
- Mudança para o cluster secundário manualmente em uma configuração Ativo/Passivo
- Disaster Recovery: executando operações pós-instalação
- Convertendo uma instalação existente para configuração multi-local
- Diretrizes sobre atualização de uma implantação Ativo/Passivo ou Ativo/Ativo
- Diretrizes sobre backup e restauração de uma implantação Ativo/Passivo ou Ativo/Ativo
- Redirecting traffic for the unsupported services to the primary cluster
- Monitoramento e alertas
- Migração e atualização
- Etapa 1: mover os dados da organização do Identity, de independente para o Automation Suite
- Etapa 2: restauração do banco de dados de produtos independente
- Etapa 3: backup do banco de dados da plataforma no Automation Suite
- Etapa 4: mesclando organizações no Automation Suite
- Etapa 5: atualização das strings de conexão do produto migradas
- Etapa 6: migração do Orchestrator independente
- Etapa 7: migração do Insights independente
- Etapa 8: exclusão do tenant padrão
- B) Migração de um único tenant
- Migração do Automation Suite no Linux para o Automation Suite no EKS/AKS
- Atualizando o Automação Suite
- Download dos pacotes de instalação e obtenção de todos os arquivos no primeiro nó do servidor
- Recuperação da mais recente configuração aplicada do cluster
- Atualização da configuração de cluster
- Configuração do registro compatível com OCI para instalações offline
- Migração para um registro externo compatível com OCI
- Execução da atualização
- Realização de operações pós-atualização
- Configuração específica do produto
- Uso da ferramenta de configuração do Orchestrator
- Configuração de parâmetros do Orchestrator
- Configurações de aplicativo do Orchestrator
- Configuração do AppSettings
- Configuração do tamanho máximo da solicitação
- Substituição da configuração de armazenamento no nível do cluster
- Configuração dos repositórios de credenciais
- Configuração da chave de criptografia por tenant
- Melhores práticas e manutenção
- Solução de problemas
- Como solucionar problemas dos serviços durante a instalação
- Como desinstalar o cluster
- Como limpar os artefatos offline para melhorar o espaço em disco
- Como limpar os dados do Redis
- Como habilitar o registro em log do Istio
- Como limpar logs manualmente
- Como limpar logs antigos armazenados no pacote do sf-logs
- Como desabilitar os logs de streaming para o AI Center
- Como depurar instalações do Automation Suite com falha
- Como excluir imagens do instalador antigo após a atualização
- Como desabilitar o descarregamento de soma de verificação NIC
- Como atualizar do Automation Suite 2022.10.10 e 2022.4.11 para 2023.10.2
- Como definir manualmente o nível de log do ArgoCD como Info
- Não é possível executar uma instalação offline no SO RHEL 8.4
- Erro ao baixar o pacote
- A instalação offline falha devido a um binário ausente
- Problema de certificado na instalação offline
- First installation fails during Longhorn setup
- Erro de validação da string de conexão ao SQL
- Verificação de pré-requisito para o módulo iscsid do selinux falha
- Azure disk not marked as SSD
- Falha após a atualização do certificado
- Antivírus causa problemas de instalação
- Automation Suite not working after OS upgrade
- O Automation Suite requer que backlog_wait_time seja definido como 0
- Não é possível montar o volume devido a não estar pronto para cargas de trabalho
- Cluster unhealthy after automated upgrade from 2021.10
- Upgrade fails due to unhealthy Ceph
- RKE2 não é iniciado devido a um problema de espaço
- O volume não pode ser montado e permanece no estado de loop anexar/desanexar
- A atualização falha devido a objetos clássicos no banco de dados do Orchestrator
- Um cluster do Ceph foi encontrado em um estado degradado após atualização lado a lado
- Um componente sem integridade do Insights causa uma falha na migração
- A atualização do serviço falha para o Apps
- Tempos limite de atualização no local
- Migração de registro do Docker presa no estágio de exclusão do PVC
- Falha no provisionamento do AI Center após a atualização para a 2023.10
- Falha de atualização em ambientes offline
- Configurando um intervalo de tempo limite para os portais de gerenciamento
- Autenticação não funciona após migração
- kinit: não é possível encontrar o KDC para o realm <AD Domain> ao obter credenciais iniciais
- kinit: o Keytab não contém chaves adequadas para *** ao obter credenciais iniciais
- Falha na operação GSSAPI devido a código de status inválido
- Alarme recebido para trabalho com falha do Kerberos-tgt-update
- Provedor de SSPI: servidor não encontrado no banco de dados Kerberos
- Falha de login para usuário do AD devido a conta desabilitada
- ArgoCD login failed
- Atualizar as conexões de diretório subjacentes
- Falha ao obter a imagem do sandbox
- Os pods não são exibidos na UI do ArgoCD
- Falha de teste do Redis
- O servidor RKE2 falha ao iniciar
- Segredo não encontrado no namespace da UiPath
- O ArgoCD entra em estado Em andamento após a primeira instalação
- Pods de MongoDB em CrashLoopBackOff ou provisionamento de PVC pendente após exclusão
- Unhealthy services after cluster restore or rollback
- Pods presos em Init:0/X
- Métricas Ceph-rook ausentes nos painéis de monitoramento
- O Document Understanding não está no menu de navegação esquerdo do Automation Suite
- Status de Falha ao criar uma sessão de rotulagem de dados
- Status de Falha ao tentar implantar uma habilidade de ML
- Trabalho de migração falha no ArgoCD
- Reconhecimento de escrita com o Extrator de formulários inteligente não está funcionando
- Execução da ferramenta de diagnóstico
- Usando a ferramenta de pacote de suporte do Automation Suite
- Exploração de logs
Arquitetura de implantação
Para saber mais sobre os principais conceitos usados em uma implantação do Automation Suite, consulte o Glossário.
O Automation Suite oferece suporte aos dois modos de implantação a seguir:
Modo de implantação |
Description |
---|---|
Nó único — avaliação |
Com suporte para cenários de avaliação e demonstração. |
Vários nós - produção, habilitado para HA |
Suportado para uso em produção. Você pode executar configurações adicionais pós-implantação para obter recursos completos de HA. |
Consulte Casos de uso aceitos para instalações de nó único de múltiplos nós para mais detalhes sobre como escolher o modo de implantação mais adequado às suas necessidades.
Esta página oferece informações sobre a arquitetura do Automation Suite e descreve os componentes agrupados no instalador.
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 análise do Task Mining, pipelines do Document Understanding que exigem capacidade de GPU ou Automation Suite Robots. No entanto, os principais serviços do Task Mining, Document Understanding ou Automation Suite Robots ainda são executados no servidor ou nos nós dos agentes. Os nós de agentes especializados não hospedam nenhum produto UiPath® ou componentes compartilhados.
Uma implantação de avaliação de nó único refere-se, aqui, a um nó de servidor único. Isso não significa uma implantação de todo o Automation Suite em uma única máquina. Talvez seja necessário adicionar agentes adicionais ou nós de agentes especializados se todo o conjunto de produtos não puder caber em um único nó de servidor ou se você desejar executar tarefas especiais, como análise de Task Mining e pipelines de Document Understanding, que exigem recursos de GPU.
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 conjunto de automação ainda esteja disponível para executar fluxos de trabalho críticos de negócios. O número de nós de agente é opcional e é baseado no uso real.
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 mais 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.
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 mais 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.
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 carregamento de binários (hidratação) para o registro introduz uma carga adicional de requisitos de hardware mais altos, maior complexidade de instalação em relação a processos adicionais e tempo de instalação em comparação com a implantação online. A instalação offline aumenta não apenas a complexidade durante a instalação, mas também as operações de gerenciamento de cluster, como manutenção de máquina, recuperação de desastres, 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.
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 armazenamento de objeto/blob compatível com Amazon S3 sobre volumes persistentes criados pelo Longhorn. 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 |
Required |
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 |
Required |
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 |
Required |
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 | Necessá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. |
1 Instalada apenas durante o backup e a restauração.