Mange har sikkert hørt om Anycast. Med denne metoden for nettverksadressering og ruting tilordnes en enkelt IP-adresse til flere servere på et nettverk. Disse serverne kan til og med være plassert i datasentre som ligger fjernt fra hverandre. Ideen til Anycast er at, avhengig av plasseringen av forespørselskilden, blir dataene sendt til den nærmeste (i henhold til nettverkstopologien, mer presist, BGP-rutingsprotokollen) server. Dermed er det mulig å redusere antall nettverksoverganger (hop) og forsinkelse (latency).
I hovedsak annonseres den samme ruten fra flere datasentre rundt om i verden. Dermed vil klienter bli sendt til "beste" og "nærmeste" basert på BGP-ruter, datasenteret. Hvorfor er det Anycast? Hvorfor bruke Anycast i stedet for Unicast?
Unicast er virkelig egnet for et nettsted med en enkelt webserver og en moderat mengde trafikk. Men hvis en tjeneste har millioner av abonnenter, bruker den vanligvis mange webservere, hver med samme IP-adresse. Disse serverne er fordelt geografisk for å betjene forespørsler optimalt.
I dette scenariet vil Anycast forbedre ytelsen (trafikken sendes til brukeren med minimal forsinkelse), sikre tjenestepålitelighet (på grunn av redundante servere) og belastningsbalansering - ruting til flere servere vil effektivt fordele belastningen mellom dem, og forbedre hastigheten på nettstedet.
Operatører tilbyr kundene ulike typer lastbalansering basert på Anycast og DNS. Klienter kan spesifisere IP-adresser som forespørsler skal sendes til basert på den geografiske plasseringen til nettstedet. Dette gjør det mulig å distribuere brukerforespørsler mer fleksibelt.
Anta at det er flere nettsteder du trenger for å fordele belastningen (brukere), for eksempel en nettbutikk med 100 000 forespørsler per dag eller en populær blogg. For å begrense regionen som brukere får tilgang til et bestemt nettsted fra, kan du bruke alternativet Geo Community. Den lar deg begrense regionen der operatøren vil kunngjøre ruten.
Anycast og Unicast: Forskjeller
Anycast brukes ofte i applikasjoner som DNS (Domain Name System) og CDN (Content Delivery Networks) for å ta rutingbeslutninger som forbedrer nettverksytelsen. Innholdsleveringsnettverk bruker Anycast fordi de håndterer store mengder trafikk, og Anycast gir en rekke fordeler i dette tilfellet (mer om dem nedenfor). I DNS lar Anycast deg betydelig øke nivået av pålitelighet og feiltoleranse for tjenesten.
I Anycast IP, når du bruker BGP, er det flere ruter til en bestemt vert. De er faktisk kopier av verter i flere datasentre som brukes til å etablere forbindelser med lavere ventetid.
Så i Anycast-nettverket annonseres den samme IP-adressen fra forskjellige steder, og nettverket bestemmer hvor brukerens forespørsel skal sendes basert på "kostnaden" for ruten. For eksempel brukes BGP ofte til å bestemme den korteste dataveien. Når en bruker sender en Anycast-forespørsel, bestemmer BGP den beste ruten for tilgjengelige Anycast-servere på nettverket.
Fordeler med Anycast
Latensreduksjon
Anycast-systemer er i stand til å redusere ventetiden når de behandler brukerforespørsler, da de lar deg motta data fra nærmeste server. Det vil si at brukere alltid vil koble seg til den "nærmeste" (i forhold til rutingprotokollen) DNS-server. Som et resultat reduserer Anycast kommunikasjonstiden ved å redusere nettverksavstanden mellom klient og server. Dette reduserer ikke bare ventetiden, men gir også lastbalansering.
Fart
Siden trafikk dirigeres til nærmeste node, og latensen i dataoverføring mellom klienten og noden reduseres, vil resultatet være en optimalisering av leveringshastigheten, uansett hvor klienten ber om informasjon fra.
Økt stabilitet og feiltoleranse
Hvis flere servere rundt om i verden bruker samme IP, vil trafikken bli omdirigert til nærmeste server hvis en av serverne svikter eller går ned. Som et resultat gjør Anycast tjenesten mer spenstig og gir bedre nettverkstilgang/latens/hastighet.
Ved å ha flere servere konstant tilgjengelig for brukerne, forbedrer for eksempel Anycast stabiliteten til DNS. Hvis en vert mislykkes, vil brukerforespørsler bli omdirigert til en annen DNS-server uten manuell intervensjon eller rekonfigurering. Anycast gir en nesten gjennomsiktig veksling til andre nettsteder ved ganske enkelt å fjerne rutene til det problematiske nettstedet.
Lastbalansering
I Anycast-systemet distribueres nettverkstrafikk til forskjellige servere. Det vil si at den fungerer som en lastbalanser, og forhindrer at en enkelt server mottar mesteparten av trafikken. Lastbalansering kan for eksempel brukes når det er flere nettverksnoder i samme geografiske avstand fra forespørselskilden. I dette tilfellet er belastningen fordelt mellom nodene.
Redusere virkningen av DoS-angrep
En annen funksjon i Anycast er DDoS-motstand. Det er usannsynlig at DDoS-angrep vil kunne ødelegge Anycast-systemet, siden det ville måtte undertrykke alle serverne i et slikt nettverk med et skred av forespørsler.
DDoS-angrep bruker ofte botnett som kan generere så mye trafikk at det overbelaster den angrepne serveren. Fordelen med å bruke Anycast i denne situasjonen er at hver server er i stand til å "absorbere" en del av angrepet, noe som reduserer belastningen på en bestemt server. Et tjenestenektangrep vil sannsynligvis være lokalisert til serveren og ikke påvirke hele tjenesten.
Høy horisontal skalerbarhet
Anycast-systemer er godt egnet for tjenester med høye trafikkmengder. Hvis en tjeneste som bruker Anycast krever nye servere for å håndtere den økende trafikken, kan nye servere legges til nettverket for å håndtere den. De kan plasseres på nye eller eksisterende nettsteder.
Hvis det er en stor økning i trafikken på et bestemt sted, vil det å legge til en server bidra til å balansere belastningen for det nettstedet. Å legge til en server på et nytt nettsted vil bidra til å redusere ventetiden ved å lage en ny snarvei for noen brukere. Begge metodene bidrar også til å forbedre stabiliteten til tjenesten etter hvert som nye servere blir tilgjengelige på nettverket. Således, hvis en server er overbelastet, kan man ganske enkelt distribuere en annen på et sted som vil tillate den å akseptere en del av den overbelastede serverens forespørsler. Dette krever ingen konfigurasjon av klientene.
Dette er den eneste måten å betjene terabit med trafikk og et veldig stort antall brukere når det bare er noen få 10 eller 25 Gb/s-porter på serveren. 100 verter med én IP-adresse vil gjøre det mulig å behandle terabit-volumer av trafikk.
Enkel konfigurasjonsadministrasjon
Som nevnt ovenfor, er en interessant bruk av Anycast DNS. Det er mulig å plassere flere forskjellige DNS-servere i nettverksnodene, men bruk én DNS-adresse. Avhengig av hvor kilden befinner seg, blir forespørsler rutet til nærmeste node. Dette gir en viss trafikkbalansering og redundans i tilfelle DNS-serverfeil. I stedet for å konfigurere forskjellige DNS-servere avhengig av hvor de befinner seg, kan en enkelt DNS-serverkonfigurasjon spres til alle verter.
Anycast-nettverk kan konfigureres til å rute forespørsler ikke bare basert på avstand, men også basert på parametere som servertilgjengelighet, antall etablerte tilkoblinger. eller responstid.
Ingen spesielle servere, nettverk eller spesielle komponenter kreves for å bruke Anycast-teknologi på klientsiden. Men Anycast har også ulemper. Det antas at implementeringen er en kompleks oppgave som krever ekstra utstyr, pålitelige leverandører og riktig trafikkruting.
Fra en ren kilde til en vakker langt unna
Mens Anycast dirigerer brukere basert på minst hopp, betyr det ikke nødvendigvis minst forsinkelse. Latency er en mer kompleks beregning fordi ett hopp kan ha mer enn ti.
Eksempel: Interkontinental kommunikasjon kan involvere et enkelt hopp med svært høy latens.
Anycast brukes hovedsakelig for UDP-baserte tjenester som DNS. Brukerforespørsler blir rutet til "beste" og "nærmeste" datasenter basert på BGP-ruter.
Eksempel: En DNS-klientarbeidsstasjon med en Anycast DNS IP-adresse på 123.10.10.10 utfører DNS-oppløsning for den nærmeste av tre DNS-navneservere som er distribuert med samme Anycast IP-adresse. Hvis enten R1 eller Server A feiler, vil DNS-klientpakker automatisk videresendes til den neste nærmeste DNS-serveren via R2 og R3. I tillegg vil ruten til vår server A bli fjernet fra rutetabellene, noe som forhindrer videre bruk av denne navneserveren.
Implementeringsscenarier
Det er to generelle skjemaer som brukes til å bestemme hvilken server en bruker kobler til:
- Anycast-nettverkslag. Kobler brukeren til nærmeste server. Nettverksveien fra brukeren til serveren er viktig her.
- Applikasjonsnivå Anycast. Det er flere beregnede beregninger i denne ordningen, inkludert servertilgjengelighet, responstid, antall tilkoblinger osv. Det avhenger av den eksterne monitoren som gir nettverksstatistikk.
CDN basert på Anycast
La oss nå gå tilbake til bruken av Anycast i innholdsleveringsnettverk. Anycast er absolutt et interessant nettverkskonsept og får mer aksept fra neste generasjons CDN-leverandører.
CDN er et distribuert nettverk av servere som leverer innhold til sluttbrukere med høy tilgjengelighet og lav ventetid. Innholdsleveringsnettverk spiller en viktig rolle i dag som ryggraden i en rekke online multimedietjenester, og forbrukere blir mindre tolerante for lave nedlastingshastigheter. Video- og taleapplikasjoner er spesielt følsomme for jitter og nettverksforsinkelse.
CDN forener alle servere i ett nettverk og gir raskere innholdslasting. Noen ganger er det mulig å redusere brukerens ventetid med 5-6 sekunder. Målet med et CDN er å optimalisere leveringen ved å servere innhold fra serveren nærmest sluttbrukeren. Dette ligner veldig på Anycast, hvor den nærmeste serveren velges basert på plasseringen til sluttbrukeren. Det ser ut til at alle CDN-leverandører vil bruke Anycast som standard, men i virkeligheten er dette ikke tilfelle.
Applikasjoner som bruker protokoller som HTTP/TCP er avhengige av at tilkoblingen opprettes. Hvis en ny Anycast-node velges (for eksempel hvis serveren svikter), kan tjenesten bli avbrutt. Dette er grunnen til at Anycast tidligere ble anbefalt for tilkoblingsløse tjenester som UDP og DNS. Anycast fungerer imidlertid bra for tilkoblingsorienterte protokoller, for eksempel fungerer TCP fint i Anycast-modus.
Noen CDN-leverandører bruker Anycast-basert ruting, andre foretrekker DNS-basert ruting: nærmeste server velges avhengig av hvor brukerens DNS-server befinner seg.
Hybrid- og multidatasenterinfrastrukturer er et annet bruksområde for Anycast. Load Balancing IP-adressen mottatt fra leverandøren lar deg fordele belastningen mellom IP-adressene til ulike kundetjenester i leverandørens datasenter. Med hvilken som helst enhetsadresseringsteknologi gir den bedre ytelse under tett trafikk, feiltoleranse og bidrar til å optimalisere responstiden med et stort antall brukere.
I hybride multidatasenterinfrastrukturer kan du distribuere trafikk på tvers av servere eller til og med virtuelle maskiner på dedikerte servere.
Dermed er det et enormt utvalg av tekniske løsninger for å bygge infrastruktur. Du kan også sette opp IP-belastningsbalansering på tvers av flere datasentre ved å bruke en hvilken som helst enhet i gruppen for å optimalisere nettstedets ytelse.
Du kan distribuere trafikk i henhold til dine egne regler, og definere "vekten" til hver av de distribuerte serverne i hvert datasenter. Denne konfigurasjonen er spesielt nyttig når det er en distribuert serverpark, og ytelsen til tjenestene varierer. Dette vil tillate hyppigere distribusjon av trafikk for å forbedre serverytelsen.
For å lage et overvåkingssystem ved å bruke ping-kommandoen, er det mulig å konfigurere sonder. Dette lar administratoren definere sine egne kontrollprosedyrer og få en klarere oversikt over statusen til hver komponent i infrastrukturen. På denne måten kan tilgjengelighetskriterier defineres.
Det er mulig å bygge en hybrid infrastruktur: noen ganger er det praktisk å forlate backoffice i bedriftsnettverket, og outsource grensesnittdelen til leverandøren.
Det er mulig å legge til SSL-sertifikater for lastbalansering, kryptering av overførte data og sikkerhet for kommunikasjon mellom besøkende og bedriftens infrastruktur. Ved lastbalansering mellom datasentre kan SSL også benyttes.
Anycast-tjeneste med adressebelastningsbalansering kan fås fra Internett-leverandøren din. Denne funksjonen vil bidra til å forbedre måten brukere samhandler med apper basert på plassering. Det er nok å annonsere hvilke tjenester som er tilgjengelige i datasenteret, og trafikken vil bli omdirigert til nærmeste infrastruktur. Hvis det er dedikerte servere, for eksempel i Frankrike eller Nord-Amerika, vil klientene bli dirigert til nærmeste server på nettverket.
Et av alternativene for å bruke Anycast er det optimale valget av operatørens tilstedeværelse (PoP). La oss ta med . LinkedIn (blokkert i Russland) søker ikke bare å forbedre ytelsen og hastigheten til produktene sine - mobil- og nettapplikasjoner, men også å forbedre nettverksinfrastrukturen for raskere innholdslevering. For denne dynamiske innholdsleveringen bruker LinkedIn mye PoPs – Points of Presence. Anycast brukes til å dirigere brukere til nærmeste PoP.
Årsaken er at når det gjelder Unycast, har hver LinkedIn PoP en unik IP-adresse. Brukere blir deretter tildelt PoP basert på deres geografiske plassering ved hjelp av DNS. Problemet er at når du bruker DNS, ble omtrent 30 % av brukerne i USA omdirigert til en suboptimal PoP. Takket være den gradvise introduksjonen av Anycast, falt suboptimal PoP-tildeling fra 31 % til 10 %.
Resultatene av pilottesten vises i grafen, der y-aksen er prosentandelen av optimal PoP-tilordning. Etter hvert som Anycast "skalerte opp" i mange amerikanske stater, var det en forbedring i prosentandelen av trafikk mot den optimale PoP.
Anycast nettverksovervåking
I teorien er Anycast-nettverk enkle: flere fysiske servere blir tildelt samme IP-adresse, som BGP bruker for å bestemme ruten. Men implementeringen og utformingen av Anycast-plattformer er kompleks, spesielt for feiltolerante Anycast-nettverk. Enda vanskeligere er effektiv overvåking av Anycast-nettverket for raskt å identifisere og isolere feil.
Hvis tjenester bruker en tredjeparts CDN-leverandør for å betjene innholdet, er det svært viktig for dem å overvåke og verifisere nettverksytelsen. Anycast CDN-overvåking fokuserer på å måle ende-til-ende-latens og nest siste hop-egenskaper for å forstå hvilket datasenter som betjener innholdet. Parsing av HTTP-serverhoder er en annen måte å finne ut hvor dataene kommer fra.
Eksempel: HTTP-svarhoder som angir plasseringen til CDN-serveren.
For eksempel bruker CloudFlare sin egen CF-Ray-header i HTTP Response-meldinger, som inkluderer en indikasjon på datasenteret som forespørselen ble sendt til. Når det gjelder Zendesk, er CF-Ray-overskriften for Seattle-regionen CF-RAY: 2a21675e65fd2a3d-SEA og for Amsterdam er det CF-RAY: 2a216896b93a0c71-AMS. Du kan også bruke HTTP-X-hodene fra HTTP-svaret for å finne ut hvor innholdet befinner seg.
Andre adresseringsmetoder
Det finnes andre adresseringsmetoder for å dirigere brukerforespørsler til et spesifikt nettverksendepunkt:
unicast
Det meste av internett i dag bruker denne metoden. Unicast - unicast-overføring, IP-adressen er knyttet til kun en spesifikk node på nettverket. Dette kalles en-til-en-matching.
Multicast
Multicast bruker et en-til-mange-av-mange- eller mange-til-mange-forhold. Multicasting lar deg sende en forespørsel fra avsenderen samtidig til forskjellige utvalgte endepunkter. Dette gir klienten muligheten til å laste ned en fil i biter fra flere verter samtidig (noe som er nyttig for lyd- eller videostrømming). Multicast forveksles ofte med Anycast, men hovedforskjellen er at Anycast dirigerer avsenderen til én bestemt node, selv om flere noder er tilgjengelige.
Kringkaste
Et datagram fra en enkelt avsender blir rutet til alle endepunkter knyttet til kringkastingsadressen. Nettverket replikerer automatisk datagrammene for å kunne nå alle mottakere i sendingen (vanligvis på samme subnett).
geocast
Geocast ligner litt på Multicast: forespørsler fra en avsender sendes samtidig til flere endepunkter. Forskjellen ligger imidlertid i at adressaten bestemmes av dens geografiske plassering. Dette er en spesialisert form for multicasting som brukes av noen mobile peer-to-peer-rutingsprotokoller.
Geo Router beregner tjenesteområdet og tilnærmer det. Georoutere, utveksle serviceområder, bygge rutetabeller. Systemet med georutere har en hierarkisk struktur.
Unicast, Multicast og Broadcast.
Bruken av Anycast-teknologi forbedrer påliteligheten, robustheten og sikkerheten til DNS. Ved å bruke denne teknologien tilbyr operatørene sine kunder ulike typer DNS-baserte lastbalanseringstjenester. I kontrollpanelet kan du spesifisere IP-adressene som forespørsler skal sendes til avhengig av geografisk plassering. Dette vil gi kundene muligheten til å distribuere brukerforespørsler mer fleksibelt.
Noen operatører bruker per-point-of-presence (POP)-ruteovervåking: systemet analyserer automatisk de korteste lokale og globale rutene for POP-er og ruter dem gjennom de geografiske stedene med lavest ventetid uten nedetid.
For øyeblikket er Anycast den mest stabile og pålitelige løsningen for å bygge høylastede DNS-tjenester som har høye krav til stabilitet og pålitelighet.
.ru-domenet støtter 35 Anycast DNS-servere gruppert i 20 noder fordelt på fem Anycast-skyer. I dette tilfellet brukes prinsippet om å bygge på geografisk grunnlag, d.v.s. geocast. Når du plasserer DNS-noder, er det planlagt å flytte dem til geografisk spredte steder nær de mest aktive brukerne, den maksimale konsentrasjonen av russiske leverandører ved nodeplasseringspunktet, samt tilgjengeligheten av gratis kapasitet og enkel interaksjon med nettstedet.
Hvordan bygge en CDN?
CDN er et nettverk av servere som øker hastigheten på levering av innhold til brukere. samler alle servere i ett nettverk og gir raskere innholdslasting. Avstanden fra serveren til brukeren spiller en viktig rolle i nedlastingshastigheten.
CDN lar deg bruke servere som er nærmest målgruppen. Dette reduserer ventetiden, bidrar til å øke hastigheten på lasting av nettstedinnhold for alle besøkende, noe som er spesielt viktig for nettsteder med store filer eller multimedietjenester. Typiske applikasjoner for CDN-er er e-handel og underholdning.
Nettverket av ekstra servere opprettet i CDN-infrastrukturen, som er plassert så nært brukerne som mulig, bidrar til mer stabil og raskere datalevering. I følge statistikk reduserer bruken av et CDN forsinkelsen ved tilgang til et nettsted med mer enn 70 % sammenlignet med nettsteder uten et CDN.
Som? Å sette opp et CDN med din egen Anycast-løsning kan være ganske dyrt, men det finnes billigere alternativer. Du kan for eksempel bruke GeoDNS og vanlige servere med unike IP-adresser. Med GeoDNS-tjenester kan du opprette en geolokasjonsaktivert CDN der beslutninger tas basert på den virkelige plasseringen til den besøkende i stedet for plasseringen til DNS-løseren. Du kan sette opp DNS-sonen din til å vise amerikanske server-IP-adresser til amerikanske besøkende, mens europeiske besøkende vil se en IP-adresse fra Europa.
Med GeoDNS kan du returnere forskjellige DNS-svar avhengig av brukerens IP-adresse. For å gjøre dette er DNS-serveren konfigurert til å returnere forskjellige IP-adresser avhengig av kildens IP-adresse i forespørselen. Vanligvis brukes GeoIP-databasen til å bestemme regionen som forespørselen sendes fra. Geolokalisering ved hjelp av DNS lar deg sende innhold til brukere fra nærmeste nettsted.
GeoDNS definerer IP-adressen til klienten som sendte DNS-forespørselen, eller IP-en til leverandørens rekursive DNS-server, som brukes ved behandling av klientforespørselen. Landet/regionen bestemmes av klientens IP- og GeoIP-base. Klienten får da IP-adressen til nærmeste CDN-server. Les mer om å konfigurere GeoDNS.
Anycast eller GeoDNS?
Selv om Anycast er en flott måte å levere innhold på global skala, mangler den spesifisitet. Det er her GeoDNS kommer til unnsetning. Denne tjenesten lar deg lage regler som sender brukere til unike endepunkter basert på deres plassering.
Eksempel: Brukere i Europa blir rutet til et annet endepunkt.
Du kan også nekte tilgang til domener ved å droppe alle forespørsler. Dette er spesielt en rask måte å kutte av inntrengere.
GeoDNS gir mer nøyaktige svar enn Anycast. Hvis i tilfelle av Anycast den korteste ruten bestemmes av antall hopp, så i GeoDNS, skjer ruting for sluttbrukere avhengig av deres fysiske plassering. Dette reduserer ventetiden og forbedrer nøyaktigheten når du oppretter detaljerte rutingsregler.
Når du bytter til et domene, får nettleseren tilgang til nærmeste DNS-server, som, avhengig av domenet, utsteder en IP-adresse for å laste siden. Anta at en nettbutikk er populær i USA og Europa, men det finnes DNS-servere for den bare i Europa. Da vil brukere fra USA som ønsker å bruke tjenestene til butikken bli tvunget til å sende en forespørsel til nærmeste server, og siden det er veldig langt unna, vil det ta lang tid å vente på svar - siden vil ikke last raskt.
Når du plasserer en GeoDNS-server i USA, vil brukere allerede kontakte den. Responsen vil være rask, noe som vil påvirke nettstedets lastehastighet.
I en situasjon med en eksisterende amerikansk DNS-server, når en bruker fra USA navigerer til dette domenet, vil han henvende seg til nærmeste server, som vil utstede ønsket IP. Brukeren vil bli dirigert til serveren som inneholder innholdet på siden, men siden serverne med innholdet er langt unna, vil han ikke få det raskt.
Hvis du også plasserer CDN-servere med hurtigbufrede data i USA, vil klientnettleseren ved lasting sende en forespørsel til nærmeste DNS-server, som sender tilbake riktig IP-adresse. Nettleseren med den mottatte IP-en kontakter nærmeste CDN-server og hovedserveren, og CDN-serveren sender det bufrede innholdet til nettleseren. Mens det bufrede innholdet lastes, kommer filene som mangler for å laste hele nettstedet fra hovedserveren. Som et resultat reduseres nettstedets lastetid, siden mye færre filer sendes fra hovedserveren.
Å bestemme den nøyaktige plasseringen til en bestemt IP-adresse er ikke alltid en lett oppgave: det er mange faktorer som spiller inn, og eierne av et IP-adresseområde kan bestemme seg for å kunngjøre det til den andre siden av verden (da må du vente til databasen oppdateres for å få riktig plassering). Noen ganger tildeler VPS-leverandører adresser som antas å være i USA til VPS i Singapore.
I motsetning til bruk av Anycast-adresser, gjøres tildeling på tidspunktet for navneoppløsning, ikke på tidspunktet for tilkobling til cache-serveren. Hvis den rekursive serveren ikke støtter EDNS-klientundernett, brukes plasseringen til den rekursive serveren i stedet for brukeren som skal koble til hurtigbufferserveren.
Klientundernett i DNS er en utvidelse av DNS (RFC7871) som definerer hvordan rekursive DNS-servere kan sende informasjon om en klient til en DNS-server, nærmere bestemt nettverksinformasjon som en GeoDNS-server kan bruke for mer nøyaktig å bestemme en klients plassering.
De fleste bruker ISP sine DNS-servere, eller DNS-servere som er geografisk nære dem, men hvis noen i USA av en eller annen grunn bestemmer seg for å bruke en DNS-løser lokalisert i Australia, vil de mest sannsynlig få en IP.-serveradresse nærmest Australia.
Hvis du ønsker å bruke GeoDNS, er det viktig å være klar over disse funksjonene, da det i noen tilfeller kan øke avstanden mellom cachingserverne og klienten.
Sammendrag: Hvis du vil kombinere flere VPS-er til en CDN, er det beste distribusjonsalternativet å bruke en DNS-serverpakke med GeoDNS + Anycast-funksjonen ut av esken.
Kilde: www.habr.com