Partager via

Fiabilité dans Azure Container Instances

Cet article décrit la prise en charge de la fiabilité dans Azure Container Instances, qui offre un moyen simple d’exécuter des conteneurs Linux ou Windows dans Azure, sans avoir à gérer les machines virtuelles ou à adopter un service de niveau supérieur plus complexe.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour 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 Container Instances résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il met en évidence certaines informations clés sur le contrat de niveau de service Azure Container Instances (SLA).

Recommandations de déploiement de production pour la fiabilité

Pour augmenter la fiabilité des applications de production basées sur Container Instances, nous vous recommandons d’effectuer les actions suivantes :

Vue d’ensemble de l’architecture de fiabilité

Pour utiliser Container Instances, vous déployez un groupe de conteneurs. Un groupe de conteneurs contient un ou plusieurs conteneurs. Chaque conteneur est créé à partir d’une image conteneur, qui est stockée dans un registre tel qu’Azure Container Registry.

Tous les conteneurs d’un groupe de conteneurs sont déployés ensemble en tant qu’unité logique unique et partagent la même infrastructure physique.

Le diagramme suivant montre la relation entre les groupes de conteneurs, les conteneurs et les images.

Diagramme montrant un groupe de conteneurs avec deux conteneurs. Chaque conteneur utilise une image distincte dans un registre.

Container Instances fournit les fonctionnalités suivantes pour gérer les groupes de conteneurs :

  • NGroups (préversion) fournit un ensemble de fonctionnalités permettant de gérer plusieurs groupes de conteneurs associés. Lorsque vous créez un NGroup, vous définissez le nombre de groupes de conteneurs à créer. Container Instances fournit des fonctionnalités telles que les déploiements de mise à niveau automatisés et la répartition des groupes de conteneurs entre les zones de disponibilité.

  • Les pools de secours créent un pool de groupes de conteneurs préprovisionnés qui peuvent être utilisés en réponse au trafic entrant. Les pools de secours sont conçus pour optimiser la création de groupes de conteneurs et ne sont pas destinés à augmenter votre résilience.

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.

Les Kits de développement logiciel (SDK) fournis par Microsoft gèrent généralement les fautes temporaires. Étant donné que vous hébergez vos propres applications sur Container Instances, prenez des mesures pour réduire le risque d’erreurs temporaires :

  • Exécutez plusieurs groupes de conteneurs pour des charges de travail importantes pour vous assurer qu’une défaillance dans un conteneur ou un groupe de conteneurs n’affecte pas l’ensemble de votre application.

  • Construisez votre code d’application pour qu’il soit résilient aux erreurs temporaires dans les services auxquels vous vous connectez, par exemple en utilisant des stratégies de réessai avec stratégies de recul.

Pour plus d’informations sur d’autres erreurs qui peuvent se produire au moment de l’exécution et comment y répondre, consultez Problèmes lors de l’exécution du groupe de conteneurs.

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.

