Fiabilité dans Azure Application Gateway v2

Azure Application Gateway est un équilibreur de charge de trafic web que vous pouvez utiliser pour gérer le trafic vers vos applications web. Il fournit des fonctionnalités avancées telles que la mise à l’échelle automatique, la redondance de zone, les adresses IP virtuelles statiques (VIP) et l’intégration du pare-feu d’applications web (WAF) pour fournir des services de remise d’applications hautement disponibles et sécurisés.

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 Application Gateway v2 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 également en évidence certaines informations clés sur le contrat de niveau de service Application Gateway v2 (SLA).

Recommandations concernant le déploiement de production

Pour en savoir plus sur le déploiement d’Application Gateway afin de répondre aux exigences de fiabilité de votre solution, et sur l’impact de la fiabilité sur d’autres aspects de votre architecture, consultez les meilleures pratiques d’architecture pour Application Gateway dans le cadre Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Application Gateway est un service managé. Il est important de comprendre certains éléments clés de l’architecture de service afin que vous puissiez prendre des décisions de fiabilité éclairées.

• Passerelle: Lorsque vous déployez Application Gateway, vous déployez une passerelle, qui est la ressource Azure avec laquelle vous travaillez.

• Instances: Une instance est une unité unique de la passerelle. Une passerelle a plusieurs instances. Chaque instance a sa propre adresse IP privée, gère le trafic et route les demandes.

  Important

  Pour la haute disponibilité, chaque passerelle est toujours créée avec au moins deux instances. Toutefois, le portail Azure peut indiquer que votre passerelle a une seule instance, même si elle a en fait deux.

  La plateforme gère automatiquement la création d'instances, la surveillance de l'état de santé et le remplacement des instances défectueuses. Il gère également la suppression normale d’instances pendant les événements de mise à l’échelle. Ce processus est appelé drainage de connexion.

  Le diagramme suivant illustre une passerelle avec deux instances :

  

Pour distribuer des instances entre plusieurs zones de disponibilité et augmenter ainsi la redondance et la disponibilité pendant les défaillances du centre de données, vous pouvez activer la redondance de zone.

• Mise à l'échelle : Un aspect important de la fiabilité d’une passerelle est la manière dont elle s’adapte à la requête de trafic. Si une passerelle n'est pas mise à l'échelle de manière appropriée, le trafic ne peut pas circuler et votre application peut subir des temps d'arrêt. Vous pouvez configurer Application Gateway pour utiliser l’un des modes de mise à l’échelle suivants.

  • Mise à l'échelle automatique : Ajuste automatiquement le nombre d'instances dans une plage que vous spécifiez. La mise à l'échelle automatique adapte le nombre d'instances en fonction de la requête de trafic actuelle.

  • Mise à l'échelle manuelle : Vous oblige à spécifier un nombre exact d'instances. Vous êtes responsable de la sélection d'un nombre d'instances qui répond à votre requête de trafic.

  Une unité de capacité représente une quantité de capacité que la passerelle peut traiter. Une unité de capacité est une mesure synthétique qui intègre le trafic, le nombre de connexions et les ressources de calcul. Chaque instance peut gérer au moins 10 unités de capacité. Pour plus d’informations, consultez Mettre à l’échelle Application Gateway v2 et WAF v2.

• Sondes d’intégrité : Application Gateway utilise des sondes d’intégrité pour surveiller en continu vos serveurs principaux, comme les serveurs d’applications individuels. Le trafic peut être automatiquement redirigé vers des serveurs back-end sains lorsque des serveurs non sains sont détecté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, consultez Recommandations pour la gestion des erreurs temporaires.

Lorsque vous utilisez Application Gateway, tenez compte des meilleures pratiques suivantes :

• Implémentez une logique de nouvelle tentative. Les clients doivent mettre en œuvre des mécanismes de nouvelle tentative appropriés pour les échecs de connexion temporaires.

