GSLB-overzicht

Tegenwoordig is de hoge beschikbaarheid van IT-services een must en daarom ontwikkelen bedrijven en organisaties computersystemen die over de hele wereld worden gedistribueerd en host-services in meer dan één Data Center, omdat het de volgende voordelen biedt:

Fout tolerantie: wanneer de gehoste service in het datacenter faalt, wordt de service ingeschakeld op een van de andere beschikbare sites.
Automatisch herstel van datacenters: wanneer een datacenter faalt, wordt de service automatisch omgeleid naar een ander beschikbaar datacenter.
Load Balancing: het verkeer kan worden geoptimaliseerd door de belasting over alle beschikbare sites te verdelen, waardoor de latentie wordt verbeterd en de dienstverlening sneller wordt.
Verbeterde latentie: het verkeer van clienttoepassingen is rechtstreeks met de echte server, het is niet nodig om alle toepassingsgegevens door de load balancer te sturen.

De acceptatie en implementatie van IT-services in de Cloud vereist dat een methode op basis van WAN de beste optie is om Geo-locatie high availability-oplossingen te bieden. Dat is wat we noemen Global Service Load-balancering or GSLB.

Wanneer GSLB te gebruiken

De GSLB-service wordt aanbevolen voor gebruik in de volgende gevallen:

Bedrijven die via WAN hun diensten in meerdere datacenters hosten.
Bedrijven die een hoge beschikbaarheid van diensten of datacenters nodig hebben.
Internetproviders maken inkomende load balancing-services die door hun gebruikers kunnen worden gebruikt.

Zeker, wanneer het nodig is om gebruikers en verkeer tussen servers over de hele wereld te delen zonder storingspunten, is GSLB de juiste oplossing.

Hoe werkt GSLB

GSLB is een mechanisme voor load balancing op DNS protocol, het is snel en betrouwbaar omdat het gebruikt UDP protocol en de reactie van de klant is bijna in realtime.

In een algemeen DNS-verzoek, bijvoorbeeld www.zvnlb.net, een client stuurt de DNS-verzoekresolutie naar de lokaal geconfigureerde DNS-servers (bijvoorbeeld 8.8.8.8 en 8.8.4.4 ) en vervolgens selecteert het clientsysteem willekeurig een van de servers die tegen het verzoek moet worden gemaakt en om 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 wie verantwoordelijk is voor het oplossen van de DNS-zone zvnlb.net.

Het DNS dat door de client wordt gebruikt, 8.8.8.8 or 8.8.4.4 in dit geval detecteert dat ns1.zvnlb.net en ns2.zvnlb.net zijn verantwoordelijk voor zoneresoluties voor zvnlb.net dus ze sturen de DNS-query die de client heeft ontvangen (bijvoorbeeld, wat is het IP-adres van www.zvnlb.net? ) naar een van hen.

Een van de name-servers ook ns1.zvnlb.net or ns2.zvnlb.net ontvangt de DNS-vraag van 8.8.8.8 or 8.8.4.4 en vervolgens controleert de naamserver die de aanvraag ontvangt de beschikbare servers voor de host www.zvnlb.net en het zal reageren op de DNS-query met de lijst met beschikbare applicatieservers om de echte applicatie voor de host te bedienen www.zvnlb.netvandaar dat deze informatie uiteindelijk door de klant wordt ontvangen.

Nu selecteert de client willekeurig een van de toepassingsservers uit de lijst die is ontvangen in de DNS-query en verzendt deze rechtstreeks de aanvraag naar de toepassing 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 gestaag de gezondheidstoestand van de echte toepassing van de host www.zvnlb.net (192.235.113.3 en 194.23.52.21 in ons geval). Als ns1.zvnlb.net or ns2.zvnlb.net detecteert een probleem bij het controleren van de status van sommige echte servers, dan wordt de onbeschikbare server gedeactiveerd gedurende een bepaalde tijd en wordt het IP-adres niet vermeld in de DNS-query's totdat het weer beschikbaar is.

Het volgende 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 voor noodherstel is vereist, dus als alle services van een bepaald bedrijf zich in één datacenter bevinden en een dergelijk datacenter faalt, zal het systeem alle betrokken services naar een ander beschikbaar datacenter verplaatsen .

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

