Fiabilité dans Azure Load Balancer

Azure Load Balancer est un service d’équilibrage de charge de couche 4 (TCP/UDP) qui distribue le trafic entrant entre les instances saines des services. Load Balancer offre une haute disponibilité et des performances réseau à vos applications avec une latence ultra faible.

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 Load Balancer 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 Load Balancer (SLA).

Recommandations concernant le déploiement de production

Azure Well-Architected Framework fournit des recommandations sur la fiabilité, les performances, la sécurité, le coût et les opérations. Pour comprendre comment ces domaines influencent les uns les autres et contribuent à une solution Load Balancer fiable, consultez les meilleures pratiques d’architecture pour Load Balancer dans Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Un équilibreur de charge peut être public ou interne. Un équilibreur de charge public accepte le trafic à partir d’Internet via une ressource d’adresse IP publique. Un équilibreur de charge interne est accessible uniquement au sein de votre réseau virtuel et d’autres réseaux que vous connectez au réseau virtuel.

Chaque équilibreur de charge se compose de plusieurs composants, notamment :

• Configurations IP frontales, qui reçoivent le trafic. Un équilibreur de charge public reçoit le trafic sur une adresse IP publique. Un équilibreur de charge interne reçoit le trafic sur une adresse IP au sein de votre réseau virtuel.
• Pools principaux, qui contiennent une collection d’instances principales pouvant recevoir le trafic, comme des machines virtuelles individuelles qui exécutent votre application.
• Règles d’équilibrage de charge, qui définissent la façon dont le trafic d’un front-end doit être distribué à un pool principal.
• Sondes d’intégrité, qui surveillent la disponibilité des instances back-end.

Pour en savoir plus sur le fonctionnement de Load Balancer, consultez les composants Load Balancer.

Pour les solutions déployées à l’échelle mondiale, vous pouvez déployer un équilibreur de charge global, qui est un type spécial d’équilibreur de charge public conçu pour acheminer le trafic entre différents déploiements régionaux de votre solution. Un équilibreur de charge global fournit une adresse IP anycast unique. Il achemine le trafic vers l’équilibreur de charge régional sain le plus proche en fonction de la proximité du client et de l’état d’intégrité régional. Pour plus d’informations, consultez Résilience aux défaillances à l’échelle de la région.

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 Load Balancer, tenez compte des meilleures pratiques suivantes pour réduire le risque d’erreurs temporaires affectant votre application :

• Implémentez une logique de nouvelle tentative. Les clients doivent implémenter des mécanismes de nouvelle tentative appropriés pour les échecs de connexion temporaires, y compris les stratégies d’interruption exponentielle.

• Configurez les sondes d’intégrité avec tolérance. Configurez vos sondes d’intégrité pour trouver un équilibre entre la détection rapide des défaillances et éviter les faux positifs lors de problèmes temporaires.

• Surveillez l’allocation de port SNAT. Pour les connexions sortantes, surveillez l’allocation de ports SNAT et configurez des règles de trafic sortant pour empêcher les échecs de connexion temporaires en raison de l’épuisement des ports.

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.

Load Balancer peut être déployé en tant que redondant interzone en configurant chaque configuration IP frontale que vous créez. Une configuration IP frontale redondante interzone est servie simultanément à partir d’une infrastructure indépendante dans plusieurs zones. Cette configuration garantit que les défaillances de zone n’affectent pas la capacité de l’équilibreur de charge à recevoir et à distribuer le trafic.

Le diagramme suivant illustre un équilibreur de charge public redondant interzone, qui est configuré en créant une adresse IP publique redondante interzone :

Le diagramme suivant illustre un équilibreur de charge interne à l’aide d’une configuration redondante interzone similaire :

Dans les régions sans zones de disponibilité, les équilibreurs de charge sont créés dans une configuration nonzonale ou régionale à l’aide d’une configuration frontale sans zone configurée. Si la région rencontre une panne, les équilibreurs de charge nonzonaux peuvent rencontrer des temps d’arrêt.

Instances principales et zones de disponibilité

La configuration de la zone de disponibilité de vos instances back-end est indépendante de la configuration IP frontale de votre équilibreur de charge.

Distribuez vos instances principales entre les zones en configurant le service approprié, conformément aux fonctionnalités de fiabilité du service auxquels ils appartiennent et à l’architecture que vous concevez.

Par exemple, lorsque vous utilisez des machines virtuelles, une approche de conception commune pour les charges de travail de production est d’obtenir une résilience de zone en plaçant plusieurs machines virtuelles zonales dans les zones 1, 2 et 3. Pour l’équilibrage de charge, vous pouvez ensuite créer un équilibreur de charge redondant interzone et configurer ces machines virtuelles en tant qu’instances principales au sein de l’équilibreur de charge. Les sondes d’intégrité de l’équilibreur de charge suppriment automatiquement les machines virtuelles non saines de la rotation, quel que soit leur emplacement de zone.

