Fiabilité dans Azure Automation

Azure Automation est un service qui exécute des tâches de gestion en votre nom. Vous définissez des scripts, appelés runbooks, que vous souhaitez exécuter, et Azure Automation fournit l’infrastructure pour exécuter ces scripts. Cet article se concentre sur l’automatisation des processus, qui est la fonctionnalité principale du service. Les workers de runbook hybrides, qui s’exécutent sur une infrastructure gérée par le client, ne sont pas couverts par cet article.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure Automation résilient aux différentes pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité, les pannes de région et la maintenance du service. Il décrit également les options de sauvegarde et de restauration, ainsi que les informations clés relatives au contrat de niveau de service (SLA) Azure Automation.

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production qui utilisent l’automatisation des processus, suivez les recommandations suivantes :

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

Lorsque vous déployez Azure Automation, vous créez un compte Automation, qui est un conteneur logique pour les ressources qui exécutent votre automatisation.

• Runbooks, qui représentent le travail à effectuer. Les runbooks textuels sont des scripts écrits dans PowerShell ou Python. Les runbooks graphiques sont créés à l’aide d’un éditeur graphique.
• Ressources que les runbooks partagent, notamment les modules, les connexions, les informations d’identification, les certificats et les variables.
• Ressources qui déclenchent l’exécution des runbooks, notamment les planifications et les observateurs.

Pour plus d’informations sur ces ressources, consultez l’exécution du Runbook dans Azure Automation.

Cet article traite de la fiabilité et de la résilience de ces fonctionnalités, qui font partie de l’automatisation des processus dans Azure Automation.

Architecture physique

Les runbooks s’exécutent sur l’infrastructure de calcul. Deux modèles de déploiement existent pour l’automatisation des processus :

• Travaux cloud (gérés Microsoft) : par défaut, les runbooks s’exécutent sur l’infrastructure cloud fournie par Microsoft. Microsoft est responsable de la haute disponibilité et de la gestion de cette infrastructure. Lorsque vous envoyez un travail de runbook, Azure Automation alloue un travail cloud à partir de son pool de ressources de calcul disponibles, exécute le runbook, puis retourne la ressource au pool.

  Les travaux cloud peuvent parfois être interrompus lors de l’exécution. Concevez vos runbooks en supposant qu’un travail peut redémarrer sur une autre infrastructure et que toutes les données écrites dans un stockage temporaire sur l’instance précédente ne sont plus accessibles.

• Workers de runbook hybrides : vous pouvez éventuellement configurer votre propre infrastructure de calcul (machines virtuelles dans Azure, autres clouds ou environnement local) afin d’y exécuter des runbooks. Lorsque vous utilisez des Runbook Workers hybrides, vous êtes responsable de leur configuration pour répondre à vos exigences de fiabilité. Les workers de runbook hybrides ne sont pas couverts par cet article.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Vous êtes responsable de l’écriture de runbooks qui gèrent les erreurs temporaires dans les services et les API avec lesquels ils interagissent. Pour les runbooks textuels, implémentez une logique de nouvelle tentative à l’aide de boucles et de gestion des erreurs. Pour obtenir des conseils et des exemples, consultez Gérer les erreurs temporaires dans un script dépendant du temps. Pour les runbooks graphiques, configurez le comportement des nouvelles tentatives pour les activités de votre workflow. Pour plus de détails sur la configuration, consultez l’activité de nouvelle tentative dans les runbooks graphiques.

La maintenance de l’infrastructure ou d’autres événements affectant la plateforme peuvent interrompre les tâches de runbook. Concevez vos runbooks pour gérer ces interruptions :

• Implémentez des points de contrôle. Pour les runbooks de flux de travail PowerShell, utilisez des points de contrôle pour enregistrer la progression aux points clés de votre flux de travail. Si un travail est interrompu et redémarré, il peut reprendre à partir du dernier point de contrôle plutôt que de recommencer. Pour plus d’informations, consultez Utiliser des points de contrôle dans un flux de travail.

