GSLB ülevaade

Tänapäeval on IT-teenuste kõrge kättesaadavus hädavajalik ning see on põhjus, miks ettevõtted ja organisatsioonid arendavad arvutisüsteeme, mis on jaotatud üle maailma ja pakuvad teenuseid rohkem kui ühes andmekeskuses, kuna see pakub järgmisi eeliseid:

Veataluvus: kui andmekeskuse hostitud teenus ebaõnnestub, läheb teenus edasi mõnda muudest kättesaadavatest saitidest.
Automaatne andmekeskuse taastamine: kui üks andmekeskus ebaõnnestub, suunatakse teenus automaatselt mis tahes teise kättesaadava andmekeskuse juurde.
Koormuse tasakaalustamine: liiklust saab optimeerida, jaotades koormuse kõigi olemasolevate saitide vahel, parandades latentsust ja muutes teenuse osutamise kiiremaks.
Täiustatud latentsus: kliendirakenduse liiklus on otse reaalse serveriga, ei ole vaja kõiki rakenduse andmeid laadida koormuse tasakaalustaja kaudu.

IT-teenuste kasutuselevõtt ja rakendamine pilves nõuab, et WAN-il põhinev meetod oleks parim võimalus Geo-toega kõrglahutusega lahenduste pakkumiseks. Seda me nimetame Globaalse teenuse koormuse tasakaalustamine or GSLB.

Millal GSLB-d kasutada

GSLB teenust soovitatakse kasutada järgmistel juhtudel:

Ettevõtted, kes pakuvad oma teenuseid WAN-i kaudu rohkem kui ühes andmekeskuses.
Ettevõtted, mis vajavad teenuste või andmekeskuste kõrget kättesaadavust.
Interneti-teenuse pakkujad loovad sissetuleva koormuse tasakaalustamisteenused, mida nende kasutajad kasutavad.

Kindlasti on GSLB õige lahendus, kui kogu maailmas on vaja kasutajaid ja liiklust serverite vahel ilma rikkepunktideta jagada.

Kuidas GSLB toimib

GSLB on koormuse tasakaalustamise mehhanism DNS protokoll, see on kiire ja usaldusväärne, sest kasutab seda UDP protokoll ja kliendi reaktsioon on peaaegu reaalajas.

Näiteks ühises DNS-i taotluses www.zvnlb.net, saadab klient DNS-i päringu resolutsiooni kohalikele konfigureeritud DNS-serveritele (näiteks 8.8.8.8 ja 8.8.4.4 ) ja seejärel valib kliendisüsteem juhuslikult ühe serveri, kes esitab päringu vastu ja saadab päringu.

Valitud DNS-server võtab vastu kliendi taotluse (näiteks milline on IP-aadress www.zvnlb.net? ) ja kohalikud konfigureeritud DNS-serverid püüavad leida, kes vastutab DNS-tsooni lahendamise eest zvnlb.net.

Kliendi poolt kasutatav DNS 8.8.8.8 or 8.8.4.4 sel juhul tuvastab selle ns1.zvnlb.net ja ns2.zvnlb.net vastutavad tsooni resolutsioonide eest zvnlb.net nii saadavad nad kliendi poolt saadud DNS-päringu (näiteks milline on IP-aadress www.zvnlb.net? ) ühele neist.

Üks nimeservereid ns1.zvnlb.net or ns2.zvnlb.net saab DNS-i päringu 8.8.8.8 or 8.8.4.4 ja siis päringu vastu võtnud nimeserver kontrollib hostile kättesaadavaid servereid www.zvnlb.net ja see vastab DNS-päringule koos olemasolevate rakendusserverite loendiga, et teenida hostile tegelikku rakendust www.zvnlb.netseega saab klient selle teabe lõpuks vastu.

Nüüd valib klient DNS-päringus vastuvõetud loendist juhuslikult ühe rakendusserveri ja saadab taotluse otse rakendusele http://www.zvnlb.net.

Nime serverid ns1.zvnlb.net (meie näites, asub Frankfurdis) ja ns2.zvnlb.net (meie näites, mis asub Torontos) kontrollivad pidevalt peremehe tegeliku rakenduse tervislikku seisundit www.zvnlb.net (192.235.113.3 ja 194.23.52.21 meie puhul). Kui ns1.zvnlb.net or ns2.zvnlb.net tuvastab mõnede reaalsete serverite tervisliku seisundi kontrollimise probleemi, siis deaktiveeritakse kättesaamatu server teatud ajaks ja selle IP-aadressi ei kuvata DNS-päringutes seni, kuni see muutub taas kättesaadavaks.

Järgnev diagramm näitab kirjeldatud DNS-liiklust GSLB-funktsioonidega.

GSLB konfigureerimine andmekeskuste taastamiseks

See konfiguratsioon on soovitatav teenustele, mis nõuavad katastroofide taastamiseks vajalike andmekeskuste kõrget kättesaadavust, nii et kui teatava ettevõtte kõik teenused on ühes andmekeskuses ja selline andmekeskus ebaõnnestub, siis süsteem liigutab kõik mõjutatud teenused teisele olemasolevale andmekeskusele .

