Gewichtete Round Robin über TTL - möglich?

Ich verwende derzeit DNS Round Robin für den Lastausgleich, was großartig funktioniert. Die Aufzeichnungen sehen so aus (ich habe eine TTL von 120 Sekunden)

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

Ich habe erfahren, dass nicht jeder ISP / jedes Gerät eine solche Antwort gleich behandelt. Beispielsweise drehen einige DNS-Server die Adressen zufällig oder durchlaufen sie immer. Einige verbreiten nur den ersten Eintrag, andere versuchen anhand der IP-Adresse herauszufinden, welcher am besten (regional in der Nähe) ist.

Wenn die Benutzerbasis jedoch groß genug ist (verteilt auf mehrere ISPs usw.), ist der Ausgleich ziemlich gut. Die Abweichungen vom Server mit dem höchsten zum niedrigsten Server überschreiten kaum jeweils 15%.

Jetzt habe ich jedoch das Problem, dass ich mehr Server in die Systeme einführe und dass nicht alle die gleichen Kapazitäten haben.

Ich habe derzeit nur 1-Gbit / s-Server, möchte aber auch mit 100-Mbit / s-Servern und 10-Gbit / s-Servern arbeiten.

Ich möchte also einen Server mit 10 Gbit / s und einem Gewicht von 100, einen 1-Gbit / s-Server mit einem Gewicht von 10 und einen 100-Mbit / s-Server mit einem Gewicht von 1 einführen.

Ich habe zuvor zweimal Server hinzugefügt, um mehr Datenverkehr zu ihnen zu bringen (was gut funktioniert hat - die Bandbreite hat sich fast verdoppelt). Das 100-fache Hinzufügen eines 10-Gbit / s-Servers zu DNS ist jedoch etwas lächerlich.

Also habe ich darüber nachgedacht, die TTL zu verwenden.

Wenn ich Server A 240 Sekunden TTL und Server B nur 120 Sekunden gebe (was ungefähr das Minimum für Round Robin ist, da viele DNS-Server auf 120 gesetzt sind, wenn eine niedrigere TTL angegeben ist (wie ich gehört habe)). Ich denke, so etwas sollte in einem idealen Szenario auftreten:

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

Wie Sie sehen, ist die Vorhersage ziemlich kompliziert und wird in der Praxis mit Sicherheit nicht so funktionieren. Aber es sollte sich definitiv auf die Distribution auswirken!

Ich weiß, dass gewichtetes Round Robin existiert und nur vom Root-Server gesteuert wird. Beim Antworten werden nur DNS-Einträge durchlaufen und DNS-Einträge mit einer festgelegten Wahrscheinlichkeit zurückgegeben, die der Gewichtung entspricht. Mein DNS-Server unterstützt dies nicht und meine Anforderungen sind nicht so genau. Wenn es nicht perfekt wiegt, ist es in Ordnung, aber es sollte in die richtige Richtung gehen.

Ich denke, die Verwendung des TTL-Felds könnte eine elegantere und einfachere Lösung sein - und es ist kein DNS-Server erforderlich, der dies dynamisch steuert, wodurch Ressourcen gespart werden -, was meiner Meinung nach der springende Punkt beim DNS-Lastausgleich im Vergleich zum Hardware-Lastausgleich ist.

Meine Frage lautet nun: Gibt es Best Practices / Methoden / Faustregeln zur Gewichtung der Round-Robin-Verteilung mithilfe des TTL-Attributs von DNS-Einträgen?

Bearbeiten:

Das System ist ein Forward-Proxy-Server-System. Die Bandbreite (keine Anforderungen) überschreitet die Kapazität eines einzelnen Servers mit Ethernet. Ich brauche also eine Ausgleichslösung, die die Bandbreite auf mehrere Server verteilt. Gibt es alternative Methoden als die Verwendung von DNS? Natürlich kann ich einen Load Balancer mit Fibre Channel usw. verwenden, aber die Kosten sind lächerlich und es erhöht auch nur die Breite des Engpasses und beseitigt ihn nicht. Das einzige, woran ich denken kann, sind Anycast-IP-Adressen (Anycast oder Multicast?), Aber ich habe nicht die Mittel, um ein solches System einzurichten.

Zunächst einmal stimme ich @Alnitak voll und ganz zu, dass DNS nicht für diese Art von Dingen entwickelt wurde, und es wird empfohlen, DNS nicht (ab) als Load Balancer für arme Männer zu verwenden.

Meine Frage ist jetzt ... gibt es die besten Regeln / Methoden / Faustregeln, um die Round-Robin-Verteilung mithilfe des TTL-Attributs von DNS-Einträgen zu gewichten?

Um unter der Prämisse der Frage zu antworten, besteht der Ansatz zur Durchführung eines basixgewichteten Round Robin unter Verwendung von DNS in folgenden Schritten:

