Perché non è raccomandato il failover DNS?

Dalla lettura, sembra che il failover DNS non sia raccomandato solo perché DNS non è stato progettato per esso. Ma se si dispone di due server web su diverse sottoreti che contengono contenuti ridondanti, quali altri methods sono disponibili per assicurare che tutto il traffico venga inviato al server live se un server scende?

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

  • Utilizzo di Microsoft DNS per rispondere in base alla richiesta di subnet
  • Come impostare il record mx sul registrar?
  • Posso avere un IP separato per un record e un record MX
  • "La zona può essere scavenged dopo" continua a crescere
  • Miglior modo per aggiungere un record di wildcard DNS per un dominio
  • Assegnazione di più ips pubblici per un sito web
  • Esecuzione di più servizi su diversi server con IPv6 e un FQDN
  • Haploxy Resolver Sezione + Amazon ELB
  • Disponibilità di Apache con i due front-ends in posizioni diverse. È ansible?
  • DNS Round-robin, bilanciamento del carico, condivisione di carico e failover nel 2012
  • Come funziona il CDN se IP Addr è random?
  • Cisco DHCP e Windows DNS senza aggiornamenti non sicuri
  • 16 Solutions collect form web for “Perché non è raccomandato il failover DNS?”

    Con il 'failover DNS' ho inteso che si intende DNS Round Robin combinato con un certo monitoraggio, ovvero la pubblicazione di più indirizzi IP per un nome host DNS e la rimozione di un indirizzo morto quando il monitoraggio rileva che un server è in discesa. Questo può essere utile per piccoli siti Web trafficati.

    Di progettazione, quando si risponde a una richiesta DNS si fornisce anche un Time To Live (TTL) per la risposta che hai distribuito. In altre parole, stai raccontando altri server DNS e le cache "puoi memorizzare questa risposta e usarla per x minuti prima di tornare indietro con me". Gli inconvenienti provengono da questo:

    • Con il failover DNS, una percentuale sconosciuta degli utenti avrà i dati DNS memorizzati nella cache con quantità diverse di TTL a sinistra. Finché la TTL non scade questi possono essere connessi al server morto. Ci sono modi più veloci per completare il failover di questo.
    • A causa di quanto sopra, sei disposto a impostare il TTL abbastanza basso, per esempio 5-10 minuti. Ma impostandolo più in alto fornisce un vantaggio di performance (molto piccolo) e può aiutare il tuo lavoro di propagazione DNS in modo affidabile anche se c'è un breve errore nel traffico di networking. Quindi usando il failover basato su DNS va contro elevati TTLs, ma TTL elevati sono una parte del DNS e possono essere utili.

    I methods più comuni per get buone uptime coinvolgono:

    • Posizionamento dei server sulla stessa LAN.
    • Posizionare la LAN in un data center con potenza e piani di networking altamente disponibili.
    • Utilizza un bilanciatore di carico HTTP per diffondere il carico e non riuscire a verificare i singoli errori del server.
    • Ottieni il livello di ridondanza / tempi di attesa previsti per i firewall, i bilanciatori di carico e gli interruttori.
    • Avere una strategia di comunicazione in atto per i guasti a tutti i datacenter e il guasto occasionale di un server switch / database / altre risorse che non possono essere facilmente rispecchiati.

    Una piccola minoranza di siti web utilizza strutture multi-datacenter, con "geo-bilanciamento" 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 sisthemes di monitoraggio hanno rilevato interruzioni, problemi di connettività o server sovraccarichi. Quando vedi la velocità con cui funziona e i volumi del traffico reale che possono essere spostati con facilità – non si guarderà mai indietro. Io uso Zabbix per il monitoraggio di tutti i miei sisthemes e i grafici visivi che mostrano cosa succede durante una situazione di failover DNS mettere tutti i miei dubbi e la fine. Ci possono essere alcuni ISP là fuori che ignorano TTL e ci sono alcuni utenti ancora là fuori con i vecchi browser – ma quando stai guardando il traffico da milioni di visualizzazioni di pagina per un giorno su 2 posizioni del datacenter e si effettua uno spostamento del traffico DNS – il traffico residuo che viene ignorato da TTL è ridicolo. Il failover DNS è una tecnica solida.

    DNS non è stato progettato per il failover ma è stato progettato con TTL che funziona incredibilmente per i requisiti di failover combinati con un sistema di monitoraggio solido. I TTL possono essere impostati molto brevi. Ho effettivamente utilizzato TTL di 5 secondi in produzione per alleggerire le soluzioni basate su failover DNS veloce. È necessario disporre di server DNS in grado di gestire il carico aggiuntivo e il nome non lo taglierà. Tuttavia, powerdns si adatta alla fattura quando è supportta da database mysql replicati sui server nome ridondanti. È inoltre necessario un sistema di monitoraggio distribuito solido che è ansible affidarsi all'integrazione automatica dei failover. Zabbix funziona per me – posso verificare quasi immediatamente gli interruzioni di più sisthemes distribuiti Zabbix – aggiornare i record di mysql utilizzati da powerdns in volo – e fornire un failover quasi immediato durante le interruzioni e le chiazze di traffico.

    Ma ehi – ho costruito una società che fornisce servizi di failover DNS dopo anni per farlo funzionare per le grandi aziende. Quindi prendi la mia opinione con un granello di sale. Se vuoi vedere alcuni grafici di traffico zabbix di siti di grandi volumi durante un'interruzione – per vedere da solo esattamente come funziona il failover di DNS corretto – mandami un'e-mail io sono più che felice di condividere.

    Il problema con il failover DNS è che in molti casi è inaffidabile. Alcuni ISP ignoreranno i tuoi TTL, non accade immediatamente, anche se rispettano i tuoi TTL e quando il tuo sito ritorna in su, può portre ad una strana stranezza con le sessioni quando la cache DNS di un utente si ritarda e finiranno all'altro server.

    Purtroppo, è praticamente l'unica opzione, a less che non sia abbastanza grande per eseguire il proprio path (esterno).

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

    Comunque,

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

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

    L'utilizzo di più record A non è un trucco del commercio, o una caratteristica concepita dai fornitori di equipaggiamenti di bilanciamento del carico. Per questo motivo il protocollo DNS è stato progettato con il supporto di più record A. Applicazioni quali browser e proxy e server di posta utilizzano quella parte del protocollo DNS.

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

    Grazie,

    Valentino

    PS: mi dispiace per il collegamento interrotto ma, come nuovo utente, non posso submit più di 1

    Ho eseguito il failover di DNS RR su un sito web di produzione moderatamente trafficato, ma di grande rilevanza (in due geografiche) per molti anni.

    Funziona bene, ma ci sono alless tre sottigliezze che ho imparato in modo duro.

    1) I browser avranno failover da un IP non funzionante ad un IP di lavoro dopo 30 secondi (l'ultima volta che ho controllato) se entrambi sono considerati attivi in ​​qualunque DNS memorizzato nella cache è disponibile per i tuoi clienti. Questo è fondamentalmente una buona cosa.

    Ma avere "metà" i tuoi utenti attendere 30 secondi è inaccettabile, quindi probabilmente vuoi aggiornare i tuoi record TTL per essere pochi minuti, non pochi giorni o settimane in modo che in caso di interruzione, puoi rimuovere rapidamente il server in discesa dal tuo DNS. Altri hanno alluso a questo nelle loro risposte.

    2) Se uno dei tuoi nameserver (o una delle due aree geografiche intere) scende in discesa che serve il tuo dominio round-robin e se il primario di essi scende, mi ricordo vagamente che puoi correre in altri problemi che cercano di rimuoverlo distriggersto il nameserver da DNS se non hai impostato anche il valore SOFT / SOAP per il nameserver a un valore sufficientemente basso. Potrei avere i dettagli tecnici errati qui, ma c'è più di una sola impostazione di TTL che devi avere diritto a difendere veramente da singoli punti di fallimento.

    3) Se pubblicate le API web, i servizi REST, ecc., Questi tipi di solito non vengono chiamati dai browser e quindi, a mio avviso, il failover DNS inizia a mostrare difetti reali. Questo può essere il motivo per cui alcuni dicono, come lei ha detto "non è raccomandato". Ecco perché lo dico. In primo luogo, le applicazioni che consumano quegli URL in genere non sono browser, quindi non dispongono delle properties; / logica di failover di 30 secondi di browser comuni. In secondo luogo, se la seconda voce DNS viene chiamata o anche se il DNS viene rieseguito, dipende molto dai dettagli di programmazione a bassa livello delle librerie di networking nei linguaggi di programmazione utilizzati da questi client API / REST, più esattamente come vengono chiamati da l'applicazione client API / REST. (Sotto la copertura, la biblioteca chiama get_addr, e quando? Se le prese appendono o chiudono, l'app riapre nuove prese? C'è una sorta di logica di timeout, etc etc)

    È economico, ben testato e "funziona soprattutto". Così come con la maggior parte delle cose, il tuo chilometraggio può variare.

    Ci sono un gruppo di persone che ci usano (Dyn) per il failover. E 'lo stesso motivo per cui i siti possono fare una pagina di stato quando hanno tempi di inattività (pensiamo a cose come la Fail Whale di Twitter) … o semplicemente reroute il traffico in base ai TTL. Alcune persone potrebbero pensare che il DNS Failover sia ghetto … ma abbiamo seriamente progettato la nostra networking con failover fin dall'inizio … in modo che functionrebbe così come l'hardware. Non sono sicuro di come funziona DME, ma abbiamo 3 dei 17 dei nostri più vicini PoP monitorati dal tuo server dalla posizione più vicina. Quando rileva da due dei tre che è in discesa, semplicemente reroute il traffico verso l'altro IP. L'unico tempo di inattività è per quelli che erano a quello richiesto per il resto di quel intervallo TTL.

    Alcune persone amano usare entrambi i server in una sola volta … e in questo caso può fare qualcosa come un bilanciamento del carico rotatorio … o un bilanciamento del carico basato su geo. Per coloro che veramente preoccupano la performance … il nostro gestore del traffico in tempo reale monitorerà each server … e se uno è più lento … redirect il traffico al più veloce in base a quali IP collegati nei tuoi hostname. Ancora una volta … questo funziona in base ai valori inseriti nel nostro UI / API / Portal.

    Suppongo che il mio punto è … abbiamo progettato dns failover a proposito. Mentre DNS non è stato fatto per il failover quando è stato originariamente creato … la nostra networking DNS è stata progettata per attuarla dal get go. Di solito può essere altrettanto efficace quanto hardware … senza ammortamento o il costo dell'hardware. Spero che non mi fa sentire zoppo per colbind Dyn … ci sono molte altre aziende che lo fanno … sto solo parlando dalla prospettiva del nostro team. Spero che questo ti aiuti…

    L'alternativa è un sistema di failover basato su BGP. Non è facile impostare, ma dovrebbe essere prova a prova di proiettile. Impostare il sito A in una posizione, il sito B in un secondo con indirizzi IP locali, quindi get una class C o un altro block di ip che sono porttili e impostare il reindirizzamento dal IP porttile ai IP locali.

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

    Un'opzione per il failover multi-data center è quello di formare i tuoi utenti. Pubbliciamo ai nostri clienti che forniamo più server in più città e nelle nostre e-mail di iscrizione e includono link diretti a ciascun "server" in modo che gli utenti sappiano se un server è in discesa può utilizzare il collegamento all'altro server.

    Ciò totalmente elimina il problema del failover DNS solo mantenendo i nomi di dominio multipli. Gli utenti che visitano http://www.company.com o company.com e il login vengono indirizzati a server1.company.com o server2.company.com e hanno la scelta di segnalibro di uno di questi se notano che ottengono performance migliori usando uno o l'altro . Se si scende, gli utenti sono addestrati per passare all'altro server.

    Un'altra opzione sarebbe quella di impostare il server di nomi 1 nella posizione A e il nome server 2 nella posizione B, ma impostarli ciascuno in modo che tutti i record A sul traffico di punti NS1 per gli indirizzi IP per la posizione A e su NS2 tutti i record A puntino a IP per posizione B. Impostate quindi i tuoi TTL per un numero molto basso e assicurati che il registro di dominio presso il registratore sia stato configurato per NS1 e NS2. In questo modo, verrà automaticamente caricato l'equilibrio e non riesce se un server o uno di un collegamento ad una posizione scenda.

    Ho usato questo approccio in un modo leggermente diverso. Ho una posizione con due ISP e utilizzi questo metodo per dirigere il traffico su each collegamento. Ora, potrebbe essere un po 'più di manutenzione di quello che sei disposto a fare … ma sono riuscito a creare un semplice software che tira automaticamente i record NS1, aggiorna un indirizzo IP di record per le zone selezionate e spinge quelle zone a NS2.

    Ho utilizzato il bilanciamento e il failover dei siti basati su DNS per gli ultimi dieci anni e ci sono alcuni problemi, ma possono essere mitigati. BGP, anche se superiore in qualche modo non è una soluzione al 100% con una maggiore complessità, probabilmente costi hardware aggiuntivi, tempi di convergenza, ecc …

    Ho trovato che la combinazione di bilanciamento del carico locale (LAN) e GSLB e di cloud based funziona abbastanza bene per chiudere alcune delle problematiche normalmente associate al bilanciamento del carico DNS.

    "e perché state prendendo le tue possibilità usando per la maggior parte degli ambienti di produzione (anche se è meglio di niente)".

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

    Ci sono molti siti di grandi size che utilizzano la buona manipolazione del traffico basato su dns. Sono il tipo di siti che conoscono each ora se le vendite sono spente. Sembra che siano l'ultimo ad essere "prendendo le tue possibilità usando per la maggior parte degli ambienti di produzione". In effetti, hanno esaminato con attenzione le loro opzioni, selezionato la tecnologia e pagato bene per questo. Se avessero pensato che qualcosa fosse meglio, avrebbero lasciato un battito cardiaco. Il fatto che ancora sceglie di rimanere parla di volumi sull'utilizzo del mondo reale.

    Il failover basato su Dns subisce una certa quantità di latenza. Non c'è modo per farlo. Ma è ancora l'unico approccio vitale alla gestione dei failover in uno scenario multi-pop. Come l'unica opzione, è molto più che "meglio di niente".

    Tutte queste risposte hanno una certa validità a loro, ma credo che dipenda in realtà da ciò che stai facendo e da quale è il tuo budget. Qui a CloudfloorDNS, una grande percentuale della nostra attività è DNS e offre non solo DNS veloce, ma basse opzioni TTL e failover DNS. Non saremmo in attività se questo non funzionasse e funzionasse bene.

    Se sei una società multinazionale con un budget illimitato sull'utilizzo, sì, i bilancieri di carico GSLB hardware ei datacenter tier 1 sono grandi, ma il tuo DNS deve ancora essere veloce e solidale. Come molti di voi sanno, il DNS è un aspetto critico di qualsiasi infrastruttura, diversa dal nome del dominio stesso, è il servizio di livello più basso che each altra parte della tua presenza in linea entra. A partire da un registrar di dominio solido, DNS è altrettanto critico quanto non lasciare che il tuo dominio scada. DNS scende, significa che l'integer aspetto online della tua organizzazione è anche in discesa!

    Quando si utilizza il failover DNS, gli altri aspetti critici sono il monitoraggio del server (sempre più posizioni geografiche da controllare e sempre multiple (alless 3) dovrebbero essere controllate per evitare falsi positivi) e gestire correttamente i record DNS un guasto viene rilevato. Bassa TTL e alcune opzioni con il failover possono rendere questo un process senza soluzione di continuità e batte il pazzo fuori di svegliarsi fino a un cercapersone nel mezzo della notte se sei un amministratore di sistema.

    Nel complesso, il failover DNS funziona veramente e può essere molto conveniente. Nella maggior parte dei casi da noi o dalla maggior parte dei gestori DNS gestiti, riceverai DNS Anycast con monitoraggio e failover per una frazione del costo delle opzioni hardware.

    Quindi la vera risposta è sì, funziona, ma è per tutti e per each bilancio? Forse no, ma fino a quando non lo provate e fai i test per te stesso, è difficile ignorare se sei un business di piccole e medie size con un budget IT limitato che vuole il miglior rendimento ansible.

    Se vuoi saperne di più, legga le note di applicazione a

    http://edgedirector.com

    Essi coprono: failover, bilanciamento del carico globale e una serie di argomenti correlati.

    Se l'architettura del backend lo consente, l'opzione migliore è il bilanciamento del carico globale con l'opzione di failover. In questo modo, tutti i server e la width di banda sono in gioco il più ansible. Invece di inserire un server aggiuntivo disponibile sul guasto, questa configuration ritira un server non riuscito dal servizio finché non viene recuperato.

    La breve risposta: funziona, ma bisogna capire le limitazioni.

    Credo che l'idea di failover sia stata destinata al clustering, ma perché potrebbe anche funzionare solo, ha reso ansible operare in una disponibilità di uno a uno.

    Oggi i buoni bilancieri del carico globale che funzionano usando quella tecnica e funzionano abbastanza bene. Controlla ad esempio Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/

    Raccommand che sia A, seleziona un datacenter multihomed nel proprio AS o B, ospita i server dei nomi in una cloud pubblica. È veramente improbabile che EC2, HP o IBM scenderanno. Solo un pensiero. Mentre il DNS funziona come una correzione, è semplicemente solo una correzione a un disegno scadente nella fondazione di networking in questo caso.

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

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.