Perché il failover DNS non è raccomandato?

Dalla lettura, sembra che il failover DNS non sia consigliato solo perché DNS non è stato progettato per questo. Ma se hai due server web su diverse sottoreti che ospitano contenuti ridondanti, quali altri metodi ci sono per garantire che tutto il traffico venga instradato al server live se un server si arresta?

Per me sembra che il failover DNS sia l'unica opzione di failover qui, ma il consenso è che non è una buona opzione. Tuttavia servizi come DNSmadeeasy.com lo forniscono, quindi deve esserci merito. Qualche commento?

Per "failover DNS" intendo che intendi DNS Round Robin combinato con un po 'di monitoraggio, ovvero pubblicare più indirizzi IP per un nome host DNS e rimuovere un indirizzo morto quando il monitoraggio rileva che un server è inattivo. Questo può essere praticabile per siti Web di piccole dimensioni, meno trafficati.

In base alla progettazione, quando si risponde a una richiesta DNS si fornisce anche un Time To Live (TTL) per la risposta che si distribuisce. In altre parole, stai dicendo ad altri server DNS e cache "puoi memorizzare questa risposta e usarla per x minuti prima di ricontrollare con me". Gli svantaggi derivano da questo:

• Con il failover DNS, una percentuale sconosciuta dei tuoi utenti avrà i dati DNS memorizzati nella cache con quantità variabili di TTL rimanenti. Fino alla scadenza del TTL, questi possono connettersi al server morto. Esistono modi più rapidi per completare il failover di questo.
• A causa di quanto sopra, sei propenso a impostare il TTL piuttosto basso, diciamo 5-10 minuti. L'impostazione più alta offre un vantaggio in termini di prestazioni (molto piccolo) e può aiutare la propagazione del DNS a funzionare in modo affidabile anche se c'è un piccolo problema nel traffico di rete. Pertanto, l'utilizzo del failover basato su DNS va contro TTL elevati, ma TTL elevati fanno parte del DNS e possono essere utili.

I metodi più comuni per ottenere un buon tempo di attività comportano:

• Mettere insieme i server sulla stessa LAN.
• Posizionare la LAN in un datacenter con potenza e piani di rete altamente disponibili.
• Utilizzare un servizio di bilanciamento del carico HTTP per distribuire il carico e il failover su singoli errori del server.
• Ottieni il livello di ridondanza / tempo di attività previsto necessario per i tuoi firewall, bilanciamento del carico e switch.
• Predisporre una strategia di comunicazione per gli errori dell'intero datacenter e il fallimento occasionale di uno switch / server di database / altra risorsa che non può essere facilmente replicato.

Una piccolissima minoranza di siti Web utilizza configurazioni multi-datacenter, con "bilanciamento geografico" tra i datacenter.

Il failover DNS funziona perfettamente. Lo uso da molti anni per spostare manualmente il traffico tra i datacenter o automaticamente quando i sistemi di monitoraggio rilevano interruzioni, problemi di connettività o server sovraccarichi. Quando vedi la velocità con cui funziona e i volumi di traffico del mondo reale che possono essere spostati con facilità, non guarderai mai indietro. Uso Zabbix per il monitoraggio di tutti i miei sistemi e i grafici visivi che mostrano cosa succede durante una situazione di failover DNS mettono tutti i miei dubbi alla fine. Potrebbero esserci alcuni ISP là fuori che ignorano i TTL e ci sono alcuni utenti ancora là fuori con vecchi browser - ma quando si guarda il traffico da milioni di visualizzazioni di pagina al giorno attraverso 2 posizioni di datacenter e si fa uno spostamento del traffico DNS - il traffico residuo in arrivo che ignora i TTL è ridicolo.

Il DNS non è stato progettato per il failover, ma è stato progettato con TTL che funzionano in modo straordinario per le esigenze di failover se combinato con un solido sistema di monitoraggio. I TTL possono essere impostati molto brevi. Ho effettivamente utilizzato TTL di 5 secondi in produzione per alleggerire soluzioni veloci basate su failover DNS. Devi avere server DNS in grado di gestire il carico aggiuntivo e il nome non lo taglierà. Tuttavia, powerdns si adatta al conto se supportato da un database replicato mysql su server dei nomi ridondanti. È inoltre necessario un solido sistema di monitoraggio distribuito affidabile per l'integrazione automatizzata del failover. Zabbix funziona per me - posso verificare le interruzioni da più sistemi Zabbix distribuiti quasi istantaneamente - aggiornare i record mysql utilizzati da powerdns al volo - e fornire un failover quasi istantaneo durante interruzioni e picchi di traffico.