Toutefois, si vous choisissez de déployer vos machines virtuelles dans la même zone de disponibilité, vous pouvez toujours déployer une configuration IP frontale redondante interzone sur votre équilibreur de charge, que le diagramme suivant illustre :

Spécifications

Prise en charge de la région : Les équilibreurs de charge redondants interzone peuvent être déployés dans n’importe quelle région qui prend en charge les zones de disponibilité.

Coûts

La configuration de zone de disponibilité ne change pas la façon dont un équilibreur de charge est facturé. La facturation est basée sur le nombre de règles configurées et de données traitées, quelle que soit la configuration de la zone. Pour plus d’informations, consultez tarification d’Azure Load Balancer.

Configurez la prise en charge des zones de disponibilité

Lorsque vous travaillez avec Load Balancer, vous définissez la prise en charge de la zone de disponibilité sur la configuration IP frontale.

• Créez un nouveau répartiteur de charge avec prise en charge des zones de disponibilité.

  • Pour les équilibreurs de charge publics, la configuration IP frontale adopte automatiquement la configuration de la zone de disponibilité de la ressource d’adresse IP publique que vous associez à celle-ci. Pour rendre la configuration IP frontale redondante entre zones, créez ou sélectionnez une adresse IP publique redondante entre zones. Les adresses IP publiques sont redondantes interzone par défaut. Pour obtenir des instructions détaillées, consultez Créer un équilibreur de charge public pour équilibrer la charge des machines virtuelles à l’aide du portail Azure.

  • Pour les équilibreurs de charge internes, lorsque vous configurez l’adresse IP frontale de l’équilibreur de charge, vous définissez le type de prise en charge de la zone de disponibilité sur la configuration IP frontale. Pour obtenir des instructions détaillées, consultez Créer un équilibreur de charge interne pour équilibrer la charge des machines virtuelles à l’aide du portail Azure.

• Modifiez la configuration de la zone de disponibilité d’un équilibreur de charge existant. Pour modifier la configuration de la zone de disponibilité d’un équilibreur de charge existant, vous devez remplacer la configuration IP frontale. Vous pouvez utiliser cette approche pour passer d'une configuration IP frontale zonale à une configuration IP frontale à redondance de zone. L’approche générale est la suivante :

  1. Créez une nouvelle configuration frontale IP avec la configuration de zone de disponibilité souhaitée.

     Pour les équilibreurs de charge publics, créez d’abord une adresse IP publique qui utilise votre configuration de zone de disponibilité souhaitée. Ensuite, reconfigurez votre équilibreur de charge pour ajouter une configuration IP frontale qui référence cette adresse IP publique.

     Pour les équilibreurs de charge internes, reconfigurez votre équilibreur de charge pour ajouter une nouvelle configuration IP frontale avec votre configuration de disponibilité souhaitée. Cette étape affecte une nouvelle adresse IP privée à partir de votre sous-réseau.

  2. Reconfigurez vos règles d’équilibrage de charge pour utiliser la nouvelle configuration IP frontale.

     Important

     Cette opération vous oblige à reconfigurer vos clients pour envoyer le trafic vers la nouvelle adresse IP frontale. Selon vos clients, le processus peut nécessiter un temps d’arrêt.

  3. Supprimez l’ancienne configuration IP frontale.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsqu’un équilibreur de charge utilise une configuration IP frontale redondante interzone et que toutes les zones de disponibilité sont opérationnelles.

• Routage du trafic entre les zones : L’équilibrage de charge peut être effectué dans n’importe quelle zone de disponibilité. Le trafic est envoyé à des instances principales saines spécifiées dans le pool back-end, sans tenir compte de la zone de disponibilité dans laquelle se trouve l’instance back-end.

• Réplication des données entre les zones. Load Balancer est un service pass-through réseau qui ne stocke pas ou ne réplique pas les données d’application. Même si vous activez la persistance de session sur l’équilibreur de charge, aucun état n’est stocké sur l’équilibreur de charge. La persistance de session ajuste le processus de hachage pour acheminer les requêtes vers la même instance principale. Toutefois, la persistance de session n’est pas garantie. Lorsque le pool principal change, la distribution des demandes clientes est recomputée. Ce processus est effectué sans stocker ni synchroniser l’état.

  Le service conserve son état de configuration avec la réplication synchrone entre les zones, garantissant ainsi une cohérence immédiate des règles d’équilibrage de charge, des configurations de sonde d’intégrité et l’appartenance au pool principal dans toutes les zones.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsqu’un équilibreur de charge utilise une configuration IP frontale redondante interzone et qu’il existe une panne de zone de disponibilité.

