Équilibrage de charge des serveurs DNS: UDP / TCP

On m'a demandé de reconstruire notre infrastructure d'équilibrage de charge dans le centre de données.

La demande initiale consistait à équilibrer la charge des serveurs FTP. J'ai essayé de le faire en utilisant l'équilibreur de charge actuel ( Piranha / LVS), mais je ne l'ai pas mis en service. Pas seulement parce qu'il y a peu ou pas de documentation pour ce logiciel. Depuis Piranhaest considéré comme obsolète, je suis allé au HAProxybout de quelques jours à essayer, ce qui a fait le travail en une fraction du temps passé Piranha.

J'ai donc l'équilibrage de charge FTP (mode passif) en place. Maintenant, on m'a demandé de remplacer l'intégralité de Piranha Load Balancer dans le centre de données. Dans la configuration actuelle de Piranha, nous avons plusieurs serveurs Web, serveurs IIS .... aaaand DNS .

Non, voici la chose:
HAProxysemble être un LB couramment utilisé, mais il n'est pas capable de gérerUDP load balancing . C'est une déception, car j'aime comment ça HAProxymarche. J'ai donc beaucoup cherché sur Google et je suis tombé sur plusieurs choses. La plupart des gens semblent utiliser LVScomme LB pour DNS (TCP / UDP). Certains utilisent dlbDNS, certains utilisent lbnamedet certains utilisent netfilter / iptables.

Étant donné que je voudrais m'en tenir aux HAProxyserveurs FTP, HTTP et IIS, je me suis perdu à l'utiliser côte à côte avec LVS.

Exigences:
2 instances LB avec basculement
2 serveurs DNS (déjà existants) avec basculement
Plusieurs serveurs backend (http, application, etc ...)

Questions:
est-ce possible? L'équilibrage de charge UDP sur les serveurs DNS est-il même nécessaire? Y a-t-il une sorte de ressource qui pourrait me montrer comment commencer avec ça? Ou existe-t-il une solution LB capable de gérer non seulement TCP / HTTP, mais également l'équilibrage de charge UDP?

PS: La solution LB doit être non matérielle et open source / licence GPL / sans frais.

Toute aide ou aboutissement à des ressources respectives est très appréciée!

Ne pas équilibrer la charge de votre DNS.

C'est un protocole incroyablement léger - vous auriez besoin d'une énorme quantité de trafic pour avoir besoin de plus d'une boîte (dans ce cas, vous allez juste goulot d'étranglement sur votre équilibreur de charge de toute façon), et il y a une résilience intégrée car vous pouvez utiliser plusieurs enregistrements NS dans votre délégation (d'autres serveurs seront utilisés en cas de panne).

Je ne suis pas à l'aise avec ce Q&A car il n'a pas vraiment été établi de quel type de serveur DNS vous parlez. Il existe des idées fausses importantes en ce qui concerne la résilience du DNS récursif et il est important que les personnes qui naviguent via les moteurs de recherche ne s'éloignent pas de cette discussion avec un faux sentiment de sécurité.

• DNS faisant autorité : pour les serveurs DNS faisant autorité, les connaissances communes concernant la résilience du DNS sont assez précises. Tant que vous avez plusieurs serveurs DNS faisant autorité qui sont géo-redondants, tout va bien. La raison principale de l'ajout de la haute disponibilité pour des adresses IP individuelles est que vous hébergez de nombreuses zones faisant autorité. Cela vous permet d'augmenter votre nombre de serveurs sans avoir à modifier les paramètres du registraire pour chaque domaine hébergé.

• DNS récursif : utilisez toujours une forme de solution à haute disponibilité. (BGP, appareil, etc.) C'est là que vous pouvez avoir de sérieux problèmes. Toutes les bibliothèques de résolveurs ne sont pas créées égales: les clients DNS Windows effectueront un round robin sur le serveur initial utilisé entre les requêtes, mais la majorité des systèmes basés sur Unix parcourront toujours la liste séquentiellement. Ce qui est encore moins connu, c'est que ces bibliothèques Unix devront expirer sur chaque combinaison de domaine de recherche avant de passer au serveur suivant. Si vous avez configuré plusieurs domaines de recherche et que le premier serveur dans l'ordre de recherche du résolveur est mort, cela peut créer des retards importants dans la résolution DNS pour chaque demande: plus que suffisant pour provoquer des problèmes au sein de vos applications critiques.

En ce qui concerne le DNS récursif, n'oubliez pas que votre infrastructure de serveur est aussi résiliente que la configuration client la plus braindead. À mesure que votre entreprise se développe, c'est quelque chose que vous n'avez jamais le contrôle. Ne faites aucune hypothèse de conception basée sur un environnement de système d'exploitation de serveur homogène, car les choses restent rarement les mêmes dans une entreprise en croissance. Cela mordra certainement quelqu'un si vous ne le prévoyez pas à l'avance.

Ces jours-ci, vous pouvez utiliser dnsdistpar PowerDNS

Du README

dnsdist est un équilibreur de charge très sensible au DNS, au DoS et aux abus. Son objectif dans la vie est d'acheminer le trafic vers le meilleur serveur, offrant des performances optimales aux utilisateurs légitimes tout en shuntant ou en bloquant le trafic abusif.

dnsdist est dynamique, en ce sens que sa configuration peut être modifiée au moment de l'exécution et que ses statistiques peuvent être interrogées à partir d'une interface de type console.

https://github.com/PowerDNS/pdns/tree/master/pdns/dnsdistdist

Ils fournissent des référentiels pour les systèmes d'exploitation courants: https://repo.powerdns.com/