Panoramica GSLB #

Al giorno d'oggi, l'alta disponibilità di servizi IT è un must e questo è il motivo per cui aziende e organizzazioni sviluppano sistemi informatici distribuiti in tutto il mondo e servizi host in più di un Data Center, in quanto offre i seguenti vantaggi:

Tolleranza ai guasti: quando il servizio ospitato nel data center fallisce, il servizio continua in uno degli altri siti disponibili.
Ripristino automatico del data center: quando un data center non funziona, il servizio viene reindirizzato automaticamente a qualsiasi altro centro dati disponibile.
Bilancio del carico: il traffico potrebbe essere ottimizzato distribuendo il carico tra tutti i siti disponibili migliorando la latenza e rendendo più rapida la consegna del servizio.
Latenza migliorata: il traffico dell'applicazione client è direttamente con il server reale, non è necessario passare tutti i dati dell'applicazione tramite il servizio di bilanciamento del carico.

L'adozione e l'implementazione dei servizi IT nel cloud richiede che un metodo basato su WAN sia l'opzione migliore per fornire soluzioni di disponibilità elevata geolocalizzate. Questo è ciò che chiamiamo Servizio globale Bilanciamento del carico or GSLB.

Quando usare GSLB #

Si consiglia di utilizzare il servizio GSLB per i seguenti casi d'uso:

Aziende che ospitano i loro servizi in più di un data center tramite WAN.
Aziende che richiedono di creare un'elevata disponibilità di servizi o data center.
Provider di servizi Internet per creare servizi di bilanciamento del carico in entrata per essere utilizzati dai propri utenti.

Sicuramente, quando è necessario condividere utenti e traffico tra server in tutto il mondo senza punti di errore, GSLB è la soluzione giusta.

Come funziona GSLB #

GSLB è un meccanismo di bilanciamento del carico su DNS protocollo, è veloce e affidabile perché utilizza UDP protocollo e la risposta del cliente è quasi in tempo reale.

Ad esempio, in una richiesta DNS comune www.zvnlb.net, un client invia la risoluzione della richiesta DNS ai server DNS configurati locali (ad esempio 8.8.8.8 and 8.8.4.4 ) e quindi il sistema client seleziona casualmente uno dei server per fare contro la richiesta e inviare la query.

