Créer et gérer des groupes de serveurs - Server Load Balancer

Un groupe de serveurs Application Load Balancer (ALB) achemine les requêtes client vers un ou plusieurs serveurs backend. Pour utiliser une instance ALB, vous devez créer un groupe de serveurs et y ajouter des serveurs backend afin de recevoir les requêtes transférées.

Ajout et suppression de serveurs backend

Avant d'ajouter un serveur backend, assurez-vous que votre application est déployée sur ce serveur.

Important

Vérifiez que vos serveurs backend ne bloquent pas les adresses suivantes via des règles de groupe de sécurité, iptables ou tout autre logiciel de sécurité :
- Les instances ALB mises à niveau utilisent des adresses IP privées (Local IPs) issues du bloc CIDR de leur vSwitch pour la communication. Vous pouvez consulter ces adresses IP sur la page des détails de l'instance.
- Les instances ALB non mises à niveau utilisent le bloc CIDR 100.64.0.0/10 pour communiquer avec les serveurs backend.
Assurez-vous que la configuration du serveur backend ne crée pas de chemin de transfert entraînant une boucle.

Ajouter des serveurs backend

Type de serveur

Accédez à la page Groupes de serveurs dans la console ALB. Identifiez le groupe de serveurs cible et cliquez sur Modify Backend Server dans la colonne Actions.
Sous l'onglet Backend Servers, cliquez sur Add Backend Server. Dans le panneau Add Backend Server, ajoutez les serveurs, puis cliquez sur Next.
- Ajouter des instances ECS
  
  Définissez le paramètre Server Type sur ECS/ENI et sélectionnez les instances ECS cibles.
  
  Si aucune instance ECS n'est disponible, cliquez sur Purchase ECS Instance dans le coin supérieur droit de la liste des serveurs.
- Ajouter des ENI
  1. Définissez le paramètre Server Type sur ECS/ENI et activez l'option Advanced Mode.
  2. Cliquez sur l'icône située à gauche de l'ID de l'instance ECS cible, puis sélectionnez l'ENI cible.
  Pour ajouter une ENI, assurez-vous qu'elle est associée à une instance ECS. Pour plus d'informations, consultez la rubrique Associer une ENI secondaire .
- Ajouter des instances ECI
  
  Définissez le paramètre Server Type sur ECI et sélectionnez les instances ECI cibles.
  
  Si aucune instance ECI n'est disponible, cliquez sur Purchase Elastic Container Instance dans le coin supérieur droit de la liste des serveurs.
Sur la page Ports/Weights, configurez les ports et les poids des serveurs ajoutés, puis cliquez sur OK.
- Port : port de service sur le serveur backend.
- Weight : proportion du trafic distribuée au serveur. Valeurs valides : 0 à 100. Valeur par défaut : 100.
  
  Par exemple, si un groupe de serveurs contient trois serveurs dont les poids sont respectivement de 100, 50 et 50, les requêtes sont distribuées selon un ratio de 2:1:1. Le serveur ayant un poids de 100 reçoit 50 % des requêtes, tandis que les deux autres serveurs en reçoivent chacun 25 %.
  Remarque
  
  Si la persistance de session est activée, la distribution des requêtes entre les serveurs backend peut être inégale.
  
  Si le poids d'un serveur est défini sur 0, ce serveur ne reçoit plus de nouvelles requêtes.
  
  Les serveurs qui échouent aux checks de santé ne reçoivent pas de trafic. Les requêtes sont distribuées entre les serveurs sains restants en fonction de leur ratio de poids.
  
  Si tous les serveurs d'un groupe de serveurs sont indisponibles, ALB tente toujours de distribuer le trafic en fonction des poids des serveurs afin de minimiser les interruptions de service.
Opérations par lot
- Sélectionnez plusieurs serveurs et utilisez les options Set Same Port, Set Same Weight ou Remove Backend Servers situées en bas de la liste.
- Survolez le côté droit d'une zone de saisie de port ou de poids, puis sélectionnez Replicate to Below, Replicate to Above ou Replicate to All pour appliquer rapidement la valeur actuelle aux autres serveurs.
- Cliquez sur Reset à droite de l'en-tête de colonne Port ou Weight pour effacer tous les ports des serveurs ou restaurer tous les poids à leurs valeurs par défaut.

Type Function Compute

Les versions 2.0 et 3.0 de Function Compute sont prises en charge. ALB communique avec Function Compute de manière sécurisée via le réseau interne d'Alibaba Cloud.

