GSLB Oversigt

I dag er den høje tilgængelighed af it-tjenester et must, og det er grunden til, at virksomheder og organisationer udvikler computersystemer fordelt over hele verden og værtsservice i mere end et datacenter, da det giver følgende fordele:

Fejltolerance: Når den hostede tjeneste i datacenteret fejler, fortsætter tjenesten på nogen af ​​de andre tilgængelige websteder.
Automatisk datacentergendannelse: Når et datacenter mislykkes, omdirigeres tjenesten automatisk til ethvert andet tilgængeligt datacenter.
Load Balancing: trafikken kan optimeres ved at distribuere belastningen blandt alle de tilgængelige websteder, hvilket forbedrer ventetiden og gør serviceleverancen hurtigere.
Forbedret latens: Klientprogrammets trafik er direkte med den reelle server, det er ikke nødvendigt at overføre alle applikationsdata gennem belastningsbalanceren.

Vedtagelsen og implementeringen af ​​it-tjenester i Cloud kræver, at en metode baseret på WAN er den bedste mulighed for at levere Geo-placeret højtilgængeløsninger. Det er det, vi kalder Global Service Load balancing or GSLB.

Hvornår skal du bruge GSLB

GSLB-tjenesten anbefales at blive brugt til følgende brugsager:

Virksomheder, der er vært for deres tjenester i mere end et datacenter gennem WAN.
Virksomheder, der kræver at skabe høj tilgængelighed af tjenester eller datacentre.
Internetudbydere til at oprette indgående belastningsbalanceringstjenester, der skal bruges af deres brugere.

Absolut når det er nødvendigt at dele brugere og trafik mellem servere rundt om i verden uden fejlpunkter, er GSLB den rigtige løsning.

Hvordan virker GSLB

GSLB er en belastningsbalanceringsmekanisme på DNS protokollen, det er hurtigt og pålideligt, fordi det bruger UDP protokol og klientens svar er næsten i realtid.

I en fælles DNS-forespørgsel, for eksempel www.zvnlb.net, sender en klient DNS-forespørgselsopløsningen til de lokale konfigurerede DNS-servere (for eksempel 8.8.8.8 8.8.4.4 ) og derefter vælger klientsystemet tilfældigt en af ​​serverne for at imødekomme anmodningen og sende forespørgslen.

Den valgte DNS-server modtager anmodningen fra klienten (for eksempel, hvad er IP-adressen til www.zvnlb.net? ) og de lokale konfigurerede DNS-servere forsøger at finde hvem der er ansvarlig for at løse DNS-zonen zvnlb.net.

Den DNS, der bruges af klienten, 8.8.8.8 or 8.8.4.4 i dette tilfælde opdager det ns1.zvnlb.net ns2.zvnlb.net er ansvarlige for zone opløsninger for zvnlb.net så de sender DNS-forespørgslen modtaget af klienten (for eksempel, hvad er IP-adressen til www.zvnlb.net? ) til en af ​​dem.

En af navnet servere enten ns1.zvnlb.net or ns2.zvnlb.net modtager DNS forespørgslen fra 8.8.8.8 or 8.8.4.4 og så kontrollerer den navneserver, der modtager anmodningen, de tilgængelige servere til værten www.zvnlb.net og det vil svare på DNS-forespørgslen med listen over tilgængelige applikationsservere for at tjene den rigtige applikation til værten www.zvnlb.net, hvorfor disse oplysninger vil blive modtaget af kunden.

Nu vælger klienten tilfældigt en af ​​applikationsserverne fra listen modtaget i DNS-forespørgslen, og den sender direkte anmodningen til applikationen http://www.zvnlb.net.

Navneserverne ns1.zvnlb.net (i vores eksempel, beliggende i Frankfurt) og ns2.zvnlb.net (i vores eksempel, der ligger i Toronto) kontrollerer løbende sundhedstilstanden for den reelle anvendelse af værten www.zvnlb.net (192.235.113.3 194.23.52.21 i vores tilfælde). Hvis ns1.zvnlb.net or ns2.zvnlb.net opdager et problem med at kontrollere sundhedstilstanden for nogle af de rigtige servere, vil den utilgængelige server blive deaktiveret i et bestemt tidsrum, og dets IP-adresse vil ikke blive angivet i DNS-forespørgsler, før den bliver tilgængelig igen.

Følgende diagram viser den beskrevne DNS-trafik med GSLB-funktioner.

Konfiguration af GSLB til katastrofeinddrivelse af datacentre

Denne konfiguration anbefales til tjenester, der kræver høj tilgængelighed af datacentre til katastrofeinddrivelse. Så hvis alle tjenester i et bestemt firma er i et datacenter, og et sådant datacenter mislykkes, vil systemet flytte alle de berørte tjenester til et andet tilgængeligt datacenter .