• Configurez les sondes d’intégrité avec tolérance. Configurez vos sondes de santé pour autoriser une période de grâce pour les pannes transitoires. Les sondes de santé peuvent être configurées avec un seuil de santé, qui spécifie le nombre de tentatives de connexion infructueuses consécutives qui doivent déclencher le marquage du serveur principal comme étant en mauvaise santé. La valeur par défaut de trois garantit que les erreurs temporaires dans vos serveurs principaux ne déclenchent pas Application Gateway pour marquer inutilement le serveur comme non sain.

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.

Application Gateway fournit deux types de prise en charge des zones de disponibilité lorsque vous déployez une passerelle Standard_v2 ou WAF_v2 dans une région prise en charge.

• Redondant interzone : Azure distribue automatiquement les instances entre deux zones de disponibilité ou plus.

  Lorsque vous déployez une nouvelle passerelle, elle est redondante entre zones par défaut.

  Le diagramme suivant illustre une passerelle redondante interzone avec trois instances réparties entre trois zones de disponibilité :

  

• Zonal : Azure déploie toutes les instances Application Gateway dans une seule zone que vous sélectionnez dans votre région Azure choisie.

  Le diagramme suivant illustre une passerelle zonale avec trois instances déployées dans la même zone de disponibilité :

  

  Important

  L’épinglage à une seule zone de disponibilité n’est recommandé que lorsque la latence inter-zones est trop élevée pour vos besoins et lorsque vous vérifiez que la latence ne répond pas à vos exigences. Par lui-même, une passerelle zonale ne fournit pas de résilience à une panne de zone de disponibilité. Pour améliorer la résilience d’un déploiement de passerelle d’application zonale, vous devez déployer explicitement des passerelles distinctes dans plusieurs zones de disponibilité et configurer le routage du trafic et le basculement.

Spécifications

• Prise en charge de la région : Application Gateway prend en charge les zones de disponibilité pour les niveaux Standard_v2 et WAF_v2 dans toutes les régions Azure qui prennent en charge les zones de disponibilité.

• SKU: Vous devez utiliser la référence SKU Standard_v2 ou WAF_v2 pour activer la prise en charge des zones de disponibilité.

• Nombre d’instances : Votre passerelle doit avoir au moins deux instances.

  Remarque

  Toutes les passerelles ont un minimum de deux instances pour la haute disponibilité. Même si le portail Azure indique que votre passerelle a une seule instance, elle est toujours créée en interne avec un minimum de deux instances.

Considérations

Les passerelles redondantes de zone sont réparties sur deux ou plusieurs zones de disponibilité dans la région. Par exemple, dans une région qui a trois zones de disponibilité, un déploiement Application Gateway v2 redondant interzone a des instances dans au moins deux de ces zones. Selon la capacité régionale et les décisions de plateforme, les instances peuvent être réparties entre deux zones ou trois zones.

Coûts

La prise en charge de la zone de disponibilité pour Application Gateway v2 n'entraîne pas de frais supplémentaires au-delà du prix unitaire de capacité standard. Pour plus d’informations sur la tarification, consultez Comprendre la tarification d’Application Gateway et waf et Application Gateway.

Configurez la prise en charge des zones de disponibilité

Cette section explique comment configurer la prise en charge des zones de disponibilité pour vos passerelles.