• Comprendre les limites du travail. Les travaux cloud ont des limites de partage équitable sur la durée d’exécution. Pour plus d’informations sur les limites d’exécution des travaux et leur application, consultez Exécution du Runbook.

• Stockez l’état persistant en externe. Les travaux ne conservent pas leur état entre les exécutions. Si un travail est interrompu et redémarré sur une autre instance, tout ce qui est écrit dans un stockage temporaire par la première exécution peut être perdu. Si vous devez conserver des données entre les exécutions du travail, stockez-les dans un stockage externe, comme Stockage Blob Azure ou une base de données.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Dans les régions prises en charge, les comptes Automation et les travaux cloud sont redondants entre zones, ce qui signifie que le service répartit vos ressources sur plusieurs zones de disponibilité. Microsoft active automatiquement la redondance de zone et ne nécessite aucune configuration.

Spécifications

Prise en charge des régions : lorsque vous déployez un compte Automation dans l’une des régions suivantes, il devient automatiquement redondant par zone :

Pour obtenir la liste actuelle des régions prises en charge, consultez la prise en charge des zones de disponibilité pour Azure Automation.

Coûts

Il n’y a pas de frais supplémentaires pour la redondance de zone. Pour l’automatisation des processus, la facturation est calculée en fonction de la durée d’exécution de vos tâches et de vos agents de surveillance. Pour plus d’informations, consultez Azure Automation tarification.

Configurez la prise en charge des zones de disponibilité

Lorsque vous créez un compte d’automatisation dans une région prise en charge, il est automatiquement redondant entre zones. Vous ne pouvez pas désactiver la redondance de zone. Pour plus d’informations, consultez la prise en charge des zones de disponibilité pour Azure Automation.

Comportement lorsque toutes les zones sont saines

Cette section décrit le comportement attendu lorsque votre compte Automation est redondant par zone et que toutes les zones de disponibilité de la région sont opérationnelles.

• Fonctionnement interzone : Les opérations de gestion des comptes Automation et les travaux dans le cloud sont automatiquement répartis sur l’ensemble des zones de disponibilité de la région. Une demande ou un travail peut être géré par n’importe quelle instance dans n’importe quelle zone de disponibilité.

• Réplication des données interzones : La configuration du compte Automation, les scripts runbook et d’autres ressources que vous déployez sur votre compte Automation sont répliquées de manière synchrone sur plusieurs zones de disponibilité.

Comportement lors d’une défaillance de zone

Cette section décrit à quoi s’attendre lorsque votre compte Automation est redondant interzone et qu’une panne survient dans l’une des zones de disponibilité de la région.

• Détection et réponse : La plateforme Azure Automation est chargée de détecter une défaillance dans une zone de disponibilité. Vous n’avez rien à faire pour initier un failover de zone.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Requêtes actives : toute exécution de travail en cours dans la zone défaillante peut être interrompue. Azure Automation démarre automatiquement une nouvelle tâche exécutée à l’aide de l’infrastructure dans des zones saines. Concevez vos runbooks pour qu’ils soient résilients aux pannes temporaires et aux interruptions afin qu’ils puissent redémarrer en toute sécurité.

• Perte de données attendue : Les travaux en cours d’exécution ne conservent pas leur état, de sorte qu’une défaillance de zone ne devrait pas entraîner de perte de données pour les travaux en cours. Si un travail doit stocker des données qu’il peut utiliser pour récupérer après une interruption, comme des points de contrôle, stockez ces informations dans un service de stockage cloud persistant comme stockage Azure ou une base de données.

  La configuration du compte Automation et les données de runbook sont répliquées entre les zones et restent accessibles même lorsqu’une zone n’est pas disponible.

• Temps d’arrêt attendu : Pendant une panne de zone, votre compte Automation peut rencontrer une brève interruption pendant que le service détecte l’échec et redistribue la charge de travail dans des zones saines.

