Возможность

Сценарии Health Check

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

TR7 Health Check Scenarios не оставляют решения GTM на уровне «дата-центр работает или нет?». Результаты health-check HTTP, HTTPS, Oracle и других объединяются с автоматическими проверками на каждый дата-центр и булевыми сценариями, чтобы отражать реальную работоспособность сервиса в каждом DNS-ответе. Для каждого дата-центра доступны автоматические проверки доступа WAN, доступа LAN, общего доступа, статуса интернета и режима обслуживания. Пользовательские HTTP/HTTPS-проверки содержимого, JSONata-валидации, Oracle-сценарии подключения и результаты health-check со стороны ADC могут все добавляться в одну и ту же структуру принятия решений. Движок сценариев поддерживает комбинации AND/OR и отрицательные условия. Например, запись может включаться в DNS-ответ только когда дата-центр достижим, приложение работоспособно, база данных отвечает, а режим обслуживания выключен. При изменении состояния нужно регенерировать только затронутые записи. Итог: в TR7 health-check — это не просто данные мониторинга, а живой слой решений, определяющий, какой IP вернёт DNS.

Автоматических health-check на дата-центр (WAN, LAN, доступ, интернет, режим обслуживания)

Типов health-check — TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS, Oracle

Дефолтный порог последовательных успехов/отказов — защита от дребезга

Дата-центр может выглядеть работоспособным, в то время как приложение, база данных или путь доступа — нет.

Самая распространённая ошибка GTM — управление работоспособностью дата-центра одним флагом up/down. В реальности дата-центр может быть достижим, пока приложение лежит; приложение может отвечать, пока база данных не работает; WAN-канал может быть открыт, пока доступ со стороны LAN отказал. Однофлаговая модель работоспособности не может уловить эти различия.

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

Сложные сценарии ещё труднее. Условия вроде «активировать DC1, если у него есть доступ в интернет и он не на обслуживании; иначе вернуть резервную запись, если работоспособность приложения DC2 или доступ DC3 положительны» обычно управляются через YAML-файлы, скрипты и ручные зависимости. Это превращает GTM-решение в операционный лабиринт, который трудно понять или аудировать.

Дребезг — реальный риск. Когда health-check кратковременно отказывает и DNS меняется немедленно, пользовательский трафик ненужно переносится в другой регион. Аналогично короткий успех может вернуть трафик до полного решения проблемы. Пороги последовательных успехов и отказов плюс логика сохранения состояния поэтому существенны.

Сценарии health-check TR7 объединяют дата-центр, приложение, базу данных, режим обслуживания и пользовательские проверки в один булевый слой принятия решений, привязывая DNS-ответы напрямую к реальной работоспособности сервиса.

Наш подход

TR7 оценивает GTM health-решения, объединяя автоматические проверки дата-центра, ручные проверки и логику сценария в единой модели.

Автоматические и ручные health-check объединяются в одном сценарии

Автоматические проверки на каждый дата-центр, пользовательские HTTP/HTTPS/Oracle-проверки и результаты health-check ADC могут все использоваться в одной структуре принятия решений. Это связывает работоспособность инфраструктуры и приложения в одно GTM-решение.

Булевые условия упрощают сложные решения

Сценарии строятся группами AND и OR. Добавление `!` к идентификатору health-check отрицает условие, так что состояния вроде режима обслуживания могут использоваться как отрицательные условия в том же решении.

При изменении состояния работоспособности переоцениваются только затронутые записи

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

Валидация содержимого проверяет уровень приложения, а не только доступность порта

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

Возможности

TR7 Health Check Scenarios покрывают ряд потребностей GTM — от простых проверок доступа до многослойных решений по приложению и дата-центру.

HTTP- и HTTPS-проверки валидируют коды статуса и содержимое ответа

