Fiabilité des sandboxes d’Azure Container Apps (préversion)

Azure Container Apps bacs à sable fournissent des environnements isolés pour l’exécution du code. Chaque bac à sable s’exécute dans une machine virtuelle légère (microVM) qui démarre en moins d’une seconde et peut conserver son état en mémoire en cas de suspension. Le service prend en charge la fiabilité des charges de travail de bac à sable via les fonctionnalités que vous configurez et les fonctionnalités que la plateforme gère en votre nom.

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 les bacs à sable Container Apps résilients aux erreurs temporaires, aux défaillances de zone de disponibilité, aux défaillances à l’échelle de la région et à la maintenance du service. Il décrit également les options de sauvegarde et de restauration et les informations clés sur le contrat de niveau de service (SLA).

Important

Les bacs à sable Container Apps sont actuellement en préversion. Consultez les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure pour les conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale.

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production, nous vous recommandons de :

  • Stockez des données durables en dehors de la mémoire du bac à sable et choisissez une option de redondance de stockage qui correspond à vos objectifs de récupération. Utilisez des volumes de bac à sable pour les données qui doivent être conservées lorsqu’un bac à sable s’arrête. Pour la résilience à une défaillance à l’échelle de la région, utilisez un magasin de données externe qui réplique les données dans une autre région.

    Lorsque vous utilisez Stockage Blob Azure, le stockage géoredondant (GRS) réplique les données dans une région jumelée. Pour les régions non appariées, déployez des comptes de stockage distincts et configurez une méthode de réplication prise en charge, telle que la réplication d’objets pour les blobs de blocs. Pour plus d’informations, consultez les solutions multirégions personnalisées pour Stockage Blob Azure.

  • Déployez des groupes sandbox distincts dans plusieurs régions si votre objectif de disponibilité ne peut pas être atteint avec un déploiement dans une seule région. Pour plus d’informations, consultez Résilience aux défaillances à l’échelle de la région.

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

Azure Container Apps fournit des options de calcul distinctes pour les applications, les travaux, les sessions dynamiques et les bacs à sable. Les groupes de bac à sable ne nécessitent pas d’environnement Container Apps. Pour plus d’informations sur la fiabilité des autres composants Container Apps, consultez Fiabilité dans Azure Container Apps.

Les principales ressources des bacs à sable Container Apps sont les suivantes :

  • Groupe de bacs à sable : Un groupe de bacs à sable est la limite de gestion régionale de niveau supérieur pour les bacs à sable et utilise le Microsoft.App/sandboxGroups type de ressource. Tous les bacs à sable, images de disque, captures instantanées, volumes et valeurs de configuration sensibles (secrets) sont limités à un groupe de bacs à sable.

  • Bac à sable : Chaque bac à sable est une microVM légère et isolée qui s’exécute à partir d’une image de disque ou d’une capture instantanée et possède son propre processeur, mémoire, disque local et limite réseau.

    Une image de disque est une image de conteneur OCI (Open Container Initiative) convertie pour servir de système de fichiers racine d’un bac à sable.

    Un instantané est une capture à un point dans le temps de l’état complet d’un bac à sable qui persiste indépendamment du bac à sable source.

    L’état d’un sandbox peut être en cours d’exécution ou arrêté. Lorsqu’un bac à sable s’arrête automatiquement ou à la demande, il libère ses ressources de calcul. Le mode mémoire conserve l’image mémoire complète du bac à sable et le disque local. Le mode disque conserve uniquement le disque local, de sorte que la microVM et ses processus redémarrent lorsque vous reprenez le bac à sable.

  • Volumes : Le disque local appartient à un bac à sable individuel. Un volume de bac à sable fournit un stockage persistant qui existe indépendamment d’un bac à sable individuel. Vous pouvez monter Stockage Blob Azure volumes en plusieurs bacs à sable en même temps, tandis que les volumes de disque de données sauvegardés par Stockage sur disque Azure peuvent monter en un seul bac à sable à la fois. Le service de stockage sous-jacent détermine les options de durabilité et de récupération des données du volume.

