Fonctionnement d'Elastic Load Balancing

Un équilibreur de charge accepte le trafic entrant en provenance des clients et achemine les demandes vers ses cibles enregistrées (telles que EC2 les instances) dans une ou plusieurs zones de disponibilité. L'équilibreur de charge surveille également l'état des cibles enregistrées et veille à ne rediriger le trafic que vers des cibles saines. Lorsque l'équilibreur de charge détecte une cible qui n'est pas saine, il arrête le routage du trafic vers cette cible. Il le reprend lorsqu'il détecte que la cible est de nouveau saine.

Vous configurez votre équilibreur de charge pour qu'il accepte le trafic entrant en spécifiant un ou plusieurs écouteurs. Un écouteur est un processus qui vérifie les demandes de connexion. Il est configuré avec un protocole et un numéro de port pour les connexions entre les clients et l'équilibreur de charge. De même, il est configuré avec un protocole et un numéro de port pour les connexions entre l'équilibreur de charge et les cibles.

Elastic Load Balancing prend en charge les types d'équilibreurs de charge suivants :

• Application Load Balancers

• Network Load Balancers

• Gateway Load Balancers

• Équilibreurs de charge classiques

Il existe une différence clé dans la configuration des équilibreurs de charge. Avec Aplication Load Balancers, Network Load Balancers et Gateway Load Balancers, vous enregistrez des cibles dans des groupes cibles, et vous acheminez le trafic vers les groupes cibles. Avec les Classic Load Balancers, vous enregistrez les instances auprès de l'équilibreur de charge.

Zones de disponibilité et nœuds d'équilibreurs de charge

Lorsque vous activez une zone de disponibilité pour votre équilibreur de charge, Elastic Load Balancing crée un nœud d'équilibreur de charge dans la zone de disponibilité. Si vous enregistrez des cibles dans une zone de disponibilité mais que vous n'activez pas la zone de disponibilité, ces cibles enregistrées ne reçoivent pas le trafic. Votre équilibreur de charge est plus efficace si vous vous assurez que chaque zone de disponibilité activée contient au moins une cible enregistrée.

Nous recommandons d'activer plusieurs zones de disponibilité pour tous les équilibreurs de charge. Cependant, avec un Application Load Balancer, vous devez activer au moins deux zones de disponibilité. Cette configuration permet de s'assurer que l'équilibreur de charge peut continuer à acheminer le trafic. Si une zone de disponibilité devient indisponible ou ne contient pas de cible saine, l'équilibreur de charge peut acheminer le trafic vers les cibles saines d'une autre zone de disponibilité.

Une fois qu'une zone de disponibilité est désactivée, les cibles de cette zone de disponibilité restent enregistrées auprès de l'équilibreur de charge. Cependant, même si elles restent enregistrées, l'équilibreur de charge ne leur achemine plus de trafic.

Equilibrage de charge entre zones

Les nœuds de votre équilibreur de charge distribuent les requêtes des clients à des cibles enregistrées. Lorsque l'équilibrage de charge entre zones est activé, chaque nœud d'équilibreur de charge distribue le trafic entre les cibles enregistrées dans toutes les zones de disponibilité activées. Lorsque l'équilibrage de charge entre zones est désactivé, chaque nœud d'équilibreur de charge distribue le trafic entre les cibles enregistrées dans sa zone de disponibilité uniquement.

Les diagrammes suivants illustrent l'effet de la répartition de charge entre zones avec le routage en tourniquet comme algorithme de routage par défaut. Il existe deux zones de disponibilité activées, avec deux cibles dans la zone de disponibilité A et huit cibles dans la zone de disponibilité B. Les clients envoient des demandes, et Amazon Route 53 répond à chaque demande avec l'adresse IP de l'un des nœuds de l'équilibreur de charge. Sur la base de l'algorithme de routage circulaire, le trafic est distribué de telle sorte que chaque nœud d'équilibreur de charge reçoit 50 % du trafic des clients. Chaque nœud d'équilibreur de charge distribue son partage du trafic entre cibles enregistrées dans son champ.

