В CDN применяется два метода для определения самого близкого узла к пользователю, в этой статье расскажем о GeoDNS, Anycast и нюансы их работы.
· Anycast – выбирает наиболее эффективные маршруты для доставки интернет-трафика.
· GeoDNS – определяет ближайший узел по местоположению запроса.
Обычно GeoDNS и Anycast нецелесообразно использовать вместе, если у вас не самая крупная система в мире или если нет бюджета на поддержание всей этой инфраструктуры. Выберите один метод, который больше всего подходит для вашей системы.
В конце статьи описан будет пример комбинации двух этих подходов.
Anycast — этот метод, при котором сервера используют один и тот же публичный IP-адрес, но находятся удаленно друг от друга.
Anycast использует в работе протокол BGP – Border Gateway Protocol, который выбирает наиболее эффективные маршруты для доставки интернет-трафика.
Понятия:
· AS (Autonomous System) – это сеть, управляемая одной организацией.
· AS-path описывает через какие автономные системы надо пройти, чтобы дойти до сети назначения.
· ISP (Internet Service Provider) - интернет провайдер.
Нюансы работы Anycast:
· Его задача - направить трафик к ближайшему серверу.
Определяет ближайший путь до нашего сервера на основе “переходов/шагов" и других параметров.
· В протоколе BGP содержится информация о смежных сетях (AS) и длину AS-path (кол-во переходов).
· Anycast не анализирует геоданные – он не вернет IP в зависимости от страны/города в котором находится наш пользователь, он просто ищет самый короткий маршрут.
Поэтому, российский и немецкий пользователи могут попасть на один и тот же ближайший сервер.
· Он не поддерживаем многое то что есть в GeoDNS.
Например, локализация может быть кривой – выдается одинаковый контент для разных регионов, если вдруг не правильно был задан AS-path.
Пример передвижения трафика между AS:
Как провайдеры находят конечный сервер и выбирают оптимальный маршрут? (В примеры привел Cloudflare)
— Каждый провайдер (AS) анонсирует свои IP-сети через BGP (Border Gateway Protocol).
Каждый сервер Cloudflare рассылает анонсы по BGP, в которых описан AS-path.
Пример анонсов:
· Сеть: 1.1.1.0/24, AS-path: AS3320 → AS1234 → AS13335
· “IP 95.123.1.1 доступен через меня (AS12345 – свой уникальный номер)”.
Эти анонсы распространяются по всей сети интернет через соседние маршрутизаторы (BGP-пиры).
— Транзитные партнёры Cloudflare.
В цепочке AS могут быть транзитные сети (AS), например, сети вашего провайдера или сети магистральных операторов связи.
Cloudflare заключает договоры с локальными провайдерами (например, Ростелеком, Deutsche Telekom).
Ростелеком анонсирует: "Я могу доставить трафик до Cloudflare".
Эти анонсы также распространяются по цепочке через BGP-пиринги (соседние провайдеры).
— Как находится “кратчайший” путь?
Как раз в анонсах (BGP-анонсы) уже отправляется вся информация о пути и через какие AS пройдет трафик до вашего Cloudflare.
И эта информация хранится у вашего провайдера (ISP) в таблице маршрутизации.
Ниже будет описано по каким критериям выбирается лучший путь.
То есть это не "поиск в реальном времени" ближайшего сервера, а выбор из уже известных вариантов, которые обновляются при изменениях в сети.
Если анонсов не будет, то ранее заданные маршруты ISP удаляет из таблицы через 1-2 минуты (обычно), после трафик автоматически переключается на следующий известный лучший маршрут.
— Как избегают "плохих" маршрутов?
Cloudflare и провайдеры используют BGP-теги для управления маршрутами.
Например: AS13335:80 # "Не отправляй трафик через этот маршрут в Азию"
Три ключевых приоритета для нахождения лучшего пути
Когда вы запрашиваете Anycast-IP (например, 1.1.1.1), ваш интернет-провайдер (ISP) определяет лучший путь на основе приоритетов:
1) Local Preference
Провайдер сначала смотрит на local-pref, который обозначает приоритет.
Даже если AS-path короче, то выберется путь у которого local-pref выше.
Хорошо использовать для определения дешевых или резервных путей, блокировки нежелательных провайдеров (LOCAL_PREF: 0).
Например, немецкий провайдер будет считать Франкфурт "ближе", чем Москву.
2) Кратчайший AS-path
Чем короче список AS — тем "ближе" маршрут.
Пример:
· Путь до московского сервера:
AS-your-ISP → AS-Russia → AS-Cloudflare (1.1.1.1) (3 прыжка).
· Путь до франкфуртского:
AS-your-ISP → AS-France → AS-Germany → AS-Cloudflare (1.1.1.1) (4 прыжка).
Выбор падает на московский сервер.
Примечание:
Вот эти “AS-Germany”, “ AS-Russia” используют свои IP для инфраструктуры, но помогают Cloudflare анонсировать Anycast-IP (1.1.1.1).
Пользователь всегда видит только 1.1.1.1, но трафик проходит через сети партнёров.
BGP объединяет всё это в единую систему, делая Anycast возможным.
Некоторые провайдеры могут блокировать определенные AS, поэтому какие-то пути могут быть как длиннее, так и короче.
3) Междатацентровые метрики – дополнительные метрики.
· Задержка (ping).
· Стоимость трафика (может дешевле отправить в Германию, чем в Австралию).
· Качество отправки пакетов, может часто пакеты теряются по пути.
Зачем предлагать несколько маршрутов, если можно сразу указать самый ближайший и короткий?
· Интернет — это гигантская сеть независимых операторов (AS), и прямое подключение ко всем невозможно физически и экономически.
Кабеля, соединения и тд, не все соединены напрямую друг с другом или просто не могут владеть всеми этими кабелями и обслуживать их.
· Каждый провайдер (AS) владеет своей частью инфраструктуры.
· Никто не контролирует весь интернет: даже Google или Cloudflare зависят от других AS для доставки трафика.
· Также каждый посредник берет плату за трафик, поэтому часто выбирается самый “короткий” путь.
· Можно это представить как авиаперелеты:
Есть путь: Москва (Шереметьево) → Дубай (DXB) → Сидней (SYD). У данного пути нет прямого рейса, поэтому приходится делать пересадку. А если и есть прямой рейс, то это очень дорого, все билеты выкупают только обеспеченные.
Если бы AS не сотрудничали, интернет распался бы на изолированные куски.
Anycast работает именно благодаря этой глобальной кооперации.
Плюсы Anycast:
- Автоматическая балансировка трафика.
- Меньше задержки (трафик автоматически идёт на ближайший узел).
Как правило, работает быстрее, чем GeoDNS «из коробки», когда рядом находится множество местоположений. - Есть возможность сэкономить - перенаправлять трафик по самому дешевому пути.
- Изменения списка серверов может быть быстрым и легким.
Не нужно реорганизовывать руками. - Защита от DDOS.
Атака дробится между десятками дата-центрами (узлами), тк используется один IP-адрес.
Минусы Anycast:
- Высокие требования к инфраструктуре:
Разнесённые дата-центры.
Настройка BGP.
Аренда блока IP-адресов.
Все это дорогое удовольствие и нужны компетенции для настройки. - Нет гарантии, что клиент попадёт на ближайший сервер.
"Ближайший" ≠ "самый быстрый" - пакеты могут идти через неоптимальные маршруты.
Обычно меньшее количество переходов коррелирует с меньшей задержкой, но это не всегда так. Иногда один переход через океан может считаться равносильным одному переходу между городами, несмотря на высокую задержку.
Также разные ISP могут видеть разный "ближайший" узел. Пользователи одного провайдера попадают на один сервер, пользователи другого провайдера на другой сервер, даже если физически находятся рядом. - Задержки при failover (переключении на другой узел).
Если один узел падает, BGP требует времени на обновление маршрутов, обычно 1-2 минуты. - Мало контроля над тем, как распределяется ваш трафик.
- Мониторинг таких серверов с помощью стандартных служб значительно сложнее.
- Трудно определить физический узел, который обрабатывал запрос.
Если узел в Нью-Йорке падает, BGP автоматически переключает трафик на Лондон — внешне сервис работает, но проблема остаётся.
Пример: Zabbix видит, что 1.1.1.1 отвечает, но не понимает, что трафик теперь идёт через Сингапур вместо Токио.
- Маршруты могут постоянно меняться из-за BGP
- Сбои на стыках AS
GeoDNS - это процесс распределения трафика на основе местоположения запросов.
Это тот же DNS просто с дополнительным функционалом.
Все ваши серверы будут иметь разные IP-адреса.
Он более гибкий, чем Anycast, тк позволяет учесть страну, город, район.
Понятия:
· EDNS (Extended DNS) - позволяет передавать дополнительные данные в DNS-запросе (Это конверт над DNS, чтобы передавать ECS).
· ECS (EDNS Client Subnet) – это адрес, можно сказать "подсказка" от браузера, чтобы GeoDNS работал точнее и знал где находится наш пользователь.
Типо подсеть обозначает “92.123.45.0/24”.
Без ECS все пользователи получают ответ от GeoDNS в зависимости от местоположения их Резолвера, независимо от реального местоположения пользователя.
· Резолвер – это DNS от провайдера (МТС, Ростелеком) или тот, который ты задал руками в настройках винды.
· Авторитативный DNS-сервер - "главная телефонная книга" для вашего домена.
Владеет точными записями (IP-адреса) о домене, в отличие от кэширующих резолверов (как Google DNS или ваш провайдерский).
Хранит фактические IP и записи домена.
Пример: cервер google.com = 142.250.185.46.
· TLD-сервер (Top-Level Domain Server) - знает только NS-записи (список авторитативных серверов) для доменов в своей зоне (например, все .COM или .RU).
Знает список авторитативных серверов домена.
Пример: список NS-записей для google.com: ns1.google.com, ns2.google.com
· Корневой DNS-сервер - отвечает на запросы других DNS-серверов, позволяет получить список DNS-серверов для любого домена верхнего уровня: RU, COM, NET, MUSEUM и др.
Это 13 глобальных серверов (имена a.root-servers.net - m.root-servers.net).
Знает где искать TLD-серверы.
Примечание: корневые серверы дают адреса TLD-серверов (для .com и т.д.), а TLD-сервера уже указывают на авторитативные серверы домена.
Благодаря корневым и TLD-серверам будет находится наш Авторитативный DNS-сервер по домену.
Как происходит работа с GeoDNS:
- Пользователь в Москве ищет example.com
- Браузер отправляет DNS-запрос к локальному DNS-резолверу (провайдерский), добавляя в запрос ECS.
- Локальный DNS-резолвер запрашивает Авторитативный DNS-сервер домена и отправляет запрос к нему (например, к ns.example.com).
- Данный Авторитативный DNS-сервер, который реализуется как GeoDNS, получает запрос.
- Идет определение местоположения пользователя благодаря переданному ECS.
- У GeoDns есть БД - "таблица" с соответствием IP и страны/штата/города, где написано:
92.123.xx.xx → Россия
104.18.xx.xx → США - GeoDns идет в эту GeoIP-базу, быстро определяется откуда IP и выбирает нужный ответ (ближайший сервер).
- Ближайший IP-адрес к пользователю возвращен.
- Браузер и DNS-резолвер кэширует этот IP (запоминает на некоторое время).
- Дальше запрос идет к этому IP и наш провайдер смотрит на свою BGP-таблицу, чтобы найти где находится наш сервер и по какому пути до него добраться.
По сути используется AS-path, приоритеты (local_pref), задержки и тд.
Но это не Anycast, тк тут у каждого сервера свой IP. Это просто подкапотная работа вашего провайдера - как ему доставить данные до конечной точки (а он в свою очередь уже использует BGP для этого). - Последующие запросы – браузер и резолвер проверяет свой кэш, используют оттуда данные, а если данные истекли, то заново идет запрос в GeoDNS.
Пример кода с определением ближайшего сервера на основе IP-адреса:
Нюансы работы "с" и "без" ECS:
· БЕЗ ECS - GeoDNS видит только IP провайдера DNS, но не твой реальный IP.
(например, МТС/Ростелеком - типо IP-резолвера или если ты свой указываешь в винде, то именно этот IP используется)
Здесь GeoDNS определяет уже ближайший узел к резолверу, а не ближайший к пользователю.
Пример: Если твой резолвер/DNS – это “Google DNS (1.1.1.1)”, который находится в США, то те кто его использует будут отображаться как пользователи из США, даже россиянам.
Соответственно без ECS запрос в GeoDNS идет от лица этого DNS-сервера, который предоставил нам провайдер, а не от реального местоположения пользователя.
· С ECS - DNS видит примерное местоположение пользователя (например, Москва, 92.123.45.67).
Тут резолвер уже передает “подсказку” в GeoDNS.
GeoDNS понимает, что запрос из России, и отправляет IP-адрес ближайшего узла к пользователю.
Примечание:
Не все DNS-резолверы поддерживают ECS, но основные поддерживают, такие как: Cloudflare, Google, Quad9.
Плюсы GeoDNS:
- Быстро и дешево - его легко реализовать, главное иметь актуальную GeoIP базу, и не требует специфических знаний.
- Мониторинг - легко проверить какой IP-адрес придет в ответ на запрос определенного пользователя с помощью эмуляции запросов из разных стран.
- Обход блокировок (осуждаем такое!).
- Выдача данных зависимых от гео.
Например, геотаргетинг или просто локализация. - Гибкий - можем контролировать и балансировать трафик так, как нам захочется.
Минусы GeoDNS:
- Отказоустойчивость - если московский сервер падает, то GeoDNS продолжит возвращать московский IP, так как не знает о сбое. Необходимое ручное переключение на другой регион, на что потребуется время.
К тому же такие IP могут кэшироваться и отдаваться длительное время, что тоже дает свой вклад в эту проблему.
Чтобы это решить нужно реализовать Health checks и динамически обновлять записи с адресами - доступен ли сервер или нет, понимать какой теперь сервер ближайший к пользователю. У некоторых продуктов таких механизмов может и не быть под капотом, а реализовывать это все с нуля не простая задача. - Пользователи могут направляться не на самое быстрое место.
GeoDNS не проверяет задержку до серверов или нагрузку на сами серверы. - Неточность геолокации - все зависит от базы используемой для ее определения, тк в GeoIP БД может быть неверная или устаревшая информация, потому что обновляются вручную.
Есть к тому же динамические/перепродаваемые IP (например, российский провайдер мог использовать старый диапазон IP, который раньше принадлежал африканскому), VPN, прокси будут искажать реальное местоположение пользователя.
Из-за этого GeoDNS отправит некоторых пользователей на неправильный сервер. - Конфиденциальность (ECS может не передаваться).
Некоторые резолверы могут не отправлять исходный IP-адрес (ECS), из-за чего опять страдает неточность.
GeoDNS видит IP резолвера, а не пользователя, по итогу выдается не самый ближайший узел к пользователю. - Зависимость - долгое внесение изменений в GeoIP базу при выявлении неточности.
В большинстве случаев не вы обслуживаете данную БД и придется ждать новых изменений, либо изучать как вносить изменения самим в БД, что тоже не хорошо, тк за всеми изменениями можно не уследить.
Либо использовать платные версии таких баз, чтобы была быстрая поддержка и поддержание ее в актуальном состоянии. - Частичная информация - некоторые DNS-провайдеры обрезают подсеть (например, префикс маски только /24 вместо точного /32).
- Ограниченная поддержка IPv6 - многие GeoIP-базы хуже покрывают IPv6, чем IPv4.
- Внесение изменений в список серверов (отсутствие автоматической балансировки) - у нас есть 2 сервера в Европе и нужно добавить третий между ними.
Из-за этого нам придется нарисовать "карту" и высчитать откуда и куда теперь будет перенаправляться трафик. Особенно сложно все это сделать, если до этого была тщательная настройка маршрутизации - это все придется заново "перелапатить".
Благо их всего 2 сейчас, а если больше? Сколько времени потребуется, чтобы все это изменить?
То же самое и с удалением - можно конечно перезаписать для всех записей с таким гео, которые были привязаны к удаляемому серверу, что перенаправлять теперь на другой сервер, но будет страдать неточность, тут снова нужно будет продумывать лучший способ маршрутизации для каждой локации. - Ручная настройка для сопоставлений конкретных локаций (страны, города) и ближайших серверов к ним.
- Не защищает от DDOS атак.
Атака не дробится между несколькими дата-центрами (узлами).
Как можно комбинировать Anycast и GeoDNS?
Комбинация может помочь избавиться от минусов каждого из подхода, но это не панацея.
Сначала GeoDNS, потом Anycast.
· Уровень GeoDNS - Разделяет трафик по странам/регионам, возвращая IP разных кластеров, размещенных в разных странах (то есть не конкретных серверов!).
GeoDNS не знает о внутренней структуре кластеров — он просто возвращает их Anycast-IP в рамках страны.
· Уровень Anycast - каждый кластер (Москва + Владивосток + Казань) развёрнут с Anycast — один IP анонсируется из множества точек, например, в рамках одной страны.
Пользователь из Самары получает от GeoDNS IP 95.123.1.1 (кластер из России), после с помощью Anycast он автоматически направляется на ближайший физический сервер внутри кластера (например, в Москву, а не во Владивосток).
Пример, есть такой список серверов:
Сервер США EAST: 1.1.1.1 2.2.2.2
Сервер США WEST 1.1.1.1 2.2.2.2
Сервер Европа EAST: 1.1.1.1 3.3.3.3
Сервер Европа CENTRAL: 1.1.1.1 3.3.3.3
Сервер Европа WEST: 1.1.1.1 3.3.3.3
Сервер Австралия: 1.1.1.1 4.4.4.4
GEO DNS DEFAULT: 1.1.1.1
GEO DNS NORTH AMERICA: 2.2.2.2
GEO DNS EUROPE: 3.3.3.3
GEO DNS OCEANIA: 4.4.4.4
Каждому серверу выдается Anycast-IP так, что они относятся только к конкретному континенту и управляется это с помощью GeoDNS.
Здесь решается проблема когда на основе BGP пользователя могут отправить через океан на другой континент.
Если пользователь находится в Азии, а у нас сервера только в Америке или Европе, то он получит стандартный IP 1.1.1.1 и будет использоваться BGP для определения ближайшего узла, поэтому потенциально может попасть на любой сервер.
Все минусы каждого из подходов такая комбинация МОЖЕТ (но не во всех случаях) исключить:
- Максимальная отказоустойчивость
- Находит быстро и точный ближайший узел
- Есть защита от DDOS
Если без связки Anycast и GeoDNS реализовать, а выбрать только одну конкретную, то будет работать менее надежно и будет отдавать возможно не самый ближайший/быстрый сервер к пользователю, а такая комбинация может исключить этого.
Эта комбинация подойдет для:
- Глобальных сервисов (CDN).
- Высоконагруженных DNS-сервисов.
- Сценариев, где нужна отказоустойчивость и геоточность.