Server Load Balancer:NLB server groups

Types de groupes de serveurs NLB

Créer un groupe de serveurs

Lorsque les Pods principaux risquent une saturation des connexions, envisagez les approches suivantes :

• Vérification d'état comme solution de secours — Configurez les vérifications d'état de sorte que, lorsque les connexions TCP persistantes d'un Pod principal sont saturées et qu'il ne peut plus répondre aux sondes de vérification d'état, NLB supprime automatiquement ce serveur principal après que le nombre d'échecs consécutifs a atteint le Unhealthy Threshold. Les nouvelles requêtes ne sont plus transférées vers ce serveur principal.

• Drainage des connexions — Activez l'option Connection draining lors de la création du groupe de serveurs. Après qu'un échec de vérification d'état a entraîné la suppression d'un serveur principal, les connexions TCP persistantes existantes peuvent continuer à transmettre des données jusqu'à l'expiration du délai d'attente du drainage des connexions. Cela garantit que les connexions en cours ne sont pas interrompues.

• Rejet actif des connexions côté Pod — Nous recommandons de mettre en œuvre une surveillance du nombre de connexions dans vos Pods et de rejeter activement les nouvelles connexions lorsque le seuil est atteint (par exemple, en renvoyant des réponses d'erreur ou en fermant le socket d'écoute) pour un contrôle plus précis du trafic.

1. Connectez-vous à la console NLB.

2. Dans la barre de navigation supérieure, sélectionnez la région dans laquelle l'instance NLB est déployée.

3. Dans le volet de navigation de gauche, choisissez NLB > Server Groups.

4. Sur la page Server Groups, cliquez sur Create Server Group.

