Перейти к основному содержимому
Возможность

Взвешенный DNS

Распределяйте трафик процентно на DNS-слое — управляйте canary (выпуск новой версии сначала небольшому проценту пользователей), A/B-тестами, blue/green (параллельная работа старой и новой сред для одномоментного переключения) и drain (постепенный вывод цели) через веса на запись.

TR7 Weighted DNS не рассматривает DNS-записи как простые равнодолевые списки IP. Назначая отдельный вес каждой записи, он позволяет вам решать — на DNS-уровне — какая доля трафика идёт в какое назначение. С алгоритмами weighted round-robin и weighted random новый релиз, новый дата-центр, новую группу сервисов или тестовую среду можно ввести с низкой долей трафика. Увеличьте вес, чтобы сдвинуть трафик постепенно; если появляется проблема, снизьте вес или установите его в 0, чтобы удалить цель из DNS-ответов. Изменения весов входят в конвейер живой перезагрузки конфигурации. Новые DNS-запросы получают ответы, отражающие текущее распределение весов; ответы, уже закешированные клиентами, живут до истечения их TTL. По этой причине сценарии быстрого перехода выигрывают от низкого TTL. Итог: TR7 управляет вашим процентом трафика в терминах DNS — canary-релиз, blue/green-переключение, A/B-тестирование, drain для обслуживания и постепенная миграция дата-центра — всё без поднятия дополнительного балансирующего слоя.

6
Алгоритмов распределения: all, rr, wrr, random, wRandom, closest
3 с
Задержка живой перезагрузки с debounce
0
Значение веса — помещает цель в режим drain без удаления записи

Классический DNS round-robin распределяет трафик равномерно; современные развёртывания требуют процентного контроля.

Классический DNS round-robin распределяет IP-адреса под одной записью приблизительно равномерно. Эта модель может быть адекватной для простого разделения нагрузки, но она не даёт контроля, нужного для развёртывания новых релизов, A/B-тестирования, blue/green-переключений или миграций дата-центров. Команды эксплуатации обычно хотят отправить только 5% трафика в новое назначение и оставить остальное на существующей системе.

Без взвешивания на DNS-уровне разделение трафика должно решаться на уровне приложения или в отдельном слое разделения трафика. Это значит дополнительная архитектура, дополнительный мониторинг, дополнительное управление сертификатами и дополнительные точки отказа. Когда решение можно принять прямо в DNS-ответе, клиент направляется в правильное назначение с самого первого запроса.

Сценарии обслуживания и drain также грубы, когда обрабатываются удалением записей. Удаление IP из DNS-записи эффективно для новых запросов, но не решает потребность постепенно снижать долю трафика или контролируемо выводить цель из ротации. Также нужно учитывать поведение кеша клиента и промежуточных резолверов в окне TTL.

Правильная модель — назначить отдельный вес каждой DNS-записи и выбрать алгоритм под сценарий. Weighted round-robin подходит для сбалансированного упорядоченного распределения; weighted random даёт статистический процентный выбор. Вес 0 помещает цель в эффективный режим drain, удаляя её из новых DNS-ответов. TR7 Weighted DNS обеспечивает контролируемое распределение трафика на DNS-слое через веса на запись, weighted round-robin, weighted random, живую перезагрузку конфигурации и поведение drain при весе 0.

Наш подход

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

Weighted round-robin ротирует записи пропорционально их весам

Для каждой IP- или записи-члена определяется целочисленный вес. Алгоритм weighted round-robin использует эти веса для пропорционального распределения DNS-ответов по пулу.

Weighted random даёт статистический процентный выбор

Алгоритм weighted random выполняет пропорциональный по весу случайный выбор на каждом запросе. На больших объёмах запросов наблюдаемое распределение трафика сходится к заданным соотношениям весов.

Живое обновление вступает в силу на новых DNS-запросах без задержки

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

Вес 0 запускает поведение drain, удаляя цель из ответов

Когда вес записи установлен в 0, она удаляется из активного списка кандидатов. Это поведение обеспечивает контролируемый drain для обслуживания, отката или вывода дата-центра из эксплуатации.

Возможности

Weighted DNS управляет значениями веса на запись вместе с выбором алгоритма, живыми обновлениями, интеграцией с топологией и сценариями обслуживания.

Отдельный целочисленный вес назначается каждой DNS-записи

В TR7 каждый член записи может иметь собственное значение веса. Это значение определяет его относительную долю в распределении трафика — веса 5 и 2 нацеливают на соотношение примерно 5:2. Если предоставлено дробное число, оно округляется до целого перед использованием. Модель упрощает назначение большей доли целям с большей ёмкостью и меньшей — тестовым целям.