Pour plus d’informations sur l’architecture et les ressources de bac à sable, consultez Azure Container Apps vue d’ensemble des bacs à sable.

Architecture physique

Les sandboxes s’exécutent sur plusieurs clusters de calcul indépendants qu’exploite Microsoft. Vous êtes chargé de configurer les groupes d’environnements de test, les environnements de test et les autres ressources que vous déployez. Microsoft est responsable du déploiement du cluster, de la configuration, de la gestion des capacités, de la surveillance de l’état de santé et de la maintenance. Vous ne sélectionnez pas, déployez, configurez ou gérez les clusters. Le service planifie de nouveaux environnements de test, redémarre les environnements de test arrêtés sur des clusters sains et redirige les placements afin d’éviter les clusters défaillants.

Microsoft gère des magasins de données d’état redondants pour la configuration du service, les métadonnées du bac à sable et les artefacts tels que les images de disque et les instantanés.

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, voir Recommandations concernant le traitement des pannes transitoires.

Lorsque vous utilisez les environnements de bac à sable de Container Apps, tenez compte des défaillances transitoires dans les parties suivantes de votre solution :

  • Opérations de gestion des bacs à sable : Lorsque votre automatisation gère des groupes de bacs à sable, des bacs à sable ou des ressources associées, réessayez les requêtes qui échouent en raison d’erreurs temporaires et appliquez une stratégie de temporisation exponentielle. Limitez le nombre de tentatives de nouvelle tentative, et réessayez uniquement les opérations qui sont sécurisées pour se répéter.

  • Code en cours d’exécution dans un bac à sable : Implémentez la gestion des erreurs temporaires pour les appels à des API externes, des bases de données et d’autres services. Suivez les instructions de nouvelle tentative pour chaque dépendance, car le comportement et les opérations de nouvelle tentative qui sont sûrs à répéter varient selon le service.

Résilience aux échecs de zone de disponibilité

Les Container Apps Sandboxes ne prennent pas en charge le déploiement dans une zone de disponibilité spécifique ni la redondance interzone pour un groupe de sandboxes. Pour rendre votre charge de travail résiliente aux défaillances de zone de disponibilité, déployez des groupes de bacs à sable distincts dans plusieurs régions. Pour plus d’informations, consultez Résilience aux défaillances à l’échelle de la région.

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

Container Apps Sandboxes est un service à région unique. Si la région devient indisponible, vos groupes de bacs à sable et les bacs à sable qu’ils contiennent sont également indisponibles. Le service ne réplique pas les groupes de bacs à sable ni les bacs à sable entre les régions géographiques, et il n’effectue pas automatiquement de basculement vers une autre région. Toutefois, vous pouvez déployer des groupes de bac à sable distincts dans plusieurs régions. Vous êtes responsable de la mise à disposition des dépendances dans chaque région et de la gestion de la distribution et du basculement des charges de travail. Pour plus d’informations, consultez les solutions multirégions personnalisées pour la résilience.

Lors d’une panne touchant toute une région, vous risquez de perdre tout état stocké uniquement en mémoire dans un sandbox en cours d’exécution. Les groupes de bacs à sable, les bacs à sable et les artefacts gérés par le service dans la région concernée restent indisponibles jusqu’à ce que la région récupère.

Les volumes de bac à sable fournissent un stockage qui persiste au-delà du cycle de vie d’un bac à sable individuel. En cas de défaillance à l’échelle d’une région, la disponibilité du volume et la récupération dépendent du service de stockage sous-jacent et de sa configuration. Les environnements de bac à sable Container Apps ne fournissent ni réplication entre régions ni basculement pour les données de volume. Au lieu de cela, le service de stockage fournit ces fonctionnalités lorsqu’il est configuré. Par exemple, pour plus d’informations sur les volumes Stockage Blob Azure, consultez Fiabilité dans Stockage Blob Azure.

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