Vous devez activer le service Function Compute avant utilisation. Les comptes Alibaba Cloud enregistrés après le 27 août 2024 et ayant terminé la vérification d'identité peuvent utiliser le service directement sans activation préalable.

Limites

Consultez la liste des régions prenant en charge l'ajout de fonctions Function Compute en tant que serveurs backend.
L'instance ALB et la fonction doivent se trouver dans la même région.
Un groupe de serveurs de type Function Compute ne peut contenir qu'une seule fonction.
Pour Function Compute 2.0, si le paramètre Type de gestionnaire est défini sur Gestionnaire d'événements, configurez un déclencheur HTTP pour associer la fonction à une instance ALB.

Accédez à la page Groupes de serveurs dans la console ALB. Identifiez le groupe de serveurs cible et cliquez sur Modify Backend Server dans la colonne Actions.
Sous l'onglet Backend Servers, cliquez sur Add Function. Dans le panneau Add Backend Server, configurez la fonction à l'aide de l'une des méthodes suivantes, puis cliquez sur OK.
- Service
  - Function Name : sélectionnez une fonction existante. Si aucune fonction n'est disponible, cliquez sur Create Function. Pour plus d'informations, consultez la rubrique Créer une fonction.
  - Version or Alias : sélectionnez l'option Specified Version ou Specified Alias. Par défaut, une fonction nouvellement créée ne dispose que de la version LATEST.
- Configuration par ARN
  - ARN : saisissez le nom de ressource Alibaba Cloud (ARN) de la fonction cible. Vous pouvez obtenir l'ARN de la fonction depuis la page des détails de la fonction dans la console Function Compute.

Type IP

Si l'option Remote IP est désactivée, vous ne pouvez ajouter que des adresses IP issues du bloc CIDR du VPC actuel. Si l'option Remote IP est activée, vous pouvez également ajouter des adresses IP provenant d'autres VPC ou d'un centre de données local.

Remarque

À partir du 25 février 2025 à 00:00:00 (UTC+8), les instances nouvellement créées utiliseront par défaut la version mise à niveau d'ALB. Les instances ALB existantes ne sont pas affectées, à l'exception des instances créées via des applications en libre-service. Pour plus d'informations, consultez l'avis concernant la mise à niveau des instances Application Load Balancer (ALB).

Limites

Avertissement

Les instances ALB non mises à niveau ne permettent pas d'ajouter des instances ALB, Network Load Balancer (NLB) ou Classic Load Balancer (CLB) du même VPC à un groupe de serveurs de type IP. Si vous devez ajouter ces ressources depuis le même VPC, assurez-vous d'utiliser une instance ALB mise à niveau afin d'éviter d'éventuels problèmes de service.

Mise à niveau effectuée

Limites relatives aux serveurs backend

Seules les adresses IP privées sont prises en charge. Les adresses IP publiques ne sont pas prises en charge.
Si vous définissez le paramètre IP Version sur Server Type, vous ne pouvez ajouter que des adresses IPv6 issues du bloc CIDR du VPC du groupe de serveurs. Vous ne pouvez pas activer l'option Remote IP.

Limites de configuration de transfert entre ALB et les serveurs backend

Si vous utilisez un routeur de transit Enterprise Edition, celui-ci crée une interface réseau élastique (ENI) sur un vSwitch dans la zone de disponibilité que vous avez spécifiée. Cette ENI sert de point d'entrée du trafic depuis le VPC vers le routeur de transit. Lors de la création de votre VPC, veillez à créer au moins un vSwitch dans la zone de disponibilité spécifiée pour connecter le VPC au routeur de transit. Pour plus d'informations, consultez la rubrique Fonctionnement des routeurs de transit.
Le trafic entre une instance ALB et ses serveurs backend ne peut être acheminé que via la table de routage système. Les tables de routage personnalisées du VPC ne sont pas prises en charge.

Non mis à niveau

Limites relatives aux serveurs backend

Consultez la liste des régions prenant en charge l'ajout d'adresses IP distantes pour les instances ALB non mises à niveau.
Les serveurs backend interrégionaux sont pris en charge uniquement pour les groupes de serveurs de type IP.
Seules les adresses IP privées sont prises en charge. Les adresses IP publiques ne sont pas prises en charge.
Vous ne pouvez pas ajouter d'instances ALB, NLB ou CLB provenant du même VPC.

