Anycast vs Unicast: kumb on igal juhul parem valida

Tõenäoliselt on paljud inimesed Anycastist kuulnud. Selle võrguaadressi ja marsruutimise meetodi puhul määratakse võrgus mitmele serverile üks IP-aadress. Need serverid võivad asuda isegi üksteisest kaugel asuvates andmekeskustes. Anycasti idee seisneb selles, et olenevalt päringu allika asukohast saadetakse andmed lähimasse (vastavalt võrgu topoloogiale, täpsemalt BGP marsruutimisprotokolli) serverisse. Nii saate vähendada võrguhüpete arvu ja latentsust.

Põhimõtteliselt reklaamitakse sama marsruuti mitmest andmekeskusest üle maailma. Seega saadetakse kliendid BGP marsruutide alusel "parimale" ja "lähimale" andmekeskusesse. Miks Anycast? Miks kasutada Unicasti asemel Anycasti?

Anycast vs Unicast: kumb on igal juhul parem valida
Unicast sobib tõesti ühe veebiserveri ja mõõduka liiklusega saidile. Kui teenusel on aga miljoneid tellijaid, kasutab see tavaliselt paljusid veebiservereid, millest igaühel on sama IP-aadress. Need serverid on päringute optimaalseks teenindamiseks geograafiliselt jaotatud.

Selle stsenaariumi korral parandab Anycast jõudlust (liiklus saadetakse kasutajale minimaalse viivitusega), tagab teenuse usaldusväärsuse (tänu varuserveritele) ja koormuse tasakaalustamise - mitmele serverile marsruutimine jaotab koormuse tõhusalt nende vahel, parandades kiirust. saidilt.

Operaatorid pakuvad klientidele erinevat tüüpi koormuse tasakaalustamist, mis põhinevad Anycastil ja DNS-il. Kliendid saavad saidi geograafilise asukoha alusel määrata IP-aadressid, kuhu päringud saadetakse. See võimaldab kasutajate taotlusi paindlikumalt levitada.

Oletame, et on mitu saiti, mille vahel peate koormuse (kasutajad) jaotama, näiteks veebipood 100 000 päringuga päevas või populaarne ajaveeb. Piirkonna piiramiseks, kust kasutajad konkreetsele saidile pääsevad, saate kasutada Geo Community valikut. See võimaldab teil piirata piirkonda, kus operaator marsruuti reklaamib.

Anycast vs Unicast: kumb on igal juhul parem valida

Anycast vs Unicast: kumb on igal juhul parem valida
Anycast ja Unicast: erinevused

Anycasti kasutatakse sageli sellistes rakendustes nagu DNS (domeeninimesüsteem) ja CDN (sisu edastamise võrgud), võimaldades teha võrgu jõudlust parandavaid marsruutimisotsuseid. Sisu edastamise võrgud kasutavad Anycasti, kuna need tegelevad suurte liiklusmahtudega ja Anycast pakub sel juhul mitmeid eeliseid (nende kohta lähemalt allpool). DNS-is võimaldab Anycast märkimisväärselt tõsta teenuse töökindluse ja tõrketaluvuse taset.

Anycast vs Unicast: kumb on igal juhul parem valida
Anycasti IP puhul on BGP kasutamisel mitu marsruuti konkreetsesse hosti. Need on tegelikult mitmes andmekeskuses asuvate hostide koopiad, mida kasutatakse väiksema latentsusega ühenduste loomiseks.

Niisiis reklaamitakse Anycasti võrgus sama IP-aadressi erinevatest kohtadest ja võrk otsustab, kuhu kasutaja päring suunata, lähtudes marsruudi "kulust". Näiteks kasutatakse BGP-d sageli andmeedastuse lühima marsruudi määramiseks. Kui kasutaja saadab Anycasti päringu, määrab BGP võrgus saadaolevate Anycasti serverite jaoks parima marsruudi.

Anycasti eelised

Latentsuse vähendamine
Anycastiga süsteemid võivad kasutaja päringute töötlemisel latentsusaega vähendada, kuna need võimaldavad teil saada andmeid lähimast serverist. See tähendab, et kasutajad loovad alati ühenduse "lähima" (marsruutimisprotokolli seisukohast) DNS-serveriga. Selle tulemusena vähendab Anycast interaktsiooniaega, vähendades võrgu vahemaad kliendi ja serveri vahel. See mitte ainult ei vähenda latentsust, vaid tagab ka koormuse tasakaalustamise.

