Когда failover ЦОД управляется ручными изменениями DNS, RTO ограничен скоростью человека.
В традиционной модели DNS primary/backup сбой ЦОД обнаруживается, команда эксплуатации получает уведомление, обновляется запись зоны, сервис перезагружается, и клиенты ждут распространения нового DNS-ответа. В runbook эта цепочка выглядит простой; в реальном инциденте задержки на принятие решений, контроль доступа, согласование и выполнение значительно увеличивают RTO.
Во многих организациях проверка работоспособности и DNS работают как отдельные системы. Инструмент мониторинга видит, что ЦОД недоступен, но DNS-сервер продолжает отвечать теми же IP-адресами. Мостом между ними обычно служит скрипт, ручной runbook или отдельный слой автоматизации. Этот разрыв становится самым слабым звеном в момент failover.
Failback несёт равный риск. Если ЦОД быстро мигает, DNS-ответ может многократно переключаться — клиенты разбросаны по разным ЦОД, и трафик может вернуться до завершения синхронизации состояния. Простой логики «удалить при сбое, добавить при восстановлении» недостаточно.
Правильная модель оценивает работоспособность ЦОД через логику булевых сценариев, снижает риск дребезга порогами последовательных успехов/отказов и делает DNS-ответ естественным результатом этого решения. Та же модель должна покрывать ручной переход для планового обслуживания, отказоустойчивый ответ при неработоспособности всех ЦОД и DR-условия.
TR7 DC Failover реализует эту модель: автоматически обновляет DNS-ответ при изменении сценария работоспособности ЦОД и привязывает весь процесс failover к DNS TTL и заданным оператором параметрам работоспособности.
Наш подход
TR7 реализует решения о failover ЦОД через сценарии работоспособности, логику булевых условий, защиту от дребезга и механизм ручного перехода.
Сценарий работоспособности напрямую управляет DNS-ответом
При изменении состояния health-check для ЦОД соответствующий сценарий переоценивается. Если результат сценария меняется, связанные DNS-записи регенерируются, а неработоспособный ЦОД удаляется из ответа.
Булевые условия могут моделировать сложные решения о состоянии ЦОД
Группы условий объединяются логикой AND; группы объединяются логикой OR. Для каждой проверки можно определить и отрицательное условие, что позволяет создавать инверсные сценарии вида «активировать эту запись, когда эта проверка неуспешна».
Защита от зависшего состояния снижает осцилляцию failback
Пока ЦОД находится в переходном состоянии, можно сохранять предыдущий результат оценки. Это поведение помогает предотвратить кратковременные колебания up/down, постоянно меняющие DNS-ответ.
Режим обслуживания обеспечивает ручной переход при плановом простое
Во время планового обслуживания оператор может вывести ЦОД офлайн через режим обслуживания. Даже если ЦОД выглядит работоспособным, его можно исключить из DNS-ответа, направив трафик на другой ЦОД.
Возможности
DC Failover — это слой failover GTM, который автоматически управляет DNS-ответами по нескольким ЦОД на основе состояния работоспособности.
Цепочка приоритетов N ЦОД поддерживает основной, вторичный и третичный потоки
TR7 может оценивать записи ЦОД как цепочку приоритетов, упорядоченную позицией в массиве. Если основной ЦОД неработоспособен, его место занимает вторичный; если и вторичный неработоспособен, в дело вступает третичный — и более длинные цепочки также поддерживаются. Кодовая модель теоретически не ограничена двумя эндпоинтами. Эта структура упрощает проектирование многоступенчатой непрерывности в финансовых, государственных и крупных SaaS-средах.
Единственный GSLB, который переносит базу данных вместе с трафиком
Когда ЦОД не проходит свой сценарий доступности, TR7 не просто уводит от него DNS — триггерное действие выполняет переключение базы данных в рамках того же события. Switchover Oracle Data Guard запускается тем же решением о состоянии, которое перенаправило трафик, поэтому аварийное восстановление становится одним автоматическим шагом вместо двух команд на конференц-звонке, договаривающихся, кто идёт первым.
Route Health Injection — переключение объявляется сети, а не остаётся внутренним решением
Площадка, не прошедшая проверки, перестаёт анонсировать префикс службы, а уцелевшая продолжает: решение доходит до вышестоящих маршрутизаторов как обновление маршрутов за секунды. Именно так трафик действительно переносится, а не просто помечается перенесённым. Поскольку адрес анонсирует только исправная площадка, не возникает окна, когда на него претендуют обе, и нет чёрной дыры, пока истекает срок жизни DNS-записи. BFD сокращает обнаружение до заметно менее секунды.
Доступны пять автоматических типов health-check на ЦОД
TR7 может оценивать сигналы работоспособности на уровне ЦОД: wanAccess, lanAccess, access, internet и maintenanceMode. Достижимость WAN, достижимость LAN, общее состояние доступа, доступ в интернет и ручной режим обслуживания моделируются отдельно. ЦОД оценивается по нескольким измерениям доступа, а не только по результату одного ping. DNS-ответ отражает более реалистичную картину работоспособности ЦОД.
Пороги последовательных успехов и отказов снижают риск дребезга
requiredSuccess и requiredFailure определяют, сколько последовательных результатов нужно, чтобы ЦОД был объявлен работоспособным или нет. Эта модель предотвращает ненужные изменения DNS, вызванные переходящей потерей пакетов, кратковременными разрывами сети или мгновенными замедлениями сервиса. Операторы могут использовать более строгие пороги для критичных сервисов и более терпимые для шумных каналов. RTO планируется вместе с этими порогами и интервалом проверки.
Режимы backupBehavior управляют поведением пассивного ЦОД
Режим noResponse удерживает пассивный ЦОД в молчании при нормальных условиях. Режим onlyNew может предотвратить ответ устаревшими данными от ЦОД, который долго был недоступен. Это поведение гарантирует, что во время failover DNS-ответы формируют только ЦОД в правильном состоянии, а не просто достижимые. Это важный защитный слой в средах, где есть риск устаревших данных.
Режим DR условно активирует записи аварийного восстановления
Режим DR на уровне записи позволяет конкретным записям становиться активными только при выполнении DR-условия. Сценарий drCond или флаг drIfNoRecords запускает DR-запись, когда основные и вторичные цели исчерпаны. Эта модель удерживает удалённые IP-адреса аварийного восстановления вне нормальных DNS-ответов, держа их в резерве для критических ситуаций. DR-стратегия становится управляемой на уровне DNS.
Отказоустойчивый ответ FailSafe — последнее средство при неработоспособности всех ЦОД
Если ни один ЦОД не работоспособен, ответ может быть сформирован из массива fallbackRecords. Эти записи могут указывать на страницу обслуживания, статический аварийный эндпоинт или альтернативный сервис восстановления. Поведение FailSafe гарантирует, что DNS выдаст контролируемый последний ответ вместо ничего. Операторы определяют эти записи согласно кризисному плану организации.
Сохранение состояния обеспечивает преемственность оценки между перезапусками
TR7 может хранить локальные данные health-check и состояния сценариев на уровне файла. После перезапуска или перезагрузки сервиса восстанавливается прежнее состояние, и оценка не начинается с нуля. Этот подход снижает ненужную осцилляцию решений failover при переходящем перезапуске. Особенно полезно для поддержания согласованности во время операций обслуживания, перезапускающих сервис GTM.
Достижимость ЦОД проверяется через несколько целей WAN и LAN
Списки целей wanAccess и lanAccess можно определить для каждого ЦОД. Несколько целей доступа дают более точную картину внешней и внутренней достижимости ЦОД. Переходящая проблема с одной целью не обязательно помечает весь ЦОД как недоступный. Эта структура позволяет более комплексно моделировать работоспособность дата-центров.
Ручной переход обеспечивает контролируемый перенос трафика при плановом обслуживании
При активации maintenanceMode соответствующий ЦОД сознательно выводится офлайн. Это полезно во время патчей, окон обслуживания, миграций или контролируемых DR-тестов. Оператор может удалить ЦОД из DNS-ответа — даже когда он работоспособен — и перенаправить трафик на другой ЦОД. По завершении обслуживания режим отключается, и нормальная оценка возобновляется.
Перечисление статусов классифицирует сбои ЦОД более чётко
Состояние ЦОД может быть выражено как ok, noInternet, noAccess, noWan или noLan. Эта классификация показывает, какое измерение доступа проблематично, а не просто говорит «отказ». Команды эксплуатации могут быстрее различать проблемы интернет-выхода, достижимости WAN и достижимости LAN. Причина решения о failover становится более читаемой.
Регенерация DNS-конфигурации автоматически запускается при изменении состояния работоспособности
При изменении состояния health-check связанный сценарий может быть переоценен немедленно. Записи, привязанные к сценарию, входят в конвейер регенерации динамической конфигурации, и DNS-ответ обновляется. Это поведение снижает необходимость ручных правок зоны или внешних скриптов. Изменения группируются коротким debounce, чтобы избежать ненужной повторной регенерации.
Записи master DNS в HA-кластере выполняются одним узлом
В сценарии HA-кластера записи DNS-конфигурации контролируются через роль master. При сбое узла master резервный узел может принять роль после заданного периода безопасности. Эта модель помогает предотвратить одновременное формирование разных DNS-конфигураций двумя узлами. Поведение GTM остаётся согласованным с состоянием кластера.
Операционная глубина
Операция failover ЦОД планируется вместе с интервалом проверки, последовательными порогами, структурой ID HC, условиями сценария, конвейером регенерации и параметрами RTO.
Интервал проверки ЦОД
accessPeriod определяет, как часто запускаются health-check ЦОД. Настраивается в секундах или минутах. Короткий период даёт более быстрое обнаружение; длинный — более тихую оценку с меньшим шумом.
Required success/failure
requiredSuccess определяет, сколько последовательных успехов нужно, чтобы ЦОД считался работоспособным. requiredFailure — сколько последовательных отказов нужно, чтобы он считался неработоспособным. Эти два значения задают баланс между скоростью failover и защитой от дребезга.
Тип доступа к ЦОД
Списки wanAccess и lanAccess определяют цели доступа для ЦОД. Это позволяет оценить, доступен ли ЦОД не только извне, но и из внутренней сети. Различие особенно важно в сценариях межЦОД и гибридной маршрутизации.
Формат ID HC
Автоматические записи HC следуют формату `auto|
Структура условий сценария
Условия внутри группы объединяются логикой AND; группы объединяются логикой OR. Эта структура поддерживает широкий спектр моделей принятия решений, от простой проверки «основной отключён» до сложных многомерных сценариев работоспособности ЦОД. Операторы не ограничены результатом одной проверки.
Конвейер принятия решений о failover
При изменении состояния HC сценарий переоценивается, выявляются привязанные записи, и запускается регенерация динамической конфигурации. Конвейер работает с коротким debounce, чтобы быстрые последовательные изменения объединялись в одну регенерацию. DNS-ответ перерисовывается в соответствии с текущим состоянием работоспособности.
Зависимости параметров RTO
RTO зависит от accessPeriod, числа requiredFailure, длительности debounce регенерации и поведения TTL DNS-клиента. Вместо заявления одного фиксированного времени окно failover нужно планировать под требования сервиса. Критичные сервисы выигрывают от более короткого TTL и более частых проверок.
Когда использовать
Классическая пара ЦОД active/passive
DC1 определён как основной, DC2 — как пассивный резерв. При сбое сценария интернета или доступа для DC1 записи DC1 удаляются из DNS-ответа, и начинает отвечать DC2.
Цепочка трёх ЦОД с приоритетом в финансовом учреждении
Финансовые учреждения могут построить последовательную цепочку failover DC1 → DC2 → DC3. Каждый уровень оценивается собственным сценарием работоспособности, а неработоспособный ЦОД автоматически удаляется из DNS-ответа.
Плановое обслуживание с ручным переходом
В окне обслуживания DC1 переводится в режим обслуживания, а трафик направляется в DC2. После завершения обслуживания режим отключается, и нормальная оценка работоспособности возобновляется.
Активация удалённой площадки аварийного восстановления
Когда основной и вторичный ЦОД одновременно неработоспособны, могут активироваться записи в режиме DR. В этом сценарии удалённая DR-площадка остаётся пассивной в нормальных условиях и добавляется в DNS-ответ только при выполнении определённых условий.
Вторичный ЦОД с защитой от устаревших данных
Когда долго недоступный ЦОД возвращается в строй, не всегда желательно, чтобы он отвечал устаревшими данными. Поведение onlyNew удерживает устаревший ЦОД в пассиве, снижая риск публикации устаревших записей.
Гибридная маршрутизация geofence и failover
Сначала по стране или региону выбирается ближайший ЦОД, затем — если он становится неработоспособным — активируется резервный. Эта модель объединяет управление производительностью и решения о непрерывности в одной конфигурации GTM.
Часто задаваемые вопросы
Когда и как срабатывает решение о failover ЦОД?
Как работает защита от дребезга?
Сколько занимает RTO?
Чем режим DR отличается от обычного failover?
Теряется ли состояние failover при перезапуске сервиса GTM?
Как вывести ЦОД офлайн для планового обслуживания?
Сократите failover ЦОД до скорости DNS TTL
Сценарий работоспособности, DNS-ответ и ручной переход объединены в один конвейер принятия решений. Давайте пройдёмся по живой настройке с вашей собственной архитектурой ЦОД.