We hebben twee Zevenet Load Balancers in twee datacenters op verschillende locaties in Frankfurt ingezet 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 Datacenter 1 en Datacenter 2. Het ontwerp van deze architectuur zal het mogelijk maken om alle klantenverkeer naar de Datacenter 1 maar als het niet lukt, wordt de client doorgestuurd naar Datacenter 2.

Volg deze procedure om deze configuratie te bereiken.

Maak verbinding met het Zevenet-webpaneel in de Datacenter 1 (Frankfurt voor onze zaak), klik in het hoofdmenu GSLB module en maak een nieuwe aan Boerderij, in ons voorbeeld zal worden genoemd DNS1-Frankfurt in de virtuele poort 53.

Nadat de boerderij is gemaakt, bewerkt u deze en gaat u naar het tabblad Zones en creëer in dit geval de DNS-zone die door de GSLB-module zal worden beheerd zvnlb.net, als volgt:

Nadat deze zone is gemaakt, maakt u de eerste configuratie zoals hieronder wordt weergegeven:

Merk op dat ns1 en ns2 zijn de Name Servers verantwoordelijk 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 het webpaneel van Zevenet in het datacenter 2, selecteer in het hoofdmenu GSLB en maak een nieuwe Boerderij, in ons geval zal worden genoemd DNS2-Toronto in de virtuele poort 53.

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

Nadat deze nieuwe zone is aangemaakt, maakt u de eerste configuratie als volgt:

Zoals het geval van de GSLB in de Datacenter 1, de naamservers n1 en n2 wijst in beide naar de GSLB-services Datacenter 1 en Datacenter 2, Respectievelijk.

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

Selecteer het Algoritme optie Prioriteit: Verbindingen altijd met de meest beschikbare prio en configureer de service als volgt:

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

Merk op dat als Farm Guardian is niet geconfigureerd om een ​​health check toe te passen, de GSLB-service gebruikt een standaard check_tcp naar de TCP-poort die is gedefinieerd in het veld voor de gezondheidscontrole in de serviceconfiguratie.

Om de nieuwe service in te schakelen, gaat u naar de aangemaakte zone (zvnlb.net in ons geval) en maak een nieuwe aan Hulpbron. Maak het vervolgens door het nieuwe te selecteren Service zoals hieronder wordt weergegeven.

Sla ten slotte de wijzigingen op. Het is vereist om deze configuratie in beide datacenters toe te passen.

Op dit punt, de gastheer www.zvnlb.net wordt beheerd door de GSLB-module in Prioriteit modus, dus al het verkeer wordt verzonden naar de Datacenter 1 en dan, als het faalt, wordt het verkeer omgeleid naar de andere beschikbaar Datacenter 2.

De TTL is geconfigureerd op 5, het is het soort vervaldatum dat op een DNS-record wordt gezet. De TTL dient om de recursieve server of lokale resolver te vertellen hoelang deze record in zijn cache moet worden bewaard. Dus een lagere waarde die sneller is geconfigureerd, worden de wijzigingen gedetecteerd.

Als we deze methode toepassen, kunnen we zo veel gegevenscentra toevoegen als nodig is door nieuwe naamservers op te nemen met de GSLB-service.

Het volgende DNS-verzoek toont de configuratie van de Nameservers voor zvnlb.net en de DNS-resolutie voor de host www.zvnlb.net.

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

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

Gebruik nu uw huidige DNS-servers om een ​​host op te lossen (bijvoorbeeld www) in deze 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

Zoals het wordt getoond, momenteel de host 188.166.230.211 is het actieve echte toepassingsknooppunt in de Datacenter 1. Zodra de host niet bereikbaar is (bijvoorbeeld de http-service in 188.166.230.211 is down) verandert de DNS-resolutie zoals hieronder wordt weergegeven.

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

Zodra de toepassingenserver faalt, verandert de DNS-resolutie de host in de Datacenter 2. Zodra de host in de Datacenter 1 is hoger dan wordt de fail-back automatisch toegepast.

GSLB configureren voor actief actieve datacenters

