- Visão geral
- Requisitos
- Instalação
- Q&A: Deployment templates
- Configuração das máquinas
- Configurando o objectstore externo
- Configurando um registro externo do Docker
- Configuração do balanceador de carga
- Configuração do DNS
- Como configurar o Microsoft SQL Server
- Configuração dos certificados
- Instalação online de produção pronta para alta disponibilidade de vários nós
- Instalação offline de produção pronta para alta disponibilidade de vários nós
- Disaster Recovery - Instalando o cluster secundário
- Baixando os pacotes de instalação
- Parâmetros do install-uipath.sh
- Como habilitar o High Availability Add-on do Redis para o cluster
- Arquivo de configuração do Document Understanding
- 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
- Pós-instalação
- Administração de cluster
- Monitoramento e alertas
- Migração e atualização
- Opções de migraçã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 Insights independente
- Etapa 7: exclusão do tenant padrão
- B) Migração de um único tenant
- Configuração específica do produto
- 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 limpar automaticamente instantâneos do Longhorn
- Como desabilitar o descarregamento de soma de verificação NIC
- 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ó da GPU afetado por indisponibilidade de recurso
- Não é possível montar o volume devido a não estar pronto para cargas de trabalho
- Falha ao carregar ou baixar dados no objectstore
- PVC resize does not heal Ceph
- Falha no redimensionamento do PVC
- Falha no redimensionamento do PVC do Objectstore
- Pod do Rook Ceph ou Looker travado no estado Init
- Erro de anexo de volume StatefulSet
- Falha ao criar volumes persistentes
- Patch de reclamação de armazenamento
- Falha de backup devido ao erro TooManySnapshots
- Todas as réplicas do Longhorn estão com falha
- Configurando um intervalo de tempo limite para os portais de gerenciamento
- Atualizar as conexões de diretório subjacentes
- 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
- 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
- Problemas de acesso à conta somente leitura do ArgoCD
- 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
- Prometheus no estado CrashloopBackoff com erro de falta de memória (OOM)
- 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
- Usando a ferramenta de diagnóstico do Automation Suite
- Usando a ferramenta de pacote de suporte do Automation Suite
- Exploração de logs
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.
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.
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.
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.
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.
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.
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.
Você pode reduzir o tempo de recuperação configurando o Gerenciador de Tráfego para sempre rotear o tráfego para o cluster primário quando disponível. O redirecionamento para o cluster secundário deve ser feito somente quando o cluster primário estiver inativo. Isso garante que a troca de tráfego seja automática e reduz o tempo para uma troca manual. Você pode usar os pontos de extremidade de integridade de ambos os clusters para fazer isso.
Se todos os nós no cluster secundário estiverem em execução, você poderá economizar tempo ativando os nós e aguardando a ativação do cluster. No entanto, isso pode aumentar o custo de sua infraestrutura em quase duas vezes.
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.
Como as implantações do Automation Suite em vários locais consistem em dois clusters distintos, qualquer operação executada em qualquer cluster deve ser executada no outro cluster a tempo de reduzir o desvio. Isso garante que ambos os clusters possuam configurações semelhantes e nenhum esforço adicional seja necessário durante a fase 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.
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.
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.