14 min de lecture

Objectifs d'apprentissage

À la fin de ce module, vous serez en mesure de:

  • Décider quand le passage en transparence TCP de la couche 4 est le niveau d'équilibrage de charge approprié plutôt que le routage de contenu de la couche 7
  • Choisir un algorithme de distribution pour un Managed Network Load Balancer et utiliser le pondération des cibles pour un déploiement canary contrôlé
  • Expliquer pourquoi le chiffrement de bout en bout et le trafic non-HTTP maintiennent le certificat sur le serveur d'arrière-plan et excluent la terminaison TLS sur l'équilibreur de charge
  • Composer une couche 7 publique en périphérie avec un équilibreur de charge privé de couche 4 devant la couche de données
  • Créer un équilibreur de charge privé de couche 4 dans Data Center Designer

Unité 3.4 : Équilibrage de charge - Couche 4 (réseau)

Introduction

L'unité 3.3 terminait TLS sur un équilibreur de charge public de couche 7, car le point d'accès devait lire le HTTP et router en fonction du contenu. La couche de données a l'exigence opposée. Elle communique via des protocoles non-HTTP tels que les bases de données, et la posture RGPD/BSI de FinCorp exige que la charge utile soit chiffrée depuis la couche applicative jusqu'à la base de données, sans intermédiaire capable de la lire. Un équilibreur de charge conscient du contenu ne peut pas servir cette couche, et il ne devrait pas essayer.

Cette unité porte sur le Managed Network Load Balancer (NLB), l'équilibreur de charge TCP de couche 4 de la plateforme, et se termine par la création d'un NLB privé devant la couche de données de FinCorp, à l'intérieur du VDC que vous avez créé dans l'unité 3.1. La décision de conception est volontairement étroite : distribuer les connexions TCP entre les cibles saines sans jamais les déchiffrer ni les inspecter.

1. Transparence TCP de niveau 4 et ses avantages

Le Managed Network Load Balancer fonctionne au niveau 4 TCP/IP du modèle OSI et fournit un equilibrage de charge basé sur les connexions. Il s'agit d'un élément VDC préconfiguré, entièrement géré, déployé dans une configuration à haute disponibilité et intégré dans le réseau défini par logiciel de la plateforme. Il sert de point d'entrée et de sortie unique pour le trafic des clients : l'écouteur accepte les connexions, et les règles de transfert répartissent les sessions sur plusieurs cibles de calcul pour un traitement parallèle.

La propriété déterminante est ce que le NLB ne fait pas. Il distribue tout trafic basé sur TCP, y compris les protocoles de niveaux supérieurs tels que HTTP et HTTPS, mais ses règles de transfert et ses vérifications d'état de santé sont strictement TCP. Les décisions de routage basées sur une URL ou un en-tête HTTP ne sont pas prises en charge. Le NLB ne déchiffre jamais la connexion, il ne termine donc jamais TLS. Lorsqu'un client ouvre une connexion chiffrée, la session TLS est établie avec la cible en arrière-plan, et le certificat ainsi que la clé privée résident sur cette cible, et non sur l'équilibreur. C'est exactement le comportement souhaité par la couche de données.

Deux situations rendent le niveau 4 obligatoire plutôt qu'une simple préférence :

  • Chiffrement de bout en bout. Lorsque le modèle de sécurité exige que la charge utile reste chiffrée depuis le client (ou la couche amont) jusqu'à l'arrière-plan, sans étape de déchiffrement intermédiaire, un équilibreur de niveau 7 est écarté, car terminer TLS signifie déchiffrer. Le NLB laisse passer le flux TCP chiffré intact, de sorte que l'arrière-plan conserve le certificat et reste le seul endroit où les données en clair existent. Pour le chemin de données réglementé de FinCorp, cela retire l'équilibreur de l'ensemble des composants qui manipulent des données clients en clair, ce qui simplifie l'évaluation de la protection des données.
  • Trafic non HTTP. Les protocoles de base de données (protocoles filaires PostgreSQL, MariaDB), les courtiers de messages et autres services TCP ne sont pas HTTP, il n'y a donc rien sur quoi un équilibreur de niveau 7 puisse router. Le niveau 4 est la seule couche adaptée.

