UDP est un protocole léger qui opère sans établir de connexion. C'est pourquoi il est largement utilisé dans des services comme DNS, RADIUS, SIP, NTP, syslog, jeux et médias en temps réel. Cependant, être sans connexion ne signifie pas que le côté équilibrage de charge n'a pas besoin d'état. Le même client doit atteindre le même backend, et les flux d'appel ou d'authentification ne doivent pas être perturbés.
La distribution simple de paquets n'est pas suffisante pour la plupart des services UDP. Dans l'authentification RADIUS, disperser le même flux de session sur différents backends peut provoquer des erreurs. Côté SIP, si un flux d'appel ne reste pas sur le même backend, les comportements REGISTER, INVITE et de routage média peuvent se casser. Côté DNS, envoyer des paquets à un résolveur défaillant a un impact direct sur l'expérience utilisateur.
Les services UDP exigent typiquement un PPS élevé. Les modèles proxy simples qui traitent ce trafic entièrement dans l'espace utilisateur peuvent créer des goulots d'étranglement CPU sous forte charge. Pour le trafic DNS, syslog et jeux en particulier, la latence et la perte de paquets se traduisent directement en dégradation de la qualité de service.
La bonne approche est d'établir un véritable modèle d'équilibrage de charge L4 pour UDP : sélection d'algorithme, suivi 5-tuple, persistance bornée dans le temps, contrôles de santé conscients du protocole, routage à faible latence et haute disponibilité doivent tous faire partie du même modèle de service.
TR7 UDP Load Balancing apporte les services UDP en production avec des performances L4 au niveau kernel, suivi de session, affinité SIP, modes NAT/DR et contrôles de santé conscients du protocole.
TR7 gère le trafic UDP avec un routage L4 rapide, suivi de session, affinité consciente du protocole et contrôles de santé.
Les paquets UDP sont distribués rapidement via le moteur de routage L4. Ce modèle fournit une faible latence et une capacité élevée pour les services nécessitant des taux de paquets élevés, tels que DNS, RADIUS, SIP et trafic de jeux.
Les flux UDP sont suivis en utilisant IP source, port source, IP destination, port destination et protocole. Tout au long du timeout de persistance, le même flux est dirigé vers le même backend.
L'affinité basée sur call-ID est disponible pour le trafic SIP. REGISTER, INVITE et les messages associés sont transportés vers le même backend, préservant l'intégrité des appels.
TR7 ne se limite pas à vérifier si un port est ouvert. Des contrôles de santé conscients du protocole utilisant de vraies requêtes DNS, des requêtes d'authentification RADIUS ou des paquets UDP personnalisés sont disponibles, et les backends qui ne répondent pas sont retirés de la rotation.
UDP Load Balancing délivre distribution L4 haute vitesse, affinité de session, conscience du protocole et comportement HA dans un seul modèle pool.
TR7 supporte round-robin, round-robin pondéré, least connections, least connections pondéré, source hash et destination hash dans les pools UDP. La méthode de distribution peut être sélectionnée selon le type de service et les caractéristiques de trafic. La distribution pondérée convient aux services à fort volume comme DNS, tandis que la distribution basée sur le hash est préférée pour les services sensibles aux flux comme les jeux ou RADIUS. L'algorithme est géré centralement au niveau du pool.
Bien qu'UDP soit sans connexion, TR7 suit les flux en utilisant les informations 5-tuple. La combinaison IP source, port source, IP destination, port destination et protocole est liée au même backend pour une durée définie. L'entrée est effacée à l'expiration du timeout de persistance. Cette structure fournit une continuité de session pour le trafic RADIUS, SIP et jeux.
Lorsque le trafic SIP est distribué uniquement par IP source, le flux d'appel peut se casser. TR7 fournit une affinité basée sur call-ID via le mode de persistance spécifique à SIP. Cela garantit que les messages appartenant au même appel vont vers le même backend. Dans les environnements télécom et VoIP, ce comportement est critique.
Les services UDP peuvent nécessiter différentes topologies réseau. TR7 peut utiliser des modes de fonctionnement L4 comme NAT, SNAT, DR et TUN pour UDP. NAT/SNAT offrent un comportement de routage plus traditionnel, tandis que le mode DR est précieux pour un chemin de retour à faible latence. La sélection du mode apporte des avantages architecturaux pour les médias en temps réel et les services UDP à fort volume.
En mode DR, l'équilibreur de charge délivre le trafic du client au backend, et le trafic de retour peut aller directement au client. Cela réduit la charge sur le trafic sensible à la latence comme la voix, la vidéo et les jeux. Le chemin de retour direct est avantageux en termes de débit et de latence. La topologie réseau doit être préparée de manière appropriée pour ce mode.
TR7 peut vérifier les backends UDP non seulement par l'accès au port mais aussi par le comportement du protocole. Une vraie requête peut être utilisée pour DNS, une requête d'authentification pour RADIUS, ou un paquet défini pour les services UDP personnalisés. Un backend qui ne produit pas de réponse est retiré de la rotation. Cela réduit le problème « port ouvert mais service cassé ».
Une valeur de poids peut être définie pour chaque backend. Les serveurs plus puissants reçoivent plus de trafic pendant que ceux à plus faible capacité transportent moins de charge. Le nombre de flux suivis simultanément par backend peut également être plafonné. Cela maintient la consommation de ressources sous contrôle.
Un service UDP peut être publié sur plusieurs ports. TR7 peut supporter plusieurs définitions d'IP et port frontend sous le même pool. Par exemple, les ports d'authentification et de comptabilisation RADIUS, les ports de signalisation SIP ou les ports de jeux personnalisés peuvent tous être gérés en utilisant le même modèle de service. Cela réduit la répétition de configuration.
Pour les services UDP, un statut « up/down » seul n'est pas suffisant. TR7 peut afficher des métriques comme le taux de paquets, le taux de connexions/flux, la bande passante entrante/sortante et le statut des backends. Les opérateurs peuvent surveiller quel backend est sous charge et quel pool approche de sa limite de capacité. Cette visibilité est importante pour la planification de capacité.
Un VIP de service UDP peut se déplacer du nœud actif vers un autre nœud. Après un failover, les nouveaux flux UDP continuent via le nœud actif. Ce comportement fournit une disponibilité critique pour des services comme DNS, RADIUS et SIP. Certains flux UDP en cours récupèrent par retransmission en raison de la nature sans connexion du protocole.
L'équilibrage de charge UDP opère au niveau L4 et n'utilise pas le payload DNS comme moteur de décision. Lorsque le contenu DNS, les réponses géographiques, le failover DC ou le comportement DNS autoritatif est nécessaire, le module GTM est utilisé. Cette séparation garde l'architecture propre. L'équilibrage de charge UDP se concentre sur la distribution rapide des paquets, tandis que GTM se concentre sur le moteur de décision DNS.
Les opérateurs n'ont pas besoin d'apprendre un produit séparé ou un langage de gestion pour UDP. Pool, backend, algorithme, contrôle de santé, VIP et comportement HA sont tous gérés en utilisant les mêmes concepts de plateforme. Cela réduit la charge opérationnelle des équipes réseau et applicatives. Les services UDP font partie du modèle ADC d'entreprise.
L'équilibrage de charge UDP doit être planifié avec le comportement des timeouts, la capacité conntrack, les intervalles de contrôle de santé, le chemin de retour, la fragmentation et l'impact HA.
Les flux UDP sont surveillés pendant une durée définie et les entrées inactives sont effacées. Si le timeout est trop court, la même session peut atteindre un backend différent ; si trop long, la table grossit inutilement. Il doit être réglé selon le type de service.
Pour les services UDP à fort volume, la capacité de la table de suivi devient critique. Des services comme DNS, jeux et syslog peuvent générer un grand nombre de flux de courte durée. La planification de capacité doit être basée sur le PPS et le nombre de flux attendus.
Si les contrôles de santé sont effectués trop fréquemment sur les services UDP, ils peuvent ajouter de la charge au backend. S'ils sont effectués trop rarement, les pannes sont détectées tardivement. Pour des services comme DNS, RADIUS et SIP, l'intervalle de contrôle basé sur le protocole doit être choisi soigneusement.
Les modes NAT/SNAT gèrent le chemin de retour via l'équilibreur de charge. En mode DR, le retour peut aller directement au client et peut fournir une latence plus faible. Cependant, le backend et la topologie réseau doivent être préparés correctement pour DR.
Les grands messages SIP peuvent être fragmentés et le comportement de fragmentation UDP peut causer des problèmes. Dans de tels environnements, le MTU, la taille des messages et si nécessaire une alternative SIP basée sur TCP doivent être évalués. La persistance SIP seule ne résout pas les problèmes de fragmentation.
La session, l'état des backends, le taux de paquets et les résultats des contrôles de santé peuvent être surveillés pour les services UDP. Les failovers, les transitions de backends en bas/en haut et les limites de capacité doivent être enregistrés à des fins d'audit. Ces informations jouent un rôle critique dans l'analyse post-incident.
Un ISP ou réseau d'entreprise peut agréger plusieurs résolveurs DNS sous un seul VIP. Les résolveurs défaillants sont retirés de la rotation et la distribution pondérée peut être appliquée.
Le trafic RADIUS UDP 1812/1813 peut être distribué sur plusieurs backends d'authentification. Le timeout de persistance aide à maintenir le même flux d'authentification cohérent.
Les flux SIP REGISTER et INVITE peuvent être maintenus sur le même backend. L'affinité basée sur call-ID préserve l'intégrité des appels VoIP.
Le trafic UDP 123 est distribué sur plusieurs backends NTP. Un routage L4 léger et rapide augmente la disponibilité du service de temps.
Lorsque le trafic syslog UDP 514 est intense, un seul collecteur peut devenir un goulot d'étranglement. TR7 augmente la capacité en distribuant le flux de logs sur plusieurs backends.
Les ports UDP personnalisés peuvent être distribués avec source hash ou mode DR. Les flux de joueurs restent sur le même backend pendant que la latence est maintenue basse.
Gérez les services DNS, RADIUS, SIP et NTP avec équilibrage de charge L4, affinité de session et contrôles de santé. Laissez-nous vous guider dans une configuration en direct dans votre environnement.