Az Anycast-ról valószínűleg sokan hallottak. E módszer segítségével egy IP-cím több szerverhez rendelhető a hálózaton. Ezek a szerverek akár távol is lehetnek egymástól az adatközpontban. Az Anycast lényege, hogy a kérés forrásának helyzetétől függően az adatok a legközelebbi (a hálózat topológiája alapján, pontosabban a BGP irányítási protokoll szerint) szerverre kerülnek elküldésre. Így csökkenthető a hálózati ugrások (hop) száma és a késleltetés (latency).
Lényegében ugyanazt az útvonalat hirdetik különféle adatközpontokból világszerte. Így a kliensek a BGP útvonalai alapján a "legjobb" és "legközelebb eső" adatközponthoz jutnak el. Miért pont az Anycast? Miért használjunk Anycast-ot a Unicast helyett?
A Unicast valóban megfelelő egy olyan webhelyhez, amelynek egyetlen webszervere van és mérsékelt forgalma. Azonban, ha a szolgáltatásnak millió előfizetője van, akkor általában sok webszervert használnak, amelyek mind ugyanazzal az IP-címmel rendelkeznek. Ezek a szerverek földrajzilag elosztva vannak a lekérdezések optimális kiszolgálása érdekében.
Ebben a forgatókönyvben az Anycast teljesítménynövekedést fog biztosítani (a forgalmat minimális késleltetéssel irányítja a felhasználóhoz), megbízhatóságot kínál (a tartalék szerverek révén) és terheléselosztást – az irányítás több szerverre hatékonyan osztja el a terhelést, javítva ezzel a webhely sebességét.
A szolgáltatók különféle, Anycaston és DNS-en alapuló terheléselosztást kínálnak az ügyfeleknek. Az ügyfelek megadhatják az IP-címeket, amelyekre a lekérdezések el lesznek küldve a webhely geografikus elhelyezkedése szerint. Ez lehetővé teszi a lekérdezések rugalmasabb elosztását.
Tegyük fel, hogy több helyszín között kell elosztani a terhelést (felhasználókat), például egy webáruház, amely napi 100 000 kérdést kap, vagy egy népszerű blog. A terület korlátozásához, ahonnan a felhasználók behozzák az adott helyszínt, a Geo Community opciót lehet használni. Ez lehetővé teszi, hogy korlátozd a régiót, amelyen belül a szolgáltató be fogja hirdetni az útvonalat.
Anycast és Unicast: a különbségek
Az Anycast gyakran használatos olyan alkalmazásokban, mint a DNS (Domain Name System) és a CDN (Content Delivery Network), lehetővé téve a hálózati teljesítményjavító útválasztási döntések meghozatalát. A CDN-ek az Anycastot használják, mivel nagy forgalmat kezelnek, és az Anycast ebben az esetben számos előnyt nyújt (a továbbiakban ismertetjük őket). A DNS-ben az Anycast jelentősen növeli a szolgáltatás megbízhatóságát és hibatűrését.
Anycast IP használata során a BGP-n keresztül több útvonal létezik egy adott hoszthoz. Valójában ezek a hosztok több adatközpontban található másolatok, amelyeket alacsonyabb késleltetésű kapcsolatok létrehozására használnak.
Tehát az Anycast hálózatában ugyanazt az IP-címet különböző helyekről hirdetik, és a hálózat eldönti, hová irányítja a felhasználói kérést a "költség" alapján. Például gyakran a BGP protokollt használják az adatok legrövidebb útvonalának meghatározására. Amikor egy felhasználó Anycast-kérést indít, a BGP meghatározza a legjobb útvonalat az elérhető Anycast szerverek számára.
Anycast előnyei
Késleltetés csökkentése
Az Anycasttal ellátott rendszerek csökkenteni tudják a felhasználói kérések feldolgozási késleltetését, mivel lehetővé teszik az adatok elérését a legközelebbi szerverről. Azaz a felhasználók mindig a "legközelebbi" (a route protokoll szempontjából) DNS-szerverhez csatlakoznak. Ennek eredményeként az Anycast csökkenti az interakciók idejét az ügyfél és a szerver közötti hálózati távolság minimalizálásával. Ez nem csak a késleltetést csökkenti, hanem a terheléselosztást is biztosít.
Sebesség
Mivel a forgalom a legközelebbi csomópont felé irányul, és csökken a késleltetés az ügyfél és a csomópont közötti adatátvitel során, az eredmény a szállítási sebesség optimalizálása lesz, függetlenül attól, honnan kéri az ügyfél az információt.
Növelt stabilitás és hibatűrés
Ha több szerver világszerte ugyanazt az IP-t használja, akkor egy szerver leállása vagy hibája esetén a forgalom a legközelebbi szerverre irányul. Ennek eredményeként az Anycast robusztusabbá teszi a szolgáltatást, és jobb hálózati hozzáférést/késleltetést/sebességet biztosít.
Ezért, a felhasználók számára folyamatosan elérhető szervereknek köszönhetően az Anycast például növeli a DNS működésének stabilitását. Ha egy csomópont leáll, a felhasználói kérések átirányítódnak egy másik DNS-szerverre bármiféle manuális beavatkozás vagy újrakonfigurálás nélkül. Az Anycast gyakorlatilag átlátható váltást biztosít más helyekre, egyszerűen eltávolítva a problémás oldal útvonalait.
Terheléselosztás
Az Anycast rendszerben a hálózati forgalmat különféle szerverek között osztják el. Ez azt jelenti, hogy terheléselosztóként működik, megakadályozva, hogy bármelyik egyes szerver a forgalom fő részét kapja. A terheléselosztás alkalmazható például akkor, ha a kérés forráshoz képest azonos földrajzi távolságra több hálózati csomópont található. Ilyen esetben a terhelés a csomópontok között oszlik el.
A DoS-támadások hatásának csökkentése
Az Anycast másik jellemzője a DDoS-támadásokkal szembeni ellenállás. A DDoS-támadások valószínűleg nem képesek működésképtelenné tenni az Anycast rendszert, mivel ahhoz az ilyen hálózat minden szerverét el kellene árasztaniuk kérésekkel.
A DDoS-támadások során gyakran botneteket alkalmaznak, amelyek olyan mennyiségű forgalmat generálhatnak, hogy ezzel leterhelik a támadott szervert. Az Anycast használatának előnye ebben a helyzetben az, hogy minden szerver képes „felfogni” a támadás egy részét, csökkentve ezzel a konkrét szerverre nehezedő terhelést. Az „elérhetőségi megtagadás” típusú támadás valószínűleg lokalizálva lesz a szerveren, és nem befolyásolja az egész szolgáltatást.
Magas horizontális skálázhatóság
Az Anycast rendszerek jól alkalmazhatók nagy forgalmú szolgáltatások esetében. Ha egy Anycast-ot használó szolgáltatás új szervereket igényel a növekvő forgalom kezelésére, új szervereket lehet hozzáadni a hálózathoz a forgalom feldolgozására. Ezeket új vagy már meglévő helyeken is elhelyezhetjük.
Ha egy adott helyszínen jelentős forgalomnövekedés tapasztalható, akkor egy új szerver hozzáadása segíthet egyensúlyozni a terhelést az adott helyszínen. Egy új helyszínen elhelyezett szerver csökkenti a várakozási időt, új, rövidebb utat teremtve egyes felhasználók számára. Mindkét módszer segít növelni a szolgáltatás stabilitását, mivel a hálózatban új szerverek válnak elérhetővé. Így ha az egyik szerver túlterhelt, egyszerűen telepíthetünk egy másikat olyan helyre, ahol azt be tudja fogadni, csökkentve a túlterhelt szerverre irányuló kérések számát. Az ügyfelek részéről nem szükséges semmiféle beállítás.
Csak így lehet terabájt forgalmat és rendkívül sok felhasználót kezelni, amikor egy szerveren csupán néhány 10 vagy 25 Gbit/s sebességű port áll rendelkezésre. 100 hoszt egy IP-címmel lehetővé teszi terabájt forgalom kezelést.
A konfiguráció kezelésének egyszerűsége
Ahogy már említésre került, az Anycast DNS egy izgalmas felhasználási módja. A hálózati csomópontokban több különböző DNS-szerver is elhelyezhető, de egy DNS-címet használhatunk. Az, hogy hol van a forrás, azt határozza meg, hogy a kérések a legközelebbi csomóponthoz kerülnek. Ez némi forgalomelosztást és redundanciát biztosít a DNS-szerver hibája esetén. Így ahelyett, hogy a különböző DNS-szervereket a helyszínük alapján állítanánk be, egy DNS-szerver konfigurációja kiterjeszthető az összes csomópontra.
Az Anycast hálózatok konfigurálhatók a kérések irányítására nemcsak a távolság, hanem olyan paraméterek alapján is, mint a szerver elérhetősége, a nyitott kapcsolatok száma vagy a válaszidő.
Az Anycast technológia ügyféloldali használatához nincs szükség különleges szerverekre, hálózatokra vagy speciális komponensekre. Az Anycastnak azonban vannak hátrányai is. Úgy vélik, hogy a bevezetése összetett feladat, amely további felszerelést, megbízható szolgáltatókat és megfelelő forgalomirányítást igényel.
A tiszta forrástól a gyönyörű messzeségig
Bár az Anycast a felhasználókat a legkevesebb átkelési pont alapján irányítja, ez nem feltétlenül jelenti a minimális késleltetést. A késleltetés egy bonyolultabb metrika, mivel egy átkelés késleltetése magasabb lehet, mint tíz átkelésé.
Példa: a kontinensek közötti kommunikációk magukban foglalhatnak egy nagyon magas késleltetéssel rendelkező átmenetet.
Az Anycast főként az UDP-alapú szolgáltatásokhoz, például a DNS-hez használatos. A felhasználói kérések a BGP útvonalai alapján a "legjobb" és a "legközelebbi" adatközpont felé irányulnak.
Példa: egy DNS-ügyfél munkagép, amelynek Anycast DNS IP-címe 123.10.10.10, DNS-feloldást hajt végre a három névszerver közül a legközelebbi felé, amelyeket ugyanazzal az Anycast IP-címmel telepítettek. Ha az R1 router vagy az A szerver meghibásodik, a DNS-ügyfél csomagjai automatikusan az ezt követő legközelebbi DNS-szerverhez irányulnak az R2 és R3 routereken keresztül. Ezenkívül az A szerver felé vezető útvonal a routing táblákból eltávolításra kerül, megakadályozva ezzel a névszerver további használatát.
Telepítési forgatókönyvek
Két általános séma létezik, amelyek a felhasználóhoz kapcsolódó szerver meghatározására szolgálnak:
- Hálózati szintű Anycast. A felhasználót a legközelebbi szerverhez kapcsolja. Itt a felhasználó és a szerver közötti hálózati útvonal fontos.
- Alkalmazási szintű Anycast. Ezen a sémán nagyobb számítási metrikák szerepelnek, beleértve a szerver elérhetőségét, válaszidőt, kapcsolatok számát stb. Ez egy külső monitorozótól függ, amely statisztikákat szolgáltat a hálózatról.
Anycast alapú CDN
Most térjünk vissza az Anycast használatához a tartalomszolgáltató hálózatokban. Az Anycast kétségtelenül egy érdekes hálózati koncepció, amely egyre nagyobb elismerést nyer az új generációs CDN szolgáltatóktól.
A CDN egy elosztott szerverhálózat, amely a tartalmat a végfelhasználók számára magas rendelkezésre állással és alacsony késleltetéssel szolgáltatja. A tartalom-szolgáltató hálózatok ma fontos szerepet játszanak, mivel a számos multimédiás online szolgáltatás alapját képezik, és a fogyasztók egyre kevésbé tolerálják a lassú betöltési sebességet. A videó- és hangalkalmazások különösen érzékenyek a jitterre és a késleltetésre a hálózatban.
A CDN összeszedi az összes szervert egy hálózatba, és gyorsabb tartalomszolgáltatást biztosít. Néha akár 5-6 másodperccel is csökkentheti a felhasználói várakozási időt. A CDN célja, hogy optimalizálja a szállítást azáltal, hogy tartalmat szolgáltat a felhasználóhoz legközelebbi szerverről. Ez nagyon hasonló az Anycast-hoz, ahol a legközelebbi szerver kerül kiválasztásra a végfelhasználó helyzete alapján. Úgy tűnik, hogy minden CDN szolgáltató alapértelmezés szerint Anycast-ot használ, de a valóságban ez nem így van.
A HTTP/TCP protokollokat használó alkalmazások megbízható kapcsolatra építenek. Ha új Anycast csomópontot választanak (például egy szerver leállása esetén), a kiszolgálás megszakadhat. Ezért az Anycast korábban olyan kapcsolaton kívüli szolgáltatások, mint az UDP és a DNS számára ajánlott volt. Mindazonáltal az Anycast jól működik a kapcsolatorientált protokollok esetén is, például a TCP tökéletesen funkcionál Anycast módban.
Egyes CDN szolgáltatók Anycast-alapú irányítást alkalmaznak, míg mások a DNS-alapú irányítást részesítik előnyben: a legközelebbi szerver a felhasználó DNS-szerverének helyzete alapján kerül kiválasztásra.
A hibrid infrastruktúrák és a több adatközponttal rendelkező infrastruktúrák újabb példái az Anycast alkalmazásának. A szolgáltatótól kapott Load Balancing IP cím lehetővé teszi a terhelés elosztását az ügyfelek különböző szolgáltatásainak IP-címei között a szolgáltató adatközpontjában. Az eszközök bármely címzésének köszönhetően ez jobb teljesítményt biztosít jelentős forgalom, hibamentes működés mellett, és segít optimalizálni a válaszidőt magas felhasználószám mellett.
A több adatközponttal rendelkező hibrid infrastruktúrák lehetővé teszik a forgalom elosztását a szerverek vagy akár a dedikált szerverek virtuális gépei között.
Így óriási választék áll rendelkezésre a technikai megoldásokban az infrastruktúra kiépítésére. Az IP-címek közötti terheléselosztást is be lehet állítani több adatközpontban, a csoporthoz tartozó eszközök címzésével az oldal működésének optimalizálása érdekében.
A forgalmat a saját szabályai szerint lehet terjeszteni, meghatározva minden elosztott szerver " súlyát " minden adatközpontban. Ez a konfiguráció különösen hasznos, amikor elosztott szerver park van, és a szolgáltatások teljesítménye eltérő. Ez lehetővé teszi a forgalom gyakori elosztását a szerverek teljesítményének növelése érdekében.
A ping parancs segítségével létrehozható kontrollrendszer esetén lehetőség van sondák konfigurálására. Ez lehetővé teszi az adminisztrátor számára, hogy meghatározza a saját ellenőrzési eljárásait, és pontosabb képet kapjon az infrastruktúra minden elemének állapotáról. Így lehetőség van a rendelkezésre állás kritériumainak meghatározására.
Lehetőség van hibrid infrastruktúra kiépítésére: néha kényelmes a back office-t a vállalati hálózaton hagyni, míg a frontend részt a szolgáltatóra bízzuk.
SSL tanúsítványok hozzáadása lehetséges a terheléselosztás, az átkonfigurált adatok titkosítása és a weboldal látogatói és a vállalati infrastruktúra közötti biztonságos kapcsolatok érdekében. A terheléselosztás során az adatközpontok között is alkalmazhatók SSL tanúsítványok.
Az Anycast terheléselosztással rendelkező szolgáltatás elérhető a szolgáltatónál. Ez a funkció segít javítani a felhasználók alkalmazásokkal való interakciós algoritmusát a tartózkodási helyük függvényében. Elég csak bejelenteni, hogy mely szolgáltatások találhatók az adatközpontban, és a forgalmat a legközelebbi infrastruktúrára irányítják. Ha vannak dedikált szerverek, például Franciaországban vagy Észak-Amerikában, akkor az ügyfelek a hálózat legközelebbi szerverére lesznek irányítva.
Az Anycast egyik lehetséges alkalmazása az operátor jelenlétének optimális választása (PoP). Ezt mutatjuk be. . A LinkedIn (Oroszországban blokkolva) nemcsak a termékei — mobil és webalkalmazások — teljesítményének és sebességének javítására törekszik, hanem a hálózati infrastruktúra fejlesztésére is a tartalom gyorsabb szállítása érdekében. Ehhez a LinkedIn aktívan használja a PoP-okat – a jelenlét pontjait. A felhasználók legközelebbi PoP-hoz irányításához az Anycast-ot alkalmazzák.
Az oka az, hogy az Unycast esetében minden LinkedIn PoP egyedi IP címmel rendelkezik. Ezután a felhasználók geo-lokációjuk alapján kapják meg a PoP-okat a DNS segítségével. A probléma az, hogy a DNS használatakor az Egyesült Államokban körülbelül a felhasználók 30%-a nem optimális PoP-hoz van irányítva. Az Anycast fokozatos bevezetésével a nem optimális PoP-ok kiosztásának aránya 31%-ról 10%-ra csökkent.
A pilot teszt eredményei a grafikonon láthatók, ahol az Y tengely az optimális PoP kiosztásának százalékát mutatja. Az Anycast fokozatos bevezetése során az Egyesült Államok több államában is javulás volt megfigyelhető az optimális PoP-ok forgalmának arányában.
Anycast hálózat figyelése
Elméletileg az Anycast hálzatok egyszerűek: több fizikai szerver kapja ugyanazt az IP címet, amelyet a BGP használ az útvonal meghatározására. Azonban az Anycast platformok megvalósítása és tervezése bonyolult, különösen, ha figyelembe vesszük az ezekre jellemző hibatűrő Anycast hálzatokat. Még nehezebb az Anycast hálózat hatékony figyelése a hibák gyors azonosítása és lokalizálása érdekében.
Ha a szolgáltatások külső CDN szolgáltatót használnak tartalmuk kiszolgálására, nagyon fontos a hálózat teljesítményének nyomon követése és ellenőrzése. Anycast alapú CDN figyelés során a fő hangsúly az áthaladási késleltetések és a végső átmenet jellemzőinek mérésén van, hogy megértsük, melyik adatközpont szolgáltatja a tartalmat. Az HTTP szerver fejlécek elemzése szintén egy módja annak, hogy meghatározzuk, honnan származik az adat.
Példa: Az HTTP válaszüzenet fejléc, amely a CDN szerver elhelyezkedését jelzi.
Például a CloudFlare saját CF-Ray fejlécét használja a HTTP válaszokban, amely tartalmazza azt az adatközpontot, ahonnan a kérés érkezett. A Zendesk esetében a Seattle régióra vonatkozó CF-Ray fejléc: CF-RAY: 2a21675e65fd2a3d-SEA, míg Amszterdamra: CF-RAY: 2a216896b93a0c71-AMS. A HTTP-X-fejlécek segítségével is meg lehet határozni, hol található a tartalom.
Egyéb címzési módszerek
Vannak más címzési módszerek is a felhasználói kérések konkrét hálózati végpontokhoz való irányítására:
Unicast
Az internet legnagyobb része manapság ezt a módszert használja. A Unicast egy egycímzett átvitel, ahol az IP cím csak egyetlen konkrét csomóponthoz van rendelve a hálózatban. Ezt kölcsönösen egyértelmű összpontosításnak nevezik.
Multicast
A multicast a "egy a sokból" vagy "sok a sokhoz" kapcsolatot használ. A multicast lehetővé teszi, hogy a küldő egyszerre küldjön kérést különböző kiválasztott végpontokra. Ez lehetővé teszi a kliens számára, hogy fájlokat egyszerre több gazdától töltsön le darabokban (ami hasznos audio vagy videó streaminghez). A multicastot gyakran összekeverik az Anycast-tal, de a fő különbség abban rejlik, hogy az Anycast a küldőt egy konkrét csomópont felé irányítja, még ha több csomópont is elérhető.
Közvetítés
Az adatgramma egyetlen küldőtől minden végpont felé irányul, amely a széles sávú címhez kapcsolódik. A hálózat automatikusan replikálja az adatgrammákat, hogy kapcsolatba léphessen minden fogadóval a széles sávú közvetítés során (általában egy alhálózaton belül).
Geokast
A geokast részben hasonlít a multicast-ra: a küldőtől érkező kérések egyszerre több végpont felé irányulnak. A különbség az, hogy a címzettet földrajzi elhelyezkedése határozza meg. Ez a speciális formájú csoportcímzés bizonyos irányítási protokollok által használt mobil peer-to-peer hálózatokban.
A földrajzi útválasztó (Geo Router) meghatározza szolgáltatási területét és azt közelíti. A geomarshrutizáló rendszerek, megosztva szolgáltatási területeiket, útválasztási táblákat építenek. A geomarshrutizátorok rendszere hierarchikus struktúrával rendelkezik.
Unicast, Multicast és Broadcast.
Az Anycast technológia alkalmazása növeli a DNS megbízhatóságát, elérhetőségét és biztonságát. E technológia segítségével az üzemeltetők különböző DNS-alapú terhelésmegosztási szolgáltatásokat kínálnak ügyfeleiknek. A vezérlőpulton megadhatók azok az IP-címek, amelyekre a kérések a földrajzi elhelyezkedés alapján irányulnak. Ez lehetővé teszi az ügyfelek számára, hogy rugalmasabban oszthassák el a felhasználói kéréseket.
Néhány üzemeltető minden jelenlét ponton (POP) útvonal-monitoring eszközöket alkalmaz: a rendszer automatikusan elemzi a legrövidebb helyi és globális útvonalakat a jelenlét pontokhoz, és átirányítja azokat a legalacsonyabb késleltetéssel bíró földrajzi helyszínekre, minimális leállással.
Jelenleg az Anycast a legstabilabb és legmegbízhatóbb megoldás a nagyobb terhelésű DNS-szolgáltatások létrehozására, amelyek magas ellenállósági és megbízhatósági követelményeknek felelnek meg.
.ru domain 35 Anycast DNS szervert támogat, amelyet 20 csomópontba csoportosítanak, öt Anycast-felhőre elosztva. A geográfiai elv szerint, azaz Geocast elv alapján építik fel. A DNS csomópontok elhelyezésénél a geográfiai helyeken való elosztás feltételezett, amelyek a legaktívabb felhasználókhoz közel helyezkednek el, maximális orosz szolgáltatók koncentrációjával a csomópont elhelyezésének helyén, valamint a szabad kapacitások meglétével és a platformmal való kényelmes interakcióval.
Hogyan lehet CDN-t építeni?
A CDN egy szerverhálózat, amely felgyorsítja a tartalom küldését a felhasználóknak. összeköti az összes szervert egy hálózatban, és biztosítja a gyorsabb tartalom betöltést. A betöltési sebesség szempontjából fontos szerepet játszik a távolság a szerver és a felhasználó között.
A CDN lehetővé teszi a célnak legjobban megfelelő szerverek használatát. Ez csökkenti a várakozási időt, és segít a weboldalak tartalmának gyorsabb betöltésében minden látogató számára, ami különösen kritikus a nagy fájlméretű vagy multimédiás szolgáltatásokkal rendelkező weboldalak esetében. A CDN tipikus alkalmazási területei a kereskedelem és a szórakoztatás.
A CDN infrastruktúráján létrehozott kiegészítő szerverek hálózata, amelyek a felhasználókhoz a lehető legközelebb helyezkednek el, hozzájárul a stabilabb és gyorsabb adatátvitelhez. A statisztikák szerint a CDN használata több mint 70%-kal csökkenti a weboldal elérési késleltetését a CDN nélküli weboldalakhoz képest.
Mint? Настройка CDN с использованием собственного решения Anycast может быть достаточно дорогим проектом, но есть более дешевые варианты. Например, можно использовать GeoDNS и обычные серверы с уникальными IP-адресами. С помощью сервисов GeoDNS можно создать CDN с функциями геолокации, в которой решения принимаются на основе реального местоположения посетителя, а не местоположения ресолвера DNS. Можно настроить свою DNS-зону так, чтобы показывать IP-адреса американских серверов посетителям из США, а европейские посетители будут видеть IP-адрес из Европы.
A GeoDNS segítségével különböző DNS válaszok adhatók vissza a felhasználó IP-címe szerint. Ehhez a DNS-szervereket úgy konfigurálják, hogy a beérkező IP-cím szerint eltérő IP-címeket adjanak vissza. Általában a GeoIP adatbázis használatával határozzák meg a kérés származási régióját. A DNS-alapú geolokáció lehetővé teszi, hogy a felhasználóknak a legközelebbi webhelyből származó tartalmat küldjenek.
A GeoDNS meghatározza a DNS-kérést küldő kliens IP-címét vagy a szolgáltató rekurszív DNS-szerverének IP-címét, amelyet a kliens kérésének feldolgozása során használnak. A kliens IP-címe és a GeoIP adatbázis alapján megállapítják az országot/regiót. Ezután a kliens megkapja a legközelebbi CDN-szerver IP-címét. A GeoDNS beállításairól bővebben olvashat..
Anycast vagy GeoDNS?
Bár az Anycast remek módja a globális szintű tartalom szállításának, hiányzik belőle a specifikusság. Itt lép a GeoDNS a képbe. Ez a szolgáltatás lehetővé teszi olyan szabályok létrehozását, amelyek a felhasználókat egyedi végpontokra irányítják a tartózkodási helyük alapján.
Példa: az európai felhasználók egy másik végpontra irányulnak.
A domainekhez való hozzáférés is letiltható, ha minden kérést elutasítunk. Ez különösen gyors módja a rosszindulatú felhasználók kiszűrésének.
A GeoDNS pontosabb válaszokat ad, mint az Anycast. Míg az Anycast esetében a legrövidebb út a hopszám alapján kerül meghatározásra, a GeoDNS esetében a végfelhasználók számára történő irányítás az ő fizikai tartózkodási helyük alapján történik. Ez csökkenti a késleltetést és növeli a pontosságot a részletes irányítási szabályok létrehozása során.
Amikor a felhasználó rákattint a domainre, a böngésző a legközelebbi DNS-szerverhez fordul, amely a domain alapján IP-címet ad a weboldal betöltéséhez. Tegyük fel, hogy egy online bolt népszerű az Egyesült Államokban és Európában, és a DNS-szerverei csak Európában találhatók. Ebben az esetben az Egyesült Államokból érkező felhasználóknak a legközelebbi szerverhez kell fordulniuk, ami nagyon távol van, így a válaszra várakozniuk kell — a weboldal betöltése lassú lesz.
Ha GeoDNS-szervert helyeznek el az Egyesült Államokban, a felhasználók ehhez a szerverhez fognak kapcsolódni. A válasz gyors lesz, ami befolyásolja a weboldal betöltési sebességét.
A már létező amerikai DNS-szerver esetén, amikor egy amerikai felhasználó a domainhez fordul, ő a legközelebbi szerverhez csatlakozik, amely megadja a szükséges IP-címet. A felhasználó arra a szerverre irányul, amely a webhely tartalmát tartalmazza, de mivel a tartalomhoz szükséges szerverek messze vannak, hamar nem fogja megkapni.
Ha az Egyesült Államokban helyezik el a szervereket és a CDN-t a gyorsítótárazott adatokkal, akkor a kliens böngészője a legközelebbi DNS-szerverhez küld egy kérdést, amely visszaküldi a szükséges IP-címet. A böngésző a megkapott IP-címmel kapcsolatba lép a legközelebbi CDN szerverrel és az alap szerverrel, a CDN szerver pedig visszaadja a böngészőnek a gyorsítótárazott tartalmat. Mialatt a gyorsítótárazott tartalom betöltődik, az alap szerverről megérkeznek a hiányzó fájlok a teljes weboldal betöltéséhez. Ennek eredményeként csökken a weboldal betöltési ideje, mivel sokkal kevesebb fájl érkezik az alap szerverről.
A meghatározott IP-cím pontos földrajzi helyének megállapítása nem mindig könnyű feladat: számos tényező befolyásolja, és az IP-cím tartományának tulajdonosai úgy döntenek, hogy az a világ másik végén jelenik meg (ebben az esetben meg kell várni, amíg az adatbázis frissül, hogy a helyes helymeghatározást megkapjuk). Néha a VPS szolgáltatók amerikai címeket rendelnek a szingapúri VPS-hez.
Ahelyett, hogy Anycast címeket használnának, a forgalom terjesztése a névkibővítés során történik, nem pedig a gyorstár szerverhez való csatlakozáskor. Ha a rekurzív szerver nem támogatja a kliens alhálózatok EDNS funkcióját, akkor a rekurzív szerver helyzete lesz a meghatározó, nem pedig a felhasználó, aki a gyorstárazó szerverhez csatlakozik.
A DNS kliens alhálózatok a DNS kiterjesztése (RFC7871), amely meghatározza, hogyan küldhetnek a rekurzív DNS-szerverek információt a kliensről a DNS-szervernek, különösen azokat az információkat, amelyeket a GeoDNS szerver a kliens helyének pontosabb meghatározására használhat.
A legtöbben az internetszolgáltatójuk DNS-szervereit vagy a számukra földrajzilag közeli DNS-szervereket használják, de ha valaki az Egyesült Államokban valamilyen okból DNS-lezárót folyamodik, amely Ausztráliában található, akkor valószínűleg egy Ausztráliához legközelebbi szerver IP-címét kapja.
Ha GeoDNS-t szeretne használni, fontos tisztában lennie ezekkel a sajátos vonásokkal, mivel bizonyos esetekben növelheti a távolságot a gyorsítárazott szerverek és a kliens között.
Összefoglalva: ha több VPS-t szeretne CDN-be integrálni, a legjobb telepítési lehetőség a GeoDNS funkcióval rendelkező DNS-szerver és az Anycast „out of the box” kombináció használata.
Forrás: habr.com