Si l'équilibrage de charge entre zones est activé, chacune des 10 cibles reçoit 10 % du trafic. En effet, chaque nœud d'équilibreur de charge peut acheminer ses 50 % du trafic client vers l'ensemble des 10 cibles.

Si l'équilibrage de charge entre zones est désactivé :

• Chacune des deux cibles de la zone de disponibilité A reçoit 25 % du trafic.

• Chacune des huit cibles de la zone de disponibilité B reçoit 6,25 % du trafic.

En effet, chaque nœud d'équilibreur de charge peut acheminer ses 50 % du trafic client uniquement vers les cibles dans sa zone de disponibilité.

Avec les Application Load Balancers, la répartition de charge entre zones est toujours activé au niveau de l'équilibreur de charge. Au niveau du groupe cible, la répartition de charge entre zones peut être désactivé. Pour plus d'informations, consultez Désactiver la répartition de charge entre zones dans le Guide de l'utilisateur pour Application Load Balancers.

Avec les Network Load Balancers et les Gateway Load Balancers, la répartition de charge entre zones est désactivée par défaut. Après avoir créé un équilibreur de charge, vous pouvez activer ou désactiver la répartition de charge entre zones à tout moment. Pour plus d'informations, consultez la section Équilibrage de charge entre zones dans le Guide de l'utilisateur pour les équilibreurs de charge réseau.

Lorsque vous créez un Classic Load Balancer, les valeurs par défaut pour la répartition de charge entre zones dépend de la manière dont vous créez l'équilibreur de charge. Avec le API ouCLI, l'équilibrage de charge entre zones est désactivé par défaut. Avec le AWS Management Console, l'option permettant d'activer l'équilibrage de charge entre zones est sélectionnée par défaut. Après avoir créé un Classic Load Balancer, vous pouvez activer ou désactiver la répartition de charge entre zones à tout moment. Pour plus d'informations, consultez Activer la répartition de charge entre zones dans le Guide de l'utilisateur pour Classic Load Balancers.

Changement de zone

Le changement de zone est une fonctionnalité d'Amazon Application Recovery Controller (ARC) (ARC). Avec le changement de zone, vous pouvez déplacer une ressource d'équilibreur de charge hors d'une zone de disponibilité altérée en une seule action. De cette façon, vous pouvez continuer à opérer depuis d'autres zones de disponibilité saines dans une Région AWS.

Lorsque vous lancez un changement de zone, votre équilibreur de charge arrête d'envoyer le trafic pour la ressource vers la zone de disponibilité concernée. ARCcrée le décalage de zone immédiatement. Cependant, l'établissement des connexions existantes en cours dans la zone de disponibilité concernée peut prendre un certain temps, généralement quelques minutes. Pour plus d'informations, consultez Comment fonctionne un changement de zone : bilans de santé et adresses IP zonales dans le manuel du développeur Amazon Application Recovery Controller (ARC).

Avant d'utiliser un changement de zone, passez en revue les points suivants :

• Le décalage de zone n'est pas pris en charge lorsque vous utilisez un Application Load Balancer avec l'équilibrage de charge entre zones activé. Le décalage de zone est pris en charge lorsque vous utilisez un Network Load Balancer avec l'équilibrage de charge entre zones activé ou désactivé.

• Le changement de zone n'est pas pris en charge lorsque vous utilisez un Application Load Balancer comme point de terminaison d'accélérateur dans AWS Global Accelerator.

• Vous pouvez démarrer un changement de zone pour un équilibreur de charge spécifique uniquement pour une zone de disponibilité unique. Vous ne pouvez pas commencer un changement de zone pour plusieurs zones de disponibilité.