5. Dans la boîte de dialogue Create Server Group, configurez les paramètres suivants et cliquez sur Create.

   Paramètre	Description
   Server Group Type	Sélectionnez un type de groupe de serveurs : Server Type : vous permet d'ajouter des instances ECS, ENI et ECI en tant que serveurs principaux. IP Type : vous permet d'ajouter des adresses IP en tant que serveurs principaux. Seules les adresses IP privées sont prises en charge. Les adresses IP publiques ne sont pas prises en charge. Vous devez sélectionner un VPC lors de la création d'un groupe de serveurs de type adresse IP. Seuls les VPC de votre compte actuel sont pris en charge. Les adresses IP provenant de VPC intercomptes ne peuvent pas être ajoutées.
   VPC	Sélectionnez un VPC dans la liste déroulante. La liste déroulante affiche uniquement les VPC de votre compte actuel. Les VPC d'autres comptes ne sont pas pris en charge.
   Backend Server Protocol	Sélectionnez un protocole principal : TCP : associe le groupe de serveurs aux écouteurs TCP et TCP/SSL. UDP : associe le groupe de serveurs aux écouteurs UDP.
   Scheduling Algorithm	Sélectionnez un algorithme d'ordonnancement : Round Robin : distribue les requêtes aux serveurs principaux de manière séquentielle. Weighted Round-robin (par défaut) : distribue les requêtes aux serveurs principaux en fonction de leurs pondérations. Les serveurs principaux ayant des pondérations plus élevées reçoivent plus de requêtes. Source IP Hashing : utilise le hachage cohérent basé sur les adresses IP source. Les requêtes provenant de la même adresse IP source sont acheminées vers le même serveur principal. Four-element Hashing : utilise le hachage cohérent basé sur les quadruplets (adresse IP source, adresse IP de destination, port source et port de destination). Les paquets provenant du même flux sont acheminés vers le même serveur principal. QUIC ID Hashing : utilise le hachage cohérent basé sur les identifiants de connexion QUIC. Les requêtes avec le même identifiant QUIC sont acheminées vers le même serveur principal. Vous pouvez sélectionner le hachage par identifiant QUIC uniquement lorsque le protocole principal est UDP. Le protocole QUIC évolue rapidement. Cet algorithme est implémenté sur la base de draft-ietf-quic-transport-10. La compatibilité avec toutes les versions de QUIC n'est pas garantie. Nous vous recommandons d'effectuer des tests suffisants avant d'utiliser cet algorithme dans un environnement de production. Weighted Least Connections : distribue les requêtes en fonction à la fois de la pondération et de la charge réelle (nombre de connexions) de chaque serveur principal. Si les serveurs principaux ont la même pondération, le serveur ayant le moins de connexions reçoit plus de requêtes.
   Resource Group	Sélectionnez un groupe de ressources pour le groupe de serveurs.
   Tag	Définissez une Tag Key et une Tag Value.
   IPv6	Sélectionnez une version IP : IPv4 (par défaut) : vous pouvez ajouter uniquement des serveurs principaux IPv4. IP Version : vous pouvez ajouter des serveurs principaux IPv4 et IPv6. Si IPv6 n'est pas activé pour le VPC que vous avez sélectionné, vous ne pouvez sélectionner que IPv4.
   IPv4/IPv6 dual-stack	Si vous définissez l'option IP Version Affinity sur IP Version, vous pouvez configurer l'option IPv4/IPv6 dual-stack : IP Version Affinity (par défaut) : les requêtes sont distribuées aux serveurs principaux sains en fonction de l'algorithme d'ordonnancement, quelle que soit la version IP de la source. No affinity : les requêtes sont acheminées en fonction de la version IP de leur source. Les requêtes IPv4 sont acheminées uniquement vers les serveurs principaux IPv4, et les requêtes IPv6 sont acheminées uniquement vers les serveurs principaux IPv6. Si vous sélectionnez le mode Affinity mode, assurez-vous que le groupe de serveurs contient des serveurs principaux IPv4 et IPv6 sains. Sinon, les requêtes de la version IP correspondante ne peuvent pas être correctement transférées.
   Session Persistence Timeout Period	Spécifie s'il faut activer le drainage des connexions. Cette fonctionnalité est désactivée par défaut. Si vous activez le drainage des connexions, vous devez également définir le paramètre Connection Draining. Le délai d'attente peut être défini de 0 à 900 secondes. Une valeur de 0 indique que les connexions sont drainées immédiatement. Lorsqu'un serveur principal est supprimé ou échoue à une vérification d'état : Si le drainage des connexions est désactivé (par défaut), les connexions existantes ne sont pas activement interrompues. Elles sont interrompues uniquement après la déconnexion du client ou l'expiration de la session. Si le drainage des connexions est activé, les connexions existantes sont maintenues jusqu'à la fin du délai d'attente. Ensuite, les connexions sont activement fermées pour assurer une transition de service fluide.
   Connection Draining Timeout	Spécifie s'il faut activer la préservation de l'adresse IP du client. Si vous activez cette fonctionnalité, les serveurs principaux peuvent récupérer les adresses IP source des clients. Si vous désactivez cette fonctionnalité, les serveurs principaux peuvent agir en tant que clients pour accéder à l'instance NLB. Pour récupérer les adresses IP source des clients, vous pouvez activer le protocole Proxy pour l'écouteur. Les groupes de serveurs basés sur les adresses IP ne transmettent pas automatiquement les adresses IP source des clients aux serveurs principaux. Vous devez utiliser le protocole Proxy sur l'écouteur pour récupérer les adresses IP source.
   Client IP Preservation	Spécifie s'il faut activer le transfert multi-port. Si vous activez cette fonctionnalité, vous n'avez pas besoin de spécifier un port lorsque vous ajoutez un serveur principal. NLB transfère le trafic vers le serveur principal en fonction du port de la requête entrante. Si vous activez la fonctionnalité multi-port forwarding pour un écouteur, vous devez également activer cette fonctionnalité pour le groupe de serveurs principaux.
   Multi-port Forwarding	Spécifie s'il faut activer les vérifications d'état.
   Health Check	Si vous activez les vérifications d'état, vous pouvez cliquer sur Health Check Settings pour modifier les paramètres de vérification d'état.
   Modify	Sélectionnez un protocole pour les vérifications d'état : TCP (par défaut) : envoie des paquets SYN pour vérifier si le port du serveur est accessible. HTTP : envoie des requêtes HEAD ou GET pour vérifier si l'application sur le serveur est saine. UDP : envoie des paquets ICMP Echo Request et des paquets de sonde UDP pour obtenir des informations d'état. Vous pouvez sélectionner UDP pour le paramètre Health Check Protocol uniquement si le protocole principal du groupe de serveurs est UDP.
   Health Check Protocol	Sélectionnez une méthode de vérification d'état : GET : si un paquet de réponse est supérieur à 8 Ko, le paquet est tronqué. Cela n'affecte pas le résultat de la vérification d'état. HEAD : les vérifications d'état des écouteurs HTTP utilisent HEAD par défaut. Assurez-vous que vos serveurs principaux prennent en charge les requêtes HEAD. Si votre application principale ne prend pas en charge ou a désactivé les requêtes HEAD, les vérifications d'état peuvent échouer. Dans ce cas, utilisez la méthode GET. Ce paramètre prend effet uniquement lorsque le protocole de vérification d'état est HTTP.
   Health Check Method	Sélectionnez une version HTTP : HTTP/1,0 (par défaut) ou HTTP/1.1. La version du protocole de vérification d'état doit correspondre à la version HTTP prise en charge par votre application principale. Sinon, les vérifications d'état peuvent échouer. Si votre serveur principal : prend en charge uniquement HTTP 1.0, vous devez sélectionner HTTP/1.0. prend en charge uniquement HTTP 1.1, vous devez sélectionner HTTP/1.1. prend en charge à la fois HTTP 1.0 et HTTP 1.1, vous pouvez sélectionner l'une ou l'autre version. Ce paramètre prend effet uniquement lorsque le protocole de vérification d'état est HTTP .
   Health Check Protocol Version	Sélectionnez le port de sonde que le service de vérification d'état utilise pour accéder au serveur principal. Health Check Port : par défaut, le service de vérification d'état utilise les ports des serveurs principaux. Backend Server Port : spécifiez un port pour les vérifications d'état. Si vous activez le transfert multi-port, vous devez spécifier un port de vérification d'état.
   Custom Port	Saisissez l'URL de la page de vérification d'état. Ce paramètre prend effet uniquement lorsque le protocole de vérification d'état est HTTP.
   Health Check Path	Saisissez le nom de domaine pour les vérifications d'état. Health Check Domain Name (par défaut) : l'adresse IP privée du serveur principal est utilisée comme nom de domaine pour les vérifications d'état. Backend Server Internal IP : saisissez un nom de domaine. Ce paramètre prend effet uniquement lorsque le protocole de vérification d'état est HTTP.
   Custom Domain Name	Sélectionnez les codes d'état qui indiquent une vérification d'état réussie. Vous pouvez sélectionner http_2xx (par défaut), http_3xx, http_4xx et http_5xx. Ce paramètre prend effet uniquement lorsque le protocole de vérification d'état est HTTP.
   Health Check Status Codes	Lorsque vous configurez une vérification d'état pour un écouteur UDP, vous pouvez activer l'option Custom Request/Response. Ensuite, saisissez le contenu de la requête dans le champ Custom Request/Response, tel que youraccountID, et la réponse attendue dans le champ Custom Request, tel que slb123. Vous devez également ajouter la logique de réponse de vérification d'état correspondante à l'application sur le serveur principal. Par exemple, si l'application reçoit une requête contenant youraccountID, elle doit renvoyer une réponse contenant slb123. Si l'instance NLB reçoit la réponse attendue du serveur principal, la vérification d'état est réussie. Sinon, la vérification d'état échoue. Cette méthode maximise la fiabilité des vérifications d'état UDP. Ce paramètre prend effet uniquement lorsque le protocole de vérification d'état est UDP.
   Custom Response	Période d'attente d'une réponse à une requête de vérification d'état. Si un serveur principal ne répond pas dans le délai spécifié, la vérification d'état échoue.
   Response Timeout Period	Intervalle auquel les vérifications d'état sont effectuées. Si vous définissez le paramètre Health Check Interval sur UDP, assurez-vous que la valeur de Health Check Protocol est supérieure ou égale à la valeur de Health Check Interval. Cela évite qu'une sonde UDP ne soit considérée à tort comme sans réponse en raison d'un délai d'attente. Si vos serveurs principaux risquent une saturation des connexions, nous vous recommandons de raccourcir l'Response Timeout Period (par exemple, 2 à 3 secondes) et de réduire le Health Check Interval (par exemple, 2 échecs consécutifs) pour détecter plus rapidement la saturation des connexions des serveurs principaux et réduire le temps de détection des pannes.
   Unhealthy Threshold	Nombre de vérifications d'état réussies consécutives requises pour faire passer l'état d'un serveur principal de malsain à sain.
   Healthy Threshold	Nombre de vérifications d'état échouées consécutives requises pour faire passer l'état d'un serveur principal de sain à malsain.