Kiirus

Kuna liiklus suunatakse lähimasse sõlme ning kliendi ja sõlme vaheline latentsusaeg väheneb, on tulemuseks optimeeritud tarnekiirus, olenemata sellest, kust klient teavet küsib.

Suurenenud stabiilsus ja veataluvus

Kui mitu serverit üle maailma kasutavad sama IP-d, siis kui üks serveritest ebaõnnestub või katkeb, suunatakse liiklus lähimasse serverisse. Selle tulemusena muudab Anycast teenuse vastupidavamaks ja pakub paremat juurdepääsu võrgule / latentsust / kiirust. 

Seega, kuna kasutajatel on pidevalt saadaval mitu serverit, parandab Anycast näiteks DNS-i stabiilsust. Kui sõlm ebaõnnestub, suunatakse kasutajate päringud ilma käsitsi sekkumise või ümberseadistamiseta teise DNS-serverisse. Anycast pakub praktiliselt läbipaistvat üleminekut teistele saitidele, eemaldades lihtsalt probleemse saidi marsruudid. 

Koormuse tasakaalustamine

Anycastis jaotatakse võrguliiklus erinevate serverite vahel. See tähendab, et see toimib koormuse tasakaalustajana, takistades ühelgi serveril suuremat osa liiklusest vastu võtmast. Koormuse tasakaalustamist saab kasutada näiteks siis, kui päringu allikast samal geograafilisel kaugusel on mitu võrgusõlme. Sel juhul jaotatakse koormus sõlmede vahel.

Vähendage DoS-rünnakute mõju 

Teine Anycasti omadus on selle DDoS-kindlus. Tõenäoliselt ei suuda DDoS-i rünnakud Anycasti süsteemi hävitada, kuna need peaksid kõik sellises võrgus olevad serverid päringute laviiniga üle koormama. 

DDoS-i rünnakud kasutavad sageli robotvõrke, mis võivad tekitada nii palju liiklust, et koormavad rünnatud serverit üle. Anycasti kasutamise eelis selles olukorras on see, et iga server suudab osa rünnakust "imada", mis vähendab selle konkreetse serveri koormust. Teenuse keelamise rünnak lokaliseeritakse suure tõenäosusega serverisse ega mõjuta kogu teenust.

Kõrge horisontaalne mastaapsus

Anycasti süsteemid sobivad hästi suure liiklusega teenuste jaoks. Kui Anycasti kasutav teenus nõuab suurenenud liikluse haldamiseks uusi servereid, saab selle haldamiseks võrku lisada uusi servereid. Neid saab paigutada uutele või olemasolevatele saitidele. 

Kui konkreetses asukohas on liiklus oluliselt suurenenud, aitab serveri lisamine selle saidi koormust tasakaalustada. Serveri lisamine uuele saidile aitab ooteaegu lühendada, luues mõne kasutaja jaoks uue lühima marsruudi. Mõlemad meetodid aitavad parandada ka teenuse stabiilsust, kuna võrgus muutuvad kättesaadavaks uued serverid. Kui server on ülekoormatud, saate sel viisil lihtsalt juurutada teise serveri asukohta, mis võimaldab tal teatud osa ülekoormatud serveri päringutest vastu võtta. See ei nõua klientidelt mingeid konfiguratsioone. 

Ainult nii saab teenindada terabitti liiklust ja väga suurt hulka kasutajaid, kui serveril on vaid paar 10 või 25 Gbps porti. 100 ühe IP-aadressiga hosti võimaldavad töödelda terabitist liiklust.

Lihtne konfiguratsioonihaldus

Nagu eespool märgitud, on Anycasti huvitav kasutusala DNS. Võrgusõlmedesse saate paigutada mitu erinevat DNS-serverit, kuid kasutada ühte DNS-aadressi. Sõltuvalt allika asukohast suunatakse päringud lähimasse sõlme. See tagab DNS-serveri tõrke korral teatud liikluse tasakaalustamise ja koondamise. Nii saab erinevate DNS-serverite konfigureerimise asemel sõltuvalt nende asukohast ühe DNS-serveri konfiguratsiooni levitada kõikidesse sõlmedesse.

