Dova Docs22.0.5
Suporte

Reatribuir referências, preservar metadados e retirar workers

Revise dependências, valide o destino e confirme a ausência do recurso no provedor antes de considerar uma retirada concluída.

Manual completo em PDF
Nesta página
  1. Escopo e pré-requisitos
  2. Inventariar e preparar
  3. Gerar preview e aplicar
  4. Resolver Sessions e retirar a infraestrutura
  5. Exemplo e recuperação

Escopo e pré-requisitos

A migração de um worker altera referências de execução para uma capacidade autorizada e compatível. Ela não transfere automaticamente arquivos, bancos de dados, credenciais ou sistema operacional. Antes de começar, confirme tenant de origem, destino elegível, autoridade de gerenciamento e janela operacional. O assistente mantém verificações de propriedade, atividade e dependências; um estado de VM desconhecido não autoriza a exclusão.

Um Dependency backup preserva metadados de atribuição e integridade, não uma imagem de VM ou uma cópia completa de dados. Ao restaurar ou reatribuir, confira novamente a existência dos objetos e as capacidades atuais do destino. As conexões e os arquivos precisam ser preparados por seu procedimento autorizado separado.

Inventariar e preparar

  1. Abra Cloud workers → Workers e consulte o worker de origem.
  2. Use Reassign references, Dependency backups ou Restore/reassign to another worker, conforme a finalidade.
  3. Confira origem, tenant e referências atuais. Diferencie inventário vazio de inventário incompleto.
  4. Revise uso como worker padrão, execuções ativas ou em fila, Sessions, Workflows e dependências de conexões e credenciais.
  5. Use Pause scheduling ou Pause scheduling quando o objetivo for impedir novas atribuições e aguardar as atuais.
  6. Resolva inventários desconhecidos, bloqueios e erros de observação do provedor antes de tentar retirar.
DependênciaPreparação
Worker padrãoDefina outro destino padrão autorizado quando necessário.
Trabalho ativo ou reservadoAguarde ou conclua o fluxo de contenção permitido; Stop VM não substitui a espera controlada.
Sessions / WorkflowsRevise compatibilidade e referências publicadas ainda usadas.
Worker públicoRevise dependências entre os tenants autorizados e versões históricas ainda utilizadas.
Estado do provedor indisponívelRestabeleça uma observação verificável; indisponível não significa ausente.

Gerar preview e aplicar

  1. Selecione o Destination worker suportado e as referências pretendidas.
  2. Confirme Destination credentials have been configured and verified somente após verificar a configuração real do destino.
  3. Use Preview changes e leia alterações, avisos e bloqueios.
  4. Se destino, seleção ou configuração relevante mudar, gere outro preview.
  5. Aplique o plano permitido com Apply reassignment e confira a quantidade e o resultado das alterações.
  6. Atualize origem e destino e consulte o backup de dependências gerado quando aplicável.

A interface gerencia identificadores de preview e tentativas. Não os altere para aceitar um plano antigo. Download metadata copy contém apenas o escopo de metadados indicado, sem ser uma cópia portátil de todos os conteúdos ou segredos. Um conflito exige nova revisão do estado, não modificação manual das referências no armazenamento.

Resolver Sessions e retirar a infraestrutura

O fluxo pode oferecer Replace worker, Distribute Sessions ou Disable affected Sessions. A substituição exige destino compatível com todas as Sessions afetadas; a distribuição exige atribuição completa e sem duplicação. Desabilitar Sessions altera sua execução e pode produzir erro de dependência nos Workflows relacionados. Revise o efeito antes de escolher essa opção.

Abra o diálogo de retirada e atualize o impacto: recursos cloud, referências e atividade. Resolva worker padrão, atividade e política pública. A retirada pública revisa referências entre tenants e versões históricas ainda usadas; versões históricas inacessíveis são preservadas e não bloqueiam por si só. Se o fluxo oferecer Stop and deprovision the VM, leia a ação, preencha Type to confirm e o reconhecimento apenas após satisfazer as condições e envie uma vez.

O registro Dova é retirado após ausência confirmada no provedor e verificação final das referências. Uma falha preserva o registro para diagnóstico e nova tentativa. Clean up Dova record aplica-se à ausência confirmada; Unknown ou Unavailable não significa Absent. Se parar a VM falhar ou novas dependências surgirem, resolva e atualize antes de prosseguir.

Exemplo e recuperação

No laboratório, reatribua uma Session sintética de worker-origem-demo para um destino compatível. Confira referências publicadas, backup e impacto atualizado da origem antes de qualquer retirada. A validação de um conflito deve demonstrar que um preview antigo não é aplicado após mudança de dependência. Use um simulador para falhas de provedor, sem provocar falhas em recursos reais.

Depois de erro de rede, reabra a operação e confira o estado atual antes de repetir. Fechar o diálogo não cancela uma solicitação já aceita pelo provedor. Não anuncie remoção ou economia cloud até confirmar o resultado do provedor e o estado Dova correspondente. Após restauração, revalide compatibilidade e publicação, pois o destino atual pode diferir do momento do backup.

Consulte também: Cloud workers, Instalação de workers, Audit.