Ehi, ho creato un'azienda che fornisce servizi di failover DNS dopo anni di funzionamento per grandi aziende. Quindi prendi la mia opinione con un granello di sale. Se vuoi vedere alcuni grafici di traffico zabbix di siti ad alto volume durante un'interruzione - per vedere di persona come funziona correttamente il failover DNS - inviami un'e-mail Sono più che felice di condividere.

Il problema con il failover DNS è che, in molti casi, non è affidabile. Alcuni ISP ignoreranno i tuoi TTL, non succederà immediatamente anche se rispettano i tuoi TTL, e quando il tuo sito torna indietro, può portare a qualche stranezza con sessioni quando la cache DNS di un utente scade e finiscono per andare sull'altro server.

Sfortunatamente, è praticamente l'unica opzione, a meno che tu non sia abbastanza grande da fare il tuo routing (esterno).

L'opinione prevalente è che con DNS RR, quando un IP diminuisce, alcuni client continueranno a utilizzare l'IP non funzionante per minuti. Questo è stato affermato in alcune delle precedenti risposte alla domanda ed è anche scritto su Wikipedia.

Comunque,

http://crypto.stanford.edu/dns/dns-rebinding.pdf spiega che non è vero per la maggior parte degli attuali browser HTML. Proveranno il prossimo IP in pochi secondi.

http://www.tenereillo.com/GSLBPageOfShame.htm sembra essere ancora più forte:

L'uso di più record A non è un trucco del mestiere, né una funzionalità concepita dai fornitori di attrezzature per il bilanciamento del carico. Il protocollo DNS è stato progettato con il supporto di più record A proprio per questo motivo. Applicazioni come browser, proxy e server di posta fanno uso di quella parte del protocollo DNS.

Forse qualche esperto può commentare e dare una spiegazione più chiara del perché DNS RR non è buono per l'alta disponibilità.

Grazie,

Valentino

PS: scusami per il link non funzionante ma, come nuovo utente, non posso pubblicare più di 1

Ho eseguito il failover RR DNS su un sito Web di produzione a traffico moderato ma critico per l'azienda (in due aree geografiche) per molti anni.

Funziona bene, ma ci sono almeno tre sottigliezze che ho imparato a mie spese.

1) I browser eseguiranno il failover da un IP non funzionante a un IP funzionante dopo 30 secondi (l'ultima volta che ho verificato) se entrambi sono considerati attivi in ​​qualunque DNS memorizzato nella cache sia disponibile per i tuoi clienti. Questa è sostanzialmente una buona cosa.

Ma avere "metà" dei tuoi utenti in attesa di 30 secondi è inaccettabile, quindi probabilmente vorrai aggiornare i tuoi record TTL in modo che siano pochi minuti, non pochi giorni o settimane in modo che in caso di interruzione, puoi rimuovere rapidamente il down server dal tuo DNS. Altri hanno accennato a questo nelle loro risposte.

2) Se uno dei tuoi nameserver (o una delle tue due aree geografiche completamente) cade, il che serve il tuo dominio round-robin, e se quello principale si abbassa, ricordo vagamente che potresti imbatterti in altri problemi nel tentativo di rimuoverlo server dei nomi abbattuto dal DNS se non hai impostato il SOA TTL / scadenza per il server dei nomi anche su un valore sufficientemente basso. Potrei avere i dettagli tecnici sbagliati qui, ma c'è più di una sola impostazione TTL che devi ottenere per difenderti davvero da singoli punti di errore.

3) Se pubblichi API Web, servizi REST, ecc., Questi in genere non vengono chiamati dai browser, e quindi secondo me il failover DNS inizia a mostrare vere imperfezioni. Questo potrebbe essere il motivo per cui alcuni dicono, come dici "non è raccomandato". Ecco perché lo dico io. Innanzitutto, le app che utilizzano tali URL in genere non sono browser, quindi mancano le proprietà / la logica di failover di 30 secondi dei browser comuni. In secondo luogo, il fatto che venga chiamata o meno la seconda voce DNS o che venga eseguito nuovamente il polling del DNS dipende molto dai dettagli di programmazione di basso livello delle librerie di rete nei linguaggi di programmazione utilizzati da questi client API / REST, oltre a come vengono chiamati da l'app client API / REST. (Sotto le loro copertine, la libreria chiama get_addr e quando? Se i socket si bloccano o si chiudono, l'app riapre i nuovi socket? Esiste una sorta di logica di timeout? Ecc. Ecc.)

È economico, ben collaudato e "funziona principalmente". Come per la maggior parte delle cose, il tuo chilometraggio può variare.