Anycasti võrke saab konfigureerida päringuid suunama mitte ainult kauguse, vaid ka parameetrite, näiteks serveri olemasolu, loodud ühenduste arvu alusel. või reageerimisaeg.

Anycasti tehnoloogia kasutamiseks pole kliendi poolel vaja spetsiaalseid servereid, võrke ega erikomponente. Kuid Anycastil on ka oma varjuküljed. Arvatakse, et selle rakendamine on keeruline ülesanne, mis nõuab lisavarustust, usaldusväärseid pakkujaid ja õiget liikluse suunamist.

Kaugel puhtast allikast iluni

Kuigi Anycast suunab kasutajad kõige vähemate hüpete alusel, ei tähenda see tingimata madalaimat latentsust. Latentsusaeg on keerulisem mõõdik, kuna see võib ühe ülemineku puhul olla suurem kui kümne puhul.

Anycast vs Unicast: kumb on igal juhul parem valida
Näide: Mandritevaheline side võib hõlmata ühte hüpet väga suure latentsusega.

Anycasti kasutatakse peamiselt UDP-põhiste teenuste (nt DNS) jaoks. Kasutajate päringud suunatakse BGP marsruutide alusel parimasse ja lähimasse andmekeskusesse.

Anycast vs Unicast: kumb on igal juhul parem valida
Näide: DNS-kliendi tööjaam, mille Anycasti DNS-i IP-aadress on 123.10.10.10, teostab DNS-i eraldusvõime kolmest sama Anycasti IP-aadressi abil juurutatud DNS-i nimeserverist, mis on lähim. Kui ruuter R1 või server A ebaõnnestub, suunatakse DNS-kliendi paketid ruuterite R2 ja R3 kaudu automaatselt järgmisele lähimale DNS-serverile. Lisaks eemaldatakse marsruutimistabelitest marsruut meie serverisse A, mis takistab selle nimeserveri edasist kasutamist.

Kasutuselevõtu stsenaariumid

On kaks üldist skeemi, mida kasutatakse selleks, et määrata, millise serveriga kasutaja ühenduse loob:

  • Anycasti võrgukiht. Ühendab kasutaja lähima serveriga. Siin on oluline võrgutee kasutajast serverini.
  • Rakenduse tase anycast. Sellel skeemil on rohkem arvutatud mõõdikuid, sealhulgas serveri saadavus, reageerimisaeg, ühenduste arv jne. See sõltub välisest monitorist, mis pakub võrgustatistikat.

CDN, mis põhineb Anycastil

Pöördume nüüd tagasi Anycasti kasutamise juurde sisu edastamise võrkudes. Anycast on kindlasti huvitav võrgukontseptsioon ja kogub järgmise põlvkonna CDN-i pakkujate seas üha enam heakskiitu.

CDN on hajutatud serverite võrk, mis edastab sisu lõppkasutajatele kõrge kättesaadavuse ja madala latentsusajaga. Sisu edastamise võrgud mängivad tänapäeval olulist rolli paljude võrgumeediateenuste selgroona ja tarbijad taluvad üha vähem aeglast allalaadimiskiirust. Video- ja kõnerakendused on eriti tundlikud võrgu värina ja latentsuse suhtes.

CDN ühendab kõik serverid ühte võrku ja tagab sisu kiirema laadimise. Mõnikord on võimalik vähendada kasutaja ooteaega 5-6 sekundi võrra. CDN-i eesmärk on optimeerida edastamist, teenindades sisu lõppkasutajale kõige lähemal asuvast serverist. See on väga sarnane Anycastiga, kus lähim server valitakse lõppkasutaja asukoha põhjal. Näib, et iga CDN-i teenusepakkuja kasutaks vaikimisi Anycasti, kuid tegelikult see nii pole.

Selliseid protokolle nagu HTTP/TCP kasutavad rakendused sõltuvad ühenduse loomisest. Kui valitakse uus Anycasti sõlm (näiteks serveri rikke tõttu), võib teenus katkeda. Seetõttu soovitati Anycasti varem ühenduseta teenuste jaoks, nagu UDP ja DNS. Kuid Anycast töötab hästi ka ühendusele orienteeritud protokollide puhul; näiteks TCP töötab hästi Anycasti režiimis.

