Più data center e traffico HTTP: DNS Round Robin è l'UNICO modo per garantire il failover immediato?

Record multipli A che puntano allo stesso dominio sembrano essere usati quasi esclusivamente per implementare DNS Round Robin come tecnica di bilanciamento del carico a basso costo.

Il solito avvertimento contro DNS RR è che non è buono per l'alta disponibilità. Quando 1 IP scende, i client continueranno a usarlo per minuti.

Un bilanciamento del carico viene spesso suggerito come una scelta migliore.

Entrambe le affermazioni non sono completamente vere:

1. Quando il traffico è HTTP, la maggior parte dei browser HTML è in grado di provare automaticamente il record A successivo se il precedente è inattivo, senza una nuova ricerca DNS. Leggi qui il capitolo 3.1 e qui .

2. Quando sono coinvolti più data center, DNS RR è l'unica opzione per distribuire il traffico su di essi.

Quindi, è vero che, con più data center e traffico HTTP, l'uso di DNS RR è l'UNICO modo per garantire il failover istantaneo quando un data center fallisce?

Grazie,

Valentino

Modificare:

• Ovviamente ogni data center ha un Load Balancer locale con hot spare.
• È OK sacrificare l'affinità di sessione per un failover immediato.
• AFAIK l'unico modo per un DNS di suggerire un data center invece di un altro è rispondere con solo l'IP (o IP) associato a quel data center. Se il data center diventa irraggiungibile, anche tutti questi IP sono irraggiungibili. Ciò significa che, anche se i browser HTML intelligenti sono in grado di provare immediatamente un altro record A, tutti i tentativi falliranno fino a quando la voce della cache locale non scade e non viene eseguita una nuova ricerca DNS, recuperando i nuovi IP funzionanti (suppongo che DNS suggerisca automaticamente a un nuovo data center in caso di errore). Pertanto, "DNS intelligente" non può garantire il failover immediato.
• Al contrario, un round robin DNS lo consente. Quando un data center fallisce, i browser HTML intelligenti (la maggior parte di essi) provano istantaneamente gli altri record A memorizzati nella cache saltando a un altro data center (funzionante). Pertanto, il round robin DNS non assicura l'affinità di sessione o il RTT più basso, ma sembra essere l'unico modo per garantire il failover istantaneo quando i client sono browser HTML "intelligenti".

Modifica 2:

• Alcune persone suggeriscono TCP Anycast come soluzione definitiva. In questo articolo (capitolo 6) viene spiegato che il failover di Anycast è correlato alla convergenza BGP. Per questo motivo Anycast può impiegare da 15 minuti a 20 secondi per essere completato. 20 secondi sono possibili su reti in cui la topologia è stata ottimizzata per questo. Probabilmente solo gli operatori di CDN possono garantire così rapidi fallimenti.

Modifica 3: *

• Ho fatto alcune ricerche DNS e traceroute (forse qualche esperto può ricontrollare) e:
  • L'unica CDN che utilizza TCP Anycast sembra essere CacheFly, altri operatori come le reti CDN e BitGravity usano CacheFly. Sembra che i loro bordi non possano essere usati come proxy inversi. Pertanto, non possono essere utilizzati per garantire il failover istantaneo.
  • Akamai e LimeLight sembrano usare DNS geo-compatibili. Ma! Restituiscono più record A. Da traceroutes sembra che gli IP restituiti si trovino sullo stesso data center. Quindi, sono perplesso su come possano offrire uno SLA al 100% quando un data center fallisce.

Quando uso il termine "DNS Round Robin" intendo generalmente "tecnica di bilanciamento del carico economico", come lo descrive OP.

Ma non è l'unico modo in cui il DNS può essere utilizzato per l'alta disponibilità globale. Il più delle volte, è difficile per le persone con background (tecnologici) diversi comunicare bene.

La migliore tecnica di bilanciamento del carico (se il denaro non è un problema) è generalmente considerata:

1. Una rete globale Anycast di server DNS "intelligenti",
2. e una serie di datacenter distribuiti a livello globale,
3. dove ogni nodo DNS implementa Split Horizon DNS,
4. e il monitoraggio della disponibilità e dei flussi di traffico sono disponibili in qualche modo per i nodi DNS "intelligenti",
5. in modo che la richiesta DNS dell'utente fluisca al server DNS più vicino tramite IP Anycast ,
6. e questo server DNS distribuisce un record A / set low-TTL di record per il / migliore più vicino datacenter per questo utente finale tramite DNS orizzonte 'intelligente' dividere.

L'uso di anycast per DNS va generalmente bene, perché le risposte DNS sono apolidi e quasi estremamente brevi. Pertanto, se le route BGP cambiano, è altamente improbabile che si interrompa una query DNS.

Anycast è meno adatto per le conversazioni HTTP più lunghe e stateful, quindi questo sistema utilizza DNS split horizon. Una sessione HTTP tra un client e un server viene mantenuta in un centro dati; generalmente non può eseguire il failover su un altro datacenter senza interrompere la sessione.