Limites de configuration de transfert entre ALB et les serveurs backend

Vous pouvez utiliser un routeur de transit Enterprise Edition ou Express Connect pour le transfert d'IP distantes. Les routeurs de transit Basic Edition ne sont pas pris en charge.

Si vous utilisez un routeur de transit Enterprise Edition, celui-ci crée une interface réseau élastique (ENI) sur un vSwitch dans la zone de disponibilité que vous avez spécifiée. Cette ENI sert de point d'entrée du trafic depuis le VPC vers le routeur de transit. Lors de la création de votre VPC, veillez à créer au moins un vSwitch dans une zone de disponibilité prise en charge pour connecter le VPC au routeur de transit. Pour plus d'informations, consultez la rubrique Régions et zones prenant en charge les routeurs de transit Enterprise Edition.
Au sein d'une instance Cloud Enterprise Network (CEN), un seul VPC par région peut contenir une ou plusieurs instances ALB utilisant des serveurs backend interrégionaux.
- Les instances ALB présentes dans plusieurs VPC au sein d'une même région ne peuvent pas utiliser le même routeur de transit pour accéder à un service backend.
- Les instances ALB présentes dans plusieurs VPC au sein d'une même région ne peuvent pas utiliser plusieurs routeurs de transit pour accéder au même service backend.
Le trafic entre une instance ALB et ses serveurs backend ne peut être acheminé que via la table de routage système. Les tables de routage personnalisées du VPC ne sont pas prises en charge.

Accédez à la page Groupes de serveurs dans la console ALB. Identifiez le groupe de serveurs cible et cliquez sur ECS/ENI dans la colonne Actions.
Sous l'onglet Server Type, cliquez sur Add IP Address. Dans le panneau Add Backend Server, saisissez les adresses IP des serveurs backend, puis cliquez sur Next.
- Si vous activez l'option Remote IP, vous pouvez saisir des adresses IP issues des blocs CIDR privés suivants : 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12 et 192.168.0.0/16.
- Si vous n'activez pas l'option Remote IP, vous ne pouvez saisir que des adresses IP issues du bloc CIDR du VPC actuel.
- Pour ajouter plusieurs serveurs backend, cliquez sur Add IP Address.
Sur la page Ports/Weights, configurez les ports et les poids, puis cliquez sur OK.
- Port : port sur lequel le serveur backend fournit des services.
- Weight : proportion du trafic distribuée au serveur. Valeurs valides : 0 à 100. Valeur par défaut : 100.
  
  Par exemple, si un groupe de serveurs contient trois serveurs dont les poids sont respectivement de 100, 50 et 50, les requêtes sont distribuées selon un ratio de 2:1:1. Le serveur ayant un poids de 100 reçoit 50 % des requêtes, tandis que les deux autres serveurs en reçoivent chacun 25 %.
  Remarque
  - Si la persistance de session est activée, la distribution des requêtes entre les serveurs backend peut être inégale.
  - Si le poids d'un serveur est défini sur 0, ce serveur ne reçoit plus de nouvelles requêtes.
  - Les serveurs qui échouent aux checks de santé ne reçoivent pas de trafic. Les requêtes sont distribuées entre les serveurs sains restants en fonction de leur ratio de poids.
  - Si tous les serveurs d'un groupe de serveurs sont indisponibles, ALB tente toujours de distribuer le trafic en fonction des poids des serveurs afin de minimiser les interruptions de service.
Opérations par lot
- Sélectionnez plusieurs serveurs et utilisez les options Set Same Port, Set Same Weight ou Remove Backend Servers situées en bas de la liste.
- Survolez le côté droit d'une zone de saisie de port ou de poids, puis sélectionnez Replicate to Below, Replicate to Above ou Modify Backend Server pour appliquer rapidement la valeur actuelle aux autres serveurs.
- Cliquez sur Actions à droite de l'en-tête de colonne Port ou Weight pour effacer tous les ports des serveurs ou restaurer tous les poids à leurs valeurs par défaut.

Supprimer des serveurs backend

Un serveur supprimé ne traite plus les requêtes transférées.

Avertissement

La suppression directe d'un serveur peut entraîner des interruptions de service. Nous vous recommandons de définir le poids du serveur sur 0 avant de le supprimer.

Accédez à la page Groupes de serveurs dans la console ALB. Identifiez le groupe de serveurs cible et cliquez sur Modify Backend Server dans la colonne Actions.
Sous l'onglet Backend Servers, identifiez le serveur backend à supprimer. Dans la colonne Actions, cliquez sur Remove, puis sur OK.