Container Instances prend en charge les zones de disponibilité de différentes façons, selon la façon dont vous déployez vos groupes de conteneurs :

  • Groupes de conteneurs créés manuellement : Un groupe de conteneurs individuel est une ressource zonale , ce qui signifie qu’elle peut être déployée dans une seule zone de disponibilité que vous sélectionnez. Tous les conteneurs au sein du groupe sont déployés dans la même zone de disponibilité. Si cette zone de disponibilité a une panne, le groupe de conteneurs et tous ses conteneurs peuvent rencontrer des temps d’arrêt.

    Le diagramme suivant montre un groupe de conteneurs qui a été déployé manuellement dans la zone de disponibilité 1 :

    Diagramme montrant un groupe de conteneurs avec deux conteneurs déployés dans une seule zone de disponibilité.

    Note

    Pour vous assurer que votre application continue à s’exécuter quand une seule zone de la région subit une panne, nous vous recommandons de créer au moins deux groupes de conteneurs entre deux zones de disponibilité différentes.

    Si vous ne spécifiez pas de zones de disponibilité à utiliser pour votre groupe de conteneurs, il s’agit de zones nonzonales ou régionales, ce qui signifie qu’il peut être placé dans une zone de disponibilité au sein de la région ou dans la même zone. Si une zone de disponibilité dans la région a un problème, votre groupe de conteneurs risque de subir une interruption.

  • NGroups : Lorsque vous déployez un groupe NGroup, vous pouvez spécifier une ou plusieurs zones dans lesquelles le déployer. Si vous déployez un NGroup sur deux ou plusieurs zones, il s'agit d'un groupe N à redondance zonale, et une panne d’une zone de disponibilité cause uniquement des problèmes pour les groupes de conteneurs au sein de la zone affectée.

    Le diagramme suivant montre un groupe NGroup déployé sur trois zones de disponibilité :

    Diagramme montrant un groupe NGroup avec trois groupes de conteneurs, déployés dans trois zones de disponibilité.

    Si vous ne spécifiez pas de zones de disponibilité à utiliser pour votre groupe NGroup, il est nonzonal et peut rencontrer un temps d’arrêt si une zone de disponibilité dans la région a un problème.

  • Pools de secours : Lorsque vous déployez un pool de secours, vous pouvez éventuellement spécifier une ou plusieurs zones. La plateforme peut demander des conteneurs dans les zones que vous sélectionnez.

    Toutefois, les pools en veille ne sont pas redondants ni résilients aux zones, car il n'est pas garanti que les conteneurs soient créés dans plusieurs zones. Si une panne de zone se produit, il est possible que tous les conteneurs du pool soient placés dans la zone affectée.

    Étant donné que les pools de secours ne sont pas conçus pour prendre en charge la résilience aux défaillances de zone, ce guide ne décrit pas le comportement détaillé des pools de secours avec des zones de disponibilité.

    Important

    Les pools de secours ne sont pas conçus pour être résilients à la zone. Ils ne doivent pas être utilisés pour les charges de travail qui nécessitent une résilience aux défaillances de zone.

Soutien régional

Les déploiements de groupes de conteneurs zonaux sont pris en charge dans toutes les régions avec des zones de disponibilité.

Spécifications

  • Les déploiements zonaux sont disponibles pour les groupes de conteneurs Linux et Windows Server 2019.

  • Pour sélectionner une zone de disponibilité, vous devez utiliser la référence SKU Standard. Les groupes de conteneurs zonaux ne sont pas disponibles avec la référence SKU confidentielle.

Considérations

Les conteneurs Spot ne prennent pas en charge les zones de disponibilité et sont toujours nonzonaux.

Coûts

Il n’existe aucun coût supplémentaire pour configurer des zones de disponibilité pour un groupe de conteneurs.

Configurez la prise en charge des zones de disponibilité

  • Créez des groupes de conteneurs avec prise en charge des zones de disponibilité. L’approche que vous utilisez pour configurer des zones de disponibilité dépend de la façon dont vous créez des groupes de conteneurs.

    • Groupes de conteneurs créés manuellement : Pour créer un groupe de conteneurs zonal dans une zone spécifique, vous pouvez utiliser l’une des méthodes suivantes :

    • NGroups : Vous pouvez déployer un groupe NGroup redondant interzone à l’aide d’un fichier Bicep ou d’un modèle ARM et en spécifiant plusieurs zones. Pour plus d’informations, consultez NGroups avec l’exemple de zones.

    • Pools de secours : Vous pouvez déployer un pool de secours qui utilise des zones de disponibilité en spécifiant une ou plusieurs zones lorsque vous créez ou mettez à jour le pool. Toutefois, les conteneurs peuvent ne pas être créés dans plusieurs zones. Les pools de secours ne doivent pas être utilisés pour les charges de travail qui nécessitent une résilience aux défaillances de zone. Pour plus d’informations, consultez Créer un pool de secours pour Container Instances.

  • Activer la prise en charge des zones de disponibilité sur les ressources existantes. L’approche que vous utilisez pour configurer des zones de disponibilité dépend de la façon dont vous créez des groupes de conteneurs.

    • Groupes de conteneurs créés manuellement : Vous ne pouvez pas activer les zones de disponibilité sur un groupe de conteneurs nonzonal existant. Vous devez supprimer le groupe de conteneurs et créer un groupe de conteneurs zonal.

    • NGroups : Vous ne pouvez pas activer les zones de disponibilité sur un groupe NGroup nonzonal existant. Vous devez supprimer le NGroup et créer un NGroup redondant interzone.

    • Pools de secours : Vous ne pouvez pas activer les zones de disponibilité sur un pool de secours nonzonal existant. Vous devez supprimer le groupe de conteneurs et créer un pool de secours qui utilise plusieurs zones de disponibilité.

  • Déplacez des groupes de conteneurs entre des zones ou désactivez la prise en charge des zones de disponibilité. L’approche que vous utilisez pour modifier les zones de disponibilité dépend de la façon dont vous créez des groupes de conteneurs.

    • Groupes de conteneurs créés manuellement : Pour modifier la zone de disponibilité d’un groupe de conteneurs, vous devez supprimer le groupe de conteneurs et créer un autre groupe de conteneurs avec la nouvelle zone de disponibilité. Pour savoir comment supprimer le groupe de conteneurs, consultez les ressources suivantes :

    • NGroups : Vous pouvez ajouter des zones à un NGroup, mais vous ne pouvez pas supprimer de zones.

    • Pools de secours : Vous pouvez ajouter des zones à un pool de secours, mais vous ne pouvez pas supprimer de zones.

