Server Load Balancer:CLB listener FAQ

Prise en charge de la redirection de port par CLB

Oui.

CLB prend en charge la redirection de port. Pour un exemple, consultez Utiliser CLB pour rediriger les requêtes HTTP vers HTTPS.

Prise en charge des plages de ports pour les écouteurs de couche 4

Non. Pour écouter sur une plage de ports avec un écouteur TCP ou UDP, créez une instance Network Load Balancer (NLB) et activez la fonctionnalité All Ports pour l'écouteur. Pour plus d'informations, consultez Utiliser la fonctionnalité d'écouteur All Ports de NLB pour transférer le trafic sur plusieurs ports.

Considérations relatives à la configuration du port de l'écouteur

Certains opérateurs classent les ports tels que 25, 135, 139, 444, 445, 5800 et 5900 comme présentant un risque élevé et les bloquent par défaut. Même si vous autorisez ces ports dans les règles du groupe de sécurité, les utilisateurs situés dans des régions restreintes peuvent ne pas être en mesure d'accéder à vos services. Nous vous recommandons d'utiliser d'autres ports non considérés comme à haut risque.

• Pour obtenir des informations sur les ports utilisés par les applications sur les systèmes Windows Server, consultez la documentation Microsoft Service overview and network port requirements for Windows Server.

• Pour plus d'informations sur les ports courants, consultez Ports courants.

Configuration de l'écouteur pour WebSocket

• Si vos serveurs backend hébergent des services WebSocket, vous pouvez configurer un écouteur TCP ou un écouteur HTTP.

• Si vos serveurs backend hébergent des services WebSocket Secure, vous pouvez configurer un écouteur TCP ou un écouteur HTTPS.

Effet des modifications de la configuration de l'écouteur

Les modifications prennent effet immédiatement et s'appliquent uniquement aux nouvelles requêtes. Les connexions existantes ne sont pas affectées.

Caractères spéciaux dans les règles de transfert d'URL

Vous devez encoder les caractères spéciaux d'une URL au format URL pour garantir un accès correct. Par exemple, le caractère dièse (#) est encodé sous la forme %23, de sorte que l'URL devient http://www.example.com/%23/. Pour connaître les règles d'encodage complètes, consultez la RFC 3986.

Gérer les serveurs backend pour les règles de transfert

Sur la page Forwarding Rule, cliquez sur le nom du groupe de serveurs virtuels cible dans la colonne Virtual Server Group. Sur la page Edit Virtual Server Group, vous pouvez ajouter ou supprimer des serveurs backend, ainsi que modifier leurs ports ou leurs pondérations.

CLB prend-il en charge la définition de limites de taille du corps de la requête ?

CLB ne prend pas en charge le paramètre client_max_body_size. La limite de taille du corps de la requête de 50 Go s'applique à Application Load Balancer (ALB), et non à CLB.

Pour contrôler la taille du corps de la requête, utilisez un écouteur TCP de couche 4 et configurez client_max_body_size sur le serveur web de l'instance ECS backend (tel que Nginx) :

http {
    client_max_body_size 100m;
}

Avec un écouteur TCP, CLB transfère le trafic de couche 4 de manière transparente, et la limite de taille du corps de la requête est appliquée par l'instance ECS backend.

Comment la bande passante est-elle calculée pour les instances CLB à bande passante fixe ?

La bande passante sortante et entrante d'une instance CLB à bande passante fixe sont calculées indépendamment. Après avoir défini la valeur de la bande passante fixe, les bandes passantes sortante et entrante sont plafonnées individuellement à la valeur configurée. Vous n'avez pas besoin de les additionner. Par exemple, si la bande passante fixe est définie sur 80 Mbit/s, la bande passante sortante maximale est de 80 Mbit/s et la bande passante entrante maximale est également de 80 Mbit/s. Les deux valeurs sont calculées indépendamment et ne s'influencent pas mutuellement.

Vous pouvez consulter les données de surveillance en temps réel de la bande passante sortante et entrante sur la page de surveillance de la console CLB. Dans les métriques de surveillance, inBitsPS représente la bande passante entrante et outBitsPS représente la bande passante sortante. Nous vous recommandons d'utiliser les données de surveillance au niveau de la minute dans la console comme référence lors de l'ajustement de la bande passante.

Perte de trafic sans dépassement de la limite de bande passante

Ce problème survient généralement pour les raisons suivantes :

• La surveillance de la bande passante d'Alibaba Cloud utilise des moyennes sur une minute. Si un pic de trafic instantané au cours d'une seconde dépasse la limite de bande passante de l'instance, le système supprime le trafic. Cela peut se produire même si la bande passante moyenne pour l'ensemble de la minute reste inférieure à la limite configurée. Par conséquent, le graphique de surveillance peut indiquer que l'utilisation globale de la bande passante est inférieure à la limite spécifiée.

• Les instances CLB s'exécutent sur un cluster de serveurs qui répartit uniformément les requêtes entrantes entre ses serveurs. La bande passante de crête configurée est également distribuée entre les serveurs du cluster. Si les données téléchargées par une seule connexion client dépassent le seuil d'un serveur individuel, le système supprime le trafic. Pour plus d'informations sur le calcul du trafic de téléchargement maximal pour une seule connexion, consultez Pourquoi une connexion ne peut-elle pas atteindre la bande passante de crête dans certains scénarios ?.

Le trafic surveillé dépasse la limite configurée

Les instances CLB utilisent un cluster de serveurs pour la limitation de débit distribuée. La limite de débit de crête pour un seul nœud est calculée comme suit : Limite de débit de crête pour un seul nœud = Bande passante totale configurée / (N - 1), où N est le nombre de nœuds dans le cluster. Par conséquent, la limite de débit effective totale peut être légèrement supérieure à la valeur configurée.