• Créez une passerelle avec prise en charge des zones de disponibilité. L’approche que vous utilisez pour configurer des zones de disponibilité dépend de la création d’une passerelle redondante interzone ou zonale.

  • Redondant interzone : Les nouvelles passerelles sont créées par défaut comme redondantes en zone. Les instances sont réparties entre plusieurs zones de disponibilité et peuvent utiliser deux ou plusieurs zones dans la région.

    Pour déployer une nouvelle passerelle, consultez Démarrage rapide : Diriger le trafic web à l’aide d’Application Gateway – Portail Azure.

    Lorsque vous utilisez Azure CLI, Azure PowerShell, Bicep, les modèles Azure Resource Manager (modèles ARM) ou Terraform, vous pouvez éventuellement spécifier les zones de disponibilité dans lesquelles déployer votre passerelle. Vous pouvez déployer une passerelle redondante par zone en spécifiant deux zones ou plus. Toutefois, nous vous recommandons d’omettre la liste des zones afin que votre passerelle puisse utiliser toutes les zones de disponibilité, sauf si vous avez une raison spécifique de ne pas utiliser une zone spécifique.

  • Zonal : Vous pouvez déployer une passerelle zonale à l’aide des outils suivants.

    • Azure CLI : Vous devez sélectionner explicitement les zones en utilisant le paramètre --zones dans la commande az network application-gateway create. Pour épingler la passerelle à une seule zone, spécifiez le numéro de zone logique.

    • Azure PowerShell : Utilisez le paramètre -Zone dans la commande New-AzApplicationGateway. Pour épingler la passerelle à une seule zone, spécifiez le numéro de zone logique.

    • Modèles Bicep et ARM : Configurez la zones propriété dans la définition de ressource. Pour épingler la passerelle à une seule zone, spécifiez le numéro de zone logique.

    Remarque

    Lorsque vous sélectionnez les zones de disponibilité à utiliser, vous sélectionnez en fait la zone de disponibilité logique. Si vous déployez d’autres composants de charge de travail dans un autre abonnement Azure, ils peuvent utiliser un autre numéro de zone de disponibilité logique pour accéder à la même zone de disponibilité physique. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques.

• Modifiez la configuration de la zone de disponibilité d’une instance Application Gateway v2 existante. Toutes les passerelles sont redondantes interzone, sauf si vous les avez configurées pour être zonales.

  Si vous devez passer d’une passerelle redondante de zone à une configuration zonale, vous devez déployer une nouvelle passerelle.

• Désactivez la prise en charge des zones de disponibilité. La prise en charge des zones de disponibilité ne peut pas être désactivée. Toutes les passerelles dans les régions qui prennent en charge les zones de disponibilité doivent être redondantes interzones ou zonales.

Planification de capacité et gestion

Lorsque vous planifiez des défaillances de zone pour une passerelle d’application redondante interzone ou plusieurs passerelles zonales déployées dans plusieurs zones, pensez que les instances des zones survivantes peuvent rencontrer une charge accrue à mesure que le trafic est redistribué. Les connexions peuvent rencontrer de brèves interruptions qui peuvent durer quelques secondes.

Pour gérer efficacement la capacité, effectuez les actions suivantes :

• Utiliser la mise à l’échelle automatique. Configurez la mise à l'échelle automatique avec un nombre maximal d'instances approprié pour gérer la redistribution potentielle du trafic lors des pannes de zone.

  Si vous utilisez la mise à l'échelle manuelle, pour vous préparer à une défaillance de la zone de disponibilité, envisagez de surprovisionner le nombre d'instances dans votre passerelle. Le surapprovisionnement permet à la solution de tolérer un certain degré de perte de capacité, tout en continuant à fonctionner sans dégradation des performances. Pour plus d’informations, consultez Gérer la capacité avec le surapprovisionnement.

• Répondez aux modifications apportées aux modèles de trafic. Surveillez les mesures de capacité et ajustez les paramètres de mise à l’échelle en fonction des modèles de trafic et des exigences de performances.

Comportement lorsque toutes les zones sont saines

La section suivante décrit ce qu’il faut attendre lorsque Application Gateway v2 est configuré avec la prise en charge des zones de disponibilité et que toutes les zones de disponibilité sont opérationnelles.

• Routage du trafic entre les zones : Application Gateway distribue automatiquement les requêtes entrantes entre les instances de toutes les zones que votre passerelle utilise. Cette configuration active-active garantit des performances et une répartition de charge optimales dans des conditions de fonctionnement normales.

• Gestion des instances : La plateforme gère automatiquement l’emplacement des instances entre les zones que votre passerelle utilise. Il remplace les instances ayant échoué et gère le nombre d’instances configurées. La surveillance de l’état de santé garantit que seules les instances saines reçoivent du trafic.