API

Appelez l'opération AddServersToServerGroup pour ajouter des serveurs backend à un groupe de serveurs.
Appelez l'opération RemoveServersFromServerGroup pour supprimer des serveurs backend d'un groupe de serveurs.

Planification de la configuration

Avant de créer un groupe de serveurs, déterminez les configurations clés en fonction de vos besoins métier. Le type de groupe de serveurs ne peut pas être modifié après sa création. Sélectionnez un type en fonction de la manière dont vos services backend sont déployés.

Sélectionner un type de groupe de serveurs

Type de groupe de serveurs	Types de services backend	Description	Documentation connexe
Serveur	Instances Elastic Compute Service (ECS), interfaces réseau élastiques (ENI) et instances Elastic Container Instance (ECI)	Les serveurs backend doivent se trouver dans le même Virtual Private Cloud (VPC) que le groupe de serveurs.	Mettre en œuvre rapidement l'équilibrage de charge IPv4 avec une instance ALB Mettre en œuvre rapidement l'équilibrage de charge IPv6 avec une instance ALB
IP	Adresses IP	Option Remote IP activée : utilisez cette option lorsque les serveurs backend ne se trouvent pas dans le VPC du groupe de serveurs, par exemple pour des adresses IP situées dans d'autres VPC ou dans des centres de données locaux. Les blocs CIDR suivants sont pris en charge : 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12 et 192.168.0.0/16. Option Remote IP désactivée : seules les adresses IP situées dans le VPC du groupe de serveurs sont prises en charge.	Utiliser une instance ALB pour ajouter des serveurs dans un VPC interrégional Utiliser une instance ALB pour ajouter des serveurs dans un centre de données local de la même région
Function Compute	Function Compute	Vous devez activer le service Function Compute. La fonction doit se trouver dans la même région que l'instance ALB.	Ajouter Function Compute en tant que service backend pour une instance ALB

Important

Si un serveur backend d'une instance ALB est libéré ou si son adresse IP privée est modifiée, ALB ne met pas automatiquement à jour le serveur backend. Nous vous recommandons de supprimer d'abord le serveur backend du groupe de serveurs ALB avant de le libérer ou de modifier son adresse IP privée afin d'éviter toute interruption de service.

Protocole backend et algorithme de planification

Protocole backend

Cas d'utilisation

HTTP (par défaut)

La plupart des scénarios d'applications web. Convient aux écouteurs HTTP, HTTPS et QUIC.

HTTPS

Scénarios nécessitant une communication chiffrée entre une instance ALB et ses serveurs backend. Convient aux écouteurs HTTPS et HTTP.

gRPC

Services backend utilisant le protocole gRPC. Nécessite un écouteur HTTP ou HTTPS avec HTTP/2 activé. L'activation de HTTP/2 pour les écouteurs HTTP est une fonctionnalité sur liste blanche. Pour utiliser cette fonctionnalité, contactez votre gestionnaire de compte.

Algorithme de planification

Cas d'utilisation

Tourniquet pondéré

Scénarios polyvalents. Distribue les requêtes uniformément en fonction des ratios de poids. La planification en tourniquet s'effectue par requête et non par utilisateur.

Moins de connexions pondéré

Scénarios présentant des connexions persistantes ou des variations significatives du temps de traitement des requêtes. Prend en compte à la fois le poids et le nombre de connexions actives, et privilégie les serveurs ayant une charge plus faible.

Hachage cohérent

Scénarios nécessitant une affinité de requête, tels que l'optimisation des taux de succès du cache. Achemine les requêtes présentant les mêmes caractéristiques vers le même serveur backend en fonction d'un hachage de l'adresse IP source ou d'un paramètre d'URL.

Pour plus de détails sur la logique des algorithmes, consultez la rubrique Algorithmes de planification de l'équilibrage de charge .

Le tableau suivant décrit la compatibilité entre les protocoles d'écouteur, les protocoles backend et les protocoles de check de santé.

