Domanda di installazione globale ad alta disponibilità

Possiedo e gestisco visualwebsiteoptimizer.com /. L'app fornisce uno snippet di codice che i miei clienti inseriscono nei loro siti Web per tracciare determinate metriche. Poiché lo snippet di codice è JavaScript esterno (nella parte superiore del codice del sito), prima di mostrare il sito Web di un cliente, il browser di un visitatore contatta il nostro server delle app. Nel caso in cui il nostro server delle applicazioni non funzioni, il browser continuerà a provare a stabilire la connessione prima che scada (in genere 60 secondi). Come puoi immaginare, non possiamo permetterci di disattivare il nostro server di app in qualsiasi scenario perché influirà negativamente sull'esperienza non solo dei visitatori del nostro sito Web ma anche dei visitatori del sito Web dei nostri clienti!

Attualmente stiamo utilizzando il meccanismo di failover DNS con un server di backup situato in un centro dati diverso (in realtà un continente diverso). Cioè, monitoriamo il nostro server delle app da 3 posizioni separate e non appena viene rilevato che è inattivo, cambiamo un record per puntare all'IP del server di backup. Funziona bene per la maggior parte dei browser (dato che il nostro TTL è di 2 minuti) ma IE memorizza nella cache il DNS per 30 minuti, il che potrebbe essere un affare mortale. Vedi questo recente post del nostro visualwebsiteoptimizer.com/split-testing-blog/ma maximum-theoretical-downtime-for-a-website-30-minutes/

Quindi, che tipo di installazione possiamo usare per garantire un failover quasi istantaneo nel caso in cui il data center delle app subisca gravi interruzioni? Ho letto qui www.tenereillo.com/GSLBPageOfShame.htm che avere più record A è una soluzione ma non possiamo permetterci la sincronizzazione della sessione (ancora). Un'altra strategia che stiamo esplorando è avere due record A, uno che punta al server delle app e il secondo a un proxy inverso (situato in un centro dati diverso) che risolve il server delle app principale se è attivo e il server di backup se è attivo. Pensi che questa strategia sia ragionevole?

Solo per essere sicuri delle nostre priorità, possiamo permetterci di mantenere il nostro sito Web o app inattivo, ma non possiamo rallentare il sito Web dei clienti a causa dei nostri tempi di inattività. Quindi, nel caso in cui i nostri server di app siano inattivi, non intendiamo rispondere con la risposta predefinita dell'applicazione. Anche una risposta vuota sarà sufficiente, abbiamo solo bisogno che il browser completi quella connessione HTTP (e nient'altro).

Riferimento: ho letto questo thread che è stato utile serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure

La tua situazione è abbastanza simile alla nostra. Vogliamo data center divisi e failover del tipo di livello di rete.

Se hai il budget per farlo, allora quello che vuoi sono due data center, più passaggi IP a ciascuno, una coppia di router periferici che eseguono sessioni BGP ai tuoi fornitori di transito, pubblicizzando i tuoi indirizzi IP su Internet globale.

Questo è l'unico modo per eseguire il vero failover. Quando i router notano che il percorso verso i tuoi server non è più valido (cosa che puoi fare in diversi modi), allora smettono di pubblicizzare quel percorso e il traffico va sull'altro sito.

Il problema è che per un paio di router perimetrali, inizialmente stai cercando un costo abbastanza alto per ottenere questa configurazione.
Quindi devi impostare la rete dietro tutto questo e potresti voler considerare una sorta di connettività Layer2 tra i tuoi siti come un collegamento punto a punto in modo da avere la possibilità di instradare il traffico in entrata a un datacenter, direttamente all'altro in caso di guasto parziale del tuo sito principale.

Best practice BGP multihomed / multi-location e il modo migliore per migliorare la resilienza? sono domande che ho posto su problemi simili.

La pagina della vergogna GSLB solleva alcuni punti importanti, motivo per cui, personalmente, non avrei mai scelto volontariamente un GSLB per fare il lavoro del routing BGP.

Dovresti anche esaminare gli altri punti di errore della tua rete. Assicurarsi che tutti i server dispongano di 2 NIC (connesse a 2 switch separati), 2 PSU e che il servizio sia composto da più server back-end, come coppie ridondanti o cluster con bilanciamento del carico.

Fondamentalmente, il "bilanciamento del carico" DNS tramite più record A è semplicemente "condivisione del carico" poiché il server DNS non ha idea di quanto carico sia presente su ciascun server. Questo è economico (gratuito).

Un servizio GSLB ha un'idea di quanto siano caricati i server e della loro disponibilità e fornisce una maggiore resistenza agli errori, ma è ancora afflitto dai problemi relativi alla memorizzazione nella cache e al pegging del DNS. Questo è meno economico, ma leggermente migliore.

Una rete instradata BGP, supportata da una solida infrastruttura, è IMHO, l'unico modo per garantire veramente un buon tempo di attività. È possibile risparmiare un po 'di denaro utilizzando i route server anziché i router Cisco / Juniper / etc, ma alla fine è necessario gestire questi server con molta attenzione. Questa non è affatto un'opzione economica, o qualcosa da intraprendere alla leggera, ma è una soluzione molto gratificante e ti porta in Internet come fornitore, piuttosto che come semplice consumatore.

OK, questo è stato chiesto poco fa, ma ora lo vedo per la prima volta.

lo snippet di codice è JavaScript esterno (nella parte superiore del codice del sito), prima di mostrare il sito Web di un cliente, il browser di un visitatore contatta il nostro server delle app.

Dovresti:

1. Posiziona il tuo file Javascript su una buona rete di distribuzione dei contenuti professionale, ovvero acquista una porzione HTTP (S) a disponibilità elevata del Javascript da qualcuno che ha già quella competenza.
2. Programma il tuo Javascript in modo che ci sia un buon stato di fallback, cioè se il tuo server delle applicazioni non risponde rapidamente, l'utente finale vede una pagina normale, non modificata.

Fare qualsiasi altra cosa è irresponsabile, davvero. Presumo che tu l'abbia già messo in atto.

Si dovrebbe non basare il vostro servizio sul BGP trucchi di routing se non si ha o di ottenere il know-how per farlo. Gli scenari di routing BGP complessi sono decisamente non banali da implementare; non farlo tu stesso se non hai le conoscenze specifiche del dominio.

La tua stessa domanda è un po 'confusa. L'analisi di come creare un servizio a disponibilità elevata inizia con i dati dell'applicazione , perché questo è il tuo "stato". Le parti senza stato sono facili da rendere altamente disponibili, le parti a stato pieno non lo sono. Quindi, invece di concentrarti sui tuoi server e DNS, guarda dove l'applicazione mantiene lo stato . Inizia ottimizzando lì e possibilmente chiedendo consigli sugli algoritmi su Stack Overflow. Potresti implementare una nozione di transazioni e tentativi di smart server nel tuo file Javascript fx?

In realtà, ciò che desideri potrebbe essere aggiornato per aiutare le tue attività di split test anche se combini geodn e failover DNS.

L'invio del gruppo A all'ip 1 e del gruppo B all'ip 2, anche se si trovavano sullo stesso server, consente di separare i gruppi di test. Il gruppo A e il gruppo B provengono da diverse regioni geografiche. Per essere onesti, il giorno / settimana / mese successivo, capovolgi i gruppi per assicurarti di consentire le differenze geografiche. Solo per essere rigoroso nella tua metodologia.

Il servizio geodns / failover dns su http://edgedirector.com può farlo

divulgazione: sono associato al link sopra, inciampato qui alla ricerca di un articolo sull'applicazione di stupidi trucchi DNS per dividere i test.