Weighted round-robin обеспечивает контролируемое сбалансированное распределение

Weighted round-robin выбирает записи в ротации согласно их соотношениям весов. Это предпочтительный выбор, когда ожидается сбалансированное распределение и приемлемо последовательное использование записей. Это практичный алгоритм для canary-релизов, постепенных развёртываний и распределения трафика, пропорционального ёмкости. Операторы перестраивают распределение просто изменением значений веса.

Weighted random выполняет статистически пропорциональный выбор трафика

Weighted random производит пропорциональный по весу случайный выбор на каждом DNS-запросе. На коротких временных окнах могут появляться небольшие отклонения; на больших объёмах запросов распределение сходится к заданным соотношениям. Хорошо подходит для A/B-тестирования и экспериментальной маршрутизации трафика. Новые цели с низким весом можно безопасно опробовать в том же пуле записей.

Изменения весов распространяются на новые запросы через живую перезагрузку

Когда значения весов меняются, конфигурация GTM входит в процесс живой перезагрузки. Механизм debounce коалесцирует быстрые последовательные изменения, снижая ненужные перерисовки; типичная задержка живой перезагрузки около 3 секунд. Новые DNS-запросы получают обновлённое распределение весов. Ранее закешированные ответы в кешах клиентов и резолверов остаются до истечения TTL.

Планирование TTL критично для быстрых переходов и откатов

Когда вес DNS меняется, система немедленно обновляет новые ответы; однако DNS-ответы, уже выданные, живут в промежуточных кешах до истечения TTL. Для сценариев canary, blue/green или быстрого отката TTL следует держать низким. Значения в диапазоне 5-60 секунд позволяют переходам вступать в силу быстрее. Более высокий TTL уместен в стабильные периоды эксплуатации.

Установка веса в 0 помещает запись в эффективный режим drain

Когда вес IP или члена записи достигает 0, эта цель удаляется из новых DNS-ответов. Это делает возможным drain записи для обслуживания без её удаления. Существующие закешированные ответы продолжают использовать старый ответ до истечения TTL; новые запросы больше не получают цель. Это контролируемый и обратимый метод для обслуживания, отката или вывода дата-центра из эксплуатации.

Веса на уровне дата-центра и IP могут оцениваться вместе

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

После совпадения по топологии вес применяется внутри выбранного бакета

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

Классические алгоритмы round-robin и random также доступны в той же модели

Записи, не требующие взвешенного распределения, могут использовать классический round-robin или random-выбор. Round-robin распределяет записи равномерно; random выбирает случайно. Этих алгоритмов достаточно для простых сценариев, и они управляются через ту же модель записи, так что переключение на взвешенные алгоритмы не требует структурных изменений. Операторы выбирают подходящее поведение распределения для каждой DNS-записи.

Алгоритм closest предлагает выбор по близости для записей A и AAAA

Алгоритм closest доступен для записей A и AAAA, требующих выбора по IP-близости. В отличие от взвешенного распределения, он сосредотачивается на выборе ближайшей или наиболее подходящей цели для клиента. Топология, closest и вес могут служить отдельными слоями принятия решений в глобальном управлении трафиком. Результат — DNS-ответ, осведомлённый о контексте, а не просто случайный.

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

Weighted DNS эксплуатируется вместе с форматом веса, выбором алгоритма, задержкой живой перезагрузки, влиянием TTL и поведением выбора записей.

01

Формат веса

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

02

Поведение рендеринга взвешенного алгоритма

Алгоритмы weighted round-robin и weighted random используют список записей вместе с картой весов. Для каждой записи генерируются индексированные значения веса. Эта структура оценивается функцией селектора во время формирования DNS-ответа.

03

Задержка живой перезагрузки

Изменения конфигурации проходят через процесс живой перезагрузки с debounce. Типичное значение debounce — 3 секунды; может применяться лимит максимального ожидания во время всплесков быстрых последовательных изменений. Это поведение снижает ненужные частые операции перерисовки.

04

Влияние TTL

Изменение веса вступает в силу на новых DNS-запросах. Клиенты или резолверы, уже получившие предыдущий ответ, продолжают использовать закешированную запись до истечения её TTL. По этой причине TTL такой же важный операционный параметр, как и вес, при планировании переходов.

05

Поведение drain

Вес 0 используется для удаления записи из активного списка кандидатов. Это делает возможным выполнение обслуживания или миграции без полного удаления записи. Чтобы восстановить запись, установите вес обратно в положительное значение.

