GSLB-overzicht #

Tegenwoordig is een hoge beschikbaarheid van IT-diensten een must. Daarom ontwikkelen bedrijven en organisaties computersystemen die over de hele wereld verspreid zijn en hosten ze diensten in meer dan één datacenter. Dit biedt namelijk de volgende voordelen:

Fout tolerantie: als de gehoste service in het datacenter uitvalt, wordt de service op een van de andere beschikbare locaties voortgezet.
Automatisch datacenterherstel: als één datacenter uitvalt, wordt de service automatisch omgeleid naar een ander beschikbaar datacenter.
Load Balancing: het verkeer kan worden geoptimaliseerd door de belasting te verdelen over alle beschikbare sites. Hierdoor wordt de latentie verbeterd en kan de dienstverlening sneller worden uitgevoerd.
Verbeterde latentie: het verkeer van de clienttoepassing verloopt rechtstreeks naar de echte server. Het is niet nodig om alle toepassingsgegevens via de load balancer te sturen.

Voor de adoptie en implementatie van IT-diensten in de cloud is een WAN-gebaseerde methode de beste optie om geografisch gelokaliseerde, zeer beschikbare oplossingen te bieden. Dit noemen we Global Service Load Balancing, ofwel GSLB.

Wanneer GSLB gebruiken #

Het gebruik van de GSLB-service wordt aanbevolen voor de volgende use cases:

Bedrijven die hun diensten in meer dan één datacenter via WAN hosten.
Bedrijven die een hoge beschikbaarheid van diensten of datacenters nodig hebben.
Internet Service Providers moeten inkomende load balancing-services creëren die door hun gebruikers gebruikt kunnen worden.

Wanneer gebruikers en verkeer zonder storingspunten tussen servers over de hele wereld gedeeld moeten worden, is GSLB de juiste oplossing.

Hoe werkt GSLB? #

GSLB is een load balancing-mechanisme gebaseerd op het DNS- protocol. Het is snel en betrouwbaar omdat het gebruikmaakt van het UDP -protocol en de clientrespons vrijwel in realtime is.

Bij een standaard DNS-verzoek, bijvoorbeeld www.zvnlb.net , stuurt een client het DNS-verzoek naar de lokaal geconfigureerde DNS-servers (bijvoorbeeld 8.8.8.8 en 8.8.4.4 ). Vervolgens selecteert het clientsysteem willekeurig één van de servers om het verzoek af te handelen en de query te verzenden.

De geselecteerde DNS-server ontvangt het verzoek van de client (bijvoorbeeld: wat is het IP-adres van www.zvnlb.net ?) en de lokaal geconfigureerde DNS-servers proberen te achterhalen welke server verantwoordelijk is voor het oplossen van de DNS-zone zvnlb.net.

De DNS-server die door de client wordt gebruikt, in dit geval 8.8.8.8 of 8.8.4.4 , detecteert dat ns1.zvnlb.net en ns2.zvnlb.net verantwoordelijk zijn voor de zone-resolutie voor zvnlb.net. Daarom sturen ze de DNS-query die de client ontvangt (bijvoorbeeld: wat is het IP-adres van www.zvnlb.net ?) door naar een van deze servers.

Een van de naamservers, ns1.zvnlb.net of ns2.zvnlb.net, ontvangt de DNS-query van 8.8.8.8 of 8.8.4.4. Vervolgens controleert de naamserver die het verzoek ontvangt welke servers beschikbaar zijn voor de host www.zvnlb.net en beantwoordt de DNS-query met een lijst van beschikbare applicatieservers die de daadwerkelijke applicatie voor de host www.zvnlb.net kunnen bedienen . Deze informatie wordt uiteindelijk door de client ontvangen.

De client selecteert nu willekeurig een van de applicatieservers uit de lijst die is ontvangen in de DNS-query en stuurt het verzoek direct naar de applicatie http://www.zvnlb.net.

