Fonctionnement d’Azure Load Balancer

  • 5 minutes

Azure Load Balancer fonctionne au niveau de la couche transport du modèle OSI. Cette fonctionnalité de couche 4 permet de gérer le trafic en fonction des propriétés spécifiques du trafic. Les propriétés, notamment les adresses source et de destination, le type de protocole TCP ou UDP et le numéro de port.

Load Balancer a plusieurs éléments qui fonctionnent ensemble pour garantir la haute disponibilité et les performances d’une application :

  • Adresse IP front-end
  • Règles d'équilibrage de charge
  • Pool de back-ends
  • Sondes d’intégrité
  • Règles NAT entrantes
  • Ports à haute disponibilité
  • Règles de trafic sortant

Adresse IP front-end

L’adresse IP front-end est l’adresse utilisée par les clients pour se connecter à votre application web. Une adresse IP de front-end peut être une adresse IP publique ou privée. Les équilibreurs de charge Azure peuvent avoir plusieurs IP de front-end. La sélection d’une adresse IP publique ou privée détermine le type d’équilibreur de charge à créer :

  • Adresse IP publique : équilibreur de charge public :un équilibreur de charge public mappe l’adresse IP publique et le port du trafic entrant à l’adresse IP privée et au port de la machine virtuelle. Vous pouvez distribuer des types de trafic donnés entre plusieurs machines virtuelles ou services en appliquant des règles d’équilibrage de charge. Par exemple, vous pouvez répartir la charge du trafic des requêtes web entre plusieurs serveurs web. L’équilibreur de charge mappe le trafic de réponse à partir de l’adresse IP privée et du port de la machine virtuelle vers l’adresse IP publique et le port de l’équilibreur de charge. Ensuite, il transmet la réponse au client demandeur en retour.

  • Adresse IP privée : équilibreur de charge interne : un équilibreur de charge interne distribue le trafic aux ressources qui se trouvent à l’intérieur d’un réseau virtuel. Azure réserve l’accès aux adresses IP de front-end d’un réseau virtuel qui ont une charge équilibrée. Les adresses IP du serveur frontal et les réseaux virtuels ne sont jamais directement exposés à un point de terminaison Internet. Les applications métier internes s’exécutent dans Azure et sont accessibles à partir d’Azure ou de ressources locales à travers une connexion VPN ou ExpressRoute.

    Diagram that depicts how public and internal load balancers work in Azure Load Balancer.

Règles d'équilibrage de charge

Une règle d’équilibreur de charge définit la façon dont le trafic est distribué au pool de back-ends. La règle mappe une IP et un port de front-end spécifiques à un ensemble d’adresses IP et de ports de back-ends.

Diagram that depicts how load balancer rules work in Azure Load Balancer.

Le trafic est géré en utilisant un hachage à cinq tuples effectué à partir des éléments suivants :

  • IP source : Adresse IP du client demandeur.
  • Port source : Port du client demandeur.
  • IP de destination : adresse IP de destination de la demande .
  • Port de destination : Port de destination de la requête.
  • Type de protocole : Type de protocole spécifié : TCP ou UDP.
  • Affinité de session : Garantit que le même nœud de pool gère toujours le trafic pour un client.

Load Balancer vous permet d’équilibrer la charge des services sur plusieurs ports, plusieurs adresses IP ou les deux. Vous pouvez configurer différentes règles d’équilibrage de charge pour chaque adresse IP de front-end. Seules les machines virtuelles IaaS prennent en charge plusieurs configurations de front-end.

Load Balancer ne peut pas appliquer différentes règles en fonction du contenu du trafic interne, car il fonctionne au niveau de la couche 4 (couche de transport) du modèle OSI. Si vous devez gérer le trafic en fonction de ses propriétés de couche 7 (couche application), vous devez déployer une solution de type Azure Application Gateway.

Pool de back-ends

Le pool de back-ends est un groupe de machines virtuelles ou d’instances dans un groupe de machines virtuelles identiques qui répond à la demande entrante. Pour une mise à l’échelle rentable visant à répondre à des volumes élevés de trafic entrant, il est généralement recommandé d’ajouter davantage d’instances au pool de back-ends.

Load Balancer implémente la reconfiguration automatique pour redistribuer la charge sur le nombre d’instances modifié quand vous effectuez un scale-up ou un scale-down des instances. Par exemple, si vous avez ajouté deux autres instances VM au pool de back-ends, Load Balancer se reconfigure pour commencer à équilibrer le trafic vers ces instances en fonction des règles d’équilibrage de charge déjà configurées.

Sondes d’intégrité

