Alta disponibilità multi-sito

Abbiamo un'applicazione SaaS di cui abbiamo bisogno per essere altamente disponibili. Abbiamo già un cluster di failover Hyper-V costoso e ben gestito, ma oggi il data center in cui ospitiamo quel cluster ha avuto un'interruzione di corrente di cinque ore che ci ha messo completamente offline. Quindi ora ci chiediamo se un approccio migliore potrebbe essere quello di utilizzare i server in due data center separati. Supponendo di avere tutta la replica dei file back-end e la replica dei dati funzionanti tra questi due siti, ci chiediamo come gestire il routing front-end - non c'è da meravigliarsi di come affrontiamo il problema, finiamo sempre col bilanciamento del carico essendo un singolo punto di errore.

Quindi la domanda è ... come possiamo impostare il bilanciamento del carico tra due siti di hosting in modo tale che il bilanciamento del carico non sia l'unico punto di errore? Esiste un modo per utilizzare due bilanciatori di carico separati, uno in ciascun sito? Dovremmo prendere in considerazione il DNS round robin?

Per farlo correttamente, devi avere:

• Due istanze separate in due datacenter (come hai già determinato)
• Sincronizzazione tra i due datacenter (come già determinato)
• Un modo di reindirizzare i client dall'uno all'altro in caso di guasto

Esistono due modi comuni per farlo. Uno semplice, uno ... no.

DNS

Round-Robin DNS non è proprio quello che vuoi, perché è probabile che tutte le richieste vengano indirizzate al controller di dominio primario e il secondo controller di dominio viene utilizzato solo durante i tempi di inattività del primo.

Quello che puoi fare è impostare un TTL molto basso sul tuo DNS (diciamo, 30 secondi o 5 minuti), il che significa che se il controller di dominio si interrompe, aggiorni il DNS e in circa 5 minuti, tutto i tuoi clienti indicheranno l'altro tuo controller di dominio.

Ciò significa che, poiché i due controller di dominio avranno layout IP diversi, è necessario adattarsi a ciò nella configurazione del datacenter.

BGP

Fondamentalmente, se stai ponendo questa domanda, allora questo è fuori dalla tua portata. In breve, i tuoi indirizzi IP rimangono gli stessi, ma vengono "spostati" da un datacenter all'altro. Ciò comporta router costosi, intervalli IP costosi e abbonamenti costosi al registro locale per numeri AS e intervalli IP.

I router BGP smettono di pubblicizzare il tuo centro dati principale e iniziano la pubblicità nel tuo centro dati secondario. Quindi Internet si sposta intorno al datacenter offline e invia il traffico al nuovo controller di dominio.

Se sei virtualizzato con ESXi e vSphere, VMWare ha un prodotto abbastanza buono che abbiamo provato una volta chiamato VMWare Site Recovery Manager , che praticamente fa tutto per te. Mantiene sincronizzate le configurazioni VM e le accende sul 2 ° sito quando il 1 ° sito diventa offline. Tuttavia, è un sacco di soldi.

È necessario bilanciare il carico dei bilanciatori del carico.

È possibile fare questo con DNS round-robin, ma questo approccio ha molti problemi. Non puoi controllare i client che memorizzano nella cache voci più lunghe di quanto desideri e non puoi forzare il traffico verso una determinata posizione.

Puoi farlo anche con Global Server Load Balancing (GSLB). Questo è un modo più avanzato di sfruttare il DNS per darti visibilità su più data center da Internet. In breve, si imposta un meccanismo per suddividere il traffico in sezioni e utilizzare DNS per selezionare una sezione. Usiamo un hash del resolver DNS configurato per fare ricerche per il client. Altre persone usano la geografia per instradare al data center "più vicino". Dovrai aggiungere un meccanismo per rimuovere rapidamente un IP dal GSLB in caso di guasto di un singolo punto di errore per quel data center o cluster.

http://www.eukhost.com/web-hosting/kb/global-server-load-balancing/

Infine, alcune persone davvero avanzate affrontano questo problema con Anycast DNS. Questo tenta di nuovo di sfruttare l'approccio del data center "più vicino". Anasticare il vostro servizio significa che dovrete eliminare ogni "stato d'animo". Questo può rivelarsi difficile.

Anni dopo ... ma per coloro che ancora cercano queste sembrano essere le soluzioni più convenienti / semplici per il failover DNS:

• DynDNS
• DNS reso facile
• Amazon Route 53