Wan unicast что это
Юникастовая маршрутизация мультикаст-трафика
Предисловие
Недавно мною было замечено, что при просмотре мультикастового IPTV через Wi-Fi часть трафика теряется. После детального изучения проблемы было выяснено, что такое поведение объясняется природой мультикаст-трафика, а именно – MAC-адрес получателя пакета. Он не зависит от получателя и формируется из адреса мультикаст-группы. Соответственно, на такие пакеты претендуют все клиенты, подключенные к беспроводной точке доступа. Вследствие этого нам достается лишь часть пакетов и мы видим обрывистую картинку.
Штатными средствами проблема решается либо созданием отдельной точки доступа для клиента, либо созданием статического маршрута для определенных мультикаст-групп, или же выведением клиента в отдельный VLAN. Вся “сила” таких решений проявится, когда в сети будет несколько IPTV-приставок, желающих посмотреть один и тот же канал, плюс необходимость их в интернете добавит сложность к настройке роутера. Свое решение данной проблемы предлагаю ниже.
Программы типа udpxy здесь не подходят, так как они меняют полную структуру пакета. А нам необходимо лишь установить необходимый MAC-адрес, при этом сохраняя сетевую и транспортную части, чтобы клиентское ПО не заметило никаких изменений.
Немного теории
Схематическое представление mfc_cache-списка:
Изображение взято из книги “Linux Networking Architecture”
Разработка
За основу было взято ядро Linux 3.18. Для хранения IP-адресов клиентов для каждой мультикаст-группы расширяем mfc_cache связанным списком:
Вводим новую функцию ipmr_unicast_xmit. В ней будет генерироваться юникастовый rtable, но передавать при этом будем мультикастовый sk_buff. Таким образом мы выбираем необходимый интерфейс для будущей отправки.
Теперь для того, чтобы в дальнейшем был создан neighbour для нашего получателя, а не для мультикаст-группы, в rtable указываем шлюз. За это отвечает поле rt_gateway:
Вводим sysctl-переменную /proc/sys/net/ipv4/mut. Она даст возможность смены режима работы ядра “на лету”.
Как и раньше можно посмотреть список маршрутов, теперь еще и unicast:
# cat /proc/net/ip_mr_cache
Group Origin Iif Pkts Bytes Wrong Dsts
0520C3EF 2 18842 25323648 0 01000A0A
Подробнее со всеми изменениями можно ознакомиться в репозитории. Ссылка в конце статьи.
Наглядное представление работы (изменения в колонке с MAC-адресом):
Маршрутизатор
За основу взята программа IGMPProxy. Можно было взять любую другую, тот же mrouted. Очень важно, что все IGMP-сообщения отправляются от IP-адреса запрашивающего интерфейса, и нам ни что не мешает его использовать. Подробности изменений описывать смысла нет, их также можно найти в соответствующем репозитории. Главное то, что в управлении ядра появляются две новые команды, которые должна поддерживать программа:
Предупреждение
Стоит заметить, что такой подход не дает возможности отключать клиентов от групп за отсутствие от них Membership Report-запросов, так как, исходя из протокола IGMP, клиент, получивший от другого клиента такой запрос с той же группой, сам не отправляет аналогичный. Поэтому отключение возможно только после получения явного Leave Group-пакета.
Использование
Для включения новой возможности необходимо скомпилировать ядро с опцией CONFIG_IP_MUT=y
Для полноценной работы измененной IGMPProxy также необходимо включить CONFIG_SYSCTL_SYSCALL=y
Ссылки
Использованная литература
Rami Rosen «Linux Kernel Networking. Implementation and Theory»
Christian Benvenuti «Understanding Linux Network Internals»
Klaus Wehrle and Frank Pahlke «Linux Networking Architecture»
Если у кого-нибудь есть иной способ решения проблемы, прошу поделиться в комментариях.
Технология Multicast: рациональная передача мегапиксельного видеотрафика
Для более рационального использования пропускной способности и снижения требований к выделяемым каналам связи необходимо использовать технологии экономичного расходования ресурсов вычислительной сети. Рассмотрим всем известные технологии передачи потоков данных от источника к заинтересованным получателям – Multicast и Unicast.
Multicast и Unicast: ключевые различия
Между технологиями Multicast и Unicast есть принципиальная разница в способе передачи данных.
На рисунке приведено сравнение Unicast-технологии (сверху) копирования потоков данных в соответствии с числом получателей и Multicast-технологии (снизу) с возможностью передавать одну копию большому числу получателей.
Unicast – классическая технология, позволяющая передавать поток данных строго заинтересованному получателю. Используемые протоколы и методы обработки хорошо известны, поэтому не будем на этом подробно останавливаться.
Технология Multicast позволяет передавать потоки данных по IP-сетям, без излишнего дублирования, широкому кругу заинтересованных получателей (рабочие места видеонаблюдения, мобильные устройства, абоненты IPTV, терминалы видеоконференцсвязи), экономя пропускную способность канала. Unicast для вышеописанных целей крайне неэффективен, так как единый источник данных вынужден отправлять столько копий одних и тех же данных, сколько было запрошено. Это приводит к чрезмерной нагрузке на источник данных и локальную сеть (при большом количестве приемников).
Тонкости IP Multicast IP
Multicast использует UDP-пакеты (User Datagram Protocol), что позволяет передавать данные с меньшими задержками, но не отслеживает потери пакетов. Есть возможность компенсировать этот недостаток классификацией трафика (технология QoS).
IP Multicast оперирует группами подписчиков – для получения данных от каждого источника. Каждый подписчик определяет свою принадлежность к той или иной группе, отправляя IGMP-ответ (Internet Group Management Protocol) устройству (часто маршрутизатору), которое опрашивает сеть о существующих группах рассылки с использованием IGMP-сообщений. В результате формируются группы получателей. Для каждой группы источник генерирует один поток данных, а сетевые устройства (маршрутизаторы и коммутаторы) обеспечивают получение этого потока каждым подписчиком конкретной группы.
Прогрессивное применение Multicast
Технологию Multicast крайне целесообразно применять в случаях, когда источники видеосигнала (будь то видеокамера или видеосервер) находятся на значительном удалении от приемников данного сигнала. Это могут быть разные терминалы аэропорта, разные здания промышленного назначения с единым постом видеонаблюдения. Или обратная ситуация, когда приемники видеосигнала (например, АРМ видеонаблюдения) размещаются на значительном удалении от источников и не имеют широкополосного канала связи.
Бесспорная выгода использования технологии обусловлена тем, что у источника сигнала (видеокамеры или видеосервера) отсутствует необходимость генерировать количество одинаковых потоков в соответствии с числом приемников, которые одновременно желают получать видеоданные. Технология позволяет экономить не только пропускную способность интерфейсов источников, но и их вычислительные возможности. Экономия вычислительных возможностей – крайне актуальная тема для видеосерверов, поскольку на эти устройства возложен ряд серьезных задач, таких как прием, дешифрование, шифрование, распределение, дополнительное сжатие и преобразование, запись потоков видеоданных, реализация алгоритмов видеоаналитики.
Технология Multicast часто находит применение для рассылки видеосерверами потоков видеоданных рабочим местам и иным приемникам. Однако более прогрессивное применение технологии – использование Multicast-потоков видеокамеры (многие камеры имеют поддержку этой функциональности) для получения видеосигнала приемниками. Это позволяет экономить вычислительные мощности серверов, так как видеопотоки транслируются на приемники непосредственно в обход сервера, а сервер осуществляет запись (со всеми смежными функциями).
Памятка инсталляторам
Ретрансляция потоков данных
Технология Multicast относится к функциональности 3-го уровня и потому полноценно поддерживается маршрутизаторами. При этом возможно обойтись без маршрутизаторов, применяя коммутаторы 2-го уровня, но с функцией IGMP snooping.
Многие коммутаторы 2-го уровня могут прослушивать IGMP-сообщения, относящиеся к 3-му уровню, и добавлять соответствующих получателей в таблицу входящих в группу Multicast-хостов – этот механизм и называется IGMP snooping.
С использованием IGMP snooping коммутатор 2-го уровня ретранслирует потоки данных только тем адресатам, которые подписывались на получение Multicast-трафика в конкретную Multicast-группу. В некоторых коммутаторах прослушиванием и анализом IGMP-сообщений занимается отдельная интегральная плата. Она освобождает центральный процессор коммутатора от трудоемкой задачи анализа каждого Multicast-пакета и поиска в нем сообщений о присоединении или оставлении группы.
Реализация сети
При реализации сети с использованием Multicast важно обращать внимание не только на поддержку Multicast конечным и сетевым оборудованием, но и на скорость работы сетевых интерфейсов установленного в сети оборудования.
Тонкость в том, что в большинстве случаев инсталляций коммутаторы, несмотря на их широкие возможности по настройке и управлению, не конфигурируют, а ставят «как есть». Почему это происходит, мы обсуждать не будем. Важно следствие – любой ненастроенный коммутатор по умолчанию ведет себя с Multicast-трафиком одинаково – ретранслирует этот трафик на все свои порты, а не на порты, к которым подключены подписчики. Последствие этого явления довольно неприятное – сеть, рассчитанная на определенное значение пропускной способности, перестает справляться с ней, поскольку не предполагалось такого развития событий. В результате активное оборудование сети работает в перегруженном режиме.
Еще один неприятный момент заключается в том, что устройства с сетевыми интерфейсами небольшой пропускной способности (в том числе и Fast Ethernet) при интенсивном Multicast-трафике перестают успевать отбрасывать ненужные им пакеты и принимать нужные пакеты в связи с переполнением буфера интерфейса. В итоге часть пакетов, предназначенных такому устройству, теряется. Для пользователей это будет выглядеть как рассыпание изображений (для видеоданных), прерывание и неразборчивость речи (для аудио). Чтобы локальная сеть выполняла предполагаемые задачи, крайне важно сконфигурировать механизм IGMP snooping на всех коммутаторах 2-го уровня. Эта настройка является важной частью инсталляции и должна быть выполнена грамотным специалистом.
Технология Multicast дает неоспоримые преимущества, но – как и любая задача – ее применение требует комплексного подхода для получения высокоэффективного решения
Практические рекомендации
Резюмируя, хочу еще раз перечислить преимущества, которые дает технология Multicast при построении сети, предназначенной для передачи видео (в особенности мегапиксельного), и ключевых моментах, на которые следует обратить внимание.
Anycast против Unicast: что лучше выбирать в каждом случае
Про Anycast наверняка многие слышали. При этом методе сетевой адресации и маршрутизации один IP-адрес присваивается нескольким серверам в сети. Эти серверы могут находиться даже в удаленных друг от друга ЦОД. Идея Anycast в том, что, в зависимости от местоположения источника запросов, данные отправляются на ближайший (согласно топологии сети, точнее — протокола маршрутизации BGP) сервер. Таким образом, можно уменьшить количество сетевых переходов (hop) и задержку (latency).
По сути, объявляется один и тот же маршрут из нескольких центров обработки данных по всему миру. Таким образом, клиенты будут отправлены в «лучший» и «ближайший» исходя из маршрутов BGP, центр обработки данных. Почему все же именно Anycast? Зачем использовать Anycast вместо Unicast?
Unicast действительно подойдет для сайта с одним веб-сервером и умеренным объемом трафика. Однако если у сервиса миллионы подписчиков, то он обычно использует множество веб-серверов, каждый из которых имеет один и тот же IP-адрес. Эти серверы распределены географически для оптимального обслуживания запросов.
При таком сценарии Anycast даст улучшение производительности (трафик направляется пользователю с минимальной задержкой), обеспечит надежность сервиса (благодаря резервным серверам) и балансирование нагрузки — маршрутизация на несколько серверов эффективно распределит нагрузку между ними, улучшая скорость работы сайта.
Операторы предлагают клиентам различного вида балансирование нагрузки на основе Anycast и DNS. Клиенты могут указывать IP-адреса, на которые будут отправляться запросы в зависимости от географического местоположения сайта. Это дает возможность более гибко распределять запросы пользователей.
Предположим, есть несколько площадок, между которыми нужно распределить нагрузку (пользователей), например, интернет-магазин с 100 000 запросами в день или популярный блог. Для ограничения региона, откуда пользователи заходят на конкретную площадку, можно воспользоваться опцией Geo Community. Она позволяет ограничить регион, в рамках которого оператор будет анонсировать маршрут.
Anycast и Unicast: отличия
Anycast часто используется в таких приложениях, как DNS (система доменных имен) и CDN (сети доставки контента), позволяя принимать решения о маршрутизации, повышающие производительность сети. Сети доставки контента используют Anycast, поскольку имеют дело с большими объемами трафика, а Anycast дает в этом случае ряд преимуществ (о них — ниже). В DNS Аnycast позволяет существенно повысить уровень надежности и отказоустойчивости сервиса.
В Anycast IP при использовании BGP существует несколько маршрутов к конкретному хосту. На самом деле это копии хостов в нескольких центрах обработки данных, используемые для установления соединений с более низкой задержкой.
Итак, в сети Anycast один и тот же IP-адрес объявляется из разных мест, и сеть решает, куда направить запрос пользователя исходя из «стоимости» маршрута. Например, часто для определения кратчайшего маршрута передачи данных применяется протокол BGP. Когда пользователь отправляет запрос Anycast, BGP определяет наилучший маршрут для доступных в сети Anycast серверов.
Преимущества Anycast
| Уменьшение задержки | Системы с Anycast способны снизить задержку при обработке пользовательских запросов, поскольку позволяют получать данные с ближайшего сервера. То есть пользователи всегда будут подключаться к «ближайшему» (с точки зрения протокола маршрутизации) DNS-серверу. В результате Anycast снижает время взаимодействия за счет уменьшения сетевого расстояния между клиентом и сервером. Это не только уменьшает задержку, но также обеспечивает балансирование нагрузки. |
| Скорость | Поскольку трафик направляется на ближайший узел, и уменьшается задержка при передаче данных между клиентом и узлом, результатом будет оптимизация скорости доставки, независимо от того, откуда клиент запрашивает информацию. |
| Повышенная стабильность и отказоустойчивость | Если несколько серверов по всему миру используют один и тот же IP, то в случае сбоя одного из серверов или его отключения трафик будет перенаправлен на ближайший сервер. В результате Anycast делает сервис более устойчивым и обеспечивает лучший доступ к сети/задержку/скорость. |
Таким образом, благодаря наличию нескольких серверов, постоянно доступных для пользователей, Anycast, например, повышает стабильность работы DNS. При отказе узла пользовательские запросы будут перенаправлены на другой сервер DNS без какого-либо ручного вмешательства или перенастройки. Anycast обеспечивает практически прозрачное переключение на другие сайты, просто убирая маршруты проблемного сайта.
В DDoS-атаках часто применяются ботнеты, которые могут генерировать такой объем трафика, что он перегружает атакуемый сервер. Преимущество использования Anycast в этой ситуации заключается в том, что каждый сервер способен «поглощать» часть атаки, что снижает нагрузку на конкретный сервер. Атака типа «отказ в обслуживании», скорее всего, будет локализована на сервере и не повлияет на весь сервис.
Если в конкретном месте наблюдается большой рост трафика, то добавление сервера поможет сбалансировать нагрузку для данной площадки. Добавление сервера на новой площадке поможет сократить время ожидания, создав для некоторых пользователей новый кратчайший маршрут. Оба способа помогают также повысить стабильность сервиса, поскольку в сети становятся доступными новые серверы. Таким образом, если сервер перегружен, можно просто развернуть другой в том месте, которое позволит ему принимать некоторую долю запросов перегруженного сервера. При этом не потребуется настройка со стороны клиентов.
Только таким способом можно обслужить терабиты трафика и очень большое число пользователей, когда на сервере лишь несколько портов 10 или 25 Гбит/с. 100 хостов с одним IP-адресом дадут возможность обработать терабитные объемы трафика.
Сети Anycast можно настроить для маршрутизации запросов не только на основе расстояния, но и по таким параметрам, как наличие сервера, количество установленных соединений. или время ответа.
Для использования технологии Anycast со стороны клиента не требуется никаких специальных серверов, сетей или специальных компонентов. Но есть у Anycast и минусы. Считается, что его внедрение — сложная задача, требующая дополнительного оборудования, надежных провайдеров и правильной маршрутизации трафика.
От чистого истока в прекрасное далёко
Хотя Anycast направляет пользователей на основе наименьшего количества переходов, это не обязательно означает минимальную задержку. Задержка — более сложная метрика, поскольку у одного перехода она может быть выше, чем десяти.
Пример: межконтинентальные коммуникации могут включать один переход с очень высокой задержкой.
Anycast в основном используется для служб на основе UDP, таких как DNS. Запросы пользователей направляются в «лучший» и «ближайший» ЦОД на основе маршрутов BGP.
Пример: рабочая станция DNS-клиента с IP-адресом Anycast DNS 123.10.10.10, выполняет разрешение DNS для ближайшего из трех серверов имен DNS, развернутых с использованием того же IP-адреса Anycast. В случае сбоя маршрутизатора R1 или сервера A пакеты DNS-клиента будут автоматически перенаправлены на следующий ближайший DNS-сервер через маршрутизаторы R2 и R3. Кроме того, маршрут к нашему серверу A будет удален из таблиц маршрутизации, что предотвратит дальнейшее использование этого сервера имен.
Сценарии развертывания
Существуют две общие схемы, которые используются для определения того, к какому серверу подключается пользователь:
CDN на основе Anycast
Вернемся теперь к использованию Anycast в сетях доставки контента. Anycast, безусловно, представляет собой интересную сетевую концепцию и получает все большее признание у провайдеров CDN нового поколения.
CDN — распределенная сеть серверов, которые доставляют контент конечным пользователям с высокой доступностью и низкой задержкой. Сети доставки контента играют сегодня важную роль, будучи основой многочисленных мультимедийных онлайн-сервисов, а потребители все менее терпимы к медленным скоростям загрузки. Видео и голосовые приложения особенно чувствительны к джиттеру и задержке в сети.
CDN объединяет все серверы в одну сеть и обеспечивает более быструю загрузку контента. Иногда удается сократить время ожидания пользователя на 5-6 секунд. Целью CDN является оптимизация доставки путем предоставления контента с сервера, который находится ближе всего к конечному пользователю. Это очень похоже на Anycast, где выбирается ближайший сервер в зависимости от местоположения конечного пользователя. Казалось бы, каждый поставщик услуг CDN по умолчанию будет использовать Anycast, но в действительности это не так.
Приложения, использующие протоколы, такие как HTTP/TCP, полагаются на устанавливаемое соединение. Если будет выбран новый узел Anycast (например, при отказе сервера), то обслуживание может быть прервано. Именно поэтому Anycast ранее рекомендовался для таких служб без установления соединения как UDP и DNS. Тем не менее Anycast хорошо работает и для протоколов, ориентированных на соединение, например, TCP отлично функционирует в режиме Anycast.
Некоторые провайдеры CDN применяют маршрутизацию на основе Anycast, другие предпочитают маршрутизацию на основе DNS: ближайший сервер выбирается в зависимости от того, где расположен DNS-сервер пользователя.
Гибридные инфраструктуры и инфраструктуры с несколькими центрами обработки данных – еще один пример применения Anycast. Получаемый от провайдера адрес Load Balancing IP позволяет распределять нагрузку между IP-адресами разных сервисов клиентов в ЦОД провайдера. Благодаря технологии адресации любому устройству, это обеспечивает лучшую производительность при значительном трафике, отказоустойчивость и помогает оптимизировать время отклика при большом числе пользователей.
В гибридных инфраструктурах с несколькими центрами обработки данных можно распределить трафик между серверами или даже виртуальными машинами на выделенных серверах.
Таким образом, имеется огромный выбор технических решений для построения инфраструктуры. Можно также настроить балансирование нагрузки по IP-адресам в нескольких центрах обработки данных, используя адресацию любому устройству группы для оптимизации работы сайта.
Можно распространять трафик в соответствии с собственными правилами, определяя «вес» каждого из распределенных серверов в каждом ЦОД. Такая конфигурация особенно полезна, когда имеется распределённый серверный парк, а производительность сервисов неодинакова. Это позволит чаще распределять трафик для повышения производительности серверов.
Для создания системы контроля при помощи команды ping есть возможность конфигурировать зонды. Это позволяет администратору определить собственные процедуры контроля и получать более четкое представление о состоянии каждого компонента в инфраструктуре. Таким образом можно определять критерии доступности.
Существует возможность построения гибридной инфраструктуры: иногда удобно бэкофис оставить в корпоративной сети, а интерфейсную часть передать на аутсорсинг провайдеру.
Есть возможность добавить сертификаты SSL для балансирования нагрузки, шифрования передаваемых данных и безопасности связи между посетителями сайта и корпоративной инфраструктурой. В случае балансирования нагрузки между ЦОД также можно применять SSL.
Услугу Anycast с балансированием нагрузки адресов можно получить у провайдера. Эта функция поможет улучшить алгоритм взаимодействия пользователей с приложениями в зависимости от местоположения. Достаточно объявить, какие сервисы имеются в ЦОД, и трафик будет перенаправлен на ближайшую инфраструктуру. Если есть выделенные серверы, например, во Франции или в Северной Америке, то клиенты будут направлены на ближайший сервер в сети.
Один из вариантов использования Anycast – оптимальный выбор точки присутствия оператора (PoP). Приведем пример. LinkedIn (заблокированный в России) стремится не только улучшать производительность и скорость своих продуктов — мобильных и веб-приложений, но и совершенствовать сетевую инфраструктуру для ускоренной доставки контента. Для этого динамической доставки контента LinkedIn активно использует PoP – точки присутствия. Чтобы направить пользователей к ближайшему PoP, применяется Anycast.
Причина в том, что в случае Unycast каждая PoP LinkedIn имеет уникальный IP-адрес. Затем пользователи назначаются PoP в зависимости от их географического местоположения с помощью DNS. Проблема в том, что при использовании DNS около 30% пользователей в Соединенных Штатах перенаправлялись к неоптимальному PoP. Благодаря поэтапному внедрению Anycast неоптимальное назначение PoP упало с 31% до 10%.
Результаты пилотного теста показаны на графике, где ось Y — это процент оптимального назначения PoP. По мере «наращивания» Anycast во многих штатах США наблюдалось улучшение в процентах трафика к оптимальной PoP.
Мониторинг сети Anycast
Теоретически сети Anycast просты: нескольким физическим серверам назначается один и тот же IP-адрес, который BGP использует для определения маршрута. Но реализация и проектирование платформ Anycast сложны, особенно этим «славятся» отказоустойчивые сети Anycast. Еще более сложен эффективный мониторинг сети Anycast для быстрого выявления и локализации неисправностей.
Если сервисы используют для обслуживания своего контента стороннего провайдера CDN, им очень важно отслеживать и проверять производительность сети. При мониторинге CDN на основе Anycast основное внимание уделяется измерению сквозных задержек и характеристик предпоследнего перехода, чтобы понять, какой центр обработки данных обслуживает контент. Анализ заголовков HTTP-сервера — это еще один способ определить, откуда поступают данные.
Пример: заголовки ответа HTTP, указывающие расположение сервера CDN.
Например, CloudFlare использует собственный заголовок CF-Ray в сообщениях HTTP Response, который включает указание центра обработки данных, к которому поступил запрос. В случае Zendesk заголовок CF-Ray для региона Сиэтла представляет собой CF-RAY: 2a21675e65fd2a3d-SEA, а для Амстердама — CF-RAY: 2a216896b93a0c71-AMS. Чтобы определить, где находится контент, также можно использовать HTTP-X-заголовки из HTTP-ответа.
Другие методы адресации
| Unicast | Большая часть интернета сегодня использует именно этот метод. Unicast — одноадресная передача, IP-адрес связан только с одним конкретным узлом в сети. Это называют взаимно-однозначным соответствием. |
| Multicast | Multicast использует связь «один ко многим из многих» или «многие ко многим». Многоадресная рассылка позволяет отправлять запрос от отправителя одновременно на разные выбранные конечные точки. Это дает клиенту возможность загружать файл порциями с нескольких хостов одновременно (что полезно для потоковой передачи аудио или видео). Multicast часто путают с Anycast, Однако основное отличие состоит в том, что Anycast направляет отправителя к одному конкретному узлу, даже если доступны несколько узлов. |
| Broadcast | Датаграмма от единственного отправителя направляется на все конечные точки, связанные с широковещательным адресом. Сеть автоматически реплицирует дейтаграммы, чтобы иметь возможность связаться со всеми получателями в широковещательной рассылке (обычно в одной подсети). |
| Geocast | Geocast в некоторой степени похож на Multicast: запросы от отправителя направляются одновременно нескольким конечным точкам. Однако различие заключается в том, что адресат определяется его географическим положением. Это специализированная форма групповой адресации используется некоторыми протоколами маршрутизации для мобильных одноранговых сетей. |
Географический маршрутизатор (Geo Router) вычисляет свою зону обслуживания и аппроксимирует её. Геомаршрутизаторы, обмениваясь зонами обслуживания, строят таблицы маршрутизации. Система геомаршрутизаторов имеет иерархическую структуру.
Unicast, Multicast и Broadcast.
Использование технологии Anycast повышает уровень надежности, отказоустойчивости и безопасности DNS. Используя данную технологию, операторы предлагают своим клиентам услуги по различным видам балансирования нагрузки на основе DNS. В панели управления можно указывать IP-адреса, на которые будут отправляться запросы в зависимости от географической локализации. Это даст клиентам возможность более гибко распределять запросы пользователей.
Некоторые операторы применяют средства мониторинга маршрута на каждой точке присутствия (POP): система автоматически анализирует наиболее короткие местные и глобальные маршруты для точек присутствия и перенаправляет их через географические местонахождения с самой низкой задержкой с нулевым временем простоя.
На данный момент Anycast – наиболее стабильное и надежное решение для построения высоконагруженных DNS-сервисов, к которым предъявляются высокие требования по устойчивости и надежности.
Как построить CDN?
CDN — сеть серверов, ускоряющая доставку пользователям контента. Сеть доставки контента объединяет все серверы в одну сеть и обеспечивает более быструю загрузку контента. В скорости загрузки важную роль играет расстояние от сервера до пользователя.
CDN позволяет использовать серверы, которые находятся к целевой аудитории ближе всего. Это сокращает время ожидания, помогает ускорить загрузку контента сайтов для всех посетителей, что особенно критично для сайтов с файлами большого объема или мультимедиа-сервисов. Типичные области применения CDN — электронная коммерция и сфера развлечений.
Создаваемая в инфраструктуре CDN сеть дополнительных серверов, которые расположены максимально близко к пользователям, способствует более стабильной и быстрой доставке данных. Согласно статистике, использование CDN уменьшает задержку при доступе к сайту более чем на 70% по сравнению с сайтами без CDN.
Как создать CDN с помощью DNS? Настройка CDN с использованием собственного решения Anycast может быть достаточно дорогим проектом, но есть более дешевые варианты. Например, можно использовать GeoDNS и обычные серверы с уникальными IP-адресами. С помощью сервисов GeoDNS можно создать CDN с функциями геолокации, в которой решения принимаются на основе реального местоположения посетителя, а не местоположения ресолвера DNS. Можно настроить свою DNS-зону так, чтобы показывать IP-адреса американских серверов посетителям из США, а европейские посетители будут видеть IP-адрес из Европы.
С помощью GeoDNS можно возвращать разные ответы DNS в зависимости от IP-адреса пользователя. Для этого DNS-сервер настраивают так, чтобы он возвращал разные IP-адреса в зависимости от исходного IP-адреса в запросе. Обычно для определения региона, из которого делается запрос, используется база данных GeoIР. Геолокация с применением DNS позволяет отправлять пользователям контент с ближайшего сайта.
GeoDNS определяет IP-адрес клиента, пославшего запрос DNS, или IP рекурсивного DNS-сервера провайдера, который используется при обработке клиентского запроса. По IP клиента и базе GeoIP определяется страна/регион. Затем клиент получает IP-адрес ближайшего CDN-сервера. О настройке GeoDNS можно подробнее прочитать здесь.
Anycast или GeoDNS?
Хотя Anycast — отличный способ доставки контента в глобальном масштабе, ему не хватает специфичности. Вот тут на выручку и приходит GeoDNS. Этот сервис позволяет создавать правила, которые отправляют пользователей на уникальные конечные точки в зависимости от их местоположения.
Пример: пользователи из Европы направляются к другой конечной точке.
Также можно запретить доступ к доменам, отбросив все запросы. Это, в частности, быстрый способ отсечь злоумышленников.
GeoDNS дает более точные ответы, чем Anycast. Если в случае Anycast кратчайший маршрут определяется по числу хопов, то в GeoDNS маршрутизация для конечных пользователей происходит в зависимости от их физического местоположения. Это уменьшает задержку и повышает точность при создании гранулярных правил маршрутизации.
При переходе на домен браузер обращается к ближайшему серверу DNS, который, в зависимости от домена, выдает IP-адрес для загрузки сайта. Предположим, интернет-магазин пользуется популярностью в CША и в Европе, а DNS-серверы для него есть только в Европе. Тогда пользователи из США, которые хотят воспользоваться услугами магазина, будут вынуждены отправлять запрос к ближайшему серверу, а так как он находится очень далеко, ждать ответа придется долго — загрузка сайта будет не быстрой.
При размещении GeoDNS-сервера в США пользователи будут обращаться уже к нему. Ответ будет быстрым, что повлияет на скорость загрузки сайта.
В ситуации с существующим DNS-сервером в США при переходе к данному домену пользователя из США он обратится к ближайшему серверу, который выдаст нужный IP. Пользователь направится на сервер, который содержит контент сайта, но так как серверы с контентом находятся далеко, он его быстро не получит.
Если разместить в США и серверы CDN с кэшированными данные, то при загрузке браузер клиента отправит запрос к ближайшему DNS-серверу, который отправит обратно нужный IP-адрес. Браузер с полученным IP обращается к ближайшему серверу CDN и к основному серверу, и сервер CDN передает браузеру кэшированный контент. Пока подгружается кэшированный контент, с основного сервера поступают недостающие для загрузки полного сайта файлы. В результате уменьшается время загрузки сайта, так как файлов с основного сервера отправляется намного меньше.
Определение точного местоположения, определенного IP-адреса — не всегда легкая задача: тут действуют многие факторы, и владельцы диапазона IP-адресов могут принять решение объявить его на другом конце света (тогда придется подождать, пока база данных обновится, чтобы получить правильное местоположение). Подчас провайдеры VPS назначают адреса, которые предположительно находятся в США, для VPS в Сингапуре.
В отличие от использования адресов Anycast, распределение выполняется во время разрешения имен, а не во время подключения к серверу кэширования. Если рекурсивный сервер не поддерживает клиентские подсети EDNS, то используется местоположение этого рекурсивного сервера, а не пользователя, который будет подключаться к серверу кэширования.
Клиентские подсети в DNS — это расширение DNS (RFC7871), которое определяет, как рекурсивные DNS-серверы могут отправлять информацию о клиенте на DNS-сервер, в частности информацию о сети, которую сервер GeoDNS может использовать для более точного определения местоположения клиента.
Большинство используют DNS-серверы своего интернет-провайдера или DNS-серверы, которые географически близки к ним, но если кто-то в США по какой-то причине решит использовать DNS-ресолвер, расположенный в Австралии, он, скорее всего, получит IP-адрес сервера, ближайшего к Австралии.
Если вы хотите использовать GeoDNS, важно знать о таких особенностях, поскольку в некоторых случаях это может увеличить расстояние между серверами кэширования и клиентом.
Резюме: если вы хотите объединить несколько VPS в CDN, то лучший вариант развертывания – использование связки DNS-сервера с функцией GeoDNS + Anycast «из коробки».