Round robins pondérés via TTL - possible?


9

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.


Soyez prêt à être frappé à la tête avec une copie de la RFC 2181 § 5.2 par un large éventail de répondants.
JdeBP

eh bien je me rends compte que RR n'a pas été conçu pour l'équilibrage de charge. mais cela fonctionne très bien ... donc ... je ne suis pas non plus au courant d'une alternative. bien sûr il y en a mais elles ne sont pas possibles pour moi à mettre en place ou bien trop chères ou trop compliquées
Le Shurrican

@JdeBP oui, bon endroit - les TTL dans un RRset DOIVENT être les mêmes.
Alnitak

Réponses:


2

Tout d'abord, je suis entièrement d'accord avec @Alnitak que DNS n'est pas conçu pour ce genre de chose, et la meilleure pratique est de ne pas (ab) utiliser DNS comme équilibreur de charge d'un pauvre.

Ma question est maintenant ... Y a-t-il de meilleurs pratiques / méthodes / règles de base pour pondérer la distribution de tourniquet en utilisant l'attribut TTL des enregistrements DNS?

Pour répondre sur la prémisse de la question, l'approche utilisée pour effectuer un round robin pondéré basix en utilisant DNS est de:

  • Ajustez l' occurrence relative des enregistrements dans les réponses DNS faisant autorité. C'est-à-dire si Server Adoit avoir 1/3 du trafic et Server Bdoit avoir 2/3, alors 1/3 des réponses DNS faisant autorité aux mandataires DNS contiendraient uniquement A l'IP, et 2/3 des réponses uniquement Bl'IP. (Si 2 serveurs ou plus partagent le même «poids», ils peuvent être regroupés en une seule réponse.)
  • Gardez un TTL DNS faible afin que la charge non équilibrée soit uniformisée assez rapidement. Étant donné que les proxys DNS en aval ont un nombre très pair de clients derrière eux, vous voudriez réorganiser les enregistrements fréquemment.

Le service DNS Route 53 d' Amazon utilise cette méthode .

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.

Droite. Donc, si je comprends bien, vous avez une sorte de service de téléchargement / distribution vidéo / téléchargement de fichiers volumineux «bon marché», où le débit binaire total du service dépasse 1 Go.

Sans connaître les spécificités exactes de votre service et de la configuration de votre serveur, il est difficile d'être précis. Mais une solution courante dans ce cas est:

  • Round robin DNS sur deux instances d'équilibreur de charge TCP / IP ou HTTP ou plus.
  • Chaque instance d'équilibreur de charge étant hautement disponible (2 équilibreurs de charge identiques coopérant pour garder une adresse IP toujours activée).
  • Chaque instance d'équilibreur de charge utilisant un round robin pondéré ou une gestion de connexion aléatoire pondérée vers les serveurs principaux.

Ce type de configuration peut être créé avec des logiciels open source ou avec des appliances spécialement conçues par de nombreux fournisseurs. La balise d'équilibrage de charge est un excellent point de départ, ou vous pouvez engager des administrateurs système qui l'ont déjà fait pour vous consulter ...


4

Ma question est maintenant ... Y a-t-il de meilleurs pratiques / méthodes / règles de base pour pondérer la distribution de tourniquet en utilisant l'attribut TTL des enregistrements DNS?

Oui, la meilleure pratique est de ne pas le faire !!

Veuillez répéter après moi

  • Le DNS n'est pas pour l'équilibrage de charge
  • DNS ne fournit pas de résilience
  • DNS ne fournit pas de fonctions de basculement

DNS sert à mapper un nom à une ou plusieurs adresses IP . Tout équilibre ultérieur que vous obtenez est par chance, pas par conception.


1
more IP addresses... comment est-ce que ce n'est pas équilibré? c'est d'ailleurs pourquoi j'ai donné à ma question une introduction appropriée. si je ne l'ai pas fait, j'apprécierais votre message en tant que commentaire, mais comme cela, je dois le déprécier. maby il n'est pas conçu mais il fonctionne très bien et offre de grands avantages par rapport à toutes les alternatives. et c'est ce que les sites Web comme google, facebook, amazon, etc. pensent aussi et l'utilisent. toutefois, un commentaire a été noté. j'ai mis à jour ma question avec plus d'informations sur le scénario et je vous demande de suggérer une solution d'équilibrage alternative @Alnitak
The Shurrican