De naamservers ns1.zvnlb.net (in ons voorbeeld gevestigd in Frankfurt) en ns2.zvnlb.net (in ons voorbeeld gevestigd in Toronto) controleren continu de status van de daadwerkelijke applicatie van de host www.zvnlb.net ( 192.235.113.3 en 194.23.52.21 in ons geval). Als ns1.zvnlb.net of ns2.zvnlb.net een probleem detecteert bij het controleren van de status van een van de daadwerkelijke servers, wordt de niet-beschikbare server tijdelijk gedeactiveerd en wordt het IP-adres ervan niet meer in DNS-query's opgenomen totdat de server weer beschikbaar is.

Het onderstaande diagram toont het beschreven DNS-verkeer met GSLB-mogelijkheden.

GSLB configureren voor noodherstel van datacenters #

Deze configuratie wordt aanbevolen voor services waarvoor een hoge beschikbaarheid van datacenters vereist is voor herstel na een ramp. Als alle services van een bepaald bedrijf zich in één datacenter bevinden en dat datacenter uitvalt, verplaatst het systeem alle getroffen services naar een ander, beschikbaar datacenter.

Volg dit echte voorbeeld van een GSLB-configuratie om een ​​actief-passief datacenter voor noodherstel te bouwen.

We hebben twee RELIANOID Loadbalancers in twee datacenters op verschillende locaties, Frankfurt 159.89.7.124 en Toronto 159.203.12.35 en we hebben een webservice die reageert op de DNS-host www.zvnlb.net, geconfigureerd in Datacentrum 1 en Datacentrum 2Het ontwerp van deze architectuur zal het mogelijk maken om al het clientverkeer naar de Datacentrum 1 maar als het mislukt, worden de clients doorgestuurd naar Datacentrum 2.

Om deze configuratie te realiseren, volgt u de onderstaande procedure.

Maak verbinding met de RELIANOID webpaneel in de Datacentrum 1 (Frankfurt in ons geval), klik in het hoofdmenu GSLB module en maak een nieuwe Boerderijin ons voorbeeld zal dit worden genoemd DNS1-Frankfurt in de virtuele haven 53.

Nadat de farm is aangemaakt, kunt u deze bewerken en naar het tabblad Zones gaan om de DNS-zone aan te maken die door de GSLB-module beheerd gaat worden, in dit geval zvnlb.net , als volgt:

Zodra u deze zone heeft aangemaakt, voert u de eerste configuratie uit zoals hieronder weergegeven:

Merk op dat ns1 en ns2 de naamservers zijn die verantwoordelijk zijn voor de DNS-resoluties voor de zone zvnlb.net (in ons geval een GSLB-service in Frankfurt en een andere in Toronto).

Maak vervolgens verbinding met de RELIANOID webpaneel in het Data Center 2, selecteer in het hoofdmenu GSLB en maak een nieuwe Boerderij, zal in ons geval genoemd worden DNS2-Toronto in de virtuele haven 53.

Bewerk de nieuwe GSLB-farm en ga naar het tabblad Zones . Maak hier de DNS-zone aan die door deze GSLB-service voor zvnlb.net beheerd zal worden, als volgt:

Zodra u deze nieuwe zone hebt aangemaakt, voert u de eerste configuratie als volgt uit:

Net als bij de GSLB in datacenter 1 , zullen de naamservers n1 en n2 verwijzen naar de GSLB-services in respectievelijk datacenter 1 en datacenter 2.

Klik vervolgens op het tabblad Services en maak een nieuwe service aan, bijvoorbeeld webpriority :

Selecteer de optie 'Algoritme Prioriteit: Verbindingen altijd met de hoogst beschikbare prioritaire verbinding' en configureer de service als volgt:

Start de farm opnieuw op om de wijzigingen toe te passen. Het is vereist om dezelfde GSLB-serviceconfiguratie in beide datacenters toe te passen.

Houd er rekening mee dat als Farm Guardian niet is geconfigureerd om een ​​gezondheidscontrole uit te voeren, de GSLB-service standaard een check_tcp gebruikt naar de TCP-poort die is gedefinieerd in het veld voor de gezondheidscontrole in de serviceconfiguratie.