La connexion n'atteint pas la bande passante de crête

• Scénario : Une seule connexion à une instance CLB orientée vers Internet qui utilise la méthode de facturation par spécification (bande passante fixe) peut ne pas atteindre la bande passante de crête configurée. Ce problème survient souvent lors des tests de charge à partir d'un seul client ou lors du transfert d'un paquet de données très volumineux.

• Cause :

  Les instances CLB s'exécutent sur un cluster de serveurs. Le cluster répartit uniformément toutes les requêtes entrantes entre ses serveurs.

  Le trafic de téléchargement maximal pour une seule connexion est calculé comme suit : Trafic de téléchargement de crête par connexion = Bande passante totale configurée / (N - 1), où N est le nombre de serveurs dans le cluster. N est égal à 4 pour un écouteur de couche 4 et à 8 pour un écouteur de couche 7. Par exemple, si vous définissez la limite de bande passante sur 10 Mbit/s dans la console, la bande passante totale peut atteindre 10 Mbit/s lorsque plusieurs clients sont utilisés simultanément. Cependant, le trafic maximal qu'un seul client peut télécharger est de 10 / (4 - 1) = 3,33 Mbit/s.

• Solution :

  • Utilisez la méthode de facturation par trafic pour l'instance CLB orientée vers Internet.

  • Utilisez une instance NLB ou ALB avec une EIP et une bande passante partagée. Cette configuration est plus élastique et permet d'éviter cette limitation.

L'instance CLB n'atteint pas le QPS de crête

• Scénario : Lors de l'utilisation d'un petit nombre de connexions persistantes, les connexions peuvent ne pas être distribuées à tous les serveurs du cluster de transfert. Par conséquent, l'instance CLB peut ne pas atteindre son QPS de crête.

• Cause :

  Les instances CLB sont déployées dans un cluster. Le système répartit uniformément les requêtes entrantes entre les serveurs du cluster. Par conséquent, le QPS de crête d'une instance CLB est également distribué entre ces serveurs.

  Le QPS maximal pour un seul serveur est calculé comme suit : QPS de crête par serveur = QPS total de l'instance / (N - 1), où N est le nombre de serveurs dans le cluster de transfert. Par exemple, si vous achetez une instance CLB de spécification slb.s1.small, qui prend en charge 1 000 QPS, le QPS total peut atteindre 1 000 lorsque plusieurs clients sont utilisés. Cependant, si le cluster compte 8 serveurs, le QPS maximal pour un seul serveur est de 1000 / (8 - 1) = 142 QPS.

  Remarque

  Les nouveaux achats d'instances CLB facturées par spécification seront interrompus le 1er juin 2025 à 00:00:00 (UTC+8). Pour plus d'informations, consultez Arrêt de la commercialisation des instances CLB facturées par spécification.

• Solution :

  • Utilisez des connexions de courte durée à partir d'un seul client pour les tests de charge.

  • Réduisez la réutilisation des connexions en fonction de vos besoins métier réels.

  • Mettez à niveau la spécification de l'instance CLB. Pour plus d'informations, consultez Mettre à niveau ou rétrograder une instance à la demande (facturée par spécification).

  • Utilisez une instance ALB. Ce type d'instance offre une plus grande élasticité.

Le taux de nouvelles connexions n'atteint pas le pic

• Scénario : Lorsque vous utilisez une instance Classic Load Balancer (CLB) facturée par spécification, son taux de nouvelles connexions (CPS) peut ne pas atteindre le niveau spécifié, en particulier lors des tests de charge à partir d'un seul client ou lorsque le trafic provient d'une source unique.

  Remarque

  Les nouveaux achats d'instances CLB facturées par spécification seront interrompus le 1er juin 2025 à 00:00:00 (UTC+8). Pour plus d'informations, consultez Arrêt de la commercialisation des instances CLB facturées par spécification.

• Cause :

  Le système d'équilibrage de charge utilise une architecture en cluster pour assurer une haute disponibilité et une évolutivité. Il répartit uniformément les demandes de connexion entrantes entre les serveurs du cluster. Par conséquent, le CPS de crête d'une instance CLB est également distribué entre ces serveurs.

  Le CPS de crête pour un seul serveur est calculé comme suit : CPS de crête par serveur = CPS total de l'instance / (N - 1), où N est le nombre de serveurs dans le cluster de transfert.

  Par exemple, si vous achetez une instance CLB de spécification slb.s1.small évaluée à 3 000 CPS, l'instance peut atteindre les 3 000 CPS complets avec des requêtes provenant de plusieurs clients. Cependant, si le cluster compte 4 serveurs, le CPS maximal pour un seul serveur est de 3000 / (4 - 1) = 1 000 CPS.

• Solution :

  • Modifiez la méthode de facturation de l'instance de « facturée par spécification » à « facturée à l'utilisation ». Les instances facturées à l'utilisation ne sont pas liées à une spécification de performance spécifique et offrent des limites plus élevées, ce qui permet d'éviter les goulots d'étranglement.

  • Effectuez une mise à niveau vers un Network Load Balancer (NLB) pour les scénarios nécessitant une concurrence élevée et un taux élevé de nouvelles connexions. NLB offre des performances et une élasticité supérieures par rapport à CLB. Une seule instance NLB prend en charge 100 millions de connexions simultanées, ce qui la rend idéale pour les applications à grande échelle et permet d'éviter les limitations de CPS de l'architecture en cluster de CLB.

Plages de délai d'expiration de connexion prises en charge

• Délai d'expiration de connexion pour l'écouteur TCP : 10 à 900 secondes.

• Écouteur HTTP :

  • Délai d'inactivité : 1 à 60 secondes.

  • Délai d'expiration de la requête : 1 à 180 secondes.

