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

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.

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 ...

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.

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.

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

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.