Budovani AnycastDNS – 1. cast
Dnes je moderni ze spousta firem se chlubi jak stavi nejaky technologie, a jak jsou v tom jednicka 🙂 Ja jsem to osobne nikdy nedelal a tedy informace o tom jak jsme vybudovali to ci ono jsem si nechaval na ruzny akce, kde jsem o tom mohl mluvit osobne s temi, ktere to zajimalo. Posledni dobou se ale venuju nasemu projektu AnycastDNS.CZ u ktereho jsem dosel k zaveru, ze by mozna stalo za to se trochu rozepsat a poodkryt co za tim stoji, nebot mnoho lidi si mysli ze se proste veme par serveru, nahaze se do ruznych lokalit a hura jedeme.
Co je to Anycast DNS?
Toto je asi nejdulezitejsi otazka.
V beznym svete kde se pouzivaji domenove jmena misto IP adres serveru je treba rici, kam dana domena smeruje – a to se resi pomoci DNS protokolu. Detaily k tomu resit tady nebudu 🙂 Preklad domen probihaji na tkzv DNS serverech a beznym standardem je, ze se domene nastavuji dva ruzne DNS servery, ktere by meli byt v lepsim pripade umistene ve dvou zcela rozlicnych geolokacich. V modelovym pripade muzeme rict ze trebas jeden server je v CZ a druhy v US. DNS protokol sam funguje tak, ze rekursivni servery nasich ISP se pri prekladu ptaji nahodne jednoho z tehle serveru. Tedy kdyz mame trebas dva ISP v CZ neznamena to, ze oba se budou dotazovat naseho serveru v CZ, ale dotazy budou chodit i napriklad do USA.
Kdyz si vemu priklad z nasich Gransy unicastovych DNS, tak zde je stats z pingu z CZ ISP na CZ server:
rtt min/avg/max/mdev = 0.728/0.926/1.207/0.151 ms
A zde na USA server:
rtt min/avg/max/mdev = 117.105/117.189/117.342/0.438 ms
Rozdil netreba ani zminovat. 0.92ms prumer vs. 117.189ms prumer.
A co kdyby server s DNS byl v Australii, Brazilii nebo Jihoafricky republice ?
AU: rtt min/avg/max/mdev = 257.320/257.400/257.550/0.684 ms
BR: rtt min/avg/max/mdev = 224.570/224.702/224.904/0.604 ms
ZA: rtt min/avg/max/mdev = 214.393/214.554/214.665/0.420 ms
Tam jsme uz v prumeru na ctvrt vterine … a to bych mohl najit dalsi vice nevhodny lokality, kde je latence i pulvterinova.
A proto se zde klasicka Unicast sit zde nehodi.
Pamatuju si jak ze zacatku meho pusobeni na internetu me kazdy vysvetlovat, ze v siti muze byt vzdy vzdycky jen jeden server s jednou konkretni unikatni IP adresou. Pokud by to byla pravda, neexistovalo by reseni, jak vyresit problem vyse uvedeny. Nastesti existuje topologie ktere se rika Anycast. Ta nam umoznuje umistit ruzne po svete servery se stejnou IP adresou, a diky existenci routovaciho protokolu BGP se tak zakaznik dostane vzdy na nejblizsi server (ne geograficky, ale sitove bohuzel).
Jako priklad mohu uvest nasi anycastovou IP adresu 185.28.194.194.
Toto jsou pingy z jednotlivych lokalit sveta:
CZ: rtt min/avg/max/mdev = 3.788/3.836/3.877/0.079 ms
ZA: rtt min/avg/max/mdev = 1.273/1.324/1.374/0.041 ms
FR: rtt min/avg/max/mdev = 0.390/0.409/0.439/0.021 ms
US: rtt min/avg/max/mdev = 3.940/3.991/4.060/0.088 ms
BR: rtt min/avg/max/mdev = 2.710/2.731/2.754/0.046 ms
AU: rtt min/avg/max/mdev = 1.725/1.820/1.997/0.134 ms
Prumer peknych 2 – 3ms 🙂
Muzete argumentovat, ze proc teda davat druhy server nekam do tramtarie kdyz je mozny dat oba do ruznych lokalit v ramci CZ a tim padem tenhle problem eliminovat uplne bez pouziti Anycastu ?
Mate pravdu, naprosto … ale Vam na web chodi jen lide z CZ ? Nechodi tam i z jinych zemich ? Roboti z vyhledavacu z USA ? Lide na dovoleny v Australii ?
I kdyz pominu vyhody nizsi latence, pak posledni a to nejvyraznejsi vyhoda Anycast site je jeji dostupnost. V praxi totiz funguje fakt, ze pokud Vam server spadne, nebo se stane nedostupny vinou ISP nebo prekopleho kabelu, vubec nic se nedeje, protoze diky BGP protokolu se zakaznik dostane takmer okamzite na nejblizsi jiny server. Dostupnost sluzby tak atakuje magickych 100%.
Jak na AnycastDNS ?
Tohle je jednoduche 🙂 Proste vememe par desitek tisic USD, nakoupime servery u desitek ISP napric svetem, nebo si je koupime sami a k ISP je posleme, ci rovnou uzavreme smlouvy primo s peeringovyma centrama 🙂
A nebo snizime rozpocet z desitek tisicu USD na tisice USD a poresime tedy jen pronajmy serveru u vybranych ISP, kdo by se beztak chtel starat o problemovy HW?
Nase sit vznikla v roce 2014, takze za tech 5 let jsme uz samozrejme nekde jinde co se vybavy lokalit. Aktualne mame tedy 43 serveru:
Evropa: CZ1, CZ2, DE1, DE2, FR1, FR2, NL1, NL2, SE1, NO1, UK1, RS1, BG1, RU1
Asie: AM1, AE1, IL1, JP1, HK1, IN1, SG1
Afrika: ZA1, TZ1, AO1
Australie: AU1, AU2, AU3, AU4
Jizni Amerika: BR1, BR2, CL1, CL2, CO1, AR1, AR2
Severni Amerika: CA1, US-LA1, US-FL1, US-FL2, US-CHG1, US-DAL1, US-NYC1, US-ATL1
Cisla znamenaji ISP, tedy CZ1 a CZ2 znamena ze mame dva servery v CZ u dvou ruznych ISP/Lokalitach.
Bohuzel svet neni ruzovy, a stejne tak neni ruzovy ani BGP routing. Jaky je rozdil mezi idealni siti a realnou siti ? Bohuzel mnoho ISP (a prijde mi ze vetsina) nejak netouzi po tom aby data sli nejkratsi moznou cestou, ale aby sli nejekonomictejsi cestou. Takze velci tranzitni operatori poslou data pres pul planety jen protoze to jde po jejich kabelech a nic je to nestoji. Nekteri jsou schopny poslat data pres pul planety jen proto, ze na konci je zakaznik ktery propaguje nas rozsah, ktery plati za data 2x tolik jak jiny zakaznik, ktery je vyrazne blize a taktez propaguje nas rozsah, a v neposledni rade se deje, ze cesta z baraku do baraku pres ulici vede sitove pres X routeru, coz dela cestu pro BGP delsi, nez je cesta napriklad do sousedniho statu … co na tom ze je tam rozdil 30ms.
A pak to vypada tak, jako na nize uvedenem obrazku 🙁
Data litaj po svete s latenci od par ms az po 250ms a nikoho to netrapi 🙁 Teda az na me, ktery plati tisice USD za 43 serveru napric svetem aby se toto nedelo.
Takze nezbyva nez se zamerit na docela zvlastni, ve vysledku celkem slozity, ale zaroven moc zajimavy obor: Optimalizace BGP.
Za pomoci nekterych nastroju jsem zjistil, ze nasi dva poskytovatele: Jeden z bodu v holandsku (NL1) a open IX v Srbsku (RS1) maji tak silny peering ze nam stahuji traffic z ruznych koutu sveta. Rozhodl jsem se tyto dva nody na chvilku vypnout a po chvili byl videt pekny vysledek:
Na grafu je videt krasny pad. Z prumernych worldwide 57ms jsme spadli na 33ms. To je dobry pro zacatek 🙂 Ale samozrejme povypinat servery neni reseni – resenim je vyuzit dostupnych nastroju k tomu aby byly servery vyuzity spravne. Nez jsem se do toho pustil, objevila se dalsi neduha BGP routingu. Vcera nejaky operator zavedl peering nebo novou linku spojujici Australii s Los Angeles. Avysledek ? Cesta z Mexika ktera nam koncila spravne v USA, nebot v Mexiku bod nemame, najednou z Mexika mizi do transitniho operatora co to pres LAX posila primo do Australie 🙁 Takze uz nemame latenci z Mexika 70ms, ale neco pres 200ms. A na to je potreba reagovat!
Protoze se jedna o beh na dlouhou trat, tak musime pripravit nastroje kterymi budeme moci poradne detekovat a zjistovat problematicky trasy, pres koho tecou, a najit cesty jak je optimalizovat. A o tom budu psat v dalsim dile.