TR7 поддерживает параметры вроде метода, URI, тела, заголовков, ожидаемых кодов статуса, верификации сертификата и таймаута для HTTP- и HTTPS-проверок. Проверка таким образом не просто измеряет, можно ли установить соединение — она также верифицирует, что приложение возвращает правильный ответ с правильного эндпоинта, приближая GTM-решение к реальному поведению приложения.

История сценария — какой шаг не прошёл и что вернулось в ответ

Сценарий — это цепочка шагов, поэтому «проверка не прошла» само по себе никогда не бывает полезным ответом. TR7 хранит переходы состояний каждого бэкенда вместе с шагом, который не прошёл, и байтами, которые проба действительно получила в тот момент, — падение во вторник в 03:40 можно прочитать, а не додумать. Цепочки send/expect с hex- и Base64-полезной нагрузкой означают, что порт, который отвечает, но больше не говорит на своём протоколе, сценарий не проходит, а записанный ответ показывает, почему именно.

JSONata-проверки содержимого осмысленно валидируют ответы API

Для health-эндпоинтов, возвращающих JSON, конкретные поля могут оцениваться через JSONata-выражение. Выражение вида `status = "ok"` подтверждает не только то, что приложение отвечает, но и то, что оно возвращает ожидаемое состояние работоспособности. Тело ответа парсится в подходящую структуру, а выражение оценивается против неё. Это даёт более надёжное измерение работоспособности для современных приложений на базе JSON API.

Простые проверки содержимого обеспечивают быстрое сопоставление строк

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

Oracle health-проверки добавляют уровень базы данных в сценарий

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

Пять автоматических health-check доступны для каждого дата-центра

TR7 может использовать проверки `wanAccess`, `lanAccess`, `access`, `internet` и `maintenanceMode` на каждый дата-центр. Эти проверки представляют разные состояния доступа и эксплуатации каждого дата-центра независимо. Состояния вроде режима обслуживания могут рассматриваться как отрицательные условия в сценарии, а не как положительные сигналы работоспособности, давая DNS-решениям более близкое соответствие операционной реальности.

Булевые сценарии поддерживают AND, OR и отрицательные условия

Сценарии строятся структурами групп условий; условия внутри группы следуют логике AND, тогда как межгрупповые отношения могут быть OR или AND. Добавление `!` к идентификатору health-check инвертирует условие, обеспечивая конструкции вида `dcAccess AND NOT maintenanceMode`. Сложные GTM-решения можно проектировать без написания скриптов.

Пороги последовательных успехов и отказов снижают риск дребезга

Значения `requiredSuccess` и `requiredFailure` могут настраиваться для health-check. Дефолтный подход считает последовательные успехи или отказы до принятия перехода состояния. Это предотвращает мгновенную потерю пакетов, краткие всплески задержки или переходящие колебания сервиса от мгновенного изменения DNS-ответа, делая поведение GTM более стабильным.

Локальное сохранение состояния health-check обеспечивает непрерывность после перезапусков

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

Одиннадцать типов health-check доступны для координации GTM и ADC

В экосистеме TR7 доступны health-check TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS и Oracle. Координация результатов health-check GTM и ADC позволяет DNS-решениям отражать истинное состояние сервисного уровня. Эта широкая поддержка типов делает возможным построение health-модели не только для веб-приложений, но и для многопротокольных корпоративных сервисов. Также доступны скрипто-подобные TCP send-receive сценарии для пользовательских требований проверок.

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

Чтобы сценарии health-check работали надёжно, формат идентификаторов, сохранение состояния, последовательность триггеров, контроль master-узла и распространение изменений должны управляться чётко.

Типы health-check

Движок сценариев может оценивать типы health-check, включая static, dcCheck, http, https и oracle. В сочетании с более широким семейством health-check GTM и ADC многопротокольные состояния сервисов могут быть приведены в структуру принятия решений — важно для сервисных архитектур, не ограниченных одним типом HTTP-проверки.

Автоматический формат идентификаторов

