- Visão geral
- Glossário
- Produtos do Automation Suite
- Dependências entre produtos
- Supported profile use cases
- Consideração de arquitetura e design de vários nós
- Comparação de funcionalidade de implantação cruzada
- Segurança e conformidade
- Visão geral dos certificados
- 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 discos
- Etapa 8: ajuste das configurações no nível do kernel e do sistema operacional
- 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
- Amostra Cluster_config.json
- Configuração geral
- Profile configuration
- Configuração de Certificados
- Configuração do Banco de Dados
- Configuração externa do Objectstore
- Configuração de URL pré-assinada
- Configuração do ArgoCD
- 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 específica do AI Center
- 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
- 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
- Migração para um registro externo compatível com OCI
- 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
- Monitoramento e alertas
- Migração e atualização
- Migrating between Automation Suite clusters
- 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
- Execução da atualização
- Realização de operações pós-atualização
- Aplicação de patch
- Configuração específica do produto
- Configuração de parâmetros 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 do NLog
- Salvando logs do robô no Elasticsearch
- Configuração dos repositórios de credenciais
- Configuração da chave de criptografia por tenant
- Limpeza do banco de dados do Orchestrator
- 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 bucket 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 do TX
- Como definir manualmente o nível de log do ArgoCD como Info
- Como expandir o armazenamento do AI Center
- Como gerar o pull_secret_value codificado para registros externos
- Como lidar com cifras fracas no TLS 1.2
- How to check the TLS version
- 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
- 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
- Falha na coleta de logs do pacote de suporte
- A atualização de nó único falha no estágio de malha
- 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
- AI Center provisioning failure after upgrading to 2023.10 or later
- Falha de atualização em ambientes offline
- A validação de SQL falha durante a atualização
- pod snapshot-controller-crds no estado CrashLoopBackOff após a atualização
- 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
- 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 de alta disponibilidade com o Process Mining
- Falha na ingestão do Process Mining ao fazer logon usando o Kerberos
- Após a recuperação de desastres, o Dapr não está funcionando corretamente para Process Mining e Task Mining
- Não é possível conectar-se ao banco de dados AutomationSuite_ProcessMining_Warehouse usando uma string de conexão em formato pyodbc.
- A instalação do Airflow falha com sqlalchemy.exc.ArgumentError: não foi possível analisar o URL rfc1738 da string ''
- Como adicionar uma regra de tabela de IP para usar a porta 1433 do SQL Server
- O certificado do Automation Suite não é confiável para o servidor em que o CData Sync está sendo executado
- Execução da ferramenta de diagnóstico
- Using the Automation Suite support bundle
- Exploração de logs
Consideração de arquitetura e design de vários nós
O seguinte diagrama de arquitetura descreve uma implantação do Automation Suite no Linux com o Kubernetes instalado em seis máquinas, um balanceador de carga e armazenamento de dados. Há vários tipos de máquina: três nós do servidor, dois nós de agentes e um nó de agentes especializados.
etcd, que faz parte do Plano de controle do Kubernetes. Para obter mais detalhes, consulte a documentação do etcd. Pelo mesmo motivo, a maioria dos nós do servidor deve estar disponível a qualquer momento para manter o cluster íntegro.
Esses nós também hospedam os componentes que exigem armazenamento de dados nos nós, como Prometheus, Objectstore Ceph no cluster, UiPath Insights e registro do Docker no cluster.
Os nós de agentes às vezes são chamados de nós de trabalho. O objetivo desses nós é hospedar serviços da UiPath® e outros recursos de suíte compartilhados.Como não há disco de dados conectado a esses nós, eles não podem hospedar os componentes que exigem armazenamento em disco.
Os nós de agentes não impõem nenhuma restrição no número de nós que devem estar disponíveis a qualquer momento. Enquanto o cluster resultante tiver capacidade suficiente para hospedar todos os pods dos nós perdidos, o cluster funcionará conforme o esperado, sem qualquer interrupção.
Esses nós são os nós de agentes especiais dedicados a tarefas especiais, como o nó do Task Mining para análise, nó do Automation Suite Robots para execução de UiPath® Robots e o nó da GPU para o modelo do Document Understanding.Você não pode hospedar outros serviços da UiPath® nesses nós.
O balanceador de carga, que é instalado fora do Automation Suite, atua como um entry point para acessar aplicativos hospedados no cluster do Automation Suite. O balanceador de carga é necessário para enfrentar a tolerância a falhas de nós. Todos os nós do servidor precisam estar configurados no balanceador de carga, mas os nós de agentes também podem ser configurados. No entanto, os nós de agentes especializados não precisam.
Quando os UiPath Robots tentam acessar o Orchestrator, a chamada chega no balanceador de carga e, em seguida, é passada para qualquer um dos nós disponíveis. Cada nó também hospeda o componente de rede chamado Istio, que é um service mesh que também atua como um balanceador de carga. Quando a chamada é recebida pelo Istio que está sendo executado no nó, ele tenta localizar a instância do Orchestrator em todo o cluster. Depois que for encontrada, ele redirecionará a chamada para essa instância.
Isso depende inteiramente de você preferir mais máquinas menores ou menos máquinas maiores, com ambas as opções tendo seus próprios prós e contras. Um número maior de máquinas menores fornece melhor resiliência a tolerância a falhas de nós em comparação com um número menor de máquinas maiores. Ao mesmo tempo, isso também introduz uma sobrecarga de gerenciamento adicional.
Por exemplo, se seu cluster do Automation Suite exigir 96 vCPU, você pode optar por uma das seguintes opções:
-
Opção 1: seis máquinas de 16 vCPU cada.
-
Impacto: a perda de uma máquina reduz a capacidade do cluster em apenas 16 vCPU; portanto, isso só afeta os serviços se o cluster resultante não tiver capacidade de hospedar todos os pods. No entanto, o gerenciamento de seis máquinas implica um esforço maior.
-
-
Opção 2: três máquinas de 32 vCPU cada
-
Impacto: a perda de uma máquina reduz a capacidade do cluster em 32 vCPU, o que tem um grande impacto no Automation Suite. No entanto, o gerenciamento de três máquinas implica um esforço menor.
-
Para concluir, o design da implantação depende do objetivo. Se o objetivo for uma melhor tolerância a falhas, então mais máquinas menores serão a melhor escolha. No entanto, se o objetivo for menos sobrecarga de gerenciamento, o número menor de máquinas maiores deve ser a escolha.
Sua opção por todos os nós do servidor em vez de nós de agentes depende de seu RTO ou RPO.
Por exemplo, digamos que seu Automation Suite precise de 80 vCPU. Você pode atingir isso da seguinte forma:
-
Opção 1: cinco máquinas de servidor com 16 vCPU cada. Aqui, você pode perder no máximo dois nós do servidor.
-
Recomendado se o objetivo for resiliência à perda de dados. Mesmo que dois nós do servidor sejam perdidos, os dados permanecerão intactos e poderão ser recriados a partir das réplicas restantes.
-
-
Opção 2: três nós de servidores e dois nós de agentes com 16 vCPU cada. Aqui, você pode perder um nó do servidor e ambos os nós de agentes; portanto, um total de três máquinas.
-
Recomendado se o objetivo for resiliência à disponibilidade dos nós. Mesmo sem três máquinas, o cluster ainda estará disponível com capacidade limitada, e depois que os nós forem retomados, todo o cluster será recuperado. No entanto, essa configuração é mais propensa à perda de dados devido ao armazenamento conectado aos nós separados. Se dois nós do servidor forem totalmente perdidos, pode ser difícil recriar os dados novamente sem restaurá-los a partir do backup.
-