Ci sono un sacco di persone che ci usano (Dyn) per il failover. È lo stesso motivo per cui i siti possono o fare una pagina di stato quando hanno tempi di inattività (pensa a cose come Fail Whale di Twitter) ... o semplicemente reindirizzare il traffico in base ai TTL. Alcune persone potrebbero pensare che il failover DNS sia ghetto ... ma abbiamo progettato seriamente la nostra rete con failover dall'inizio ... in modo che funzionasse così come l'hardware. Non sono sicuro di come DME lo faccia, ma abbiamo 3 dei 17 PoP più ravvicinati monitorati sul tuo server dalla posizione più vicina. Quando rileva da due dei tre che è inattivo, reindirizziamo semplicemente il traffico verso l'altro IP. L'unico tempo morto è per quelli che erano a quello richiesto per il resto di quell'intervallo TTL.

Ad alcune persone piace usare entrambi i server contemporaneamente ... e in quel caso possono fare qualcosa come un bilanciamento del carico round robin ... o un bilanciamento del carico basato su geo. Per quelli che si preoccupano effettivamente delle prestazioni ... il nostro gestore del traffico in tempo reale monitorerà ogni server ... e se uno è più lento ... reindirizza il traffico a quello più veloce in base a quali IP colleghi nei tuoi nomi host. Ancora una volta ... questo funziona in base ai valori che hai messo in atto nella nostra UI / API / Portale.

Immagino che il mio punto sia ... abbiamo progettato appositamente il failover DNS. Mentre il DNS non è stato creato per il failover quando è stato originariamente creato ... la nostra rete DNS è stata progettata per implementarlo sin dall'inizio. Di solito può essere efficace quanto l'hardware ... senza ammortamento o costo dell'hardware. Spero che non mi faccia sembrare zoppo per collegare Dyn ... ci sono molte altre aziende che lo fanno ... Sto solo parlando dal punto di vista del nostro team. Spero che sia di aiuto...

Un'altra opzione sarebbe quella di impostare il server dei nomi 1 nella posizione A e il server dei nomi 2 nella posizione B, ma impostarli ciascuno in modo che tutti i record A sul traffico NS1 puntino agli IP per la posizione A, e su NS2 tutti i record A che puntino a IP per posizione B. Quindi imposta i tuoi TTL per un numero molto basso e assicurati che il tuo record di dominio presso il registrar sia stato impostato per NS1 e NS2. In questo modo, caricherà automaticamente il bilanciamento e verrà eseguito il failover in caso di interruzione di un server o di un collegamento a una posizione.

Ho usato questo approccio in un modo leggermente diverso. Ho una posizione con due ISP e utilizzo questo metodo per indirizzare il traffico su ciascun collegamento. Ora, potrebbe essere un po 'più di manutenzione di quanto tu sia disposto a fare ... ma sono stato in grado di creare un semplice software che estrae automaticamente i record NS1, aggiorna gli indirizzi IP di un record per determinate zone e li spinge in NS2.

L'alternativa è un sistema di failover basato su BGP. Non è semplice da configurare, ma dovrebbe essere a prova di proiettile. Configurare il sito A in una posizione, il sito B in una seconda tutte con indirizzi IP locali, quindi ottenere una classe C o un altro blocco di IP portatili e impostare il reindirizzamento dagli IP portatili agli IP locali.

Ci sono insidie, ma è meglio delle soluzioni basate su DNS se hai bisogno di quel livello di controllo.

Un'opzione per il failover di più data center è quella di formare i tuoi utenti. Facciamo pubblicità ai nostri clienti che forniamo più server in più città e nelle nostre e-mail di iscrizione e che includono collegamenti direttamente a ciascun "server" in modo che gli utenti sappiano se un server è inattivo, possono utilizzare il collegamento all'altro server.

Questo elude totalmente il problema del failover DNS semplicemente mantenendo più nomi di dominio. Gli utenti che accedono a www.company.com o company.com e accedono vengono indirizzati a server1.company.com o server2.company.com e possono scegliere di aggiungere uno dei segnalibri a uno di essi se notano che ottengono prestazioni migliori utilizzando l'uno o l'altro . Se uno si interrompe, gli utenti vengono addestrati ad andare all'altro server.

Ho usato il bilanciamento del sito basato su DNS e il failover negli ultimi dieci anni, e ci sono alcuni problemi, ma questi possono essere mitigati. BGP, sebbene superiore in qualche modo non sia una soluzione al 100% né con maggiore complessità, probabilmente costi hardware aggiuntivi, tempi di convergenza, ecc ...

Ho scoperto che la combinazione di bilanciamento del carico locale (basato su LAN), GSLB e hosting di zona basato su cloud sta funzionando abbastanza bene per risolvere alcuni dei problemi normalmente associati al bilanciamento del carico DNS.