Protocole d'écouteur	Protocoles backend	Types de groupes de serveurs	Protocoles de check de santé
HTTP	HTTP, HTTPS et gRPC Pour utiliser gRPC comme protocole backend, vous devez activer HTTP/2 dans l'écouteur. L'activation de HTTP/2 pour les écouteurs HTTP est une fonctionnalité sur liste blanche. Pour utiliser cette fonctionnalité, contactez votre gestionnaire de compte.	Serveur, IP et Function Compute Vous n'avez pas besoin de configurer le protocole backend ni le protocole de check de santé pour les groupes de serveurs Function Compute.	HTTP, HTTPS, TCP et gRPC Les instances ALB Basic ne prennent pas en charge le protocole de check de santé HTTPS.
HTTPS	HTTP, HTTPS et gRPC gRPC nécessite un écouteur HTTPS avec HTTP/2 activé. Les écouteurs HTTPS des instances ALB Basic ne prennent en charge que les protocoles backend HTTP et gRPC.
QUIC	HTTP

Important

Le protocole backend doit correspondre au protocole effectivement fourni par le serveur backend. Par exemple, si une instance ECS backend fournit des services HTTP, sélectionnez HTTP comme protocole backend. Si le protocole backend est défini sur HTTPS alors que le serveur backend ne fournit que des services HTTP, la négociation TLS entre l'instance ALB et le serveur backend échoue, ce qui entraîne le renvoi d'une erreur 502 Bad Gateway pour les requêtes. Pour résoudre ce problème, modifiez le protocole backend en HTTP.

Création et suppression de groupes de serveurs

Créer un groupe de serveurs

Accédez à la page Groupes de serveurs dans la console ALB.
Dans la barre de navigation supérieure, sélectionnez une région, puis cliquez sur Create Server Group. Configurez les paramètres suivants et cliquez sur Create.
- Server Group Type : sélectionnez un type en fonction de la manière dont vos services backend sont déployés.
  - Server : utilise des instances ECS, des ENI ou des instances ECI en tant que serveurs backend. Les serveurs backend doivent se trouver dans le même VPC que le groupe de serveurs.
  - IP Address : utilise des adresses IP en tant que serveurs backend. Prend en charge les adresses IP au sein du VPC. Si vous activez l'option Remote IP, vous pouvez également ajouter des adresses IP provenant d'autres VPC ou de centres de données locaux.
  - Function Compute : utilise Function Compute en tant que service backend. Vous devez activer le service Function Compute et la fonction doit se trouver dans la même région que l'instance ALB.
- Server Group Name : saisissez un nom personnalisé pour le groupe de serveurs.
- VPC : VPC auquel appartient le groupe de serveurs. Seuls les serveurs backend de ce VPC peuvent être ajoutés à ce groupe de serveurs.
  
  Pour un groupe de serveurs de type IP, si vous activez l'option Remote IP, les serveurs backend ne sont pas limités à ce VPC, mais doivent être accessibles depuis le réseau du VPC.
  
  Vous n'avez pas besoin de configurer ce paramètre pour les groupes de serveurs Function Compute.
- Backend Server Protocol : sélectionnez le protocole de communication entre l'instance ALB et les serveurs backend.
  - HTTP (par défaut) : convient aux écouteurs HTTP, HTTPS et QUIC. L'instance ALB utilise HTTP pour communiquer avec les serveurs backend.
  - HTTPS : convient aux écouteurs HTTPS et HTTP. L'instance ALB utilise HTTPS pour une communication chiffrée avec les serveurs backend.
  - gRPC : convient aux écouteurs HTTP ou HTTPS. HTTP/2 doit être activé. L'instance ALB utilise le protocole gRPC pour communiquer avec les serveurs backend.
  L'activation de HTTP/2 pour les écouteurs HTTP est une fonctionnalité sur liste blanche. Pour l'utiliser, contactez votre gestionnaire de compte.
  
  Pour les instances ALB Basic, les écouteurs HTTPS ne prennent en charge que les protocoles backend HTTP et gRPC.
  
  Vous n'avez pas besoin de configurer ce paramètre pour les groupes de serveurs Function Compute.
