Возможность

On-Prem GSLB

Разверните суверенное управление трафиком, работающее внутри собственного дата-центра — без необходимости во внешнем облаке для DNS- или GSLB-решений.

TR7 On-Prem GSLB объединяет авторитативный DNS и движок решений глобальной маршрутизации трафика на одной платформе. Содержимое зон, записи запросов, данные географического сопоставления и состояние работоспособности ЦОД — всё остаётся внутри собственной инфраструктуры организации, и GSLB-решения никогда не делегируются облаку внешнего провайдера. TR7 GTM предоставляет DC failover, географическую маршрутизацию, сценарии health-check, DNSSEC, AXFR/IXFR, динамические обновления записей и топологические правила в единой модели управления. Записи неработоспособных ЦОД могут автоматически выпадать из DNS-ответов; клиентская подсеть, страна, город, ASN или CIDR могут управлять дифференцированными ответами. Эта архитектура особенно важна для финансов, правительства, здравоохранения, телекомов и любых организаций с обязательствами по месту хранения данных. DNS — это не просто слой разрешения, а точка принятия решений о доступе к приложениям и непрерывности. Удержание этой точки on-premises усиливает операционный контроль. Итог: TR7 убирает зависимость SaaS DNS из GSLB; он превращает авторитативный DNS, DC failover, гео-маршрутизацию и сценарии health в локальный слой управления трафиком, работающий на собственных устройствах организации.

Типов DNS-записей поддерживается

Автоматических типов health-check на ЦОД

<3 с

Время регенерации динамической конфигурации

Если GSLB-решения принимаются в облаке, ваши данные зон и политика трафика уже покинули здание.

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

Аутсорсинг слоя принятия GSLB-решений также вводит риск операционной непрерывности. Сбой, инцидент конфигурации или проблема доступа API у внешнего провайдера напрямую влияет на политику DC failover и DNS-ответов организации. Ваши приложения могут работать, но трафик может не достичь правильного ЦОД.

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

Правильный подход — консолидировать авторитативный DNS, сценарии health-check, DC failover и решения топологической маршрутизации на одной локальной платформе. DNS-ответы должны регенерироваться на устройстве на основе реальной работоспособности ЦОД и политики трафика; данные запросов и содержимое зон должны оставаться под контролем организации.

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

Наш подход

TR7 строит архитектуру on-prem GSLB вокруг авторитативного DNS, модели принятия решений без облака, сценариев работоспособности и цепочки приоритетов нескольких ЦОД.

Авторитативный DNS и GSLB сходятся в одном движке решений

TR7 не разделяет управление зонами и GSLB-решения на отдельные системы. DNS-записи, работоспособность ЦОД, топологические правила и формирование ответов — всё работает в одной модели управления.

Данные зон, запросов и гео-решений остаются on-premises

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

Сценарии работоспособности автоматически формируют DNS-ответы

Когда ЦОД или запись становится неработоспособной, соответствующие IP могут автоматически выпадать из DNS-ответов. Нет необходимости в ручном скриптовом мосте между результатами health-check и DNS-ответами.

Цепочка приоритетов нескольких ЦОД управляет потоками failover и резерва

Каждая запись может нести несколько записей ЦОД и оценивать их в порядке приоритета. Основные, вторичные, третичные или DR-цепочки управляются в одной модели записи.

Возможности

On-Prem GSLB обеспечивает управление DNS-записями вместе с работоспособностью ЦОД, топологической маршрутизацией, DNSSEC и локальной статистикой.

Бэкенд авторитативного DNS обеспечивает локальное хранение записей и формирование ответов

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

35 типов DNS-записей дают широкое покрытие управления зонами

TR7 поддерживает широкий набор DNS-записей, включая A, AAAA, CNAME, MX, TXT, SOA, NS, SRV, PTR, CAA, записи, связанные с DNSSEC, и другие продвинутые типы. Это даёт гибкость, необходимую для полного управления зонами, а не только простой маршрутизации A-записей. Разные требования сервисов и безопасности могут быть приведены под одну модель управления DNS. Организация управляет своей DNS-архитектурой более согласованно из одной точки.

