Partager via

Récupération d’urgence pour Azure Automation

  • Article

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.

Remarque

En raison des exigences de résidence des données, les données et journaux des travaux présents dans la région primaire ne sont pas disponibles dans la région secondaire.

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 :

Si le Runbook Worker hybride Windows est déployé à l’aide d’une approche basée sur un agent dans une région différente de la région principale de la panne, suivez les étapes pour continuer à exécuter des travaux hybrides :

  1. Désinstallez l’agent du Runbook Worker hybride présent dans le compte Automation dans la région primaire.
  2. Réinstallez l’agent sur la même machine dans le compte Automation du réplica dans la région secondaire.
  3. Vous pouvez maintenant exécuter des travaux sur le Runbook Worker hybride créé à l’étape 2.

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.

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 toute 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 :

  1. Connectez-vous au portail Azure.
  2. Accédez au compte Automation que vous souhaitez migrer vers une autre région.
  3. Sous Automatisation de processus, sélectionnez Runbooks.
  4. Sélectionnez Parcourir la galerie et, dans la recherche, entrez Migrer les ressources d’un compte Automation d’une région à une autre, puis sélectionnez Script PowerShell.
  5. Dans la page Importer un runbook, entrez un nom pour le runbook.
  6. Sélectionnez la Version du runtime 5.1 ou 7.1 (préversion)
  7. Entrez la description, puis sélectionnez Importer.
  8. Dans la page Modifier le runbook PowerShell, modifiez les paramètres requis et exécutez-le.

Vous pouvez choisir l’une des options pour modifier et exécuter le script. Vous pouvez fournir les sept paramètres obligatoires comme indiqué dans l’option 1 ou les trois paramètres obligatoires dans l’option 2 pour modifier et exécuter le script.

Les options sont :

Nom Obligatoire Description
SourceAutomationAccountName True Nom du compte Automation dans la région primaire à partir de laquelle les ressources doivent être migrées.
DestinationAutomationAccountName True Nom du compte Automation dans la région secondaire vers laquelle les ressources doivent être migrées.
SourceResourceGroup True Nom du groupe de ressources du compte Automation dans la région primaire.
DestinationResourceGroup True Nom du groupe de ressources du compte Automation dans la région secondaire.
SourceSubscriptionId True ID d’abonnement du compte Automation dans la région primaire
DestinationSubscriptionId True ID d’abonnement du compte Automation dans la région secondaire.
Type[] True Tableau composé de tous les types de ressources qui doivent être migrés, les valeurs possibles sont Certificats, Connexions, Informations d’identification, Modules, Runbooks et Variables.

Limites

  • Le script migre uniquement les modules PowerShell personnalisés. Les modules par défaut et les packages Python ne seraient 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 seraient pas migrés vers le compte réplica.

Étapes suivantes