- Scheduling Algorithm : sélectionnez une stratégie de distribution des requêtes.
  - Weighted Round-robin : distribue les requêtes en fonction des ratios de poids. Les serveurs backend ayant des poids plus élevés reçoivent davantage de requêtes.
  - Weighted Least Connections : distribue les requêtes en fonction à la fois des poids et du nombre de connexions actives. Parmi les serveurs ayant le même poids, le serveur disposant du moins de connexions actuelles reçoit la requête suivante.
  - Consistent Hash : achemine les requêtes présentant les mêmes caractéristiques vers le même serveur backend en fonction d'un facteur de hachage.
    Hash Factor :
    - Source IP : hachage basé sur l'adresse IP source du client.
    - URL Parameters : hachage basé sur la valeur d'un paramètre d'URL spécifié. Vous devez saisir l'Specified URL.
      
      Pour le champ Specified URL, saisissez le nom d'un paramètre de requête issu de l'URL de la requête, tel que userid ou sessionid. ALB hache la valeur de ce paramètre pour acheminer les requêtes contenant la même valeur de paramètre vers le même serveur backend.
      
      Par exemple, si vous définissez le paramètre Specified URL sur userid, les requêtes contenant ?userid=123 sont toujours acheminées vers le même serveur backend. Cette méthode est utile pour les scénarios nécessitant une persistance de session, tels que la liaison des sessions de panier d'achat ou l'optimisation des taux de succès du cache.
      
      Nous vous recommandons d'ajouter au moins deux serveurs backend au groupe de serveurs afin de maximiser l'efficacité de la distribution basée sur le hachage.
  Vous n'avez pas besoin de configurer ce paramètre pour les groupes de serveurs Function Compute.
- Tags and Resource Group : facultatif. Utilisé pour catégoriser et gérer les groupes de serveurs.
  - Tag Key et Tag Value : attribuez une paire clé-valeur au groupe de serveurs sous forme de tag.
  - Resource Group : groupe de ressources auquel appartient le groupe de serveurs. Le groupe de ressources par défaut est utilisé par défaut.
- Backend Persistent Connection : activée par défaut. Lorsqu'elle est activée, ALB maintient des connexions TCP persistantes avec les serveurs backend. Les nouvelles requêtes réutilisent les connexions existantes lorsque cela est possible, ce qui réduit la latence et diminue la charge sur les serveurs backend.
  
  Vous n'avez pas besoin de configurer ce paramètre pour les groupes de serveurs Function Compute.
- Health Check : activé par défaut. Détecte la disponibilité des serveurs backend.
  
  Les checks de santé sont désactivés par défaut pour les groupes de serveurs Function Compute. S'ils sont activés, les sondes de check de santé sont comptabilisées comme des requêtes Function Compute et engendrent des frais .
  - Health Check Settings : cliquez sur Modify à droite pour développer les paramètres. Pour obtenir la description des paramètres, consultez la rubrique Checks de santé pour ALB.
  - Select and Load Health Check : sélectionnez un modèle de check de santé existant et chargez sa configuration.
    
    Vous pouvez créer des modèles de check de santé qui ne sont associés ni à des groupes de serveurs ni à des écouteurs pour une utilisation future.
    
    Un groupe de serveurs ne prend en charge qu'un seul check de santé.

Supprimer un groupe de serveurs

Vous ne pouvez supprimer un groupe de serveurs que s'il n'est associé à aucune règle de transfert d'écouteur. La suppression d'un groupe de serveurs n'affecte pas ses serveurs backend.

Accédez à la page Groupes de serveurs dans la console ALB. Identifiez le groupe de serveurs à supprimer. Dans la colonne Actions, cliquez sur l'icône , sélectionnez Delete, puis cliquez sur OK.

API

Appelez l'opération CreateServerGroup pour créer un groupe de serveurs.
Appelez l'opération DeleteServerGroup pour supprimer un groupe de serveurs spécifié.

Persistance de session

Activez la persistance de session si plusieurs requêtes provenant du même client doivent être traitées par le même serveur backend, par exemple pour les scénarios de panier d'achat ou d'état de connexion.

Session Persistence : désactivée par défaut. Lorsqu'elle est activée, ALB achemine les requêtes provenant du même client vers le même serveur backend.

Vous n'avez pas besoin de configurer ce paramètre pour les groupes de serveurs Function Compute.

La persistance de session est prise en charge uniquement pour les groupes de serveurs de type Serveur et de type IP. La persistance de session n'est pas prise en charge lorsque l'équilibrage de charge interzones est désactivé.

Console

Lors de la création ou de la modification d'un groupe de serveurs, activez la persistance de session et sélectionnez une méthode de gestion des cookies :

Cookie Option :
- Insert Cookie : ALB génère un cookie nommé SERVERID et l'ajoute à la réponse. Les requêtes contenant ce cookie sont transférées vers le même serveur backend. Le paramètre Session Persistence Timeout Period varie de 1 à 86 400 secondes.
- Rewrite Cookie : ALB réécrit la valeur d'un cookie défini par l'utilisateur. Vous devez spécifier le nom du Cookie.

