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 distribueret over hele verden og hoster tjenester i mere end ét datacenter, da det tilbyder følgende fordele:

FejltoleranceNår den hostede tjeneste i datacenteret fejler, fortsætter tjenesten på et hvilket som helst af de andre tilgængelige steder.
Automatisk gendannelse af datacenterNår et datacenter fejler, omdirigeres tjenesten automatisk til et andet tilgængeligt datacenter.
Load BalancingTrafikken kunne optimeres ved at fordele belastningen mellem alle tilgængelige websteder, hvilket forbedrer latensen og gør tjenesteleveringen hurtigere.
Forbedret latensKlientapplikationstrafikken går direkte til den rigtige server, det er ikke nødvendigt at sende alle applikationsdata gennem load balancer.

Adoption og implementering af IT-tjenester i skyen kræver, at en metode baseret på WAN er den bedste mulighed for at levere geolokaliserede løsninger med høj tilgængelighed. Det er det, vi kalder det. Global servicebelastningsbalancering or GSLB.

Hvornår skal man bruge GSLB #

Det anbefales at bruge GSLB-tjenesten til følgende anvendelsesscenarier:

Virksomheder, der hoster deres tjenester i mere end ét datacenter via WAN.
Virksomheder, der har brug for at skabe høj tilgængelighed af tjenester eller datacentre.
Internetudbydere skal oprette indgående load balancing-tjenester, der skal bruges af deres brugere.

Når det er nødvendigt at dele brugere og trafik mellem servere over hele verden uden fejlpunkter, er GSLB helt sikkert den rigtige løsning.

Hvordan fungerer GSLB? #

GSLB er en belastningsbalanceringsmekanisme på DNS protokol, den er hurtig og pålidelig, fordi den bruger UDP protokol, og klientresponsen sker næsten i realtid.

I en almindelig DNS-anmodning, for eksempel www.zvnlb.net, sender en klient DNS-anmodningsopløsningen til de lokalt konfigurerede DNS-servere (f.eks. 8.8.8.8 og 8.8.4.4 ) og derefter vælger klientsystemet tilfældigt en af ​​serverne til at reagere på anmodningen og sende forespørgslen.

Den valgte DNS-server modtager anmodningen fra klienten (for eksempel, hvad er IP-adressen på www.zvnlb.net? ) og de lokalt konfigurerede DNS-servere forsøger at finde ud af, 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, at ns1.zvnlb.net og ns2.zvnlb.net er ansvarlige for zoneopløsninger for zvnlb.net så de sender den DNS-forespørgsel, som klienten modtager (for eksempel, hvad er IP-adressen på www.zvnlb.net? ) til en af ​​dem.

En af navneserverne enten ns1.zvnlb.net or ns2.zvnlb.net modtager DNS-forespørgslen fra 8.8.8.8 or 8.8.4.4 og derefter tjekker den navneserver, der modtager anmodningen, de tilgængelige servere for værten www.zvnlb.net og den vil svare på DNS-forespørgslen med en liste over tilgængelige applikationsservere til at betjene den rigtige applikation for værten. www.zvnlb.net, derfor vil disse oplysninger endeligt blive modtaget af klienten.

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

Navneserverne ns1.zvnlb.net (i vores eksempel placeret i Frankfurt) og ns2.zvnlb.net (i vores eksempel, placeret i Toronto) kontrollerer løbende sundhedsstatussen for værtens faktiske applikation www.zvnlb.net (192.235.113.3 og 194.23.52.21 i vores tilfælde). Hvis ns1.zvnlb.net or ns2.zvnlb.net registrerer problemer med at kontrollere sundhedsstatussen for nogle af de rigtige servere, vil den utilgængelige server blive deaktiveret i et bestemt tidsrum, og dens IP-adresse vil ikke blive angivet i DNS-forespørgslerne, før den bliver tilgængelig igen.

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

Konfiguration af GSLB til katastrofegendannelse af datacentre #