Ajouter des serveurs backend (type Serveur)

Lorsque vous créez un groupe de serveurs de type Serveur, vous devez ajouter des serveurs backend pour traiter les requêtes entrantes. Vous ne pouvez pas ajouter plusieurs fois la même instance ECS, ENI ou ECI à un groupe de serveurs pour lequel le transfert multi-port est activé.

1. Sur la page Unhealthy Threshold, localisez le groupe de serveurs à gérer et utilisez l'une des méthodes suivantes pour accéder à la page des serveurs backend.

   • Dans la colonne Server Groups, cliquez sur Actions.

   • Cliquez sur l'ID du groupe de serveurs. Sur la page des détails du groupe de serveurs, cliquez sur l'onglet Modify Backend Server.

2. Sous l'onglet Backend Servers, cliquez sur Backend Servers.

3. Dans le panneau Add Backend Server, sélectionnez un Add Backend Server puis cliquez sur Server Type.

   • Si Next correspond à ECS/ENI, sélectionnez les serveurs cibles ou cliquez sur Purchase ECS Instance dans le coin supérieur droit.

     Pour sélectionner une ENI, assurez-vous qu'une ENI secondaire est attachée à l'instance ECS cible et que le commutateur Purchase ECS Instance est activé. Cliquez ensuite sur l'icône située à droite de l'ID de l'instance ECS cible, puis sélectionnez l'ENI.

     Si la Advanced Mode du groupe de serveurs est définie sur IP Version, cliquez sur l'icône de paramètres à côté de l'en-tête de colonne IPv4/IPv6 dual-stack. Dans la boîte de dialogue IP, sélectionnez une politique d'adresse IP :

     • IP Address : une adresse IPv4 principale disponible est sélectionnée par défaut.

     • Prefer IPv4 over IPv6 : une adresse IPv6 disponible est sélectionnée par défaut. Si une ENI possède plusieurs adresses IPv6, la première adresse disponible est sélectionnée selon son ordre dans la liste.

     • Prefer IPv6 over IPv4 : une adresse IPv4 principale disponible et la première adresse IPv6 disponible sont sélectionnées.

     Cette option définit uniquement l'adresse IP sélectionnée par défaut pour l'ENI. Vous pouvez toujours modifier manuellement la sélection dans la colonne d'adresse IP.

   • Si Dualstack correspond à ECI, sélectionnez les serveurs cibles ou cliquez sur ECI dans le coin supérieur droit.

