Gestion de trafic avancée
Les fonctionnalités suivantes de gestion avancée du trafic sont disponibles dans l'équilibreur de charge d'application (IBM Cloud® Application Load Balancer for VPC).
Nombre max de connexions
Utilisez la configuration max connections pour limiter le nombre maximal de connexions simultanées pour un port virtuel de front-end donné. Si vous ne configurez pas de valeur, le système utilise la valeur par défaut de 2000 connexions simultanées. Le nombre maximal de connexions simultanées pour un port virtuel de front-end donné ou à l'échelle du système pour tous les ports virtuels de front-end est de 15000.
Rétention de session
Par défaut, un équilibreur de charge d'application réachemine les demandes reçues vers un serveur back-end en fonction de la méthode d'équilibrage de charge configurée. Vous pouvez activer le maintien de la session pour vous assurer qu'un client reste connecté au même serveur back-end pendant toute la durée de la session. Pour plus d'informations, consultez la section Mise à jour de la persistance de session pour les équilibreurs de charge d'application.
IP source
Avec cette option, un équilibreur de charge d'application crée l'affinité entre un client et un serveur back-end en fonction de l'adresse IP source de la connexion. Par exemple, si vous activez la permanence de session de type IP source pour le port 80 ( HTTP ), toutes les tentatives de connexion ultérieures à HTTP à partir du même client IP source sont persistantes sur le même serveur dorsal. Cette fonction est disponible pour tous les protocoles pris en charge (HTTP, HTTPS et TCP).
Signal de présence HTTP
HTTP keep alive permet à un client HTTP et à un serveur d'échanger plusieurs paires requête-réponse sur une seule connexion TCP. Cela réduit la latence pour les requêtes suivantes, minimise la charge réseau et améliore l'efficacité
globale.
Application Load Balancer for VPC prend en charge le site HTTP keep alive lorsqu'il est activé à la fois sur le serveur du consommateur et sur celui du back-end. Si le consommateur prend en charge HTTP keep alive, l'ALB
maintient la connexion ouverte pour plusieurs requêtes. L'ALB tente de réutiliser les connexions d' HTTP côté serveur vers les serveurs back-end afin de minimiser la surcharge liée aux connexions.
HTTP keep alive doit être activé à la fois côté client et côté serveur backend de la connexion.
Signal de présence TCP
TCP keep alive est un mécanisme de la couche transport ( TCP ) qui permet de maintenir des connexions inactives de longue durée en envoyant périodiquement de petits paquets (appelés sondes de maintien en vie) pour vérifier si l'autre
extrémité de la connexion est toujours joignable.
Application Load Balancer for VPC soutient TCP pour qu'il reste en vie. Avec ce paramètre, l'équilibreur de charge envoie toutes les 5 secondes des paquets TCP keep alive aux serveurs consommateurs et aux serveurs dorsaux. Après
qu'une connexion est restée inactive pendant un certain temps (appelé délai de maintien en vie, souvent fixé par défaut à 2 heures), la pile TCP envoie une sonde de maintien en vie. Si le pair répond, la connexion reste active. Si aucune réponse
n'est reçue après plusieurs tentatives, la connexion est considérée comme morte et fermée.
TCP keep alive est un paquet au niveau de la socket, sans données, qui est envoyé à l'homologue pour l'informer que l'hôte est en vie. En tant que tel, il n'est donc visible qu'au niveau de la couche réseau et non de l'application. Ce paramètre permet également d'éviter la déconnexion des connexions TCP par un proxy ou un pare-feu intermédiaire qui aurait utilisé des règles désactivant les connexions après une certaine période d'inactivité.
Délais d'attente de connexion
Les valeurs de délai suivantes sont utilisées par un équilibreur de charge d'application. Actuellement, seules les valeurs de délai d'inactivité côté client et côté serveur du tableau suivant sont personnalisables.
| Nom | Description | Délai d'attente |
|---|---|---|
| Tentative de connexion côté serveur | Fenêtre de temps maximum pouvant être utilisée par l'équilibreur de charge pour établir une connexion HTTP au serveur de back-end. Si la tentative de connexion échoue, l'équilibreur de charge tente le prochain serveur disponible, conformément à la méthode d'équilibrage de charge configurée. | 5 secondes |
| Connexion inactive côté client | Délai d'inactivité maximal après lequel l'équilibreur de charge met fin à la connexion côté client, si le client n'a pas réussi à fermer sa connexion correctement. | 50 secondes (valeur par défaut) à 2 heures |
| Connexion inactive côté serveur | Délai maximal d'inactivité (avec configuration du protocole back end sur TCP) à l'issue duquel l'équilibreur de charge met fin à la connexion côté serveur. Lorsque le protocole de back-end est configuré sur HTTP, si l'équilibreur de charge ne reçoit pas de réponse à sa demande HTTP dans le délai d'inactivité imparti, il envoie un message d'erreur au client final. | 50 secondes (valeur par défaut) à 2 heures |
Conservation de l'adresse IP du client final (HTTP/HTTPS uniquement)
Application Load Balancer for VPC fonctionne comme un proxy inverse, qui met fin au trafic entrant du client. L'équilibreur de charge établit une connexion distincte à l'instance de serveur de back-end à l'aide de sa propre adresse IP. Dans
le cas des connexions HTTP aux serveurs de back-end (par rapport aux connexions HTTP ou HTTPS de front-end), l'équilibreur de charge conserve l'adresse IP d'origine du client en l'incluant dans l'en-tête HTTP X-Forwarded-For.
Dans le cas des connexions TCP, les informations relatives à l'adresse IP du client d'origine ne sont pas conservées.
Conservation du protocole du client final (HTTP/HTTPS uniquement)
Un équilibreur de charge d'application conserve le protocole initial utilisé par le client pour les connexions HTTP et HTTPS de front-end en l'incluant dans l'en-tête HTTP X-Forwarded-Proto. Cela ne s'applique pas au protocole TCP,
car un équilibreur de charge d'application ne considère pas le trafic de couche 7 lorsque le protocole TCP est utilisé.
Activation de l'application de l'équilibreur de charge privé
L'application de l'équilibreur de charge privé empêche la création d'équilibreurs de charge publics. Ainsi, seuls les clients non Internet ou les clients de votre environnement réseau peuvent accéder à vos équilibreurs de charge. Lorsque cette application est activée, une restriction est imposée à votre compte afin d'éviter la création d'IP flottantes sur tous les équilibreurs de charge.
Pour implémenter l'application de l'équilibreur de charge privé, ouvrez un cas de support IBM et indiquez que vous avez besoin de modifier votre compte afin de restreindre la création d'IP flottantes. Une fois qu'IBM aura effectué la modification, vous ne pourrez plus créer d'équilibreur de charge public.
L'application de l'équilibreur de charge privée, lorsqu'elle est activée, est valable pour toutes les régions.
Prise en charge de HTTP/2 pour les clients se connectant à des écouteurs HTTPS
Application Load Balancer for VPC utilise la négociation de protocole de couche d'application (ALPN) pour négocier avec les clients qui se connectent aux auditeurs HTTPS et prend en charge les protocoles HTTP et HTTPS.
Le protocole HTTP/2 n'est pas encore pris en charge pour les pools dorsaux. En revanche, les protocoles HTTP et HTTPS sont pris en charge.
Compression (HTTP/HTTPS uniquement)
La compression HTTP/HTTPS vous permet de compresser les données transmises à vos utilisateurs à l'aide de gzip.
Pour compresser les données transmises avec un ALB, l'en-tête de requête doit contenir Accept-Encoding: gzip et son type MIME doit être text/html, text/plain ou text/xml.
Activation du protocole de proxy
Vous pouvez activer un protocole de proxy pour les écouteurs TCP, HTTP et HTTPS et les pools de back-end. Les cas d'utilisation sont les suivants :
Cas d'utilisation 1 : le client se connecte directement à l'équilibreur de charge
Si l'équilibreur de charge d'application reçoit le trafic d'un client directement, l'activation du protocole de proxy pour le pool de back-end de cet écouteur configure l'équilibreur de charge pour associer l'en-tête de protocole de proxy aux paquets TCP envoyés à ce pool de back-end.
Tous les membres de back-end de ce pool doivent prendre en charge le protocole de proxy pour le chemin de données fonctionne. Vous pouvez choisir la version de l'en-tête de protocole de proxy (version 1 ou version 2) lors de l'activation de ce paramètre. Ce paramètre est désactivé par défaut s'il n'est pas spécifié. Avec ce paramètre, les serveurs de back-end peuvent obtenir les informations d'adresse IP et de port du client que l'équilibreur de charge définit dans l'en-tête de protocole de proxy.
Cas d'utilisation 2 : le client se connecte à un proxy ou à une chaîne de proxy, laquelle se connecte ensuite à l'équilibreur de charge à l'aide du protocole de proxy.
Si Application Load Balancer for VPC reçoit le trafic d'un proxy (ou d'une chaîne de proxy) qui utilise le protocole de proxy, ce dernier doit être activé pour l'écouteur afin de pouvoir analyser les informations d'origine du client contenues dans les en-têtes de protocole de proxy. Ce paramètre est désactivé par défaut s'il n'est pas spécifié. L'équilibreur de charge pouvant détecter la version de l'en-tête de protocole de proxy et l'analyser correctement, il n'est pas nécessaire de spécifier la version du protocole de proxy utilisée pour envoyer le trafic vers l'équilibreur de charge d'application.
Lorsque le protocole de proxy est activé pour un écouteur de front-end, tout le trafic arrivant sur ce port de front-end est censé être un trafic de protocole de proxy. Si l'une des connexions ne contient pas les en-têtes de protocole de proxy appropriés, elle ne sera pas établie. Pour transmettre ces informations client au pool de serveurs de back-end, vous devez activer le protocole de proxy pour le pool. Comme pour le cas d'utilisation 1, vous devez sélectionner la version 1 ou la version 2 en fonction de la version du protocole de proxy que les serveurs de back-end sont configurés pour utiliser. Vous pouvez également choisir de ne pas transmettre ces informations client aux serveurs de back-end s'ils ne sont pas en mesure de les traiter ; ces informations sont alors supprimées sur l'équilibreur de charge.