Une sonde d’intégrité sert à déterminer l’état d’intégrité des instances du pool de back-ends. Cette sonde d’intégrité détermine si une instance est saine et peut recevoir du trafic. Vous pouvez définir le seuil de défaillance sur le plan de l’intégrité pour vos sondes d’intégrité. Lorsqu’une sonde ne répond pas, l’équilibrage de charge n’envoie plus de nouvelles connexions aux instances défaillantes. Un échec de la sonde n’affecte pas les connexions existantes. La connexion se poursuit jusqu’à ce que :

  • L’application termine le flux.
  • Un délai d’inactivité se produit.
  • La machine virtuelle s’arrête.

Load Balancer vous permet de configurer différents types de sonde d’intégrité pour les points de terminaison : TCP, HTTP et HTTPS.

  • Sonde personnalisée TCP : cette sonde s’appuie sur l’établissement réussi d’une session TCP sur un port de sonde défini. Si l’écouteur spécifié sur la machine virtuelle existe, l’exécution de la sonde réussit. Si la connexion est refusée, la sonde échoue. Vous pouvez spécifier le port, l’intervalle et le seuil de défaillance sur le plan de l’intégrité.
  • Sonde personnalisée HTTP ou HTTPS : l’équilibreur de charge sonde régulièrement votre point de terminaison (toutes les 15 secondes par défaut). L’instance est saine si elle répond par un code HTTP 200 avant l’expiration du délai imparti (31 secondes par défaut). Tout autre code d’état que HTTP 200 entraîne l’échec de la sonde. Vous pouvez spécifier le port (Port), l’URI permettant d’interroger l’état d’intégrité du back-end (URI), le délai entre les tentatives d’exécution de la sonde (Intervalle) ainsi que le nombre d’échecs qui doivent se produire pour que l’instance soit considérée comme non saine (Seuil de défaillance sur le plan de l’intégrité).

Persistance de session

Par défaut, Load Balancer répartit le trafic réseau équitablement sur plusieurs instances VM. Il fournit l’adhérence uniquement dans une session de transport. La persistance de session spécifie la façon dont le trafic en provenance d’un client doit être géré. Le comportement par défaut (Aucune) est que les demandes successives d’un client peuvent être traitées par n’importe quelle machine virtuelle saine.

La persistance de session est également connue sous le nom d’affinité de session, affinité IP source ou affinité IP client. Ce mode de distribution utilise un hachage à deux tuples (IP source et IP de destination) ou à trois tuples (IP source, IP de destination et type de protocole) pour le routage vers les instances de back-end. Quand vous utilisez la persistance de session, les connexions en provenance du même client vont à la même instance de back-end dans le pool de back-ends. Vous pouvez configurer une des options de persistance de session suivantes :

  • Aucune (par défaut) : spécifie que toute machine virtuelle saine peut traiter la demande.
  • Adresse IP cliente (2 tuples) : Spécifie que la même instance de back-end peut gérer les demandes successives provenant de la même adresse IP cliente.
  • Adresse IP cliente et protocole (3 tuples) : Spécifie que la même instance de back-end peut gérer les demandes successives provenant de la même combinaison adresse IP cliente/protocole.

Vous pouvez changer ce comportement en configurant une des options décrites dans les sections suivantes.

Ports à haute disponibilité

Une règle d’équilibreur de charge configurée avec protocol - all and port - 0 est appelée règle de port de haute disponibilité (HA). Cette règle permet à une seule règle d’équilibrer la charge de tous les flux TCP et UDP qui arrivent sur tous les ports d’un équilibreur de charge standard interne.

La décision d’équilibrage de charge est prise par flux. Cette action est basée sur la connexion à cinq tuples suivante :

  • Adresse IP source
  • Port source
  • Adresse IP de destination
  • Port de destination
  • Protocol

Les règles d’équilibrage de charge des ports HA sont utiles dans les scénarios critiques, comme la haute disponibilité et la mise à l’échelle d’appliances virtuelles réseau dans des réseaux virtuels. Cette fonctionnalité peut servir quand un grand nombre de ports doit avoir une charge équilibrée.

Diagram that shows how high availability ports work in Azure Load Balancer.

Règles NAT entrantes

Vous pouvez utiliser les règles d’équilibrage de charge en combinaison avec les règles de traduction d’adresses réseau (NAT). Par exemple, vous pouvez utiliser la traduction NAT entre l’adresse publique de l’équilibreur de charge et le protocole TCP 3389 d’une machine virtuelle spécifique. Cette combinaison de règles permet d’effectuer un accès au Bureau à distance en dehors d’Azure.

Diagram that shows how inbound NAT rules work in Azure Load Balancer.

Règles de trafic sortant

Une règle de trafic sortant configure la traduction d’adresses réseau (NAT) source pour toutes les machines virtuelles ou instances identifiées par le pool de back-ends. Cette règle permet aux instances du back-end de communiquer (trafic sortant) sur Internet ou vers d’autres points de terminaison.

Diagram that shows how outbound rules work in Azure Load Balancer.