Round robins ponderati tramite TTL - possibile?

Attualmente uso DNS round robin per il bilanciamento del carico, che funziona alla grande. I record sembrano così (ho un TTL di 120 secondi)

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

Ho imparato che non tutti gli ISP / dispositivi trattano tale risposta allo stesso modo. Ad esempio, alcuni server DNS ruotano gli indirizzi in modo casuale o li scorrono sempre. Alcuni semplicemente propagano la prima voce, altri cercano di determinare quale sia il migliore (a livello regionale) guardando l'indirizzo IP.

Tuttavia, se la base di utenti è abbastanza grande (si estende su più ISP, ecc.) Si equilibra abbastanza bene. Le discrepanze dal server dal più alto al più basso non superano quasi mai il 15%.

Tuttavia ora ho il problema di introdurre più server nei sistemi e che non tutti hanno le stesse capacità.

Al momento ho solo server da 1 Gbps, ma voglio lavorare anche con server a 100 Mbps e anche a 10 Gbps.

Quindi quello che voglio è introdurre un server con 10 Gbps con un peso di 100, un server da 1 Gbps con un peso di 10 e un server da 100 Mbps con un peso di 1.

In precedenza avevo aggiunto due volte server per portare più traffico su di loro (il che funzionava bene - la larghezza di banda quasi raddoppiava). Ma aggiungere un server da 10 Gbps 100 volte al DNS è un po 'ridicolo.

Quindi ho pensato di usare il TTL.

Se do al server A 240 secondi TTL e al server B solo 120 secondi (che è circa il minimo da utilizzare per il round robin, poiché molti server DNS impostati su 120 se viene specificato un TTL inferiore (quindi ho sentito)). Penso che qualcosa del genere dovrebbe accadere in uno scenario ideale:

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

Come puoi vedere, diventa piuttosto complicato da prevedere e di sicuro non funzionerà in questo modo nella pratica. Ma dovrebbe sicuramente avere un effetto sulla distribuzione!

So che esiste un round robin ponderato ed è controllato dal root server. Passa semplicemente attraverso i record DNS durante la risposta e restituisce i record DNS con una probabilità impostata che corrisponde alla ponderazione. Il mio server DNS non supporta questo e i miei requisiti non sono così precisi. Se non pesa perfettamente va bene, ma dovrebbe andare nella giusta direzione.

Penso che l'utilizzo del campo TTL possa essere una soluzione più elegante e più semplice, e non richiede un server DNS che lo controlla in modo dinamico, risparmiando risorse, che è a mio avviso il punto centrale del bilanciamento del carico DNS rispetto ai bilanciatori del carico hardware.

La mia domanda ora è: ci sono buone pratiche / metodi / regole empiriche per ponderare la distribuzione round robin usando l'attributo TTL dei record DNS?

Modificare:

Il sistema è un sistema proxy server forward. La quantità di larghezza di banda (non richieste) supera ciò che può gestire un singolo server con Ethernet. Quindi ho bisogno di una soluzione di bilanciamento che distribuisca la larghezza di banda su più server. Esistono metodi alternativi rispetto all'utilizzo del DNS? Ovviamente posso usare un bilanciamento del carico con Fibre Channel ecc., Ma i costi sono ridicoli e aumenta anche solo la larghezza del collo di bottiglia e non lo elimina. L'unica cosa a cui riesco a pensare sono gli indirizzi IP anycast (anycast o multicast?), Ma non ho i mezzi per configurare un tale sistema.

Prima di tutto, sono completamente d'accordo con @Alnitak sul fatto che il DNS non è progettato per questo genere di cose, e la migliore pratica è di non (ab) utilizzare il DNS come bilanciamento del carico di un uomo povero.

La mia domanda ora è ... ci sono dei migliori prectices / methos / regole empiriche per ponderare la distribuzione round robin usando l'attributo TTL dei record DNS?

Per rispondere alla premessa della domanda, l'approccio utilizzato per eseguire il round robin ponderato basix utilizzando DNS è di:

