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.
-
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.
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 entrant dans 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.
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 l'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.