Tutte queste risposte hanno una certa validità per loro, ma penso che dipenda davvero da quello che stai facendo e dal tuo budget. Qui a CloudfloorDNS, una grande percentuale della nostra attività è DNS e offre non solo DNS veloce, ma opzioni TTL basse e failover DNS. Non saremmo in affari se non funzionasse e funzionasse bene.

Se sei una multinazionale con budget illimitato per l'uptime, sì, i bilanciatori di carico hardware GSLB e i datacenter di livello 1 sono fantastici, ma il tuo DNS deve ancora essere veloce e solido. Come molti di voi sanno, il DNS è un aspetto critico di qualsiasi infrastruttura, a parte il nome di dominio stesso, è il servizio di livello più basso su cui si basa ogni altra parte della presenza online. A partire da un registrar di domini solido, DNS è fondamentale tanto quanto non far scadere il dominio. Il DNS non funziona, significa che anche l'intero aspetto online della tua organizzazione è inattivo!

Quando si utilizza il failover DNS, gli altri aspetti critici sono il monitoraggio del server (sempre più posizioni geografiche da controllare e sempre più (almeno 3) devono essere controllati per evitare falsi positivi) e la corretta gestione dei record DNS rileva un errore. I TTL bassi e alcune opzioni con il failover possono rendere questo un processo senza soluzione di continuità e batte il diavolo dal svegliarsi a un cercapersone nel cuore della notte se sei un amministratore di sistema.

Nel complesso, il failover DNS funziona davvero e può essere molto conveniente. Nella maggior parte dei casi da noi o dalla maggior parte dei provider DNS gestiti otterrai Anycast DNS insieme al monitoraggio e al failover del server per una frazione del costo delle opzioni hardware.

Quindi la vera risposta è sì, funziona, ma è per tutti e tutti i budget? Forse no, ma fino a quando non lo provi e fai i test da solo, è difficile ignorare se sei una piccola e media impresa con un budget IT limitato che desidera il miglior tempo di attività possibile.

"e perché stai rischiando di usarlo per la maggior parte degli ambienti di produzione (anche se è meglio di niente)."

In realtà, "meglio di niente" è meglio espresso come "l'unica opzione" quando le presenze sono geograficamente diverse. I bilanciatori del carico hardware sono ottimi per un singolo punto di presenza, ma un singolo punto di presenza è anche un singolo punto di errore.

Ci sono molti siti da un sacco di dollari che usano la manipolazione del traffico basata su DNS con buoni risultati. Sono il tipo di siti che sanno ogni ora se le vendite sono in calo. Sembrerebbe che siano gli ultimi ad essere pronti a "correre il rischio di usarlo per la maggior parte degli ambienti di produzione". In effetti, hanno esaminato attentamente le loro opzioni, selezionato la tecnologia e pagato bene. Se pensassero che qualcosa fosse meglio sarebbero partiti in un batter d'occhio. Il fatto che scelgano ancora di restare parla di volumi sull'uso del mondo reale.

Il failover basato su DNS presenta una certa latenza. Non c'è modo di aggirarlo. Tuttavia, è ancora l'unico approccio praticabile alla gestione del failover in uno scenario multi-pop. Come unica opzione, è molto più che "meglio di niente".

Oggi buoni bilanciatori di carico globali che funzionano usando quella tecnica e funzionano abbastanza bene. Controllare ad esempio Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/

Se vuoi saperne di più, leggi le note sull'applicazione all'indirizzo

http://edgedirector.com

Coprono: failover, bilanciamento del carico globale e una serie di questioni correlate.

Se l'architettura back-end lo consente, l'opzione migliore è il bilanciamento del carico globale con l'opzione di failover. In questo modo, tutti i server e la larghezza di banda sono in gioco il più possibile. Invece di inserire un ulteriore server disponibile in caso di errore, questa configurazione ritira dal servizio un server guasto fino a quando non viene ripristinato.

La risposta breve: funziona, ma devi capire i limiti.

Credo che l'idea del failover fosse destinata al clustering, ma poiché poteva anche essere eseguita da solo, era ancora possibile operare in una disponibilità uno a uno.

Ti consiglio di selezionare A, selezionare un datacenter multihomed sul proprio AS o B, per ospitare i tuoi server dei nomi in un cloud pubblico. È DAVVERO improbabile che EC2, HP o IBM andranno in crisi. Solo un pensiero. Mentre il DNS funziona come una correzione, in questo caso è semplicemente una correzione di un progetto scadente nella base della rete.

Un'altra opzione, a seconda del proprio ambiente, è quella di utilizzare una combinazione con IPSLA, PBR e FHRP per soddisfare le esigenze di ridondanza.