A propos des équilibreurs de charge de réseau
Vous pouvez utiliser l'équilibreur de charge de réseau (IBM Cloud® Network Load Balancer for VPC) afin de répartir le trafic entre plusieurs instances de serveur dans la même région que celle de votre VPC.
Les équilibreurs de charge de réseau peuvent accepter des membres dans les trois zones de disponibilité, mais l'équilibreur de charge de réseau lui-même réside dans une zone spécifique. Pour plus d'informations, voir Prise en charge multizone.
Il est possible d'affecter des ports par client, mais il n'y a pas d'application de port au niveau de la passerelle VP.
Types d'équilibreurs de charge réseau
Comme indiqué dans la rubrique Présentation des équilibreurs de charge pour VPC, de nombreux types d'équilibreur de charge de réseau sont disponibles:
-
Public- Un équilibreur de charge public est un équilibreur de charge doté d'une adresse IP accessible au public et enregistrée auprès du DNS.
-
Privé-Un équilibreur de charge privé est uniquement accessible à partir du réseau VPC, où le client se trouve dans le même VPC ou est accessible (par exemple, via Direct Link, Transit Gatewayou les deux). Pour les équilibreurs de charge privés, vous devez disposer d'un sous-réseau dédié sans route personnalisée configurée pour ce dernier.
-
Privé avec mode de routage activé- Les NLB privés avec mode de routage activé prennent en charge les dispositifs VNF (Virtual Network Function) en tant que cibles back-end. Ils effectuent un routage direct sans NAT, ce qui permet aux appareils VNF d'inspecter les paquets tels quels.
Le trafic symétrique et asymétrique est pris en charge : plusieurs NLB privés avec mode de routage dans chaque zone peuvent recevoir du trafic de manière asynchrone à tout moment grâce au transfert pondéré. Pour plus d'informations, consultez la section Création d'un équilibreur de charge réseau avec mode de routage.
-
Chemin privé-Les fournisseurs de services utilisent des NLB de chemin privé pour connecter en toute sécurité IBM Cloud à des services hébergés par un VPC tiers sur le réseau privé IBM Cloud. Les NLB Private Path sont nécessaires lorsque vous utilisez les services Private Path pour maintenir le trafic réseau sur un chemin privé qui ne croise jamais l'internet. Pour plus d'informations, voir le Guide des solutions de chemin privé.
Les NLB à chemin privé ne peuvent être utilisés qu'avec un service à chemin privé.
Mise en route
Pour commencer à utiliser les équilibreurs de charge de réseau, procédez comme suit:
- Examiner les problèmes connus pour les équilibreurs de charge réseau.
- Suivez les instructions relatives à votre équilibreur de charge de réseau particulier:
Pour plus d'informations, voir Types d'équilibreurs de charge et le graphique de comparaison des équilibreurs de charge.
Méthodes d'équilibrage de charge
Trois méthodes d'équilibrage de charge sont disponibles pour répartir le trafic entre les serveurs d'applications de back-end : permutation circulaire, permutation circulaire pondérée et nombre minimal de connexions.
Nombre minimal de connexions
Avec cette méthode, l'instance de serveur back-end qui gère le moins de connexions à un moment donné reçoit la prochaine connexion client.
Les NLB à chemin privé ne prennent pas en charge la méthode de la moindre connexion.
Circulaire
Il s'agit de la méthode d'équilibrage de charge par défaut. Avec cette méthode, l'équilibreur de charge achemine les connexions client entrantes selon une permutation circulaire vers les serveurs de back-end. En résultat, tous les serveurs de back-end reçoivent approximativement un nombre égal de connexions client.
Transfert pondéré
Le transfert pondéré n'est pris en charge que sur les NLB privés utilisant le mode de routage.
Avec le routage pondéré, le NLB utilise un algorithme de hachage d'adresse IP pour répartir les paquets entre les cibles en fonction des poids qui leur sont attribués. Le routage pondéré étant sans état, le NLB ne conserve pas l'état de la connexion. Au lieu de cela, chaque paquet est évalué indépendamment en fonction de ses en-têtes, puis acheminé selon le résultat de hachage actuel et les pondérations configurées. Par conséquent, le trafic est accepté et transmis même en l'absence de connexion existante.
Ce comportement permet de prendre en charge des scénarios de routage asymétrique, y compris les déploiements dans lesquels les flux de trafic au sein d’une même zone ne sont pas symétriques, par exemple lors de l’utilisation d’une plage d’adresses
IP publiques. Un autre scénario pris en charge est un déploiement multizone dans lequel des NLB privés configurés avec l’algorithme pool weighted_forwarding peuvent recevoir du trafic de manière asynchrone dans n’importe quelle
zone. Pour les flux de trafic symétriques, le NLB continue d’assurer un acheminement déterministe basé sur un hachage, à l’instar d’autres algorithmes de pool, ce qui rend l’acheminement pondéré adapté à tout déploiement NLB en mode route.
Si un NLB en mode route devient défaillant en raison d’une zone défaillante ou s’il ne reste plus aucun membre back-end opérationnel, le NLB retire automatiquement son annonce de routage d’entrée VPC associée. Le trafic est ensuite redirigé vers des NLB en mode route opérationnels situés dans des zones opérationnelles.
Prenons par exemple un NLB privé en mode route comportant deux nœuds back-end opérationnels : le serveur A, avec un poids de, et 8 le serveur B, avec un poids de 2. Sur 1 000 paquets entrants, environ 800 sont transférés
vers le serveur A et 200 vers le serveur B. Cependant, le transfert pondéré étant sans état, le NLB ne conserve pas l'état de la connexion. Chaque paquet est évalué indépendamment à l'aide des informations contenues dans son en-tête, puis
acheminé en fonction du résultat du hachage actuel et des pondérations configurées. Cela signifie que les paquets appartenant à un même flux peuvent arriver et repartir via différents NLB en mode route tout en étant correctement transférés,
même lorsque la répartition observée diffère du rapport de pondération configuré.
Ce comportement permet des scénarios de routage asymétrique. Pour plus d'informations, consultez le cas d'utilisation n° 8 : Haute disponibilité multizone grâce au routage asymétrique.
Circulaire pondéré
Avec cette méthode, l'équilibreur de charge achemine les connexions client entrantes vers les serveurs de back-end au prorata du poids affecté à ces serveurs. Un poids par défaut de 50 est affecté à chaque serveur, qui peut être
personnalisé en une valeur comprise entre 0 - 100.
Par exemple, si les serveurs d'applications A, B et C ont les poids 60, 60 et 30, les serveurs A et B reçoivent un nombre égal de connexions, tandis que le serveur C reçoit la moitié de ce nombre de connexions.
Les valeurs de pondération des serveurs ne sont applicables qu'avec la méthode circulaire pondérée. Elles sont ignorées avec les méthodes Permutation circulaire et Nombre minimal de connexions.
L'affectation d'un poids 0 à un serveur signifie qu'aucune nouvelle connexion n'est réacheminée vers ce serveur, mais le trafic existant continue de circuler. L'utilisation d'un poids de 0 peut aider à mettre progressivement
un serveur hors service et à le retirer de la rotation des services.
Ecouteurs de front-end et pools de back-end
Les écouteurs de front-end sont des ports d'application permettant aux équilibreurs de charge de recevoir les demandes entrantes, tandis que les pools de back-end sont les serveurs d'applications derrière les équilibreurs de charge. Vous pouvez définir jusqu'à 10 écouteurs de front-end et les mapper aux pools de back-end sur les serveurs d'applications de back-end. Pour un NLB public, le nom de domaine complet (FQDN) attribué à votre équilibreur de charge et les ports d'écoute front-end sont exposés sur Internet. Les demandes d'utilisateurs entrantes sont reçues sur ces ports. TCP et UDP sont les protocoles pris en charge pour les programmes d'écoute de front-end et les pools de back-end.
Vous pouvez connecter jusqu'à 50 instances de serveur virtuel à un pool de back-end. Le trafic est envoyé à chaque instance sur le port de données spécifié. Ce dernier n'a pas besoin d'être le même que le port de l'écouteur de front-end.
Politiques de sécurité du pool de back-end
Lors de l'édition d'un pool back-end dans un équilibreur de charge, vous pouvez spécifier l'une des actions de politique à sécurité intégrée suivantes :
- Transférer :- L'équilibreur de charge achemine les demandes vers un pool de sauvegarde désigné. Cela permet d'obtenir un chemin de basculement propre vers un autre ensemble de serveurs d'application. Un pool de sauvegarde existant doit être configuré et prêt à recevoir du trafic.
- Contournement :- L'équilibreur de charge envoie les demandes directement aux adresses IP de destination des membres, contournant ainsi complètement l'équilibreur de charge. Cette option est généralement utilisée dans des configurations de réseau spécifiques, telles que les équilibreurs de charge de réseau et les dispositifs de fonction de réseau virtuel (VNF).
- Drop :- L'équilibreur de charge abandonne toutes les demandes entrantes et le client ne reçoit pas de réponse.
Vous pouvez choisir une cible à sécurité intégrée dans une liste de pools de sauvegarde applicables.
Exigences relatives au pool de cibles à sécurité intégrée (si l'action est de type Forward):
- doivent appartenir au même équilibreur de charge
- doivent avoir le même protocole ou un protocole compatible ( TCP n'est compatible qu'avec TCP, mais toute combinaison de HTTP et HTTPS est compatible)
Nombre maximal de connexions
Il n'y a pas de nombre défini de connexions par défaut ou de connexions maximales pour un équilibreur de charge réseau. Le nombre total de connexions simultanées dépend de facteurs tels que les ressources allouées et le débit du réseau.
Représentation VPC d'un équilibreur de charge de réseau
La figure 1 illustre la représentation VPC d'une configuration type d'équilibreur de charge réseau. L'équilibreur de charge de réseau est mis à disposition sur un sous-réseau VPC. Pour configurer le chemin de données réseau sur le NLB, il faut créer un écouteur, un pool et au moins un membre. Un listener est le port frontal sur lequel le NLB écoute les requêtes des clients. Ces demandes sont transmises aux cibles du pool associé à l'écouteur. Un pool est un ensemble de cibles utilisées pour répartir les requêtes réseau entrantes vers le NLB pour un écouteur spécifique. Un membre est un serveur back-end avec un port spécifié qui est configuré pour écouter les demandes.
{: caption="de travail de l'équilibreur de charge du réseauFlux " caption-side="bottom"} travail de l'équilibreur de charge du réseau
Equilibrage de charge de couche 4
Network Load Balancer for VPC fournit un service d'équilibrage de charge de couche 4 (appelée couche transport) aux serveurs de l'utilisateur dans un VPC. Il détermine où le trafic est dirigé en fonction des adresses IP source et cible et du port indiqués dans l'en-tête de paquet. L'équilibreur de charge ne vérifie pas le contenu du paquet.
L'équilibrage de charge de couche 4 nécessitant moins de calculs qu'un équilibrage de charge plus sophistiqué, tel que celui de couche 7, l'utilisation de l'unité centrale et de la mémoire est plus optimale.
Cas d'utilisation 1: Equilibreur de charge de réseau public
Un équilibreur de charge de réseau public prend en charge Direct Server Return (DSR). Les équilibreurs de charge d'application ne prennent pas en charge cette fonction.
La figure 2 illustre le fonctionnement d'un NLB public. Le consommateur enregistre l'adresse IP de l'équilibreur de charge auprès de DNS à l'aide du nom de domaine complet de l'équilibreur de charge. Le consommateur interroge éventuellement le serveur DNS. Le serveur de noms de domaine répond avec l'adresse IP de l'équilibreur de charge. Le consommateur envoie une requête TCP à l'équilibreur de charge pour obtenir des données, et l'équilibreur de charge transmet la requête à une cible dorsale. La cible génère une réponse et celle-ci est envoyée directement au consommateur avec DSR.
Cas d'utilisation 2: Equilibreur de charge de réseau privé
Un équilibreur de charge de réseau privé est accessible uniquement à partir du réseau VPC, où le client est accessible (par exemple, via Direct Link, Transit Gatewayou les deux).
Pour les équilibreurs de charge privés, vous devez disposer d'un sous-réseau dédié sans route personnalisée configurée pour ce dernier.
La figure 3 illustre le fonctionnement d'un NLB privé. Le consommateur demande à DNS l'adresse IP de l'équilibreur de charge à l'aide du nom de domaine complet de l'équilibreur de charge. Le consommateur interroge éventuellement le serveur DNS. Le serveur de noms de domaine répond avec l'adresse IP de l'équilibreur de charge. Le consommateur envoie une demande TCP à l'équilibreur de charge pour obtenir des données via un lien direct ou une passerelle de transit, et l'équilibreur de charge transmet la demande à une cible dorsale. La cible génère une réponse et celle-ci est envoyée directement au consommateur à l'aide de DSR.
Cas d'utilisation 3: Equilibreur de charge de réseau privé avec le mode de routage activé
Les équilibreurs de charge de réseau avec route_mode défini sur true sont des équilibreurs de charge privés qui prennent en charge uniquement les dispositifs de fonction de réseau virtuel (VNF), tels qu'un pare-feu,
en tant que cibles de back-end.
La figure 4 illustre le fonctionnement d'un équilibreur de charge de réseau privé avec mode de routage. Le consommateur demande à DNS l'adresse IP de l'équilibreur de charge à l'aide du nom de domaine complet de l'équilibreur de charge. Le consommateur interroge éventuellement le serveur DNS. Le serveur de noms de domaine répond avec l'adresse IP de l'équilibreur de charge. Le consommateur envoie une demande TCP à l'équilibreur de charge pour obtenir des données via un lien direct ou une passerelle de transit. L'équilibreur de charge transmet la demande aux périphériques VNF, puis aux cibles de back end. La cible génère une réponse et cette réponse est renvoyée à l'équilibreur de charge de réseau, puis de nouveau aux unités VNF avant de revenir au client.
Plusieurs NLB privés, dont le mode de routage est activé dans chaque zone, peuvent recevoir du trafic de manière asynchrone à tout moment. Si un NLB en mode route devient défaillant, il cesse de recevoir du trafic, et celui-ci est automatiquement redirigé vers les NLB en mode route opérationnels de la zone. Pour plus d'informations, consultez la section Réacheminement pondéré.
Cas d'utilisation 4 : haute disponibilité multizone à l'aide d'un équilibreur de charge réseau
La figure 5 illustre comment vous pouvez déployer un NLB pour prendre en charge plusieurs zones. Ce scénario de déploiement nécessite souvent l'utilisation de l'option Global Load Balancer (GLB) dans IBM Cloud Internet Services(CIS).
Il existe une limitation connue pour ce cas d'utilisation. Deux membres ayant la même instance et le même port ne peuvent pas exister en même temps. Au lieu de cela, vous pouvez utiliser un port différent avec la même instance.
Vous souhaiterez peut-être tirer parti des performances de haut débit (et de la faible latence) que le NLB offre grâce au DSR. De plus, il est recommandé de déployer vos charges de travail dans plusieurs zones afin d'accroître leur disponibilité dans un environnement à haute disponibilité (HA).
Vous pouvez utiliser ce scénario de déploiement pour obtenir une haute disponibilité et vous assurer que les charges de travail sont disponibles dans plusieurs zones de disponibilité en cas de défaillance de l'équilibreur de charge. Si une condition d'échec se produit à un équilibreur de charge dans une zone de disponibilité, le GLB n'envoie plus de trafic à cette zone de disponibilité. Par exemple, si un incident se produit dans la zone de disponibilité 1, le GLB envoie le trafic à la zone de disponibilité 2 ou à la zone de disponibilité 3. Les exemples de scénarios peuvent inclure un grand nombre d'échecs, depuis un équilibreur de charge de réseau unique jusqu'à une zone de disponibilité complète.
{: caption="
L'exigence d'un NLB par zone n'est nécessaire que pour les NLB publics et privés. Le chemin privé NLB est régional par nature, il n'est donc pas nécessaire d'en définir un par zone.
Cas d'utilisation 5 : Équilibreur de charge du réseau Private Path
Un chemin privé NLB conserve tous les points de contrôle du trafic entre le fournisseur et le consommateur au sein de l'infrastructure IBM Cloud. Les données ne sortent pas sur l'internet.
Contrairement aux autres NLB, un équilibreur de charge de réseau Private Path offre une disponibilité régionale et résiste aux pannes de zone, même si un seul sous-réseau est sélectionné. Il n'est pas nécessaire de créer plusieurs équilibreurs de charge Private Path ou de spécifier plus d'un seul sous-réseau pour garantir la résilience en cas de défaillance d'une zone. Votre sélection de sous-réseau n'a d'impact que sur les adresses IP associées à l'équilibreur de charge.
Vous ne pouvez utiliser que des équilibreurs de charge de réseau de chemin privé avec un service de chemin privé. Pour plus d'informations, voir A propos des services de chemin privé.
La figure 6 illustre le fonctionnement d'un NLB Private Path pour prendre en charge un service Private Path. L'équilibreur de charge de réseau du chemin privé s'enregistre auprès du serveur DNS. Le consommateur interroge éventuellement le serveur DNS. Le consommateur envoie ensuite une demande de données ( TCP ) au Private Path NLB par l'intermédiaire d'une passerelle VPE, et le Private Path NLB transmet la demande aux cibles. Les cibles génèrent à leur tour une réponse, qui est envoyée par retour direct du serveur à l'EPV, puis au consommateur.
Cas d'utilisation n° 8 : haute disponibilité multizone grâce au routage asymétrique
La configuration suivante ne peut être utilisée qu'avec un NLB privé dont le mode de routage est activé.
La figure 9 illustre comment les NLB en mode route privée peuvent assurer une haute disponibilité multi-zone grâce au routage asymétrique. Tout d'abord, un utilisateur envoie une requête au VPC central du fournisseur via un chemin de connectivité privé, tel qu'un VPN, une connexion Direct Link ou Transit Gateway. Le NLB en mode route privé du fournisseur achemine la requête via une passerelle de transit vers les instances de serveurs virtuels situées dans le VPC spoke. Lorsque le transfert pondéré est activé, le trafic de retour peut emprunter un chemin différent de celui de la requête d’origine sans s’appuyer sur l’état de connexion établi précédemment.
Par exemple, un paquet de requête peut entrer via le NLB de la zone de disponibilité 1 et être transféré vers une instance de serveur virtuel dans le VPC spoke, tandis que le paquet de réponse revient via le NLB de la zone de disponibilité 2. Le transfert étant indépendant du chemin de connexion d'origine, la réponse est acceptée et transférée correctement. Les pondérations configurées continuent d'influencer la répartition du trafic entre les instances de serveurs virtuels backend, tout en garantissant une haute disponibilité multi-zones.
De plus, si une zone devient indisponible ou si un équilibreur de charge réseau (NLB) en mode route ne dispose plus d’instances de pare-feu actives qui lui sont associées, l’annonce de route correspondante est automatiquement retirée. Ce mécanisme dynamique de retrait d'itinéraire empêche le trafic d'être acheminé vers des points de terminaison de service défaillants et assure une haute disponibilité (HA) régionale en garantissant que le trafic est acheminé uniquement via des pare-feu opérationnels basés sur des VNF.
Haute disponibilité