EDNS Client Subnet приближает географические решения к реальному клиенту

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

Топологические правила поддерживают решения по стране, городу, континенту, ASN и CIDR

Топологические правила TR7 могут выбирать DNS-ответы по измерениям сети/CIDR, страны, города, континента и ASN. Каждое правило может быть записано как положительное или отрицательное условие. Один и тот же домен может таким образом возвращать разные списки IP в разных географических или сетевых контекстах. Гео-маршрутизация становится точнее простого разделения по странам.

Цепочка приоритетов ЦОД управляет основным и резервным поведением на уровне записи

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

Режимы backupBehavior управляют риском пассивного ЦОД и устаревших данных

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

Рекурсивный форвардер управляет внутренним и внешним разрешением вместе

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

Поддержка DNSSEC укрепляет целостность и верифицируемость зоны

TR7 может предлагать управление подписанной зоной с поддержкой DNSSEC. Процессы NSEC/NSEC3, DNSSEC key cache и подписания зоны повышают верифицируемость DNS-ответов. DNSSEC можно включать или отключать на домен. Это укрепляет безопасность целостности критичных доменов.

Поддержка AXFR и IXFR поддерживает архитектуру primary-secondary DNS

TR7 может поддерживать поведение трансфера зоны как в роли primary, так и secondary DNS. AXFR и IXFR позволяют переносить записи между разными DNS-узлами. Это упрощает интеграцию с существующей корпоративной DNS-архитектурой. Развёртывание on-prem GSLB не требует полного отказа от существующей DNS-эксплуатации.

Режим обслуживания управляет плановым обслуживанием ЦОД на уровне DNS

Режим обслуживания можно применять на ЦОД. Во время планового обслуживания ЦОД может быть удалён из DNS-ответов даже если он работоспособен, и трафик направляется в другой ЦОД. По завершении обслуживания нормальный сценарий health-check возобновляется. Эта модель обеспечивает контролируемый переход без ручных изменений зоны.

Динамическое DNS-обновление поддерживает автоматизацию записей

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

Локальная статистика и счётчики записей удерживают видимость запросов on-premises

TR7 может собирать статистику вроде DNS-запросов, кеша, rcode, qtype, задержки, памяти и uptime. Счётчики запросов на запись показывают, какая запись получает сколько запросов. Эти данные доступны для локальной отчётности и планирования мощности без обращения к платформе внешнего провайдера. DNS становится измеримым слоем трафика, а не просто генератором ответов.

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

Эксплуатация on-prem GSLB покрывает разделение портов, поведение TTL кеша, threading, дефолты SOA, сбор статистики, сохранение файлов состояния и выбор master.

Разделение внутренних портов

Компоненты TR7 GTM могут использовать отдельные диапазоны портов для авторитативного DNS, API, forwarder inner и forwarder API процессов. Это разделение упрощает мониторинг и управление каждым сервисом независимо. Команды эксплуатации могут отслеживать состояние доступа и работоспособности каждого компонента индивидуально.

Поведение TTL кеша

Интервалы обновления кеша запросов, кеша отрицательных запросов, DNSSEC key cache и кеша зоны могут все выводиться из основного значения cacheTtl. Эта структура балансирует производительность со свежестью. Более короткие TTL дают более быстрое распространение изменений; более длинные снижают нагрузку запросов.

Конфигурация потоков

Процессы подписи, distributor, receiver и retrieval могут масштабироваться согласно числу ядер CPU. Этот подход увеличивает параллельную обрабатывающую мощность под тяжёлым DNS-трафиком. Настройки threading следует планировать на основе мощности оборудования и профиля запросов.

Дефолтное поведение SOA

Дефолтную структуру SOA для новых зон можно создать со значениями refresh, retry, expire и TTL. Эти значения определяют фундаментальное поведение времени DNS-эксплуатации. Значения SOA следует пересматривать отдельно согласно требованиям организации.