• AWS supprime de manière proactive les adresses IP des équilibreurs de charge zonaux DNS lorsque plusieurs problèmes d'infrastructure ont un impact sur les services. Vérifiez toujours la capacité actuelle de la zone de disponibilité avant de commencer un changement de zone. Si la répartition de charge entre zones de vos équilibreurs de charge est désactivée et que vous utilisez un changement de zone pour supprimer une adresse IP d'équilibreur de charge zonal, la zone de disponibilité affectée par le changement de zone perd également sa capacité cible.

• Lorsqu'un Application Load Balancer est la cible d'un Network Load Balancer, commencez toujours le changement de zone à partir du Network Load Balancer. Si vous commencez un changement de zone à partir de l'Application Load Balancer, le Network Load Balancer ne reconnaît pas le changement et continue à envoyer du trafic vers l'Application Load Balancer.

Pour plus de conseils et d'informations, consultez les meilleures pratiques relatives ARC aux changements de zone de la Route 53 dans le manuel du développeur Amazon Application Recovery Controller (ARC).

Routage des demandes

Avant qu'un client n'envoie une demande à votre équilibreur de charge, celui-ci résout le nom de domaine de l'équilibreur de charge à l'aide d'un serveur Domain Name System (DNS). L'DNSentrée est contrôlée par Amazon, car vos équilibreurs de charge se trouvent dans le amazonaws.com domaine. Les DNS serveurs Amazon renvoient une ou plusieurs adresses IP au client. Il s'agit des adresses IP des nœuds de votre équilibreur de charge. Avec les Network Load Balancers, Elastic Load Balancing crée une interface réseau pour chaque zone de disponibilité que vous activez et l'utilise pour obtenir une adresse IP statique. Si vous le souhaitez, vous pouvez associer une adresse IP Elastic à chaque interface réseau lorsque vous créez le Network Load Balancer.

À mesure que le trafic vers votre application évolue au fil du temps, Elastic Load Balancing adapte votre équilibreur de charge et met à jour l'DNSentrée. L'DNSentrée indique également le time-to-live (TTL) de 60 secondes. Ainsi, les adresses IP peuvent être remappées rapidement en cas d'évolution du trafic.

Le client détermine les adresses IP à utiliser pour envoyer des demandes à l'équilibreur de charge. Le nœud d'équilibreur de charge qui reçoit la demande sélectionne une cible enregistrée saine et envoie la demande à la cible à l'aide de son adresse IP privée.

Pour plus d'informations, consultez la section Router le trafic vers un équilibreur de ELB charge dans le manuel du développeur Amazon Route 53.

Algorithme de routage

Avec les Application Load Balancers, le nœud de l'équilibreur de charge qui reçoit la demande procède comme suit :

1. Évalue les règles de l'écouteur par ordre de priorité pour déterminer la règle à appliquer.

2. Sélectionne une cible dans le groupe cible pour l'action de règle, à l'aide de l'algorithme de routage configuré pour le groupe cible. L'algorithme de routage par défaut est l'algorithme de routage en tourniquet. Le routage est effectué indépendamment pour chaque groupe cible, même si une cible est enregistrée avec plusieurs groupes cible.

Avec les Network Load Balancers, le nœud de l'équilibreur de charge qui reçoit la connexion procède comme suit :

1. Sélectionne une cible dans le groupe cible pour la règle par défaut à l'aide d'un algorithme de hachage de flux. Il base l'algorithme sur :

   • le protocole

   • l'adresse IP et le port source

   • l'adresse IP et le port de destination

   • Le numéro TCP de séquence

2. Achemine chaque TCP connexion individuelle vers une cible unique pendant toute la durée de vie de la connexion. Les TCP connexions provenant d'un client ont des ports source et des numéros de séquence différents, et peuvent être acheminées vers différentes cibles.

Avec les Classic Load Balancers, le nœud de l'équilibreur de charge qui reçoit la demande sélectionne une instance enregistrée comme suit :

• Utilise l'algorithme de routage Round Robin pour les TCP auditeurs

• Utilise l'algorithme de routage des requêtes les moins en attente pour HTTP et les HTTPS auditeurs