Mõned CDN-i pakkujad kasutavad Anycasti-põhist marsruutimist, teised eelistavad DNS-põhist marsruutimist: lähim server valitakse selle järgi, kus kasutaja DNS-server asub.

Hübriid- ja mitme andmekeskuse infrastruktuurid on veel üks näide Anycasti kasutamisest. Pakkujalt saadud koormuse tasakaalustamise IP-aadress võimaldab jagada koormust erinevate klienditeenuste IP-aadresside vahel pakkuja andmekeskuses. Tänu mis tahes seadme tehnoloogiale tagab see parema jõudluse tiheda liikluse korral, veataluvuse ja aitab optimeerida reageerimisaega, kui tegemist on suure hulga kasutajatega.

Hübriidsetes mitme andmekeskuse infrastruktuurides saate jagada liiklust serverite või isegi spetsiaalsetes serverites olevate virtuaalmasinate vahel.

Seega on infrastruktuuri ehitamise tehniliste lahenduste valik tohutu. Samuti saate konfigureerida koormuse tasakaalustamist IP-aadresside vahel mitmes andmekeskuses, sihtides saidi jõudluse optimeerimiseks rühma mis tahes seadet.

Saate liiklust jaotada vastavalt oma reeglitele, määratledes igas andmekeskuses iga hajutatud serveri "kaalu". See konfiguratsioon on eriti kasulik, kui on olemas hajutatud serveripark ja teenuste jõudlus on ebaühtlane. See võimaldab serveri jõudluse parandamiseks liiklust sagedamini jaotada.

Seiresüsteemi loomiseks käsuga ping on võimalik sonde seadistada. See võimaldab administraatoril määratleda oma seireprotseduurid ja saada selgema pildi infrastruktuuri iga komponendi olekust. Sel viisil saab määratleda juurdepääsetavuse kriteeriumid.

Hübriidtaristut on võimalik ehitada: mõnikord on mugav jätta tagakontor ettevõtte võrku ja liidese osa tellida pakkujalt.

Võimalik on lisada SSL-sertifikaate koormuse tasakaalustamiseks, edastatavate andmete krüptimiseks ning saidi külastajate ja ettevõtte infrastruktuuri vahelise suhtluse turvalisuse tagamiseks. Andmekeskuste vahelise koormuse tasakaalustamise korral saab kasutada ka SSL-i.

Aadressi koormuse tasakaalustamisega Anycasti teenust saate oma teenusepakkujalt. See funktsioon aitab parandada seda, kuidas kasutajad asukohapõhiselt rakendustega suhtlevad. Piisab andmekeskuses pakutavate teenuste väljakuulutamisest ja liiklus suunatakse lähimasse infrastruktuuri. Kui on olemas spetsiaalsed serverid, näiteks Prantsusmaal või Põhja-Ameerikas, suunatakse kliendid võrgu lähimasse serverisse.

Üks Anycasti kasutamise võimalustest on operaatori kohalolekupunkti (PoP) optimaalne valik. Anname näide. LinkedIn (Venemaal blokeeritud) ei püüa mitte ainult parandada oma toodete – mobiili- ja veebirakenduste – jõudlust ja kiirust, vaid ka parandada oma võrguinfrastruktuuri sisu kiiremaks edastamiseks. Selle dünaamilise sisu edastamise jaoks kasutab LinkedIn aktiivselt PoP-sid – kohalolekupunkte. Anycasti kasutatakse kasutajate suunamiseks lähimasse PoP-i.

Põhjus on selles, et Unycasti puhul on igal LinkedIn PoP-l kordumatu IP-aadress. Seejärel määratakse kasutajad DNS-i abil PoP-i nende geograafilise asukoha alusel. Probleem on selles, et DNS-i kasutamisel suunati umbes 30% USA kasutajatest mitteoptimaalsele PoP-le. Anycasti järkjärgulise rakendamisega langes ebaoptimaalne PoP määramine 31%-lt 10%-le.

Anycast vs Unicast: kumb on igal juhul parem valida
Piloottesti tulemused on näidatud graafikul, kus Y-telg on optimaalse PoP määramise protsent. Anycasti kasvades nägid paljud USA osariigid liikluse protsendi paranemist optimaalse PoP-i suunas.

Anycasti võrgu jälgimine