Distribution de groupes de conteneurs

La façon dont les groupes de conteneurs sont distribués entre les zones de disponibilité dépend de la façon dont vous déployez vos groupes de conteneurs.

  • Groupes de conteneurs créés manuellement : Vous êtes responsable de la distribution de vos groupes de conteneurs créés manuellement sur plusieurs zones de disponibilité.

  • NGroups : Pendant les opérations de mise à l’échelle, les groupes NGroups suppriment de manière aléatoire les instances, ce qui peut ne pas maintenir une répartition entre les zones de disponibilité. Les opérations de scale-out tentent de rééquilibrer la répartition entre les zones.

  • Pools de secours : Un pool de secours peut créer des conteneurs dans l’une des zones de disponibilité que vous configurez sur le pool. Toutefois, les conteneurs peuvent ne pas être créés dans plusieurs zones. Les pools de secours ne doivent pas être utilisés pour les charges de travail qui nécessitent une résilience aux défaillances de zone.

Planification de capacité et gestion

Pour préparer l’échec de la zone de disponibilité, envisagez de surprovisionner le nombre de groupes de conteneurs que vous déployez. Cette approche permet à la solution de tolérer une perte de capacité et de continuer à fonctionner sans dégradation des performances. Pour plus d’informations, consultez Gérer la capacité à l’aide du surprovisionnement.

