Per le distribuzioni non riuscite è possibile riprendere il processo di provisioning dal punto di errore e in circostanze specifiche. Se è attivata, l'azione Riprendi è disponibile per le richieste di provisioning non riuscite o per altre azioni applicabili.

Per utilizzare l'azione di ripresa nelle richieste di provisioning, è necessario aggiungere la proprietà personalizzata _debug_deployment = true al blueprint. Per impostazione predefinita, per le distribuzioni non riuscite viene effettuato il rollback. Tali distribuzioni vengono inoltre eliminate in modo da recuperare le risorse. La proprietà _debug_deployment = true mantiene la distribuzione al punto di errore e, laddove supportato e in base al funzionamento, consente un'azione di ripresa. Se si utilizza la ripresa solo per le azioni supportate, non è necessario abilitare la proprietà _debug_deployment.

Per ulteriori informazioni su _debug_deployment, vedere Proprietà personalizzate che iniziano con il carattere di sottolineatura (_).

Per utilizzare l'azione di ripresa per una richiesta di provisioning o per un'azione disponibile, è necessario autorizzare gli utenti all'esecuzione dell'azione di ripresa. Vedere Autorizzazione degli utenti per servizi, elementi di catalogo e azioni.

È possibile autorizzare gli utenti all'esecuzione dell'azione di ripresa per le seguenti attività di provisioning.

  • Richieste di provisioning
  • Azione di ripresa
  • Azione di scalabilità verticale
  • Azione di scalabilità orizzontale
  • Azione di eliminazione

Vincoli dell'azione di ripresa

Quando si decide se utilizzare l'azione di ripresa anziché richiedere una nuova istanza di blueprint, è consigliabile considerare i vincoli.

  • Il blueprint non è modificabile dall'ora della richiesta.

    Al momento della richiesta, una versione non modificabile del blueprint viene associata alla richiesta del catalogo. Questa versione statica contiene tutte le specifiche, inclusi gli attributi, le proprietà personalizzate, le impostazioni e così via, relative al momento dell'avvio del provisioning. Se nel blueprint è presente un errore che crea problemi, la correzione dell'errore e l'utilizzo dell'azione di ripresa non consentono di risolvere la situazione perché fanno riferimento alla versione associata alla richiesta. In questo scenario, è necessario eseguire il provisioning di una nuova istanza.

    Esempi

    • Il blueprint A richiede 5 GB di RAM, ma la richiesta non riesce perché sono presenti solo prenotazioni per 3 GB. Se si aggiorna il blueprint in modo che necessiti di soli 3 GB e quindi si esegue l'azione Riprendi, tale azione non riesce. Quando viene eseguita, l'azione di ripresa verifica infatti la richiesta originale e cerca ancora 5 GB. Tuttavia, se si aumenta la prenotazione del sistema fino a 5 GB per il gruppo di business e si esegue l'azione Riprendi, tale azione viene effettuata correttamente.
    • Quando si richiede il blueprint B, che include una specifica personalizzata guest, l'azione non viene eseguita correttamente. Un'indagine determina che la specifica personalizzata guest è stata rinominata nell'istanza di vCenter Server. Se si aggiorna il blueprint con il nuovo nome e si esegue la ripresa, tale azione non viene effettuata correttamente. Il blueprint è stato aggiornato, ma per l'azione di ripresa viene utilizzata la versione originale. Se il nuovo nome è quello che si desidera utilizzare da ora in poi, distribuire una nuova istanza del blueprint anziché utilizzare l'azione di ripresa. In caso contrario, è necessario modificare il nome della specifica personalizzata guest nell'istanza di vCenter Server riutilizzando il nome previsto dalla versione originale e quindi eseguire l'azione di ripresa. Se si desidera evitare che la successiva richiesta di provisioning non riesca, non dimenticare di aggiornare il blueprint con la specifica personalizzata guest corretta.

    L'azione di ripresa funziona se è possibile aggiornare l'ambiente di distribuzione di destinazione in modo che supporti le specifiche del blueprint esistenti al momento della richiesta.

  • Il nuovo tentativo viene eseguito solo dal punto di errore.

    L'azione di ripresa ripete le attività dei componenti dal punto di errore. Non viene inviata nuovamente l'intera richiesta di provisioning.

    Esempi

    • Il blueprint C crea una macchina virtuale dell'applicazione e una macchina virtuale del database. La macchina virtuale del database viene distribuita correttamente, ma il provisioning non riesce nella macchina virtuale dell'applicazione. Se si esegue l'azione di ripresa, viene ripetuto solo il provisioning della macchina virtuale dell'applicazione.

      Se un componente viene contrassegnato come non riuscito, viene considerato come se non fosse mai stato eseguito. Se l'installazione non riesce durante la fase di configurazione nella macchina virtuale del database, ad esempio a causa di un errore di scripting, ma il database è integro, il database esiste ancora quando viene eseguito lo script durante un'azione di ripresa. Lo script di installazione, che include lo script di configurazione, non viene eseguito nuovamente. L'azione di ripresa non riesce. È necessario correggere lo script ed effettuare il provisioning di una nuova istanza.

    • Un'altra variante da prendere in considerazione è quella in cui il passaggio di allocazione riesce, ma il provisioning no. In questo esempio, quando si esegue l'azione di ripresa, che effettua un nuovo tentativo dal punto del provisioning non riuscito, la richiesta di ripresa elabora informazioni di allocazione obsolete e pertanto tale azione non riesce.

Utilizzo dell'azione di ripresa e delle sottoscrizioni ai workflow

Se la sottoscrizione a un workflow non riesce, non è possibile eseguire un'azione di ripresa per riprendere tale workflow. L'azione di ripresa può essere eseguita solo quando si verificano eventi di provisioning non riusciti, in presenza dei quali viene eseguito un nuovo workflow.

Ad esempio, se si sottoscrive l'evento Richiesta catalogo ricevuta, la richiesta di provisioning non riuscita e la nuova richiesta di ripresa soddisfano entrambe in modo indipendente le condizioni di sottoscrizione, ma la sottoscrizione non è a conoscenza della richiesta non riuscita e della richiesta di ripresa come attività correlate.