Возможность

DNS-маршрутизация по близости

Направляйте каждый DNS-запрос в географически ближайший центр обработки данных — маршрутизация по близости решается на ваших собственных устройствах.

TR7 GTM сокращает сетевой путь, который проходит пользователь, отвечая на каждый DNS-запрос центром обработки данных, географически ближайшим к запрашивающей стороне. Селектор ближайшего ранжирует записи-кандидаты по близости запрашивающей сети к каждому ЦОД и возвращает ближайший ответ, сокращая расстояние — а значит, и время кругового обхода — между пользователем и приложением. Близость определяется по офлайн-базам GeoIP, хранящимся на устройстве: данные по стране, городу и ASN сопоставляют запрашивающий IP с местоположением, и ближайший кандидат выбирается относительно этого местоположения. При поддержке EDNS Client Subnet решение может следовать за реальной подсетью пользователя, а не за адресом пересылающего резолвера, так что ближайший центр обработки данных выбирается для того места, где пользователь действительно находится. Поскольку поиск — это локальное решение по базе данных, контекст DNS-запроса не отправляется во внешний сервис геолокации — важное свойство для сред, чувствительных к резидентности данных и приватности. Маршрутизация по близости также сочетается с осведомлённостью о работоспособности: записи неработоспособных ЦОД исключаются из набора кандидатов до запуска решения о ближайшем, поэтому запрос никогда не направляется в недоступный центр обработки данных лишь потому, что он рядом. Результат: TR7 превращает уровень DNS в точку маршрутизации с низкой задержкой, удерживающую пользователей на кратчайшем жизнеспособном пути к работоспособному центру обработки данных — без развёртывания внешнего облака управления трафиком.

3 базы данных

Офлайн-источники GeoIP: страна, город, ASN

На запись

Близость задаётся для каждой DNS-записи, а не глобально

На устройстве

Нет внешнего обращения к геолокации в пути запроса

Пользователь, направленный в удалённый центр обработки данных, платит стоимость кругового обхода при каждом запросе.

Когда DNS выдаёт каждому пользователю один и тот же центр обработки данных независимо от его местоположения, пользователи, удалённые от этого ЦОД, несут более длинный сетевой путь при каждом отдельном запросе. Дополнительное расстояние проявляется как более высокое время кругового обхода, более медленное установление соединения и ухудшенный опыт, который никакая настройка backend в точке назначения не способна компенсировать.

Простая маршрутизация только по стране помогает, но она грубая. Пользователь может находиться в нужной стране, но при этом быть гораздо ближе к одному из двух внутристрановых центров обработки данных, чем к другому, а правило по национальной границе не способно их различить. Распределение, полностью игнорирующее близость — круговой перебор или случайный выбор по всем ЦОД — активно отправляет часть пользователей длинным путём.

Передача решения о близости внешнему сервису геолокации порождает собственные проблемы: контекст DNS-запроса покидает организацию, уровень принятия решений зависит от доступности третьей стороны, а обязательства по резидентности данных становятся трудновыполнимыми. Критическое решение о трафике не должно зависеть от внешнего API.

Существует и ловушка корректности. Близость к ближайшему центру обработки данных полезна лишь тогда, когда этот центр действительно работоспособен. Направление пользователя в ближайший ЦОД, пока тот отказывает, хуже, чем отправка его немного дальше — в работающий.

TR7 DNS-маршрутизация по близости решает именно это: она выбирает ближайший работоспособный центр обработки данных для каждой запрашивающей стороны, используя офлайн-данные о близости, удерживая путь коротким без утечки контекста запроса и без игнорирования работоспособности ЦОД.

Наш подход

TR7 реализует маршрутизацию по близости через селектор ближайшего, офлайн-данные GeoIP, осведомлённость о подсети клиента и наборы кандидатов, отфильтрованные по работоспособности.

Селектор ближайшего выбирает ближайшего кандидата для каждого запроса

Когда DNS-запись использует алгоритм балансировки «ближайший», GTM ранжирует ответы-кандидаты по близости запрашивающей стороны к каждому центру обработки данных и возвращает ближайший. Решение выполняется для каждого запроса, поэтому каждой запрашивающей стороне отвечает центр обработки данных, минимизирующий её сетевое расстояние.

Офлайн-базы GeoIP оставляют поиск на устройстве

Близость определяется по базам данных стран, городов и ASN, хранящимся локально на устройстве. Решение никогда не отправляет контекст DNS-запроса во внешний API геолокации — географическое разрешение остаётся внутри инфраструктуры организации.

EDNS Client Subnet следует за реальным пользователем, а не за резолвером

С EDNS Client Subnet решение о близости может основываться на реальной подсети пользователя вместо IP пересылающего резолвера. Это позволяет избежать направления пользователей на публичных резолверах в центр обработки данных, ближайший к резолверу, а не к ним самим.