• Écouteur HTTPS :

  • Délai d'inactivité : 1 à 60 secondes.

  • Délai d'expiration de la requête : 1 à 180 secondes.

Causes des délais d'expiration de connexion CLB

Les problèmes côté serveur suivants peuvent provoquer des délais d'expiration de connexion vers l'adresse de service CLB :

• L'adresse de service est bloquée par des mesures de sécurité

  Cela inclut le nettoyage du trafic, le filtrage en trou noir ou la protection WAF. Par exemple, le WAF envoie des paquets RST au client et au cluster de serveurs après l'établissement de la connexion.

• Nombre insuffisant de ports clients

  Ce problème est fréquent lors des tests de charge. Une pénurie de ports clients peut entraîner des échecs de connexion. Par défaut, CLB supprime l'option d'horodatage des connexions TCP, ce qui empêche la fonctionnalité tw_reuse du noyau Linux (réutilisation des connexions dans l'état TIME_WAIT) de prendre effet. Cela conduit à une accumulation de connexions dans l'état TIME_WAIT et à une pénurie de ports clients disponibles.

  Solution : Utilisez des connexions persistantes plutôt que des connexions éphémères. Déconnectez-vous en envoyant un paquet RST via l'option de socket SO_LINGER au lieu d'envoyer un paquet FIN.

• La file d'attente d'acceptation du serveur backend est pleine

  Si la file d'attente d'acceptation d'un serveur backend est pleine, celui-ci n'envoie pas de réponse SYN-ACK, ce qui provoque un délai d'expiration côté client.

  Solution : La valeur par défaut de net.core.somaxconn est 128. Évaluez votre volume de trafic et ajustez cette valeur selon vos besoins. Ensuite, exécutez sysctl -w net.core.somaxconn=<new_value> pour modifier le paramètre et redémarrez l'application sur le serveur backend.

• Un serveur backend de couche 4 accède à l'adresse de service de son propre équilibreur de charge

  Les écouteurs de couche 4 CLB (TCP/UDP) n'autorisent pas un serveur backend à agir simultanément en tant que client et serveur. Si un serveur backend tente d'accéder à l'adresse de service de l'instance CLB à laquelle il est associé, la connexion échouera. Les scénarios déclencheurs courants incluent une application backend qui redirige vers l'adresse de service CLB en construisant une URL, ou une instance ECS dans un VPC qui accède à l'adresse de service de sa propre instance CLB via le réseau public, ce qui provoque une boucle de trafic.

  Ce comportement est dû à la manière dont CLB transfère le trafic au niveau de la couche 4 (LVS). Lorsqu'une instance ECS backend envoie un paquet à l'instance CLB, CLB réécrit l'adresse IP de destination et transfère le paquet à un serveur backend. Si CLB renvoie la requête à la même instance ECS qui l'a envoyée, les adresses IP source et destination du paquet sont toutes deux l'adresse IP de cette instance ECS. Par conséquent, la réponse est traitée localement sur l'instance ECS et ne repasse jamais par CLB, empêchant ainsi l'établissement de la connexion.

  • Si l'instance CLB ne possède qu'un seul serveur backend, chaque requête provenant de ce serveur lui est renvoyée, entraînant un taux d'échec de connexion de 100 %.

  • Si l'instance CLB dispose de plusieurs serveurs backend, par exemple deux serveurs avec des poids égaux, CLB transfère environ 50 % des requêtes vers l'autre serveur backend (la connexion réussit). CLB renvoie environ 50 % des requêtes au serveur backend d'origine (la connexion échoue). Le taux de réussite global est d'environ 50 %.

  Solution :

  • Utilisez un client différent pour accéder à l'adresse de service au lieu du serveur backend de couche 4.

  • Migrez vers une instance Network Load Balancer (NLB) et désactivez la fonction client IP preservation dans le groupe de serveurs. Une fois cette fonctionnalité désactivée, une instance ECS du groupe de serveurs peut agir à la fois comme serveur backend et comme client de l'instance NLB. Pour obtenir l'adresse IP source du client, activez le Proxy Protocol. Pour plus d'informations, consultez Comment une instance ECS peut-elle agir à la fois comme serveur backend et comme client d'une instance NLB ?.

  • Utilisez Alibaba Cloud DNS PrivateZone pour configurer la résolution de noms de domaine privés afin que le nom de domaine de service soit résolu vers l'adresse IP privée du serveur backend. Les requêtes atteignent alors directement le serveur backend via le réseau interne sans passer par l'instance CLB, ce qui élimine la condition de bouclage. Cette approche s'applique lorsqu'un serveur backend accède au service de l'instance CLB à laquelle il est attaché en utilisant un nom de domaine. Notez que les requêtes contournent CLB dans ce cas et ne bénéficient plus de l'équilibrage de charge ni des vérifications d'état. Utilisez cette approche uniquement pour les requêtes initiées par les serveurs backend eux-mêmes.

  • Modifiez le fichier hosts sur le serveur où s'exécute le client afin que le nom de domaine de service pointe vers l'adresse IP privée du serveur backend. L'effet est identique à celui de PrivateZone, et cette approche convient aux scénarios où vous avez besoin de la solution de contournement sur seulement quelques serveurs individuels. Étant donné qu'un fichier hosts doit être maintenu sur chaque serveur, privilégiez PrivateZone lorsque vous disposez d'un grand nombre de serveurs backend.

• Gestion incorrecte des paquets RST lors du délai d'expiration de connexion

  Après l'établissement d'une connexion TCP, s'il n'y a aucune activité pendant 900 secondes, CLB envoie des paquets RST au client et au serveur pour fermer la connexion. Certaines applications peuvent ne pas gérer correctement le paquet RST et tenter d'envoyer des données sur la connexion fermée, provoquant ainsi un délai d'expiration de l'application.

  Remarque

  Le délai d'expiration par défaut est de 900 secondes, mais il peut être ajusté selon les besoins.

Délais d'expiration de connexion HTTP et HTTPS

• Une connexion persistante HTTP prend en charge un maximum de 100 requêtes consécutives. Une fois cette limite atteinte, CLB ferme la connexion.

• Le délai d'inactivité entre deux requêtes HTTP ou HTTPS sur une connexion persistante est configurable de 1 à 60 secondes (avec une marge d'erreur de 1 à 2 secondes). Si ce délai est dépassé, la connexion TCP est fermée. Si votre application utilise des connexions persistantes, nous vous recommandons d'envoyer une requête de maintien actif (heartbeat) au moins toutes les 13 secondes.