Comme le NLB ne peut pas lire le contenu applicatif, il ne peut rien faire de conscient du contenu : aucune règle de chemin, aucun routage par hôte, aucune sonde d'état de santé consciente de HTTP. Si vous en avez besoin, vous êtes au mauvais niveau et l'Unité 3.3 est la réponse. La formulation honnête est que les niveaux 4 et 7 ne sont pas hiérarchisés ; ils se situent à des points différents de l'architecture et résolvent des problèmes différents.

1.1 Traduction d'adresse et modèle de connexion

Comprendre comment le trafic circule réellement à travers le NLB explique plusieurs de ses contraintes. Le NLB effectue une NAT de destination (DNAT) : les connexions des clients se terminent sur l'équilibreur de charge, et celui-ci initie ensuite une connexion distincte et dédiée vers la cible en arrière-plan choisie. La NAT de source (SNAT) n'est pas prise en charge, ce qui signifie que les cibles ne peuvent pas initier de connexions sortantes via l'équilibreur de charge. Le NLB est un dispositif de distribution entrant, et non un chemin de sortie. Lorsque les charges de travail privées ont besoin d'un accès sortant à Internet, c'est le rôle de la passerelle NAT (SNAT uniquement, traitée dans l'Unité 3.6), et les deux produits sont complémentaires et non interchangeables.

Comme l'équilibreur ouvre sa propre connexion vers la cible, l'arrière-plan voit par défaut l'adresse de l'équilibreur plutôt que celle du client d'origine. Lorsque l'arrière-plan a besoin de l'IP client réelle (pour la journalisation, la logique géographique ou la limitation de débit), activez le protocole Proxy sur la cible afin que les informations de connexion d'origine soient conservées et transmises. Le service en arrière-plan (par exemple Apache, NGINX ou un contrôleur d'entrée intra-cluster) doit être configuré pour s'attendre à l'en-tête du protocole Proxy et l'analyser, sinon les connexions échoueront.

1.2 Algorithmes de distribution et pondération canari

Une règle de transfert comporte un algorithme de distribution. Le NLB en propose quatre :

  • Round Robin : distribue les connexions sur les cibles dans un ordre circulaire et séquentiel, en respectant le poids de chaque cible.
  • Least Connections : envoie la prochaine connexion à la cible ayant le moins de connexions actives, ce qui convient aux sessions de longue durée ou inégales.
  • Random : distribue les connexions aléatoirement sur les cibles.
  • Source IP : associe systématiquement un client à la même cible en fonction de son adresse source.

Indépendamment de l'algorithme, le NLB maintient les sessions actives associées à la même cible grâce à l'affinité par IP source (sessions collantes) aussi longtemps que les sessions TCP sous-jacentes restent actives. L'affinité par IP source est ce qui maintient une connexion sur un seul arrière-plan ; la sélection de l'algorithme Source IP étend cette collanté pour maintenir un client donné sur le même serveur entre les connexions, ce qui est important lorsque les arrière-plans ne partagent pas l'état TLS et que vous souhaitez éviter une renégociation avec un nœud différent.

Chaque cible porte un poids de 1 à 256, avec une valeur par défaut de 1, et le trafic est distribué proportionnellement au poids d'une cible par rapport au poids combiné de toutes les cibles. C'est le mécanisme pour un canari contrôlé. Pour envoyer environ dix pour cent des nouvelles connexions vers une version candidate, enregistrez la cible canari avec un poids faible par rapport aux cibles stables de poids plus élevé (par exemple poids 1 sur le canari contre poids 9 sur le sortant) et surveillez son état de santé et ses métriques avant d'augmenter le poids. La pondération oriente uniquement les nouvelles connexions ; les sessions déjà épinglées par affinité d'IP source restent en place jusqu'à leur fermeture, de sorte qu'un changement de poids se vide progressivement et non instantanément. Pour FinCorp, la pondération canari permet à un nouveau service d'accès aux données de prendre une petite part observable du trafic réel sans bascule à date fixe.

2. Composition d'une couche publique 7 avec une couche privée 4

La forme en couches canonique de l'Unité 1.2 place un équilibreur de charge public de couche 7 à la périphérie et un équilibreur de charge privé de couche 4 devant la couche de données. Les deux ne sont pas redondants ; chacun effectue ce que l'autre ne peut pas faire.

L'équilibreur de charge public de couche 7 (Unité 3.3) se situe sur la périphérie publique, met fin aux connexions TLS et achemène le trafic HTTP en fonction du contenu vers la couche d'application sans état. Le NLB privé est entièrement situé sur un réseau privé : son écouteur n'est exposé qu'au trafic interne, il gère donc les connexions est-ouest au sein du centre de données plutôt que le trafic internet nord-sud. La couche d'application ouvre des connexions TCP chiffrées vers l'écouteur privé du NLB, le NLB les répartit sur les cibles de la couche de données, et TLS se termine sur ces cibles. Aucune adresse IP publique ne touche la couche de données, et aucun composant entre l'application et la base de données ne peut lire la charge utile.

Cette composition clarifie également une frontière de sécurité qui surprend souvent. Les pare-feu NIC et les Network Security Groups sont liés uniquement aux NIC des serveurs ; ils ne s'appliquent pas à l'équilibreur de charge géré (Unité 3.2). Le NLB comporte bien des règles de pare-feu de base qui sont appliquées automatiquement à partir de ses règles de transfert et qui ne peuvent pas être modifiées, mais il n'est pas possible d'y attacher un NSG et il n'existe aucune liste d'autorisation IP sur l'équilibreur lui-même. Le contrôle d'accès pour la couche de données relève donc des pare-feu NIC des cibles elles-mêmes et de la topologie : le LAN de données reste privé, et la seule chose qui devrait y accéder est la couche d'application via le NLB. Le fait de garder le NLB privé est en soi un contrôle principal, car un écouteur privé est inatteignable depuis internet par conception.

Une note pratique sur le placement : dans Data Center Designer, l'élément NLB dispose de deux interfaces. L'interface Nord est l'écouteur et se connecte vers les clients (un élément d'accès internet pour un NLB public, ou un LAN privé pour un NLB privé) ; l'interface Sud est l'arrière-plan et se connecte au LAN privé contenant les cibles. Pour la couche de données de FinCorp, le côté écouteur comme le côté arrière-plan restent sur des LAN privés.

