Azure Load Balancer
Introduction
Lorsqu’une application fonctionne sur une seule machine virtuelle, une panne de cette machine peut rendre le service inaccessible. De plus, sa capacité de traitement peut devenir insuffisante lorsque le nombre d’utilisateurs augmente.
Exécuter l’application sur plusieurs machines virtuelles permet de répartir les traitements et de limiter l’impact d’une panne. Il faut cependant un mécanisme capable de distribuer les connexions entre ces machines et de détecter celles qui ne peuvent plus répondre.
Azure Load Balancer remplit ce rôle en répartissant le trafic réseau entre plusieurs instances d’une application.
Présentation
Azure Load Balancer est un service de répartition de charge qui distribue les flux réseau entre des machines virtuelles ou des instances de Virtual Machine Scale Sets.
Il fonctionne au niveau 4 du modèle OSI, correspondant à la couche transport, et prend en charge les protocoles TCP et UDP. Les clients utilisent une adresse IP d’entrée ; le service dirige leurs connexions vers les instances disponibles selon les règles configurées.
Par exemple, plusieurs machines virtuelles peuvent héberger une même application HTTPS. Azure Load Balancer répartit les connexions TCP reçues sur le port 443 entre ces machines.
Il ne prend pas de décision à partir du contenu des requêtes HTTP : il ne sélectionne donc pas une machine selon une URL, un en-tête HTTP ou un cookie. Il ne réalise pas non plus la terminaison TLS ; dans cet exemple, chaque serveur prend en charge le chiffrement HTTPS.
Un équilibreur public ou interne
Selon les besoins, Azure Load Balancer peut exposer une adresse IP publique ou privée.
| Type | Adresse IP d’entrée | Utilisation |
|---|---|---|
| Public | Adresse IP publique | Distribuer le trafic provenant d’Internet vers plusieurs instances. |
| Interne | Adresse IP privée | Distribuer le trafic privé entre les composants d’une application ou depuis un réseau connecté à Azure. |
Un équilibreur interne peut notamment être utilisé par une application d’entreprise accessible depuis un réseau sur site connecté à Azure par VPN ou ExpressRoute. Il n’est pas directement accessible depuis Internet.
Les composants principaux
La configuration d’Azure Load Balancer repose sur quatre composants principaux.
| Composant | Rôle |
|---|---|
| Configuration IP frontale (frontend IP configuration) | Définit l’adresse IP utilisée par les clients pour accéder au service. |
| Pool principal (backend pool) | Regroupe les instances auxquelles le trafic peut être envoyé. |
| Sonde d’intégrité (health probe) | Vérifie si chaque instance est en mesure de répondre. |
| Règle de répartition de charge | Associe une adresse IP et un port d’entrée à un pool, un port de destination et une sonde. |
Par exemple, une règle peut distribuer les connexions TCP reçues sur le port 443 de l’adresse IP publique vers le port 443 des machines du pool. Ces machines peuvent conserver uniquement des adresses IP privées.
La répartition des connexions
Par défaut, Azure Load Balancer sélectionne une instance à l’aide d’un calcul de hachage reposant sur cinq informations :
- L’adresse IP source.
- Le port source.
- L’adresse IP de destination.
- Le port de destination.
- Le protocole utilisé.
La répartition s’effectue par flux réseau. Les données d’une même connexion TCP restent dirigées vers la même instance. Une nouvelle connexion du même client peut être affectée à une autre instance.
Ce fonctionnement ne correspond pas à une alternance systématique entre les serveurs. Il ne garantit pas non plus une répartition parfaitement égale ni la sélection du serveur dont le processeur est le moins sollicité.
Une option de persistance de session permet d’utiliser l’adresse IP du client, éventuellement associée au protocole, pour orienter ses connexions vers une même instance. Cette affinité peut toutefois déséquilibrer la charge lorsque de nombreux utilisateurs partagent une adresse IP publique. Elle ne garantit pas non plus de conserver la même instance lorsque la composition du pool change.
Les sondes d’intégrité
Les sondes d’intégrité vérifient régulièrement la disponibilité des instances. L'offre Azure Load Balancer Standard prend en charge les sondes TCP, HTTP et HTTPS.
Une sonde TCP vérifie qu’une connexion peut être établie sur le port configuré. Une sonde HTTP ou HTTPS peut interroger un chemin dédié, tel que /health, pour obtenir une indication de l’état de l’application.
Lorsqu’une instance est considérée comme indisponible, Azure Load Balancer cesse de lui envoyer de nouvelles connexions. Si elle redevient disponible, elle peut recevoir à nouveau du trafic. Les connexions TCP déjà établies ne sont pas automatiquement transférées vers un autre serveur.
Le choix de la sonde est donc essentiel. Une machine peut être démarrée alors que son application ne fonctionne plus correctement. Pour une application métier, un point de contrôle applicatif peut fournir une information plus pertinente qu’un simple contrôle de port.
Exemple de fonctionnement
Prenons une application hébergée sur trois machines virtuelles :
| Machine | Adresse IP privée | Application |
|---|---|---|
VM-Web-01 |
10.0.1.4 |
HTTPS sur le port 443 |
VM-Web-02 |
10.0.1.5 |
HTTPS sur le port 443 |
VM-Web-03 |
10.0.1.6 |
HTTPS sur le port 443 |
Un Azure Load Balancer public fournit le point d’entrée commun.
La configuration comprend :
- Une adresse IP publique frontale.
- Un pool contenant les trois machines.
- Une sonde HTTPS interrogeant
/health. - Une règle TCP associant le port frontal
443au port443des machines.
Lorsque les trois instances sont disponibles, les nouvelles connexions sont réparties entre elles.
Si l’application de VM-Web-02 cesse de répondre à la sonde, cette instance est écartée de la répartition des nouvelles connexions. Les deux autres continuent de servir les utilisateurs. Après son rétablissement et la réussite des contrôles d’intégrité, VM-Web-02 peut recevoir de nouvelles connexions. Cet exemple illustre le fonctionnement des pools, des règles et des sondes du service.
Haute disponibilité et montée en charge
Azure Load Balancer contribue à la haute disponibilité en dirigeant les nouvelles connexions vers les instances disponibles. Pour résister à la panne d’une zone de disponibilité, il faut également répartir les instances entre plusieurs zones et utiliser une configuration frontale adaptée à la redondance entre zones.
La disponibilité dépend aussi de l’ensemble de l’application. Trois serveurs web peuvent rester opérationnels tout en étant incapables de traiter les demandes si leur base de données commune est indisponible.
Concernant la montée en charge, Azure Load Balancer répartit le trafic, mais ne crée pas les machines virtuelles de l’application. L’ajout d’instances peut être réalisé manuellement ou automatisé, notamment avec Virtual Machine Scale Sets. Les instances ajoutées au pool participent ensuite à la répartition.
Pour faciliter ce fonctionnement, il est préférable que les instances ne dépendent pas de données conservées uniquement dans leur mémoire locale. Par exemple, les données de session peuvent être placées dans un stockage partagé.
Sécurité et supervision
La présence d’un équilibreur de charge ne suffit pas à autoriser les communications. Avec Azure Load Balancer Standard, les groupes de sécurité réseau, ou NSG, doivent permettre explicitement le trafic nécessaire.
Il faut également vérifier les règles du pare-feu du système d’exploitation, ainsi que l’accessibilité des ports utilisés par l’application et les sondes.
La supervision permet de suivre l’état des instances et de détecter une dégradation du service. Azure Monitor fournit des métriques et des outils de diagnostic associés à Load Balancer.
Azure Load Balancer ou Application Gateway ?
Le choix dépend du traitement attendu.
| Besoin | Service adapté |
|---|---|
| Répartir des connexions TCP ou des flux UDP entre des machines virtuelles | Azure Load Balancer |
| Router des requêtes HTTP selon leur chemin ou leur nom d’hôte | Azure Application Gateway |
| Centraliser la terminaison TLS pour une application web régionale | Azure Application Gateway |
| Ajouter un pare-feu applicatif web à une application régionale | Azure Application Gateway avec WAF |
| Distribuer du trafic HTTP/HTTPS à l’échelle mondiale | Azure Front Door |
Azure Load Balancer peut transporter du trafic HTTP ou HTTPS, mais il le traite au niveau réseau. Application Gateway et Front Door proposent des fonctions qui prennent en compte le protocole HTTP.