API

Lorsque vous appelez l'opération CreateServerGroup ou UpdateServerGroupAttribute, utilisez le paramètre StickySessionConfig pour configurer la persistance de session.

Pour plus d'informations, consultez la rubrique Configurer la persistance de session.

Démarrage et arrêt progressifs des serveurs

Démarrage progressif

Un serveur backend nouvellement ajouté peut ne pas être en mesure de gérer immédiatement une charge de trafic complète en raison de facteurs tels qu'un cache non préchauffé ou des pools de connexions non établis. En activant le démarrage progressif, une instance ALB augmente graduellement le nombre de requêtes envoyées au nouveau serveur sur une période spécifiée. Cela permet d'éviter que des pics de trafic ne submergent un serveur qui n'est pas entièrement prêt.

Cette fonctionnalité est prise en charge uniquement lorsque l'algorithme de planification est défini sur tourniquet pondéré.

Seules les instances ALB Standard et améliorées par WAF sont prises en charge. Les instances ALB Basic ne sont pas prises en charge.

Vous n'avez pas besoin de configurer ce paramètre pour les groupes de serveurs de type Function Compute.

Console

Lors de la création ou de la modification d'un groupe de serveurs, activez l'option Slow Start. Définissez la Slow Start Duration sur une valeur comprise entre 30 et 900 secondes. La valeur par défaut est de 30 secondes. La distribution normale du trafic reprend une fois la durée écoulée.

API

Lorsque vous appelez l'opération CreateServerGroup ou UpdateServerGroupAttribute, utilisez le paramètre SlowStartConfig pour configurer le démarrage progressif.

Remarque

Fonctionnement du démarrage progressif :

Les serveurs backend sains existants dans un groupe de serveurs n'entrent pas automatiquement en mode de démarrage progressif. Le premier serveur backend ajouté à un groupe de serveurs vide n'entre pas non plus en mode de démarrage progressif. Un nouveau serveur backend entre en mode de démarrage progressif uniquement lorsqu'il est ajouté à un groupe de serveurs comportant au moins un serveur backend sain qui n'est pas en mode de démarrage progressif.
Si un serveur backend en mode de démarrage progressif est supprimé, il quitte ce mode. Si le même serveur backend est ajouté à nouveau, il entre de nouveau en mode de démarrage progressif après avoir passé le check de santé.
Un serveur backend en mode de démarrage progressif quitte ce mode si son check de santé échoue. Il entre de nouveau en mode de démarrage progressif une fois que l'état de son check de santé revient à la normale.
Lorsque les checks de santé sont activés, le démarrage progressif prend effet après qu'un serveur backend a passé son check de santé. Lorsque les checks de santé sont désactivés, le démarrage progressif prend effet immédiatement.

Pour plus d'informations, consultez la rubrique Configurer le démarrage progressif.

Vidage de connexion

Lorsqu'un serveur backend est supprimé ou échoue à un check de santé, les connexions existantes sont, par défaut, terminées uniquement lorsque le client se déconnecte activement ou que la session expire. Le vidage de connexion permet à ces connexions de terminer leur traitement dans un délai d'attente spécifié avant d'être interrompues, garantissant ainsi un arrêt progressif.

Cette fonctionnalité est prise en charge uniquement par les instances ALB Standard et activées par WAF. Les instances ALB Basic ne prennent pas en charge cette fonctionnalité.

Vous n'avez pas besoin de configurer ce paramètre pour les groupes de serveurs Function Compute.

Console

Lors de la création ou de la modification d'un groupe de serveurs, activez l'option Connection Draining et définissez le Timeout Period. Le délai d'attente peut varier de 0 à 900 secondes. Une valeur de 0 signifie que les connexions sont immédiatement interrompues. La valeur par défaut est de 300 secondes.

API

Lors de l'appel à l'opération CreateServerGroup ou UpdateServerGroupAttribute, utilisez le paramètre ConnectionDrainConfig pour configurer le vidage de connexion.

Pour plus d'informations, consultez la rubrique Configurer le vidage de connexion.

Réduction de la latence interzones

Par défaut, une instance ALB distribue le trafic entre les serveurs backend situés dans différentes zones de disponibilité au sein d'une même région. Si votre activité est sensible à la latence et que vous disposez de ressources de serveurs backend suffisantes dans chaque zone de disponibilité, vous pouvez désactiver l'équilibrage de charge interzones. Cela garantit que le trafic est distribué uniquement parmi les serveurs backend situés dans la même zone de disponibilité, ce qui réduit la latence réseau interzones.