Anycasti võrgud on teoreetiliselt lihtsad: mitmele füüsilisele serverile määratakse sama IP-aadress, mida BGP kasutab marsruudi määramiseks. Kuid Anycasti platvormide juurutamine ja disain on keeruline ning tõrketaluvusega Anycasti võrgud on selle poolest eriti kuulsad. Veelgi keerulisem on Anycasti võrgu tõhus jälgimine, et rikkeid kiiresti tuvastada ja isoleerida.

Kui teenused kasutavad oma sisu edastamiseks kolmanda osapoole CDN-i pakkujat, on nende jaoks väga oluline jälgida ja kontrollida võrgu jõudlust. Anycasti-põhine CDN-i jälgimine keskendub otsast lõpuni latentsusaja ja eelviimase hüppe jõudluse mõõtmisele, et mõista, milline andmekeskus sisu teenindab. HTTP-serveri päiste analüüsimine on veel üks viis andmete päritolu kindlakstegemiseks.

Anycast vs Unicast: kumb on igal juhul parem valida
Näide: HTTP vastuse päised, mis näitavad CDN-serveri asukohta.

Näiteks CloudFlare kasutab HTTP vastuse sõnumites oma CF-Ray päist, mis sisaldab viidet andmekeskusele, kuhu päring tehti. Zendeski puhul on Seattle'i piirkonna CF-Ray päis CF-RAY: 2a21675e65fd2a3d-SEA ja Amsterdami jaoks CF-RAY: 2a216896b93a0c71-AMS. Sisu asukoha määramiseks saate kasutada ka HTTP-vastuse HTTP-X päiseid.

Muud adresseerimismeetodid

Kasutajataotluste konkreetsesse võrgu lõpp-punkti suunamiseks on ka teisi adresseerimismeetodeid.

Unicast

Seda meetodit kasutab tänapäeval suurem osa Internetist. Unicast – unicast edastamine, IP-aadress on seotud ainult ühe kindla võrgusõlmega. Seda nimetatakse üks-ühele sobitamiseks. 

Multicast

Multisaade kasutab suhet üks-mitmele või mitu-mitmele. Multisaade võimaldab saata saatja päringu samaaegselt erinevatele valitud lõpp-punktidele. See annab kliendile võimaluse alla laadida faili tükkidena korraga mitmelt hostilt (mis on kasulik heli või video voogesitamiseks). Multisaadet aetakse sageli segi Anycastiga, kuid peamine erinevus seisneb selles, et Anycast suunab saatja ühte kindlasse sõlme, isegi kui saadaval on mitu sõlme.

Ülekanne

Ühelt saatjalt pärit datagramm edastatakse kõikidele leviaadressiga seotud lõpp-punktidele. Võrk kopeerib automaatselt datagramme, et jõuda kõigi edastuse adressaatideni (tavaliselt samas alamvõrgus).

Geocast

Geocast on mõneti sarnane Multicastiga: saatja päringud saadetakse korraga mitmele lõpp-punktile. Erinevus seisneb aga selles, et adressaadi määrab tema geograafiline asukoht. See on multisaate spetsiaalne vorm, mida kasutavad mõned mobiilsete ad hoc võrkude marsruutimisprotokollid.

Geograafiline ruuter arvutab välja oma teeninduspiirkonna ja teeb selle ligikaudseks. Georouterid, teeninduspiirkondade vahetamine, marsruutimistabelite koostamine. Georuteri süsteemil on hierarhiline struktuur.

Anycast vs Unicast: kumb on igal juhul parem valida
Anycast vs Unicast: kumb on igal juhul parem valida
Anycast vs Unicast: kumb on igal juhul parem valida
Unicast, Multicast ja Broadcast.

Anycasti tehnoloogia kasutamine suurendab DNS-i töökindluse, tõrketaluvuse ja turvalisuse taset. Seda tehnoloogiat kasutades pakuvad operaatorid oma klientidele teenuseid erinevat tüüpi koormuse tasakaalustamiseks, mis põhinevad DNS-il. Juhtpaneelil saate määrata IP-aadressid, millele päringud saadetakse sõltuvalt geograafilisest asukohast. See annab klientidele võimaluse kasutajate taotlusi paindlikumalt levitada.