L’approche que vous utilisez pour surprovisionner des groupes de conteneurs dépend de la façon dont vous déployez vos groupes de conteneurs.

  • Groupes de conteneurs créés manuellement : Vous êtes responsable de la planification de la capacité de vos groupes de conteneurs créés manuellement, notamment la planification du nombre de groupes de conteneurs à déployer dans chaque zone.

  • NGroup : Envisagez de surprovisionner la capacité de votre groupe NGroup pour tolérer la perte d’une zone.

  • Pools de secours : Les pools de secours ne sont pas conçus pour être résilients aux défaillances de zone. Envisagez d’utiliser plusieurs pools de secours dans différentes zones ou utilisez NGroups.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qui doit être attendu lorsque les ressources Container Instances sont configurées pour la prise en charge des zones de disponibilité et que toutes les zones de disponibilité sont opérationnelles.

  • Routage du trafic entre les zones : Vous êtes responsable du routage du trafic vers vos conteneurs. Par exemple, vous pouvez utiliser Azure Application Gateway comme passerelle et équilibreur de charge pour vos groupes de conteneurs.

    Si vous utilisez des pools NGroups ou de secours, vous êtes responsable de l’équilibrage de charge sur chaque conteneur. Vous devez également configurer votre système de routage du trafic pour détecter l’intégrité de chaque groupe de conteneurs et rediriger le trafic vers un autre groupe si nécessaire.

  • Réplication des données entre les zones : Les conteneurs et les groupes de conteneurs sont non persistants. Vous pouvez joindre votre propre partage de fichiers ou vous connecter à des bases de données ou à d’autres services de stockage à partir de vos applications. Vous êtes responsable de vous assurer que ces partages de fichiers et services de stockage sont résilients par zone. Passez en revue les guides de fiabilité de chaque service pour comprendre comment rendre chaque zone de composant résiliente.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque les ressources Container Instances sont configurées pour la prise en charge de la zone de disponibilité et qu’il existe une panne de zone de disponibilité.

  • Détection et réponse : La responsabilité de la détection des défaillances de zone et de la réponse associée dépend de la façon dont vous déployez vos groupes de conteneurs.

    • Groupes de conteneurs créés manuellement : Vous devez détecter la perte d’une zone de disponibilité et lancer un basculement vers un groupe de conteneurs secondaire que vous créez dans une autre zone de disponibilité.

    • NGroups : La plateforme Container Instances est chargée de détecter une défaillance dans une zone de disponibilité et de répondre.

      Toutefois, vous êtes responsable de l’acheminement du trafic vers des conteneurs dans une zone saine.

    • Pools de secours : La plateforme Container Instances n’est pas garantie de répondre aux défaillances de zone pour les pools de secours. Les pools de secours ne doivent pas être utilisés pour les charges de travail qui nécessitent une résilience aux défaillances 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.

  • Demandes actives : En cas d’échec d’une zone, tous les conteneurs s’exécutant dans cette zone vont vraisemblablement être arrêtés, y compris tout travail actif qu’ils gèrent.

  • Perte de données attendue : Étant donné que les conteneurs et les groupes de conteneurs sont sans état, il n’y a aucune perte de données attendue à partir d’une défaillance de zone. Toutefois, vous devez vous assurer que chaque composant de votre charge de travail est résilient dans la zone, y compris les services de stockage et les bases de données.

  • Temps d’arrêt attendu : Le temps d’arrêt que vous pouvez attendre d’une défaillance de zone dépend de la façon dont vous déployez vos groupes de conteneurs.

    • Groupes de conteneurs créés manuellement : Pour les groupes de conteneurs zonaux, lorsqu’une zone n’est pas disponible, votre groupe de conteneurs et ses conteneurs ne sont pas disponibles tant que la zone de disponibilité n’est pas récupérée.

    • NGroups : Pour les groupes NGroups, si une zone tombe en panne, votre application reste disponible, car les groupes de conteneurs restants dans les groupes NGroups continuent à s’exécuter dans d’autres zones. Aucun temps d’arrêt n’est attendu.

    • Pools de secours : Les pools de secours ne fournissent pas de résilience de zone. Si tous les groupes de conteneurs du pool de secours se trouvent dans une seule zone, il est possible que tous les groupes de conteneurs et leurs conteneurs deviennent indisponibles tant que la zone de disponibilité n’est pas récupérée.

  • Réacheminement du trafic : Étant donné que vous êtes responsable du routage du trafic vers vos conteneurs, vous êtes également responsable de la réacheminement du trafic si un groupe de conteneurs échoue en raison d’une panne de zone de disponibilité.

Récupération de la zone

Une fois la zone récupérée, la plateforme Azure redémarre automatiquement les groupes de conteneurs arrêtés. Aucune action du client n’est nécessaire.

Tester les pannes de zone

Il n’existe aucun moyen de simuler une panne de la zone de disponibilité qui contient votre groupe de conteneurs. Toutefois, vous pouvez configurer manuellement des passerelles en amont ou des équilibreurs de charge pour rediriger le trafic vers un autre groupe de conteneurs dans une autre zone de disponibilité.

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

Container Instances est un service à région unique. Si la région devient indisponible, vos groupes de conteneurs et ses conteneurs sont également indisponibles.

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

Vous pouvez éventuellement déployer des groupes de conteneurs distincts dans plusieurs régions. Vous êtes responsable du déploiement et de la configuration des groupes de conteneurs dans chaque région. Vous devez également configurer l’équilibrage de charge à l’aide d’un service comme Azure Traffic Manager ou Azure Front Door. Vous êtes responsable de toute synchronisation, basculement et rétablissement des données.

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 contrats SLA pour les services en ligne.

Contenu connexe

  • Last updated on