Récupération d’urgence pour Azure Automation

S’applique à : ✔️ Machines virtuelles Linux ✔️ Machines virtuelles Windows

Cet article explique la propre stratégie de récupération d’urgence pour gérer une défaillance à l’échelle de la région ou de la zone.

Vous devez disposer d’une stratégie de récupération d’urgence pour gérer une panne de service à l’échelle de la région ou de la zone afin de réduire l’impact et les effets résultant d’événements imprévisibles sur votre entreprise et vos clients. Vous êtes responsable de la configuration de la récupération d’urgence des comptes Automation et de leurs ressources dépendantes, comme les modules, les connexions, les informations d’identification, les certificats, les variables et les planifications. Un aspect important d’un plan de récupération d’urgence est la préparation du basculement vers le réplica du compte Automation créé à l’avance dans la région secondaire, si le compte Automation dans la région primaire devient indisponible. Assurez-vous que votre stratégie de récupération d’urgence prend en compte votre compte Automation et les ressources dépendantes.

En plus de la haute disponibilité offerte par les zones de disponibilité, certaines régions sont associées à une autre région pour assurer une protection contre les sinistres régionaux ou à large zone géographique. Que la région primaire ait ou non une paire régionale, la stratégie de récupération d’urgence pour le compte Automation reste la même. Pour plus d’informations sur les paires régionales, consultez ceci.

Activer la reprise d’activité après sinistre

Chaque compte Automation que vous créez nécessite un emplacement que vous devez utiliser pour le déploiement. Il s’agit de la région principale de votre compte Automation, qui inclut des ressources, des runbooks créés pour le compte Automation, des données d’exécution de travaux et des journaux. Pour la récupération d’urgence, le compte Automation de réplica doit être déjà déployé et prêt dans la région secondaire.

• Commencez par créer un compte Automation de réplica dans n’importe quelle autre région.
• Sélectionnez la région secondaire de votre choix : région jumelée ou toute autre région où Azure Automation est disponible.
• Outre la création d’un réplica du compte Automation, répliquez les ressources dépendantes, comme les runbooks, les modules, les connexions, les informations d’identification, les certificats, les variables, les planifications et les autorisations affectées pour le compte d’identification et les identités managées dans le compte Automation dans la région primaire sur le compte Automation dans la région secondaire. Vous pouvez utiliser le script PowerShell pour migrer les ressources du compte Automation d’une région vers une autre.
• Si vous utilisez des modèles ARM pour définir et déployer des runbooks Automation, vous pouvez utiliser ces modèles pour déployer les mêmes runbooks dans n’importe quelle autre région Azure où vous créez le compte Automation de réplica. En cas de panne à l’échelle de la région ou de défaillance à l’échelle de la zone dans la région primaire, vous pouvez exécuter les runbooks répliqués dans la région secondaire pour continuer à travailler comme d’habitude. Cela garantit que la région secondaire prend le relais pour poursuivre le travail en cas d’interruption ou de défaillance de la région primaire.

Scénarios pour les travaux cloud et hybrides

Scénario : Exécuter des travaux cloud dans une région secondaire

Pour les travaux cloud, le temps d’arrêt serait négligeable, à condition qu’un compte Automation de réplica et que toutes les ressources et tous les runbooks dépendants soient déjà déployés et disponibles dans la région secondaire. Vous pouvez utiliser le compte de réplica pour exécuter des travaux comme d’habitude.

Scénario : Exécuter des travaux sur un Runbook Worker hybride déployé dans une région différente de la région principale en panne

Si le Runbook Worker hybride Windows ou Linux est déployé à l’aide de l’approche basée sur les extensions dans une région différente de la région principale de la panne, procédez comme suit pour continuer à exécuter les travaux hybrides :

