Когда GTM делает failover, об этом должна знать вся остальная организация.
В архитектуре GTM изменение состояния health-check может изменить DNS-ответ — но эксплуатация редко сводится только к DNS-ответу. Когда дата-центр уходит в офлайн, об этом нужно знать системе тревог, тикетов, автоматизации DR, конвейеру аудита и команде приложения. Без этой связи GTM принимает решение, а остальная операционная цепочка организации узнаёт об этом слишком поздно.
Решить это отдельным оркестрационным слоем возможно, но это значит новый сервис, новые учётные данные, новый мониторинг и новая точка отказа. Health-check уже работает внутри GTM; распространение изменений состояния во внешние системы должно управляться с той же платформы.
Со стороны форвардинга DNS проблема похожа. Некоторые домены принадлежат внутреннему DNS, некоторые — внешнему резолверу, некоторые — собственной авторитативной зоне TR7. Когда простой форвардер отправляет всё в один пункт назначения, split-DNS, внутренние зоны, партнёрские домены и поведения гео-маршрутизации сталкиваются.
Если информация ECS теряется, проблема углубляется. Гео- и топологические решения зависят от контекста сети клиента; если форвардер отбрасывает этот контекст, upstream-географическая маршрутизация может быть сделана по неправильному местоположению. Форвардер должен не просто переносить запрос — он должен сохранять и контекст решения.
TR7 GTM Triggers and Forwarders связывают изменения состояния health-check с цепочками действий HTTP/HTTPS или Oracle DB и делают DNS-форвардинг операционно управляемым через селективный форвардинг доменов, localhost zone forward и ECS pass-through.
Наш подход
TR7 проектирует GTM не просто как DNS-движок, отвечающий на запросы, а как активный операционный слой, реагирующий на состояние работоспособности и форвардящий DNS-запросы согласно контексту.
Изменение состояния health-check запускает цепочку триггеров
Когда базовое состояние HC-сценария меняется, могут выполняться действия turn или return. Когда сценарий активируется, triggerTurnActions выполняется по порядку; когда возвращается к норме, по порядку выполняется triggerReturnActions.
Триггеры HTTP и HTTPS могут валидировать содержимое ответа
HTTP/HTTPS-триггеры определяются методом, URI, заголовками, телом, ожидаемыми кодами статуса и таймаутом. Тело ответа может быть валидировано JSONata-выражением или базовой проверкой содержимого, чтобы определить, успешно ли действие.
Oracle DB-триггеры запускают сценарии базы данных
Oracle-триггеры работают со строкой подключения и массивом шагов сценария. Шаги wait и executeCmd могут запускать проверки или действия против базы данных; ожидаемые числа строк или ожидаемые текстовые значения могут быть верифицированы.
DNS-форвардер обеспечивает доменную маршрутизацию и сохранение ECS
Форвардер может отправлять конкретные домены в конкретные DNS-цели; для корневого домена может быть определена дефолтная цель. ECS pass-through сохраняет контекст подсети клиента, чтобы не нарушались решения гео-маршрутизации.
Возможности
GTM Triggers and Forwarders собирают действия health-check, HTTP/HTTPS и Oracle-валидацию, цепочечные потоки триггеров и селективный DNS-форвардинг в одной модели управления.
HTTP-триггеры настраиваются методом, URI, заголовками и телом
HTTP-триггер определяется адресом назначения, портом, методом запроса, URI, списком заголовков и телом запроса. Список ожидаемых кодов статуса определяет, успешен ли вызов. Таймаут ограничивает длинные внешние вызовы. HTTP-цели, такие как DR runbook, эндпоинты аудита или системы тревог, могут срабатывать через эту модель.
Действие триггера, которое делает больше, чем смена DNS
Триггер GTM не ограничивается перенаправлением имён. То же решение по состоянию здоровья, что переносит DNS, может выполнить и привязанное к нему действие — включая switchover Oracle Data Guard, — так что база данных следует за трафиком, а не ждёт второго решения от второй команды. То, что иначе стало бы конференц-звонком на тему «кто начинает первым», превращается в одно зафиксированное автоматическое действие: триггер, действие и его результат остаются в одном журнале аудита.
HTTPS-триггеры делают безопасные вызовы с контролем валидации сертификата
HTTPS-триггер применяет ту же модель запроса, что HTTP, поверх TLS. Флаг verifyCertificate определяет, валидируется ли целевой сертификат. В производстве рекомендуется держать валидацию сертификата включённой. Этот паттерн используется для доставки изменений GTM-сценария в защищённые внешние action-системы.
JSONata-проверка содержимого делает валидацию тела ответа гибкой
Ответы HTTP/HTTPS-триггеров могут парситься как JSON или XML и валидироваться JSONata-выражением. Контекст выражения включает body, bodyRaw, headers и status. Например, даже если внешняя система runbook возвращает 200, можно отдельно проверить поле success=true внутри тела ответа. Это даёт более надёжную валидацию триггера, не полагающуюся только на код статуса.
Базовая проверка содержимого даёт простую валидацию подстроки
Где JSONata не нужна, можно использовать базовую проверку содержимого. Тело ответа проверяется на наличие конкретной строки через семантику .includes(). Этого достаточно для маленьких интеграций, устаревших систем или эндпоинтов, возвращающих простой ответ работоспособности. Операторы могут быстро валидировать без написания сложного выражения.
Oracle DB-триггеры запускают подключения к базе данных и шаги сценария
Oracle-триггер подключается к базе данных с пользователем, паролем и строкой подключения. Шаги сценария могут включать операции wait и executeCmd. Ожидаемые числа строк или ожидаемые текстовые значения из executeCmd могут быть верифицированы. Эта модель используется для перекрёстной валидации состояния базы данных приложения или для выполнения контролируемых действий на стороне базы данных.
Цепочка триггеров запускает несколько действий последовательно
Массивы triggerTurnActions и triggerReturnActions выполняют несколько ID триггеров по порядку. Если одно действие отказывает, цепочка прерывается, и последующие действия не выполняются. Это предотвращает неконтролируемое продвижение зависимых шагов runbook. Потоки вроде «сначала запись в эндпоинт аудита, затем запуск DR-задачи» можно строить таким образом.
Направления turn и return обрабатывают переходы сценария отдельно
turn представляет момент активации сценария; return — момент деактивации и возврата к норме. Для каждого направления можно определить отдельный список триггеров и условие. Разные действия могут срабатывать во время failover и во время восстановления. Это разделение позволяет чище проектировать операционные потоки.
Очистка активных триггеров предотвращает коллизии старых процессов триггеров
При поступлении нового group key старые процессы триггеров могут быть остановлены. Жизненный цикл триггера отслеживается записями логов started, succeeded и failed; через короткую задержку событие activeTrigger очищается. Это поведение снижает вероятность коллизий старых действий с новым потоком при быстрых последовательных изменениях состояния. Основной сервис остаётся изолирован от fork триггера.
Выполнение триггеров ограничено master-узлом
В кластере триггеры выполняются только на master-узле. Другие узлы, видящие то же изменение состояния, не запускают внешнее действие повторно. Это предотвращает двойное срабатывание webhook или DB-действий. Поведение кластера становится более детерминированным.
PowerDNS Recursor форвардер работает как отдельный процесс на собственном порту
Слой форвардера позиционируется как отдельный recursor-процесс. Он принимает DNS-запросы на диапазоне forwarderInnerPort и форвардит их в определённые upstream-цели. Поведение авторитативного DNS и recursor-форвардинга развязаны. Это разделение позволяет TR7 управлять собственными зонами и внешним DNS-разрешением контролируемым образом в одной архитектуре.
Селективный форвардинг доменов определяет разные цели на домен
Список domainBasedForwarding позволяет направлять конкретные домены в конкретные DNS-адреса. Внутренние домены могут идти в корпоративный DNS; другие запросы могут идти в дефолтный upstream-резолвер. Этот дизайн важен для split-DNS и гибридных DNS-архитектур. Он выходит за рамки грубого форвардера, отправляющего каждый запрос в один пункт назначения.
ECS pass-through сохраняет клиентский контекст для гео-решений
Форвардер передаёт информацию ECS upstream-резолверам, чтобы они могли принимать решения с контекстом подсети клиента. Поведение ECS контролируется через настройки ecs-ipv4-bits, ecs-add-for и allow-list. Этот контекст критичен для гео-маршрутизации или топологических upstream-решений. Если ECS отброшен, географическая маршрутизация может быть сделана по неправильному местоположению резолвера.
Операционная глубина
Триггеры GTM и форвардер эксплуатируются вместе с поведением таймаута, отслеживанием жизненного цикла, изоляцией дочернего процесса, приоритетом парсинга, порядком forward-зон и метаданными.
Поведение таймаута триггера
Дефолтный таймаут HTTP-триггера может быть 120 секунд. Oracle-триггер может работать дольше в зависимости от собственного времени обработки. Общий процесс триггера может быть ограничен 24 часами — важный верхний предел для длинных runbook или многошаговых сценариев базы данных.
Поведение повторов
В цепочке триггеров нет автоматических повторов. Если триггер отказывает, цепочка прерывается, и последующие действия не выполняются. Целевые системы поэтому должны быть спроектированы идемпотентными и надёжными.
Логирование жизненного цикла триггера
Триггеры логируются с состояниями started, succeeded и failed. Эти записи показывают, какое действие выполнялось во время события failover или восстановления. Состояние активного триггера очищается через короткую задержку.
Выполнение в отдельном процессе
Выполнение триггера может работать как отдельный дочерний процесс. Эта модель предотвращает влияние длинных внешних вызовов или DB-операций на основной сервис GTM. Отказавший триггер не валит основной сервис.
Приоритет парсинга ответа
Тело HTTP-ответа сначала парсится как JSON, затем как XML — на основе типа контента. Если ни одно не удаётся, используется raw-строка как fallback. JSONata-выражение оценивается против этого контекста.
Порядок forward-зон
Строки forward-zones-recurse формируются в определённом порядке. Первое определение forward домена пишется как primary-строка; последующие определения пишутся как дополнительные строки. Этот порядок важен для чистого применения поведения селективного форвардинга.
Метаданные форвардера
Поле forwarder.metaData несёт дополнительные строки конфигурации recursor. Оно даёт точку расширения для пользовательских настроек кеша, политики или эксплуатации. Используемые строки метаданных должны быть тщательно валидированы.
Когда использовать
Webhook-тревога при отключении основного дата-центра
При активации сценария health-check срабатывает HTTP POST-триггер. Система тревог или управления инцидентами получает уведомление об отключении дата-центра. Решение о failover DNS становится видимым внешней операционной системе в тот же момент.
Автоматический запуск runbook при активации DR-сценария
При активации DR-сценария HTTPS-триггер может запустить задачу в платформе автоматизации. Первый триггер создаёт запись аудита; второй триггер запускает задачу подъёма DR. Если цепочка триггеров отказывает, следующий шаг не продвигается неконтролируемо.
Запись изменений health-check в эндпоинт аудита
При каждом событии turn и return HTTP-триггер может отправлять запись события в эндпоинт аудита. Информация о том, какая зона, какой сценарий и в какое время произошло изменение, отправляется во внешнюю систему логов. Решения GTM становятся аудируемыми.
Перекрёстная валидация состояния БД приложения через Oracle-триггер
Когда heartbeat приложения отказывает, Oracle-триггер может запустить независимую проверку БД. Если возвращается ожидаемое число строк или текстовое значение, событие перекрёстно валидируется. Это даёт более сильный сигнал решения без опоры только на результат HTTP health-check.
Форвардинг запросов внутренних доменов в корпоративный DNS
Домены вроде internal.example.com можно форвардить в корпоративные DNS-цели через domainBasedForwarding. Другие запросы идут в дефолтный upstream DNS. Собственные авторитативные зоны TR7 могут форвардиться в локальный DNS-процесс через localhost.
Использование селективного форвардера в split-horizon DNS-архитектуре
Внутренние клиенты могут разрешать внутренние домены приложений через корпоративный recursor, тогда как внешние клиенты получают авторитативные ответы TR7 GTM. Селективный форвардинг и ECS pass-through, используемые вместе, развязывают поведение внутреннего и внешнего разрешения. DNS-архитектура не заперта в форвардинге одного направления.
Часто задаваемые вопросы
Какие типы триггеров поддерживает GTM?
Что происходит при отказе одного действия в цепочке триггеров?
Какой узел запускает триггеры в кластере?
Как DNS-форвардер сохраняет информацию ECS?
Как настраивается селективный форвардинг доменов?
Как работает валидация ответа HTTP/HTTPS-триггера?
Подключите решения failover GTM к вашим внешним системам
Цепочки HTTP/HTTPS- и Oracle DB-триггеров, селективный DNS-форвардинг и ECS-осведомлённый recursor. Давайте пройдёмся по живой настройке в вашей собственной среде.