Неработоспособные центры обработки данных покидают набор кандидатов первыми

Состояние проверки работоспособности фильтрует записи-кандидаты до запуска решения о близости. Отказывающий центр обработки данных удаляется из набора, поэтому ближайший ответ — это всегда ближайший работоспособный центр обработки данных; близость никогда не перекрывает доступность.

Возможности

DNS-маршрутизация по близости превращает близость в DNS-решение для каждого запроса, ограниченное областью каждой записи и принимаемое локально.

Выбор ближайшего для каждого запроса сокращает сетевой путь

Алгоритм балансировки «ближайший» оценивает каждую запись-кандидата относительно местоположения запрашивающей сети и возвращает ближайший центр обработки данных. Поскольку меньшее географическое расстояние обычно означает меньшее время кругового обхода, пользователи удерживаются на кратчайшем жизнеспособном пути к приложению без какой-либо индивидуальной настройки. Решение пересчитывается для каждого запроса, а не фиксируется на этапе конфигурации.

Близость определяется по данным страны, города и ASN вместе

GTM определяет местоположение запрашивающей стороны, используя офлайн-базы стран, городов и ASN. Данные на уровне города позволяют платформе различать два центра обработки данных в одной стране, а данные ASN уточняют решение по сети, через которую подключена запрашивающая сторона. Это точнее, чем маршрутизация по национальной границе, оставаясь при этом детерминированным локальным поиском.

EDNS Client Subnet повышает точность определения близости

Когда резолвер передаёт подсеть клиента, GTM основывает решение о близости на реальном сетевом местоположении пользователя, а не резолвера. Это особенно важно для клиентов, использующих удалённые публичные резолверы, где решение только по резолверу могло бы отправить пользователя в центр обработки данных рядом с резолвером, а не с пользователем. Ближайший ответ следует за тем, где пользователь действительно находится.

Фильтрация по работоспособности сохраняет честность близости

Записи-кандидаты фильтруются по работоспособности центра обработки данных до применения решения о ближайшем. Неработоспособный центр обработки данных не может быть ближайшим ответом, поэтому платформа никогда не жертвует доступностью ради близости. Когда близкий центр обработки данных восстанавливается, он автоматически возвращается в набор кандидатов при следующем решении.

Близость сочетается с правилами топологии

Селектор ближайшего может выступать селектором внутри набора правил топологии, так что оператор может сначала ограничить кандидатов по сети, стране, городу, континенту или ASN, а затем выбрать ближайший ответ среди совпадений. Это позволяет ограничениям соответствия требованиям или оператора связи и маршрутизации по близости работать в одном конвейере принятия решений.

Настраивается для каждой DNS-записи, а не глобально

Алгоритм балансировки задаётся для каждой DNS-записи. Один и тот же домен может отвечать одной записью по близости, а другой — иной стратегией, поэтому маршрутизация по близости применяется именно там, где она приносит пользу, а остальные записи сохраняют собственное поведение. Операторы настраивают маршрутизацию запись за записью.

Решение на устройстве без внешней зависимости

И поиск близости, и выбор записи выполняются на устройстве. В пути запроса нет внешнего API геолокации, что устраняет зависимость от доступности третьей стороны и удерживает контекст DNS-запроса внутри организации. Решение о близости продолжает работать даже при недоступности исходящего соединения с внешними сервисами.

Операционная глубина

Маршрутизация по близости эксплуатируется вместе с набором баз GeoIP, полем алгоритма балансировки, селекторами топологии, фильтрацией по работоспособности и живой перезагрузкой конфигурации.

Набор баз GeoIP

Решения о близости опираются на три офлайн-базы на устройстве: базу ASN, базу на уровне города и базу на уровне страны. Вместе они поддерживают определение близости с учётом страны, города и ASN. Поскольку данные локальны, решения во время выполнения не зависят от внешнего сервиса; процесс обновления баз планируется отдельно от живого пути принятия решений.

Поле алгоритма балансировки

Близость выбирается установкой алгоритма балансировки записи в значение «ближайший» — один из доступных алгоритмов балансировки DNS-записей наряду со всеми, первыми-N, круговым перебором, взвешенным круговым перебором, случайным и взвешенным случайным. Поле задаётся для каждой записи, и изменения применяются через конвейер конфигурации.

Композиция с селектором топологии

Внутри набора правил топологии «ближайший» может использоваться как селектор, применяемый к записям, совпадающим с правилом. Это позволяет близости работать после того, как географическое или сетевое ограничение уже сузило кандидатов, объединяя фильтрацию по политике с выбором ближайшего ответа в одной записи.

Кандидаты, отфильтрованные по работоспособности

Набор кандидатов, передаваемый решению о ближайшем, отражает текущую работоспособность центров обработки данных. Записи неработоспособных ЦОД исключаются до выбора, поэтому близость вычисляется только по центрам обработки данных, которые действительно могут обслуживать трафик. Эта фильтрация — часть конвейера принятия решений, а не отдельное ручное правило.

