Fiabilité dans les applications de conteneur Azure

  • Article

Cet article décrit la prise en charge de la fiabilité dans Azure Container Apps, et couvre la résilience régionale avec les zones de disponibilité et la résilience interrégion avec la récupération d’urgence. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez Fiabilité Azure.

Prise en charge des zones de disponibilité

Les zones de disponibilité Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.

Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.

Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.

Azure Container Apps utilise des zones de disponibilité dans les régions où elles sont disponibles pour assurer une protection à haute disponibilité de vos applications et de vos données contre les défaillances des centres de données.

En activant la fonctionnalité de redondance de zone de Container Apps, les réplicas sont automatiquement distribués dans les zones de la région. Le trafic est équilibré entre les réplicas. Si une panne de zone se produit, le trafic est automatiquement acheminé vers les réplicas dans les zones restantes.

Remarque

Il n’y a pas de frais supplémentaires pour activer la redondance de zone, mais elle offre des avantages uniquement lorsque vous avez 2 réplicas ou plus, 3 ou plus étant idéal, car la plupart des régions qui prennent en charge la redondance de zone ont 3 zones.

Prérequis

Azure Container Apps offre la même prise en charge de la fiabilité, quel que soit votre type de plan.

Azure Container Apps utilise zones de disponibilité dans les régions où elles sont disponibles. Pour obtenir la liste des régions qui prennent en charge des zones de disponibilité, consultez Régions Azure avec zones de disponibilité.

Améliorations du SLA

Il n’y a pas d’augmentation des contrats SLA pour Azure Container Apps. Pour plus d’informations sur les contrats SLA Azure Container Apps, consultez Contrat de niveau de service pour Azure Container Apps.

Créer une ressource avec la zone de disponibilité activée

Configurer la redondance de zone dans votre environnement Container Apps

Pour tirer parti des zones de disponibilité, vous devez activer la redondance de zone lorsque vous créez un environnement Container Apps. L’environnement doit inclure un réseau virtuel avec un sous-réseau disponible. Pour garantir une distribution appropriée des réplicas, définissez le nombre minimal de réplicas de votre application sur trois.

Activer la redondance de zone via le portail Azure

Pour créer une application conteneur dans un environnement avec redondance de zone activée à l’aide du Portail Azure :

  1. Accédez au portail Azure.
  2. Recherchez Container Apps dans le champ de recherche supérieur.
  3. Sélectionnez Container Apps.
  4. Sélectionnez Créer nouveau dans le champ Environnement Container Apps pour ouvrir le panneau Créer un environnement Container Apps .
  5. Saisissez le nom de l'environnement.
  6. Sélectionnez Activé pour le champ de redondance de zone .

La redondance de zone nécessite un réseau virtuel avec un sous-réseau d’infrastructure. Vous pouvez choisir un réseau virtuel existant ou en créer un. Lors de la création d’un réseau virtuel, vous pouvez accepter les valeurs fournies pour vous ou personnaliser les paramètres.

  1. Sélectionnez l’onglet Mise en réseau.
  2. Pour affecter un nom de réseau virtuel personnalisé, sélectionnez Créer une dans le champ réseau virtuel .
  3. Pour affecter un nom de sous-réseau d’infrastructure personnalisé, sélectionnez Créer nouveau dans le champ Sous-réseau d’infrastructure .
  4. Vous pouvez sélectionner Interne ou Externe pour l’adresse IP virtuelle.
  5. Sélectionnez Créer.

Screenshot of Networking tab in Create Container Apps Environment page.

Activer la redondance de zone avec Azure CLI

Créez un réseau virtuel et un sous-réseau d’infrastructure à inclure dans l’environnement Container Apps.

Lorsque vous utilisez ces commandes, remplacez-les <PLACEHOLDERS> par vos valeurs.

Remarque