Mõned operaatorid rakendavad igas kohalolekupunktis (POP) marsruudi jälgimise võimalusi: süsteem analüüsib automaatselt kohalolekupunktide lühimaid kohalikke ja globaalseid marsruute ning suunab need läbi madalaima latentsusega geograafilised asukohad ilma seisakuta.

Hetkel on Anycast kõige stabiilsem ja töökindlam lahendus suure koormusega DNS-teenuste loomiseks, millel on kõrged nõuded stabiilsusele ja töökindlusele.

Domeen .ru toetab 35 Anycasti DNS-serverit, mis on rühmitatud 20 sõlme, mis on jaotatud viie Anycasti pilve vahel. Sel juhul kasutatakse geograafilistest tunnustest lähtuva ehitamise põhimõtet, s.t. Geocast. DNS-sõlmede paigutamisel on ette nähtud, et need viiakse geograafiliselt hajutatud asukohtadesse, mis on kõige aktiivsemate kasutajate lähedal, Venemaa pakkujate maksimaalne kontsentratsioon sõlme asukohas, samuti vaba võimsuse kättesaadavus ja kasutusmugavus. suhtlus saidiga.

Kuidas CDN-i luua?

CDN on serverite võrk, mis kiirendab sisu edastamist kasutajatele. Sisu edastamise võrgustik ühendab kõik serverid ühte võrku ja tagab kiirema sisu laadimise. Laadimiskiiruses mängib olulist rolli serveri ja kasutaja vaheline kaugus.

CDN võimaldab kasutada servereid, mis on sihtrühmale kõige lähemal. See vähendab ooteaega ja aitab kiirendada saidi sisu laadimist kõigi külastajate jaoks, mis on eriti oluline suurte failide või multimeediumiteenustega saitide puhul. CDN-i tüüpilised rakendused on e-kaubandus ja meelelahutus.

Andmete stabiilsemale ja kiiremale edastamisele aitab kaasa CDN infrastruktuuri loodud lisaserverite võrk, mis asuvad kasutajatele võimalikult lähedal. Statistika kohaselt vähendab CDN-i kasutamine saidile juurdepääsu latentsust rohkem kui 70% võrreldes ilma CDN-ita saitidega.

Kui luua CDN DNS-i abil? CDN-i seadistamine Anycasti enda lahenduse abil võib olla üsna kulukas projekt, kuid on ka odavamaid võimalusi. Näiteks võite kasutada unikaalsete IP-aadressidega GeoDNS-i ja tavalisi servereid. GeoDNS-i teenuseid kasutades saate luua geograafilise asukoha määramise võimalustega CDN-i, kus otsused tehakse külastaja tegeliku asukoha, mitte DNS-i lahendaja asukoha järgi. Saate konfigureerida oma DNS-tsooni nii, et see näitaks USA külastajatele USA serveri IP-aadresse, kuid Euroopa külastajad näevad Euroopa IP-aadressi.

GeoDNS-iga saate olenevalt kasutaja IP-aadressist tagastada erinevaid DNS-i vastuseid. Selleks on DNS-server konfigureeritud tagastama erinevaid IP-aadresse, olenevalt päringus olevast lähte-IP-aadressist. Tavaliselt kasutatakse GeoIP andmebaasi piirkonna määramiseks, kust päring tehakse. Geolokatsioon DNS-i abil võimaldab teil saata kasutajatele sisu lähedalasuvalt saidilt.

GeoDNS määrab DNS-päringu saatnud kliendi IP-aadressi või teenusepakkuja rekursiivse DNS-serveri IP-aadressi, mida kasutatakse kliendi päringu töötlemisel. Riigi/regiooni määrab kliendi IP ja GeoIP andmebaas. Seejärel saab klient lähima CDN-serveri IP-aadressi. Lisateavet GeoDNS-i seadistamise kohta saate lugeda siin.

Anycast või GeoDNS?

Kuigi Anycast on suurepärane viis sisu edastamiseks globaalses mastaabis, puudub sellel spetsiifilisus. Siin tuleb appi GeoDNS. See teenus võimaldab teil luua reegleid, mis saadavad kasutajad nende asukoha põhjal ainulaadsetesse lõpp-punktidesse.

Anycast vs Unicast: kumb on igal juhul parem valida
Näide: Euroopa kasutajad suunatakse teise lõpp-punkti.