• Regola l' occorrenza relativa dei record nelle risposte DNS autorevoli. Vale a dire se Server Adeve avere 1/3 del traffico e Server Bdeve avere 2/3, quindi 1/3 delle risposte DNS autorevoli ai proxy DNS conterrebbero solo A l'IP e i 2/3 Bdell'IP solo delle risposte . (Se 2 o più server condividono lo stesso "peso", possono essere raggruppati in un'unica risposta.)
• Mantenere un TTL DNS basso in modo che il carico non bilanciato venga uniformemente eliminato rapidamente. Poiché i proxy DNS downstream hanno un numero di client molto disomogeneo alle spalle, si consiglia di ripetere il riordino frequente dei record.

Il servizio DNS Route 53 di Amazon utilizza questo metodo .

La quantità di larghezza di banda (non richieste) supera ciò che può gestire un singolo server con Ethernet. Quindi ho bisogno di una soluzione di bilanciamento che distribuisca la larghezza di banda su più server.

Giusto. Quindi, a quanto ho capito, hai una sorta di download "economici" / distribuzione video / servizio di download di file di grandi dimensioni, in cui il bitrate totale del servizio supera 1 GBit.

Senza conoscere le specifiche esatte del servizio e del layout del server, è difficile essere precisi. Ma una soluzione comune in questo caso è:

• Round robin DNS su due o più istanze di bilanciamento del carico a livello TCP / IP o HTTP.
• Ogni istanza di bilanciamento del carico è altamente disponibile (2 bilanciatori di carico identici cooperano per mantenere sempre attivo un indirizzo IP).
• Ogni istanza di bilanciamento del carico utilizza un round robin ponderato o una gestione ponderata della connessione casuale con i server back-end.

Questo tipo di installazione può essere realizzata con software open source o con dispositivi appositamente creati da molti fornitori. Il tag di bilanciamento del carico qui è un ottimo punto di partenza, oppure potresti assumere amministratori di sistema che lo hanno già fatto prima di consultare per te ...

La mia domanda ora è ... ci sono dei migliori prectices / methos / regole empiriche per ponderare la distribuzione round robin usando l'attributo TTL dei record DNS?

Sì, la migliore pratica è non farlo !!

Per cortesia ripeti dopo di me

• DNS non è per il bilanciamento del carico
• DNS non fornisce resilienza
• DNS non fornisce funzionalità di failover

Il DNS serve per associare un nome a uno o più indirizzi IP . Qualsiasi successivo bilanciamento che ottieni è per fortuna, non per design.

Dai un'occhiata a PowerDNS . Ti consente di creare un backend di pipe personalizzato. Ho modificato un backend DNS di bilanciamento del carico di esempio scritto in perl per utilizzare il modulo Algorithm :: ConsistentHash :: Ketama. Questo mi permette di impostare pesi arbitrari in questo modo:

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

E un altro:

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

Ho aggiunto un cname dal mio dominio di primo livello desiderato a un dominio secondario che chiamo gslb, o Global Server Load Balancing. Da lì, invoco questo server DNS personalizzato e invio i record A secondo i miei pesi desiderati.

Funziona come un campione. L'hash ketama ha la proprietà piacevole di un'interruzione minima della configurazione esistente quando si aggiungono server o si regolano i pesi.

Consiglio di leggere Server DNS alternativi, di Jan-Piet Mens. Ha molte buone idee e codice di esempio.

Consiglierei anche di abbandonare la modulazione TTL. Ti stai già allontanando abbastanza e aggiungere un altro kludge in cima renderà estremamente difficile la risoluzione dei problemi e la documentazione.

Puoi usare PowerDNS per eseguire round robin ponderato, sebbene distribuire il carico in modo così sbilanciato (100: 1?) Possa diventare molto interessante, almeno con gli algoritmi che ho usato nella mia soluzione, in cui ogni voce RR ha un peso associato , tra 1-100 e un valore casuale viene utilizzato per includere o escludere i record.

Ecco un articolo che ho scritto sull'uso del back-end MySQL in PowerDNS per eseguire DNS RR ponderati: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

RIPienaar ha anche alcuni esempi basati su Ruby (usando il backend di pipe PowerDNS): http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin

Per gestire questo tipo di installazione, è necessario esaminare una soluzione di bilanciamento del carico reale. Leggi Linux Virtual Server e HAProxy . Ottieni il vantaggio aggiuntivo di rimuovere automaticamente i server dal pool se falliscono e gli effetti sono molto più facilmente comprensibili. La ponderazione è semplicemente un'impostazione da modificare.