4. Configurez les ports et les pondérations des serveurs, puis cliquez sur Purchase Elastic Container Instance.

   Si le transfert multi-port est activé pour le groupe de serveurs, il n'est pas nécessaire de spécifier un port lors de l'ajout d'un serveur backend. NLB transfère le trafic vers les serveurs backend en fonction des ports des requêtes entrantes.

   La pondération par défaut est de 100. Un serveur avec une pondération plus élevée reçoit davantage de requêtes.

   Vous pouvez survoler l'icône pour modifier les pondérations et les ports de plusieurs serveurs en masse :

   • Cliquez sur OK : si vous modifiez la pondération ou le port du serveur actuel, les pondérations ou les ports de tous les serveurs situés en dessous prennent la même valeur.

   • Cliquez sur Replicate to Above : si vous modifiez la pondération ou le port du serveur actuel, les pondérations ou les ports de tous les serveurs situés au-dessus prennent la même valeur.

   • Cliquez sur Replicate to All : si vous modifiez la pondération ou le port du serveur actuel, les pondérations ou les ports de tous les serveurs du groupe de serveurs prennent la même valeur.

   • Cliquez sur Reset :

     • Cliquez sur Reset à côté de Weight pour restaurer les pondérations par défaut de tous les serveurs du groupe de serveurs.

     • Cliquez sur Reset à côté de Port pour effacer les numéros de port de tous les serveurs du groupe de serveurs.

   Avertissement

   Si vous définissez la pondération d'un serveur sur 0, celui-ci ne reçoit plus de nouvelles requêtes.