• La poignée de main TCP en trois étapes entre une instance CLB et une instance ECS backend expire après 5 secondes. En cas d'expiration, CLB essaie l'instance ECS suivante. Vous pouvez identifier ce problème en vérifiant le temps de réponse amont dans le journal d'accès.

• Le délai d'expiration de la requête (le temps qu'une instance CLB attend une réponse d'une instance ECS) est configurable de 1 à 180 secondes. Si ce délai est dépassé, CLB renvoie généralement un code d'état 504 ou 408 au client. Vous pouvez identifier ce problème en vérifiant le temps de réponse amont dans le journal d'accès.

• Le délai d'expiration de réutilisation de session HTTPS est de 300 secondes. Après cette période, le même client doit effectuer à nouveau une poignée de main SSL complète.

CLB effectue-t-il automatiquement une nouvelle tentative de requête après un délai d'expiration ?

Non. Si une requête dépasse le délai d'expiration de requête configuré de l'écouteur (par exemple, 60 secondes par défaut), CLB met fin à la connexion et renvoie un code d'erreur 504 au client. CLB ne retente pas automatiquement la requête. Pour mettre en œuvre des nouvelles tentatives de requête, vous devez implémenter la logique de nouvelle tentative côté client.

Mécanisme de nouvelle tentative implicite pour les écouteurs HTTPS de couche 7 CLB

Lorsqu'un serveur backend ne répond pas ou renvoie une erreur sur un écouteur HTTPS de couche 7 CLB, CLB déclenche automatiquement un mécanisme de nouvelle tentative implicite. CLB essaie séquentiellement d'autres serveurs backend sains. La nouvelle tentative est initiée par CLB lui-même et ne dépend pas du client. En cas de délai d'expiration, CLB enregistre une erreur 504 et retente vers un autre nœud backend. Seul le résultat de la dernière tentative est renvoyé au client.

Afficher les enregistrements de nouvelle tentative : La console CLB ne fournit pas d'interface dédiée pour interroger les journaux de nouvelles tentatives. Vous pouvez afficher les enregistrements de nouvelles tentatives dans les journaux d'accès CLB. Plusieurs valeurs dans le champ upstream_addr (séparées par des virgules) servent de preuve d'une nouvelle tentative. Les multiples valeurs dans upstream_response_time correspondent aux temps de réponse de chaque tentative. Par exemple, upstream_addr: 10.0.0.1:80, 10.0.0.2:80 indique que CLB a tenté deux serveurs backend séquentiellement.

Comportement de CLB lors d'une déconnexion client prématurée

Non. CLB ne ferme pas la connexion au serveur backend pendant les opérations de lecture et d'écriture.

Activer les connexions persistantes backend pour CLB

Les instances CLB ne prennent pas en charge les connexions persistantes backend. Pour utiliser cette fonctionnalité, créez une instance ALB, configurez un écouteur HTTP ou HTTPS et activez les connexions persistantes backend pour le groupe de serveurs ALB correspondant. Pour plus d'informations, consultez Créer et gérer un groupe de serveurs.

Dépanner une latence élevée de CLB

L'accès à un service backend via une instance CLB introduit une petite quantité de latence supplémentaire par rapport à l'accès direct au serveur backend. Ceci est normal. Les écouteurs de couche 7 CLB utilisent une architecture de proxy inverse (Tengine), qui ajoute un saut réseau supplémentaire et un temps de traitement de protocole. La latence supplémentaire pour les écouteurs de couche 4, qui utilisent LVS pour le transfert, est généralement plus faible.

Si vous constatez une latence significativement élevée, suivez ces étapes pour résoudre le problème :

1. Activez les journaux d'accès et analysez les champs de latence : Activez les journaux d'accès CLB et concentrez-vous sur les champs suivants :

   • request_time : L'intervalle, en secondes, entre le moment où CLB reçoit le premier paquet de requête et le moment où il renvoie la réponse.

   • upstream_response_time : L'intervalle, en secondes, entre l'établissement d'une connexion à un serveur backend et la réception complète des données suivie de la fermeture de la connexion.

2. Identifiez la source de la latence :

   • Si upstream_response_time est élevé : La latence est probablement causée par un traitement lent sur le serveur backend. Vérifiez les performances de l'application backend, l'efficacité des requêtes de base de données et l'utilisation des ressources (CPU/mémoire), ou ajoutez davantage de serveurs backend pour répartir la charge.

   • Si request_time est beaucoup plus grand que upstream_response_time, la latence peut se situer dans le lien réseau entre le client et CLB. Vous pouvez exécuter un test ping continu ou effectuer un traçage de route MTR depuis le client vers l'adresse de service CLB pour résoudre les problèmes de lien réseau.

3. Accès interrégional : Si le client et l'instance CLB se trouvent dans différentes régions, la latence réseau due à la distance physique est inévitable. Nous vous recommandons d'utiliser Global Accelerator (GA) pour optimiser l'expérience d'accès interrégional.