L’environnement Consommation uniquement nécessite un sous-réseau dédié avec une plage CIDR de /23 ou plus. L’environnement des profils de charge de travail nécessite un sous-réseau dédié avec une plage CIDR de /27 ou plus grande. Pour en savoir plus sur le dimensionnement du sous-réseau, consultez la vue d’ensemble de l’architecture réseau .

az network vnet create \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <VNET_NAME> \
  --location <LOCATION> \
  --address-prefix 10.0.0.0/16

az network vnet subnet create \
  --resource-group <RESOURCE_GROUP_NAME> \
  --vnet-name <VNET_NAME> \
  --name infrastructure \
  --address-prefixes 10.0.0.0/21

Ensuite, recherchez l’ID de sous-réseau d’infrastructure.

INFRASTRUCTURE_SUBNET=`az network vnet subnet show --resource-group <RESOURCE_GROUP_NAME> --vnet-name <VNET_NAME> --name infrastructure --query "id" -o tsv | tr -d '[:space:]'`

Enfin, créez l'environnement avec le paramètre --zone-redundant. L’emplacement doit être le même emplacement que celui utilisé lors de la création du réseau virtuel.

az containerapp env create \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --location "<LOCATION>" \
  --infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
  --zone-redundant
Activer la redondance de zone avec Azure CLI

Remarque

Le portail Azure ne montre pas si la redondance de zone est activée.

Utilisez la commande az container app env show pour vérifier que la redondance de zone est activée pour votre environnement Container Apps.

az containerapp env show \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --subscription <SUBSCRIPTION_ID>

La commande retourne une réponse JSON. Vérifiez que la réponse contient "zoneRedundant": true.

Techniques de déploiement sécurisées

Lorsque vous configurez redondance de zone dans votre application conteneur, les réplicas sont distribués automatiquement dans les zones de la région. Une fois les réplicas distribués, le trafic est équilibré entre eux. Si une panne de zone se produit, le trafic est automatiquement acheminé vers les réplicas de la zone restante.

Vous devez toujours utiliser des techniques de déploiement sécurisées telles que déploiement bleu-vert. Azure Container Apps ne fournit pas de déploiement ou de mise à niveau d’une zone à la fois.

Si vous avez activé affinité de sessionet qu’une zone tombe en panne, les clients de cette zone sont routés vers de nouveaux réplicas, car les réplicas précédents ne sont plus disponibles. Tout état associé aux réplicas précédents est perdu.

Migration de zones de disponibilité

Pour tirer parti des zones de disponibilité, activez la redondance de zone lorsque vous créez l’environnement Container Apps. L’environnement doit inclure un réseau virtuel avec un sous-réseau disponible. Vous ne pouvez pas migrer un environnement Container Apps existant de la prise en charge de la zone d’indisponibilité vers la prise en charge des zones de disponibilité.

Récupération d’urgence et continuité d’activité inter-région

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

Dans le cas peu probable d’une panne de région complète, vous avez la possibilité d’utiliser l’une des deux stratégies suivantes :

  • Récupération manuelle : déployez manuellement dans une nouvelle région ou attendez que la région soit récupérée, puis redéployez manuellement tous les environnements et applications.

  • Récupération résiliente : commencez par déployer vos applications conteneur à l’avance dans plusieurs régions. Utilisez ensuite Azure Front Door ou Azure Traffic Manager pour gérer les demandes entrantes, pointant le trafic vers votre région primaire. Si une panne se produit, vous pouvez alors éloigner le trafic de la région affectée. Pour plus d’informations, consultez la réplication interrégion dans Azure.

Notes

Quelle que soit la stratégie que vous choisissez, assurez-vous que vos fichiers de configuration de déploiement se trouvent dans le contrôle de code source afin de faciliter le redéploiement si nécessaire.

Autres conseils

Les ressources suivantes peuvent vous aider à créer votre propre plan de récupération d’urgence :

Étapes suivantes

Fiabilité dans Azure