Résoudre les problèmes liés à Azure Load Balancer
Azure Load Balancer fonctionne au niveau de la couche transport de la pile réseau. Load Balancer publie une seule adresse IP publique à laquelle tous les clients se connectent. Load Balancer utilise ensuite ses propres règles de traduction d’adresses et de routage pour diriger les demandes TCP entrantes vers l’une des adresses sortantes d’un ensemble. En règle générale, chaque adresse sortante est associée à une machine virtuelle différente, chacune exécutant une instance de votre application.
Load Balancer utilise une sonde d’intégrité pour déterminer la disponibilité de chaque machine virtuelle dans le pool principal. Load Balancer envoie uniquement des demandes aux machines virtuelles qui indiquent qu’elles sont saines.
Dans l’exemple de scénario, vous avez reçu des alertes indiquant que Load Balancer ne peut pas diriger des demandes vers des machines virtuelles du pool de back-ends. Vous soupçonnez qu’une modification récente de la configuration réseau est à l’origine du problème. Mais vous avez besoin de comprendre comment les modifications du réseau affectent le fonctionnement de Load Balancer.
À la fin de cette unité, vous êtes en mesure de :
- Décrire une configuration classique de Load Balancer, ainsi que les composants impliqués dans le routage des demandes vers des machines virtuelles.
- Expliquer les problèmes courants pouvant entraîner l’échec de la distribution des demandes aux machines virtuelles par Load Balancer.
Comment Load Balancer fonctionne-t-il ?
Azure Load Balancer inclut de nombreux composants :
- Une adresse IP front-end
- Un pool back-end d’adresses de machines virtuelles
- Une ou plusieurs règles de routage
- Une sonde d’intégrité
- Une collection de machines virtuelles, généralement dans un réseau virtuel
Le diagramme ci-dessous montre comment les différents éléments utilisés par Load Balancer fonctionnent ensemble.
Adresse IP front-end et pool back-end
Load Balancer fournit une connexion transparente de bout en bout entre un client et une application qui s’exécute sur une collection de machines virtuelles. Load Balancer stocke les adresses IP de ces machines virtuelles dans un référentiel communément appelé pool de back-ends. Load Balancer expose sa propre adresse IP front-end aux clients. Quand un client envoie une demande à cette adresse, Load Balancer sélectionne l’adresse IP d’une machine virtuelle dans le pool de back-ends. Load Balancer route ensuite la demande par le biais de cette adresse IP back-end vers la machine virtuelle.
Le client n’a pas conscience de Load Balancer. Le client voit une adresse IP ou un nom DNS, puis envoie des requêtes à cette destination. Ce processus serait le même si le client communiquait directement avec la machine virtuelle. Quand la demande arrive sur la machine virtuelle, l’adresse du client d’origine est conservée.
De plus, la charge utile des messages envoyés du client à la machine virtuelle est opaque pour Load Balancer. Load Balancer n’examine pas le contenu des messages et il ne les manipule pas. Il réadresse les messages afin qu’ils soient envoyés à la machine virtuelle sélectionnée.
Load Balancer sélectionne l’adresse IP d’une machine virtuelle à partir du pool back-end à l’aide d’un algorithme conçu pour distribuer les requêtes de manière homogène. Load Balancer génère un code de hachage à l’aide des informations suivantes :
- Adresse IP source et port du client
- Adresse IP de destination et port
- Protocole réseau
La valeur hachée est utilisée comme clé d’une table qui contient les adresses IP dans le pool de back-ends.
Évolutivité
Vous pouvez démarrer d’autres instances de machine virtuelle et ajouter leurs adresses IP au pool principal à tout moment. Load Balancer inclut ces nouvelles instances lors de la distribution des requêtes utilisateur.
Load Balancer peut exposer plusieurs adresses IP front-end publiques et peut avoir plusieurs pools back-end. Ce schéma vous permet de réutiliser la même instance de Load Balancer pour gérer les demandes pour différents systèmes.
Règles de routage
Vous définissez des règles d’équilibrage de charge pour spécifier la manière dont les requêtes dirigées vers chaque adresse IP front-end sont mappées à un pool back-end. Une règle d’équilibrage de charge spécifie également le protocole à mettre en correspondance et éventuellement les ports source (client) et de destination. Les requêtes entrantes qui arrivent sur une adresse IP front-end et qui ne correspondent pas aux exigences de protocole et de port sont ignorées par Load Balancer. Une règle d’équilibrage de charge peut également configurer la persistance de la session de sorte qu’un client donné soit susceptible de voir ses requêtes acheminées vers la même machine virtuelle, ce qui permet aux applications fonctionnant sur une machine virtuelle de tirer parti de la mise en cache pour conserver les informations spécifiques à la session.
Sondes d’intégrité
Load Balancer a besoin de déterminer si chaque machine virtuelle référencée par le pool de back-ends est disponible pour gérer les demandes. La disponibilité est déterminée par l’ajout d’une sonde de santé. Une sonde d’intégrité envoie des messages ping à un port que vous spécifiez pour les machines virtuelles du pool de back-ends. Vous fournissez un service sur les machines virtuelles qui répondent à ces messages ping par un message HTTP 200 (OK).
Quand la machine virtuelle ne parvient pas à répondre à l’issue d’un nombre spécifié de tentatives, Load Balancer suppose qu’elle n’est pas saine, et la retire de la liste des machines virtuelles capables d’accepter des demandes utilisateur. La charge de travail est alors répartie entre les machines virtuelles saines restantes. Load Balancer continue d’effectuer un test ping sur une machine virtuelle qui ne répond pas. Si la machine virtuelle commence à répondre, elle est rajoutée à la liste des machines virtuelles saines et recommence à recevoir des demandes utilisateur.
Si vous ne fournissez pas de sonde d’intégrité, Load Balancer ne sait pas si une machine virtuelle est saine. Il suppose alors que toutes les machines virtuelles répondent.
Réseau virtuel
Les machines virtuelles, référencées par le pool back-ends, sont hébergées dans un sous-réseau de réseau virtuel Azure. Pour protéger les machines virtuelles de ce réseau, vous configurez un groupe de sécurité réseau (NSG). Un NSG implémente des règles de sécurité de trafic entrant et sortant qui permettent de limiter le trafic qui entre dans le réseau virtuel et en sort à un ensemble de points de terminaison bien défini.
Par exemple, les machines virtuelles du pool back-end de Load Balancer autorisent généralement le trafic entrant sur le port 80 (HTTP) et le port 443 (HTTPS) qui provient de l’extérieur du réseau virtuel. Toutefois, les machines virtuelles peuvent bloquer le trafic qui passe par d’autres ports.
Symptômes et causes d’un échec avec Load Balancer
Des problèmes surviennent quand Load Balancer perd la connectivité avec une ou plusieurs machines virtuelles du pool de back-ends. Les symptômes classiques sont les suivants :
- L’application est inaccessible.
- Les machines virtuelles qui exécutent l’application sont inaccessibles.
- Les temps de réponse sont lents.
- Les requêtes utilisateur expirent.
Ces échecs peuvent avoir de nombreuses raisons. Ils sont le plus souvent associés à des problèmes de détection et de chemin de données.
Problèmes de sondage
Les problèmes de sondage se produisent quand une ou plusieurs machines virtuelles du pool back-end ne parviennent pas à répondre aux requêtes de la sonde d’intégrité. Ces problèmes peuvent être générés par les causes suivantes :
- Une configuration incorrecte de la sonde, notamment une URL incorrecte ou un port incorrect.
- Une machine virtuelle ne parvient pas à répondre à la sonde, car le port nécessaire n’est pas ouvert.
Problèmes de chemins de données
Les problèmes de chemins de données se produisent quand un équilibreur de charge ne parvient pas à router une requête client vers l’application qui s’exécute sur une machine virtuelle du pool back-end. Les causes possibles sont les suivantes :
- Une règle NSG ou de pare-feu bloque les ports ou les adresses IP utilisés par l’application.
- Une machine virtuelle est en panne ou ne répond pas. La machine virtuelle est peut-être désactivée ou défectueuse, ou il existe un problème de sécurité, comme un certificat arrivé à expiration sur le serveur.
- L’application ne répond pas. Les machines virtuelles sont peut-être surchargées, l’application écoute un port incorrect ou l’application est bloquée.