Ripristino di emergenza per Automazione di Azure
Si applica a: ✔️ macchine virtuali Linux ✔️ macchine virtuali Windows
Questo articolo illustra la strategia di ripristino di emergenza per gestire un errore a livello di area o a livello di zona.
È necessario disporre di una strategia di ripristino di emergenza per gestire un'interruzione del servizio a livello di area o un errore a livello di zona per ridurre l'impatto e gli effetti derivanti da eventi imprevedibili per l'azienda e i clienti. L'utente è responsabile della configurazione del ripristino di emergenza degli account di automazione e delle relative risorse dipendenti, ad esempio moduli, connessioni, credenziali, certificati, variabili e pianificazioni. Un aspetto importante di un piano di ripristino di emergenza è la preparazione del failover nella replica dell'account di Automazione creato in anticipo nell'area secondaria, se l'account di Automazione nell'area primaria non è più disponibile. Assicurarsi che la strategia di ripristino di emergenza consideri l'account di Automazione e le risorse dipendenti.
Oltre alla disponibilità elevata offerta dalle zone di disponibilità, alcune aree sono abbinate a un'altra area per garantire la protezione da emergenze geografiche di grandi dimensioni o regionali. Indipendentemente dal fatto che l'area primaria abbia una coppia di aree o meno, la strategia di ripristino di emergenza per l'account di Automazione rimane invariata. Per altre informazioni sulle coppie di aree, vedere altre informazioni.
Abilitare il ripristino di emergenza
Ogni account di Automazione creato richiede un percorso da usare per la distribuzione. Si tratta dell'area primaria per l'account di Automazione e include asset, runbook creati per l'account di Automazione, i dati di esecuzione dei processi e i log. Per il ripristino di emergenza, l'account di Automazione di replica deve essere già distribuito e pronto nell'area secondaria.
- Iniziare la creazione di un account di Automazione di replica in qualsiasi area alternativa.
- Selezionare l'area secondaria preferita, ovvero l'area abbinata o qualsiasi altra area in cui è disponibile Automazione di Azure.
- Oltre a creare una replica dell'account di Automazione, replicare le risorse dipendenti, ad esempio runbook, moduli, connessioni, credenziali, certificati, variabili, pianificazioni e autorizzazioni assegnate per l'account Run As e le identità gestite nell'account di Automazione nell'area primaria nell'account di Automazione nell'area secondaria. È possibile usare lo script di PowerShell per eseguire la migrazione degli asset dell'account di Automazione da un'area a un'altra.
- Se si usano modelli arm per definire e distribuire runbook di Automazione, è possibile usare questi modelli per distribuire gli stessi runbook in qualsiasi altra area di Azure in cui si crea l'account di Automazione di replica. In caso di un'interruzione a livello di area o di un errore a livello di zona nell'area primaria, è possibile eseguire i runbook replicati nell'area secondaria per continuare l'attività come di consueto. Ciò garantisce che l'area secondaria intervenga pere continuare il lavoro se l'area primaria presenta un'interruzione o un errore.
Nota
A causa dei requisiti di residenza dei dati, i dati e i log dei processi presenti nell'area primaria non sono disponibili nell'area secondaria.
Scenari per processi cloud e ibridi
Scenario: Eseguire processi cloud nell'area secondaria
Per i processi cloud, si verifica un tempo di inattività trascurabile, a condizione che un account di Automazione di replica e tutte le risorse dipendenti e i runbook siano già distribuiti e disponibili nell'area secondaria. È possibile usare l'account di replica per l'esecuzione di processi come di consueto.
Scenario: eseguire processi nel ruolo di lavoro ibrido per runbook distribuito in un'area diversa dall'area primaria dell'errore
Se il ruolo di lavoro ibrido per runbook Windows o Linux viene distribuito usando l'approccio basato su estensione in un'area diversa dall'area primaria di errore, seguire questa procedura per continuare a eseguire i processi ibridi:
- Eliminare l'estensione installata nel ruolo di lavoro ibrido per runbook nell'account di Automazione nell'area primaria.
- Aggiungere lo stesso ruolo di lavoro ibrido per runbook a un gruppo di ruoli di lavoro ibridi nell'account di Automazione nell'area secondaria. L'estensione del ruolo di lavoro ibrido viene installata nel computer nella replica dell'account di Automazione.
- Eseguire i processi nel ruolo di lavoro ibrido per runbook creato nel passaggio 2.
Per il ruolo di lavoro ibrido per runbook distribuito usando l'approccio basato su agente, scegliere tra i seguenti:
Se il ruolo di lavoro ibrido per runbook di Windows viene distribuito usando un approccio basato su agente in un'area diversa dall'area primaria di errore, seguire la procedura per continuare l'esecuzione di processi ibridi:
- Disinstallare l'agente dal ruolo di lavoro ibrido per runbook presente nell'account di Automazione nell'area primaria.
- Reinstallare l'agente nello stesso computer nell'account di Automazione di replica nell'area secondaria.
- È ora possibile eseguire processi nel ruolo di lavoro ibrido per runbook creato nel passaggio 2.
Scenario: eseguire processi nel ruolo di lavoro ibrido per runbook distribuito nell'area primaria di errore
Se il ruolo di lavoro ibrido per runbook viene distribuito nell'area primaria e si verifica un errore di calcolo in tale area, il computer non sarà disponibile per l'esecuzione di processi di automazione. È necessario effettuare il provisioning di una nuova macchina virtuale in un'area alternativa e registrarla come ruolo di lavoro ibrido per runbook nell'account di Automazione nell'area secondaria.
- Vedere la procedura di installazione in come distribuire un ruolo di lavoro per runbook basato su estensioni o Windows o Linux.
- Vedere la procedura di installazione in come distribuire un ruolo di lavoro ibrido Windows basato su agente.
- Vedere la procedura di installazione in come distribuire un ruolo di lavoro ibrido Linux basato su agente.
Script per eseguire la migrazione degli asset dell'account di Automazione da un'area a un'altra
È possibile usare questi script per la migrazione degli asset dell'account di Automazione dall'account nell'area primaria all'account nell'area secondaria. Questi script vengono usati per eseguire la migrazione solo di runbook, moduli, connessioni, credenziali, certificati e variabili. L'esecuzione di questi script non influisce sull'account di Automazione e sui relativi asset presenti nell'area primaria.
Prerequisiti
Assicurarsi che l'account di Automazione nell'area secondaria sia stato creato e disponibile in modo che sia possibile eseguirne la migrazione da un'area primaria. È preferibile se l'account di automazione di destinazione è uno senza risorse personalizzate perché impedisce potenziali conflitti di risorse a causa dello stesso nome e della perdita di dati.
Assicurarsi che le identità gestite assegnate dal sistema siano abilitate nell'account di Automazione nell'area primaria.
Assicurarsi che le identità gestite assegnate dal sistema dell'account di Automazione primario abbiano accesso collaboratore alla sottoscrizione a cui appartiene.
Assicurarsi che l'identità gestita dell'account di Automazione primaria abbia accesso collaboratore con autorizzazioni di lettura e scrittura per l'account di Automazione nell'area secondaria. Per abilitare, fornire le autorizzazioni necessarie nelle identità gestite dell'account di Automazione secondario. Altre informazioni.
Assicurarsi che lo script abbia accesso agli asset dell'account di Automazione nell'area primaria. Di conseguenza, deve essere eseguito come runbook in tale account di Automazione per la corretta migrazione.
Se l'account di Automazione primario viene distribuito usando un account Run as, è necessario passare all'identità gestita prima della migrazione. Altre informazioni.
I moduli necessari sono:
- Az.Accounts versione 2.8.0
- Az.Resources versione 6.0.0
- Az.Automation versione 1.7.3
- Az.Storage versione 4.6.0
Assicurarsi che gli account di automazione di origine e di destinazione appartengano allo stesso tenant di Microsoft Entra.
Creare ed eseguire il runbook
È possibile usare lo script di PowerShell o il runbook del flusso di lavoro PowerShell o importarlo dalla raccolta Runbook ed eseguirlo per abilitare la migrazione degli asset da un account di Automazione a un altro.
Seguire la procedura per importare ed eseguire il runbook:
- Accedere al portale di Azure.
- Passare all'account di Automazione di cui si vuole eseguire la migrazione in un'altra area.
- In Automazione processi selezionare Runbook.
- Selezionare Sfoglia raccolta e nella ricerca immettere Esegui migrazione degli asset dell'account di Automazione da un'area a un'altra e selezionare Script di PowerShell.
- Nella pagina Importa un runbook immettere un nome per il runbook.
- Selezionare Versione di runtime come 5.1 o 7.1 (anteprima)
- Immettere la descrizione e selezionare Importa.
- Nella pagina Modifica runbook di PowerShell modificare i parametri necessari ed eseguirlo.
È possibile scegliere una delle opzioni per modificare ed eseguire lo script. È possibile specificare i sette parametri obbligatori indicati nell'opzione 1 o tre parametri obbligatori specificati nell'opzione 2 per modificare ed eseguire lo script.
Le opzioni sono:
| Nome | Obbligatorio | Descrizione |
|---|---|---|
| SourceAutomationAccountName | Vero | Nome dell'account di automazione nell'area primaria da cui è necessario eseguire la migrazione degli asset. |
| DestinationAutomationAccountName | Vero | Nome dell'account di automazione nell'area secondaria in cui è necessario eseguire la migrazione degli asset. |
| SourceResourceGroup | Vero | Nome del gruppo di risorse dell'account di Automazione nell'area primaria. |
| DestinationResourceGroup | Vero | Nome del gruppo di risorse dell'account di Automazione nell'area secondaria. |
| SourceSubscriptionId | Vero | ID sottoscrizione dell'account di Automazione nell'area primaria |
| DestinationSubscriptionId | Vero | ID sottoscrizione dell'account di Automazione nell'area secondaria. |
| Type[] | Vero | Matrice costituita da tutti i tipi di asset di cui è necessario eseguire la migrazione, i valori possibili sono Certificati, Connessioni, Credenziali, Moduli, Runbook e Variabili. |
Limiti
- Lo script esegue la migrazione solo dei moduli di PowerShell personalizzati. I moduli predefiniti e i pacchetti Python non verranno migrati nell'account di Automazione di replica.
- Lo script non esegue la migrazione di pianificazioni e identità gestite presenti nell'account di Automazione nell'area primaria. Questi elementi devono essere creati manualmente nell'account di Automazione della replica.
- I dati dei processi e i log attività non verranno migrati nell'account di replica.
Passaggi successivi
- Altre informazioni sulle aree che supportano le zone di disponibilità.