Ajouter des serveurs backend (type IP)

Lorsque vous créez un groupe de serveurs de type IP, vous devez ajouter des adresses IP en tant que serveurs backend pour traiter les requêtes entrantes. Vous ne pouvez pas ajouter plusieurs fois la même adresse IP à un groupe de serveurs pour lequel le transfert multi-port est activé.

• Vous ne pouvez pas ajouter les adresses IP virtuelles (VIP) des instances NLB dans le même VPC, ni les VIP des instances ALB créées dans le même VPC après .

• Seules les adresses IP privées sont prises en charge. Les adresses IP publiques ne sont pas prises en charge.

1. Sur la page Server Groups, localisez le groupe de serveurs cible et utilisez l'une des méthodes suivantes pour ajouter une adresse IP.

   • Dans la colonne Actions, cliquez sur Modify Backend Server.

   • Cliquez sur l'ID du groupe de serveurs.

2. Sur la page des détails du groupe de serveurs, cliquez sur l'onglet Backend Servers, puis cliquez sur Add IP Address.

3. Sous l'onglet Select Servers du panneau Add Backend Server, saisissez une adresse IP et cliquez sur Next.

   Vous pouvez configurer plusieurs ports et pondérations pour l'adresse IP.

4. Sous l'onglet Ports/Weights, définissez le port et la pondération pour l'adresse IP ajoutée, puis cliquez sur OK.

   Si le transfert multi-port est activé pour le groupe de serveurs, il n'est pas nécessaire de spécifier un port lors de l'ajout d'un serveur backend. NLB transfère le trafic vers les serveurs backend en fonction des ports des requêtes entrantes.

   La pondération par défaut est de 100. Un serveur avec une pondération plus élevée reçoit davantage de requêtes.

   Vous pouvez survoler l'icône pour modifier les pondérations et les ports de plusieurs serveurs en masse :

   • Cliquez sur Replicate to Below : si vous modifiez la pondération ou le port du serveur actuel, les pondérations ou les ports de tous les serveurs situés en dessous prennent la même valeur.

   • Cliquez sur Replicate to Below : si vous modifiez la pondération ou le port du serveur actuel, les pondérations ou les ports de tous les serveurs situés au-dessus prennent la même valeur.

   • Cliquez sur Replicate to Above : si vous modifiez la pondération ou le port du serveur actuel, les pondérations ou les ports de tous les serveurs du groupe de serveurs prennent la même valeur.

   • Cliquez sur Replicate to All :

     • Cliquez sur Reset à côté de Reset pour restaurer les pondérations par défaut de tous les serveurs du groupe de serveurs.

     • Cliquez sur Weight à côté de Reset pour effacer les numéros de port de tous les serveurs du groupe de serveurs.

   Avertissement

   Si vous définissez la pondération d'un serveur sur 0, celui-ci ne reçoit plus de nouvelles requêtes.

Autres opérations

Référence API

• CreateServerGroup : Crée un groupe de serveurs pour une instance NLB.

• DeleteServerGroup : Supprime un groupe de serveurs d'une instance NLB.

• AddServersToServerGroup : Ajoute des serveurs backend à un groupe de serveurs d'une instance NLB.

• RemoveServersFromServerGroup : Supprime des serveurs backend d'un groupe de serveurs d'une instance NLB.

• UpdateServerGroupAttribute : Met à jour la configuration d'un groupe de serveurs pour une instance NLB.