Я предполагаю, что этот вопрос может быть озаглавлен, как CDN работает на уровне DNS, но настоящая проблема, с которой я сталкиваюсь, заключается в том, что у моей компании есть центры обработки данных на трех континентах, и у нас должны быть europe.example.com us.example.com и asia.example .com
CDN обычно отправляют вас в локальный центр обработки данных, как я полагаю, в зависимости от вашего IP-адреса. Это должен быть DNS, где у вас есть DNS-сервер в США, который отправляет вас в центр обработки данных в США для того же поиска DNS example.com?
Я ошибся? Если я ошибаюсь, как бы я мог сделать это эффективно и, если возможно, без центральных (не DNS) серверов?
Проблема с CDN в том, что они направляют вас не на основе вашего собственного IP-адреса - они направляют вас на основе IP-адреса вашего DNS-сервера ... Это может быть совершенно неверно. И читать Статья Пола Викси в ACM, это удар по деньгам.
Во всяком случае, если у вас уже есть region.example.com настроил и запустил, вы мог рассмотрите возможность перенаправления HTTP с example.com на соответствующий веб-сервер в зависимости от IP-адреса клиента.
Это в значительной степени то, что делает Google, так я в итоге google.co.uk набрав google.com.
Также убедитесь, что вы предоставляете клиентам средства для перехода к другим вариантам. Клиентам не нравится, когда они вынуждены переходить на конкретный сайт, будь то из-за ошибок в базах данных Geo или просто потому, что им действительно нужно увидеть сайт из другого региона.
Новые CDN (Cloudflare, MaxCDN, fast.ly) используют anycast как для DNS, так и для реальных серверов контента. Это несколько лучше, чем пытаться использовать исходный IP-адрес DNS-запроса и постоянно меняющуюся базу данных сопоставления.
Теоретически использование anycast как для DNS, так и для контент-серверов позволяет самой сети находить «ближайшие» серверы к клиенту. На практике это в основном верно, но возникают некоторые странные случаи, когда люди в Сингапуре попадают на пограничные серверы в Калифорнии, а не в Гонконге из-за постоянно меняющихся отношений пиринга между интернет-провайдерами.
Anycast - это трудно преуспеть.
Старые CDN, такие как Akamai и Limelight, обычно используют anycast, чтобы добраться до ближайшего DNS-сервера, но затем используют подход на основе предположений на основе IP-адреса источника. По моему опыту, это не работает, особенно если клиент использует DNS-серверы, которых нет поблизости с точки зрения топологии сети. Тем не менее, у огромного установленного CDN, такого как Akamai, есть сотни местоположений контент-серверов, поэтому ответ «достаточно близко» обеспечивает достойный пользовательский опыт. Очевидно, что наличие сотен сайтов обходится очень дорого, поэтому ни одна из сетей CDN с универсальным доступом не выбрала этот маршрут. Следовательно, они также не берут так много за почти эквивалентную услугу.
Есть несколько способов справиться с этим, но все они сводятся к тому, чтобы выяснить, где находится IP-адрес, и указать его соответствующим образом. Например, вы можете указать диапазон IP-адресов для Северной Америки и один для Европы. Если IP-адрес, запрашивающий информацию (от DNS, вашего веб-сервера, вашего контент-сервера и т. Д.), Попадает в европейский диапазон, то ваши европейские серверы должны получать запросы.
Вы можете настроить главную страницу по умолчанию на example.com. При первом посещении они выбирают, в какой регион они хотят быть направлены. Точно так же работает www.ups.com.
Пользователь может установить флажок, чтобы сделать его / ее выбор по умолчанию с этого момента, таким образом сохраняя выбор в файле cookie.
Это дает вам преимущество использования DNS в том виде, для которого он был разработан по словам Пола Викси, в то же время позволяя вашему пользователю сделать наиболее точное решение о том, в какой центр обработки данных они должны быть направлены.
Если у вас есть веб-сайт, размещенный в нескольких регионах, вам не нужно ничего делать на уровне DNS. Вы можете использовать API, например http://ipinfo.io чтобы узнать страну посетителя, а затем перенаправить его на соответствующий URL.
Если мы не говорим о веб-сайте или каком-либо протоколе, который обрабатывает перенаправления, то на уровне DNS есть несколько вариантов. Вы можете выполнить тот же поиск страны IP, а затем вернуть запись, которая соответствует региону (DNS на основе геолокации), или вы можете иметь карту задержки между разными сетями и вернуть запись, которая представляет наименьшую задержку для пользователя (задержка на основе DNS). Amazon Сервис Route53 DNS предлагаю оба.