Возможность

Многоисточниковый выбор ЦОД

Выбирайте правильный ЦОД на каждый запрос, используя сигналы хоста, сервиса и клиента — а не только «достижим ли он».

Классический GSLB выбирает дата-центр, задавая один вопрос: достижим ли он? TR7 GTM задаёт три: как чувствует себя сам узел ЦОД, как ведёт себя работающее на нём приложение и каким на самом деле получается клиентский опыт обращения к нему? Каждый источник даёт отдельный набор сигналов. Источник хоста ЦОД даёт CPU, память, полосу и потерю пакетов, измеренные на уровне платформы. Источник сервиса даёт частоту запросов, число соединений, частоту новых сессий, CPU/память/полосу, привязанные к конкретному сервису приложения, плюс число работоспособных бэкендов за этим сервисом. Клиентский источник даёт число хопов, потерю пакетов, MOS (Mean Opinion Score для качества трафика VoIP-класса) и TTL — измеренные относительно запрашивающего резолвера или клиентской сети. Операторы выбирают один источник или комбинируют их. Критерии выбора конкретны («наибольшее число healthyBackends», «наименьшая потеря пакетов до клиента», «CPU ниже 70%»), а не вендорский жаргон. Может возвращаться несколько ЦОД (`pickDcCount`), так что взвешенное распределение по нескольким работоспособным регионам остаётся выразительным. Итог: решение GSLB, одновременно отражающее приложение, платформу и сетевой путь — ближе к реальному опыту пользователя, чем любая односигнальная модель.

3 источника

Хост, сервис, клиент — независимые входы сигналов

17 метрик

По трём источникам вместе

9 алгоритмов

Распределение записей после выбора ЦОД

На запись

Каждая DNS-запись выбирает свой источник и критерий

Односигнальный выбор ЦОД упускает действительно важный вопрос.

Большинство реализаций GSLB принимает решения о выборе дата-центра по одному классу сигналов. Географическое расстояние — один из распространённых вариантов; время туда-обратно от измерительных точек платформы — другой; статические топологические таблицы — третий. Каждый захватывает полезное измерение и упускает остальные.

География игнорирует нагрузку — ближайший дата-центр может оказаться тем самым, который сейчас под нагрузочным давлением. Задержка от зондов GSLB игнорирует пользователя — реальный сетевой путь пользователя не совпадает с тем, по которому шёл зонд. Статическая топология предполагает, что сеть не менялась с момента написания конфигурации.

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

TR7 GTM выставляет три класса сигналов — хост, сервис, клиент — как независимые входы для выбора ЦОД, позволяя операторам описывать политику, действительно подходящую под их нагрузку.

Наш подход

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

Источник хоста ЦОД — работоспособность на уровне платформы

Пять метрик, измеряемых на платформе ЦОД: CPU, память, полоса, status (составной up/down) и потеря пакетов. Полезно, когда нагрузка на платформу ЦОД — доминирующий сигнал для решений маршрутизации.

Источник сервиса — производительность приложения

Восемь метрик, измеряемых на сервис: CPU, память, полоса, частота запросов, число соединений, частота новых сессий, status и healthyBackends. Маршрутизирует трафик по тому, что приложение реально делает, а не по тому, работает ли хост.

Клиентский источник — сетевой путь до запрашивающего

Четыре метрики, измеряемые от сетевого пути до запрашивающего клиента: хопы, MOS (Mean Opinion Score), потеря пакетов и TTL. Захватывает пользовательский опыт, недоступный зондам со стороны ЦОД.

Выбор N с алгоритмом распределения

`pickDcCount` выбирает, сколько ЦОД вернуть. `balanceAlgorithm` распределяет по выборке — all, top-N, round-robin, weighted round-robin, random, weighted random или closest.

Возможности

Каждая DNS-запись в режиме ЦОД независимо выбирает источник сигналов, критерий и поведение распределения.

Хост ЦОД: пять метрик уровня платформы

Источник хоста ЦОД выставляет cpu, mem, bw, status и packetLoss. Status — это составное состояние достижимости/работоспособности, вычисляемое из точек доступа WAN и LAN ЦОД. Полезно, когда мощность на уровне хоста — доминирующий сигнал маршрутизации.

Сервис: восемь метрик уровня приложения

Источник сервиса выставляет cpu, mem, bw, request, connection, session_new, status и healthyBackends. Особенно важно число healthyBackends — оно направляет трафик в ЦОД, где у приложения сейчас больше всего работающей мощности, а не просто туда, где платформа в порядке.

Клиент: четыре измерения сетевого пути

Клиентский источник выставляет hops (длина пути), mos (Mean Opinion Score для качества VoIP/реального времени), packetLoss и ttl. Эти сигналы измеряются относительно клиентской сети, захватывая пользовательский опыт, недоступный зондам работоспособности на стороне ЦОД.

Статический выбор ЦОД для устаревших или простых случаев

Статический режим обходит многоисточниковый выбор и присваивает ЦОД на основе правил, заданных оператором. Полезно для устаревших DNS-записей, маршрутизации, продиктованной соответствием (конкретные ЦОД для конкретных клиентов), и для тестов.

Выражение критерия, определяемое оператором

Критерий выбора контролируется оператором: побеждает наименьшее значение, побеждает наибольшее значение, значение равно цели или значение отличается на запас. Один и тот же DSL управляет оценкой критериев по всем трём источникам сигналов.

Pick-N для ответов из нескольких ЦОД

`pickDcCount` по умолчанию равен 1, но может быть установлен выше, чтобы вернуть несколько ЦОД в DNS-ответе. Это обеспечивает настоящую балансировку по нескольким ЦОД, а не маршрутизацию «всегда один» — DNS-клиенты получают несколько ответов, а клиентский резолвер или стаб выбирает между ними.

