Você pode usar Retomar em implantações com falha para reiniciar o processo de provisionamento a partir do ponto de falha e em circunstâncias específicas. Quando ativada, a ação Retomar está disponível para solicitações de provisionamento com falha ou ações aplicáveis.

Para usar a ação de retomada em solicitações de provisionamento, você deve adicionar a propriedade personalizada _debug_deployment = true no blueprint. Por padrão, as implantações com falha são revertidas e limpas para que os recursos sejam recuperados. A propriedade _debug_deployment = true mantém a implantação no ponto de falha e, onde suportado e com base em como funciona, permite uma ação de retomada. Se você só estiver usando retomar nas ações compatíveis, não é necessário ativar a propriedade _debug_deployment.

Para obter mais informações sobre _debug_deployment, consulte Propriedades personalizadas com sublinhado (_).

Para usar retomar em uma solicitação de provisionamento ou nas ações disponíveis, você autoriza usuários para a ação Retomar. Consulte Autorizar usuários para serviços, itens de catálogo e ações.

Você pode autorizar usuários para a ação Retomar para essas atividades de provisionamento.

  • Solicitações de provisionamento
  • Ação Retomar
  • Ação Dimensionar Verticalmente
  • Ação Dimensionar Horizontalmente
  • Ação Destruir

Restrições da Ação Retomar

Ao decidir se você pode usar Retomar em vez de solicitar uma nova instância de um blueprint, considere as restrições.

  • O blueprint não é modificável a partir do momento da solicitação.

    No momento da solicitação, uma versão não modificável do blueprint é associada à solicitação de catálogo. Essa versão estática contém todas as especificações, incluindo atributos, propriedades personalizadas, configurações e assim por diante, como era quando o provisionamento foi iniciado. Se você tiver um erro de produção de falha no seu blueprint, corrigir o erro e usar Retomar não funcionará porque está se referindo à versão associada à solicitação. Nesse cenário, você deve provisionar uma nova instância.

    Exemplos

    • O Blueprint A solicita 5 GB de RAM, mas a solicitação falhará porque você tem apenas reservas de 3 GB. Se você atualizar o blueprint para precisar de apenas 3 GB e, em seguida, executar Retomar, essa ação falhará. Quando a ação Retomar é executada, ela verifica a solicitação original e ainda está procurando por 5 GB. No entanto, se você aumentar a reserva do sistema para o grupo de negócios para 5 GB e executar Retomar, essa ação será bem-sucedida.
    • Quando você solicitar o Blueprint B, que inclui uma Especificação Personalizada do Guest, ele falhará. A investigação revela que a Especificação Personalizada do Guest foi renomeada na sua instância do vCenter Server. Se você atualizar o blueprint com o novo nome e executar Retomar, ele falhará. Você atualizou o blueprint, mas a versão original é usada para a ação Retomar. Se o novo nome for o que você deseja usar daqui para frente, implante uma nova instância do blueprint em vez de usar Retomar. Caso contrário, você deve alterar o nome da Especificação Personalizada do Guest na instância do vCenter Server de volta para a esperada pela versão original e executar Retomar. Se você não quiser que a próxima solicitação de provisionamento falhe, não se esqueça de atualizar o blueprint com a Especificação Personalizada do Guest correta.

    A ação Retomar funciona se você puder atualizar o ambiente de implantação de destino para suportar as especificações do blueprint conforme elas existiam no momento da solicitação.

  • Repetir é apenas a partir do ponto de falha.

    A ação Retomar repete as tarefas do componente a partir do ponto de falha. Ela não reenvia toda a solicitação de provisionamento.

    Exemplos

    • O Blueprint C cria uma máquina virtual do aplicativo e uma máquina virtual do banco de dados. A VM do banco de dados é implantada com êxito, mas o provisionamento falha na VM do aplicativo. Se você executar a ação Retomar, somente o provisionamento da VM do aplicativo será repetido.

      Se um componente estiver marcado como Falhou, será tratado como se nunca tivesse sido executado. Se a instalação falhar durante a fase de configuração na VM do banco de dados, por exemplo, devido a um erro de script, mas o banco de dados estiver intacto, o banco de dados ainda existirá quando o script for executado durante uma ação de retomada. O script de instalação, que inclui o script de configuração, não é executado novamente. Sua retomada não é bem-sucedida. Você deve corrigir o script e provisionar uma nova instância.

    • Outra variação a considerar é onde a alocação da etapa foi bem-sucedida, mas a provisão falhou. Neste exemplo, quando você retoma, que repete a partir do ponto de provisionamento com falha, a solicitação de retomada está processando informações de alocação obsoletas e a retomada falha.

Trabalhando com a ação de retomada e as assinaturas de fluxo de trabalho

Se um fluxo de trabalho de assinatura falhar, você não poderá executar uma ação de retomada para retomar esse fluxo de trabalho. A ação de retomada só pode ser executada em eventos de provisionamento com falha, no momento em que um novo fluxo de trabalho é executado.

Por exemplo, se você assinar o evento de Solicitação de Catálogo Recebida, a solicitação de provisionamento com falha e a nova solicitação Retomar atenderão independentemente às condições de assinatura, mas a assinatura não terá conhecimento da solicitação com falha e da solicitação de retomada como atividades relacionadas.