06

Выбор первых N

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

Когда использовать

Дайте новому релизу небольшую долю трафика через canary-развёртывание

IP нового релиза получает низкий вес; текущий релиз получает высокий. Новая версия стартует примерно на 5% трафика; по мере того, как метрики выглядят здоровыми, вес поэтапно повышается. Если появляется проблема, новый релиз дренируется установкой веса в 0.

Контролируемая DNS-маршрутизация во время blue/green-переключения

Пока активна blue-среда, green-среда тестируется на низком весе. При переключении вес blue снижается до 0, и green становится единственной активной целью. Когда нужен откат, веса меняются обратно для возврата в предыдущую среду.

Пропорциональное распределение между двумя целями для A/B-тестирования

Две landing-страницы или два варианта сервиса определяются с отдельными IP-записями. Веса могут быть установлены 1:1 для равного теста или 9:1 для ограниченного эксперимента. На основе анализа результатов соотношение трафика корректируется на DNS-уровне.

Постепенный перенос трафика во время миграции дата-центра

Старый дата-центр стартует на высоком весе; новый дата-центр вводится на низком. Команда эксплуатации сдвигает трафик в новый центр через ступенчатое снижение вроде 100 → 80 → 50 → 20 → 0. Когда TTL держится низким, влияние каждого шага наблюдается быстрее.

Балансировка нагрузки, пропорциональная ёмкости

Бэкенды с большей ёмкостью получают больший вес; более ограниченные ресурсы — меньший. Распределение трафика становится пропорциональным ёмкости серверов. Операторы перестраивают распределение чисто обновлением значений веса.

Drain для обслуживания без прерывания сервиса

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

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

В чём разница между weighted round-robin и weighted random?
Weighted round-robin выбирает записи в последовательной ротации согласно их соотношениям весов; распределение следует сбалансированному детерминированному циклу. Weighted random выполняет статистически пропорциональный по весу случайный выбор на каждом запросе. На коротких временных окнах могут появляться небольшие отклонения; на больших объёмах распределение сходится к заданным соотношениям. Round-robin обычно предпочтительнее для canary и сценариев постепенного развёртывания; random подходит для A/B-тестирования и экспериментального распределения.
В чём разница между установкой веса в 0 и удалением записи?
Вес 0 удаляет запись из DNS-ответов, но сохраняет её в конфигурации. Чтобы восстановить её, просто установите вес в положительное значение, и запись снова станет активной. Удаление записи полностью убирает её из конфигурации. Для сценариев обслуживания, отката и миграции вес 0 предлагает более безопасный и полностью обратимый подход.
Когда изменение веса вступает в силу?
Изменение веса входит в конвейер живой перезагрузки GTM. Из-за механизма debounce типичная задержка примерно 3 секунды; может применяться лимит максимального ожидания во время всплесков быстрых изменений. Новые DNS-запросы получают обновлённое распределение веса. Однако ранее закешированные ответы живут до истечения TTL, поэтому сценарии быстрого перехода должны держать TTL низким.
Какое значение TTL рекомендуется для canary-релиза?
Для быстрых переходов и гибкости отката рекомендуется TTL в диапазоне 5-60 секунд. Низкий TTL означает, что влияние изменения веса наблюдается быстрее, так как кеши клиентов и резолверов обновляются за короткое время. Более высокий TTL можно использовать в стабильные периоды эксплуатации. TTL — такой же важный операционный параметр, как и вес.
Можно ли использовать топологическую маршрутизацию и вес вместе?
Да. Когда применяется гео- или топологический выбор, сначала идентифицируется подходящая группа кандидатов. Распределение веса затем работает внутри этого набора кандидатов. Например, европейские пользователи маршрутизируются в европейскую группу дата-центров, а IP внутри этой группы взвешиваются независимо. Топологическое решение и решение веса применяются последовательно без взаимных помех.
Можно ли ввести дробное число как значение веса?
Вес определяется как число; если предоставлено дробное, оно преобразуется в целое через математическое округление. Соотношения весов представляют относительные доли среди записей, а не абсолютные проценты. Например, веса 5 и 2 нацеливают на распределение примерно 5:2 — значимая величина — это относительное соотношение, а не точный процент.

Возьмите под контроль ваш процент трафика на DNS-уровне

Веса на запись и живая перезагрузка для canary-релизов, blue/green-переключений, A/B-тестов и миграций дата-центров. Давайте пройдёмся по живой настройке в вашей среде.