Девять алгоритмов распределения записей

После выбора ЦОД записи внутри каждого ЦОД распределяются по `balanceAlgorithm`: all (вернуть каждую запись), top-1/2/3 (вернуть верхние N), round-robin, weighted round-robin, random, weighted random или closest (по близости к запрашивающему). Правильный алгоритм зависит от того, нужно ли широкое распределение, концентрация в top-N или стикинесс.

Маршрутизация по имени сервиса для ЦОД, специфичных для приложения

При использовании источника сервиса операторы указывают имя сервиса — разные приложения, работающие на одном и том же парке ЦОД, могут иметь разные правила маршрутизации. Число healthyBackends для сервиса A и сервиса B может управлять отдельным выбором ЦОД.

В сочетании с записями fail-safe

Если выбор не возвращает работоспособного ЦОД, список fail-safe записи предоставляет ответы последней инстанции — заданные оператором IP, которые всегда возвращаются при сбое всех многоисточниковых сигналов. Предотвращает NXDOMAIN как финальный ответ.

Выбор на запись — разные записи, разные источники

Выбор ЦОД настраивается на каждую DNS-запись. У одного и того же домена A-запись может маршрутизироваться по service.healthyBackends, MX-запись — по host.status, а CNAME — по client.packetLoss. Операторы настраивают каждую запись под её нагрузку.

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

Многоисточниковый выбор работает совместно с определениями ЦОД, сценариями health-check, алгоритмами взвешенного DNS и записями fail-safe.

Каденс сбора сигналов

У каждого источника сигналов своя каденция измерений. Метрики хоста и сервиса обновляются на цикле сбора метрик GTM (обычно каждые 30–60 секунд). Метрики клиента обновляются на сессию резолвера. Операторы настраивают каденцию на источник под топологию ЦОД.

Приоритет источников при конфликте критериев

Выбор использует один источник за раз на запись. Когда операторы хотят, чтобы сигналы хоста шлюзовали сигналы сервиса («рассматривать метрики сервиса только при работоспособном хосте»), они привязывают сценарий на основе хоста к записи с источником сервиса. Слоистость явная.

Источник истины healthyBackends

Число healthyBackends читается напрямую из уровня балансировки приложения на каждом ЦОД, а не аппроксимируется по внешним зондам. Число отражает фактический пул работоспособных бэкендов за сервисом в данный момент.

Вычисление MOS

MOS вычисляется из измерений качества сети (джиттер, потеря пакетов, задержка) относительно сети запрашивающего клиента. Наиболее точен для продолжающихся клиентских сессий и сходится за несколько окон измерений для первичных клиентов.

Pick-N при меньшем числе доступных ЦОД

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

Взаимодействие алгоритма с выбором

Выбор и алгоритмы распределения компонуются: выбор берёт годные ЦОД по критерию; распределение определяет, как возвращаются записи внутри каждого ЦОД. Запись может выбрать 3 ЦОД по service.healthyBackends, а затем вернуть записи внутри каждого ЦОД через weighted random.

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

Маршрутизация по мощности приложения, а не только по достижимости ЦОД

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

Маршрутизация по сетевому опыту клиента

Клиентский источник с критерием packetLoss направляет каждого пользователя в ЦОД с самым чистым сетевым путём из его сети. Полезно для VoIP, видео, игр и приложений реального времени, где качество пути важнее географической близости.

Балансировка нагрузки по нескольким работоспособным ЦОД

Сочетайте pick-N (например, вернуть top 3 ЦОД) с weighted random для распределения трафика по нескольким работоспособным регионам. Каждый DNS-клиент получает несколько вариантов; резолверы и стабы естественно распределяют между ними.

Слоистый выбор для нагрузок с высокими ставками

Используйте сценарий на основе хоста как шлюз («ЦОД работоспособен на уровне платформы») и критерий на основе сервиса как селектор («у ЦОД наибольшее число healthyBackends среди шлюзованных»). Критические нагрузки получают двухслойный выбор без скриптинга.

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

Чем это отличается от топологических записей F5?

Топологические записи F5 отображают кортежи (регион клиента, регион сервера) на упорядоченные предпочтения ЦОД — статическая таблица топологии. Многоисточниковый выбор в TR7 динамичен: каждый выбор ЦОД учитывает живые метрики из одного из трёх источников. Эти подходы дополняют друг друга: статическая топология отвечает «кто предпочтителен?», а многоисточниковый выбор отвечает «кто из предпочтительного набора действительно сейчас работает?».

Можно ли комбинировать сигналы из нескольких источников?

Выбор использует один источник за раз на запись. Чтобы слоить сигналы (например, «маршрутизировать только в ЦОД, работоспособные на уровне хоста, затем выбирать по метрикам сервиса»), операторы используют сценарий на основе хоста как шлюз и настраивают выбор записи на использование источника сервиса. Платформа компонует слоистую политику через конфигурацию, а не через синтаксис многоисточникового выражения.

Что происходит, если для ЦОД нет доступной метрики?

ЦОД с отсутствующими или устаревшими метриками считаются непригодными для сравнения по критерию. Они переходят к пути fail-safe. Операторы видят устаревание на дашборде — ЦОД, не дающий метрик, — это видимая операционная проблема, а не тихий сбой.

Как считается healthyBackends по сервисам?

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

Требует ли выбор по клиентскому источнику специальной клиентской инфраструктуры?

Никакого специального клиентского агента не требуется. Метрики клиента измеряются относительно запрашивающего резолвера — того же пути, по которому DNS-ответ пройдёт обратно. Хопы, потеря пакетов и TTL выводятся из самого пути ответа. Вычисление MOS использует статистический анализ паттернов джиттера и потерь во времени.

Выбирайте дата-центр по сигналам, которые действительно важны.

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