Dépanner les erreurs 502, 503 ou 504

Lorsque vous accédez à un service backend via une instance CLB, les codes d'erreur 502, 503 ou 504 indiquent généralement que la requête n'a pas été traitée correctement par le serveur backend. Voici la signification de ces codes d'erreur :

• 502 Bad Gateway : CLB n'a pas pu transférer la requête à un serveur backend ou recevoir une réponse de celui-ci. Les causes courantes incluent des services backend inaccessibles ou l'échec de toutes les vérifications d'état.

• 503 Service Temporarily Unavailable : Cela est généralement causé par un trafic dépassant les limites ou par un serveur backend indisponible. Cette erreur est renvoyée lorsque le trafic instantané dépasse les limites de la spécification de l'instance CLB.

• 504 Gateway Timeout : Le serveur backend a expiré. Les causes courantes incluent des temps de traitement longs côté backend ou un délai d'expiration lors de l'établissement d'une connexion au serveur backend.

Première étape : Vérifiez les journaux d'accès

Commencez par activer les journaux d'accès CLB et vérifiez les champs status (code d'état renvoyé par CLB au client) et upstream_status (code d'état renvoyé par le serveur backend à CLB) dans les journaux :

• Si status et upstream_status sont identiques, CLB a probablement transmis directement le code d'erreur du serveur backend. Recherchez pourquoi le serveur backend renvoie cette erreur.

• Si upstream_status est "-" ou différent de status, l'erreur a été renvoyée par CLB. Reportez-vous aux points suivants pour résoudre le problème.

Dépannage des erreurs 502

• Échec de toutes les vérifications d'état des serveurs backend : Lorsque tous les serveurs backend associés à un écouteur échouent aux vérifications d'état, CLB ne peut pas transférer les requêtes et renvoie à la place une erreur 502. Vérifiez l'état des vérifications d'état dans la console et résolvez la cause de l'échec, telle que iptables ou un logiciel de sécurité tiers bloquant le bloc CIDR système CLB 100.64.0.0/10, un code d'état de vérification d'état non concordant ou un chemin de vérification d'état inexistant. Pour plus d'informations, consultez la FAQ sur les vérifications d'état CLB.

• Le backend renvoie un code d'erreur que CLB convertit en 502 : Si un serveur backend renvoie certains codes d'erreur (tels que 504 ou 444), CLB peut renvoyer une erreur 502 au client. Vérifiez le champ upstream_status dans le journal d'accès pour confirmer le code d'état réel renvoyé par le backend et investigatez la cause de l'erreur backend.

• Erreurs de service backend : Une charge élevée, des réponses mal formées ou des fermetures de connexion inattendues sur le serveur backend peuvent également provoquer des erreurs 502. Vérifiez les journaux du serveur backend et l'utilisation des ressources, telles que le CPU et la mémoire.

Dépannage des erreurs 503

• Le trafic dépasse les limites de spécification de l'instance : CLB renvoie une erreur 503 si les QPS, la bande passante ou le taux de nouvelles connexions du trafic entrant dépassent les limites de la spécification actuelle de l'instance CLB. Vous pouvez récupérer ces métriques depuis Cloud Monitor.

• Le trafic instantané dépasse les limites mais n'apparaît pas dans la surveillance : Cloud Monitor affiche les données avec une granularité à la minute et peut ne pas montrer les pics à la seconde. Vérifiez le nombre de requêtes à la seconde dans le journal d'accès. Si upstream_status est "-", cela indique que la requête n'a pas été envoyée au serveur backend.

Dépannage des erreurs 504

• Délai d'expiration de la réponse backend : Si le serveur backend ne répond pas dans le délai d'expiration de requête configuré pour l'écouteur, CLB renvoie une erreur 504. Vérifiez le champ upstream_response_time dans le journal d'accès pour confirmer le temps de réponse réel du backend et ajustez le délai d'expiration de requête de l'écouteur en conséquence.

• Délai d'expiration de la connexion backend : Le délai pour qu'une instance CLB termine une poignée de main TCP en trois étapes avec une instance ECS backend est de 5 secondes. Si upstream_response_time dans le journal d'accès est trop long, cela peut indiquer un problème de connexion avec le serveur backend. Nous vous recommandons de capturer les paquets pour investiguer la cause.

• Charge backend élevée : Une utilisation élevée des ressources (CPU, mémoire, etc.) sur le serveur backend peut entraîner des temps de réponse dépassant le délai d'expiration. Investiguez et optimisez les performances du service backend, ou ajoutez davantage de serveurs backend pour répartir la charge.

Dépanner les problèmes d'accès CLB

Si vous ne pouvez pas accéder à votre service après avoir configuré une instance CLB, suivez ces étapes pour résoudre le problème couche par couche :

1. Vérifiez la résolution de nom de domaine : Si vous accédez au service en utilisant un nom de domaine, assurez-vous que le nom de domaine se résout correctement vers l'adresse de service de l'instance CLB. Vous pouvez utiliser les commandes nslookup ou dig pour vérifier la résolution. Une résolution de nom de domaine incorrecte est une cause fréquente d'échecs d'accès.

2. Vérifiez la configuration de l'écouteur : Dans la console CLB, vérifiez si un écouteur a été créé et confirmez que le port et le protocole de l'écouteur sont correctement configurés. Si un écouteur est manquant ou mal configuré, CLB ne peut pas transférer les requêtes.

3. Vérifiez l'état des vérifications d'état : Dans la console CLB, vérifiez l'état des vérifications d'état des serveurs backend. Si tous les serveurs backend échouent aux vérifications d'état, CLB ne peut pas transférer les requêtes.

4. Vérifiez les paramètres du pare-feu : Vérifiez si iptables ou un logiciel de sécurité tiers sur le serveur backend autorise le port du service backend et le bloc CIDR système CLB 100.64.0.0/10.

5. Vérifiez que le service backend fonctionne correctement : Connectez-vous directement au serveur backend et confirmez que le service backend lui-même répond en exécutant telnet <private IP address of the backend server> <port> (couche 4) ou curl -I http://<private IP address of the backend server> (couche 7).

6. Résolvez les problèmes de lien réseau : Testez l'accès à l'adresse de service CLB depuis différents environnements réseau. Si seul votre réseau local est affecté, vous pouvez exécuter un test ping continu ou utiliser le traçage de route MTR pour une investigation plus approfondie.

Accès par IP mais pas par nom de domaine

La raison la plus courante est que le nom de domaine n'a pas terminé son dépôt ICP.

Conformément à la réglementation, lorsqu'un nom de domaine est utilisé pour un accès public en Chine continentale, il doit disposer d'un dépôt ICP valide. L'accès aux domaines sans dépôt ICP est bloqué, entraînant un code d'état 403 ou une réinitialisation de connexion.

Nous vous recommandons de suivre ces étapes pour résoudre le problème :

1. Vérifiez l'état du dépôt ICP : Connectez-vous au Système de dépôt ICP Alibaba Cloud pour vérifier si votre nom de domaine a terminé son dépôt ICP. Si ce n'est pas le cas, terminez d'abord le processus. Pour plus d'informations, consultez le processus de dépôt ICP.

2. Vérifiez si vous devez transférer votre dépôt ICP : Si votre nom de domaine possède un dépôt ICP auprès d'un autre fournisseur de services cloud mais que vous l'utilisez avec Alibaba Cloud pour la première fois, vous devez également effectuer un transfert de dépôt ICP pour associer les informations de dépôt à Alibaba Cloud. L'absence de ce transfert peut également entraîner un blocage de l'accès.

3. Écartez les autres causes : Si le nom de domaine possède un dépôt ICP et que le transfert de dépôt ICP est également terminé, vérifiez si la résolution du nom de domaine pointe correctement vers l'adresse de service de CLB (vous pouvez utiliser la commande nslookup ou dig pour vérifier), et si la configuration du port et du protocole de l'écouteur CLB correspond à la méthode d'accès par nom de domaine.

Impact du contrôle d'accès sur le trafic interne

Oui. Le contrôle d'accès s'applique au niveau de l'écouteur et affecte à la fois le trafic interne et public. Si vous configurez une liste d'autorisation qui n'autorise que des adresses IP publiques spécifiques, les requêtes provenant d'adresses IP internes ne figurant pas sur la liste d'autorisation seront bloquées. Pour éviter de perturber les services internes, nous vous recommandons d'ajouter les blocs CIDR internes pertinents à la liste d'autorisation ou d'utiliser Cloud Firewall pour restreindre l'accès public à l'EIP.

Dépanner les délais d'expiration de requête lors des tests de charge

Lorsque vous effectuez un test de charge sur un CLB de couche 7, si vous recevez des codes d'état 504 ou des délais d'expiration de requête, et que upstream_response_time dans les journaux est regroupé autour de 5 secondes, le problème est généralement un délai d'expiration de connexion causé par l'échec de la poignée de main TCP en trois étapes entre le CLB et le serveur backend. Une raison courante est que la table de suivi de connexion (nf_conntrack) sur le serveur backend est pleine, ce qui amène le serveur à abandonner les paquets pour les nouvelles connexions.

Connectez-vous au serveur backend et vérifiez le journal /var/log/messages . Vous pouvez confirmer le problème si le message d'erreur suivant apparaît :

nf_conntrack: table full, dropping packet

Solution : Ajustez les valeurs des paramètres nf_conntrack suivants en fonction de vos exigences de service réelles :

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_buckets=262144
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

Remarque : La commande précédente prend effet uniquement temporairement. Les modifications sont perdues après le redémarrage de l'instance. Pour rendre les modifications permanentes, écrivez les paramètres dans /etc/sysctl.conf.

Impact des défaillances du backend sur les écouteurs partagés

Scénario : Vous hébergez plusieurs sites web, tels qu'un site statique www.example.com et un site dynamique app.example.com, rattachés au même écouteur CLB. Lorsque la base de données backend du site dynamique tombe en panne, le site statique devient également inaccessible et renvoie une erreur HTTP 502.

Cause : Les deux sites partagent le même écouteur, dont le paramètre Health Check Domain Name est configuré avec le nom de domaine du site dynamique. En cas de défaillance du backend du site dynamique, tous les serveurs backend échouent aux tests d'intégrité. Par conséquent, CLB cesse de transférer le trafic vers le backend, ce qui affecte tous les sites configurés sous cet écouteur.

Solution : Utilisez des instances CLB distinctes pour assurer l'équilibrage de charge des sites dynamiques et statiques, afin d'isoler les activités. Ainsi, une défaillance du site dynamique n'affectera pas le site statique.

Raisons de l'échec de la persistance de session

• La persistance de session n'est pas activée : Vérifiez si la persistance de session est activée dans la configuration de l'écouteur.

• Problèmes liés aux écouteurs HTTP/HTTPS : Pour un écouteur HTTP ou HTTPS, CLB ne peut pas insérer le cookie requis pour la persistance de session dans une réponse 4xx.

  Solution : Basculez vers un écouteur TCP, qui utilise l'adresse IP source du client pour maintenir la persistance de session. Pour plus de fiabilité, vous pouvez également insérer un cookie sur l'instance ECS backend et ajouter une vérification de validité du cookie.

• Problèmes de redirection 302 : Une redirection 302 peut modifier la chaîne SERVERID utilisée pour la persistance de session.

  Si une instance ECS backend émet une redirection 302, elle peut altérer la chaîne SERVERID dans le cookie injecté par CLB, ce qui rompt la persistance de session.

  Dépannage : Utilisez les outils de développement de votre navigateur ou un analyseur de paquets pour capturer les requêtes et les réponses. Analysez les paquets pour vérifier la présence de réponses de redirection 302 et comparez les chaînes SERVERID dans les cookies avant et après la redirection.

  Solution : Basculez vers un écouteur TCP, qui utilise l'adresse IP source du client pour maintenir la persistance de session. Pour plus de fiabilité, vous pouvez également insérer un cookie sur l'instance ECS backend et ajouter une vérification de validité du cookie.

• Le délai d'expiration de la persistance de session est trop court : Si la valeur du délai d'expiration est définie trop bas, la persistance de session peut échouer.

Affichage de la chaîne de persistance de session

Vous pouvez utiliser les outils de développement de votre navigateur (F12) pour vérifier si les en-têtes de réponse contiennent la chaîne SERVERID ou un mot-clé personnalisé. Vous pouvez également exécuter la commande curl www.example.com -c /tmp/cookie123 pour enregistrer le cookie, puis exécuter curl www.example.com -b /tmp/cookie123 pour envoyer le cookie lors de la requête suivante.

Test de la persistance de session avec curl

1. Créez une page de test.

   Sur chaque instance ECS backend, créez une page de test qui affiche l'adresse IP privée de l'instance. Cette adresse identifie le serveur qui traite une requête. Si l'adresse IP reste cohérente sur plusieurs requêtes, la persistance de session fonctionne.

2. Exécutez la commande curl sur un système Linux.

   Supposons que l'adresse IP du service CLB soit 10 170.XX.XX et que l'URL de la page de test soit http://10.170.XX.XX/check.jsp.

   1. Connectez-vous au serveur Linux que vous utiliserez pour les tests.

   2. Exécutez la commande suivante pour récupérer le cookie depuis l'équilibreur de charge.

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      Remarque

      Par défaut, CLB utilise l'injection de cookie pour la persistance de session. Cependant, curl n'enregistre ni n'envoie de cookies par défaut. Vous devez enregistrer le cookie avant de tester. Sinon, les requêtes curl suivantes seront envoyées sans cookie, entraînant un routage aléatoire, ce qui pourrait vous amener à conclure à tort que la persistance de session ne fonctionne pas.

   3. Exécutez la commande suivante pour effectuer des tests continus.

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      Remarque

      Dans a≤30, 30 représente le nombre de tests répétés et peut être modifié selon vos besoins. La commande grep '10.170.XX.XX' filtre les informations d'IP affichées. Remplacez 10.170.XX.XX par l'adresse IP privée de l'instance ECS backend.

   4. Observez les adresses IP renvoyées par le test. Si toutes les réponses proviennent de la même adresse IP privée du serveur backend, la persistance de session fonctionne correctement. Dans le cas contraire, elle ne fonctionne pas.

Configuration des cookies backend pour le mode Rewrite Cookie****

Si vous sélectionnez le mode Rewrite Cookie pour la persistance de session de couche 7, vous devez configurer un cookie portant le même nom sur vos serveurs backend. Le nom du cookie doit être identique à celui configuré dans la console CLB. Les exemples suivants montrent comment procéder sur des serveurs web courants :

server {
    listen 8080;
    server_name wqwq.example.com;
    location / {
        add_header Set-Cookie name=xxxx;
        root   html;
        index  index.html index.htm;
    }
}

Dépannage d'une charge serveur inégale

Si plusieurs serveurs backend sont rattachés à une instance CLB et que l'un d'eux présente une charge significativement plus élevée que les autres, suivez ces étapes pour résoudre le problème :

1. Vérifiez si la persistance de session est activée : Les écouteurs HTTP/HTTPS de CLB prennent en charge la persistance de session via l'injection de cookie. Lorsque cette fonctionnalité est activée, toutes les requêtes provenant du même client sont acheminées vers le même serveur backend. Si quelques clients génèrent un grand nombre de requêtes, cela concentre le trafic sur des serveurs backend spécifiques, entraînant une charge inégale.

2. Désactivez la persistance de session pour une répartition uniforme : Si votre application ne dépend pas de l'état de la session (comme les cookies ou l'état de connexion), désactivez la persistance de session pour l'écouteur. Une fois désactivée, CLB répartit les requêtes uniformément sur tous les serveurs backend selon l'algorithme de planification configuré, tel que le round-robin pondéré. Effectuez cette action pendant les heures creuses et vérifiez immédiatement que votre application reste disponible. La désactivation de la persistance de session affectera les services avec état, tels que les paniers d'achat ou les connexions persistantes. Évaluez la dépendance de votre application à la persistance de session avant de procéder.

