Se non è raccomandato il failover DNS, che cosa è?

Come una domanda di follow-up alla sua domanda molto popolare: perché il failover DNS non è raccomandato? , Penso che sia stato convenuto che il failover DNS non sia al 100% affidabile a causa della memorizzazione nella cache.

Tuttavia la risposta più alta votata non ha affrontato veramente la soluzione migliore per raggiungere il failover tra due diversi data center. L'unica soluzione presentata era il bilanciamento del carico locale (single data center).

Quindi la mia domanda è semplicemente che cosa è la vera soluzione per superare il failover del data center?

  • Quali sono le opzioni per un sistema HA?
  • Come posso impostare il failover per un singolo server web utilizzando due ISP?
  • Azionamento di errore del sito di Akamai
  • Apache Failover e Load Balancing
  • DRBD + corosync + pacemaker - I server non si connetteranno dopo il failover
  • Come impostare HAProxy con il failover?
  • LVS vs HAProxy, che devo scegliere?
  • Cluster di failover a due nodes con archiviazione interna
  • 3 Solutions collect form web for “Se non è raccomandato il failover DNS, che cosa è?”

    Un integer centro dati dovrà scendere o essere irraggiungibile per applicarlo. Il backup in un altro centro dati verrà quindi raggiunto mediante l'instradamento degli indirizzi IP all'altro centro dati. Ciò avverrebbe attraverso gli annunci di path BGP dal centro dati primario che non vengono più forniti. Saranno quindi utilizzati gli annunci secondari dal centro dati secondario.

    Le imprese più piccole generalmente non sono abbastanza grandi per giustificare la spesa di allocazioni di indirizzi porttili porttili e il proprio numero di sistema autonomo per annunciare con BGP. In questo caso un fornitore avrebbe più posizioni è il modo per andare.

    Dovete essere raggiunti tramite gli indirizzi IP originali o con una modifica dell'indirizzo IP eseguito da DNS. Poiché il DNS non è stato progettato per farlo nei modi necessari a ciò che significa "failover" (gli utenti possono essere fuori dalla portta di alless il tempo che il TTL o il TTL imposto da alcuni server di caching), andare al sito di backup con gli stessi IP sono la soluzione migliore.

    Questo è iniziato come un commento … ma sta diventando troppo a lungo.

    Purtroppo la maggior parte delle risposte alla domanda precedente è sbagliata: assumono che il failover abbia qualcosa a che fare con il TTL. La risposta più votata è SPETTACOLAMENTE sbagliata e in particolare non cita alcuna fonte. Il TTL si applica al record della zona nel suo complesso e non ha niente a che fare con Round Robin.

    Da RFC 1794 (che è tutto su server DNS Round Robin)

    There is no use in handing out information with TTLs of an hour [or less] 

    (IME è più vicino a 3 ore prima di get la propagazione completa).

    Da RFC 1035

     When several RRs of the same type are available for a particular owner name, the resolver should either cache them all or none at all 

    RFC 1034 stabilisce i requisiti per la cache negativa – un metodo per indicare che tutte le richieste devono essere inviate fresche dal server DNS autorevole (nel qual caso il TTL controlla il failover) – nel mio supporto di esperienza per questo varia.

    Poiché qualsiasi failover dovrebbe essere implementato in alto nella pila client, non è probabilmente parte di TCP / IP o DNS – infatti SIP, SMTP, RADIUS e altri protocolli in esecuzione in cima a TCP / IP definiscono come il client dovrebbe lavorare con Round Robin – RFC 2616 (HTTP / 1.1) è notevole nel non citare come dovrebbe comportrsi.

    Tuttavia, nella mia esperienza, each browser e la maggior parte degli altri client HTTP scritti negli ultimi 10 anni controlleranno in modo trasparente ulteriori A RR se la connessione sembra richiedere più tempo di quanto previsto. E non solo io:

    I tempi di failover variano per implementazione ma sono nella regione di secondi. Non è una soluzione ideale perché (a causa dei limiti di DNS) la pubblicazione del nodo fallito prende il DNS TTL – nel frattempo si deve fare affidamento sul lato client di rilevamento.

    Round-Robin non sostituisce altri meccanismi HA all'interno di un sito. Ma lo completano (i ragazzi che hanno scritto HAProxy consigliano di usare un paio di installazioni accessibili tramite DNS rotondo). È il miglior meccanismo supportto per l'implementazione di HA in più siti: infatti, per quanto posso determinare, è l'unico meccanismo supportto per il failover disponibile sui client standard.

    L'approccio più semplice alla ridondanza DC duplice sarebbe una VPN L2 MPLS tra i due siti, insieme a mantenere le sessioni BGP tra i due.

    È essenzialmente quindi ansible avere un IP fisico per server e un IP virtuale che galleggia tra i due (HSRP / VRRP / CARP ecc.). Il tuo DNS sarebbe stato indirizzato a questo particolare IP e diretto di conseguenza.

    La prossima considerazione sarebbe il cervello diviso – ma questa è un'altra domanda per un'altra volta.

    Juniper ha scritto un buon white paper sulla gestione DC dual con MPLS, puoi afferrare il PDF qui http://www.juniper.net/us/en/local/pdf/whitepapers/2000407-en.pdf

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