Anycastist on tõenäoliselt paljud kuulnud. Selle aadressijaotuse ja marsruutimise meetodi korral antakse üks IP-aadress mitmele serverile võrgus. Need serverid võivad asuda isegi kaugel üksteisest andmekeskustes. Anycasti idee on see, et sõltuvalt päringu allika asukohast saadetakse andmed lähimale (võrgutopoloogiat ja täpsemalt BGP marsruutimisprotokolli silmas pidades) serverile. Nii on võimalik vähendada võrguületuste arvu (hop) ja viivitust (latency).
Sisuliselt kuulutatakse sama marsruut välja mitmest andmekeskusest üle kogu maailma. Nii suunatakse kliendid „parimasse“ ja „lähimasse“ andmekeskusesse, lähtudes BGP marsruutidest. Miks valida just Anycast? Miks kasutada Anycasti Unicasti asemel?
Unicast sobib tõepoolest veebisaidile, kus on üks veebiserver ja mõõdukas liiklusmaht. Kuid kui teenusel on miljoneid tellijaid, siis kasutatakse tavaliselt mitmeid veebiservereid, millest igaühel on sama IP-aadress. Need serverid on geograafiliselt jaotatud, et saavutada optimaalne päringute teenindamine.
Sellise stsenaariumi korral toob Anycast kaasa jõudluse paranemise (liiklus suunatakse kasutajale minimaalse viivitusega), tagab teenuse usaldusväärsuse (tänu varusse serveritele) ja koormuse tasakaalustamise — marsruutimine mitme serveri vahel jaotab koormuse efektiivselt nende vahel, parandades saidi töö kiirus.
Operaatorid pakuvad klientidele erinevaid Anycasti ja DNS-i põhiseid koormuse tasakaalustamise lahendusi. Kliendid saavad määrata IP-aadressid, kuhu päringud suunatakse vastavalt saidi geograafilisele asukohale. See võimaldab paindlikumalt jaotada kasutajate päringuid.
Kujutame ette, et on mitu platvormi, mille vahel tuleb koormust (kasutajaid) jaotada, näiteks veebipood, mis teenindab 100 000 päringut päevas, või populaarne blogi. Kasutajate sisenemise ala piiramiseks konkreetsele platvormile saab kasutada Geo Community’i valikut. See võimaldab piirata piirkonda, mille raames operaator kuulutab marsruuti.
Anycast ja Unicast: erinevused
Anycast kasutatakse sageli sellistes rakendustes nagu DNS (domeeninimede süsteem) ja CDN (sisu edastamise võrgud), võimaldades langetada marsruutimise otsuseid, mis parandavad võrgu tulemuslikkust. Sisu edastamise võrgud kasutavad Anycast'i, kuna nad tegelevad suurte andmemahtudega, ja Anycast pakub sel juhul mitmeid eeliseid (millest allpool). DNS-is võimaldab Anycast oluliselt suurendada teenuse usaldusväärsust ja rikkega taluvust.
Anycast IP puhul, kasutades BGP-t, on olemas mitu marsruuti konkreetse hosti suunas. Tegelikult on need hostide koopiad mitmes andmekeskuses, mida kasutatakse madalama latentsusega ühenduste loomiseks.
Seega, Anycast võrgus kuulutatakse sama IP-aadress erinevatest kohtadest, ja võrk otsustab, kuhu suunata kasutaja päring, lähtudes marsruudi 'kuludest'. Näiteks kasutatakse sageli andmete edastamise lühema marsruudi määramiseks BGP-protokolli. Kui kasutaja saadab Anycast'i päringu, määrab BGP parima marsruudi Anycast’i võrgus saadaval olevate serverite jaoks.
Anycast'i eelised
Latentsuse vähendamine
Anycastiga süsteemid suudavad vähendada latentsust kasutaja päringute töötlemisel, kuna need võimaldavad andmete saamist lähimalt serverilt. See tähendab, et kasutajad ühenduvad alati 'lähima' (marsruutimisprotokolli vaatenurgast) DNS-serveriga. Selle tulemusena vähendab Anycast suhtluse aega, vähendades võrgu kaugust kliendi ja serveri vahel. See ei vähenda mitte ainult latentsust, vaid tagab ka koormuse tasakaalustamise.
Kiirus
Kuna liiklus suunatakse lähimale sõlmele ja latentsus andmete edastamisel kliendi ja sõlme vahel väheneb, toob see kaasa edastamise kiirusoptimeerimise, olenemata sellest, kust klient teavet küsib.
Suurenenud stabiilsus ja rikketaluvus
Kui mitmed serverid üle kogu maailma kasutavad sama IP-aadressi, siis ühe serveri rikke või selle väljalülitamise korral suunatakse liiklus lähimale serverile. Selle tulemuseks on Anycast teenuse stabiilsemaks muutmine ning parem võrgu/latentsuse/kiirus ligipääsetavus.
Seega, tänu mitme serveri olemasolule, mis on pidevalt kasutajatele kergesti ligipääsetavad, parandab Anycast näiteks DNSi töö stabiilsust. Kui sõlme juhtub ebaõnnestuma, suunatakse kasutajate päringud automaatselt teisele DNS-serverile, ilma käsitsi sekkumiseta või seadistamiseta. Anycast tagab peaaegu sujuva ülemineku teistesse saitidesse, eemaldades lihtsalt probleemse saidi marsruudid.
Koormuse tasakaalustamine
Anycasti süsteemis jagatakse võrgu liiklus erinevate serverite vahel. See tähendab, et see tegutseb koormuse tasakaalustajana, takistades ühelgi üksikul serveril saada peamist liikluskoormust. Koormuse tasakaalustamist võib kasutada näiteks siis, kui mitmed võrgu sõlmed asuvad samal geograafilisel kaugusel päringu allikast. Sellisel juhul jagatakse koormus sõlmede vahel.
Mõjude vähendamine DoS-rünnakutele
Teine Anycasti omadus on vastupidavus DDoS-i suhtes. DDoS-rünnakud ei suuda tõenäoliselt Anycasti süsteemi välja lülitada, kuna kõikide serverite varustamine tohutu hulga päringutega oleks vajalik.
DDoS-rünnakutes kasutatakse sageli botnet'e, mis suudavad genereerida nii suurt liiklust, et see koormab rünnatud serverit. Anycasti kasutamise eelis selles olukorras seisneb selles, et iga server suudab "neelata" osa rünnakust, vähendades seeläbi koormust konkreetsele serverile. Teenuse kättesaamatuse rünnak tõenäoliselt lokaliseeritakse serverisse ja ei mõjuta kogu teenust.
Kõrge horisontaalne skaleeritavus
Anycasti süsteemid sobivad hästi teenustele, mis saavad suure liikluskoormuse. Kui Anycasti kasutav teenus vajab kasvava liikluskoormuse töötlemiseks uusi servereid, on võimalik lisada uusi servereid, et toetada võrgus liikluskorraldust. Need võivad olla paigutatud uutele või juba olemasolevatele platvormidele.
Kui konkreetses kohas on märgatav liikluse tõus, aitab serveri lisamine tasakaalustada koormust antud asukohas. Uue serveri lisamine aitab vähendada ooteaega, luues mõne kasutaja jaoks uue lühema marsruudi. Mõlemad meetodid aitavad ka suurendada teenuse stabiilsust, kuna võrgus on saadaval uued serverid. Seega, kui server on ülekoormatud, saab lihtsalt käivitada teise seal, kus see suudab vastu võtta osa ülekoormatud serveri päringutest. Klientide poolt seadistamist ei ole vaja.
Ainult sellisel viisil on võimalik teenindada terabitte liiklust ja väga suurt kasutajate arvu, kui serveril on vaid mõned 10 või 25 Gbit/s porti. 100 hosti ühel IP-aadressil võimaldab töödelda terabittide suuruseid liiklusmahte.
Konfiguratsiooni lihtsus
Nagu juba eespool mainitud, on huvitev Anycast'i kasutamine — DNS. Võib paigutada võrgus mitmeid erinevaid DNS-servereid, kuid kasutada ühte DNS-aadressi. Sõltuvalt sellest, kus allikas asub, suunatakse päringud lähimasse sõlme. See tagab teatud liikluse tasakaalu ja üleliigsuse DNS-serveri tõrgete korral. Seega, selle asemel, et seadistada erinevaid DNS-servereid vastavalt nende asukohale, saab ühe DNS-serveri konfiguratsiooni levitada kõigisse sõlmedesse.
Anycast-võrke saab seadistada päringute suunamiseks mitte ainult kauguse põhjal, vaid ka selliste parameetrite nagu serveri olemasolu, ühenduste arv või vastamisaeg järgi.
Anycast-tehnoloogia kasutamiseks ei ole klientide poolt vajalikud erilised serverid, võrgud ega spetsiaalsed komponendid. Kuid Anycast'il on ka puudused. Peetakse, et selle rakendamine on keeruline ülesanne, mis nõuab lisavarustust, usaldusväärseid teenusepakkujaid ja õiget liikluse suunamist.
Puhtast allikast kaunisse kaugusse
Kuigi Anycast suunab kasutajad põhjal lähtudes vähimatest üleminekute arvudest, ei tähenda see tingimata minimaalset latentsust. Latentsus on keerulisem mõõdik, kuna ühel üleminekul võib see olla kõrgem kui kümnel.
Näide: vahemaaülesed sidekanalid võivad hõlmata ühte üleminekut, millel on väga kõrge viivitus.
Anycastit kasutatakse peamiselt UDP-põhiste teenuste, nagu DNS, jaoks. Kasutajate päringud suunatakse "parimale" ja "lähedasematele" andmekeskustele, tuginedes BGP marsruutidele.
Näide: DNS-i kliendi tööjaam, millel on Anycast DNS-i IP-aadress 123.10.10.10, teostab DNS-i lahenduse kolme DNSi nime serveri jaoks, mis on juurutatud sama Anycast IP-aadressi abil. Kui marsruuter R1 või server A ebaõnnestub, suunatakse DNS-i kliendi paketid automaatselt järgmisele lähimale DNS-serverile marsruuterite R2 ja R3 kaudu. Pealegi eemaldatakse marsruut meie serverisse A marsruutimislaudadest, mis takistab edasist nende nimeteenuse serverite kasutamist.
Juhtumite juurutamine
On kaks levinud skeemi, mida kasutatakse selle määramiseks, millise serveriga kasutaja ühendub:
- Anycast võrgu tasemel. Ühendab kasutaja lähima serveriga. Siin on oluline kasutaja ja serveri vaheline võrgutee.
- Anycast rakenduse tasemel. Selles skeemis on rohkem arvutatud mõõdikuid, sealhulgas serveri kättesaadavus, reageerimisaeg, ühenduste arv jne. See sõltub välist jälgimisest, mis pakub võrgu statistikat.
Anycast-põhine CDN
Tagasi Anycasti kasutamise juurde sisu edastamisvõrkudes. Anycast on kindlasti huvitav võrgu kontseptsioon ja omandab üha suuremat tunnustust uue põlvkonna CDN-i pakkujates.
CDN on serverite jaotatud võrk, mis edastab sisu lõppkasutajatele kõrge saadavuse ja madala viivitusega. Sisu edastamisvõrgud mängivad täna olulist rolli, olles aluseks paljudele multimeedia online-teenustele, samas kui tarbijad on üha vähem sallivad aeglastes laadimiskiirus.
CDN ühendab kõik serverid ühte võrku, tagades kiirema sisu laadimise. Mõnikord suudab see vähendada kasutaja ootamise aega 5-6 sekundi võrra. CDN-i eesmärk on sisu edastamise optimeerimine, pakkudes sisu serverist, mis asub kõige lähemal lõppkasutajale. See on väga sarnane Anycast'ile, kus valitakse lähim server sõltuvalt lõppkasutaja asukohast. Tundub, et iga CDN-teenusepakkuja kasutab Anycast'i vaikimisi, kuid tegelikult ei ole see nii.
Rakendused, mis kasutavad protokolle nagu HTTP/TCP, tuginevad seadistatavale ühendusele. Kui valitakse uus Anycast-sõlm (nt serveri rikke korral), võib teenuse osutamine katkeda. Seetõttu soovitati Anycast'i varem selliste ühenduseta teenuste, nagu UDP ja DNS, jaoks. Sellegipoolest töötab Anycast hästi ka ühendusele suunatud protokollide puhul, näiteks TCP toimib Anycast režiimis suurepäraselt.
Mõned CDN-teenusepakkujad kasutavad Anycast-põhist marsruutimist, teised eelistavad DNS-põhist marsruutimist: lähim server valitakse sõltuvalt sellest, kus asub kasutaja DNS-server.
Hübriidstruktuurid ja mitme andmekeskuse infrastruktuurid on veel üks näide Anycast'i rakendamisest. Teenusepakkujalt saadud Load Balancing IP aadress võimaldab koormust jaotada erinevate kliendi teenuste IP-aadresside vahel teenusepakkuja andmekeskuses. Aadressimise tehnoloogia tõttu tõhusam koostöö igas seadmes tagab parema jõudluse märkimisväärse liikluse korral, kõrgema töökindluse ja aitab optimeerida vastusaega suurte kasutajate arvuga.
Hübriidstruktuurides, kus on mitu andmekeskust, on võimalik jaotada liiklus serverite või isegi virtuaalsete masinate vahel pühendatud serverites.
Seega on olemas suur valik tehnilisi lahendusi infrastruktuuri rajamiseks. Samuti on võimalik seadistada IP-aadresside põhine koormuse jagamine mitmes andmekeskuses, kasutades grupi igas seadmes adresseerimist saidi toimimise optimeerimiseks.
Saate levitada liiklust vastavalt oma reeglitele, määrates igas andmekeskuses jaotatud serverite "kaalu". Selline konfiguratsioon on eriti kasulik, kui on olemas jaotatud serverite park ja teenuste jõudlus on erinev. See võimaldab sagedamini levitada liiklust serverite jõudluse suurendamiseks.
Ping-käskluse abil kontrollsüsteemi loomiseks on võimalik konfigureerida sensoreid. See võimaldab administraatoril määratleda oma kontrolliprotseduurid ning saada selgema ülevaate iga infrastruktuuri komponendi seisundist. Nii saab määratleda kriteeriumid kättesaadavuse hindamiseks.
On võimalik luua hübriidinfrastruktuur: mõnikord on mugav jätta tagabüroo ettevõtte võrgus, samas kui liidestusosa antakse väljaandjatele.
On võimalik lisada SSL-sertifikaate koormuse tasakaalustamiseks, edastatavate andmete krüpteerimiseks ja ühenduse turvamiseks külastajate ja ettevõtte infrastruktuuri vahel. Koormuse tasakaalustamisel andmekeskuste vahel on samuti võimalik rakendada SSL-i.
Anycasti teenust koos aadresside koormuse tasakaalustamisega saab osutada teenusepakkuja. See funktsioon aitab parandada kasutajate ja rakenduste vahelist interaktsiooni vastavalt asukohale. Piisab, kui kuulutada, millised teenused on andmekeskuses, ja liiklus suunatakse lähimasse infrastruktuuri. Kui on pühendatud serverid, näiteks Prantsusmaal või Põhja-Ameerikas, suunatakse kliendid lähimasse serverisse võrgus.
Üks Anycasti kasutusvõimalusi on operaatori kohaloleku punkti (PoP) optimaalse valiku tegemine. Näiteks: . LinkedIn (Venemaal blokeeritud) püüab mitte ainult parandada oma toodete — mobiilsete ja veebirakenduste — jõudlust ja kiirus, vaid ka täiustada võrgu infrastruktuuri sisu kiiremaks edastamiseks. Selleks kasutab LinkedIn aktiivselt punktide kohaloleku (PoP) dünaamilise sisu edastamise jaoks. Kasutajad suunatakse lähimasse PoP-i, rakendades Anycast'i.
Põhjus on see, et Unycasti puhul on igal PoP-i LinkedInil ainulaadne IP-aadress. Seejärel määratakse kasutajad PoP-i vastavalt nende geograafilisele asukohale DNS-i kaudu. Probleem on selles, et DNS-i kasutamisel suunati umbes 30% kasutajatest Ameerika Ühendriikides mitteoptimaalsele PoP-ile. Tänu Anycasti etapiviisilisele kasutusele võeti mitteoptimaalne PoP-i määramine, mis langes 31%-lt 10%-ni.
Pilootkatse tulemused on esitatud graafikuna, kus Y-teljel on protsent optimaalsest PoP-i määramisest. Anycasti "koormuse suurendamisel" mitmes Ameerika osariigis on täheldatud parendust optimaalse PoP-i liikluses.
Anycasti võrgu jälgimine
Teoreetiliselt on Anycasti võrgud lihtsad: mitmele füüsilisele serverile antakse sama IP-aadress, mida BGP kasutab marsruudi määramiseks. Kuid Anycasti platvormide rakendamine ja projekteerimine on keeruline, eriti on selles osas tuntud talitlushäirete kindluse Anycasti võrgud. Veelgi keerulisem on tõhus Anycasti võrgu jälgimine vigade kiireks tuvastamiseks ja lokaliseerimiseks.
Kui teenused kasutavad sisu teenindamiseks kolmanda osapoole CDN-i, on neil väga oluline jälgida ja kontrollida võrgu jõudlust. Anycasti põhinev CDN-i jälgimine keskendub peamiselt viivitusaja ja eelviimase hüppeliigendi omaduste mõõtmisele, et mõista, milline andmekeskus teenindab sisu. HTTP-serveri päiste analüüs on veel üks viis määrata, kust andmed pärinevad.
Näide: HTTP-vastuse päised, mis näitavad CDN-i serveri asukohta.
Näiteks kasutab CloudFlare oma HTTP-vastustes oma CF-Ray pealkirja, mis sisaldab teavet andmekeskuse kohta, kuhu päring on suunatud. Näiteks Zendiski puhul tähistab Seattle'i piirkonna CF-Ray pealkiri CF-RAY: 2a21675e65fd2a3d-SEA ja Amsterdamile CF-RAY: 2a216896b93a0c71-AMS. Samuti võib määrata, kus sisu asub, kasutades HTTP-X-päiseid HTTP-vastuses.
Teised aadressimisviisid
Kasutajate päringute suunamiseks konkreetsele võrgu lõpp-punktile on olemas ka teised aadressimisviisid:
Unicast
Enamik tänapäeva internetist kasutab just seda meetodit. Unicast on üheaadressiline edastus, IP-aadress on seotud ainult ühe konkreetse sõlmega võrgus. Seda nimetatakse vastastikku eksklusiivseks vastavuseks.
Multicast
Multicast kasutab ühte-kohta-mitmele või mitmest-mitmele-side. Multicast võimaldab saatjal saata päringu samaaegselt erinevatele valitud lõpupunktidele. See annab kliendile võimaluse laadida faili osade kaupa mitmelt hostilt samal ajal (mis on kasulik audio- või videovoo jaoks). Multicast segi aetakse sageli Anycastiga, kuid peamine erinevus seisneb selles, et Anycast suunab saatja konkreetsele sõlmele, isegi kui mitu sõlme on saadaval.
Broadcast
Datagramm, mille saadab üksainus saatja, suunatakse kõikidele lõpupunktidele, mis on seotud laiekraaniga aadressiga. Võrk kopeerib automaatselt datagramme, et olla suuteline ühendust pidama kõigi vastuvõtjatega laiekirjade saatmisel (tavaliselt ühes alamvõrgus).
Geocast
Geocast sarnaneb osaliselt Multicastiga: saatja päringud suunatakse samaaegselt mitmele lõpupunktile. Kuid erinevus seisneb selles, et adressaat määratakse tema geograafilise asukoha järgi. See on spetsialiseeritud grupi adresseerimise vorm, mida kasutavad mõned marsruutimisprotokollid mobiilsetes peer-to-peer võrkudes.
Geograafiline marsruuter (Geo Router) arvutab oma teeninduspiirkonna ja ligikaudse selle. Geomarsruuterid, vahetades teeninduspiirkondi, koostavad marsruuditabelid. Geomarsruuterite süsteemil on hierarhiline struktuur.
Unicast, Multicast ja Broadcast.
Anycast tehnoloogia kasutamine suurendab DNS-i usaldusväärsust, vigade taluvust ja turvalisust. Kasutades seda tehnoloogiat, pakuvad operaatorid oma klientidele erinevaid DNS-i põhiseid koormuse tasakaalustamise teenuseid. Kontrollpaneelis saab määrata IP-aadresse, milleni päringud saadetakse geograafilise lokaliseerimise põhjal. See annab klientidele võimaluse jaotada kasutajate päringud paindlikumalt.
Mõned operaatorid rakendavad marsruuditööd igas kohaloleku punktis (POP): süsteem analüüsib automaatselt kõige lühemaid kohalikke ja globaalseid marsruute kohaloleku punktides ning suunab need geograafiliste asukohtade kaudu, kus viivitus on minimaalne ja töökatkestusi pole.
Praegu on Anycast kõige stabiilsem ja usaldusväärsem lahendus kõrge koormusega DNS-teenuste loomiseks, mis peavad vastama tugevatele nõudmistele stabiilsuse ja usaldusväärsuse osas.
.ru domeen toetab 35 Anycast DNS-serverit, mis on grupeeritud 20 sõlme, jaotatuna viie Anycast-pilve vahel. Sellega rakendatakse geograafilise printsiipi, st Geocast. DNS-sõlmede paigutamisel on arvesse võetud nende viimist geograafiliselt hajutatud asukohtadesse, mis on lähedased kõige aktiivsematele kasutajatele, Venemaa teenusepakkujate maksimaalne kontsentratsioon sõlme paigutuspunktis, samuti vabad kapatsiteed ja mugav, koostööd toetav keskkond.
Kuidas luua CDN?
CDN on serverite võrk, mis kiirendab sisu edastamist kasutajatele. ühendab kõik serverid ühte võrku ja tagab sisu kiirema laadimise. Laadimise kiirus sõltub olulisel määral serveri ja kasutaja vahelisest kaugusest.
CDN võimaldab kasutada servereid, mis asuvad sihtrühmale kõige lähemal. See vähendab ooteaega, aitab kiirendada veebisaitide sisu laadimist kõigile külastajatele, mis on eriti kriitiline suurte failide või multimeedia teenuseid pakkuvate veebisaitide puhul. CDN tüüpilised rakendusalad on e-kaubandus ja meelelahutus.
CDN infrastruktuuris loodud lisaserverite võrk, mis asub kasutajatele maksimaalselt lähedal, soodustab andmete stabiilsemat ja kiiremat edastamist. Statistika kohaselt vähendab CDN-i kasutamine viivitust saidile pääsemisel rohkem kui 70% võrreldes saitidega, mis ei kasuta CDN-i.
Kuidas? Настройка CDN с использованием собственного решения Anycast может быть достаточно дорогим проектом, но есть более дешевые варианты. Например, можно использовать GeoDNS и обычные серверы с уникальными IP-адресами. С помощью сервисов GeoDNS можно создать CDN с функциями геолокации, в которой решения принимаются на основе реального местоположения посетителя, а не местоположения ресолвера DNS. Можно настроить свою DNS-зону так, чтобы показывать IP-адреса американских серверов посетителям из США, а европейские посетители будут видеть IP-адрес из Европы.
GeoDNS-i abil saab tagasi anda erinevaid DNS-vastuseid sõltuvalt kasutaja IP-aadressist. Selleks seadistatakse DNS-server nii, et see tagastab erinevad IP-aadressid vastavalt päringu algsele IP-aadressile. Üldiselt kasutatakse päringu teostamise piirkonna määramiseks GeoIP andmebaasi. DNS-i geolokatsioon võimaldab saata kasutajatele sisu lähimast saidist.
GeoDNS määrab kliendi, kes DNS-i päringu edastas, IP-aadressi või IP-aadressi rekursiivsest DNS-serverist, mida kasutatakse kliendi päringu töötlemisel. Klientide IP-aadressi ja GeoIP andmebaasi põhjal tuvastatakse riik/region. Seejärel saab klient lähima CDN-serveri IP-aadressi. GeoDNS seadistamisest saab lähemalt lugeda.
Anycast või GeoDNS?
Kuigi Anycast on suurepärane sisu edastamise meetod globaalsetes mõõtkavades, ei ole tal piisavalt spetsiifilisust. Siin tulebki appi GeoDNS. See teenus võimaldab määrata reegleid, mis suunavad kasutajad ainulaadsetele lõpp-punktidele sõltuvalt nende asukohast.
Näide: Euroopast pärit kasutajad suunatakse teisele lõpp-punktile.
Samuti saab keelata juurdepääsu domeenidele, kõrvaldades kõik päringud. See on näiteks kiire viis pahatahtlike kasutajate tõrjumiseks.
GeoDNS annab täpsemaid vastuseid kui Anycast. Kui Anycast puhul määratakse lühim marsruut hüpete arvu põhjal, siis GeoDNS-is suunatakse lõppkasutajad nende füüsilise asukoha põhjal. See vähendab latentsi ja suurendab täpsust granulaarsuse reeglite loomisel.
Domeeni külastades pöördub brauser lähima DNS-serveri poole, mis, sõltuvalt domeenist, väljastab IP-aadressi saidi laadimiseks. Oletame, et internetipood on populaarne Ameerikas ja Euroopas, ning DNS-serverid on ainult Euroopas. Siis Ameerikast pärit kasutajad, kes soovivad poodi kasutada, peavad edastama päringu lähimale serverile, ja kuna see asub väga kaugel, tuleb tal kaua oodata vastust — saidi laadimine ei toimu kiiresti.
GeoDNS-serveri paigutamine USA-sse tähendab, et kasutajad pöörduvad juba selle poole. Vastus tuleb kiiresti, mis mõjutab saidi laadimiskiirust.
Situatsioonis, kus olemas on DNS-server Ameerikas, pöördub Ameerika kasutaja selle domeeni külastades lähima serveri poole, mis väljastab vajaliku IP-aadressi. Kasutaja suundub serverisse, mis sisaldab saidi sisu, kuid kuna sisuserverid asuvad kaugel, ei saa ta seda kiiresti kätte.
Kui asetada USA-s ja CDN-serverid vahemälus olevate andmetega, siis brauseri laadimisel saadab kliendi brauser päringu lähimale DNS-serverile, mis saadab tagasi vajaliku IP-aadressi. Brauser, saades IP, pöördub lähima CDN-serveri ja põhiserveri poole ning CDN-server edastab brauserile vahemälus oleva sisu. Samuti saadetakse põhiserverilt puuduolevad failid, et laadida täiskohta. Selle tulemusena väheneb saidi laadimisaeg, kuna põhiserverilt saadetavate failide arv on palju väiksem.
Määrata täpset asukohta antud IP-aadressile pole alati lihtne ülesanne: siin mängivad rolli paljud tegurid ja IP-aadresside vahemike omanikud võivad otsustada, et muudavad selle teisele maailma otsale (siis tuleb oodata, kuni andmebaas on uuendatud, et saada õige asukoht). Mõnikord määravad VPS-teenuse pakkujad aadresse, mis väidetavalt asuvad USA-s, Singapuri VPS-ile.
Erinevalt Anycast-aadresside kasutamisest toimub jaotamine nimede lahendamise ajal, mitte vahemäluserveri ühendamise ajal. Kui rekurssiivne server ei toeta kliendi alamvõrke EDNS, kasutatakse selle rekurssiivse serveri asukohta, mitte kasutaja oma, kes ühendub vahemäluserveriga.
DNS-i kliendi alamvõrgud on DNS-i laiendus (RFC7871), mis määratleb, kuidas rekurssiivsed DNS-serverid saavad saata kliendi teavet DNS-serverile, eriti teavet võrgu kohta, mida GeoDNS-server saab kasutada kliendi asukoha täpsemaks määramiseks.
Enamik inimesi kasutab oma internetiteenuse pakkuja DNS-servereid või geograafiliselt lähedasi DNS-servereid, kuid kui keegi USA-s mingil põhjusel otsustab kasutada Austraalias asuvat DNS-resolverd, saab ta tõenäoliselt IP-aadressi serverist, mis asub kõige lähemal Austraalias.
Kui soovite kasutada GeoDNS-i, on oluline teada selliseid omadusi, kuna mõnel juhul võib see suurendada vahet vahemäluservede ja kliendi vahel.
Kokkuvõte: kui soovite ühendada mitut VPS-i CDN-iks, on parim juurutusvõimalus kasutada DNS-serverit GeoDNS-i funktsiooni ja Anycast'i koos toimimiseks.
Allikas: habr.com