Конвейер сбора статистики

DNS-статистику можно читать через API и подавать в RRD или подобные структуры временных рядов. Отслеживаются метрики вроде qtype, rcode, cache hit/miss, UDP/TCP-запросов, задержки и использования памяти. Эти данные используются для планирования мощности и расследования инцидентов.

Сохранение состояния на диск

Информация о ЦОД, локальное состояние health-check, состояние сценария, динамическая конфигурация и динамическая конфигурация зоны могут храниться на уровне файла. После перезапуска GTM может восстановить прежний контекст оценки. Это снижает ненужные DNS-колебания во время переходящих перезапусков сервиса.

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

Цепочка непрерывности из трёх ЦОД в финансовом учреждении

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

Правительственная GSLB-эксплуатация без выхода данных

Правительственные организации могут эксплуатировать GTM без отправки содержимого зон, логов запросов или данных гео-решений во внешние DNS-сервисы. On-prem GSLB поддерживает суверенитет данных и ожидания аудита.

DNS-ответ системы здравоохранения, привязанный к работоспособности сервиса

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

Маршрутизация по нескольким ЦОД и гео в операторской среде

Телеком-команды могут выбирать разные ЦОД или PoP-локации, используя географические и сетевые топологические правила. Информация о клиентской подсети, стране, ASN или CIDR включается в решения о DNS-ответе.

Blue-green DNS-переход в электронной коммерции

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

Локальная непрерывность GTM в HA-кластере

Узлы GTM могут работать в ролях master и standby в HA-кластере. Если master-узел отказывает, standby принимает роль и поддерживает непрерывное формирование DNS-ответов.

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

В чём фундаментальная разница между on-prem GSLB и SaaS DNS?

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

Как неработоспособный ЦОД удаляется из DNS-ответов?

TR7 GTM интегрирует результаты сценариев health-check напрямую с формированием авторитативных DNS-ответов. Когда ЦОД становится неработоспособным, соответствующие IP автоматически выпадают из DNS-ответов — никакого ручного скрипта или runbook не нужно. Когда используется режим обслуживания, ЦОД может быть удалён из DNS-ответов, даже если он физически работоспособен.

Насколько гранулярными могут быть топологические правила?

Топологические правила TR7 могут выбирать DNS-ответы по измерениям сети/CIDR, страны, города, континента и ASN. Каждое правило может быть записано как положительное или отрицательное условие, и EDNS Client Subnet позволяет использовать реальную подсеть клиента. Один и тот же домен может таким образом возвращать разные списки IP в разных географических или сетевых контекстах.

Можно ли управлять конфигурацией DNSSEC на домен?

Да. Поддержку DNSSEC в TR7 можно включать или отключать на домен. Подписание зоны возможно с NSEC/NSEC3 и DNSSEC key cache; безопасность целостности можно укрепить для критичных доменов, не затрагивая другие.

Как достигается интеграция с существующей DNS-архитектурой?

TR7 может работать наряду с существующей primary-secondary DNS-архитектурой через поддержку трансфера зоны AXFR и IXFR. Процесс рекурсивного форвардера работает отдельно и может маршрутизировать конкретные домены в разные пути разрешения через domainBasedForwarding. Эта структура не требует полного отказа от существующей DNS-эксплуатации.

Где удерживается DNS-статистика и данные запросов?

TR7 собирает статистику запросов, кеша, rcode, qtype, задержки, памяти и uptime локально. Счётчики запросов на запись показывают, сколько запросов получает каждая запись. Эти данные не уходят на платформу внешнего провайдера и доступны для локальной отчётности и планирования мощности.

Приведите GSLB-решения в собственный дата-центр

Авторитативный DNS, DC failover, географическая маршрутизация и сценарии health-check — всё работает на собственных устройствах организации. Давайте пройдёмся по настройке, подходящей вашей инфраструктуре.