Järgige seda tõelist GSLB konfiguratsiooni näidet, et ehitada katastroofide taastamiseks aktiivne passiivne andmekeskus.

Oleme kasutanud kahte Zevenet Load Balancerit kahes andmekeskuses erinevates kohtades, Frankfurt 159.89.7.124 ja Toronto 159.203.12.35 ja meil on veebiteenus, mis vastab DNS-i hostile www.zvnlb.net, konfigureeritud Andmekeskus 1 ja Andmekeskus 2. Selle arhitektuuri ülesanne on saata kõik kliendid liikluseks Andmekeskus 1 aga kui see ebaõnnestub, suunab kliendid ümber Andmekeskus 2.

Selle konfiguratsiooni saavutamiseks järgige alltoodud protseduuri.

Ühendage Zevenet veebipaneeliga Andmekeskus 1 (Frankfurt meie puhul), klõpsake peamenüüs GSLB moodul ja looge uus Talu, meie näites kutsutakse DNS1-Frankfurt virtuaalses pordis 53.

Kui põllumajandusettevõte on loodud, muutke seda ja minge vahekaardile Tsoonid ja luua DNS-tsoon, mida haldab GSLB moodul, antud juhul zvnlb.net, järgnevalt:

Kui see tsoon on loodud, tehke esimene konfiguratsioon, nagu see on näidatud allpool:

Pange tähele, et ns1 ja ns2 on tsooni DNS-lahenduste eest vastutavad nimeserverid zvnlb.net (meie puhul üks GSLB teenus Frankfurdis ja teine ​​Torontos).

Seejärel ühendage Zevenet veebipaneeliga andmekeskuses 2, põhimenüüs valige GSLB ja looge uus Talu, meie puhul nimetatakse seda DNS2-Toronto virtuaalses pordis 53.

Redigeerige uut GSLB talu ja minge vahekaardile TsoonidLooge siia DNS-tsoon, mida selle GSLB-teenuse abil hallatakse zvnlb.net järgmiselt:

Kui see uus tsoon on loodud, tehke esimene konfiguratsioon järgmiselt:

Nagu. \ T Andmekeskus 1, nimeserverid n1 ja n2 osutab GSLB teenustele mõlemas Andmekeskus 1 ja Andmekeskus 2, Vastavalt.

Seejärel klõpsake vahekaardil Teenused näiteks luua uus teenus veebipõhine:

Valige Algoritm valik Prioriteet: Ühendused on alati saadaval kõige enam ja konfigureerige teenus järgmiselt:

Muudatuste rakendamiseks taaskäivitage talu. Mõlemas andmekeskuses on vaja rakendada sama GSLB-teenuse konfiguratsiooni.

Pange tähele, et kui Farm Guardian ei ole konfigureeritud tervisekontrolli rakendamiseks, kasutab GSLB teenus vaikimisi check_tcp serveri konfiguratsiooni tervisekontrolli väljale määratud TCP-porti.

Uue teenuse lubamiseks minge loodud tsooni (zvnlb.net meie puhul) ja looge uus Ressurss. Seejärel looge see, valides uue Teenus nagu allpool näidatud.

Lõpuks salvestage muudatused. See konfiguratsioon tuleb rakendada mõlemas andmekeskuses.

Sel hetkel, võõrustaja www.zvnlb.net haldab GSLB moodul Prioriteet režiimis, saadetakse kogu liiklus Andmekeskus 1 ja siis, kui see ebaõnnestub, suunatakse liiklus teistesse kättesaadavatesse Andmekeskus 2.

TTL on konfigureeritud 5-le, see on DNS-i kirjele omamoodi aegumiskuupäev. TTL annab rekursiivsele serverile või kohalikule lahendajale teada, kui kaua peaks ta seda salvestist vahemälus hoidma. Nii et muudatused tuvastatakse kiiremini konfigureeritud madalama väärtusega.

Selle meetodi rakendamisel võime lisada nii palju andmekeskusi kui vaja, lisades GSLB teenusega uued nimeserverid.

Järgmine DNS-i päring näitab nimeserverite konfiguratsiooni zvnlb.net ja DNS-i lahutusvõime www.zvnlb.net.

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

Mõlemad nimeserverid kasutavad GSLB taludes konfigureeritud virtuaalseid IP-aadresse.

Nüüd kasutage oma praeguste DNS-serverite abil serverit (näiteks www) selles tsoonis:

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

Nagu see on näidatud, on praegu host 188.166.230.211 on aktiivne reaalne rakendussõlm Andmekeskus 1. Niipea kui server pole kättesaadav (näiteks http teenus 188.166.230.211 on maas) DNS-i eraldusvõime muutub, nagu allpool näidatud.

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

Niipea, kui rakendusserver ebaõnnestub, muudab DNS-i lahutus host Andmekeskus 2. Kui host on Andmekeskus 1 on üleval, tagasipöördumist rakendatakse automaatselt.

GSLB seadistamine aktiivseks aktiivseks andmekeskuseks