Come ho indicato con "set di record A", ciò che definirei "DNS Round Robin" può essere utilizzato insieme all'impostazione sopra. In genere viene utilizzato per distribuire il carico del traffico su più bilanciatori di carico ad alta disponibilità in ciascun datacenter (in modo da poter ottenere una migliore ridondanza, utilizzare bilanciatori di carico più piccoli / economici, non sovraccaricare i buffer di rete Unix di un singolo server host, ecc.).

Quindi, è vero che, con più data center e traffico HTTP, l'uso di DNS RR è l'UNICO modo per assicurare un'alta disponibilità?

No, non è vero, non se per "DNS Round Robin" intendiamo semplicemente distribuire più record A per un dominio. Ma è vero che l'uso intelligente del DNS è un componente fondamentale in qualsiasi sistema globale ad alta disponibilità. Quanto sopra illustra un modo comune (spesso il migliore) per andare.

Modifica: l'articolo di Google "Andare oltre le informazioni sul percorso end-to-end per ottimizzare le prestazioni della rete CDN" mi sembra all'avanguardia nella distribuzione globale del carico per le migliori prestazioni dell'utente finale.

Modifica 2: ho letto l'articolo "Perché basato su DNS .. GSLB .. non funziona" a cui l'OP era collegato, ed è una buona panoramica - consiglio di guardarlo. Leggi dall'alto.

Nella sezione "La soluzione al problema di memorizzazione nella cache del browser" si consiglia di rispondere al DNS con più record A che puntano a più datacenter come l'unica soluzione possibile per il failover istantaneo.

Nella sezione "Watering down" nella parte inferiore, si espande sull'ovvio, che l'invio di più A Records non è freddo se puntano a datacenter in più continenti, perché il client si connetterà in modo casuale e quindi molto spesso ottiene un 'lento' DC in un altro continente. Pertanto, affinché funzioni davvero bene, sono necessari più datacenter in ciascun continente.

Questa è una soluzione diversa rispetto ai miei passaggi 1 - 6. Non posso fornire una risposta perfetta su questo, penso che sia necessario uno specialista DNS di artisti del calibro di Akamai o Google, perché gran parte di questo si riduce al know-how pratico su i limiti delle cache e dei browser DNS distribuiti oggi. AFAIK, i miei passaggi da 1 a 6 sono ciò che Akamai fa con il proprio DNS (qualcuno può confermarlo?).

La mia sensazione - proveniente dall'aver lavorato come PM su portali di browser mobili (telefoni cellulari) - è che la diversità e il livello di totale rottura dei browser là fuori è incredibile. Personalmente non mi fiderei di una soluzione HA che richiede al terminale dell'utente finale di "fare la cosa giusta"; quindi credo che il failover istantaneo globale senza interrompere una sessione non sia fattibile oggi.

Penso che i miei passaggi 1-6 sopra siano i migliori disponibili con la tecnologia delle materie prime. Questa soluzione non ha un failover istantaneo.

Mi piacerebbe che uno di quegli specialisti DNS di Akamai, Google ecc. Venisse in giro e mi dimostrasse che mi sbagliavo. :-)

La tua domanda è: "DNS Round Robin è l'UNICO modo per garantire il failover immediato?"

La risposta è: "DNS Round Robin non è MAI il modo giusto per garantire il failover immediato".

(almeno non da solo)

Il modo giusto per ottenere il failover immediato è utilizzare il routing BGP4 in modo che entrambi i siti utilizzino gli stessi indirizzi IP. Utilizzando questo, le tecnologie di routing di base di Internet vengono utilizzate per instradare le richieste al centro dati corretto, anziché utilizzare la tecnologia di indirizzamento di base di Internet .

Nella configurazione più semplice ciò fornisce solo il failover. Può anche essere usato per fornire ad Anycast, con l'avvertenza che i protocolli basati su TCP falliranno al momento della commutazione in caso di instabilità nel routing.

Quindi, è vero che, con più data center e traffico HTTP, l'uso di DNS RR è l'UNICO modo per assicurare un'alta disponibilità?

Chiaramente è una falsa affermazione - devi solo guardare Google, Akamai, Yahoo, per vedere che non stanno usando risposte round-robin [*] come unica soluzione (alcuni potrebbero usarlo in parte, insieme ad altri approcci .)

Ci sono molte opzioni possibili, ma dipende davvero da quali altri vincoli hai, con il tuo servizio / applicazione su quale scegli.

È possibile utilizzare le tecniche round robin su un approccio server semplice e condiviso, senza doversi preoccupare di un errore del server, se si organizza anche il "failover" dell'indirizzo IP. (Ma la maggior parte opta per tecniche di bilanciamento del carico, un singolo indirizzo IP e il failover tra bilanciatori di carico.)