Déroulement de la mise en œuvre de DCD

Vous allez construire un équilibreur de charge privé de couche 4 devant la couche de données de FinCorp, en réutilisant le VDC et la topologie à trois LAN de l'Unité 3.1. L'objectif est un NLB privé dont l'écouteur fait face au LAN applicatif et dont l'arrière-plan fait face au LAN privé des données, distribuant les connexions TCP chiffrées sur les cibles de la couche de données sans terminer le TLS. La condition préalable est que les cibles (les serveurs de la couche de données) soient déjà provisionnés sur un LAN privé ; le NLB a besoin de cibles existantes pour distribuer les sessions.

Objectif de construction : Construire un équilibreur de charge privé de couche 4 devant la couche de données.

Étapes (dans Data Center Designer) :

  1. Ouvrez le VDC de FinCorp de l'Unité 3.1 dans Data Center Designer.
  2. Glissez l'élément Network Load Balancer dans l'espace de travail.
  3. Connectez les deux interfaces du NLB. Reliez l'interface Nord (l'écouteur) au LAN applicatif privé, afin que l'équilibreur fasse face aux clients internes plutôt qu'à Internet. Reliez l'interface Sud (l'arrière-plan) au LAN privé qui héberge les cibles de la couche de données. Le fait de garder les deux côtés sur des LAN privés est ce qui en fait un équilibreur privé, est-ouest.
  4. Dans l'Inspecteur, ouvrez l'onglet Paramètres et configurez l'IP de l'écouteur. Un NLB privé utilise une IP privée ; assignez-la depuis le LAN applicatif afin que la couche applicative dispose d'une adresse stable à laquelle se connecter.
  5. Ouvrez l'onglet Règles de transfert et sélectionnez Ajouter une règle de transfert. Nommez la règle, choisissez l'algorithme de distribution (par exemple Moindre nombre de connexions pour les connexions de base de données, ou IP source si vous avez besoin qu'un client soit rattaché à un nœud unique), et confirmez le champ Protocole, qui est préconfiguré sur TCP. Définissez l'IP de l'écouteur et le Port de l'écouteur sur lesquels l'équilibreur acceptera les connexions (par exemple le port de la base de données).
  6. Au sein de la règle, sélectionnez Ajouter une cible pour chaque serveur de la couche de données. Fournissez l'IP de la cible et le Port de la cible, et définissez le Poids (de 1 à 256, valeur par défaut 1) ; utilisez des poids inégaux pour mettre en place un déploiement canari. Activez Proxy Protocol sur la cible si l'arrière-plan a besoin de l'IP client d'origine, et configurez l'arrière-plan pour l'analyser.
  7. Configurez les paramètres de Vérification d'intégrité pour la règle de transfert. Les vérifications sont basées sur TCP. Les valeurs par défaut sont un délai d'attente client de 50000 ms, un délai d'attente de connexion de 5000 ms, et un délai d'attente cible de 50000 ms ; ajustez le délai d'attente de connexion selon la rapidité avec laquelle vous souhaitez qu'une cible non responsive soit marquée comme non saine et retirée de la rotation.
  8. Provisionnez les modifications. L'équilibreur devient actif selon les paramètres, en acheminant uniquement vers les cibles qui passent la vérification d'intégrité.

Erreurs courantes :

  • S'attendre à ce que le NLB termine le TLS. Ce n'est pas le cas. Le certificat et la clé privée restent sur les cibles de l'arrière-plan ; ne planifiez pas une conception avec certificat sur l'équilibreur en couche 4.
  • Essayer d'acheminer sur l'URL ou le chemin HTTP. Les règles de transfert et les vérifications d'intégrité sont strictement TCP ; l'acheminement par contenu est une tâche de couche 7 (Unité 3.3).
  • Essayer d'attacher un Network Security Group ou une liste blanche d'IP au NLB. Il n'y en a pas. Les règles de pare-feu générées automatiquement du NLB ne peuvent pas être modifiées ; placez le filtrage sur les pare-feu des NIC des cibles et gardez l'écouteur privé.
  • Supposer que le NLB donne aux cibles une sortie Internet. Il s'agit uniquement de DNAT entrant ; le SNAT n'est pas pris en charge. Provisionnez une passerelle NAT (Unité 3.6) pour la sortie privée.
  • Oublier que l'arrière-plan voit l'adresse de l'équilibreur. Si l'application a besoin de l'IP client réelle, activez Proxy Protocol sur la cible et configurez l'arrière-plan pour s'y attendre, sinon les connexions échoueront.
  • Pointant le NLB vers des cibles qui n'existent pas encore. Les cibles doivent être provisionnées sur leur LAN privé avant que l'équilibreur ait quoi que ce soit à distribuer.

Résumé

Le Managed Network Load Balancer est le répartiteur de charge TCP de niveau 4 de la plateforme : il répartit les connexions sur des cibles saines à l'aide des algorithmes Round Robin, Least Connections, Random ou Source IP, attribue aux cibles des poids allant de 1 à 256 pour le contrôle des déploiements canary, et effectue une DNAT afin que les connexions des clients se terminent sur le répartiteur et qu'une nouvelle connexion s'ouvre vers la cible. Il ne déchiffre jamais le trafic, et ne met donc jamais fin aux sessions TLS, ce qui explique précisément pourquoi il convient aux protocoles non HTTP et aux chemins de données chiffrés de bout en bout, où le certificat doit rester sur le serveur d'arrière-plan. Placé en privé devant la couche de données de FinCorp, derrière le bord de niveau 7 public, il complète l'architecture en couches de l'Unité 1.2, sans exposition publique ni intermédiaire lisible entre l'application et la base de données.

Points clés :

  • Le niveau 4 est une transmission TCP transparente : tout trafic TCP est réparti, mais les règles et les vérifications d'état sont strictement TCP, il n'y a donc aucun routage basé sur le contenu.
  • Le NLB ne met pas fin aux sessions TLS ; le serveur d'arrière-plan conserve le certificat, ce qui rend possible le chiffrement de bout en bout et le trafic non HTTP.
  • Les algorithmes sont Round Robin, Least Connections, Random et Source IP ; les sessions persistantes sont une affinité par adresse IP source maintenue tant que les sessions TCP restent actives.
  • Les poids des cibles (de 1 à 256, valeur par défaut 1) répartissent le trafic proportionnellement et constituent le mécanisme canary ; l'attribution des poids n'oriente que les nouvelles connexions.
  • DNAT en réception uniquement, pas de SNAT ; le NLB ne fournit pas d'accès sortant (utilisez une NAT Gateway). Aucune NSG ni liste d'autorisation IP n'est associée au répartiteur managé, le filtrage doit donc être appliqué au niveau des cibles.
  • Composez un bord de niveau 7 public avec un répartiteur de niveau 4 privé placé devant une couche de données exclusivement privée.