Vous ne pouvez désactiver cette fonctionnalité que pour les instances ALB Standard et activées par WAF. Les instances ALB Basic ne prennent pas en charge cette fonctionnalité.

Pour les groupes de serveurs basés sur des adresses IP avec l'option Remote IP activée, vous ne pouvez pas désactiver l'équilibrage de charge interzones.

La persistance de session n'est pas prise en charge lorsque l'équilibrage de charge interzones est désactivé.

Vous n'avez pas besoin de configurer ce paramètre pour les groupes de serveurs de type Function Compute.

Console

Lors de la création ou de la modification d'un groupe de serveurs, désactivez l'option Cross-zone Load Balancing.

API

Lors de l'appel à l'opération CreateServerGroup ou UpdateServerGroupAttribute, définissez le paramètre CrossZoneEnabled sur false pour désactiver l'équilibrage de charge interzones (la valeur par défaut est true).

Pour plus d'informations, consultez la rubrique Désactiver l'équilibrage de charge interzones.

Ajout de serveurs backend IPv6

Si vous devez ajouter des serveurs backend IPv6 à un groupe de serveurs, définissez le paramètre IP Version sur IPv4/IPv6 dual-stack.

Cette fonctionnalité est prise en charge uniquement pour les groupes de serveurs de type Server et IP Address.
Le VPC auquel appartient le groupe de serveurs doit avoir IPv6 activé.
Vous ne pouvez ajouter un groupe de serveurs avec une IP Version définie sur IPv4/IPv6 dual-stack qu'aux règles de transfert d'une instance ALB à double pile.
Pour un groupe de serveurs de type IP, l'instance ALB doit être une instance mise à niveau. Dans cette configuration, seules les adresses IPv6 du VPC actuel sont prises en charge et vous ne pouvez pas activer l'option Remote IP.

Console

Lors de la création d'un groupe de serveurs, définissez le paramètre IP Version sur IPv4/IPv6 dual-stack.

API

Lorsque vous appelez l'opération CreateServerGroup, définissez le paramètre Ipv6Enabled sur true. Cela équivaut à définir le paramètre IP Version sur IPv4/IPv6 dual-stack.

Modification des paramètres de check de santé

Modifiez la configuration du check de santé d'un groupe de serveurs.

Avertissement

Si vous désactivez les checks de santé, ALB ne peut pas détecter les pannes des serveurs backend et n'acheminera pas automatiquement le trafic vers les serveurs sains.
Un intervalle de check de santé plus long augmente le temps nécessaire à ALB pour détecter un serveur défaillant.

Console

Accédez à la page Groupes de serveurs dans la console ALB. Identifiez le groupe de serveurs cible et cliquez sur Modify Health Check dans la colonne Actions.
Dans la boîte de dialogue Modify Health Check, activez ou désactivez les checks de santé selon vos besoins. S'ils sont activés, cliquez sur Modify à droite de Health Check Settings pour modifier les paramètres.

API

Appelez l'opération UpdateServerGroupAttribute pour mettre à jour la configuration du check de santé d'un groupe de serveurs.

Facturation

Les groupes de serveurs sont gratuits. Toutefois, vous êtes facturé pour l'instance ALB et pour les serveurs backend ajoutés au groupe de serveurs, conformément à leurs règles de facturation respectives.

Quotas

Nom du quota	Description	Valeur par défaut	Valeur maximale	Ajustable
alb_quota_loadbalancer_servers_num_basic_edition	Nombre de serveurs backend pouvant être ajoutés à une instance ALB Basic	200	400	Oui
alb_quota_loadbalancer_servers_num_standard_edition	Nombre de serveurs backend pouvant être ajoutés à une instance ALB Standard	1 000	1 500
alb_quota_loadbalancer_servers_num_standardwithwaf_edition	Nombre de serveurs backend pouvant être ajoutés à une instance ALB activée par WAF	1 000	1 500
alb_quota_server_added_num	Nombre de groupes de serveurs auxquels un serveur backend (par adresse IP) peut être ajouté	200	300
alb_quota_servergroup_attached_num	Nombre de règles de transfert auxquelles un groupe de serveurs peut être associé	50	100
alb_quota_server_groups_weight	Poids maximal d'un seul groupe de serveurs dans une règle de transfert	100	10 000	Contactez votre gestionnaire commercial