Il server DNS selezionato riceve la richiesta dal client (ad esempio, qual è l'indirizzo IP di www.zvnlb.net? ) e i server DNS configurati localmente cercano di individuare chi è responsabile della risoluzione della zona DNS zvnlb.net.

Il DNS utilizzato dal client, 8.8.8.8 or 8.8.4.4 in questo caso, lo rileva ns1.zvnlb.net and ns2.zvnlb.net sono responsabili delle risoluzioni di zona per zvnlb.net quindi inviano la query DNS ricevuta dal client (ad esempio, qual è l'indirizzo IP di www.zvnlb.net? ) a uno di loro.

Uno dei server dei nomi ns1.zvnlb.net or ns2.zvnlb.net riceve la query DNS da 8.8.8.8 or 8.8.4.4 e quindi, il server dei nomi che riceve la richiesta, controlla i server disponibili per l'host www.zvnlb.net e risponderà alla query DNS con l'elenco dei server delle applicazioni disponibili per servire l'applicazione reale per l'host www.zvnlb.net, quindi questa informazione sarà finalmente ricevuta dal cliente.

Ora il client selezionerà casualmente uno dei server dell'applicazione dall'elenco ricevuto nella query DNS e invierà direttamente la richiesta all'applicazione http://www.zvnlb.net.

I server dei nomi ns1.zvnlb.net (nel nostro esempio, situato a Francoforte) e ns2.zvnlb.net (nel nostro esempio, situato a Toronto) stanno controllando costantemente lo stato di salute della reale applicazione dell'host www.zvnlb.net (192.235.113.3 and 194.23.52.21 nel nostro caso). Se ns1.zvnlb.net or ns2.zvnlb.net rileva qualsiasi problema verificando lo stato di salute di alcuni dei server reali, quindi il server non disponibile verrà disattivato per un certo periodo di tempo e il suo indirizzo IP non verrà elencato nelle query DNS finché non sarà nuovamente disponibile.

Lo schema seguente mostra il traffico DNS descritto con le funzionalità GSLB.

Configurazione di GSLB per il ripristino di emergenza dei data center #

Questa configurazione è consigliata per servizi che richiedono un'elevata disponibilità di Data Center per il disaster recovery, quindi se tutti i servizi di una determinata azienda si trovano in un data center e tale data center non riesce, il sistema trasferirà tutti i servizi interessati in un altro data center disponibile .

Si prega di seguire questo esempio reale della configurazione GSLB per costruire un data center active-passive per il disaster recovery.

Abbiamo schierato due RELIANOID Bilanciatori di carico su due data center in sedi diverse, Francoforte 159.89.7.124 e Toronto 159.203.12.35 e abbiamo un servizio web che risponde all'host DNS www.zvnlb.net, configurato in Data Center 1 and Data Center 2. Il design di questa architettura consentirà di inviare tutto il traffico dei client a Data Center 1 ma se fallisce, allora reindirizza i client a Data Center 2.

Per ottenere questa configurazione, seguire la procedura seguente.

Connettiti al RELIANOID pannello web nel Data Center 1 (Francoforte per il nostro caso), fare clic sul menu principale GSLB modulo e creare un nuovo Fattoria, nel nostro esempio verrà chiamato DNS1-Francoforte nella porta virtuale 53.

Una volta creata la fattoria, modificala e vai alla scheda Zone e creare la zona DNS che verrà gestita dal modulo GSLB, in questo caso zvnlb.net, Come segue:

Una volta creata questa zona, effettuare la prima configurazione come mostrato di seguito:

Si noti che ns1 and ns2 sono i Name Server responsabili delle risoluzioni DNS per la zona zvnlb.net (nel nostro caso, un servizio GSLB a Francoforte e un altro a Toronto).

Quindi, connettiti al RELIANOID pannello web nel Data Center 2, nel menu principale selezionare GSLB e creare un nuovo Fattoria, nel nostro caso verrà chiamato DNS2-Toronto nella porta virtuale 53.

Modifica la nuova farm GSLB e vai alla scheda Zone, crea qui la zona DNS che verrà gestita da questo servizio GSLB per zvnlb.net come segue:

Una volta creata questa nuova zona, effettuare la prima configurazione come segue:

Come nel caso del GSLB nel Data Center 1, i server dei nomi n1 and n2 punterà ai servizi GSLB in entrambi Data Center 1 and Data Center 2, Rispettivamente.

Quindi fare clic sulla scheda Servizi e creare un nuovo servizio, per esempio webpriority:

Seleziona il Algoritmo opzione Priorità: connessioni sempre al massimo disponibile e configurare il servizio come segue:

Riavvia la farm per applicare le modifiche. È necessario applicare la stessa configurazione del servizio GSLB in entrambi i data center.

Si noti che se Guardiano della fattoria non è configurato per applicare alcun controllo dello stato, il servizio GSLB utilizza un valore predefinito check_tcp alla porta TCP definita nel campo health check nella configurazione del servizio.

Per abilitare il nuovo servizio, vai alla zona creata (zvnlb.net nel nostro caso) e creare un nuovo Gestione. Quindi crealo selezionando il nuovo Servizio come mostrato di seguito.

Infine, salva le modifiche. È necessario applicare questa configurazione in entrambi i Data Center.

A questo punto, l'host www.zvnlb.net è gestito dal modulo GSLB in Priorità modalità, quindi tutto il traffico verrà inviato al Data Center 1 e poi, se fallisce, il traffico verrà reindirizzato all'altro disponibile Data Center 2.

Il TTL è stato configurato su 5, è il tipo di data di scadenza che viene inserito in un record DNS. Il TTL serve a dire al server ricorsivo o al resolver locale per quanto tempo dovrebbe conservare tale record nella sua cache. Quindi un valore più basso configurato più velocemente le modifiche vengono rilevate.

Applicando questo metodo potremmo aggiungere tutti i data center necessari includendo nuovi Name Server con il servizio GSLB.

La seguente richiesta DNS mostra la configurazione di Nameservers per zvnlb.net e la risoluzione DNS per l'host www.zvnlb.net.

utente@client:# host -t ns zvnlb.net Server dei nomi zvnlb.net ns2.zvnlb.net. Server dei nomi zvnlb.net ns1.zvnlb.net.

Entrambi i server dei nomi utilizzano gli indirizzi IP virtuali configurati nelle farm GSLB.

Ora, usa i tuoi attuali server DNS per risolvere un host (per esempio www) in questa zona:

user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Indirizzo: 8.8.8.8#53 Risposta non autorevole: Nome: www.zvnlb.net Indirizzo: 188.166.230.211

Come viene mostrato, attualmente l'host 188.166.230.211 è il nodo dell'applicazione reale attivo nel Data Center 1. Non appena l'host non è raggiungibile (ad esempio, il servizio http in 188.166.230.211 è inattivo) la risoluzione DNS cambierà come mostrato di seguito.

user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Indirizzo: 8.8.8.8#53 Risposta non autorevole: Nome: www.zvnlb.net Indirizzo: 139.59.186.84

Non appena il server dell'applicazione si guasta, la risoluzione DNS cambierà l'host in Data Center 2. Una volta che l'host nel Data Center 1 è attivo il fail-back verrà applicato automaticamente.

Configurazione di GSLB per data center active-active #

L'elevata disponibilità con la priorità della modalità è una buona opzione per un sistema di Disaster Recovery ma il Data Center di backup utilizzato per il ripristino non ha un utilizzo eccessivo, quindi di solito è più efficiente bilanciare il carico di tutto il traffico tra i dati disponibili centri.

Per tali casi, si prega di utilizzare il metodo di condivisione per il servizio GSLB chiamato Round Robin Load Balancing come mostrato nell'esempio per il nuovo servizio chiamato sito web:

Ora aggiungilo nella zona zvnlb.net e cambiare la configurazione della risorsa www come segue:

Salvare le modifiche e riavviare la farm, se richiesto.

Per testarlo, prova a risolvere l'host www.zvnlb.net e l'output apparirà come mostrato:

user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Indirizzo: 8.8.8.8#53 Risposta non autorevole: Nome: www.zvnlb.net Indirizzo: 188.166.230.211 Nome: www.zvnlb.net Indirizzo: 139.59.186.84

Si noti che il resolver DNS restituisce entrambi i server delle applicazioni anziché uno come il caso Disaster Recovery.

Una volta che l'host ha un errore, la risoluzione DNS cambierà automaticamente. Vedi sotto cosa succede.

root@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Indirizzo: 8.8.8.8#53 Risposta non autorevole: Nome: www.zvnlb.net Indirizzo: 139.59.186.84

Il server delle applicazioni non disponibile è disattivato dall'elenco delle risposte DNS.

Appena l'ospite 188.166.230.211 è nuovamente disponibile, sarà incluso nella risoluzione DNS.

Delega di una zona in RELIANOID Servizio GSLB #

Nel caso di una zona pubblica (per esempio zvnlb.net) che fornisce un servizio GSLB come risolutore di server dei nomi che deve essere riconosciuto dai server DNS pubblici per tale dominio, quindi è necessario registrare l'indirizzo IP pubblico utilizzato dal servizio GSLB nel registrar del tuo dominio (come NameCheap, Goddady o altri) . Il seguente collegamento spiega come registrare gli IP GSLB come NameServer in una procedura di registrazione del dominio.

Registrare un host come NameServer

Seguendo la procedura indicata devi registrarti ns1.zvnlb.net and ns2.zvnlb.net con gli IP indicati.

Creazione di una sottozona dedicata per GSLB #

Nel caso in cui non fosse possibile delegare la risoluzione DNS al servizio GSLB di RELIANOID, la configurazione spiegata di seguito potrebbe essere eseguita. Il seguente esempio mostra come costruire un sottozona per zvnlb.net che punta ai NameServer di questa nuova sottozona nel servizio GSLB.

Nodo 1 (per esempio ns1.zvnlb.net con IP 162.243.5.109) e Nodo 2 (per esempio ns2.zvnlb.net con IP 178.62.233.104) sono configurati i server dei nomi e offrono servizi di risoluzione DNS per la zona zvnlb.net, questa zona è sotto un servizio DNS pubblico Bind9 e vogliamo offrire funzionalità GSLB per alcuni host della nostra infrastruttura, quindi abbiamo deciso di creare la sottozona DNS cluster.zvnlb.net e configurare le farm 2 GSLB come DNS Nameservers per questo scopo.

Abbiamo creato la sottozona per il nostro dominio cluster.zvnlb.net nei nostri server DNS Bind9 come segue:

Ora segui la sezione Delega di una zona in RELIANOID Servizio GSLB In modo da mantenere 159.89.7.124 and 159.203.12.35 nel nostro esempio come nameserver riconosciuti per la zona cluster.zvnlb.net dai server DNS pubblici.

Quindi, puoi applicare la configurazione come è spiegato per il dominio zvnlb.net nella sezione sopra Configurazione di GSLB per il ripristino di emergenza dei data center.

Indicare un host nel nostro DNS riferito a un servizio GSLB #

Nelle sezioni precedenti abbiamo creato un host chiamato www.zvnlb.net bilanciamento del carico in modalità priorità e round robin, quindi possiamo riutilizzare questa configurazione per offrire funzionalità GSLB a un altro server dei nomi DNS che non supporta questa funzionalità per impostazione predefinita.

Per ottenere questa configurazione, dobbiamo solo creare un nuovo Gestione nella zona DNS che non supporta le opzioni GSLB (ad esempio relianoid.io è gestito da Bind9) come a Nome canonico or CNAME come mostrato di seguito:

Una volta applicata la modifica, www.relianoid.io punterà a www.zvnlb.net, ma se la risoluzione dell'host www.zvnlb.net cambia poi automaticamente www.relianoid.io cambierà pure.

Si noti che questo esempio viene eseguito in un server DNS Bind9, ma i nomi Canonical o CNAMES sono configurazioni host DNS supportate da qualsiasi implementazione del servizio server DNS.

Questa semplice spiegazione mostra che un servizio GSLB può essere utilizzato anche se il nostro attuale servizio DNS non offre funzionalità GSLB, semplicemente inoltrando la risoluzione dell'host specificato in una zona non GSLB al servizio GSLB in RELIANOID Bilanciatore del carico.