Azure Container Apps Sandboxes ne prend pas en charge la coordination des déploiements multirégions ni la réplication des groupes de sandboxes, des sandboxes ou des ressources qui leur sont associées entre les régions. Pour créer une solution multirégion personnalisée, vous avez les responsabilités suivantes :

  • Déploiements régionaux et dépendances : Déployez un groupe de bac à sable distinct dans chaque région que vous envisagez d’utiliser. Conservez la configuration, les images de disque, les secrets et d’autres dépendances disponibles dans chaque région.

  • Détection des défaillances et récupération de charge de travail : Configurez votre application ou couche d’orchestration pour détecter quand une région n’est pas disponible, diriger la création et le traitement de la charge de travail du bac à sable vers une région saine et déterminer comment redémarrer le travail interrompu.

  • Routage du trafic : Si les clients se connectent via des points de terminaison spécifiques à la région que votre application expose, utilisez un service d’équilibrage de charge global, tel que Azure Front Door ou Azure Traffic Manager, pour router le trafic vers un point de terminaison sain.

  • Réplication et récupération des données : Stockez tout état requis après le basculement dans un magasin de données externe qui prend en charge la réplication et la récupération interrégions. Si un service de stockage sous-jacent fournit une réplication interrégion pour les données de volume, ce service détermine le comportement de réplication et de basculement. Les environnements de bac à sable d’Azure Container Apps ne répliquent pas les données de volume entre les régions et n’en assurent pas le basculement.

Sauvegarde et restauration

N’utilisez pas la mémoire du bac à sable ou le disque local comme seul magasin de données durable. La suspension d’un bac à sable conserve son disque local et, en mode mémoire, son état de mémoire. Vous pouvez également créer des instantanés qui existent indépendamment de la sandbox source. L’état suspendu et les instantanés restent circonscrits au groupe de bacs à sable régional et ne constituent pas des sauvegardes entre régions.

Utilisez un volume de bac à sable pour les données qui doivent persister au-delà du cycle de vie d’un bac à sable individuel. Le service de stockage sous-jacent et sa configuration déterminent les capacités de sauvegarde et de restauration des données de volume. Pour les magasins de données externes que vous gérez, vous êtes responsable de la configuration de la sauvegarde et de la récupération interrégion pour répondre à vos objectifs de durabilité et de récupération.

Pour recréer votre déploiement de bac à sable après une suppression accidentelle ou une défaillance à l’échelle de la région, stockez la configuration de votre groupe de bacs à sable dans des modèles d’infrastructure en tant que code contrôlés par la version, tels que Bicep ou Terraform. Conservez vos images de disque source dans un registre qui répond à vos besoins de récupération.

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 ?.

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. Pendant les opérations de maintenance, vous pouvez observer de brèves interruptions. En règle générale, ces interruptions durent quelques secondes. Assurez-vous que les applications clientes sont configurées pour gérer les erreurs temporaires afin qu’elles soient résilientes aux brèves interruptions.

Lorsque la maintenance affecte un bac à sable en cours d’exécution, la plateforme en préserve l’état, le déplace vers des ressources de calcul saines et en reprend automatiquement l’exécution. Pour les bacs à sable qui utilisent le mode mémoire, la plateforme conserve la mémoire et l’état du disque local. Pour les bacs à sable qui utilisent le mode disque, la plateforme conserve uniquement l’état du disque local.

Contrat de niveau de service

Azure Container Apps Sandboxes n’offre pas d’accord de niveau de service (SLA) en matière de disponibilité. Les services de stockage qui prennent en charge vos volumes de l’environnement sandbox et les magasins de données externes utilisés par votre solution peuvent avoir des SLA distincts. Pour plus d’informations, consultez Contrats de niveau de service pour les services en ligne.

Contenu connexe

  • Last updated on