Server Load Balancer:Groupes de serveurs CLB

Types de groupes de serveurs

Configuration du poids

L'algorithme de planification détermine comment le CLB distribue les requêtes entrantes sur plusieurs serveurs backend. Le poids est un paramètre utilisé dans les algorithmes pondérés pour contrôler la proportion de trafic attribuée à chaque serveur.

• Portée : s'applique uniquement lors de l'utilisation d'un algorithme de planification pondéré. Il n'a aucun effet avec l'algorithme round-robin.

• Plage : 0–100, avec une valeur par défaut de 100.

• Comportement lorsque le poids est 0 : le serveur cesse de recevoir du trafic de nouvelles requêtes. Les connexions existantes se poursuivent jusqu'à leur fermeture normale et les vérifications d'état continuent de s'exécuter. Cette configuration est couramment utilisée pour un arrêt progressif.

• Effet des modifications de poids : les ajustements de poids s'appliquent uniquement aux nouvelles connexions et n'affectent pas les connexions existantes. Dans les scénarios de connexions persistantes, la redistribution du trafic après une modification de poids se produit lentement.

• Ratio de distribution du trafic : selon l'algorithme Weighted Round Robin (WRR), chaque serveur backend reçoit un trafic proportionnel à son poids. Par exemple, si deux serveurs ont des poids de 100 et 1 respectivement (poids total : 101), le serveur avec un poids de 1 reçoit environ 1/101 (moins de 1 %) de toutes les requêtes.

  Remarque

  Lorsque le groupe de serveurs contient déjà un serveur backend à poids élevé (par exemple, poids 100), un serveur nouvellement ajouté avec un poids faible (par exemple, poids 1) peut ne recevoir aucun trafic visible pendant une période prolongée. Ce comportement est attendu avec WRR : dans des conditions de faible trafic, les quelques requêtes allouées au serveur à faible poids peuvent passer inaperçues pendant longtemps.

• Recommandation : lors de l'ajout d'un nouveau serveur backend, définissez son poids initial à au moins 10. Après avoir confirmé que le serveur reçoit normalement du trafic, ajustez le poids en fonction de vos besoins métier.

Haute disponibilité du service

Activez les vérifications d'état du CLB pour envoyer périodiquement des requêtes et vérifier l'état des serveurs.

• Vérification d'état réussie : le serveur est sain et le CLB lui transfère du trafic.

• Échec de la vérification d'état : le serveur est défaillant et le CLB cesse de lui envoyer du trafic de nouvelles requêtes jusqu'à sa récupération.

Les vérifications d'état du CLB proviennent du bloc CIDR 100.64.0.0/10 . Assurez-vous que les règles iptables de vos serveurs backend ou tout autre logiciel de sécurité tiers ne bloquent pas ce bloc CIDR. Sinon, les vérifications d'état échoueront et entraîneront une interruption de service.

Les groupes de serveurs primaire/secondaire s'appuient sur les vérifications d'état pour le basculement automatique :

• Si le serveur primaire échoue à la vérification d'état, le trafic bascule vers le serveur secondaire. Par défaut, le serveur secondaire ne fait pas l'objet de vérifications d'état ; vous devez donc garantir manuellement sa disponibilité pour assurer un basculement transparent.

• Le temps de basculement dépend du délai d'attente de réponse configuré pour la vérification d'état. Lorsque le serveur primaire récupère, le trafic revient automatiquement vers celui-ci.

Puis-je ajuster le nombre d'instances ECS pendant que l'instance CLB est en cours d'exécution ?

• Groupe de serveurs par défaut et groupe vServer : vous pouvez ajouter ou supprimer des instances ECS backend à tout moment et basculer entre différentes instances ECS. Pour garantir la stabilité du service, activez les vérifications d'état avant d'effectuer ces opérations et assurez-vous qu'au moins une instance ECS saine reste en backend.

• Groupe de serveurs primaire/secondaire : non pris en charge.

Les instances ECS backend peuvent-elles utiliser des systèmes d'exploitation différents ?

Oui, ils peuvent différer.

Le CLB ne restreint pas les systèmes d'exploitation des instances ECS backend, tant que les services applicatifs et les données sont cohérents. Nous recommandons d'utiliser le même système d'exploitation pour faciliter la gestion et la maintenance.

Puis-je utiliser des instances ECS de différentes régions comme serveurs backend ?

Le CLB ne prend pas en charge l'attachement direct de serveurs backend interrégionaux. Pour mettre en œuvre un déploiement interrégional, utilisez l'une des solutions suivantes :