3. Vérifiez la charge applicative sur les serveurs backend : Même si CLB répartit le trafic uniformément, des différences d'utilisation du CPU, de la mémoire ou d'autres ressources sur les serveurs backend eux-mêmes peuvent entraîner une charge plus élevée sur certains serveurs. Connectez-vous à chaque serveur backend, comparez l'utilisation des ressources de vos applications et recherchez les goulots d'étranglement de performance.

Échec du chargement des styles via HTTPS

Symptôme :

Vous disposez d'un écouteur HTTP et d'un écouteur HTTPS, tous deux utilisant les mêmes serveurs backend. Lorsque vous accédez au site web via l'écouteur HTTP, il s'affiche correctement. Cependant, lorsque vous y accédez via l'écouteur HTTPS, sa mise en page apparaît brisée.

Cause :

Un équilibreur de charge ne bloque pas les fichiers JavaScript (JS) par défaut. Ce problème peut être causé par les éléments suivants :

• Le certificat n'est pas compatible avec le niveau de sécurité du navigateur.

• Le certificat provient d'un fournisseur tiers non fiable. Contactez l'émetteur pour résoudre ce problème.

Solution :

1. Lorsque vous ouvrez le site web, suivez les invites du navigateur pour charger les scripts.

2. Ajoutez le certificat correspondant au magasin de confiance du client.

