Résoudre les problèmes liés aux réponses du trafic des serveurs principaux Azure Load Balancer
Cette page contient des informations de résolution des problèmes liés aux questions relatives à Azure Load Balancer.
Les machines virtuelles situées derrière un équilibreur de charge reçoivent une distribution inégale du trafic
Si vous pensez que les membres du pool principal reçoivent du trafic, cela peut être dû aux causes suivantes. Azure Load Balancer distribue le trafic en fonction des connexions. Veillez à vérifier la distribution du trafic par connexion et non par paquet. Utilisez l’onglet Distribution du flux dans votre tableau de bord Insights de l’équilibreur de charge préconfiguré.
Azure Load Balancer ne prend pas en charge le véritable équilibrage de charge de tourniquet (round robin), mais prend en charge un mode de distribution basé sur le hachage.
Cause 1 : la persistance de session est configurée
L’utilisation du mode de distribution de la persistance source peut entraîner une répartition irrégulière du trafic. Si cette distribution n’est pas souhaitée, mettez à jour la persistance de session sur Aucune pour que le trafic soit réparti entre toutes les instances saines du pool principal. En savoir plus sur les modes de distribution pour Azure Load Balancer.
Cause 2 : un proxy est configuré
Les clients qui s’exécutent derrière des proxies peuvent être perçus comme une application cliente unique du point de vue de l’équilibreur de charge.
Les machines virtuelles situées derrière l’équilibreur de charge ne répondent pas au trafic sur le port de données configuré
Si une machine virtuelle d’un pool principal est répertoriée comme saine et répond aux sondes d’intégrité, mais ne participe toujours pas à l’équilibrage de charge ou ne répond pas au trafic de données. Cela peut être dû à l’une des raisons suivantes :
Une machine virtuelle du pool principal de l’équilibreur de charge n’écoute pas sur le port de données
Un groupe de sécurité réseau bloque le port sur la machine virtuelle du pool principal de l’équilibreur de charge
Accès à l’équilibreur de charge à partir des mêmes machine virtuelle et carte d’interface réseau
Accès au serveur frontal de l’équilibreur de charge Internet à partir de la machine virtuelle du pool principal de l’équilibreur de charge
Cause 1 : une machine virtuelle du pool principal de l’équilibreur de charge n’écoute pas sur le port de données
Si une machine virtuelle ne répond pas au trafic de données, il se peut que le port cible ne soit pas ouvert sur la machine virtuelle participant ou que la machine virtuelle n’écoute pas sur ce port.
Validation et résolution
Connectez-vous à la machine virtuelle principale.
Ouvrez une invite de commandes et exécutez la commande suivante pour vérifier qu’une application écoute sur le port de données :
netstat -anSi l’état du port indiqué n’est pas ÉCOUTE, configurez le port d’écoute approprié
Si l’état du port est ÉCOUTE, recherchez dans l’application cible sur ce port des problèmes possibles.
Cause 2 : un groupe de sécurité réseau bloque le port sur la machine virtuelle du pool principal de l’équilibreur de charge
Si un ou plusieurs groupes de sécurité réseau configurés sur le sous-réseau ou sur la machine virtuelle bloquent l’adresse IP source ou le port, alors la machine virtuelle ne peut pas répondre.
Pour l’équilibreur de charge public, l’adresse IP des clients Internet sera utilisée pour la communication entre les clients et les machines virtuelles principales de l’équilibreur de charge. Assurez-vous que l’adresse IP des clients est autorisée dans le groupe de sécurité réseau de la machine virtuelle principale.
Répertoriez les groupes de sécurité réseau configurés sur la machine virtuelle du pool principal. Pour plus d’informations, consultez Créer, modifier ou supprimer un groupe de sécurité réseau.
Dans la liste des groupes de sécurité réseau, vérifiez si :
Le trafic entrant ou sortant sur le port de données subit des interférences.
Une règle Refuser tout des groupes de sécurité réseau sur la carte d’interface réseau de la machine virtuelle ou du sous-réseau a une priorité supérieure à celle de la règle par défaut qui autorise les sondes et le trafic de l’équilibreur de charge (les groupes de sécurité réseau doivent autoriser l’adresse IP 168.63.129.16 de l’équilibreur de charge qui correspond au port de la sonde)
Si l’une des règles bloque le trafic, supprimez et reconfigurez ces règles pour autoriser le trafic de données.
Vérifiez si la machine virtuelle répond à présent aux sondes d’intégrité.
Cause 3 : accès à l’équilibreur de charge interne à partir des mêmes machine virtuelle et interface réseau
Si l’application hébergée sur la machine virtuelle principale d’un équilibreur de charge interne essaie d’accéder à une autre application hébergée dans la même machine virtuelle principale via la même interface réseau, ce scénario n’est pas pris en charge et échoue.
Résolution :
Vous pouvez résoudre ce problème en utilisant l’une des méthodes suivantes :
Configurez des machines virtuelles du pool principal distinctes par application.
Configurez l’application dans les machines virtuelles à double carte d’interface réseau afin que chaque application utilise sa propre interface réseau et adresse IP.
Cause 4 : accès au serveur frontal de l’équilibreur de charge interne à partir de la machine virtuelle du pool principal de l’équilibreur de charge
Si un serveur d’équilibreur de charge interne est configuré au sein d’un réseau virtuel, et si l’une des machines virtuelles principales participantes essaie d’accéder au serveur frontal d’équilibreur de charge interne, des défaillances peuvent se produire lorsque le flux est mappé à la machine virtuelle d’origine. Ce scénario n’est pas pris en charge.
Résolution :
Il existe plusieurs façons pour débloquer ce scénario, notamment l’utilisation d’un proxy. Évaluez Application Gateway ou d’autres proxies tiers (par exemple, nginx ou haproxy). Pour plus d’informations sur Application Gateway, consultez la page Vue d’ensemble de la passerelle Application Gateway.
Détails
Les équilibreurs de charge internes ne traduisent pas les connexions sortantes vers le front-end d’un équilibreur de charge interne, car ils se trouvent tous deux dans un espace d’adressage IP privé. Les équilibreurs de charge publics offrent des connexions sortantes d’adresses IP privées à l’intérieur du réseau virtuel vers des adresses IP publiques. Pour les équilibreurs de charge internes, cette approche évite le risque d’épuisement du port SNAT à l’intérieur de l’espace d’adressage IP interne unique quand la traduction n’est pas nécessaire.
Un des effets secondaires est que, si un flux sortant d’une machine virtuelle dans le pool de back-ends tente un flux vers le front-end de l’équilibreur de charge interne dans son pool et qu’il est mappé à lui-même, les deux branches du flux ne correspondent pas. Étant donné qu’ils ne correspondent pas, le flux échoue. Le flux réussit s’il n’a pas été mappé à la même machine virtuelle dans le pool de back-ends que celle qui a créé le flux vers le front-end.
Lorsque le flux est mappé avec lui-même, le flux sortant apparaît comme provenant de la machine virtuelle vers le serveur frontal et le flux entrant correspondant apparaît comme étant issu de la machine virtuelle vers elle-même. Du point de vue du système d’exploitation invité, les parties entrante et sortante d’un même flux ne correspondent pas à l’intérieur de la machine virtuelle. La pile TCP ne reconnaît pas ces deux moitiés de flux comme faisant partie du même flux. La source et la destination ne correspondent pas. Quand le flux est mappé à une autre machine virtuelle dans le pool de back-ends, les moitiés du flux correspondent et la machine virtuelle peut répondre au flux.
Le symptôme pour repérer ce scénario est la présence de délais d’expiration de connexion intermittents lorsque le flux retourne au back-end qui est à l’origine du flux. Les solutions de contournement courantes incluent l’insertion d’une couche de proxy derrière l’équilibreur de charge interne et l’utilisation de règles de style de retour direct du serveur (DSR). Pour plus d’informations, consultez Serveurs frontaux multiples dans Azure Load Balancer.
Vous pouvez combiner un équilibreur de charge interne avec un proxy tiers ou utiliser une Application Gateway interne pour les scénarios de proxy limités à HTTP/HTTPS. Vous pouvez utiliser un équilibreur de charge public pour résoudre ce problème, mais le scénario qui en résulte est sujet aux épuisements SNAT. Évitez cette deuxième approche, sauf si elle est soigneusement gérée.
Étapes suivantes
Si les étapes précédentes ne vous permettent pas de résoudre le problème, ouvrez un ticket d’incident.