Denne konfiguration anbefales til tjenester, der kræver høj tilgængelighed af datacentre til katastrofeberedskab. Hvis alle tjenester fra en bestemt virksomhed er i ét datacenter, og et sådant datacenter fejler, flytter systemet alle de berørte tjenester til et andet tilgængeligt datacenter.

Følg venligst dette virkelige eksempel på GSLB-konfiguration for at opbygge et aktivt-passivt datacenter til katastrofegendannelse.

Vi har indsat to RELIANOID Load Balancers på tværs af to datacentre på forskellige lokationer, Frankfurt 159.89.7.124 og Toronto 159.203.12.35 og vi har en webtjeneste, der svarer til DNS-værten www.zvnlb.net, konfigureret i Datacenter 1 og Datacenter 2Designet af denne arkitektur vil tillade at sende al klienttrafik til Datacenter 1 men hvis det fejler, omdirigeres klienterne til Datacenter 2.

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

Opret forbindelse til RELIANOID webpanel i Datacenter 1 (Frankfurt i vores tilfælde), klik på i hovedmenuen GSLB modul og opret et nyt Farm, i vores eksempel vil blive kaldt DNS1-Frankfurt i den virtuelle port 53.

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

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

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

Forbind derefter til RELIANOID webpanel i Data Center 2, vælg i hovedmenuen GSLB og oprette 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 Zoner, opret her den DNS-zone, der skal administreres af denne GSLB-tjeneste for zvnlb.net som følger:

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

Ligesom tilfældet med GSLB i Datacenter 1, navneserverne n1 og n2 vil pege på GSLB-tjenesterne i begge Datacenter 1 og Datacenter 2, henholdsvis.

Klik derefter på fanen Det vi er gode til og oprette en ny tjeneste, for eksempel webprioritet:

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

Genstart farmen for at anvende ændringerne. Det er nødvendigt at anvende den samme GSLB-tjenestekonfiguration i begge datacentre.

Bemærk at hvis Gårdværge ikke er konfigureret til at udføre nogen sundhedskontrol, bruger GSLB-tjenesten en standard check_tcp til den TCP-port, der er defineret i feltet for sundhedstjek i tjenestekonfigurationen.

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

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

På dette tidspunkt, værten www.zvnlb.net administreres af GSLB-modulet i Prioritet tilstand, så al trafik vil blive sendt til Datacenter 1 og 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'en tjener til at fortælle den rekursive server eller lokale resolver, hvor længe den skal opbevare posten i sin cache. Så en lavere værdi konfigureret til at gøre det hurtigere, at ændringerne registreres.

Ved at anvende denne metode kan vi tilføje så mange datacentre som nødvendigt ved at inkludere nye navneservere med GSLB-tjenesten.

Følgende DNS-anmodning viser navneserverkonfigurationen for zvnlb.net og DNS-opløsningen for værten www.zvnlb.net.

bruger@klient:# vært -t ns zvnlb.net zvnlb.net navneserver ns2.zvnlb.net. zvnlb.net navneserver ns1.zvnlb.net.

Begge navneservere bruger de virtuelle IP-adresser, der er konfigureret i GSLB-farmene.

Brug nu dine nuværende DNS-servere til at identificere en vært (f.eks. www) i denne zone:

bruger@klient:# nslookup www.zvnlb.net Server: 8.8.8.8 Adresse: 8.8.8.8#53 Ikke-autoritativt svar: Navn: www.zvnlb.net Adresse: 188.166.230.211

Som det fremgår, er værten i øjeblikket 188.166.230.211 er den aktive, reelle applikationsnode i Datacenter 1Så snart værten ikke kan nås (for eksempel http-tjenesten i 188.166.230.211 er nede) vil DNS-opløsningen ændres som vist nedenfor.

bruger@klient:# nslookup www.zvnlb.net Server: 8.8.8.8 Adresse: 8.8.8.8#53 Ikke-autoritativt svar: Navn: www.zvnlb.net Adresse: 139.59.186.84