2
L'équilibrage de cette façon n'offre aucune garantie d'exhaustivité, car de nombreux problèmes rencontrés par le client se posent hors de votre contrôle. C'est doublement le cas lorsque vous souhaitez «peser» car, fondamentalement, vous ne pouvez pas garantir le tournoi à la ronde en premier lieu. Le DNS est un service de conseil uniquement, les clients n'ont pas besoin de le suivre à la lettre. Je pense que c'est le point que @Alnitak voulait faire valoir
Matthew Ife

je le comprends parfaitement. citation de ma question: 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 essaient 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%.
The Shurrican

@JoeHopfgartner le seul moyen infaillible d'assurer la résilience, la redondance et l'équilibrage se situe au niveau de la couche IP - c'est-à-dire le routage BGP et les équilibreurs de charge de la couche 4. Je ne l'ai pas dit dans cette réponse parce que je l'ai déjà dit des dizaines de fois dans d'autres réponses.
Alnitak

La redondance est-elle importante pour votre solution? IE si un serveur tombe en panne, il est correctement géré? Parce que si c'est votre ouverture, une boîte de vers avec RR-DNS.
Matthew Ife

2

Jetez un œil à PowerDNS . Il vous permet de créer un backend de tuyau personnalisé. J'ai modifié un exemple de backend DNS d'équilibreur de charge écrit en perl pour utiliser le module Algorithm :: ConsistentHash :: Ketama. Cela me permet de définir des poids arbitraires comme suit:

my $ketamahe = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);

Et un autre:

# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);

J'ai ajouté un nom de domaine de mon domaine de premier niveau souhaité à un sous-domaine que j'appelle gslb, ou Global Server Load Balancing. À partir de là, j'invoque ce serveur DNS personnalisé et envoie des enregistrements A en fonction de mes poids souhaités.

Fonctionne comme un champion. Le hachage ketama a la belle propriété de perturber le moins possible la configuration existante lorsque vous ajoutez des serveurs ou ajustez les poids.

Je recommande la lecture des serveurs DNS alternatifs, par Jan-Piet Mens. Il contient de nombreuses bonnes idées ainsi qu'un exemple de code.

Je recommanderais également d'abandonner la modulation TTL. Vous êtes déjà loin et l'ajout d'un autre kludge au-dessus rendra le dépannage et la documentation extrêmement difficiles.


1

Vous pouvez utiliser PowerDNS pour effectuer un round robin pondéré, bien que la distribution de la charge d'une manière aussi déséquilibrée (100: 1?) Puisse devenir très intéressante, au moins avec les algorithmes que j'ai utilisés dans ma solution, où chaque entrée RR a un poids qui lui est associé , entre 1 et 100, et une valeur aléatoire est utilisée pour inclure ou exclure des enregistrements.

Voici un article que j'ai écrit sur l'utilisation du backend MySQL dans PowerDNS pour faire du DNS RR pondéré: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

RIPienaar a également quelques exemples basés sur Ruby (en utilisant le backend de canal PowerDNS): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin


1

Pour gérer ce type de configuration, vous devez rechercher une véritable solution d'équilibrage de charge. Lisez Linux Virtual Server et HAProxy . Vous obtenez l'avantage supplémentaire de supprimer automatiquement les serveurs du pool s'ils échouent et que les effets sont beaucoup plus faciles à comprendre. La pondération est simplement un paramètre à modifier.


Le problème avec cela est que j'ai un problème de bande passante et pas un problème de nombre de requêtes qu'un seul serveur peut gérer. Donc, une solution où je dois diriger tout le trafic via un nœud n'est pas une solution pour moi. La seule chose à laquelle je peux penser à côté de la solution DNS est une adresse IP de multidiffusion. J'ai modifié ma question en conséquence.
The Shurrican

désolé je veux dire anycast, pas multicast (je pense)
The Shurrican

1
Si la bande passante est le problème, vous devriez examiner ce + LACP sur vos commutateurs. Vous pouvez ensuite lier plusieurs cartes 10G dans les dispositifs d'équilibrage de charge.
Mark Harrigan

j'ai voté pour cela parce que c'est intéressant ... mais j'ai mon interrupteur comme goulot d'étranglement
Le Shurrican
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.