HTTPconnexions

Classic Load Balancers utilisent des connexions pré-ouvertes, mais pas les Application Load Balancers. Classic Load Balancers et Application Load Balancers utilisent le multiplexage des connexions. Cela signifie que les demandes de plusieurs clients sur plusieurs connexions front-end peuvent être acheminées vers une cible donnée via une seule connexion backend. Le multiplexage des connexions améliore la latence et réduit la charge sur vos applications. Pour empêcher le multiplexage des connexions, désactivez HTTP keep-alive les en-têtes en les Connection: close définissant dans vos HTTP réponses.

Les équilibreurs de charge d'application et les équilibreurs de charge classiques prennent en charge les connexions frontales HTTP en pipeline. Ils ne prennent pas en charge les connexions en pipeline HTTP sur le backend.

Les équilibreurs de charge d'application prennent en charge les méthodes de HTTP demande suivantes : GET HEADPOST,PUT,DELETE,OPTIONS, etPATCH.

Les équilibreurs de charge d'application prennent en charge les protocoles suivants sur les connexions frontales : HTTP /0.9, HTTP /1.0, HTTP /1.1 et /2. HTTP Vous pouvez utiliser HTTP /2 uniquement avec des HTTPS écouteurs et envoyer jusqu'à 128 requêtes en parallèle en utilisant une connexion HTTP /2. Les équilibreurs de charge des applications prennent également en charge les mises à niveau de connexion de HTTP à WebSockets. Toutefois, en cas de mise à niveau de la connexion, les règles de routage et les AWS WAF intégrations de l'écouteur Application Load Balancer ne s'appliquent plus.

Les équilibreurs de charge d'application utilisent HTTP /1.1 sur les connexions principales (équilibreur de charge vers la cible enregistrée) par défaut. Cependant, vous pouvez utiliser la version du protocole pour envoyer la demande aux cibles en utilisant HTTP /2 ou RPC g. Pour plus d'informations, consultez Versions de protocole. L'en-tête keep-alive est pris en charge par défaut sur les connexions backend. Pour les demandes HTTP /1.0 provenant de clients qui n'ont pas d'en-tête d'hôte, l'équilibreur de charge génère un en-tête d'hôte pour les demandes HTTP /1.1 envoyées sur les connexions principales. L'en-tête de l'hôte contient le DNS nom de l'équilibreur de charge.