1. Supprimez l’extension installée sur le Runbook Worker hybride dans le compte Automation de la région primaire.
2. Ajoutez le même Runbook Worker hybride à un groupe de travail hybride dans le compte Automation de la région secondaire. L’extension Worker hybride est installée sur la machine dans le réplica du compte Automation.
3. Exécutez les travaux sur le Runbook Worker hybride créé à l’étape 2.

Pour le Runbook Worker hybride déployé à l’aide de l’approche basée sur un agent, choisissez l’une des options ci-dessous :

Scénario : Exécuter des travaux sur un Runbook Worker hybride déployé dans la région primaire de l’échec

Si le Runbook Worker hybride est déployé dans la région primaire et qu’il y a un échec de calcul dans cette région, l’ordinateur ne sera pas disponible pour l’exécution de travaux Automation. Vous devez provisionner une nouvelle machine virtuelle dans une autre région et l’inscrire en tant que Runbook Worker hybride dans le compte Automation dans la région secondaire.

• Consultez les étapes d’installation dans Déployer un Runbook Worker hybride utilisateur Windows ou Linux basé sur une extension.
• Consultez les étapes d’installation dans Déployer un Worker hybride Windows basé sur un agent.
• Consultez les étapes d’installation dans Déployer un Worker hybride Linux basé sur un agent.

Script pour migrer les ressources de compte Automation d’une région vers une autre

Vous pouvez utiliser ces scripts pour la migration des ressources de compte Automation du compte dans la région primaire vers le compte de la région secondaire. Ces scripts sont utilisés pour migrer uniquement les runbooks, les modules, les connexions, les informations d’identification, les certificats et les variables. L’exécution de ces scripts n’affecte pas le compte Automation et ses ressources présentes dans la région primaire.

Prérequis

1. Vérifiez que le compte Automation dans la région secondaire est créé et disponible afin que les ressources de la région primaire puissent y être migrées. Il est préférable que le compte Automation de destination soit un compte sans ressources personnalisées, car cela empêche les conflits de ressources potentiels en raison du même nom et de la perte de données.

2. Vérifiez que les identités managées affectées par le système sont activées dans le compte Automation de la région primaire.

3. Vérifiez que les identités managées affectées par le système du compte Automation principal disposent d’un accès contributeur à l’abonnement auquel il appartient.

4. Vérifiez que l’identité managée du compte Automation principal dispose d’un accès Contributeur avec des autorisations de lecture et d’écriture sur le compte Automation dans la région secondaire. Pour l’activer, fournissez les autorisations nécessaires dans les identités managées du compte Automation secondaire. Plus d’informations

5. Vérifiez que le script a accès aux ressources du compte Automation dans la région primaire. Par conséquent, il doit être exécuté en tant que runbook dans ce compte Automation pour une migration réussie.

6. Si le compte Automation principal est déployé à l’aide d’un compte d’identification, il doit être basculé vers l’identité managée avant la migration. Plus d’informations

7. Les modules requis sont les suivants :

   • Az.Accounts version 2.8.0
   • Az.Resources version 6.0.0
   • Az.Automation version 1.7.3
   • Az.Storage version 4.6.0

8. Vérifiez que les comptes Automation source et de destination doivent appartenir au même locataire Microsoft Entra.

Créer et exécuter le runbook

Vous pouvez utiliser le script PowerShell ou le runbook de workflow PowerShell, ou importer à partir de la galerie de runbooks et l’exécuter pour activer la migration des ressources d’un compte Automation vers un autre.

Suivez les étapes pour importer et exécuter le runbook :

Les options sont :

Limites

• Le script migre uniquement les modules PowerShell personnalisés. Les modules par défaut et les packages Python ne sont pas migrés vers le compte Automation réplica.
• Le script ne migre pas les planifications et les identités managées présentes dans le compte Automation dans la région primaire. Vous devez les créer manuellement dans le compte Automation réplica.
• Les données des travaux et les journaux d’activité ne sont pas migrés vers le compte réplica.

Étapes suivantes

• En savoir plus sur les régions qui prennent en charge les zones de disponibilité.