- Visão geral
- Requisitos
- Instalação
- Pós-instalação
- Migração e atualização
- Atualização do Automation Suite no EKS/AKS
- 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: migração do Test Manager independente
- Etapa 9: exclusão do tenant padrão
- Executando uma migração de único tenant
- Migração do Automation Suite no Linux para o Automation Suite no EKS/AKS
- Monitoramento e alertas
- Administração de cluster
- Configuração específica do produto
- 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
- Limpeza do banco de dados do Orchestrator
- Solução de problemas
- A configuração de backup não funciona devido a uma falha na conexão com o Azure Government
- Pods no namespace uipath travaram ao habilitar taints de nó personalizado
- Não é possível iniciar o Automation Hub e o Apps com configuração de proxy
- Os pods não podem se comunicar com o FQDN em um ambiente de proxy
- A cadeia de caracteres de conexão SQL da Automação de Teste é ignorada
- Falha de backup do EKS devido à versão do Velero
- O backup do Velero falha com o erro FailedValidation
- O acesso ao FQDN retorna o erro de acesso negado do RBAC
- Migreção manual do ArgoCD NetworkPolicy (GHSA-47m3-95c7-g2g8)
Restaurando o backup
Processo de restauração do cluster para o Automation Suite no EKS/AKS e como reativar backups de instantâneo após a restauração.
Depois que um cluster é restaurado, o backup de instantâneo não é habilitado. Para habilitá-la após a restauração, consulte a Habilitação do instantâneo de backup.
Restaurar o cluster não restaura fontes de dados externas, como o SQL Server. Certifique-se de restaurar o servidor SQL para o instantâneo relevante.
Para restaurar o cluster, execute as seguintes etapas:
Etapa 1: Provisionamento do cluster do Kubernetes
Antes de restaurar, certifique-se de configurar o cluster do Kubernetes no qual você deseja restaurar.
Para obter detalhes, consulte Pré-requisitos.
Etapa 2: Restaurar o SQL Server e o objectstore
Como o SQL Server e o Objectstore são componentes externos, certifique-se de que você os restaurou antes de restaurar o cluster do Automation Suite .
Não é permitido alterar o FQDN durante a operação de restauração. Certifique-se de preservar o FQDN para o cluster do Automation Suite , o SQL Server, Objectstore, Redis e Filestore.
Etapa 3: fornecer a configuração do snapshot
Forneça a configuração do instantâneo, como objectstore, onde os dados de backup são armazenados. Essa configuração é semelhante à que você forneceu durante a configuração de backup. Para obter detalhes, consulte Configuração do armazenamento de backup.
Etapa 4: seleção do snapshot a ser restaurado
Para identificar o backup que você deseja restaurar, consulte Listar os instantâneos existentes.
A seleção do snapshot relevante para os dados do SQL Server e do Objectstore é importante. Incompatibilidades podem ocorrer se houver uma grande diferença entre o momento em que você tira o instantâneo do cluster do Automation Suite e quando você tira o instantâneo dos componentes de armazenamento externo.
Etapa 5: execução do script de restauração
Certifique-se de que o Velero esteja instalado no cluster do EKS recém-implantado para que você possa restaurar o snapshot. Para instalar o Velero no novo cluster, execute o seguinte comando:
./uipathctl manifest apply input.json --only velero --versions versions.json
./uipathctl manifest apply input.json --only velero --versions versions.json
Para restaurar o snapshot selecionado, execute o seguinte comando:
./uipathctl snapshot restore create <restore_name> --from-snapshot <snapshot_name>
./uipathctl snapshot restore create <restore_name> --from-snapshot <snapshot_name>
O comando de restauração requer o nome da restauração, que você pode usar para obter o status da restauração e depurar em caso de falha.
Essa operação leva algum tempo para ser concluída e é executada em segundo plano. Você pode usar o comando history para exibir o status, conforme descrito na próxima seção.
Problema conhecido: em certos cenários, a operação de restauração pode ficar presa. Se a operação de restauração ficar presa, você deve remover manualmente o objeto restore e, posteriormente, tentar novamente a operação de restauração.
Depuração da restauração
Para depurar a operação de restauração, você pode usar os comandos history e log .
Histórico:
./uipathctl snapshot restore history
# Output Example
NAME STATUS CREATED EXPIRATION
prefix-scheduled-xx1 Completed xx1 xx1
prefix-scheduled-xx2 Failed xx2 xx2
test-snapshot-xx3 Failed xx3 xx3
./uipathctl snapshot restore history
# Output Example
NAME STATUS CREATED EXPIRATION
prefix-scheduled-xx1 Completed xx1 xx1
prefix-scheduled-xx2 Failed xx2 xx2
test-snapshot-xx3 Failed xx3 xx3
Logs:
./uipathctl snapshot restore logs restore_1
./uipathctl snapshot restore logs restore_1