Comportement lors d’une défaillance de zone

La section suivante décrit ce qu’il faut attendre lorsque Application Gateway v2 est configuré avec la prise en charge des zones de disponibilité et qu’une ou plusieurs zones de disponibilité ne sont pas disponibles.

• Détection et réponse : La responsabilité de la détection et de la réponse dépend de la configuration de la zone de disponibilité utilisée par votre passerelle.

  • Redondant interzone : Microsoft gère la détection des défaillances de zone et lance automatiquement le basculement. Aucune action du client n’est nécessaire.

  • Zonal : Vous devez détecter la perte d’une zone de disponibilité et lancer un basculement vers une passerelle secondaire que vous créez dans une autre zone de disponibilité.

• • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également 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 : Lors d’une panne de zone, les requêtes en cours de traitement par les instances de cette zone sont arrêtées. Les clients doivent réessayer les demandes en suivant les instructions pour gérer les erreurs temporaires.

• Perte de données attendue : Les échecs de zone ne sont pas censés entraîner une perte de données, car Application Gateway est un service sans état.

• Temps d’arrêt attendu : Le temps d’arrêt que vous pouvez attendre dépend de la configuration de la zone de disponibilité utilisée par votre passerelle.

  • Redondant interzone : Pendant les pannes de zone, les connexions peuvent rencontrer de brèves interruptions qui durent généralement quelques secondes au fur et à mesure que le trafic est redistribué.

  • Zonal : Lorsqu'une zone n'est pas disponible, votre passerelle n'est pas disponible jusqu'à ce que la zone de disponibilité soit rétablie.

• Gestion des instances : Le comportement de gestion des instances dépend de la configuration de la zone de disponibilité utilisée par votre passerelle.

  • Redondant interzone : La plateforme tente de maintenir la capacité de votre passerelle en créant des instances temporaires dans d'autres zones de disponibilité.

    En interne, Application Gateway utilise des ensembles de machines virtuelles de mise à l'échelle, qui effectuent un équilibrage de zone au mieux. En raison de ce comportement, les opérations de mise à l’échelle peuvent ne pas se produire lorsque la capacité ne peut pas être répartie uniformément entre les zones (+/- 1 instance).

  • Zonal : Vous êtes responsable de la création d'instances dans des zones saines si vous en avez besoin.

• Réacheminement du trafic : Le comportement de réacheminement du trafic dépend de la configuration de la zone de disponibilité utilisée par votre passerelle.

  • Redondant interzone : Application Gateway redistribue immédiatement le trafic vers les instances dans les zones saines, y compris toutes les instances créées temporairement.

  • Zonal : Lorsqu'une zone n'est pas disponible, votre passerelle n'est pas disponible. Si vous disposez d'une passerelle secondaire dans une autre zone de disponibilité, vous êtes responsable du réacheminement du trafic vers cette passerelle secondaire.

Récupération de la zone

Le comportement de récupération de zone dépend de la configuration de la zone de disponibilité utilisée par votre passerelle :

• Redondant interzone : Lorsque la zone de disponibilité affectée récupère, Application Gateway effectue automatiquement les actions suivantes :

  • Restaure les instances dans la zone récupérée

  • Supprime toutes les instances temporaires créées dans d'autres zones pendant la panne

  • Retour à la répartition normale du trafic dans toutes les zones disponibles

• Zonal : Vous êtes responsable du réacheminement du trafic vers la passerelle dans la zone de disponibilité d'origine une fois la zone de disponibilité récupérée.

Tester les pannes de zone

Les options de test des défaillances de zone dépendent de la configuration de la zone de disponibilité utilisée par votre passerelle.

• Redondant interzone : La plateforme Application Gateway gère entièrement le routage du trafic, le basculement et la restauration automatique pour les passerelles redondantes interzone. Étant donné que Microsoft gère cette fonctionnalité, vous n’avez pas besoin d’initier ou de valider les processus d’échec de zone de disponibilité. La plateforme gère tous les scénarios de défaillance de zone de manière transparente.