Følg dette ægte eksempel på GSLB-konfiguration for at opbygge et aktivt passivt datacenter til Disaster Recovery.

Vi har implementeret to Zevenet Load Balancers på tværs af to datacentre på forskellige steder, Frankfurt 159.89.7.124 og Toronto 159.203.12.35 og vi har en webservice, der reagerer på DNS-vært www.zvnlb.net, konfigureret i Datacenter 1 Datacenter 2. Udformningen af ​​denne arkitektur vil tillade at sende alle klienterne trafik til Datacenter 1 men hvis det mislykkes, omdirigeres klienterne til Datacenter 2.

For at opnå denne konfiguration skal du følge nedenstående procedure.

Opret forbindelse til Zevenet webpanelet i Datacenter 1 (Frankfurt til vores sag), klik på hovedmenuen GSLB modul og opret en ny Farm, i vores eksempel vil blive kaldt DNS1-Frankfurt i den virtuelle port 53.

Når bedriften er oprettet, skal du redigere den og gå til fanen Zoner og opret DNS-zonen, der skal styres af GSLB-modulet, i dette tilfælde zvnlb.net, som følger:

Når denne zone var oprettet, bedes du foretage den første konfiguration, som den er vist nedenfor:

Bemærk, at ns1 ns2 er navneserverne ansvarlige for DNS-opløsningerne for zonen zvnlb.net (i vores tilfælde en GSLB-tjeneste i Frankfurt og en anden i Toronto).

Derefter skal du oprette forbindelse til Zevenet webpanelet i Data Center 2, i hovedmenuen vælg GSLB og opret en ny Farm, i vores tilfælde vil blive kaldt DNS2-Toronto i den virtuelle port 53.

Rediger den nye GSLB gård og gå til fanen ZonerOpret her DNS-zonen, der skal administreres af denne GSLB-tjeneste for zvnlb.net som følger:

Når først denne nye zone er oprettet, skal du gøre den første konfiguration som følger:

Ligesom tilfældet med GSLB i Datacenter 1, navnet servere n1 n2 vil pege på GSLB tjenester i begge Datacenter 1 Datacenter 2, henholdsvis.

Klik derefter på fanen Services og lav en ny tjeneste, for eksempel webpriority:

Vælg Algoritme option Prioritet: Tilslutninger altid til den mest tilgængelige prio og konfigurer tjenesten som følger:

Genstart gården for at anvende ændringerne. Det er nødvendigt at anvende den samme GSLB-servicekonfiguration i begge datacentre.

Bemærk at hvis Farm Guardian er ikke konfigureret til at anvende en sundhedscheck, bruger GSLB-tjenesten en standard check_tcp til TCP-porten defineret i feltet sundhedskontrol i servicekonfigurationen.

Hvis du vil aktivere den nye tjeneste, skal du gå til den oprettede zone (zvnlb.net i vores tilfælde) og opret en ny Resource. Opret derefter det ved at vælge det nye Service som det er vist nedenfor.

Gem endelig ændringerne. Det er nødvendigt at anvende denne konfiguration i begge datacentre.

På dette tidspunkt er værten www.zvnlb.net styres af GSLB modulet i Prioritet mode, så al trafik vil blive sendt til Datacenter 1 og så, hvis det fejler, vil trafikken blive omdirigeret til den anden tilgængelige Datacenter 2.

TTL er konfigureret til 5, det er den slags udløbsdato, der sættes på en DNS-post. TTL tjener til at fortælle den rekursive server eller lokale resolver, hvor længe den skal holde nævnte post i sin cache. Så en lavere værdi konfigureres hurtigere, og ændringerne registreres.

Ved anvendelse af denne metode kunne vi tilføje så mange datacentre efter behov ved at inkludere nye navneservere med GSLB-service.

Den følgende DNS-anmodning viser Nameserver-konfigurationen til zvnlb.net og DNS-opløsningen for værten www.zvnlb.net.

user@client:# host -t ns zvnlb.net
zvnlb.net name server ns2.zvnlb.net.
zvnlb.net name server ns1.zvnlb.net.

Begge navneservere bruger de virtuelle IP-adresser, der er konfigureret i GSLB-gårdene.

Brug nu dine nuværende DNS-servere til at løse en vært (for eksempel www) i denne zone:

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211

Som det er vist, i øjeblikket værten 188.166.230.211 er den aktive reelle applikationsknude i Datacenter 1. Så snart værten ikke er tilgængelig (for eksempel http-tjenesten i 188.166.230.211 er nede) DNS-opløsningen ændres som vist nedenfor.

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

Så snart applikationsserveren fejler, ændrer DNS-opløsningen værten til Datacenter 2. Når værten i Datacenter 1 er op fejlsøgningen vil blive anvendt automatisk.

Konfiguration af GSLB til aktive aktive datacentre