Certificats de serveur backend pour la redirection HTTP vers HTTPS

Non. Vous devez uniquement configurer un certificat sur l'écouteur HTTPS de l'instance CLB. Pour plus d'informations, consultez Configurer un certificat SSL.

Le navigateur affiche l'ancienne date d'expiration du certificat après la mise à jour

Cela se produit généralement si l'instance CLB est intégrée de manière transparente à WAF 2.0 et que le certificat de WAF n'a pas été mis à jour. WAF synchronise périodiquement les certificats depuis CLB. Pour déclencher une synchronisation immédiate, vous pouvez désactiver puis réactiver la redirection du trafic dans la console WAF afin de forcer l'actualisation du certificat. Cette action peut provoquer une brève interruption de service, durant 1 à 2 secondes.

Version du protocole HTTP pour l'accès au serveur backend

• Si une requête client utilise HTTP/1,1 ou HTTP/2,0, l'écouteur de couche 7 communique avec le serveur backend en utilisant HTTP/1,1.

• Si une requête client utilise une version de protocole autre que HTTP/1,1 ou HTTP/2,0, l'écouteur de couche 7 communique avec le serveur backend en utilisant HTTP/1,0.

Récupération de la version du protocole client

Oui.

Limitation de débit basée sur l'URL

CLB ne prend pas en charge la limitation de débit basée sur l'URL, mais uniquement la limitation de bande passante au niveau de l'écouteur.

