Automation Suite
2021.10
falso
- Visão geral
- Requisitos
- Instalação
- Perguntas e respostas: modelos de implantação
- Baixando 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
- Conexão do aplicativo Task Mining
- Adição de um nó de agente dedicado ao Task Mining
- Pós-instalação
- Administração de cluster
- Monitoramento e alertas
- Migração e atualização
- Modo online de avaliação de nó único
- Modo offline de avaliação de nó único
- Modo de produção online pronto para alta disponibilidade de vários nós
- Modo de produção offline pronto para alta disponibilidade de vários nós
- Migrando o disco físico do Longhorn para o LVM
- Fazendo downgrade do Ceph de 16.2.6 para 15.2.9
- Opções de migraçã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 desativar o TLS 1.0 e 1.1
- Como habilitar o registro em log do Istio
- Como limpar logs manualmente
- Como limpar logs antigos armazenados no pacote do sf-logs
- Como depurar instalações do Automation Suite com falha
- Como desabilitar o descarregamento de soma de verificação NIC
- 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
- Falha após a atualização do certificado
- O Automation Suite requer que Backlog_wait_time seja definido como 1
- Não é possível fazer login após a migração
- Configurando um intervalo de tempo limite para os portais de gerenciamento
- Atualizar as conexões de diretório subjacentes
- Kinit: não é possível encontrar o KDC para domínio <AD Domain> ao obter as credenciais iniciais
- kinit: o Keytab não contém chaves adequadas para *** ao obter credenciais iniciais
- A operação do GSSAPI falhou com erro: um código de status inválido foi fornecido (as credenciais do cliente foram revogadas).
- Falha de login para o usuário <ADDOMAIN><aduser>. Motivo: a conta está desativada.
- Alarme recebido para tarefa Kerberos-tgt-update com falha
- Provedor SSPI: servidor não encontrado no banco de dados Kerberos
- 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
- Inconsistência inesperada; execute o fsck manualmente
- Operador de autocura ausente e repositório Sf-k8-utils ausente
- MongoDB degradado ou aplicativos de negócios após a restauração do cluster
- Serviços não íntegros após restauração ou reversão do cluster
- 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
Migrando o disco físico do Longhorn para o LVM
Guia de instalação do Automation Suite
Última atualização 19 de abr de 2024
Migrando o disco físico do Longhorn para o LVM
Observação: esta etapa é opcional, mas altamente recomendada ao atualizar o Automation Suite.
Na versão 2021.10.0, você precisava trazer um disco físico para o armazenamento de blocos/disco de dados. No entanto, com um disco físico, o tamanho de um volume/PVC que você podia criar era limitado ao tamanho do disco subjacente. Além disso, apenas o dimensionamento vertical era possível. É por isso que o Longhorn recomenda veementemente usar o LVM para agregar todos os discos de dados em uma única partição. Isso permite que o armazenamento de blocos seja estendido com facilidade no futuro Longhorn | Práticas recomendadas.
Se você alocou armazenamento de 2TiB para o Longhorn e seus requisitos de armazenamento são baixos, recomendamos migrar para o LVM.
- Seu cluster deve ser um cluster de produção pronto para alta disponibilidade de vários nós, ou seja, o cluster deve conter um mínimo de três nós de servidor.
- Certifique-se de que nenhuma das cargas de trabalho da família AI (AI Center, DU, TM) esteja sendo executada no momento da rotação de nós, caso contrário, essas cargas de trabalho falharão abruptamente.
- Você deve atualizar o Automation Suite para a versão 2021.10.1.
- Ao configurar o cluster em
cluster_config.json
comofixed_rke2_address
, o URL do LB é usado em vez de embutir o IP ou FQDN da primeira máquina. - Provisione três máquinas em standby que substituirão os nós de servidor originais. A configuração de hardware dessas máquinas deve ser a mesma que a de seus nós de servidor existentes. As máquinas devem ser colocadas na mesma VPC, subrede, grupo de segurança de rede, etc., e o número de discos anexados e seu tamanho também devem ser os mesmos.
- Certifique-se de que todas as portas estejam acessíveis nas máquinas. Consulte Configuração das máquinas para obter mais detalhes.
- Não crie as partições de disco manualmente em novas máquinas. Em vez disso, use o script de particionamento de disco documentado em Como configurar o disco.
- Certifique-se de que os nomes de host das máquinas sejam idênticos. Por exemplo, se seus servidores antigos tiverem os nomes
server0
,server1
eserver2
, dê esses mesmos nomes de host para os novos nós de servidor. - Copie a pasta do instalador junto com
cluster_config.json
do primeiro servidor existente para todas as três máquinas recém-criadas. - Antes de prosseguir com a rotação do servidor, execute esse script de verificação de integridade de qualquer um dos servidores existentes. O script não deve gerar nenhum erro e deve emitir para você a seguinte mensagem:
All Deployments are Healthy
.
- Os nós de servidor devem ser rotaciodados um a um. Observe que o processo de rotação de nós não se aplica para nós de agente.
- Desligue o nó antigo
server-N
para que as cargas de trabalho em execução no nó sejam excluídas corretamente (N
é o nó de número n; por exemplo,server0
). -
Remova o servidor do cluster executando o seguinte comando:
#where N is the nth server node Ex: server0 kubectl delete node server-N
#where N is the nth server node Ex: server0 kubectl delete node server-N - Remova o servidor N do pool de back-end do balanceador de carga, ou seja, tanto do pool de servidores quanto de nós. Consulte Configuração do balanceador de carga para obter mais detalhes.
- No novo nó do servidor N, instale o Kubernetes e configure o novo nó como um servidor. Consulte Adição de um novo nó ao cluster para obter mais detalhes.
- Depois que a instalação do Kubernetes for bem-sucedida, execute
kubectl get nodes
e verifique se o novo nó está de fato associado ao cluster original. - Execute o script de verificação de integridade do nó recém-adicionado para monitorar a integridade do cluster. O script deve exibir a seguinte mensagem:
All Deployments are Healthy
. - Depois que o script de verificação de integridade retornar um sucesso, adicione o novo nó de servidor aos pools de servidor e nós no Balanceador de carga. Consulte Configuração do balanceador de carga para obter mais detalhes.
- Repita o processo de rotação de nós para outros nós de servidor, ou seja, servidor 1, servidor 2, servidor N.
- Depois que todos os nós de servidor forem rotacionados, você pode excluir os nós de servidor mais antigos que estão no estado de desligamento.