Så snart applikationsserveren fejler, vil DNS-opløsningen ændre værten til Datacenter 2Når værten i Datacenter 1 er aktiv, vil failback-funktionen blive anvendt automatisk.

Konfiguration af GSLB til aktiv-aktive datacentre #

Høj tilgængelighed med prioritetstilstand er en god mulighed for et system til katastrofegendannelse, men det backup-datacenter, det bruges til gendannelse, bruges ikke særlig meget, så det er normalt mere effektivt at belastningsfordele al trafik mellem de tilgængelige datacentre.

I sådanne tilfælde skal du bruge delingsmetoden for din GSLB-tjeneste kaldet Round Robin Load Balancing som vist i eksemplet for den nye tjeneste kaldet web:

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

Gem ændringerne, og genstart farmen, hvis det bliver bedt om det.

For at teste det, prøv at løse værten www.zvnlb.net og outputtet vil se ud som vist:

bruger@klient:# nslookup www.zvnlb.net Server: 8.8.8.8 Adresse: 8.8.8.8#53 Ikke-autoritativt svar: Navn: www.zvnlb.net Adresse: 188.166.230.211 Navn: www.zvnlb.net Adresse: 139.59.186.84

Bemærk, at DNS-resolveren returnerer begge applikationsservere i stedet for én, som i tilfældet med Disaster Recovery.

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

root@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Adresse: 8.8.8.8#53 Ikke-autoritativt svar: Navn: www.zvnlb.net Adresse: 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 den blive inkluderet i DNS-opløsningen igen.

Delegering af en zone i RELIANOID GSLB-tjeneste #

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

Registrer en vært som en navneserver

Du skal registrere dig efter den givne procedure ns1.zvnlb.net og ns2.zvnlb.net med de givne IP'er.

Oprettelse af en dedikeret underzone til GSLB #

I tilfælde af at det ikke er muligt at delegere DNS-opløsningen til GSLB-tjenesten RELIANOID, kan den nedenfor forklarede konfiguration udføres. Følgende eksempel viser, hvordan man bygger en underzone forum zvnlb.net der peger på navneserverne for denne nye underzone i GSLB-tjenesten.

Node 1 (for eksempel ns1.zvnlb.net med IP-adresse 162.243.5.109) og Node 2 (for eksempel ns2.zvnlb.net med IP-adresse 178.62.233.104) er navneservere konfigureret og tilbyder DNS-opløsningstjenester for zonen zvnlb.netDenne zone er underlagt en offentlig Bind9 DNS-tjeneste, og vi ønsker at tilbyde GSLB-funktioner til nogle af vores værter i infrastrukturen, så vi besluttede at oprette DNS-underzonen. cluster.zvnlb.net og konfigurer 2 GSLB-farme som DNS-navneservere til dette formål.

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

Følg nu afsnittet Delegering af en zone i RELIANOID GSLB-tjeneste for at holde 159.89.7.124 og 159.203.12.35 i vores eksempel som en anerkendt navneserver 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 en vært i vores egen DNS med reference til en GSLB-tjeneste #

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

For at opnå denne konfiguration skal vi blot oprette en ny Resource i DNS-zonen, der ikke understøtter GSLB-indstillinger (f.eks. relianoid.io administreres af Bind9) som en Canonisk navn or CNAME som det er vist nedenfor:

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

Bemærk, at dette eksempel er udført på en Bind9 DNS-server, men Canonical Names eller CNAMES er DNS-værtskonfigurationer, der understøttes af enhver DNS-servertjenesteimplementering.

Denne enkle forklaring viser, at en GSLB-tjeneste kan bruges, selvom vores nuværende DNS-tjeneste ikke tilbyder GSLB-funktioner, idet den blot videresender opløsningen fra den givne vært i en ikke-GSLB-zone til GSLB-tjenesten i RELIANOID Load Balancer.