• Détection et réponse : la plateforme Azure est chargée de détecter une défaillance dans une zone de disponibilité et de répondre. 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 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 : tous les flux TCP/UDP existants dans la zone ayant échoué sont réinitialisés et doivent être retentés par le client. Vos clients doivent disposer de suffisamment de gestion des erreurs temporaires implémentées, y compris les nouvelles tentatives automatisées.

• Perte de données attendue : en tant que service réseau sans état, Load Balancer ne stocke pas les données d’application, donc aucune perte de données ne se produit au niveau de la couche d’équilibreur de charge.

• Temps d’arrêt attendu : aucun temps d’arrêt n’est prévu pour les équilibreurs de charge redondants interzone, car l’équilibreur de charge continue de fonctionner à partir de zones saines.

  Toutefois, si l’échec affecte les services de calcul dans la zone, toutes les machines virtuelles ou autres ressources qui se trouvent dans la zone affectée peuvent être indisponibles. Les sondes d’intégrité de l’équilibreur de charge sont conçues pour détecter ces défaillances et acheminer le trafic vers d’autres instances d’une autre zone en fonction de l’état d’intégrité de l’algorithme d’équilibrage de charge et des instances principales.

• Réacheminement du trafic : l’équilibreur de charge continue à fonctionner à partir des zones saines. Le service Load Balancer maintient la même adresse IP de frontend pendant les échecs de zone. Ce comportement signifie que vous n’avez pas besoin d’appliquer des mises à jour DNS ou de reconfigurer des clients. Les nouvelles connexions sont automatiquement établies via les zones saines restantes.

Récupération de la zone

Lorsqu’une zone de disponibilité récupère, Load Balancer reprend automatiquement les opérations normales. Le front-end redondant interzone commence automatiquement à traiter le trafic de la zone rétablie parallèlement aux autres zones opérationnelles. Les sondes de santé de la zone récupérée reprennent l'évaluation des instances back-end.

Si l’échec de la zone a également affecté vos services de calcul dans la zone, alors, à mesure que les instances backend de la zone récupérée passent les vérifications d’intégrité, elles sont automatiquement ajoutées au pool backend sain. La distribution du trafic est rééquilibrée dans toutes les zones disponibles en fonction de l'algorithme de répartition de charge et de l'état de santé des instances de backend.

Tester les pannes de zone

La plateforme Azure gère le routage du trafic, la réponse interzone et la récupération. Ces fonctionnalités sont entièrement gérées. Vous n’avez donc pas besoin de lancer ou de valider les processus d’échec de zone de disponibilité.

Vous pouvez utiliser Azure Chaos Studio pour simuler l’échec d’une machine virtuelle dans une seule zone. Chaos Studio fournit des erreurs intégrées pour les machines virtuelles, notamment pour arrêter une machine virtuelle. Vous pouvez utiliser ces fonctionnalités pour simuler des défaillances de zone et tester vos processus de basculement.

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

Les équilibreurs de charge publics et internes sont déployés dans une seule région Azure. Si la région devient indisponible, vos équilibreurs de charge dans cette région sont également indisponibles. Toutefois, Azure Load Balancer fournit une prise en charge multirégion native via Global Load Balancer, qui permet l’équilibrage de charge entre les régions Azure. Vous pouvez également déployer d’autres services d’équilibrage de charge pour acheminer et basculer entre les régions Azure.

Équilibreurs de charge globaux

Global Load Balancer fournit une adresse IP anycast statique unique qui achemine automatiquement le trafic vers le déploiement régional optimal en fonction de la proximité du client et de la santé régionale. Global Load Balancer peut aider à améliorer la fiabilité et les performances de votre application.

Avec Global Load Balancer, vous déployez plusieurs équilibreurs de charge publics dans différentes régions, et l’équilibreur de charge global agit comme un front-end global. Si les serveurs principaux d’une région rencontrent un problème, le trafic bascule automatiquement vers des régions saines et sans modifications DNS, car l’adresse IP anycast reste constante et achemine le trafic vers une autre région.

Pour plus d’informations, consultez Global Load Balancer.

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

Azure fournit une gamme de services d’équilibrage de charge qui répondent à différentes exigences. Vous pouvez sélectionner un équilibreur de charge qui répond à vos exigences de résilience et qui convient à votre type d’application. Pour plus d’informations, consultez les options d’équilibrage de charge.

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.

Le contrat SLA Azure Load Balancer s’applique lorsqu’au moins deux machines virtuelles saines sont configurées en tant qu’instances principales. Le contrat SLA exclut les temps d’arrêt en raison de l’épuisement des ports SNAT ou des groupes de sécurité réseau (NSG) qui bloquent le trafic.

Contenu connexe

• Documentation Azure Load Balancer
• Équilibreur de charge global
• Présentation de la fiabilité d'Azure