LBL DNS Global Load Balancer

Back

LBL®Global Distributed Gateway Global Load Balancer (GLB) è uno strumento che permette di utilizzare i DNS per poterli gestire in maniera dinamica sfruttandone al massimo le caratteristiche ed applicandole per la gestione di indirizzamento e bilanciamento globale con funzionalità di alta affidabilità distribuita.

Questo documento descrive una architettura di riferimento per installare e configurare LBL®GLB in un ambiente DNS autoritativo e distribuito su due siti.

Ambiente di riferimento

L’ambiente di riferimento prende in considerazione due siti che implementano DNS primari e secondari.

I DNS ns1.foo.com, ns2.foo.com, ns3.foo.com e ns4.foo.com sono stati registrati con i seguenti indirizzi:

ns1.foo.com 10.41.11.22

ns2.foo.com 10.41.11.23

ns3.foo.com 10.43.12.24

ns4.foo.com 10.43.12.25


E’ importante notare che il DNS registrar richiede per indirizzo primario e secondario due classi di indirizzi differenti per garantire un minimo di continuità operativa.

Implementazione


Una possibile implementazione di architetture dinamiche di risoluzione della risoluzione dei nomi, prevede l’introduzione di sistemi LBL®GLB in grado di filtrare le richieste interponendosi tra a richiesta ed il DNS.

Questa soluzione semplifica diverse situazioni rendendo altamente disponibili due indirizzi su differenti subnet e bilanciando le richieste su differenti DNS.

Fino a questo momento non sono state apportate modifiche alle configurazioni DNS. Sono stati aggiunti solamente dei servizi che espongono due differenti indirizzi e che utilizzano i DNS per la loro risoluzione.

La situazione risultante, senza modifiche al DNS registrar, risulta essere quindi la seguente:

ns11.foo.com 10.41.11.30

ns1.foo.com 10.41.11.22

ns2.foo.com 10.41.11.23

ns33.foo.com 10.43.12.30

ns3.foo.com 10.43.12.24


ns4.foo.com 10.43.12.25

Dell’infrastruttura esistente al momento non è stata apportata nessuna modifica ma sarà possibile provare tutte le funzionalità impostando ns11.foo.com e ns33.foo.com come DNS nei client deputati al test.

Una volta eseguiti i test è possibile modificare nel DNS registrar le attribuzioni dei due DNS di riferimento spostando l’indirizzo ed il nome nei GLB:

ns11.foo.com 10.41.11.30

ns1.foo.com 10.41.11.22

ns2.foo.com 10.41.11.23

ns33.foo.com 10.43.12.30

ns3.foo.com 10.43.12.24


ns4.foo.com 10.43.12.25

Disaster Recovery

In architetture di Disaster Recovery è bene suddividere gli argomenti in due temi specifici, Alta affidabilità del servizio DNS e gestione dei DNS.

L’alta affidabilità del servizio DNS è garantita sicuramente dalla duplice risoluzione dei due indirizzi DNS, in questo caso VIP NS11 e VIP NS33. Nel caso specifico, in caso di indisponibilità totale del sito principale è possibile accedere ai servizi DNS attraverso il DNS secondario ora rappresentato da VIP NS33.

Questa situazione è comunque una situazione non utilizzabile nel tempo in quanto il sito secondario non potrebbe effettuare modifiche alle risoluzioni degli indirizzi limitando le possibilità di gestione.

Disaster Recovery con DNS Multimaster

Un primo scenario di risoluzione del problema della gestibilità dei siti è possibile attraverso l’utilizzo di un sistema DNS Multimaster.

L’allineamento delle zone dei due master in questo caso viene garantito da sistemi di ridondanza in dipendenza del tipo di DNS che si sta utilizzando. Se si sta utilizzando la piattaforma LBL®GLB è possibile mantenere allineate le zone BIND attraverso il sistema di clustering LBL®GLB.

Un eventuale indisponibilità del sito principale non si ripercuote sull’operatività generale, di funzionamento e di gestione del sito secondario che sarebbe comunque completamente autonomo anche in caso di unico superstite. Nel caso specifico, in caso di indisponibilità totale del sito principale è possibile accedere ai servizi DNS attraverso il DNS secondario ora rappresentato da VIP NS33 ed apportare modifiche al DNS primario ns3.foo.com.