Samuti saate domeenidele juurdepääsu keelata, loobudes kõigist päringutest. See on eelkõige kiire viis sissetungijate äralõikamiseks.

GeoDNS annab täpsemaid vastuseid kui Anycast. Kui Anycasti puhul määrab lühima marsruudi hüpete arv, siis GeoDNS-is toimub marsruutimine lõppkasutajate jaoks sõltuvalt nende füüsilisest asukohast. See vähendab latentsust ja suurendab täpsust üksikasjalike marsruutimisreeglite loomisel.

Domeeni navigeerimisel võtab brauser ühendust lähima DNS-serveriga, mis sõltuvalt domeenist väljastab saidi laadimiseks IP-aadressi. Oletame, et USA-s ja Euroopas on veebipood populaarne, kuid selle jaoks mõeldud DNS-serverid on saadaval ainult Euroopas. Siis on USA kasutajad, kes soovivad poe teenuseid kasutada, sunnitud saatma päringu lähimasse serverisse ja kuna see on väga kaugel, peavad nad vastust ootama kaua - sait ei laadita kiiresti.

Kui GeoDNS-server asub USA-s, pääsevad kasutajad sellele juba juurde. Vastus on kiire, mis mõjutab saidi laadimiskiirust.

Olukorras, kus USA-s on olemasolev DNS-server, kui Ameerika Ühendriikidest pärit kasutaja navigeerib antud domeenile, võtab ta ühendust lähima serveriga, mis pakub vajalikku IP-d. Kasutaja suunatakse serverisse, mis sisaldab saidi sisu, kuid kuna sisuga serverid on kaugel, ei saa ta seda kiiresti kätte.

Kui majutate USA-s CDN-servereid vahemällu salvestatud andmetega, saadab kliendibrauser laadimisel päringu lähimale DNS-serverile, mis saadab tagasi nõutud IP-aadressi. Vastuvõetud IP-ga brauser võtab ühendust lähima CDN-serveri ja põhiserveriga ning CDN-server teenindab brauserile vahemällu salvestatud sisu. Vahemällu salvestatud sisu laadimise ajal võetakse põhiserverist vastu kogu saidi laadimiseks puuduvad failid. Selle tulemusena väheneb saidi laadimisaeg, kuna põhiserverist saadetakse palju vähem faile.

Konkreetse IP-aadressi täpse asukoha kindlaksmääramine ei ole alati lihtne ülesanne: mängus on palju tegureid ja paljude IP-aadresside omanikud võivad otsustada seda reklaamida teisel pool maailma (siis peate õige asukoha leidmiseks oodake andmebaasi värskendamist). Mõnikord määravad VPS-i pakkujad Singapuris asuvale VPS-ile aadressid, mis väidetavalt asuvad USA-s.

Erinevalt Anycasti aadresside kasutamisest toimub levitamine nimede lahendamise ajal, mitte vahemällu salvestava serveriga ühenduse loomise ajal. Kui rekursiivne server ei toeta EDNS-i kliendi alamvõrke, kasutatakse selle rekursiivse serveri asukohta, mitte kasutajat, kes loob ühenduse vahemällu salvestava serveriga.

Kliendi alamvõrgud DNS-is on DNS-i (RFC7871) laiendus, mis määrab, kuidas rekursiivsed DNS-serverid saavad saata DNS-serverisse klienditeavet, eriti võrguteavet, mida GeoDNS-server saab kasutada kliendi asukoha täpsemaks määramiseks.

Enamik kasutab oma Interneti-teenuse pakkuja DNS-servereid või DNS-servereid, mis on neile geograafiliselt lähedal, kuid kui keegi USA-s otsustab mingil põhjusel kasutada Austraalias asuvat DNS-i lahendajat, siis tõenäoliselt saab ta lõpuks Austraaliale lähima IP-serveri aadressi.

Kui soovite GeoDNS-i kasutada, on oluline olla nende funktsioonidega kursis, kuna mõnel juhul võib see suurendada vahemällu salvestavate serverite ja kliendi vahelist kaugust.

Kokkuvõte: kui soovite ühendada mitu VPS-i CDN-iks, on parim juurutamisvõimalus kasutada DNS-serveri komplekti koos funktsiooniga GeoDNS + Anycast.

Anycast vs Unicast: kumb on igal juhul parem valida

Allikas: www.habr.com

Lisa kommentaar