Den høje tilgængelighed med tilstandsprioritet er en god mulighed for et katastrofegendannelsessystem, men backup-datacentret, som det bruges til gendannelsen, har ikke for meget brug, så det er normalt mere effektivt at indlæse al trafik mellem de tilgængelige data centre.

I sådanne tilfælde skal du bruge delingsmetoden til din GSLB-tjeneste, der hedder Round Robin Load Balancing som det er vist i eksemplet for den nye kaldte tjeneste web:

Tilføj nu det i zonen zvnlb.net og ændre ressource konfiguration www som følger:

Gem ændringerne og genstart bedriften hvis det ønskes.

For at teste det skal du forsøge at løse værten www.zvnlb.net og output ser ud som om det er vist:

user@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 188.166.230.211
Name:	www.zvnlb.net
Address: 139.59.186.84

Bemærk, at DNS resolver returnerer begge applikationsservere i stedet for en som Disaster Recovery-sagen.

Når værten har en fejl, ændres DNS-opløsningen automatisk. Se nedenfor, hvad der sker.

root@client:# nslookup www.zvnlb.net
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.zvnlb.net
Address: 139.59.186.84

Den utilgængelige applikationsserver er deaktiveret fra DNS-svarlisten.

Så snart værten 188.166.230.211 er tilgængelig igen, vil det blive inkluderet tilbage i DNS-opløsningen.

Delegering af en zone i Zevenet GSLB-tjenesten

I tilfælde af en offentlig zone (for eksempel zvnlb.net) som leverer en GSLB-tjeneste som en navneserveropløsningsenhed, der skal genkendes af offentlige DNS-servere til et sådant domæne, skal det registreres den offentlige IP-adresse, der bruges af GSLB-tjenesten, i dit domænes registrator (som NameCheap, Goddady eller andre) . Følgende link forklarer, hvordan man registrerer GSLB-IP'er som NameServers i en domæneregistreringsprocedure.

Registrer en vært som en navneserver

Efter den angivne procedure skal du registrere dig ns1.zvnlb.net ns2.zvnlb.net med de givne IP'er.

Oprettelse af en dedikeret subzone til GSLB

Bare hvis det ikke er muligt at delegere DNS-opløsningen til GSLB-tjenesten i Zevenet, kunne nedenstående konfiguration udføres. Følgende eksempel viser, hvordan man bygger en underzone forum zvnlb.net der peger på NameServers af denne nye subzone i GSLB-tjenesten.

Node 1 (for eksempel ns1.zvnlb.net med IP 162.243.5.109) og Node 2 (for eksempel ns2.zvnlb.net med IP 178.62.233.104) er Nameservers konfigureret og tilbyder DNS-opløsningstjenester for zonen zvnlb.net, denne zone er under en Bind9 offentlig DNS-tjeneste, og vi ønsker at tilbyde GSLB-muligheder for nogle værter af vores infrastruktur, så vi besluttede at oprette DNS-subsonen cluster.zvnlb.net og konfigurere 2 GSLB gårde som DNS Nameservers til dette formål.

Vi har oprettet delzonen for vores domæne cluster.zvnlb.net i vores Bind9 DNS-servere som følger:

Følg nu afsnittet Delegering af en zone i Zevenet GSLB-tjenesten for at holde 159.89.7.124 159.203.12.35 i vores eksempel som anerkendte navneservere for zonen cluster.zvnlb.net af offentlige DNS-servere.

Derefter kan du anvende konfigurationen som forklaret for domænet zvnlb.net i afsnittet ovenfor Konfiguration af GSLB til katastrofegendannelse af datacentre.

Peger på en vært i vores egen DNS henvist til en GSLB-tjeneste

I de foregående afsnit har vi oprettet en vært ved navn www.zvnlb.net belastningsbalancering i prioritets- og round robin-tilstande, så vi kan genbruge denne konfiguration for at tilbyde GSLB-funktioner til en anden DNS-navneserver, som ikke understøtter denne funktion som standard.

For at opnå denne konfiguration behøver vi kun at oprette en ny Resource i DNS-zonen, der ikke understøtter GSLB-indstillinger (f.eks zevenet.io styres af Bind9) som a Canonisk navn or CNAME som det vises nedenfor:

Når ændringen er anvendt, www.zevenet.io vil pege på www.zvnlb.net, men hvis værtsopløsningen www.zvnlb.net ændres derefter automatisk www.zevenet.io vil også ændre sig.

Bemærk, at dette eksempel er lavet på en Bind9 DNS-server, men Canonical Names eller CNAMES er DNS-hostkonfigurationer understøttet af en hvilken som helst DNS-servertjenesteimplementering.

Denne enkle forklaring viser, at en GSLB-tjeneste kan bruges, selvom vores nuværende DNS-service ikke tilbyder GSLB-funktioner, bare kun videresender opløsningen af ​​den givne vært i en ikke-GSLB-zone til GSLB-tjenesten i Zevenet Load Balancer.