• Zonal : Vous pouvez simuler certains aspects de la défaillance d’une zone de disponibilité en arrêtant explicitement une passerelle. En arrêtant la passerelle, vous pouvez tester la façon dont d’autres systèmes et équilibreurs de charge gèrent une panne dans la passerelle. Pour plus d’informations, consultez Comment arrêter et démarrer Application Gateway.

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

Application Gateway v2 est un service à région unique. Si la région devient indisponible, votre passerelle n’est pas disponible également.

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

Pour obtenir une résilience multirégion à l’aide d’Application Gateway v2, vous devez déployer des passerelles distinctes dans chaque région souhaitée et implémenter la gestion du trafic entre les régions. Vous êtes responsable du déploiement et de la configuration de chacune des passerelles, ainsi que du routage du trafic et du basculement. Tenez compte des points suivants :

• Configurez des règles et des stratégies de passerelle d’application cohérentes dans toutes les régions. Vous pouvez définir l’infrastructure en tant que code (IaC) à l’aide d’outils tels que Bicep ou Terraform pour simplifier vos déploiements et configurations dans différentes régions.

• Déployez une solution d’équilibrage de charge globale capable d’envoyer du trafic entre vos passerelles régionales. Les services d’équilibrage de charge mondiaux dans Azure sont Azure Traffic Manager et Azure Front Door. Chaque service achemine le trafic en fonction de contrôles de santé, de proximité géographique ou de mesures de performance. Azure Front Door fournit également une gamme d’autres fonctionnalités, notamment la protection contre les attaques par déni de service distribué (DDoS), les fonctionnalités WAF et les règles avancées et les fonctionnalités de routage.

• Au-delà de la passerelle, envisagez de répliquer les applications et les données back-end entre les régions. Consultez les guides de fiabilité de chaque service Azure pour comprendre les approches de déploiement multirégional.

Pour obtenir un exemple d’approche, consultez Utiliser Application Gateway avec Traffic Manager.

Sauvegarde et restauration

Application Gateway v2 est un service sans état qui ne nécessite pas d’opérations de sauvegarde et de restauration traditionnelles. Toutes les données de configuration sont stockées dans Resource Manager et peuvent être redéployées à l’aide d’approches IaC, telles que des fichiers Bicep ou des modèles ARM.

Pour la gestion de la configuration et la récupération d’urgence, vous devez effectuer les actions suivantes :

• Définissez la configuration de votre déploiement Application Gateway à l’aide de fichiers Bicep ou de modèles ARM, ou exportez la configuration d’une passerelle existante.

• Stockez les certificats TLS (Transport Layer Security) dans Azure Key Vault pour la gestion et la réplication sécurisées.

• Documenter et contrôler les versions des configurations personnalisées, des règles et des stratégies.

• Implémentez des pipelines de déploiement automatisés pour le provisionnement de passerelle cohérent.

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

Application Gateway v2 effectue des mises à niveau de service régulières et d’autres tâches de maintenance. Pour maintenir votre capacité attendue pendant une mise à niveau, la plateforme ajoute automatiquement des instances supplémentaires de votre passerelle pendant le processus de mise à niveau. Toutefois, vous devez vous assurer que le sous-réseau de la passerelle dispose d’un espace d’adressage IP libre suffisant pour que les instances temporaires soient créées. Pour plus d’informations, consultez Comment Application Gateway gère-t-il la maintenance de routine ?.

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.

Pour qu’une passerelle soit éligible au contrat SLA de disponibilité Application Gateway, elle doit répondre aux critères suivants :

• Il doit être configuré correctement pour effectuer votre équilibrage de charge HTTP.
• Il doit être redondant par zone, ou bien il doit être configuré pour utiliser la mise à l’échelle automatique.

Contenu connexe

• Présentation de la fiabilité d'Azure