{"id":88961,"date":"2020-07-16T19:42:34","date_gmt":"2020-07-16T17:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae"},"modified":"2020-07-16T19:42:34","modified_gmt":"2020-07-16T17:42:34","slug":"anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae","title":{"rendered":"Anycast vs Unicast: mida valida igas olukorras","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Anycastist on t\u00f5en\u00e4oliselt paljud kuulnud. Selle aadressijaotuse ja marsruutimise meetodi korral antakse \u00fcks IP-aadress mitmele serverile v\u00f5rgus. Need serverid v\u00f5ivad asuda isegi kaugel \u00fcksteisest andmekeskustes. Anycasti idee on see, et s\u00f5ltuvalt p\u00e4ringu allika asukohast saadetakse andmed l\u00e4himale (v\u00f5rgutopoloogiat ja t\u00e4psemalt BGP marsruutimisprotokolli silmas pidades) serverile. Nii on v\u00f5imalik v\u00e4hendada v\u00f5rgu\u00fcletuste arvu (hop) ja viivitust (latency). <\/p>\n<p>Sisuliselt kuulutatakse sama marsruut v\u00e4lja mitmest andmekeskusest \u00fcle kogu maailma. Nii suunatakse kliendid \u201eparimasse\u201c ja \u201el\u00e4himasse\u201c andmekeskusesse, l\u00e4htudes BGP marsruutidest. Miks valida just Anycast? Miks kasutada Anycasti Unicasti asemel?<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ruvds\/blog\/511050\/\"><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/6573f1e2d39d783575348734518c4bae.png\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nUnicast sobib t\u00f5epoolest veebisaidile, kus on \u00fcks veebiserver ja m\u00f5\u00f5dukas liiklusmaht. Kuid kui teenusel on miljoneid tellijaid, siis kasutatakse tavaliselt mitmeid veebiservereid, millest iga\u00fchel on sama IP-aadress. Need serverid on geograafiliselt jaotatud, et saavutada optimaalne p\u00e4ringute teenindamine.<\/p>\n<p>Sellise stsenaariumi korral toob Anycast kaasa j\u00f5udluse paranemise (liiklus suunatakse kasutajale minimaalse viivitusega), tagab teenuse usaldusv\u00e4\u00e4rsuse (t\u00e4nu varusse serveritele) ja koormuse tasakaalustamise \u2014 marsruutimine mitme serveri vahel jaotab koormuse efektiivselt nende vahel, parandades saidi t\u00f6\u00f6 kiirus.<\/p>\n<p>Operaatorid pakuvad klientidele erinevaid Anycasti ja DNS-i p\u00f5hiseid koormuse tasakaalustamise lahendusi. Kliendid saavad m\u00e4\u00e4rata IP-aadressid, kuhu p\u00e4ringud suunatakse vastavalt saidi geograafilisele asukohale. See v\u00f5imaldab paindlikumalt jaotada kasutajate p\u00e4ringuid.<\/p>\n<p>Kujutame ette, et on mitu platvormi, mille vahel tuleb koormust (kasutajaid) jaotada, n\u00e4iteks veebipood, mis teenindab 100 000 p\u00e4ringut p\u00e4evas, v\u00f5i populaarne blogi. Kasutajate sisenemise ala piiramiseks konkreetsele platvormile saab kasutada Geo Community\u2019i valikut. See v\u00f5imaldab piirata piirkonda, mille raames operaator kuulutab marsruuti.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/54582f256a946a3ff557ab971cec087d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/48849a5cf65cb1c7190c1f75aa33e2d8.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Anycast ja Unicast: erinevused<\/i><\/p>\n<p>Anycast kasutatakse sageli sellistes rakendustes nagu DNS (domeeninimede s\u00fcsteem) ja CDN (sisu edastamise v\u00f5rgud), v\u00f5imaldades langetada marsruutimise otsuseid, mis parandavad v\u00f5rgu tulemuslikkust. Sisu edastamise v\u00f5rgud kasutavad Anycast'i, kuna nad tegelevad suurte andmemahtudega, ja Anycast pakub sel juhul mitmeid eeliseid (millest allpool). DNS-is v\u00f5imaldab Anycast oluliselt suurendada teenuse usaldusv\u00e4\u00e4rsust ja rikkega taluvust.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/8043fec22ecef8aa2b3b9c1a06e8f5f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Anycast IP puhul, kasutades BGP-t, on olemas mitu marsruuti konkreetse hosti suunas. Tegelikult on need hostide koopiad mitmes andmekeskuses, mida kasutatakse madalama latentsusega \u00fchenduste loomiseks.<\/i><\/p>\n<p>Seega, Anycast v\u00f5rgus kuulutatakse sama IP-aadress erinevatest kohtadest, ja v\u00f5rk otsustab, kuhu suunata kasutaja p\u00e4ring, l\u00e4htudes marsruudi 'kuludest'. N\u00e4iteks kasutatakse sageli andmete edastamise l\u00fchema marsruudi m\u00e4\u00e4ramiseks BGP-protokolli. Kui kasutaja saadab Anycast'i p\u00e4ringu, m\u00e4\u00e4rab BGP parima marsruudi Anycast\u2019i v\u00f5rgus saadaval olevate serverite jaoks.<\/p>\n<h2>Anycast'i eelised<\/h2>\n<p>Latentsuse v\u00e4hendamine<br \/>\nAnycastiga s\u00fcsteemid suudavad v\u00e4hendada latentsust kasutaja p\u00e4ringute t\u00f6\u00f6tlemisel, kuna need v\u00f5imaldavad andmete saamist l\u00e4himalt serverilt. See t\u00e4hendab, et kasutajad \u00fchenduvad alati 'l\u00e4hima' (marsruutimisprotokolli vaatenurgast) DNS-serveriga. Selle tulemusena v\u00e4hendab Anycast suhtluse aega, v\u00e4hendades v\u00f5rgu kaugust kliendi ja serveri vahel. See ei v\u00e4henda mitte ainult latentsust, vaid tagab ka koormuse tasakaalustamise.<\/p>\n<p>Kiirus<\/p>\n<p>Kuna liiklus suunatakse l\u00e4himale s\u00f5lmele ja latentsus andmete edastamisel kliendi ja s\u00f5lme vahel v\u00e4heneb, toob see kaasa edastamise kiirusoptimeerimise, olenemata sellest, kust klient teavet k\u00fcsib.<\/p>\n<p>Suurenenud stabiilsus ja rikketaluvus<\/p>\n<p>Kui mitmed serverid \u00fcle kogu maailma kasutavad sama IP-aadressi, siis \u00fche serveri rikke v\u00f5i selle v\u00e4ljal\u00fclitamise korral suunatakse liiklus l\u00e4himale serverile. Selle tulemuseks on Anycast teenuse stabiilsemaks muutmine ning parem v\u00f5rgu\/latentsuse\/kiirus ligip\u00e4\u00e4setavus.\u00a0<\/p>\n<p>Seega, t\u00e4nu mitme serveri olemasolule, mis on pidevalt kasutajatele kergesti ligip\u00e4\u00e4setavad, parandab Anycast n\u00e4iteks DNSi t\u00f6\u00f6 stabiilsust. Kui s\u00f5lme juhtub eba\u00f5nnestuma, suunatakse kasutajate p\u00e4ringud automaatselt teisele DNS-serverile, ilma k\u00e4sitsi sekkumiseta v\u00f5i seadistamiseta. Anycast tagab peaaegu sujuva \u00fclemineku teistesse saitidesse, eemaldades lihtsalt probleemse saidi marsruudid.\u00a0<\/p>\n<p>Koormuse tasakaalustamine<\/p>\n<p>Anycasti s\u00fcsteemis jagatakse v\u00f5rgu liiklus erinevate serverite vahel. See t\u00e4hendab, et see tegutseb koormuse tasakaalustajana, takistades \u00fchelgi \u00fcksikul serveril saada peamist liikluskoormust. Koormuse tasakaalustamist v\u00f5ib kasutada n\u00e4iteks siis, kui mitmed v\u00f5rgu s\u00f5lmed asuvad samal geograafilisel kaugusel p\u00e4ringu allikast. Sellisel juhul jagatakse koormus s\u00f5lmede vahel.<\/p>\n<p>M\u00f5jude v\u00e4hendamine DoS-r\u00fcnnakutele\u00a0<\/p>\n<p>Teine Anycasti omadus on vastupidavus DDoS-i suhtes. DDoS-r\u00fcnnakud ei suuda t\u00f5en\u00e4oliselt Anycasti s\u00fcsteemi v\u00e4lja l\u00fclitada, kuna k\u00f5ikide serverite varustamine tohutu hulga p\u00e4ringutega oleks vajalik.\u00a0<\/p>\n<p>DDoS-r\u00fcnnakutes kasutatakse sageli botnet'e, mis suudavad genereerida nii suurt liiklust, et see koormab r\u00fcnnatud serverit. Anycasti kasutamise eelis selles olukorras seisneb selles, et iga server suudab \"neelata\" osa r\u00fcnnakust, v\u00e4hendades seel\u00e4bi koormust konkreetsele serverile. Teenuse k\u00e4ttesaamatuse r\u00fcnnak t\u00f5en\u00e4oliselt lokaliseeritakse serverisse ja ei m\u00f5juta kogu teenust.<\/p>\n<p>K\u00f5rge horisontaalne skaleeritavus<\/p>\n<p>Anycasti s\u00fcsteemid sobivad h\u00e4sti teenustele, mis saavad suure liikluskoormuse. Kui Anycasti kasutav teenus vajab kasvava liikluskoormuse t\u00f6\u00f6tlemiseks uusi servereid, on v\u00f5imalik lisada uusi servereid, et toetada v\u00f5rgus liikluskorraldust. Need v\u00f5ivad olla paigutatud uutele v\u00f5i juba olemasolevatele platvormidele.\u00a0<\/p>\n<p>Kui konkreetses kohas on m\u00e4rgatav liikluse t\u00f5us, aitab serveri lisamine tasakaalustada koormust antud asukohas. Uue serveri lisamine aitab v\u00e4hendada ooteaega, luues m\u00f5ne kasutaja jaoks uue l\u00fchema marsruudi. M\u00f5lemad meetodid aitavad ka suurendada teenuse stabiilsust, kuna v\u00f5rgus on saadaval uued serverid. Seega, kui server on \u00fclekoormatud, saab lihtsalt k\u00e4ivitada teise seal, kus see suudab vastu v\u00f5tta osa \u00fclekoormatud serveri p\u00e4ringutest. Klientide poolt seadistamist ei ole vaja.\u00a0<\/p>\n<p>Ainult sellisel viisil on v\u00f5imalik teenindada terabitte liiklust ja v\u00e4ga suurt kasutajate arvu, kui serveril on vaid m\u00f5ned 10 v\u00f5i 25 Gbit\/s porti. 100 hosti \u00fchel IP-aadressil v\u00f5imaldab t\u00f6\u00f6delda terabittide suuruseid liiklusmahte.<\/p>\n<p>Konfiguratsiooni lihtsus<\/p>\n<p>Nagu juba eespool mainitud, on huvitev Anycast'i kasutamine \u2014 DNS. V\u00f5ib paigutada v\u00f5rgus mitmeid erinevaid DNS-servereid, kuid kasutada \u00fchte DNS-aadressi. S\u00f5ltuvalt sellest, kus allikas asub, suunatakse p\u00e4ringud l\u00e4himasse s\u00f5lme. See tagab teatud liikluse tasakaalu ja \u00fcleliigsuse DNS-serveri t\u00f5rgete korral. Seega, selle asemel, et seadistada erinevaid DNS-servereid vastavalt nende asukohale, saab \u00fche DNS-serveri konfiguratsiooni levitada k\u00f5igisse s\u00f5lmedesse.<\/p>\n<p>Anycast-v\u00f5rke saab seadistada p\u00e4ringute suunamiseks mitte ainult kauguse p\u00f5hjal, vaid ka selliste parameetrite nagu serveri olemasolu, \u00fchenduste arv v\u00f5i vastamisaeg j\u00e4rgi.<\/p>\n<p>Anycast-tehnoloogia kasutamiseks ei ole klientide poolt vajalikud erilised serverid, v\u00f5rgud ega spetsiaalsed komponendid. Kuid Anycast'il on ka puudused. Peetakse, et selle rakendamine on keeruline \u00fclesanne, mis n\u00f5uab lisavarustust, usaldusv\u00e4\u00e4rseid teenusepakkujaid ja \u00f5iget liikluse suunamist.<\/p>\n<h2>Puhtast allikast kaunisse kaugusse<\/h2>\n<p>\nKuigi Anycast suunab kasutajad p\u00f5hjal l\u00e4htudes v\u00e4himatest \u00fcleminekute arvudest, ei t\u00e4henda see tingimata minimaalset latentsust. Latentsus on keerulisem m\u00f5\u00f5dik, kuna \u00fchel \u00fcleminekul v\u00f5ib see olla k\u00f5rgem kui k\u00fcmnel. <\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/8fb50007806759ab243c89bb88cdeb31.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>N\u00e4ide: vahemaa\u00fclesed sidekanalid v\u00f5ivad h\u00f5lmata \u00fchte \u00fcleminekut, millel on v\u00e4ga k\u00f5rge viivitus.<\/i><\/p>\n<p>Anycastit kasutatakse peamiselt UDP-p\u00f5histe teenuste, nagu DNS, jaoks. Kasutajate p\u00e4ringud suunatakse \"parimale\" ja \"l\u00e4hedasematele\" andmekeskustele, tuginedes BGP marsruutidele. <\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/05a1b75b981d55967e44e3b90cfd88b9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>N\u00e4ide: DNS-i kliendi t\u00f6\u00f6jaam, 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\u00f5i server A eba\u00f5nnestub, suunatakse DNS-i kliendi paketid automaatselt j\u00e4rgmisele l\u00e4himale DNS-serverile marsruuterite R2 ja R3 kaudu. Pealegi eemaldatakse marsruut meie serverisse A marsruutimislaudadest, mis takistab edasist nende nimeteenuse serverite kasutamist.<\/i><\/p>\n<h2>Juhtumite juurutamine<\/h2>\n<p>\nOn kaks levinud skeemi, mida kasutatakse selle m\u00e4\u00e4ramiseks, millise serveriga kasutaja \u00fchendub:<\/p>\n<ul>\n<li><b>Anycast v\u00f5rgu tasemel<\/b>. \u00dchendab kasutaja l\u00e4hima serveriga. Siin on oluline kasutaja ja serveri vaheline v\u00f5rgutee.<\/li>\n<li><b>Anycast rakenduse tasemel<\/b>. Selles skeemis on rohkem arvutatud m\u00f5\u00f5dikuid, sealhulgas serveri k\u00e4ttesaadavus, reageerimisaeg, \u00fchenduste arv jne. See s\u00f5ltub v\u00e4list j\u00e4lgimisest, mis pakub v\u00f5rgu statistikat.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Anycast-p\u00f5hine CDN<\/h2>\n<p>\nTagasi Anycasti kasutamise juurde sisu edastamisv\u00f5rkudes. Anycast on kindlasti huvitav v\u00f5rgu kontseptsioon ja omandab \u00fcha suuremat tunnustust uue p\u00f5lvkonna CDN-i pakkujates.<\/p>\n<p>CDN on serverite jaotatud v\u00f5rk, mis edastab sisu l\u00f5ppkasutajatele k\u00f5rge saadavuse ja madala viivitusega. Sisu edastamisv\u00f5rgud m\u00e4ngivad t\u00e4na olulist rolli, olles aluseks paljudele multimeedia online-teenustele, samas kui tarbijad on \u00fcha v\u00e4hem sallivad aeglastes laadimiskiirus. <\/p>\n<p>CDN \u00fchendab k\u00f5ik serverid \u00fchte v\u00f5rku, tagades kiirema sisu laadimise. M\u00f5nikord suudab see v\u00e4hendada kasutaja ootamise aega 5-6 sekundi v\u00f5rra. CDN-i eesm\u00e4rk on sisu edastamise optimeerimine, pakkudes sisu serverist, mis asub k\u00f5ige l\u00e4hemal l\u00f5ppkasutajale. See on v\u00e4ga sarnane Anycast'ile, kus valitakse l\u00e4him server s\u00f5ltuvalt l\u00f5ppkasutaja asukohast. Tundub, et iga CDN-teenusepakkuja kasutab Anycast'i vaikimisi, kuid tegelikult ei ole see nii.<\/p>\n<p>Rakendused, mis kasutavad protokolle nagu HTTP\/TCP, tuginevad seadistatavale \u00fchendusele. Kui valitakse uus Anycast-s\u00f5lm (nt serveri rikke korral), v\u00f5ib teenuse osutamine katkeda. Seet\u00f5ttu soovitati Anycast'i varem selliste \u00fchenduseta teenuste, nagu UDP ja DNS, jaoks. Sellegipoolest t\u00f6\u00f6tab Anycast h\u00e4sti ka \u00fchendusele suunatud protokollide puhul, n\u00e4iteks TCP toimib Anycast re\u017eiimis suurep\u00e4raselt.<\/p>\n<p>M\u00f5ned CDN-teenusepakkujad kasutavad Anycast-p\u00f5hist marsruutimist, teised eelistavad DNS-p\u00f5hist marsruutimist: l\u00e4him server valitakse s\u00f5ltuvalt sellest, kus asub kasutaja DNS-server.<\/p>\n<p>H\u00fcbriidstruktuurid ja mitme andmekeskuse infrastruktuurid on veel \u00fcks n\u00e4ide Anycast'i rakendamisest. Teenusepakkujalt saadud Load Balancing IP aadress v\u00f5imaldab koormust jaotada erinevate kliendi teenuste IP-aadresside vahel teenusepakkuja andmekeskuses. Aadressimise tehnoloogia t\u00f5ttu t\u00f5husam koost\u00f6\u00f6 igas seadmes tagab parema j\u00f5udluse m\u00e4rkimisv\u00e4\u00e4rse liikluse korral, k\u00f5rgema t\u00f6\u00f6kindluse ja aitab optimeerida vastusaega suurte kasutajate arvuga.<\/p>\n<p>H\u00fcbriidstruktuurides, kus on mitu andmekeskust, on v\u00f5imalik jaotada liiklus serverite v\u00f5i isegi virtuaalsete masinate vahel p\u00fchendatud serverites.<\/p>\n<p>Seega on olemas suur valik tehnilisi lahendusi infrastruktuuri rajamiseks. Samuti on v\u00f5imalik seadistada IP-aadresside p\u00f5hine koormuse jagamine mitmes andmekeskuses, kasutades grupi igas seadmes adresseerimist saidi toimimise optimeerimiseks.<\/p>\n<p>Saate levitada liiklust vastavalt oma reeglitele, m\u00e4\u00e4rates igas andmekeskuses jaotatud serverite \"kaalu\". Selline konfiguratsioon on eriti kasulik, kui on olemas jaotatud serverite park ja teenuste j\u00f5udlus on erinev. See v\u00f5imaldab sagedamini levitada liiklust serverite j\u00f5udluse suurendamiseks.<\/p>\n<p>Ping-k\u00e4skluse abil kontrolls\u00fcsteemi loomiseks on v\u00f5imalik konfigureerida sensoreid. See v\u00f5imaldab administraatoril m\u00e4\u00e4ratleda oma kontrolliprotseduurid ning saada selgema \u00fclevaate iga infrastruktuuri komponendi seisundist. Nii saab m\u00e4\u00e4ratleda kriteeriumid k\u00e4ttesaadavuse hindamiseks.<\/p>\n<p>On v\u00f5imalik luua h\u00fcbriidinfrastruktuur: m\u00f5nikord on mugav j\u00e4tta tagab\u00fcroo ettev\u00f5tte v\u00f5rgus, samas kui liidestusosa antakse v\u00e4ljaandjatele.<\/p>\n<p>On v\u00f5imalik lisada SSL-sertifikaate koormuse tasakaalustamiseks, edastatavate andmete kr\u00fcpteerimiseks ja \u00fchenduse turvamiseks k\u00fclastajate ja ettev\u00f5tte infrastruktuuri vahel. Koormuse tasakaalustamisel andmekeskuste vahel on samuti v\u00f5imalik rakendada SSL-i.<\/p>\n<p>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\u00e4himasse infrastruktuuri. Kui on p\u00fchendatud serverid, n\u00e4iteks Prantsusmaal v\u00f5i P\u00f5hja-Ameerikas, suunatakse kliendid l\u00e4himasse serverisse v\u00f5rgus.<\/p>\n<p>\u00dcks Anycasti kasutusv\u00f5imalusi on operaatori kohaloleku punkti (PoP) optimaalse valiku tegemine. N\u00e4iteks: <noindex><a rel=\"nofollow\" href=\"https:\/\/engineering.linkedin.com\/network-performance\/tcp-over-ip-anycast-pipe-dream-or-reality\">n\u00e4ide<\/a><\/noindex>. LinkedIn (Venemaal blokeeritud) p\u00fc\u00fcab mitte ainult parandada oma toodete \u2014 mobiilsete ja veebirakenduste \u2014 j\u00f5udlust ja kiirus, vaid ka t\u00e4iustada v\u00f5rgu infrastruktuuri sisu kiiremaks edastamiseks. Selleks kasutab LinkedIn aktiivselt punktide kohaloleku (PoP) d\u00fcnaamilise sisu edastamise jaoks. Kasutajad suunatakse l\u00e4himasse PoP-i, rakendades Anycast'i.<\/p>\n<p>P\u00f5hjus on see, et Unycasti puhul on igal PoP-i LinkedInil ainulaadne IP-aadress. Seej\u00e4rel m\u00e4\u00e4ratakse kasutajad PoP-i vastavalt nende geograafilisele asukohale DNS-i kaudu. Probleem on selles, et DNS-i kasutamisel suunati umbes 30% kasutajatest Ameerika \u00dchendriikides mitteoptimaalsele PoP-ile. T\u00e4nu Anycasti etapiviisilisele kasutusele v\u00f5eti mitteoptimaalne PoP-i m\u00e4\u00e4ramine, mis langes 31%-lt 10%-ni.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/f1635951294bc476639ec65d175c11e0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Pilootkatse tulemused on esitatud graafikuna, kus Y-teljel on protsent optimaalsest PoP-i m\u00e4\u00e4ramisest. Anycasti \"koormuse suurendamisel\" mitmes Ameerika osariigis on t\u00e4heldatud parendust optimaalse PoP-i liikluses.<\/i><\/p>\n<h2>Anycasti v\u00f5rgu j\u00e4lgimine<\/h2>\n<p>\nTeoreetiliselt on Anycasti v\u00f5rgud lihtsad: mitmele f\u00fc\u00fcsilisele serverile antakse sama IP-aadress, mida BGP kasutab marsruudi m\u00e4\u00e4ramiseks. Kuid Anycasti platvormide rakendamine ja projekteerimine on keeruline, eriti on selles osas tuntud talitlush\u00e4irete kindluse Anycasti v\u00f5rgud. Veelgi keerulisem on t\u00f5hus Anycasti v\u00f5rgu j\u00e4lgimine vigade kiireks tuvastamiseks ja lokaliseerimiseks. <\/p>\n<p>Kui teenused kasutavad sisu teenindamiseks kolmanda osapoole CDN-i, on neil v\u00e4ga oluline j\u00e4lgida ja kontrollida v\u00f5rgu j\u00f5udlust. Anycasti p\u00f5hinev CDN-i j\u00e4lgimine keskendub peamiselt viivitusaja ja eelviimase h\u00fcppeliigendi omaduste m\u00f5\u00f5tmisele, et m\u00f5ista, milline andmekeskus teenindab sisu. HTTP-serveri p\u00e4iste anal\u00fc\u00fcs on veel \u00fcks viis m\u00e4\u00e4rata, kust andmed p\u00e4rinevad.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/9dfcf689c3c7a553b00de5f0dac4d0ec.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>N\u00e4ide: HTTP-vastuse p\u00e4ised, mis n\u00e4itavad CDN-i serveri asukohta.<\/i><\/p>\n<p>N\u00e4iteks kasutab CloudFlare oma HTTP-vastustes oma CF-Ray pealkirja, mis sisaldab teavet andmekeskuse kohta, kuhu p\u00e4ring on suunatud. N\u00e4iteks Zendiski puhul t\u00e4histab Seattle'i piirkonna CF-Ray pealkiri CF-RAY: 2a21675e65fd2a3d-SEA ja Amsterdamile CF-RAY: 2a216896b93a0c71-AMS. Samuti v\u00f5ib m\u00e4\u00e4rata, kus sisu asub, kasutades HTTP-X-p\u00e4iseid HTTP-vastuses.<\/p>\n<h2>Teised aadressimisviisid<\/h2>\n<p>\nKasutajate p\u00e4ringute suunamiseks konkreetsele v\u00f5rgu l\u00f5pp-punktile on olemas ka teised aadressimisviisid:<\/p>\n<p>Unicast<\/p>\n<p>Enamik t\u00e4nap\u00e4eva internetist kasutab just seda meetodit. Unicast on \u00fcheaadressiline edastus, IP-aadress on seotud ainult \u00fche konkreetse s\u00f5lmega v\u00f5rgus. Seda nimetatakse vastastikku eksklusiivseks vastavuseks.\u00a0<\/p>\n<p>Multicast<\/p>\n<p>Multicast kasutab \u00fchte-kohta-mitmele v\u00f5i mitmest-mitmele-side. Multicast v\u00f5imaldab saatjal saata p\u00e4ringu samaaegselt erinevatele valitud l\u00f5pupunktidele. See annab kliendile v\u00f5imaluse laadida faili osade kaupa mitmelt hostilt samal ajal (mis on kasulik audio- v\u00f5i videovoo jaoks). Multicast segi aetakse sageli Anycastiga, kuid peamine erinevus seisneb selles, et Anycast suunab saatja konkreetsele s\u00f5lmele, isegi kui mitu s\u00f5lme on saadaval.<\/p>\n<p>Broadcast<\/p>\n<p>Datagramm, mille saadab \u00fcksainus saatja, suunatakse k\u00f5ikidele l\u00f5pupunktidele, mis on seotud laiekraaniga aadressiga. V\u00f5rk kopeerib automaatselt datagramme, et olla suuteline \u00fchendust pidama k\u00f5igi vastuv\u00f5tjatega laiekirjade saatmisel (tavaliselt \u00fches alamv\u00f5rgus).<\/p>\n<p>Geocast<\/p>\n<p>Geocast sarnaneb osaliselt Multicastiga: saatja p\u00e4ringud suunatakse samaaegselt mitmele l\u00f5pupunktile. Kuid erinevus seisneb selles, et adressaat m\u00e4\u00e4ratakse tema geograafilise asukoha j\u00e4rgi. See on spetsialiseeritud grupi adresseerimise vorm, mida kasutavad m\u00f5ned marsruutimisprotokollid mobiilsetes peer-to-peer v\u00f5rkudes.<\/p>\n<p>Geograafiline marsruuter (Geo Router) arvutab oma teeninduspiirkonna ja ligikaudse selle. Geomarsruuterid, vahetades teeninduspiirkondi, koostavad marsruuditabelid. Geomarsruuterite s\u00fcsteemil on hierarhiline struktuur.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/fa98a1f0705bd754e1a9c8b479c834a7.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/da36388f194ac565aba7b7661839ff6c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/16161b1bdc81867d8c8bba7bd084b7cf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Unicast, Multicast ja Broadcast.<\/i><\/p>\n<p>Anycast tehnoloogia kasutamine suurendab DNS-i usaldusv\u00e4\u00e4rsust, vigade taluvust ja turvalisust. Kasutades seda tehnoloogiat, pakuvad operaatorid oma klientidele erinevaid DNS-i p\u00f5hiseid koormuse tasakaalustamise teenuseid. Kontrollpaneelis saab m\u00e4\u00e4rata IP-aadresse, milleni p\u00e4ringud saadetakse geograafilise lokaliseerimise p\u00f5hjal. See annab klientidele v\u00f5imaluse jaotada kasutajate p\u00e4ringud paindlikumalt.<\/p>\n<p>M\u00f5ned operaatorid rakendavad marsruudit\u00f6\u00f6d igas kohaloleku punktis (POP): s\u00fcsteem anal\u00fc\u00fcsib automaatselt k\u00f5ige l\u00fchemaid kohalikke ja globaalseid marsruute kohaloleku punktides ning suunab need geograafiliste asukohtade kaudu, kus viivitus on minimaalne ja t\u00f6\u00f6katkestusi pole.<\/p>\n<p>Praegu on Anycast k\u00f5ige stabiilsem ja usaldusv\u00e4\u00e4rsem lahendus k\u00f5rge koormusega DNS-teenuste loomiseks, mis peavad vastama tugevatele n\u00f5udmistele stabiilsuse ja usaldusv\u00e4\u00e4rsuse osas. <\/p>\n<p>.ru domeen toetab 35 Anycast DNS-serverit, mis on grupeeritud 20 s\u00f5lme, jaotatuna viie Anycast-pilve vahel. Sellega rakendatakse geograafilise printsiipi, st Geocast. DNS-s\u00f5lmede paigutamisel on arvesse v\u00f5etud nende viimist geograafiliselt hajutatud asukohtadesse, mis on l\u00e4hedased k\u00f5ige aktiivsematele kasutajatele, Venemaa teenusepakkujate maksimaalne kontsentratsioon s\u00f5lme paigutuspunktis, samuti vabad kapatsiteed ja mugav, koost\u00f6\u00f6d toetav keskkond.<\/p>\n<h2>Kuidas luua CDN?<\/h2>\n<p>\nCDN on serverite v\u00f5rk, mis kiirendab sisu edastamist kasutajatele.<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ruvds\/blog\/503800\/\"> Sisu edastamise v\u00f5rk<\/a><\/noindex> \u00fchendab k\u00f5ik serverid \u00fchte v\u00f5rku ja tagab sisu kiirema laadimise. Laadimise kiirus s\u00f5ltub olulisel m\u00e4\u00e4ral serveri ja kasutaja vahelisest kaugusest.<\/p>\n<p>CDN v\u00f5imaldab kasutada servereid, mis asuvad sihtr\u00fchmale k\u00f5ige l\u00e4hemal. See v\u00e4hendab ooteaega, aitab kiirendada veebisaitide sisu laadimist k\u00f5igile k\u00fclastajatele, mis on eriti kriitiline suurte failide v\u00f5i multimeedia teenuseid pakkuvate veebisaitide puhul. CDN t\u00fc\u00fcpilised rakendusalad on e-kaubandus ja meelelahutus.<\/p>\n<p>CDN infrastruktuuris loodud lisaserverite v\u00f5rk, mis asub kasutajatele maksimaalselt l\u00e4hedal, soodustab andmete stabiilsemat ja kiiremat edastamist. Statistika kohaselt v\u00e4hendab CDN-i kasutamine viivitust saidile p\u00e4\u00e4semisel rohkem kui 70% v\u00f5rreldes saitidega, mis ei kasuta CDN-i.<\/p>\n<p>Kuidas<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ruvds\/blog\/466447\/\"> luua CDN DNS-i abil<\/a><\/noindex>? \u041d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0430 CDN \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u0440\u0435\u0448\u0435\u043d\u0438\u044f Anycast \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0434\u043e\u0440\u043e\u0433\u0438\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u043c, \u043d\u043e \u0435\u0441\u0442\u044c \u0431\u043e\u043b\u0435\u0435 \u0434\u0435\u0448\u0435\u0432\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043c\u043e\u0436\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c GeoDNS \u0438 \u043e\u0431\u044b\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u0441 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u044b\u043c\u0438 IP-\u0430\u0434\u0440\u0435\u0441\u0430\u043c\u0438. \u0421 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 GeoDNS \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c CDN \u0441 \u0444\u0443\u043d\u043a\u0446\u0438\u044f\u043c\u0438 \u0433\u0435\u043e\u043b\u043e\u043a\u0430\u0446\u0438\u0438, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u043f\u0440\u0438\u043d\u0438\u043c\u0430\u044e\u0442\u0441\u044f \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u0433\u043e \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043f\u043e\u0441\u0435\u0442\u0438\u0442\u0435\u043b\u044f, \u0430 \u043d\u0435 \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0440\u0435\u0441\u043e\u043b\u0432\u0435\u0440\u0430 DNS. \u041c\u043e\u0436\u043d\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0441\u0432\u043e\u044e DNS-\u0437\u043e\u043d\u0443 \u0442\u0430\u043a, \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c IP-\u0430\u0434\u0440\u0435\u0441\u0430 \u0430\u043c\u0435\u0440\u0438\u043a\u0430\u043d\u0441\u043a\u0438\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u043f\u043e\u0441\u0435\u0442\u0438\u0442\u0435\u043b\u044f\u043c \u0438\u0437 \u0421\u0428\u0410, \u0430 \u0435\u0432\u0440\u043e\u043f\u0435\u0439\u0441\u043a\u0438\u0435 \u043f\u043e\u0441\u0435\u0442\u0438\u0442\u0435\u043b\u0438 \u0431\u0443\u0434\u0443\u0442 \u0432\u0438\u0434\u0435\u0442\u044c IP-\u0430\u0434\u0440\u0435\u0441 \u0438\u0437 \u0415\u0432\u0440\u043e\u043f\u044b.<\/p>\n<p>GeoDNS-i abil saab tagasi anda erinevaid DNS-vastuseid s\u00f5ltuvalt kasutaja IP-aadressist. Selleks seadistatakse DNS-server nii, et see tagastab erinevad IP-aadressid vastavalt p\u00e4ringu algsele IP-aadressile. \u00dcldiselt kasutatakse p\u00e4ringu teostamise piirkonna m\u00e4\u00e4ramiseks GeoIP andmebaasi. DNS-i geolokatsioon v\u00f5imaldab saata kasutajatele sisu l\u00e4himast saidist.<\/p>\n<p>GeoDNS m\u00e4\u00e4rab kliendi, kes DNS-i p\u00e4ringu edastas, IP-aadressi v\u00f5i IP-aadressi rekursiivsest DNS-serverist, mida kasutatakse kliendi p\u00e4ringu t\u00f6\u00f6tlemisel. Klientide IP-aadressi ja GeoIP andmebaasi p\u00f5hjal tuvastatakse riik\/region. Seej\u00e4rel saab klient l\u00e4hima CDN-serveri IP-aadressi. GeoDNS seadistamisest saab l\u00e4hemalt lugeda<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/178727\/\"> siin<\/a><\/noindex>.<\/p>\n<h2>Anycast v\u00f5i GeoDNS?<\/h2>\n<p>\nKuigi Anycast on suurep\u00e4rane sisu edastamise meetod globaalsetes m\u00f5\u00f5tkavades, ei ole tal piisavalt spetsiifilisust. Siin tulebki appi GeoDNS. See teenus v\u00f5imaldab m\u00e4\u00e4rata reegleid, mis suunavad kasutajad ainulaadsetele l\u00f5pp-punktidele s\u00f5ltuvalt nende asukohast.<\/p>\n<p><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/05c9d6752ba196f90bfefe6091075b23.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>N\u00e4ide: Euroopast p\u00e4rit kasutajad suunatakse teisele l\u00f5pp-punktile.<\/i><\/p>\n<p>Samuti saab keelata juurdep\u00e4\u00e4su domeenidele, k\u00f5rvaldades k\u00f5ik p\u00e4ringud. See on n\u00e4iteks kiire viis pahatahtlike kasutajate t\u00f5rjumiseks.<\/p>\n<p>GeoDNS annab t\u00e4psemaid vastuseid kui Anycast. Kui Anycast puhul m\u00e4\u00e4ratakse l\u00fchim marsruut h\u00fcpete arvu p\u00f5hjal, siis GeoDNS-is suunatakse l\u00f5ppkasutajad nende f\u00fc\u00fcsilise asukoha p\u00f5hjal. See v\u00e4hendab latentsi ja suurendab t\u00e4psust granulaarsuse reeglite loomisel. <\/p>\n<p>Domeeni k\u00fclastades p\u00f6\u00f6rdub brauser l\u00e4hima DNS-serveri poole, mis, s\u00f5ltuvalt domeenist, v\u00e4ljastab IP-aadressi saidi laadimiseks. Oletame, et internetipood on populaarne Ameerikas ja Euroopas, ning DNS-serverid on ainult Euroopas. Siis Ameerikast p\u00e4rit kasutajad, kes soovivad poodi kasutada, peavad edastama p\u00e4ringu l\u00e4himale serverile, ja kuna see asub v\u00e4ga kaugel, tuleb tal kaua oodata vastust \u2014 saidi laadimine ei toimu kiiresti.<\/p>\n<p>GeoDNS-serveri paigutamine USA-sse t\u00e4hendab, et kasutajad p\u00f6\u00f6rduvad juba selle poole. Vastus tuleb kiiresti, mis m\u00f5jutab saidi laadimiskiirust.<\/p>\n<p>Situatsioonis, kus olemas on DNS-server Ameerikas, p\u00f6\u00f6rdub Ameerika kasutaja selle domeeni k\u00fclastades l\u00e4hima serveri poole, mis v\u00e4ljastab vajaliku IP-aadressi. Kasutaja suundub serverisse, mis sisaldab saidi sisu, kuid kuna sisuserverid asuvad kaugel, ei saa ta seda kiiresti k\u00e4tte.<\/p>\n<p>Kui asetada USA-s ja CDN-serverid vahem\u00e4lus olevate andmetega, siis brauseri laadimisel saadab kliendi brauser p\u00e4ringu l\u00e4himale DNS-serverile, mis saadab tagasi vajaliku IP-aadressi. Brauser, saades IP, p\u00f6\u00f6rdub l\u00e4hima CDN-serveri ja p\u00f5hiserveri poole ning CDN-server edastab brauserile vahem\u00e4lus oleva sisu. Samuti saadetakse p\u00f5hiserverilt puuduolevad failid, et laadida t\u00e4iskohta. Selle tulemusena v\u00e4heneb saidi laadimisaeg, kuna p\u00f5hiserverilt saadetavate failide arv on palju v\u00e4iksem. <\/p>\n<p>M\u00e4\u00e4rata t\u00e4pset asukohta antud IP-aadressile pole alati lihtne \u00fclesanne: siin m\u00e4ngivad rolli paljud tegurid ja IP-aadresside vahemike omanikud v\u00f5ivad otsustada, et muudavad selle teisele maailma otsale (siis tuleb oodata, kuni andmebaas on uuendatud, et saada \u00f5ige asukoht). M\u00f5nikord m\u00e4\u00e4ravad VPS-teenuse pakkujad aadresse, mis v\u00e4idetavalt asuvad USA-s, Singapuri VPS-ile.<\/p>\n<p>Erinevalt Anycast-aadresside kasutamisest toimub jaotamine nimede lahendamise ajal, mitte vahem\u00e4luserveri \u00fchendamise ajal. Kui rekurssiivne server ei toeta kliendi alamv\u00f5rke EDNS, kasutatakse selle rekurssiivse serveri asukohta, mitte kasutaja oma, kes \u00fchendub vahem\u00e4luserveriga.<\/p>\n<p>DNS-i kliendi alamv\u00f5rgud on DNS-i laiendus (RFC7871), mis m\u00e4\u00e4ratleb, kuidas rekurssiivsed DNS-serverid saavad saata kliendi teavet DNS-serverile, eriti teavet v\u00f5rgu kohta, mida GeoDNS-server saab kasutada kliendi asukoha t\u00e4psemaks m\u00e4\u00e4ramiseks.<\/p>\n<p>Enamik inimesi kasutab oma internetiteenuse pakkuja DNS-servereid v\u00f5i geograafiliselt l\u00e4hedasi DNS-servereid, kuid kui keegi USA-s mingil p\u00f5hjusel otsustab kasutada Austraalias asuvat DNS-resolverd, saab ta t\u00f5en\u00e4oliselt IP-aadressi serverist, mis asub k\u00f5ige l\u00e4hemal Austraalias. <\/p>\n<p>Kui soovite kasutada GeoDNS-i, on oluline teada selliseid omadusi, kuna m\u00f5nel juhul v\u00f5ib see suurendada vahet vahem\u00e4luservede ja kliendi vahel.<\/p>\n<p>Kokkuv\u00f5te: kui soovite \u00fchendada mitut VPS-i CDN-iks, on parim juurutusv\u00f5imalus kasutada DNS-serverit GeoDNS-i funktsiooni ja Anycast'i koos toimimiseks.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/ruvds.com\/ru-rub?utm_source=habr&amp;utm_medium=article&amp;utm_campaign=caplin&amp;utm_content=anycastvsunicast#order\"><img decoding=\"async\" alt=\"Anycast vs Unicast: mida valida igas olukorras\" src=\"\/wp-content\/uploads\/2020\/07\/73c6b0732883a352ddd9096804f2e533.png\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<br \/>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ruvds\/blog\/511050\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e Anycast \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u043b\u044b\u0448\u0430\u043b\u0438. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u043c\u0435\u0442\u043e\u0434\u0435 \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u0438 \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043e\u0434\u0438\u043d IP-\u0430\u0434\u0440\u0435\u0441 \u043f\u0440\u0438\u0441\u0432\u0430\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c \u0432 \u0441\u0435\u0442\u0438. \u042d\u0442\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u044c\u0441\u044f \u0434\u0430\u0436\u0435 \u0432 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0445 \u0434\u0440\u0443\u0433 \u043e\u0442 \u0434\u0440\u0443\u0433\u0430 \u0426\u041e\u0414. \u0418\u0434\u0435\u044f Anycast \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e, \u0432 \u0437\u0430\u0432\u0438\u0441\u0438\u043c\u043e\u0441\u0442\u0438 \u043e\u0442 \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0438\u0441\u0442\u043e\u0447\u043d\u0438\u043a\u0430 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u0434\u0430\u043d\u043d\u044b\u0435 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u0430 \u0431\u043b\u0438\u0436\u0430\u0439\u0448\u0438\u0439 (\u0441\u043e\u0433\u043b\u0430\u0441\u043d\u043e \u0442\u043e\u043f\u043e\u043b\u043e\u0433\u0438\u0438 \u0441\u0435\u0442\u0438, \u0442\u043e\u0447\u043d\u0435\u0435 \u2014 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 BGP) \u0441\u0435\u0440\u0432\u0435\u0440. \u0422\u0430\u043a\u0438\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":88962,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-88961","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e Anycast \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u043b\u044b\u0448\u0430\u043b\u0438. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u043c\u0435\u0442\u043e\u0434\u0435 \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u0438 \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043e\u0434\u0438\u043d IP-\u0430\u0434\u0440\u0435\u0441 \u043f\u0440\u0438\u0441\u0432\u0430\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c \u0432 \u0441\u0435\u0442\u0438. \u042d\u0442\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u044c\u0441\u044f \u0434\u0430\u0436\u0435 \u0432 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0445 \u0434\u0440\u0443\u0433 \u043e\u0442 \u0434\u0440\u0443\u0433\u0430 \u0426\u041e\u0414.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Anycast \u043f\u0440\u043e\u0442\u0438\u0432 Unicast: \u0447\u0442\u043e \u043b\u0443\u0447\u0448\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u0442\u044c \u0432 \u043a\u0430\u0436\u0434\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e Anycast \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u043b\u044b\u0448\u0430\u043b\u0438. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u043c\u0435\u0442\u043e\u0434\u0435 \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u0438 \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043e\u0434\u0438\u043d IP-\u0430\u0434\u0440\u0435\u0441 \u043f\u0440\u0438\u0441\u0432\u0430\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c \u0432 \u0441\u0435\u0442\u0438. \u042d\u0442\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u044c\u0441\u044f \u0434\u0430\u0436\u0435 \u0432 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0445 \u0434\u0440\u0443\u0433 \u043e\u0442 \u0434\u0440\u0443\u0433\u0430 \u0426\u041e\u0414.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-07-16T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-07-16T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Anycast vs Unicast: mida valida igas olukorras | ProHoster","description":"Anycast'ist on kindlasti paljusid kuulnud. Selle meetodi korral m\u00e4\u00e4ratakse \u00fcks IP-aadress mitmele serverile v\u00f5rgus. Need serverid v\u00f5ivad olla isegi erinevates andmekeskustes.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Anycast \u043f\u0440\u043e\u0442\u0438\u0432 Unicast: \u0447\u0442\u043e \u043b\u0443\u0447\u0448\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u0442\u044c \u0432 \u043a\u0430\u0436\u0434\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 | ProHoster","og:description":"\u041f\u0440\u043e Anycast \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u043c\u043d\u043e\u0433\u0438\u0435 \u0441\u043b\u044b\u0448\u0430\u043b\u0438. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u043c\u0435\u0442\u043e\u0434\u0435 \u0441\u0435\u0442\u0435\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441\u0430\u0446\u0438\u0438 \u0438 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043e\u0434\u0438\u043d IP-\u0430\u0434\u0440\u0435\u0441 \u043f\u0440\u0438\u0441\u0432\u0430\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0430\u043c \u0432 \u0441\u0435\u0442\u0438. \u042d\u0442\u0438 \u0441\u0435\u0440\u0432\u0435\u0440\u044b \u043c\u043e\u0433\u0443\u0442 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u044c\u0441\u044f \u0434\u0430\u0436\u0435 \u0432 \u0443\u0434\u0430\u043b\u0435\u043d\u043d\u044b\u0445 \u0434\u0440\u0443\u0433 \u043e\u0442 \u0434\u0440\u0443\u0433\u0430 \u0426\u041e\u0414.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/anycast-protiv-unicast-chto-luchshe-vybirat-v-kazhdom-sluchae","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-07-16T17:42:34+00:00","article:modified_time":"2020-07-16T17:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"88961","title":null,"description":null,"keywords":null,"keyphrases":{"focus":[],"additional":[]},"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:19:34","updated":"2026-08-11 12:50:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/88961","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=88961"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/88961\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/88962"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=88961"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=88961"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=88961"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}