Le trafic d'entreprise ne se compose pas uniquement d'applications HTTP. DNS, SIP, RADIUS, NTP, services TCP bruts, protocoles de tunnel et flux de streaming à fort volume se comportent différemment. Pour ces services, plutôt que le traitement du contenu, ce sont la faible latence, la faible consommation CPU, la décision rapide et le bon chemin de retour qui sont plus critiques.
Lorsque l'équilibrage de charge L4 et L7 est géré comme des produits séparés, des consoles séparées ou des niveaux de licence séparés, l'exploitation se complique. Une équipe doit gérer un composant réseau séparé pour les services DNS et UDP, un ADC séparé pour les applications web, une couche séparée pour la sécurité. En cas de problème, même la question de savoir quel trafic est passé par quel produit fait perdre du temps.
Le trafic UDP demande une attention particulière. Comme l'état de connexion n'est pas aussi marqué qu'en TCP, la persistence, le comportement de l'IP source, l'effet du NAT et le chemin de réponse du backend doivent être conçus correctement. Pour des protocoles comme SIP, la session doit rester sur le même backend, tandis que pour des services comme DNS et NTP, c'est la latence la plus faible possible qui prime.
Des modes comme le direct return et l'IP tunnel offrent un grand avantage lorsqu'ils sont correctement configurés ; mais ils créent des problèmes si les exigences réseau ne sont pas clairement connues. En mode direct routing, les réglages d'alias VIP loopback, de comportement ARP et de chemin de retour doivent être corrects sur les backends. Sinon, au lieu d'un gain de performance, un problème d'accessibilité apparaît.
Les modes L4 de TR7 réunissent la distribution de trafic à faible latence au niveau kernel, le choix de mode adapté aux différentes topologies réseau et le fonctionnement mixte L4+L7 sous un seul modèle de gestion ADC.
TR7 traite le trafic L4 au niveau kernel tout en offrant la gestion centralisée du mode, de l'algorithme, du contrôle de santé et des services mixtes.
TR7 s'appuie sur l'infrastructure Linux LVS/IPVS pour l'équilibrage de charge L4. Cette approche réduit le coût de traitement en espace utilisateur, permettant une décision rapide pour le trafic TCP et UDP.
Pour chaque pool de services L4 sont configurés le protocole, l'algorithme, la liste des backends, le poids, la limite de connexions et le contrôle de santé. La couche d'orchestration L4 de TR7 transforme cette configuration en comportement d'équilibrage L4 exécutable.
Les modes NAT, SNAT, direct routing, IP tunnel et forwarding de protocole générique répondent à des besoins différents. L'opérateur choisit le mode adapté selon le chemin de retour du trafic, la préservation de l'IP source et le placement des backends.
Sur le même TR7, des services L7 basés sur HTTP/TCP et des services L4 basés sur IPVS peuvent fonctionner côte à côte. Ainsi, sur une seule VIP, différents ports peuvent être routés vers différents moteurs de traitement.
Les Modes L4 de TR7 offrent des options d'équilibrage flexibles pour différents protocoles, topologies réseau et comportements de service.
TR7 prend en charge les modes NAT, SNAT, direct routing, IP tunnel et forwarding de protocole générique. En mode NAT, le trafic de retour passe par l'équilibreur de charge. En mode direct routing, le chemin de retour va directement du backend vers le client. Le mode IP tunnel peut être utilisé dans les scénarios nécessitant un site distant ou une traversée d'un réseau différent.
Un pool de services L4 peut être défini avec le protocole TCP ou UDP. Les services UDP comme DNS, SIP, RADIUS et NTP peuvent être équilibrés sans être forcés dans le pipeline de traitement L7. Les services TCP peuvent être utilisés pour une distribution à faible latence par port. Chaque pool fonctionne de manière simple et prévisible avec une logique mono-protocole.
TR7 prend en charge les algorithmes round robin, weighted round robin, least connection, weighted least connection, source hash et destination hash. Les algorithmes pondérés peuvent être utilisés pour envoyer plus de trafic vers les backends les plus puissants. Les algorithmes basés sur le hash facilitent le routage d'une même source ou destination vers le même service. Ces algorithmes fonctionnent dans les pools L4 indépendamment des algorithmes L7.
Une valeur de timeout peut être définie pour la persistence basée sur l'IP source. L'approche par défaut maintient une même source vers le même backend pendant une durée donnée. Pour le trafic SIP, un moteur de persistence basé sur le call-id peut être utilisé. Cette architecture aide à éviter la rupture des comportements de session basés sur UDP.
Les pools de services L4 peuvent être gérés avec un contrôle de santé. Le mécanisme de contrôle de santé L4 peut retirer les backends indisponibles de la distribution. Un contrôle basé sur HTTP permet de surveiller l'API de gestion ou un endpoint de santé personnalisé. Ainsi, les décisions L4 sont prises non seulement selon la définition du port, mais selon la disponibilité réelle du service.
Une valeur de weight peut être définie pour chaque backend et, dans les algorithmes pondérés, le ratio de trafic est déterminé en conséquence. Une limite de connexions permet de borner la surcharge d'un seul backend. Cette fonctionnalité permet une utilisation plus équilibrée, dans le même pool, de services aux capacités différentes. L'équipe d'exploitation gère plus finement l'ajout de services et l'augmentation de capacité.
Le mécanisme de failover VRRP permet de déplacer la VIP entre les membres d'une paire HA. En cas de perte d'un node ADC, la VIP peut être reprise sur l'autre node. Pour les services UDP, une courte perte de session est acceptable dans la plupart des scénarios, tandis que pour les services TCP, le comportement de failover doit être évalué selon l'application et la structure de session. Ce modèle permet de rattacher les services L4 à une architecture de haute disponibilité.
Via les statistiques IPVS, les ratios de connexions, de paquets et de bande passante peuvent être suivis. Les valeurs instantanées de CPS, de ratio de paquets entrée/sortie et de bande passante entrée/sortie peuvent être surveillées. TR7 peut produire ces statistiques de manière compatible avec la structure de monitoring de la plateforme. L'équipe d'exploitation peut voir comment les pools L4 transportent réellement le trafic.
Le mode protocole générique peut être utilisé dans les scénarios de forwarding L3 générique pour les protocoles autres que TCP et UDP. Pour des types de trafic comme ESP, GRE ou ICMP, le modèle L4 classique par port peut ne pas suffire. Dans ce mode, les statistiques détaillées de connexion sont limitées ; la visibilité est assurée par des compteurs d'octets de base. Il constitue une option de forwarding pratique pour les traversées réseau spécifiques.
Avec le réglage de namespace L4, un pool de services L4 peut être exécuté dans un contexte de network namespace séparé. Cette architecture est importante pour les organisations qui veulent distinguer différents tenants ou zones réseau. Plusieurs contextes réseau sur le même appareil peuvent être gérés de manière plus contrôlée. L'isolation renforce la sécurité opérationnelle dans les conceptions de déploiement mixte.
Pour que les modes L4 fonctionnent correctement, le suivi des connexions, le comportement de failover, les exigences du direct routing, les limites des statistiques et la gestion des services doivent être planifiés clairement.
L'équilibrage de charge L4 basé sur IPVS convient aux services exigeant une faible latence et un débit élevé. En mode direct routing, comme le trafic de retour contourne l'équilibreur de charge, l'avantage est particulièrement net pour les services produisant des réponses à fort volume. La capacité réelle dépend de la carte réseau, du CPU, du choix du mode et de la topologie des backends.
Pour les services UDP et L4 intensifs, la taille de la table conntrack Linux devient critique. Les valeurs par défaut peuvent ne pas suffire pour un trafic à grande échelle ; elles doivent être planifiées selon le volume de trafic.
La VIP peut être déplacée entre les membres d'une paire HA avec VRRP. En cas de perte d'un node, le service continue sur l'autre node. Comme les services UDP sont souvent stateless, ils se rétablissent plus facilement, tandis que pour les sessions TCP, le comportement d'interruption doit être évalué selon la tolérance de l'application.
En mode direct routing, le backend doit reconnaître la VIP comme alias loopback. Pour le comportement ARP, il est important de configurer correctement les réglages arp_ignore et arp_announce. Si ces exigences ne sont pas satisfaites, au lieu de l'avantage du chemin de retour, un problème d'accès peut apparaître.
En mode de forwarding de protocole générique, les détails par connexion sont limités. Ce mode répond plutôt à un besoin de forwarding L3 spécifique et est surveillé par des compteurs d'octets de base. Pour les services nécessitant une analyse de connexion approfondie, les modes TCP ou UDP peuvent être plus adaptés.
Les statistiques des pools L4 peuvent être collectées et rendues compatibles avec la forme de monitoring générale de la plateforme. Les valeurs de connexions, de paquets et de bande passante peuvent être écrites dans les systèmes d'enregistrement historiques. Cela facilite la surveillance des services L4 dans le même panneau d'exploitation que les services L7.
Pour le trafic SIP UDP, l'utilisation du NAT peut affecter le comportement de l'IP source et du chemin de retour. Si le backend veut produire une réponse directe au client, le choix du mode doit être fait avec soin. Les options de persistence SIP et de direct routing peuvent offrir une meilleure conception dans ce type de scénario.
Pour chaque pool L4, le service d'orchestration L4 associé peut être supervisé. L'état du service, la durée de fonctionnement et le dernier changement d'état sont précieux pour l'audit opérationnel. Ces informations soutiennent les changements de configuration L4 et les analyses de failover.
Un télécom ou un fournisseur de services peut équilibrer plusieurs backends de recursors DNS sur UDP 53. En désactivant la persistence, une distribution DNS à faible latence et équilibrée est assurée.
Une organisation peut router le trafic UDP 1812 et 1813 avec l'algorithme source hash pour diriger un même client vers le même service d'authentification. Cette architecture assure un choix de service cohérent dans le flux d'authentification.
En environnement télécom, le trafic SIP UDP 5060 peut être équilibré avec une persistence basée sur le call-id. Faire aller le même flux d'appel vers le même backend aide à préserver le comportement de session.
Dans un scénario média ou CDN, le trafic TCP 80/443 peut être exécuté en mode direct routing. Comme le trafic de retour va directement du backend vers le client, la charge de retour sur l'équilibreur de charge diminue.
Dans les services d'infrastructure, le trafic NTP UDP 123 peut être distribué vers les backends de manière équilibrée et à faible latence avec le round robin. Pour ce type de trafic sans besoin de persistence, une simple définition de pool suffit.
Sur une même VIP, les ports 80 et 443 peuvent être routés vers le moteur de traitement L7, et le port 53 vers le moteur L4 IPVS. Une optimisation distincte pour des types de trafic mixtes est assurée sous une seule licence et une seule console.
Équilibrage de charge L4 à faible latence et par mode pour des services comme DNS, SIP, RADIUS, NTP et streaming. Parcourons-le ensemble dans une installation en direct avec vos propres services.