Om de nieuwe service in te schakelen, ga je naar de aangemaakte zone ( in ons geval zvnlb.net ) en maak je een nieuwe resource aan . Maak deze vervolgens aan door de nieuwe service te selecteren , zoals hieronder weergegeven.

Sla ten slotte de wijzigingen op. Deze configuratie moet in beide datacenters worden toegepast.

Op dit punt wordt de host www.zvnlb.net beheerd door de GSLB-module in prioriteitsmodus , waardoor al het verkeer naar datacenter 1 wordt gestuurd en, als dat datacenter uitvalt, het verkeer wordt omgeleid naar het andere beschikbare datacenter 2.

De TTL is ingesteld op 5, een soort vervaldatum die aan een DNS-record wordt gekoppeld. De TTL dient om de recursieve server of lokale resolver te vertellen hoe lang deze record in de cache moet worden bewaard. Een lagere waarde zorgt er dus voor dat wijzigingen sneller worden gedetecteerd.

Met deze methode kunnen we zoveel datacenters toevoegen als nodig is door nieuwe naamservers met GSLB-service op te nemen.

Het volgende DNS-verzoek toont de nameserverconfiguratie voor zvnlb.net en de DNS-resolutie voor de host www.zvnlb.net.

gebruiker@client:# host -t ns zvnlb.net zvnlb.net naamserver ns2.zvnlb.net. zvnlb.net naamserver ns1.zvnlb.net.

Beide naamservers gebruiken de virtuele IP-adressen die zijn geconfigureerd in de GSLB-farms.

Gebruik nu uw huidige DNS-servers om een ​​host (bijvoorbeeld www ) in deze zone op te lossen:

gebruiker@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Adres: 8.8.8.8#53 Niet-gezaghebbend antwoord: Naam: www.zvnlb.net Adres: 188.166.230.211

Zoals te zien is, is host 188.166.230.211 momenteel het actieve applicatieknooppunt in Data Center 1. Zodra de host niet meer bereikbaar is (bijvoorbeeld doordat de http-service op 188.166.230.211 niet beschikbaar is), zal de DNS-resolutie veranderen zoals hieronder weergegeven.

gebruiker@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Adres: 8.8.8.8#53 Niet-gezaghebbend antwoord: Naam: www.zvnlb.net Adres: 139.59.186.84

Zodra de applicatieserver uitvalt, zal de DNS-resolutie de host wijzigen naar Data Center 2. Zodra de host in Data Center 1 weer operationeel is, wordt de failback automatisch toegepast.

GSLB configureren voor actieve-actieve datacenters #

Hoge beschikbaarheid met de prioriteitsmodus is een goede optie voor een systeem voor noodherstel, maar het back-updatacenter dat voor het herstel wordt gebruikt, wordt niet zo veel gebruikt. In dat geval is het doorgaans efficiënter om al het verkeer te verdelen over de beschikbare datacenters.

Gebruik in dergelijke gevallen de Round Robin Load Balancing -methode voor uw GSLB-service , zoals weergegeven in het voorbeeld voor de nieuwe service genaamd web :

Voeg het nu toe aan de zone zvnlb.net en wijzig de resourceconfiguratie www als volgt:

Sla de wijzigingen op en start de farm opnieuw op indien gevraagd.

Om het te testen, probeer de host www.zvnlb.net op te lossen . De uitvoer zal er dan uitzien zoals weergegeven:

gebruiker@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Adres: 8.8.8.8#53 Niet-gezaghebbend antwoord: Naam: www.zvnlb.net Adres: 188.166.230.211 Naam: www.zvnlb.net Adres: 139.59.186.84

Houd er rekening mee dat de DNS-resolver beide applicatieservers retourneert in plaats van één zoals in het geval van Disaster Recovery.

Zodra de host uitvalt, verandert de DNS-resolutie automatisch. Zie hieronder wat er gebeurt.

root@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Adres: 8.8.8.8#53 Niet-gezaghebbend antwoord: Naam: www.zvnlb.net Adres: 139.59.186.84