• Déployez Global Traffic Manager au-dessus du CLB et déployez plusieurs instances CLB dans différentes régions. Basculez entre les instances CLB pour réaliser un attachement interrégional.

• Utilisez Application Load Balancer (ALB) ou Network Load Balancer (NLB), qui prennent en charge l'attachement de serveurs backend interrégionaux.

Pourquoi y a-t-il des requêtes fréquentes provenant d'adresses IP commençant par 100 vers mon instance ECS ?

Ces requêtes proviennent des vérifications d'état et de la surveillance de la disponibilité de l'équilibreur de charge.

• Source : bloc CIDR réservé Alibaba Cloud 100.64.0.0/10.

• Sécurité : ce bloc CIDR est réservé par Alibaba Cloud et ne peut pas être attribué à d'autres utilisateurs, il ne présente donc aucun risque de sécurité.

• Recommandation : assurez-vous que les règles iptables de vos serveurs backend ou tout autre logiciel de sécurité tiers ne bloquent pas ce bloc CIDR afin de maintenir la disponibilité du service.

Si les vérifications d'état échouent, consultez la rubrique Comment résoudre les échecs de vérification d'état ?

Mon instance ECS n'a pas la compression activée, mais les réponses HTTP du CLB sont compressées. Pourquoi ?

• Raison : la compression Gzip est activée dans la configuration de l'écouteur CLB et le navigateur client prend en charge la compression.

• Action : pour la désactiver, désactivez la compression Gzip dans les paramètres de l'écouteur de la console CLB ou basculez vers un écouteur TCP.

Une instance ECS utilisant HTTP/1,0 prend-elle en charge le codage par fragments (chunked transfer encoding) ?

Oui.

Pourquoi mon instance ECS backend CLB reçoit-elle fréquemment des requêtes avec User-Agent KeepAliveClient ?

• Observation : l'ECS backend reçoit de nombreuses requêtes GET provenant d'adresses IP internes avec l'User-Agent KeepAliveClient.

• Raison : le protocole de l'écouteur est TCP, mais le protocole de vérification d'état est défini sur HTTP. Lorsqu'un écouteur TCP utilise des vérifications d'état HTTP, il utilise par défaut la méthode GET.

• Solution : alignez le protocole de l'écouteur et le protocole de vérification d'état (par exemple, utilisez tous les deux TCP ou tous les deux HTTP).

Puis-je modifier le port du serveur dans le groupe de serveurs par défaut ?

La modification directe n'est pas prise en charge.

• Restriction : le port du groupe de serveurs par défaut ne peut être défini que lors de la création de l'écouteur et tous les serveurs backend sous le même écouteur doivent utiliser le même port.

• Solution : pour configurer différents ports backend pour le même écouteur, utilisez un groupe vServer.

L'écouteur de couche 4 du CLB prend-il en charge l'utilisation de la même instance ECS en tant que serveur backend et client ?

Non. Cette configuration provoque une boucle.

Alternatives :

• Utilisez un écouteur de couche 7 CLB (HTTP/HTTPS).

• Utilisez une instance NLB et désactivez la conservation de l'adresse IP client pour le groupe de serveurs. Consultez la rubrique Comment une instance ECS peut-elle servir à la fois de serveur backend et de client dans NLB ?

Pourquoi mon backend CLB présente-t-il de nombreuses connexions TIME-WAIT, tandis qu'ALB en présente peu ?

Classic Load Balancer (CLB) et Application Load Balancer (ALB) utilisent des mécanismes de connexion différents lorsqu'ils interagissent avec les serveurs backend.

• Classic Load Balancer (CLB) : utilise par défaut des connexions HTTP éphémères. Le CLB insère l'en-tête Connection: close dans les requêtes HTTP. Après le traitement de la requête, le serveur backend envoie un paquet FIN pour fermer la connexion sur la base de cet en-tête. Chaque fermeture entre dans l'état TIME-WAIT (60 secondes par défaut), ce qui entraîne une accumulation rapide en cas de forte concurrence.

• Application Load Balancer (ALB) : prend en charge par défaut les connexions persistantes HTTP (keep-alive). Une seule connexion TCP gère plusieurs requêtes, réduisant ainsi les fermetures de connexion et donc les connexions TIME-WAIT.

Pour réduire l'accumulation de connexions TIME-WAIT, envisagez les options suivantes :

• Basculez vers un écouteur de couche 4 CLB (TCP). Les vérifications d'état de couche 4 envoient un paquet RST après une négociation réussie pour fermer la connexion sans entrer dans l'état TIME-WAIT.