• Redistribution: Le service rééquilibrée automatiquement la capacité entre les zones saines restantes. Les nouvelles exécutions de travaux, les observateurs et les planifications continuent de s’exécuter sur l’infrastructure des zones saines. La récupération ne dépend pas de la remise en service de la zone défaillante.

Récupération de la zone

Lorsqu’une zone défaillante est remise en service, Azure Automation la réintègre automatiquement dans la rotation des zones. Aucune action de votre part n’est nécessaire. Le service surveille l’intégrité de la zone et redistribue la charge de travail dans toutes les zones au fur et à mesure que les opérations normales reprendnt.

Tester les pannes de zone

Azure Automation gère le routage du trafic, le basculement et la récupération après incident liés aux zones pour les ressources redondantes par zone. Vous n’avez pas besoin d’initier quoi que ce soit, et vous n’avez pas besoin de valider les procédures de défaillance de la zone de disponibilité. Testez vos runbooks pour confirmer qu’ils sont résilients aux interruptions.

Résilience aux défaillances à l’échelle de la région

Azure Automation est un service à région unique. Si la région devient indisponible, votre compte Automation n’est pas disponible.

Solutions multirégions personnalisées pour la résilience

Vous pouvez déployer des comptes Automation distincts dans plusieurs régions et basculer entre eux si nécessaire. Vous êtes responsable du déploiement des comptes dans chaque région, de leur configuration appropriée, de la distribution des demandes entre les comptes et de la gestion du basculement si une région n’est pas disponible. Pour plus d’informations sur les approches que vous pouvez envisager, consultez la récupération d’urgence pour Azure Automation.

Sauvegarde et restauration

Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Que sont la redondance, la réplication et la sauvegarde ?.

Azure Automation ne fournit pas de sauvegarde intégrée pour la configuration de votre compte Automation ou le contenu du runbook. Conservez vos propres copies en dehors du service pour pouvoir les redéployer si nécessaire.

• Utilisez l’infrastructure en tant que code (IaC) pour configurer les comptes Automation. Définissez des comptes Automation et des ressources associées dans des fichiers Bicep, des modèles ARM ou Terraform. Stockez les modèles dans le contrôle de code source et utilisez votre pipeline de déploiement pour recréer l’environnement dans la même région ou une autre région. Incluez des certificats, des variables, des planifications et des références d’identifiants dans vos artefacts et processus de déploiement. Stockez des secrets dans des services tels que Azure Key Vault plutôt que d’incorporer des valeurs directement dans le code du runbook.

• Stockez les scripts de runbook dans la gestion de code source. Conservez la source pour PowerShell et Python runbooks dans un système de contrôle de code source tel que Git. Utilisez la gestion des versions, les branches et la revue des pull requests pour protéger la qualité des scripts et permettre un retour à des versions fiables.

• Sauvegardez l’état à partir du stockage de données approprié. Les travaux ne conservent pas leur état. Si vous devez conserver des journaux de travail détaillés ou d’autres données générées par vos runbooks, stockez-le dans un autre service de stockage ou de base de données Azure et sauvegardez-le à partir de là.

Résilience à la suppression accidentelle

Si vous supprimez accidentellement un compte Automation, vous pouvez le restaurer dans une fenêtre de temps limitée. Pour plus d’informations, consultez Restaurer un compte Automation supprimé.

Résilience à la maintenance du service

Microsoft applique régulièrement des mises à jour de service et effectue d’autres maintenances. La plateforme Azure gère automatiquement ces activités, ce qui garantit que la maintenance est fluide et transparente pour vous. Aucun temps d'arrêt n'est prévu pendant les événements de maintenance, sauf si vous avez été informé via la maintenance planifiée d'Azure Service Health.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Contenu connexe

• Fiabilité dans Azure
• Récupération d’urgence pour Azure Automation
• Gérer des runbooks dans Azure Automation
• Exécution d’un runbook dans Azure Automation