De hoge beschikbaarheid met de modusprioriteit is een goede optie voor een Disaster Recovery-systeem, maar het back-updatacenter dat wordt gebruikt voor het herstel heeft niet al te veel gebruik, dus meestal is het efficiënter om al het verkeer tussen de beschikbare gegevens te verdelen. centra.

Gebruik in dergelijke gevallen de methode voor delen van uw GSLB-service met de naam Round Robin Load Balancing zoals weergegeven in het voorbeeld voor de nieuwe service die wordt aangeroepen web:

Voeg het nu toe in de zone zvnlb.net en verander de bronconfiguratie www als volgt:

Sla de wijzigingen op en start de farm opnieuw op als hierom wordt gevraagd.

Probeer de host op te lossen om het te testen www.zvnlb.net en de uitvoer zal eruit zien alsof het wordt weergegeven:

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

Merk op dat de DNS-resolver beide applicatieservers retourneert in plaats van een zoals de Disaster Recovery-casus.

Zodra de host een fout heeft, wordt de DNS-resolutie automatisch gewijzigd. Zie hieronder wat er gebeurt.

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

De niet-beschikbare toepassingenserver is gedeactiveerd in de DNS-responsenlijst.

Zodra de gastheer 188.166.230.211 is weer beschikbaar, het wordt terug opgenomen in de DNS-resolutie.

Een zone delegeren in de Zevenet GSLB-service

In het geval van een openbare zone (bijvoorbeeld zvnlb.net) die een GSLB-service levert als een naamserver-resolver die moet worden herkend door openbare DNS-servers voor een dergelijk domein, dan is het vereist om het openbare IP-adres dat wordt gebruikt door de GSLB-service te registreren bij de registrar van uw domein (zoals NameCheap, Goddady of anderen) . De volgende link legt uit hoe u GSLB IP's registreert als NameServers in een domeinregistratieprocedure.

Registreer een host als een nameserver

Na de gegeven procedure moet u zich registreren ns1.zvnlb.net en ns2.zvnlb.net met de opgegeven IP's.

Een speciale subzone maken voor GSLB

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

Knooppunt 1 (bijvoorbeeld ns1.zvnlb.net met IP 162.243.5.109) en Knooppunt 2 (bijvoorbeeld ns2.zvnlb.net met IP 178.62.233.104) zijn Nameservers geconfigureerd en bieden DNS-resolutieservices voor de zone zvnlb.net, deze zone valt onder een openbare DNS-service van Bind9 en we willen GSLB-mogelijkheden bieden voor sommige hosts van onze infrastructuur. Daarom hebben we besloten om de DNS-subzone te maken cluster.zvnlb.net en configureer 2 GSLB-boerderijen zoals DNS Nameservers voor dit doel.

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

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

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

Een host aanwijzen in onze eigen DNS met betrekking tot een GSLB-service

In de vorige paragrafen hebben we een host met de naam gemaakt www.zvnlb.net taakverdeling in prioriteits- en round robin-modi, zodat we deze configuratie kunnen hergebruiken om GSLB-mogelijkheden aan een andere DNS-naamserver te bieden die deze functie niet standaard ondersteunt.

Om deze configuratie te bereiken, hoeven we alleen een nieuwe te maken Hulpbron in de DNS-zone die geen GSLB-opties ondersteunt (bijvoorbeeld zevenet.io wordt beheerd door Bind9) zoals a Canonieke naam or CNAME zoals het hieronder wordt getoond:

Zodra de wijziging is toegepast, www.zevenet.io zal wijzen naar www.zvnlb.net, maar als de hostresolutie www.zvnlb.net verandert dan automatisch www.zevenet.io zal ook veranderen.

Merk op dat dit voorbeeld wordt gedaan in een Bind9 DNS-server, maar Canonical Names of CNAMES zijn DNS-hostconfiguraties die door elke DNS-serverdienstimplementatie worden ondersteund.

Deze eenvoudige uitleg laat zien dat een GSLB-service kan worden gebruikt, zelfs als onze huidige DNS-service geen GSLB-mogelijkheden biedt, alleen de resolutie van de gegeven host in een niet-GSLB-zone doorstuurt naar de GSLB-service in Zevenet Load Balancer.