Живая перезагрузка конфигурации

Изменения алгоритмов записей и наборов кандидатов поступают в конвейер регенерации конфигурации и применяются без перезапуска сервиса. Новые запросы получают ответы, отражающие текущую конфигурацию; ответы, уже закэшированные клиентами, живут до истечения их TTL, поэтому меньшие TTL ускоряют вступление в силу изменений близости и работоспособности.

Близость против живых сетевых сигналов

Селектор ближайшего принимает решение по географической близости, которая служит косвенным показателем задержки, а не её живым измерением. Когда решение должно отражать реальный сетевой путь в реальном времени или нагрузку центра обработки данных, многоисточниковый выбор ЦОД предоставляет живые сигналы хоста, сервиса и пути клиента, дополняющие маршрутизацию по географической близости.

В каких сценариях используется

Направление глобальных пользователей в ближайший регион

Для сервисов с пользователями, распределёнными по регионам, селектор ближайшего отвечает на каждый запрос географически ближайшим центром обработки данных, сокращая сетевой путь и уменьшая время кругового обхода без индивидуальных правил.

Выбор между двумя центрами обработки данных в одной стране

Когда в стране размещено более одного центра обработки данных, близость на уровне города определяет, какой из них ближе к запрашивающей стороне — точнее, чем правило только по стране, которое считало бы оба равнозначными.

Маршрутизация по близости с резидентностью данных

Поскольку поиск геолокации выполняется по офлайн-базам на устройстве, организации с обязательствами по резидентности данных или приватности запросов получают маршрутизацию по близости без отправки контекста DNS-запроса внешнему провайдеру геолокации.

Близость внутри политики топологии

Сначала ограничьте кандидатов по стране, ASN или CIDR по соображениям соответствия требованиям или оператора связи, затем позвольте селектору ближайшего выбрать ближайший ответ среди разрешённых центров обработки данных — политика и близость в одной записи.

Часто задаваемые вопросы

Измеряет ли TR7 GTM живую задержку от резолвера до каждого центра обработки данных?

Нет. Селектор ближайшего принимает решение по географической близости, а не по активному измерению времени кругового обхода. Он сопоставляет запрашивающую сеть с местоположением по офлайн-данным GeoIP и выбирает ближайший центр обработки данных; географическое расстояние служит косвенным показателем задержки. Если вам нужны решения, основанные на живых сигналах сетевого пути или нагрузки, многоисточниковый выбор ЦОД предоставляет метрики хоста, сервиса и пути клиента, дополняющие маршрутизацию по близости.

Как определяется местоположение запрашивающей стороны?

По офлайн-базам стран, городов и ASN, хранящимся на устройстве. Запрашивающий IP — или, когда присутствует EDNS Client Subnet, реальная подсеть пользователя — сопоставляется с местоположением, и относительно него выбирается ближайший кандидат. Контекст DNS-запроса не отправляется во внешний сервис геолокации.

Зачем использовать EDNS Client Subnet с маршрутизацией по близости?

Без него решение о близости основывается на адресе пересылающего резолвера, который может быть далёк от пользователя, когда задействованы публичные резолверы. EDNS Client Subnet позволяет решению следовать за реальной подсетью пользователя, так что ближайший центр обработки данных выбирается для того места, где пользователь действительно находится, а не где располагается его резолвер.

Что не даёт направить запрос в ближайший центр обработки данных, пока он недоступен?

Состояние проверки работоспособности фильтрует записи-кандидаты до запуска решения о ближайшем. Неработоспособный центр обработки данных удаляется из набора кандидатов, поэтому ближайший ответ — это всегда ближайший работоспособный центр обработки данных. Когда центр обработки данных восстанавливается, он возвращается в набор кандидатов при следующем решении.

Можно ли сочетать маршрутизацию по близости с правилами по стране или ASN?

Да. Селектор ближайшего может использоваться как селектор внутри набора правил топологии, так что кандидаты сначала ограничиваются по сети, стране, городу, континенту или ASN, а затем среди совпадений выбирается ближайший ответ. Фильтрация по политике и маршрутизация по близости работают в одной записи.

Применяется ли маршрутизация по близости ко всей зоне или к каждой записи?

К каждой DNS-записи. Алгоритм балансировки — это настройка на уровне записи, поэтому одна запись может маршрутизировать по близости, а другая в том же домене — использовать иную стратегию. Это позволяет применять маршрутизацию по близости именно там, где она помогает.

Удерживайте каждого пользователя на кратчайшем пути к работоспособному центру обработки данных

DNS-маршрутизация по близости, решаемая на ваших собственных устройствах — офлайн-GeoIP, осведомлённость о подсети клиента и фильтрация по работоспособности. Проведём по ней на вашей собственной топологии.