Les équilibreurs de charge classiques prennent en charge les protocoles suivants sur les connexions frontales (du client à l'équilibreur de charge) : HTTP /0.9, HTTP /1.0 et /1.1. HTTP Ils utilisent HTTP /1.1 sur les connexions principales (équilibreur de charge vers la cible enregistrée). L'en-tête keep-alive est pris en charge par défaut sur les connexions backend. Pour les demandes HTTP /1.0 provenant de clients qui n'ont pas d'en-tête d'hôte, l'équilibreur de charge génère un en-tête d'hôte pour les demandes HTTP /1.1 envoyées sur les connexions principales. L'en-tête d'hôte contient l'adresse IP du nœud de l'équilibreur de charge.

HTTPen-têtes

Application Load Balancers et Classic Load Balancers ajoutent automatiquement les en-têtes X-Forwarded-For, X-Forwarded-Proto et X-Forwarded-Port à la demande.

Les équilibreurs de charge d'application convertissent les noms d'HTTPhôtes dans les en-têtes d'hôtes en minuscules avant de les envoyer aux cibles.

Pour les connexions frontales qui utilisent HTTP /2, les noms des en-têtes sont en minuscules. Avant que la demande ne soit envoyée à la cible via HTTP /1.1, les noms d'en-tête suivants sont convertis en majuscules et minuscules : X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, Host, X-Amzn-Trace-Id, Upgrade et Connection. Tous les autres noms d'en-tête sont en minuscules.

Les Application Load Balancers et les Classic Load Balancers prennent en compte l'en-tête de connexion de la demande client entrante après avoir redirigé la réponse vers le client.

Lorsque les équilibreurs de charge d'application et les équilibreurs de charge classiques utilisant HTTP /1.1 reçoivent un en-tête Expect : 100-Continue, ils répondent immédiatement par HTTP/1.1 100 Continue sans tester la longueur de l'en-tête du contenu. L'en-tête de demande Expect: 100-Continue n'est pas transmis à ses cibles.

Lorsque vous utilisez HTTP /2, les équilibreurs de charge d'application ne prennent pas en charge l'en-tête Expect : 100-Continue provenant des demandes des clients. L'Application Load Balancer ne répondra pas avec HTTP/2 100 Continue ou ne transmettra pas cet en-tête à ses cibles.

HTTPlimites d'en-têtes

Les limites de taille des Application Load Balancers qui suivent sont des limites strictes qui ne peuvent pas être modifiées :

• Ligne de demande : 16 K

• En-tête simple : 16 K

• En-tête de réponse entier : 32 K

• En-tête de demande entier : 64 K

Schéma d'un équilibreur de charge

Lorsque vous créez un équilibreur de charge, vous devez choisir entre un équilibreur de charge interne et un équilibreur de charge accessible sur Internet.

Les nœuds d'un équilibreur de charge accessible sur Internet ont des adresses IP publiques. Le DNS nom d'un équilibreur de charge connecté à Internet peut être résolu publiquement en fonction des adresses IP publiques des nœuds. Les équilibreurs de charge accessibles sur Internet peuvent donc acheminer des demandes de clients via Internet.

Les nœuds d'un équilibreur de charge interne ont des adresses IP privées uniquement. Le DNS nom d'un équilibreur de charge interne peut être résolu publiquement en utilisant les adresses IP privées des nœuds. Par conséquent, les équilibreurs de charge internes peuvent uniquement acheminer les demandes des clients ayant accès à l'VPCéquilibreur de charge.

Les équilibreurs de charge internes et accessibles sur Internet acheminent les demandes vers vos cibles à l'aide d'adresses IP privées. Par conséquent, vos cibles n'ont pas besoin d'adresses IP publiques pour recevoir des demandes d'un équilibreur de charge interne ou accessible sur Internet.

Si votre application comporte plusieurs niveaux, vous pouvez concevoir une architecture qui utilise à la fois des équilibreurs de charge internes et accessibles sur Internet. Par exemple, c'est le cas si votre application utilise des serveurs web qui doivent être connectés à Internet et des serveurs de base de données qui ne sont connectés qu'aux serveurs web. Créez un équilibreur de charge accessible sur Internet et enregistrez les serveurs Web auprès de celui-ci. Créez un équilibreur de charge interne et enregistrez les serveurs d'application auprès de celui-ci. Les serveurs web reçoivent les demandes de l'équilibreur de charge accessible sur Internet et les envoient pour les serveurs d'application à l'équilibreur de charge interne. Les serveurs d'application reçoivent les demandes de l'équilibreur de charge interne.

Types d'adresses IP

Le type d'adresse IP que vous spécifiez pour votre équilibreur de charge détermine la manière dont les clients peuvent communiquer avec l'équilibreur de charge.

• IPv4uniquement — Les clients communiquent en utilisant des IPv4 adresses publiques et privées. Les sous-réseaux que vous sélectionnez pour votre équilibreur de charge doivent comporter des plages d'IPv4adresses.

• Dualstack — Les clients communiquent en utilisant des adresses et des adresses publiques IPv4 et IPv6 privées. Les sous-réseaux que vous sélectionnez pour votre équilibreur de charge doivent comporter des plages IPv4 d'IPv6adresses.

• Dualstack sans public IPv4 — Les clients communiquent en utilisant des adresses publiques et privées et IPv6 des adresses privéesIPv4. Les sous-réseaux que vous sélectionnez pour votre équilibreur de charge doivent comporter des plages IPv4 d'IPv6adresses. Cette option n'est pas prise en charge avec le schéma d'internaléquilibrage de charge.

Le tableau suivant décrit les types d'adresses IP pris en charge pour chaque type d'équilibreur de charge.

Nouveau type d'équilibreur de charge	IPv4uniquement	Double pile	Dualstack sans public IPv4
Application Load Balancer	Oui	Oui	Oui
Network Load Balancer	Oui	Oui	Non
Équilibreur de charge de passerelle	Oui	Oui	Non
Classic Load Balancer	Oui	Non	Non

Le type d'adresse IP que vous spécifiez pour votre groupe cible détermine la manière dont l'équilibreur de charge peut communiquer avec les cibles.

• IPv4uniquement — L'équilibreur de charge communique à l'aide d'IPv4adresses privées. Vous devez enregistrer les cibles avec IPv4 des adresses appartenant à un groupe IPv4 cible.

• IPv6uniquement — L'équilibreur de charge communique à l'aide d'IPv6adresses. Vous devez enregistrer les cibles avec IPv6 des adresses appartenant à un groupe IPv6 cible. Le groupe cible doit être utilisé avec un équilibreur de charge à double pile.

Le tableau suivant décrit les types d'adresses IP pris en charge pour chaque protocole de groupe cible.

Protocole du groupe cible	IPv4uniquement	IPv6uniquement
HTTPet HTTPS	Oui	Oui
TCP	Oui	Oui
TLS	Oui	Oui
UDPet TCP _ UDP	Oui	Oui
GENEVE	-	-

Réseau MTU pour votre équilibreur de charge

L'unité de transmission maximale (MTU) détermine la taille, en octets, du plus gros paquet pouvant être envoyé sur le réseau. Plus une connexion est MTU importante, plus le volume de données pouvant être transmises dans un seul paquet est important. Les trames Ethernet se composent du paquet, ou des données réelles que vous envoyez, et des informations de surcharge du réseau qui l’entourent. Le trafic envoyé via une passerelle Internet a un MTU de 1500. Cela signifie que si un paquet est supérieur à 1 500 octets, il est fragmenté pour être envoyé en utilisant plusieurs trames, ou il est supprimé si Don't Fragment est défini dans l'en-tête IP.

La MTU taille des nœuds d'équilibrage de charge n'est pas configurable. Les cadres Jumbo (9001MTU) sont standard sur tous les nœuds d'équilibreur de charge pour les équilibreurs de charge d'application, les équilibreurs de charge réseau et les équilibreurs de charge classiques. Les équilibreurs de charge Gateway prennent en charge le 8500MTU. Pour plus d'informations, consultez la section Unité de transmission maximale (MTU) dans le Guide de l'utilisateur pour les équilibreurs de charge de passerelle.

Le chemin MTU est la taille de paquet maximale prise en charge sur le chemin entre l'hôte d'origine et l'hôte de réception. Path MTU Discovery (PMTUD) est utilisé pour déterminer le chemin MTU entre deux appareils. MTULa découverte de chemins est particulièrement importante si le client ou la cible ne prend pas en charge les images jumbo.

Lorsqu'un hôte envoie un paquet supérieur à celui MTU de l'hôte récepteur ou supérieur à celui MTU d'un périphérique le long du chemin, l'hôte ou le périphérique récepteur abandonne le paquet, puis renvoie le ICMP message suivant :Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Type 3, Code 4). Cela indique à l'hôte émetteur de diviser la charge utile en plusieurs paquets plus petits et de les retransmettre.

Si des paquets supérieurs à la MTU taille du client ou de l'interface cible continuent d'être supprimés, il est probable que Path MTU Discovery (PMTUD) ne fonctionne pas. Pour éviter cela, assurez-vous que Path MTU Discovery fonctionne de bout en bout et que vous avez activé les images jumbo sur vos clients et cibles. Pour plus d'informations sur Path MTU Discovery et l'activation des cadres jumbo, consultez Path MTU Discovery dans le guide de l'EC2utilisateur Amazon.