Forse hai bisogno di tutte le richieste per una singola sessione per andare sugli stessi server, ma vuoi che le richieste siano distribuite su cluster di server regionali diversi? Round robin non è appropriato, per questo: è necessario fare qualcosa che assicuri che ogni dato client acceda allo stesso cluster di server fisico ogni volta (tranne quando si verificano "eccezioni", come un errore del server). O ricevono un indirizzo IP coerente da una query DNS o vengono instradati allo stesso cluster di server fisico. Le soluzioni per questo includono vari "bilanciatori di carico" DNS commerciali e non commerciali o (se si ha un maggiore controllo della propria rete) annunci di rete BGP. Puoi semplicemente organizzare che i nameserver del tuo dominio forniscano risposte completamente diverse (ma, poiché le richieste DNS possono essere inviate ovunque, hai vinto "

[* Userò "round-robin", perché "RR" nella terminologia DNS significa "record di risorse".]

Molto bella l'osservazione vmiazzo +1 per te !! Sono bloccato esattamente dove sei ... confuso da come questi CDN fanno la loro magia.

Di seguito sono le mie ipotesi su come CDN gestisce la loro rete:

• Utilizzare Anycast DNS (menzionato da Jesper Mortensen) per ottenere il data center più vicino
• Gestiscono una rete locale che si estende su diversi data center che consente loro di fare qualcosa come CARP sui loro host attraverso diversi data center

O

• Impiegano Gateway Load Balancing Protocol sui loro router o Hot Standby Router Protocol (HSRP) . che gestiscono l'interruzione del datacenter.
• Il motivo per cui includono più IP è che il client riproverà e, al momento del nuovo tentativo, il percorso di routing potrebbe essere cambiato.

Al momento la seguente soluzione funziona per me: - DNS restituisce più IP, ad esempio:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Ultimo punto di accesso a un proxy inverso su Amazon Cloud, che passa in modo intelligente al server disponibile (o fornisce una pagina in manutenzione)

Il proxy inverso viene comunque colpito ma il bot è pesante come quello principale.

Perché RFC 2782 (applicare lo stesso di MX / priorità per servizi come http, imap, ...) non è implementato in nessun tipo di browser? Le cose sarebbero più facili ... C'è un bug, aperto da dieci anni a Mozilla !!! perché sarà la fine dell'industria del bilanciamento del carico commerciale ??? Ne sono molto deluso.

2 - Puoi farlo con Anycast usando Quagga

(Anche se ci sono alcune informazioni che Anycast è dannoso con TCP, ci sono diverse grandi aziende che lo usano come CacheFly)

Mi chiedo quante persone che rispondono a queste domande stiano effettivamente eseguendo una grande rete mondiale di server? Google utilizza il round robin e la mia azienda lo utilizza da anni. Può funzionare abbastanza bene, con alcune limitazioni. Sì, deve essere aumentato con altre misure.

La vera chiave è essere disposti ad accettare un singhiozzo o due se un server si arresta. Quando estraggo la spina su un server, se un browser sta tentando di accedere a quel server, ci sarà un ritardo di circa un minuto mentre il browser apprende che l'indirizzo IP è inattivo. Ma poi passa a un altro server molto rapidamente.

Funziona benissimo e le persone che sostengono che causa molti problemi non sanno di cosa stanno parlando. Richiede solo il giusto design.

Il failover fa schifo. Il miglior HA utilizza tutte le risorse in ogni momento.

Lavoro con HA dal 1986. Ho seguito una formazione approfondita per creare sistemi di failover e non sono per niente un fan del failover.

Inoltre, RR lavora per distribuire il carico, anche se passivamente anziché attivamente. I log dei nostri server mostrano chiaramente la percentuale appropriata di traffico su ciascun server - entro limiti ragionevoli.

Un'altra scelta molto semplice è utilizzare un TTL basso (quanto basso dipende dalle tue esigenze) nel record DNS A o CNAME e aggiornare questo record per scegliere quale IP verrà utilizzato.

Abbiamo 2 ISP e diversi servizi pubblici e stiamo usando con successo questo metodo per l'alta disponibilità da 3 anni.

Una chiave in cantiere è che un certo numero di ISP ha risolutori mal configurati che memorizzano nella cache i record per un intervallo prestabilito e ignorano completamente le impostazioni TTL. Non dovrebbe essere così e non ci sono scuse per farlo, ma purtroppo dalla mia esperienza con la migrazione di numerosi siti Web e servizi accade.

TCP Anycast è in realtà molto stabile ed è utilizzato almeno da CacheFly (dal 2002), Prolexic e BitGravity. Una buona presentazione su TCP Anycast è stata fatta su NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Record multipli A sono l'unico modo per eliminare un possibile singolo punto di errore. Qualsiasi altra soluzione forza tutte le richieste in arrivo a passare attraverso un singolo dispositivo da qualche parte tra il server e il client.

Quindi, per la ridondanza assoluta, è necessario. Questo è il motivo per cui Google lo fa, o chiunque voglia essere assicurato della disponibilità continua del servizio.

È abbastanza ovvio il motivo per cui questo è il caso ... più record A sono l'unico modo per spostare il punto in cui le richieste vengono instradate al browser client. Qualsiasi altro metodo si baserà su un singolo punto tra il browser client e il server in cui può verificarsi un errore, interrompendo il servizio. Utilizzando i record A, l'unico singolo punto di errore dal client al server diventa il client stesso.

Se non hai impostato più record A, stai chiedendo tempi di inattività ...

Questo metodo ovviamente non può essere invocato per il bilanciamento del carico.