Équilibrage de charge d'un serveur UDP

J'ai un serveur udp, c'est une partie centrale de mon processus métier. afin de gérer les charges que j'attends dans l'environnement de production, j'aurai probablement besoin de 2 ou 3 instances du serveur. Le serveur est presque entièrement sans état, il collecte principalement des données, et la couche au-dessus de lui sait comment gérer la quantité minimale de données périmées pouvant provenir des multiples instances de serveur.

Ma question est, comment puis-je implémenter l'équilibrage de charge entre les serveurs? Je préférerais répartir les demandes aussi uniformément que possible entre les serveurs. Je voudrais également avoir une certaine fidélité, je veux dire si le client X a été routé vers le serveur y, alors je veux que toutes les requêtes ultérieures de X soient envoyées au serveur Y, tant qu'il est raisonnable et ne surcharge pas Y.

Au fait, c'est un système .NET ... que recommanderiez-vous?

l'état est interne au sein des serveurs, pas une transaction quelconque. l'état est certaines données que les serveurs regroupent à partir des données qu'ils reçoivent, et est quaryable avec un simple WebService WCF. L'application est basée sur UDP, et bien que je ne sois pas d'accord avec la décision, son "Au-dessus de ma note de salaire"

J'essaie actuellement le NLB de MS, cela fonctionne bien, il fait la fidélité hors de la boîte, mais il génère du bruit sur l'ensemble du réseau ...

Pas de DNS aussi ... Oh et c'est un protocole complètement costumé.

J'ai un serveur udp, le [...] serveur est presque entièrement apatride [..] j'ai une certaine fidélité, je veux dire si le client X a été routé vers le serveur y, alors je veux que toutes les requêtes suivantes de X aillent au serveur Y, comme tant qu'il est sensible et ne surcharge pas Y.

Donc, vous utilisez un protocole d'application non divulgué qui conserve un certain état d'application et s'exécute sur UDP? Vous allez en quelque sorte dans une direction difficile. UDP n'est pas un transport de données fiable, c'est tout l'intérêt - pour un transport de données fiable, consultez son ami populaire TCP. La seule façon d'obtenir votre `` fidélité '' est d'avoir un proxy d'équilibrage de charge qui comprend votre protocole de couche d'application, qui sait quel est l'état actuel de votre application et peut agir en conséquence.

Je vois 3 approches qui sont proches de fournir ce que vous recherchez:

• Répartissez statiquement les connexions entrantes sur 3 adresses IP, en fonction de l'adresse IP source (utilisateur final). De cette façon, un utilisateur donné sera toujours dirigé vers le même serveur. La plupart des pare-feu professionnels peuvent le faire pour vous. Vous devrez peut-être rendre les 3 serveurs hautement disponibles vous-même, car la plupart des pare-feu ne feront pas de vérifications de l'état du backend pour vous.

• Utilisez DNS et DNS Round Robin, comme déjà suggéré par Matt Simmons.

• Utilisez l' équilibrage de charge réseau (NLB) intégré de Windows . Honnêtement, je ne sais pas comment le scénario de basculement se déroulerait avec NLB et votre service basé sur UDP semi-stateful - vous devrez enquêter vous-même, en fonction de la façon dont votre application gère l'état. Du côté positif, NLB est très facile à configurer, gratuit avec la licence Windows, mature et performant.

Linux Virtual Server est un serveur hautement évolutif et hautement disponible construit sur un cluster de serveurs réels. Protocole UDP pris en charge par LVS et algorithme de hachage source (utilisé lorsque vous souhaitez qu'un client apparaisse toujours sur le même serveur réel).

J'utilise LVM pour équilibrer DNS (rr), SIP (sh).

Intéressant. La plupart des logiciels proxy que j'ai vus sont certes basés sur TCP.

La plupart de l'équilibrage de charge spécifique à UDP que j'ai vu dans ma maigre expérience a été basé sur DNS (c'est-à-dire: serveurs de temps, serveurs DNS, etc.). Existe-t-il un moyen de fournir plusieurs enregistrements A? Si cela fonctionnait, le DNS Round Robin normal garantirait une distribution équitable des demandes (probablement assez juste, de toute façon) et la mise en cache du client garantirait que la fidélité était conservée (en supposant que vous utilisez une plate-forme basée sur le cache du côté client).

Vous pouvez utiliser n'importe quel type d'équilibreur de charge pour effectuer cela, que ce soit du matériel ou du logiciel, vous pouvez choisir parmi différents équilibreurs de charge en fonction de vos besoins.

Équilibreur de charge de niveau 3: équilibrera la charge uniquement en regardant l'adresse IP entrante et les adresses IP de backend disponibles, ce type d'équilibreur de charge garantira l'adhérence en envoyant toujours la même adresse IP entrante au même backend, bien que ce type de stratégie puisse en surcharger un des backends si de nombreux clients proviennent de la même IP (que ce soit un proxy ou une passerelle d'entreprise)

Équilibreur de charge de niveau 7 : Un équilibreur de charge de niveau 7 sera non seulement équilibré en tant qu'équilibreur de niveau 3, mais il examinera également le contenu du package, ce qui vous donnera beaucoup plus de flexibilité pour vos politiques d'équilibrage.

Étant donné que vous utilisez UDP, les deux équilibreurs devraient donner de bonnes performances, l'inspection approfondie des paquets en UDP est un peu plus limitée que sur TCP (juste pour des raisons de protocole).

En fonction de votre budget, vous pouvez commencer par utiliser un équilibreur de charge logiciel (linux + IPVS par exemple), puis commencer à monter vers des équilibreurs de charge matériels comme ceux proposés par Cisco ou Netapp

Le NGINX open source et la plateforme de livraison d'applications, NGINX Plus, prennent désormais en charge l'équilibrage de charge UDP. La nouvelle capacité s'appuie sur nos capacités TCP et HTTP existantes, faisant de NGINX un frontend puissant, facile à utiliser et cohérent pour une gamme encore plus large d'applications et d'appareils Internet.

Disponible dans la version nginx-1.9.13