• Passen Sie das relative Auftreten von Einträgen in autorisierenden DNS-Antworten an. Wenn Server Aalso 1/3 des Datenverkehrs und Server B2/3 des Datenverkehrs vorhanden sein soll, enthält 1/3 der autorisierenden DNS-Antworten auf DNS-Proxys nur A die IP-Adresse und 2/3 der IP-Adressen der Antworten B. (Wenn zwei oder mehr Server dasselbe Gewicht haben, können sie zu einer Antwort zusammengefasst werden.)
• Halten Sie eine niedrige DNS-TTL ein, damit eine unausgeglichene Last relativ schnell ausgeglichen wird. Da die nachgeschalteten DNS-Proxys eine sehr ungerade Anzahl von Clients hinter sich haben, möchten Sie die Einträge häufig neu mischen.

Der Route 53-DNS-Dienst von Amazon verwendet diese Methode .

Die Bandbreite (keine Anforderungen) überschreitet die Kapazität eines einzelnen Servers mit Ethernet. Ich brauche also eine Ausgleichslösung, die die Bandbreite auf mehrere Server verteilt.

Richtig. So wie ich das verstehe, haben Sie eine Art "billigen" Download- / Videodistributions- / Download-Service für große Dateien, bei dem die Gesamtdienst-Bitrate 1 GBit überschreitet.

Ohne die genauen Einzelheiten Ihres Dienstes und Ihres Server-Layouts zu kennen, ist es schwierig, genau zu sein. Aber eine gemeinsame Lösung ist in diesem Fall:

• DNS-Round-Robin für zwei oder mehr Load-Balancer-Instanzen auf TCP / IP- oder HTTP-Ebene.
• Jede Load Balancer-Instanz ist hoch verfügbar (2 identische Load Balancer arbeiten zusammen, um eine IP-Adresse immer aktiv zu halten).
• Jede Load-Balancer-Instanz verwendet gewichtetes Round-Robin oder gewichtetes zufälliges Verbindungshandling zu den Backend-Servern.

Diese Art der Einrichtung kann mit Open-Source-Software oder mit speziell entwickelten Appliances vieler Anbieter erstellt werden. Das Load Balancing-Tag hier ist ein guter Ausgangspunkt, oder Sie können Systemadministratoren einstellen, die dies bereits getan haben, um sich für Sie zu beraten ...

Meine Frage ist jetzt ... gibt es die besten Regeln / Methoden / Faustregeln, um die Round-Robin-Verteilung mithilfe des TTL-Attributs von DNS-Einträgen zu gewichten?

Ja, die beste Vorgehensweise ist, es nicht zu tun !!

Bitte wiederhole es nach mir

• DNS dient nicht zum Lastenausgleich
• DNS bietet keine Ausfallsicherheit
• DNS bietet keine Failover-Funktionen

DNS dient zum Zuordnen eines Namens zu einer oder mehreren IP-Adressen . Jeder nachfolgende Ausgleich erfolgt durch Glück, nicht durch Design.

Schauen Sie sich PowerDNS an . Sie können damit ein benutzerdefiniertes Pipe-Backend erstellen. Ich habe ein in Perl geschriebenes Beispiel für ein Load-Balancer-DNS-Backend geändert, um das Modul Algorithm :: ConsistentHash :: Ketama zu verwenden. Auf diese Weise kann ich beliebige Gewichte wie folgt einstellen:

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);

Und noch einer:

# 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);

Ich habe einem Subdoman, den ich gslb oder Global Server Load Balancing nenne, einen c-Namen aus meiner gewünschten Top-Level-Domain hinzugefügt. Von dort aus rufe ich diesen benutzerdefinierten DNS-Server auf und sende A-Einträge gemäß meinen gewünschten Gewichten.

Funktioniert wie ein Champion. Der Ketama-Hash hat die nette Eigenschaft, die vorhandene Konfiguration nur minimal zu stören, wenn Sie Server hinzufügen oder Gewichte anpassen.

Ich empfehle, alternative DNS-Server von Jan-Piet Mens zu lesen. Er hat dort viele gute Ideen sowie Beispielcode.

Ich würde auch empfehlen, die TTL-Modulation aufzugeben. Sie sind bereits ziemlich weit weg und das Hinzufügen eines weiteren Kludges erschwert die Fehlerbehebung und Dokumentation erheblich.

Sie können PowerDNS verwenden, um ein gewichtetes Round-Robin-Verfahren durchzuführen, obwohl die Verteilung der Last auf eine derart unausgeglichene Weise (100: 1?) Sehr interessant sein kann, zumindest bei den Algorithmen, die ich in meiner Lösung verwendet habe und mit denen jedem RR-Eintrag ein Gewicht zugeordnet ist zwischen 1 und 100, und ein zufälliger Wert wird verwendet, um Datensätze einzuschließen oder auszuschließen.

Hier ist ein Artikel, den ich über die Verwendung des MySQL-Backends in PowerDNS für gewichtetes RR-DNS geschrieben habe: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

RIPienaar verfügt auch über einige Ruby-basierte Beispiele (unter Verwendung des PowerDNS-Pipe-Backends): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin

Um mit dieser Art von Setup fertig zu werden, müssen Sie sich eine echte Lastausgleichslösung ansehen. Lesen Sie Linux Virtual Server und HAProxy . Sie erhalten den zusätzlichen Vorteil, dass Server automatisch aus dem Pool entfernt werden, wenn sie ausfallen und die Auswirkungen viel einfacher zu verstehen sind. Die Gewichtung ist einfach eine Einstellung, die angepasst werden muss.