Disaster Recovery con DNS Primary in replica

Un altro scenario di Disaster Recovery possibile è implementabile attraverso la replica del DNS principale nel sito secondario che in questo caso può avere un unico DNS secondario.

La mappa dell’architettura diventa la seguente. Il DNS primario ns1.foo.com viene replicato attraverso strumenti di replica storage e nel sito secondario è spento.

ns11.foo.com 10.41.11.30

ns1.foo.com 10.41.11.22

ns2.foo.com 10.41.11.23

ns33.foo.com 10.43.12.30

ns4.foo.com 10.43.12.25

In caso di avaria del sito principale il sito secondario sarà immediatamente disponibile e con l’avvio del DNS Primario replicato nel sito secondario sarà possibile anche effettuare la gestione di lungo periodo.

In questo caso, anteporre LBL®GLB permette di avere comunque un indirizzamento esterno differente dall’indirizzamento interno riutilizzando gli indirizzi del DNS primario. In caso di zone geografiche differenti ci sarebbero innumerevoli problemi di realizzazione.

La situazione con il sito primario in avaria sarebbe la presente con il vantaggio che l’indirizzo con subnet 10.41.11 non causerebbe problemi di instradamento globale se posizionato in zone differenti perché posizionato nel backend:

ns33.foo.com 10.43.12.30

ns1.foo.com 10.41.11.22


ns4.foo.com 10.43.12.25

Disaster Recovery con DNS GLB Cloud

Per offrire una altissima disponibilità dei servizi DNS è possibile oggi dislocare le componenti LBL®GLB direttamente in cloud su zone geografiche differenziate.

La soluzione garantisce una disponibilità dei due DNS indipendentemente dalla disponibilità dei siti offrendo una garanzia elevatissima di affidabilità.

ns111.foo.com 12.61.9.30

ns1.foo.com 10.41.11.22

ns2.foo.com 10.41.11.23

ns333.foo.com 21.33.8.30

ns3.foo.com 10.43.12.24


ns4.foo.com 10.43.12.25

In caso di avaria del sito principale le richieste di risoluzione sarebbero comunque garantite dalle componenti in cloud.

Disaster Recovery con estensione Layer 2

Nel caso i due datacenter appartengano alla stessa dorsale permettendo la migrazione di indirizzi da un datacenter ad un altro è possibile gestire, sia nella situazione DNS multimaster che in replica di DNS master, la migrazione degli indirizzi da un datacenter ad un altro attraverso l’attribuzione dei VIP LBL®GLB in Mutual fail over.

In questo caso analizzeremo le configurazioni mutual fail-over delle componenti LBL®GLB che contengono la possibilità di attribuirsi, in caso di avaria o manutenzione programmata, l’indirizzo VIP su entrambi i siti utilizzando le risorse DNS superstiti. Per semplicità espositiva non ci addentreremo sulle caratteristiche di designazione delle risorse FAR e NEAR della componente LBL®GLB dando per scontato tale caratteristica o approfondendo in fase implementativa essendo molto semplice da implementare.


I sistemi LBL®GLB in questo caso avranno la possibilità di eseguire il fail over degli indirizzi mutualmente dal sito 1 al sito 2 in maniera automatica o manuale presentando, in caso di avaria entrambi gli indirizzi

In caso di avaria la coppia di LBL®GLB nel sito di DR espongono, anche su interfacce fisiche differenti, i due indirizzi IP.

Considerazioni

Le architetture esposte nei paragrafi precedenti servono come esempio per orientare le scelte delle politiche architetturali di alta affidabilità senza per altro essere le uniche soluzioni possibili. Si rimanda a studi architetturali specifici che saranno approfonditi caso per caso in base alle infrastrutture esistenti. In ogni caso gli scenari proposti sono tuttavia da ritenersi un riferimento in situazioni di alta disponibilità geografica ed essere utilizzati come base di partenza per il disegno ottimale dell’infrastruttura che puntualmente si sta analizzando.

Considerazioni rispetto a filtri, firewall, DoS/DDoS mitigation, analisi traffico DNS sono funzionalità degli strumenti citati nei capitoli e non sono stati approfonditi in questo documento.

Sei interessato alle nostre soluzioni?