De niet-beschikbare applicatieserver wordt gedeactiveerd in de DNS-antwoordlijst.

Zodra de host 188.166.230.211 weer beschikbaar is, wordt deze opnieuw opgenomen in de DNS-resolutie.

Een zone delegeren in de RELIANOID GSLB-service #

In het geval van een publieke zone (bijvoorbeeld zvnlb.net ) die een GSLB-service levert als naamserverresolver die door publieke DNS-servers voor dat domein moet worden herkend, is het noodzakelijk om het publieke IP-adres dat door de GSLB-service wordt gebruikt, te registreren bij de registrar van uw domein (zoals NameCheap, Goddady of anderen). De volgende link legt uit hoe u GSLB-IP-adressen als naamservers kunt registreren bij een domeinregistrar.

Registreer een host als een nameserver

Volg de aangegeven procedure om ns1.zvnlb.net en ns2.zvnlb.net te registreren met de opgegeven IP-adressen.

Het creëren van een speciale subzone voor GSLB #

Voor het geval het niet mogelijk is om de DNS-resolutie te delegeren aan de GSLB-service van RELIANOID, kan de hieronder beschreven configuratie worden uitgevoerd. Het volgende voorbeeld laat zien hoe u een subzone besteld, zvnlb.net die verwijst naar de NameServers van deze nieuwe subzone in de GSLB-service.

Node 1 (bijvoorbeeld ns1.zvnlb.net met IP-adres 162.243.5.109 ) en Node 2 (bijvoorbeeld ns2.zvnlb.net met IP-adres 178.62.233.104 ) zijn nameservers die geconfigureerd zijn en DNS-resolutiediensten aanbieden voor de zone zvnlb.net . Deze zone valt onder een openbare Bind9 DNS-service en we willen GSLB-functionaliteit aanbieden aan een aantal hosts in onze infrastructuur. Daarom hebben we besloten om de DNS-subzone cluster.zvnlb.net aan te maken en hiervoor twee GSLB-farms als DNS-nameservers te configureren.

We hebben de subzone voor ons domein cluster.zvnlb.net in onze Bind9 DNS-servers als volgt aangemaakt :

Volg nu het gedeelte Een zone delegeren in de RELIANOID GSLB-service om te behouden 159.89.7.124 en 159.203.12.35 in ons voorbeeld als erkende naamservers voor de zone cluster.zvnlb.net door openbare DNS-servers.

Vervolgens kunt u de configuratie toepassen zoals uitgelegd voor het domein zvnlb.net in het bovenstaande gedeelte ' GSLB configureren voor noodherstel van datacenters'.

Een host in onze eigen DNS aanwijzen die verwijst naar een GSLB-service #

In de voorgaande secties hebben we een host met de naam www.zvnlb.net aangemaakt met load balancing in prioriteits- en round-robin-modus. We kunnen deze configuratie hergebruiken om GSLB-functionaliteit aan te bieden aan een andere DNS-nameserver die deze functie standaard niet ondersteunt.

Om deze configuratie te realiseren, hoeven we alleen een nieuwe resource aan te maken in de DNS-zone die geen GSLB-opties ondersteunt (bijvoorbeeld relianoid.io wordt beheerd door Bind9), zoals een canonieke naam of CNAME, zoals hieronder weergegeven:

Zodra de wijziging is doorgevoerd, zal www.relianoid.io verwijzen naar www.zvnlb.net , maar als de hostresolutie van www.zvnlb.net verandert, zal www.relianoid.io automatisch ook veranderen.

Houd er rekening mee dat dit voorbeeld is uitgevoerd op een Bind9 DNS-server, maar Canonical Names of CNAMES zijn DNS-hostconfiguraties die door elke DNS-serverservice-implementatie worden ondersteund.

Deze eenvoudige uitleg laat zien dat een GSLB-service gebruikt kan worden, zelfs als onze huidige DNS-service geen GSLB-mogelijkheden biedt, en dat de resolutie van de gegeven host in een niet-GSLB-zone alleen naar de GSLB-service wordt doorgestuurd. RELIANOID Loadbalancer.