• Migrez vers ALB pour tirer parti de son mécanisme de réutilisation des connexions persistantes HTTP par défaut.

Pourquoi le trafic est-il inégalement réparti entre les serveurs backend ?

Comment supprimer en toute sécurité une instance ECS backend du CLB ?

La suppression directe d'une instance ECS peut provoquer des déconnexions transitoires. Définissez d'abord le poids de l'instance ECS sur 0. Attendez que les connexions existantes soient terminées avant de supprimer l'instance. Pour plus de détails sur le comportement du poids lorsqu'il est défini sur 0, consultez la section Configuration du poids ci-dessus.

Si les requêtes métier se poursuivent après la suppression de l'instance ECS, vérifiez les points suivants :

• Vérifiez si l'instance ECS est également attachée à d'autres instances CLB.

• Vérifiez si l'instance ECS fournit directement d'autres services. Utilisez la commande netstat pour vérifier l'état d'écoute des ports.

Pourquoi aucun trafic n'est-il transféré vers un serveur backend nouvellement ajouté ?

Si le CLB ne transfère pas de trafic vers un serveur backend nouvellement ajouté, vérifiez les points suivants :

• Échec de la vérification d'état : le port du serveur backend est inaccessible ou l'application n'écoute pas sur le port attendu, ce qui entraîne l'échec de la vérification d'état. Dans la console CLB, confirmez l'état de vérification d'état du serveur et vérifiez l'écoute du port et l'état de l'application sur le serveur backend. Si les vérifications d'état échouent, consultez la rubrique Comment résoudre les échecs de vérification d'état ?

• Poids défini sur 0 : les serveurs avec un poids de 0 ne reçoivent pas de trafic de nouvelles requêtes. Vérifiez le poids du serveur dans le groupe de serveurs et assurez-vous qu'il est supérieur à 0. Pour plus de détails, consultez la section Configuration du poids ci-dessus.

• Ajout au mauvais groupe de serveurs : chaque écouteur CLB est lié à un groupe de serveurs spécifique (par défaut ou groupe vServer). Si le nouveau serveur est ajouté à un groupe non lié à l'écouteur cible, il ne recevra pas de trafic pour cet écouteur. Confirmez le groupe de serveurs effectivement lié à l'écouteur et ajoutez le serveur au groupe correct.

• iptables ou un logiciel de sécurité tiers bloque le bloc CIDR de vérification d'état : les vérifications d'état du CLB utilisent le bloc CIDR 100.64.0.0/10 . Si iptables ou un autre logiciel de sécurité tiers sur le serveur backend bloque ce bloc CIDR, les vérifications d'état échouent et le CLB considère le serveur comme défaillant. Assurez-vous que les règles pertinentes ne bloquent pas ce bloc CIDR.

• Fenêtre de vérification d'état non atteinte : après l'ajout d'un serveur backend, le CLB attend une vérification d'état réussie avant de transférer du trafic. Attendez brièvement, puis vérifiez si le trafic circule normalement.

• L'algorithme de planification par hachage cohérent (CH) empêche l'allocation de trafic : lorsqu'un écouteur utilise l'algorithme de planification par hachage cohérent (CH) basé sur l'adresse IP source, les requêtes sont attribuées à des serveurs spécifiques en fonction du résultat du hachage de l'adresse IP source. Après l'ajout d'un nouveau serveur, seules les requêtes dont le hachage de l'adresse IP source correspond au nouveau serveur lui sont transférées. Si le nombre de clients est faible ou que les adresses IP sources sont concentrées, le nouveau serveur peut ne recevoir aucun trafic pendant une période prolongée. Dans la console CLB, accédez à la page des détails de l'instance, cliquez sur l'onglet Listener et vérifiez l'algorithme de planification de l'écouteur correspondant. S'il est défini sur Consistent Hashing (CH) , envisagez de basculer vers Weighted Round Robin (WRR) ou Round Robin (RR) .

Quel protocole le CLB utilise-t-il pour transférer les requêtes aux serveurs backend pour les écouteurs de couche 7 ?

Que l'écouteur de couche 7 utilise HTTP ou HTTPS, le CLB transfère toujours les requêtes aux serveurs backend en utilisant le protocole HTTP. Le mappage des versions HTTP est le suivant :

• Si la requête client utilise HTTP/1,1 ou HTTP/2,0, l'écouteur de couche 7 accède aux serveurs backend en utilisant HTTP/1,1.

• Si la requête client utilise une version autre que HTTP/1,1 ou HTTP/2,0, l'écouteur de couche 7 accède aux serveurs backend en utilisant HTTP/1,0.