Kõrge kättesaadavus režiimi prioriteediga on hädaolukorra taastamise süsteemi jaoks hea valik, kuid varundamiseks kasutataval andmekeskusel, mida taaskasutamiseks kasutatakse, pole liiga palju kasutusi, nii et tavaliselt on kogu olemasoleva andmeliikluse tasakaalu tasakaalustamine tõhusam keskused.

Sellistel juhtudel kasutage kutsutud GSLB teenuse jagamismeetodit Ümar Robin koormuse tasakaalustamine nagu on näidatud uue teenuse nimega web:

Nüüd lisage see tsooni zvnlb.net ja muuta ressursside konfiguratsiooni www järgmiselt:

Salvestage muudatused ja taaskäivitage talu, kui seda nõutakse.

Selle testimiseks proovige serverit lahendada www.zvnlb.net ja väljund näeb välja nagu oleks näidatud:

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

Pange tähele, et DNS-i lahendaja tagastab mõlemad rakendusserverid niisuguse asemel nagu katastroofi taastamise juhtum.

Kui hostil on rike, muutub DNS-i lahutus automaatselt. Vaadake allpool, mis juhtub.

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

Kasutamata rakendusserver on DNS-i vastuste loendist välja lülitatud.

Niipea kui peremees 188.166.230.211 on taas saadaval, lisatakse see DNS-i lahutusse.

Tsooni delegeerimine Zevenet GSLB teenuses

Avaliku tsooni puhul (nt zvnlb.net), mis pakub GSLB-teenust nimeserveri lahendajana, mille avalikud DNS-serverid peavad selle domeeni jaoks ära tundma, peab GSLB-teenuse kasutatav avalik IP-aadress oma domeeni registripidajas registreerima (nagu NameCheap, Goddady või teised). . Järgmine link selgitab, kuidas GSLB IP-sid domeeniregistri menetluses NameServeritena registreerida.

Registreeri host nimeserverina

Pärast antud protseduuri peate registreerima ns1.zvnlb.net ja ns2.zvnlb.net IP-dega.

GSLB jaoks spetsiaalse alamsooni loomine

Igaks juhuks, kui DNS-i eraldusvõimet pole võimalik delegeerida Zevenet'i GSLB-teenusele, võidakse teha allpool selgitatud konfiguratsioon. Järgmine näide näitab, kuidas a subonoon eest zvnlb.net mis viitab GSLB-teenuse selle uue allone nimeserveritele.

Sõlm 1 (näiteks ns1.zvnlb.net IP-ga 162.243.5.109) Ja Sõlm 2 (näiteks ns2.zvnlb.net IP-ga 178.62.233.104) on nimeserverid konfigureeritud ja pakuvad tsoonile DNS-lahenduse teenuseid zvnlb.net, see tsoon on Bind9i avaliku DNS-teenuse all ja me tahame pakkuda mõnedele meie infrastruktuuri hostidele GSLB-võimeid, seega otsustasime luua DNS-alamsooni cluster.zvnlb.net ja konfigureerige sel eesmärgil 2 GSLB talud nagu DNS nimeserverid.

Oleme loonud meie domeeni alamsooni cluster.zvnlb.net meie Bind9i DNS-serverites järgmiselt:

Nüüd järgige jaotist Tsooni delegeerimine Zevenet GSLB teenuses säilitamiseks 159.89.7.124 ja 159.203.12.35 meie näites tsooni tunnustatud nimeserveritena cluster.zvnlb.net avaliku DNS-serveri poolt.

Seejärel saate rakendada sellist konfiguratsiooni nagu domeenile selgitatud zvnlb.net ülaltoodud jaotises GSLB seadistamine andmekeskuste taastamiseks.

Hostimise suunamine meie enda DNS-i, viidates GSLB-teenusele

Eelmistes osades oleme loonud hosti nimega www.zvnlb.net koormuse tasakaalustamine prioriteetsetes ja ringkäigu režiimides, nii et saame seda konfiguratsiooni uuesti kasutada, et pakkuda GSLB võimalusi teisele DNS-nimeserverile, mis seda funktsiooni vaikimisi ei toeta.

Selle konfiguratsiooni saavutamiseks peame looma ainult uue Ressurss DNS-tsoonis, mis ei toeta GSLB-valikuid (näiteks zevenet.io haldab Bind9) nagu a Kanooniline nimi or CNAME nagu see on allpool näidatud:

Pärast muudatuse rakendamist www.zevenet.io suunab www.zvnlb.net, aga kui vastuvõtva resolutsioon www.zvnlb.net muutub automaatselt www.zevenet.io muutub ka.

Pange tähele, et see näide on tehtud Bind9i DNS-serveris, kuid Canonical Names või CNAMES on DNS-hostikonfiguratsioonid, mida toetavad mis tahes DNS-serveriteenuse rakendused.

See lihtne selgitus näitab, et GSLB-teenust saab kasutada ka siis, kui meie praegune DNS-teenus ei paku GSLB-võimalusi, edastades Zevenet Load Balanceri GSLB-teenusele ainult antud hosti eraldusvõime GSLB-välises tsoonis.