Автоматические health-check на каждый дата-центр идентифицируются форматом `auto||`. Например, статус интернета дата-центра представлен отдельным идентификатором автоматической проверки. Этот стандартный формат делает отношения сценария и записи более лёгкими для отслеживания.

Идентификаторы ручных health-check

Пользовательские health-check создаются с уникальными идентификаторами. На эти идентификаторы можно ссылаться прямо в условиях сценария, что значит, что одна и та же HTTP-, HTTPS- или Oracle-проверка может оцениваться в нескольких GTM-сценариях.

Поток триггеров

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

Дефолтные состояния сценариев

Встроенные сценарии вроде `ALWAYS` и `NEVER` доступны для формирования фиксированных решений. С `ALWAYS` запись всегда считается годной; с `NEVER` достигается отключённое поведение. Это полезно для тестирования, временного снятия или безусловной маршрутизации.

Контроль master-узла

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

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

DNS-решение на основе доступа WAN и LAN

Многоплощадочные организации могут не хотеть, чтобы дата-центр считался работающим на основе одного пути доступа. TR7 объединяет разные маршруты доступа в одно DNS-решение через сценарии вроде `wanAccess OR lanAccess`.

Отвечать только когда приложение и БД оба работоспособны

Для критичных бизнес-приложений достижимости дата-центра одной мало. TR7 использует сценарии вроде `dcAccess AND appHC AND dbHC`, чтобы включать соответствующий IP в DNS-ответ только когда и приложение, и база данных Oracle работоспособны.

Держать трафик в стороне, когда активен режим обслуживания

Команда эксплуатации может не хотеть, чтобы дата-центр принимал трафик во время обслуживания, даже если он технически достижим. TR7 может удалить площадку обслуживания из DNS-ответа через сценарий вроде `dcAccess AND NOT maintenanceMode`.

Маршрутизация GTM на основе работоспособности JSON API

Современные приложения могут публиковать своё состояние работоспособности через JSON-эндпоинт. TR7 привязывает DNS-ответы к реальной работоспособности приложения, комбинируя HTTPS health-check с JSONata-выражением вроде `status = "ok"`.

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

В чём разница между сценарием health-check и простой проверкой up/down?

Простая проверка up/down сообщает только, технически ли достижим дата-центр. Сценарий health-check объединяет валидацию содержимого HTTP/HTTPS, JSONata-выражения, проверки подключения Oracle и автоматические проверки на каждый дата-центр через логику AND/OR. DNS-ответ таким образом основан на реальной работоспособности сервиса, а не только на достижимости инфраструктуры.

Как мне отразить режим обслуживания в DNS-решении?

TR7 включает автоматическую проверку `maintenanceMode` для каждого дата-центра. Добавляя эту проверку в условие сценария как отрицательное (через суффикс `!`), дата-центр на обслуживании может быть исключён из DNS-ответов без изменения его технической достижимости.

Что можно сделать для предотвращения дребезга?

TR7 поддерживает параметры `requiredSuccess` и `requiredFailure` для health-check. Дефолтный порог — 3 последовательных успеха или отказа. Это предотвращает мгновенную потерю пакетов или переходящие колебания сервиса от мгновенного изменения DNS-ответа, делая поведение GTM более стабильным.

Как привязать работоспособность БД Oracle к GTM-решению?

Oracle health-check настраивается через последовательность сценария, включающую шаги установления соединения, ожидания и выполнения SQL-команды. Результаты оцениваются на основе ожидаемого числа строк или ожидаемого текста. Эту проверку можно включить в GTM-сценарий, чтобы DNS-ответ был обусловлен и достижимостью базы данных.

Можно ли использовать один и тот же health-check для нескольких DNS-записей?

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

Сбрасываются ли состояния health-check при перезапуске GTM?

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

Привяжите DNS-решения к реальной работоспособности сервисов

Объединяйте проверки HTTP, HTTPS, Oracle и дата-центров в булевые сценарии. Давайте пройдёмся по живой настройке в вашей собственной среде.