ALB prend en charge la limitation de débit basée sur l'URL. Vous pouvez configurer une règle de transfert d'écouteur pour appliquer une limitation QPS à un chemin spécifique. Cette fonctionnalité doit être utilisée conjointement avec l'action « Forward to ».

CLB prend-il en charge SSE (Server-Sent Events) ?

SSE (Server-Sent Events) est une technologie basée sur HTTP qui permet aux serveurs de pousser des données vers les clients de manière unidirectionnelle. Elle est couramment utilisée dans les scénarios de streaming de données en temps réel.

• CLB de couche 7 prend en charge le protocole SSE.

• CLB de couche 4 ne prend pas en charge le protocole SSE.

Restrictions d'utilisation : Les écouteurs CLB de couche 7 prennent en charge SSE, mais n'autorisent pas l'utilisation de SSE sur des connexions HTTP persistantes (keep-alive). Vous devez utiliser des connexions éphémères.

Le champ Transfer-Encoding: chunked

Transfer-Encoding: chunked est un champ standard du protocole HTTP indiquant que le corps du message est envoyé par transfert en blocs (chunked). Layer-7 CLB est un proxy inverse basé sur Tengine. Lorsqu'il transfère des requêtes à un serveur backend, il utilise le transfert en blocs. Par conséquent, le serveur backend reçoit ce champ dans l'en-tête de la requête. Il s'agit d'un comportement normal pour un proxy inverse et cela n'affecte pas vos services. Un CLB de couche 4 transfère uniquement le trafic et n'ajoute pas ce champ.

Champs d'en-tête de réponse supprimés

Pour mettre en œuvre la persistance de session, CLB supprime des champs tels que Date, Server, X-Pad et X-Accel-Redirect de l'en-tête de réponse. Pour conserver ces champs, vous pouvez ajouter un préfixe à vos en-têtes de réponse personnalisés, comme xl-server, ou basculer vers un écouteur TCP de couche 4.

proxy_buffering et proxy_cache

Les fonctionnalités proxy_buffering et proxy_cache ne sont pas activées pour CLB. CLB ne met ni en tampon ni en cache les données de requête ou de réponse. Au lieu de cela, il transfère directement les requêtes client aux serveurs backend en mode de transfert transparent. Il s'agit du comportement par défaut de CLB et ne nécessite aucune configuration supplémentaire.

CLB prend-il en charge le proxy forward ?

CLB ne prend pas en charge le proxy forward. CLB est un équilibreur de charge à proxy inverse : il distribue les requêtes client aux serveurs backend, mais il ne peut pas proxifier l'accès d'un client à des ressources externes comme le fait un proxy forward. Si vous avez besoin de fonctionnalités de proxy forward, construisez votre propre proxy forward en utilisant un service tel que Nginx.

Activer la protection WAF pour CLB

Impact de la désactivation de l'ENI public

Si une instance ECS possède une adresse IP publique, la désactivation de son interface réseau élastique (ENI) publique affecte le service d'équilibrage de charge.

En effet, si une interface réseau élastique publique existe, la route par défaut dirige le trafic via le réseau public. La désactivation de l'interface empêche l'envoi des paquets de réponse, ce qui perturbe le service d'équilibrage de charge. Nous vous recommandons de ne pas désactiver l'interface réseau élastique publique. Si vous devez la désactiver, modifiez la route par défaut vers le réseau privé pour éviter toute interruption de service. Toutefois, tenez compte du fait que vos services peuvent dépendre de l'accès au réseau public, par exemple pour accéder à RDS.

Prise en charge des requêtes client avec un champ TOA

Non. Un champ TCP Option Address (TOA) fourni par le client entre en conflit avec le champ TOA utilisé par l'équilibreur de charge pour la communication interne. Ce conflit empêche le serveur backend d'obtenir l'adresse IP réelle du client.