J'utilise actuellement DNS round robin pour l'équilibrage de charge, ce qui fonctionne très bien. Les enregistrements ressemblent à ceci (j'ai un TTL de 120 secondes)
;; ANSWER SECTION:
orion.2x.to. 116 IN A 80.237.201.41
orion.2x.to. 116 IN A 87.230.54.12
orion.2x.to. 116 IN A 87.230.100.10
orion.2x.to. 116 IN A 87.230.51.65
J'ai appris que tous les FAI / appareils ne traitent pas une telle réponse de la même manière. Par exemple, certains serveurs DNS font tourner les adresses de manière aléatoire ou les parcourent toujours. Certains propagent simplement la première entrée, d'autres tentent de déterminer laquelle est la meilleure (régionalement proche) en regardant l'adresse IP.
Cependant, si la base d'utilisateurs est suffisamment grande (répartie sur plusieurs FAI, etc.), elle s'équilibre assez bien. Les écarts entre le serveur le plus chargé et le plus chargé ne dépassent pratiquement pas 15%.
Cependant, j'ai maintenant le problème que j'introduis plus de serveurs dans les systèmes et que tous n'ont pas les mêmes capacités.
Je n'ai actuellement que des serveurs 1 Gbps, mais je veux aussi travailler avec 100 Mbps et également des serveurs 10 Gbps.
Donc, ce que je veux, c'est que je veux introduire un serveur à 10 Gbps avec un poids de 100, un serveur à 1 Gbps avec un poids de 10 et un serveur à 100 Mbps avec un poids de 1.
J'ai déjà ajouté des serveurs deux fois pour leur apporter plus de trafic (ce qui fonctionnait bien - la bande passante a presque doublé). Mais ajouter un serveur 10 Gbps 100 fois au DNS est un peu ridicule.
J'ai donc pensé à utiliser le TTL.
Si je donne au serveur A 240 secondes TTL et au serveur B seulement 120 secondes (ce qui est à peu près le minimum à utiliser pour le tourniquet, car beaucoup de serveurs DNS sont définis sur 120 si un TTL inférieur est spécifié (c'est ce que j'ai entendu)). Je pense que quelque chose comme ça devrait se produire dans un scénario idéal:
First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds
Second 120 seconds
50% of requests still have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds
Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B (from the 50% of Server A that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec
Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...
Comme vous pouvez le voir, cela devient assez compliqué à prévoir et cela ne fonctionnera certainement pas comme ça dans la pratique. Mais cela devrait définitivement avoir un effet sur la distribution!
Je sais que le round robin pondéré existe et est juste contrôlé par le serveur racine. Il parcourt simplement les enregistrements DNS lors de la réponse et renvoie les enregistrements DNS avec une probabilité définie qui correspond à la pondération. Mon serveur DNS ne prend pas cela en charge et mes exigences ne sont pas aussi précises. S'il ne pèse pas parfaitement, ça va, mais il devrait aller dans la bonne direction.
Je pense que l'utilisation du champ TTL pourrait être une solution plus élégante et plus simple - et cela ne nécessite pas de serveur DNS qui contrôle cela dynamiquement, ce qui économise des ressources - ce qui est à mon avis le point essentiel de l'équilibrage de la charge DNS par rapport aux équilibreurs de charge matériels.
Ma question est maintenant la suivante: existe-t-il des meilleures pratiques / méthodes / règles empiriques pour pondérer la distribution circulaire à l'aide de l'attribut TTL des enregistrements DNS?
Éditer:
Le système est un système de serveur proxy direct. La quantité de bande passante (pas les demandes) dépasse ce qu'un seul serveur avec Ethernet peut gérer. J'ai donc besoin d'une solution d'équilibrage qui distribue la bande passante sur plusieurs serveurs. Existe-t-il des méthodes alternatives à l'utilisation du DNS? Bien sûr, je peux utiliser un équilibreur de charge avec Fibre Channel, etc., mais les coûts sont ridicules et cela n'augmente que la largeur du goulot d'étranglement et ne l'élimine pas. La seule chose à laquelle je peux penser est les adresses IP anycast (est-ce anycast ou multicast?), Mais je n'ai pas les moyens de mettre en place un tel système.