Multaj homoj verŝajne aŭdis pri Anycast. En ĉi tiu metodo de retadresado kaj vojigo, ununura IP-adreso estas asignita al multoblaj serviloj en reto. Ĉi tiuj serviloj eĉ povas troviĝi en datumcentroj malproksimaj unu de la alia. La ideo de Anycast estas, ke, depende de la loko de la peta fonto, la datumoj estas senditaj al la plej proksima (laŭ la reto-topologio, pli precize, la BGP-enrutiga protokolo) servilo. Tiel vi povas redukti la nombron da retaj saltoj kaj latenteco.
Esence, la sama itinero estas reklamita de pluraj datumcentroj tra la mondo. Tiel, klientoj estos senditaj al la "plej bona" kaj "plej proksima" surbaze de BGP-itineroj, la datumcentro. Kial Anycast? Kial uzi Anycast anstataŭ Unicast?
Unicast vere taŭgas por retejo kun unu retservilo kaj modera kvanto da trafiko. Tamen, se servo havas milionojn da abonantoj, ĝi kutime uzas multajn retservilojn, ĉiu kun la sama IP-adreso. Ĉi tiuj serviloj estas distribuitaj geografie por optimume servi petojn.
En ĉi tiu scenaro, Anycast plibonigos agadon (trafiko estas sendita al la uzanto kun minimuma prokrasto), certigos fidindecon de la servo (danke al rezervaj serviloj) kaj ekvilibro de ŝarĝo - vojigo al pluraj serviloj efike distribuos la ŝarĝon inter ili, plibonigante la rapidecon. de la retejo.
Funkciistoj ofertas al klientoj diversajn specojn de ŝarĝoekvilibro bazita sur Anycast kaj DNS. Klientoj povas specifi IP-adresojn al kiuj petoj estos senditaj laŭ la geografia loko de la retejo. Ĉi tio ebligas disdoni uzantpetojn pli flekseble.
Supozu, ke ekzistas pluraj retejoj, inter kiuj vi devas distribui la ŝarĝon (uzantoj), ekzemple reta vendejo kun 100 000 petoj tage aŭ populara blogo. Por limigi la regionon de kiu uzantoj aliras specifan retejon, vi povas uzi la opcion Geo Community. Ĝi permesas vin limigi la regionon en kiu la funkciigisto reklamos la itineron.
Anycast kaj Unicast: diferencoj
Anycast ofte estas uzata en aplikoj kiel DNS (Domain Name System) kaj CDN (Content Delivery Networks), ebligante vojajn decidojn, kiuj plibonigas retan rendimenton. Enhavaj liveraj retoj uzas Anycast ĉar ili traktas grandajn volumojn de trafiko, kaj Anycast provizas kelkajn avantaĝojn en ĉi tiu kazo (pli pri ili sube). En DNS, Anycast permesas vin signife pliigi la nivelon de fidindeco kaj toleremo al misfunkciadoj de la servo.
En Anycast IP, kiam vi uzas BGP, ekzistas pluraj vojoj al specifa gastiganto. Ĉi tiuj fakte estas kopioj de gastigantoj en multoblaj datumcentroj, uzataj por establi pli malaltajn latentecajn konektojn.
Do, en Anycast-reto, la sama IP-adreso estas reklamita de malsamaj lokoj, kaj la reto decidas kie direkti la peton de la uzanto surbaze de la "kosto" de la itinero. Ekzemple, BGP ofte kutimas determini la plej mallongan itineron por datumtranssendo. Kiam uzanto sendas Anycast-peton, BGP determinas la plej bonan itineron por disponeblaj Anycast-serviloj en la reto.
Avantaĝoj de Anycast
Reduktante Latencia
Sistemoj kun Anycast povas redukti la latentecon dum prilaborado de uzantpetoj ĉar ili permesas vin ricevi datumojn de la plej proksima servilo. Tio estas, uzantoj ĉiam konektos al la "plej proksima" (de vojprotokola vidpunkto) DNS-servilo. Kiel rezulto, Anycast reduktas interagotempon reduktante la retan distancon inter la kliento kaj servilo. Ĉi tio ne nur reduktas latencian sed ankaŭ provizas ŝarĝan ekvilibron.
Rapido
Ĉar trafiko estas direktita al la plej proksima nodo kaj la latenteco inter la kliento kaj la nodo estas reduktita, la rezulto estas optimumigita liverrapideco, ne grave de kie la kliento petas informojn.
Pliigita stabileco kaj faŭltoleremo
Se pluraj serviloj tra la mondo uzas la saman IP, tiam se unu el la serviloj malsukcesas aŭ estas malkonektita, trafiko estos redirektita al la plej proksima servilo. Kiel rezulto, Anycast faras la servon pli rezistema kaj provizas pli bonan retan aliron/latentecon/rapidecon.
Tiel, havante plurajn servilojn konstante disponeblaj por uzantoj, Anycast, ekzemple, plibonigas DNS-stabilecon. Se nodo malsukcesas, uzantpetoj estos redirektitaj al alia DNS-servilo sen ia mana interveno aŭ reagordo. Anycast disponigas preskaŭ travideblan ŝanĝadon al aliaj retejoj simple forigante la itinerojn de la problema retejo.
Ŝarĝo Ekvilibro
En Anycast, rettrafiko estas distribuita tra malsamaj serviloj. Tio estas, ĝi funkcias kiel ŝarĝbalancilo, malhelpante ajnan ununuran servilon ricevi la plej grandan parton de la trafiko. Ŝarĝbalancado povas esti uzita, ekzemple, kiam ekzistas multoblaj retaj nodoj ĉe la sama geografia distanco de la petofonto. En ĉi tiu kazo, la ŝarĝo estas distribuita inter la nodoj.
Redukti la efikon de DoS-atakoj
Alia trajto de Anycast estas ĝia DDoS-rezisto. DDoS-atakoj verŝajne ne povos faligi sistemon Anycast, ĉar ili devus superŝuti ĉiujn servilojn en tia reto per lavango de petoj.
DDoS-atakoj ofte uzas botnetojn, kiuj povas generi tiom da trafiko, ke ĝi troŝarĝas la atakitan servilon. La avantaĝo uzi Anycast en ĉi tiu situacio estas, ke ĉiu servilo kapablas "sorbi" parton de la atako, kio reduktas la ŝarĝon sur tiu aparta servilo. Neo de servo-atako plej verŝajne estos lokalizita al la servilo kaj ne influos la tutan servon.
Alta horizontala skaleblo
Anycast-sistemoj estas bone taŭgaj por servoj kun grandaj volumoj de trafiko. Se servo uzanta Anycast postulas novajn servilojn pritrakti pliigitan trafikon, novaj serviloj povas esti aldonitaj al la reto por pritrakti ĝin. Ili povas esti metitaj sur novaj aŭ ekzistantaj retejoj.
Se aparta loko spertas grandan kreskon de trafiko, tiam aldoni servilon helpos ekvilibrigi la ŝarĝon por tiu retejo. Aldoni servilon ĉe nova retejo helpos redukti atendtempojn kreante novan plej mallongan itineron por iuj uzantoj. Ambaŭ metodoj ankaŭ helpas plibonigi la stabilecon de la servo kiam novaj serviloj iĝas disponeblaj en la reto. Tiel, se servilo estas troŝarĝita, vi povas simple deploji alian en loko kiu permesas al ĝi akcepti iun parton de la petoj de la troŝarĝita servilo. Ĉi tio ne postulas ajnan agordon de la klientoj.
Nur tiamaniere terabitoj da trafiko kaj tre granda nombro da uzantoj povas esti servataj kiam la servilo havas nur kelkajn 10 aŭ 25 Gbps-havenojn. 100 gastigantoj kun unu IP-adreso ebligos prilabori terabitajn volumojn de trafiko.
Facila agorda administrado
Kiel notite supre, interesa uzo de Anycast estas DNS. Vi povas meti plurajn malsamajn DNS-servilojn sur retajn nodojn, sed uzu unu DNS-adreson. Depende de kie la fonto situas, petoj estas direktitaj al la plej proksima nodo. Ĉi tio provizas iun trafikan ekvilibron kaj redundon en kazo de fiasko de DNS-servilo. Tiel, anstataŭ agordi malsamajn DNS-servilojn depende de kie ili situas, la agordo de unu DNS-servilo povas esti disvastigita al ĉiuj nodoj.
Anycast-retoj povas esti agorditaj por direkti petojn ne nur surbaze de distanco, sed ankaŭ de parametroj kiel la ĉeesto de servilo, la nombro da establitaj ligoj. aŭ respondtempo.
Neniuj specialaj serviloj, retoj aŭ specialaj komponantoj estas postulataj ĉe la kliento por uzi Anycast-teknologion. Sed Anycast ankaŭ havas siajn malavantaĝojn. Oni kredas, ke ĝia efektivigo estas kompleksa tasko, postulanta plian ekipaĵon, fidindajn provizantojn kaj taŭgan trafikan vojigon.
Malproksime de pura fonto al beleco
Kvankam Anycast direktas uzantojn surbaze de la plej malmultaj saltoj, ĉi tio ne nepre signifas la plej malaltan latentecon. Latenteco estas pli kompleksa metriko ĉar ĝi povas esti pli alta por unu transiro ol por dek.
Ekzemplo: Interkontinentaj komunikadoj povas impliki ununuran salteton kun tre alta latenteco.
Anycast estas ĉefe uzata por UDP-bazitaj servoj kiel ekzemple DNS. Uzantpetoj estas direktitaj al la "plej bona" kaj "plej proksima" datumcentro bazita sur BGP-itineroj.
Ekzemplo: DNS-klienta laborstacio kun Anycast DNS IP-adreso de 123.10.10.10 elfaras DNS-rezolucion al la plej proksima el tri DNS-nomserviloj deplojitaj uzante la saman Anycast-IP-adreson. Se Router R1 aŭ Servilo A malsukcesas, DNS-klientpakaĵoj estos aŭtomate plusenditaj al la sekva plej proksima DNS-servilo per Routers R2 kaj R3. Aldone, la itinero al nia servilo A estos forigita de la vojtabeloj, malhelpante pluan uzon de tiu nomservilo.
Deploj Scenaroj
Estas du ĝeneralaj skemoj, kiuj estas uzataj por determini al kiu servilo uzanto ligas:
- Anycast retotavolo. Ligas la uzanton al la plej proksima servilo. La reto vojo de la uzanto al la servilo estas grava ĉi tie.
- Aplika nivelo anycast. Ĉi tiu skemo havas pli kalkulitajn metrikojn, inkluzive de servila havebleco, respondtempo, nombro da konektoj, ktp. Ĉi tio dependas de ekstera monitoro, kiu provizas retajn statistikojn.
CDN bazita sur Anycast
Ni nun revenu al uzado de Anycast en enhavaj liveraj retoj. Anycast certe estas interesa interreta koncepto kaj akiras kreskantan akcepton inter venontgenaj CDN-provizantoj.
CDN estas distribuita reto de serviloj, kiuj liveras enhavon al finaj uzantoj kun alta havebleco kaj malalta latenco. Enhavaj liveraj retoj ludas gravan rolon hodiaŭ kiel la spino de multaj interretaj amaskomunikilaj servoj, kaj konsumantoj estas ĉiam pli malpli toleremaj pri malrapidaj elŝutaj rapidecoj. Vidaĵoj kaj voĉaj aplikoj estas speciale sentemaj al retaj tremo kaj latenco.
CDN konektas ĉiujn servilojn en unu reton kaj certigas pli rapidan ŝarĝon de enhavo. Kelkfoje eblas redukti la atendan tempon de la uzanto je 5-6 sekundoj. La celo de CDN estas optimumigi liveron servante enhavon de la servilo, kiu estas plej proksima al la finuzanto. Ĉi tio estas tre simila al Anycast, kie la plej proksima servilo estas elektita surbaze de la loko de la finuzanto. Ŝajnus, ke ĉiu CDN-servoprovizanto uzus Anycast defaŭlte, sed fakte ĉi tio ne estas la kazo.
Aplikoj kiuj uzas protokolojn kiel HTTP/TCP dependas de la konekto estanta establita. Se nova Anycast-nodo estas elektita (ekzemple, pro servila fiasko), servo povas esti interrompita. Jen kial Anycast antaŭe estis rekomendita por senkonektaj servoj kiel UDP kaj DNS. Tamen, Anycast ankaŭ funkcias bone por konekt-orientitaj protokoloj; ekzemple, TCP funkcias bone en Anycast-reĝimo.
Iuj CDN-provizantoj uzas Anycast-bazitan vojigon, aliaj preferas DNS-bazitan vojigon: la plej proksima servilo estas elektita surbaze de kie situas la DNS-servilo de la uzanto.
Hibridaj kaj mult-datumcentraj infrastrukturoj estas alia ekzemplo de la uzo de Anycast. La IP-adreso de Load Balancing ricevita de la provizanto permesas al vi distribui la ŝarĝon inter la IP-adresoj de malsamaj klientservoj en la datumcentro de la provizanto. Danke al ajna-aparata teknologio, ĝi provizas pli bonan rendimenton sub peza trafiko, misfunkciadotoleremo kaj helpas optimumigi respondtempon kiam traktas grandan nombron da uzantoj.
En hibridaj plurdatumcentraj infrastrukturoj, vi povas distribui trafikon tra serviloj aŭ eĉ virtualaj maŝinoj sur dediĉitaj serviloj.
Tiel, ekzistas grandega elekto de teknikaj solvoj por konstrui infrastrukturon. Vi ankaŭ povas agordi ŝarĝan ekvilibron tra IP-adresoj tra pluraj datumcentroj, celante ajnan aparaton en grupo por optimumigi la agadon de la retejo.
Vi povas distribui trafikon laŭ viaj propraj reguloj, difinante la "pezon" de ĉiu el la distribuitaj serviloj en ĉiu datumcentro. Ĉi tiu agordo estas precipe utila kiam ekzistas distribuita servila parko kaj la agado de servoj estas malebena. Ĉi tio permesos trafikon esti distribuita pli ofte por plibonigi servilan rendimenton.
Por krei monitoran sistemon per la ping-komando, eblas agordi sondilojn. Ĉi tio permesas al la administranto difini siajn proprajn monitorajn procedurojn kaj akiri pli klaran bildon de la statuso de ĉiu komponento en la infrastrukturo. Tiamaniere, alireblaj kriterioj povas esti difinitaj.
Eblas konstrui hibridan infrastrukturon: foje estas oportune lasi la malantaŭan oficejon en la kompania reto, kaj subkontrakti la interfacan parton al la provizanto.
Eblas aldoni SSL-atestilojn por ŝarĝoekvilibro, ĉifrado de transdonitaj datumoj kaj sekureco de komunikado inter retejvizitantoj kaj kompania infrastrukturo. En kazo de ŝarĝo-ekvilibro inter datumcentroj, SSL ankaŭ povas esti uzata.
Anycast-servo kun adresŝarĝa ekvilibro povas esti akirita de via provizanto. Ĉi tiu funkcio helpos plibonigi kiel uzantoj interagas kun aplikaĵoj laŭ loko. Sufiĉas anonci kiajn servojn disponeblas en la datumcentro, kaj trafiko estos redirektita al la plej proksima infrastrukturo. Se ekzistas dediĉitaj serviloj, ekzemple en Francio aŭ Nordameriko, tiam klientoj estos direktitaj al la plej proksima servilo en la reto.
Unu el la ebloj por uzi Anycast estas la optimuma elekto de la punkto de ĉeesto de funkciigisto (PoP). Ni donu . LinkedIn (blokita en Rusio) strebas ne nur plibonigi la rendimenton kaj rapidecon de siaj produktoj - moveblaj kaj retaj aplikaĵoj, sed ankaŭ plibonigi sian retan infrastrukturon por pli rapida livero de enhavo. Por ĉi tiu dinamika enhavo livero, LinkedIn aktive uzas PoPs - punktoj de ĉeesto. Anycast estas uzata por direkti uzantojn al la plej proksima PoP.
La kialo estas, ke en la kazo de Unycast, ĉiu LinkedIn PoP havas unikan IP-adreson. Uzantoj tiam estas asignitaj al PoP surbaze de sia geografia loko uzante DNS. La problemo estas, ke uzante DNS, ĉirkaŭ 30% de uzantoj en Usono estis redirektitaj al suboptimuma PoP. Kun la faza efektivigo de Anycast, suboptimuma PoP-tasko falis de 31% al 10%.
La rezultoj de la pilota testo estas montritaj en la grafikaĵo, kie la Y-akso estas la procento de optimuma PoP-tasko. Dum Anycast pliiĝis, multaj usonaj ŝtatoj vidis plibonigon de la procento de trafiko al la optimuma PoP.
Anycast Reta Monitorado
Anycast-retoj estas simplaj en teorio: multoblaj fizikaj serviloj ricevas la saman IP-adreson, kiun BGP uzas por determini la itineron. Sed la efektivigo kaj dezajno de Anycast-platformoj estas kompleksaj, kaj mistoleremaj retoj Anycast estas precipe famaj pro tio. Eĉ pli malfacila estas efike monitori Anycast-reton por rapide identigi kaj izoli misfunkciojn.
Se servoj uzas triapartan CDN-provizanton por servi sian enhavon, estas tre grave por ili kontroli kaj kontroli retan rendimenton. Anycast-bazita CDN-monitorado temigas mezuradon de fin-al-fina latencia kaj antaŭlasta hop-efikeco por kompreni kiu datumcentro servas la enhavon. Analizi HTTP-servilajn kapliniojn estas alia maniero determini de kie venas datumoj.
Ekzemplo: HTTP-respondaj kaplinioj indikante la lokon de la CDN-servilo.
Ekzemple, CloudFlare uzas sian propran CF-Ray-kapon en HTTP-Respondaj mesaĝoj, kiu inkluzivas indikon pri la datumcentro al kiu la peto estis farita. En la kazo de Zendesk, la CF-Ray-kapo por la Seatla regiono estas CF-RAY: 2a21675e65fd2a3d-SEA, kaj por Amsterdamo ĝi estas CF-RAY: 2a216896b93a0c71-AMS. Vi ankaŭ povas uzi HTTP-X-kapojn de la HTTP-respondo por determini kie troviĝas la enhavo.
Aliaj adresaj metodoj
Ekzistas aliaj adresmetodoj por direkti uzantpetojn al specifa reta finpunkto:
Unikast
Plejparto de la Interreto hodiaŭ uzas ĉi tiun metodon. Unicast - unicast transdono, la IP-adreso estas asociita kun nur unu specifa nodo en la reto. Ĉi tio nomiĝas unu-al-unu kongruo.
Multicast
Multicast uzas unu-al-multaj aŭ mult-al-multaj rilaton. Multicast permesas al peto de sendinto esti sendita samtempe al malsamaj elektitaj finpunktoj. Ĉi tio donas al la kliento la kapablon elŝuti dosieron en pecoj de pluraj gastigantoj samtempe (kio estas utila por elsendi audio aŭ video). Multicast estas ofte konfuzita kun Anycast, tamen la ĉefa diferenco estas, ke Anycast direktas la sendinton al unu specifa nodo, eĉ se pluraj nodoj disponeblas.
elsendo
Datagramo de ununura sendinto estas plusendita al ĉiuj finpunktoj asociitaj kun la elsenda adreso. La reto aŭtomate reproduktas datagramojn por povi atingi ĉiujn ricevantojn en la elsendo (kutime sur la sama subreto).
Geocast
Geocast estas iom simila al Multicast: petoj de la sendinto estas senditaj al pluraj finpunktoj samtempe. Tamen la diferenco estas, ke la alparolato estas determinita de ĝia geografia loko. Ĉi tio estas specialeca formo de multirolantaro uzata de kelkaj vojprotokoloj por moveblaj ad hoc retoj.
Geografia enkursigilo kalkulas sian servareon kaj proksimigas ĝin. Georouters, interŝanĝantaj servareojn, konstruas vojtablojn. La georouter-sistemo havas hierarkian strukturon.
Unicast, Multicast kaj Broadcast.
Uzado de Anycast-teknologio pliigas la nivelon de fidindeco, faŭltoleremo kaj sekureco de DNS. Uzante ĉi tiun teknologion, telefonistoj ofertas al siaj klientoj servojn por diversaj specoj de ŝarĝo-ekvilibro bazita sur DNS. En la kontrolpanelo, vi povas specifi IP-adresojn al kiuj petoj estos senditaj depende de geografia loko. Ĉi tio donos al klientoj la ŝancon distribui uzantpetojn pli flekseble.
Kelkaj funkciigistoj efektivigas itinermonitoradkapablojn ĉe ĉiu punkto de ĉeesto (POP): la sistemo aŭtomate analizas la plej mallongajn lokajn kaj tutmondajn itinerojn por punktoj de ĉeesto kaj direktas ilin tra la plej malsupraj latentecaj geografiaj lokoj kun nula malfunkcio.
Nuntempe, Anycast estas la plej stabila kaj fidinda solvo por konstrui altŝarĝajn DNS-servojn, kiuj havas altajn postulojn por stabileco kaj fidindeco.
La domajno .ru subtenas 35 Anycast DNS-servilojn, grupigitajn en 20 nodojn, distribuitajn tra kvin Anycast-nuboj. En ĉi tiu kazo, la principo de konstruado bazita sur geografiaj trajtoj estas uzata, t.e. Geocast. Kiam oni metas DNS-nodojn, oni antaŭvidas, ke ili estos movitaj al geografie disigitaj lokoj proksime al la plej aktivaj uzantoj, la maksimuma koncentriĝo de rusaj provizantoj ĉe la punkto kie troviĝas la nodo, kaj ankaŭ la havebleco de libera kapablo kaj facileco de. interago kun la retejo.
Kiel konstrui CDN?
CDN estas reto de serviloj, kiu akcelas la liveron de enhavo al uzantoj. kunigas ĉiujn servilojn en unu reton kaj certigas pli rapidan ŝarĝon de enhavo. La distanco de la servilo al la uzanto ludas gravan rolon en ŝarĝrapideco.
CDN permesas vin uzi servilojn kiuj estas plej proksimaj al la celgrupo. Ĉi tio reduktas atendan tempon kaj helpas akceli la ŝarĝon de retejo-enhavo por ĉiuj vizitantoj, kio estas precipe kritika por retejoj kun grandaj dosieroj aŭ plurmediaj servoj. Tipaj aplikoj por CDN estas elektronika komerco kaj distro.
La reto de kromaj serviloj kreitaj en la CDN-infrastrukturo, kiuj situas kiel eble plej proksime al uzantoj, kontribuas al pli stabila kaj pli rapida livero de datumoj. Laŭ statistiko, uzi CDN reduktas la latentecon alirante retejon je pli ol 70% kompare kun retejoj sen CDN.
Kiel? Agordi CDN uzante la propran solvon de Anycast povas esti sufiĉe multekosta projekto, sed ekzistas pli malmultekostaj elektoj. Ekzemple, vi povas uzi GeoDNS kaj regulajn servilojn kun unikaj IP-adresoj. Uzante GeoDNS-servojn, vi povas krei CDN kun geolokkapabloj, kie decidoj estas faritaj surbaze de la reala loko de la vizitanto, prefere ol la loko de la DNS-solvilo. Vi povas agordi vian DNS-zonon por montri usonajn servilojn IP-adresojn al usonaj vizitantoj, sed eŭropaj vizitantoj vidos la eŭropan IP-adreson.
Kun GeoDNS, vi povas resendi malsamajn DNS-respondojn depende de la IP-adreso de la uzanto. Por fari tion, la DNS-servilo estas agordita por redoni malsamajn IP-adresojn depende de la fonta IP-adreso en la peto. Tipe, GeoIP-datumbazo estas uzata por determini la regionon de kiu peto estas farita. Geolokigo per DNS permesas sendi enhavon al uzantoj de proksima retejo.
GeoDNS determinas la IP-adreson de la kliento kiu sendis la DNS-peton, aŭ la IP-adreson de la rekursiva DNS-servilo de la provizanto, kiu estas uzata dum prilaborado de la kliento-peto. La lando/regiono estas determinita de la IP- kaj GeoIP-datumbazo de la kliento. La kliento tiam akiras la IP-adreson de la plej proksima CDN-servilo. Vi povas legi pli pri agordo de GeoDNS.
Anycast aŭ GeoDNS?
Kvankam Anycast estas bonega maniero liveri enhavon tutmonde, al ĝi mankas specifeco. Jen kie GeoDNS venas al la savo. Ĉi tiu servo permesas krei regulojn, kiuj sendas uzantojn al unikaj finpunktoj laŭ ilia loko.
Ekzemplo: Uzantoj el Eŭropo estas direktitaj al malsama finpunkto.
Vi ankaŭ povas nei aliron al domajnoj forĵetante ĉiujn petojn. Ĉi tio estas, precipe, rapida maniero fortranĉi entrudiĝintojn.
GeoDNS donas pli precizajn respondojn ol Anycast. Se en la kazo de Anycast la plej mallonga itinero estas determinita de la nombro da lupolo, tiam en GeoDNS-vojigo por finaj uzantoj okazas depende de ilia fizika loko. Ĉi tio reduktas latencian kaj plibonigas precizecon dum kreado de grajnecaj vojreguloj.
Navigante al domajno, la retumilo kontaktas la plej proksiman DNS-servilon, kiu, depende de la domajno, eldonas IP-adreson por ŝargi la retejon. Ni supozu, ke reta vendejo estas populara en Usono kaj Eŭropo, sed DNS-serviloj por ĝi disponeblas nur en Eŭropo. Tiam usonaj uzantoj, kiuj volas uzi la servojn de la vendejo, estos devigitaj sendi peton al la plej proksima servilo, kaj ĉar ĝi estas tre malproksime, ili devos atendi longan tempon por respondo - la retejo ne ŝargiĝos rapide.
Kiam GeoDNS-servilo troviĝas en Usono, uzantoj jam aliros ĝin. La respondo estos rapida, kio influos la ŝarĝan rapidon de la retejo.
En situacio kun ekzistanta DNS-servilo en Usono, kiam uzanto de Usono navigas al difinita domajno, li kontaktos la plej proksiman servilon kiu provizos la bezonatan IP. La uzanto estos direktita al la servilo kiu enhavas la enhavon de la retejo, sed ĉar la serviloj kun la enhavo estas malproksime, li ne ricevos ĝin rapide.
Se vi gastigas CDN-servilojn en Usono kun kaŝmemoritaj datumoj, tiam post ŝarĝo la klienta retumilo sendos peton al la plej proksima DNS-servilo, kiu resendos la bezonatan IP-adreson. La retumilo kun la ricevita IP kontaktas la plej proksiman CDN-servilon kaj la ĉefan servilon, kaj la CDN-servilo servas la kaŝmemoritan enhavon al la retumilo. Dum la kaŝmemorigita enhavo estas ŝarĝita, la dosieroj mankantaj por ŝargi la plenan retejon ricevas de la ĉefa servilo. Kiel rezulto, la tempo de ŝarĝo de la retejo estas reduktita, ĉar multe malpli da dosieroj estas senditaj de la ĉefa servilo.
Determini la precizan lokon de specifa IP-adreso ne ĉiam estas facila tasko: estas multaj faktoroj en ludo, kaj la posedantoj de gamo da IP-adresoj eble decidos reklami ĝin sur la alia flanko de la mondo (tiam vi devos atendu ĝisdatigi la datumbazon por akiri la ĝustan lokon). Kelkfoje VPS-provizantoj asignas adresojn supozeble situantajn en Usono al VPS en Singapuro.
Male al uzado de Anycast-adresoj, distribuo estas farita dum nomsolvado prefere ol dum konekto al la kaŝmemorservilo. Se la rekursiva servilo ne subtenas EDNS-klientsubretojn, tiam la loko de tiu rekursiva servilo estas uzata prefere ol la uzanto kiu konektos al la kaŝmemorservilo.
Kliento-Subretoj en DNS estas etendaĵo de DNS (RFC7871) kiu difinas kiom rekursivaj DNS-serviloj povas sendi klientajn informojn al la DNS-servilo, precipe retajn informojn, kiujn la GeoDNS-servilo povas uzi por pli precize determini la lokon de la kliento.
Plej multaj uzas la DNS-servilojn de sia ISP aŭ DNS-servilojn geografie proksimajn al ili, sed se iu en Usono ial decidas uzi DNS-solvilon situantan en Aŭstralio, ili verŝajne finos kun IP-servila adreso plej proksima al Aŭstralio.
Se vi volas uzi GeoDNS, gravas konscii ĉi tiujn funkciojn, ĉar en iuj kazoj ĝi povas pliigi la distancon inter la kaŝmemorserviloj kaj la kliento.
Resumo: se vi volas kombini plurajn VPS en CDN, tiam la plej bona disfalda opcio estas uzi DNS-servilan pakaĵon kun la funkcio GeoDNS + Anycast ekstere de la skatolo.
fonto: www.habr.com