従来のプライマリ/バックアップDNSモデルでは、データセンター障害が検出され、運用チームがアラートを受け取り、ゾーンレコードが更新され、サービスがリロードされ、クライアントは新しいDNS応答の伝搬を待ちます。この連鎖はランブック上では単純に見えますが、実際のインシデントでは意思決定、アクセス制御、承認、実行による遅延がRTOを大幅に引き伸ばします。
多くの組織では、ヘルスチェックとDNSは別々のシステムとして動作しています。監視ツールはDCが到達不能であることを認識しますが、DNSサーバーは同じIPアドレスで応答し続けます。両者の間の橋渡しは通常、スクリプト、手動ランブック、あるいは別の自動化レイヤーです。そのギャップがフェイルオーバーの瞬間における最も弱い環となります。
フェイルバックも同様のリスクを伴います。DCが短時間で繰り返しアップダウンすると、DNS応答が繰り返し切り替わり — クライアントは異なるデータセンターに分散され、状態同期が完了する前にトラフィックが戻る可能性があります。単純な「ダウンしたら削除、アップしたら再追加」のロジックでは不十分です。
正しいモデルは、ブールシナリオロジックでDCの健全性を評価し、連続成功/失敗閾値でフラッピングリスクを低減し、DNSレスポンスをその判断の自然な出力にすることです。同じモデルは、計画メンテナンスのための手動カットオーバー、すべてのDCが異常な場合のフェイルセーフ応答、およびDR条件もカバーしなければなりません。
TR7 DCフェイルオーバーはこのモデルを実現します: DCヘルスシナリオが変化したときにDNS応答を自動的に更新し、フェイルオーバープロセス全体をDNS TTLと運用者定義のヘルスパラメータに結びつけます。
TR7はヘルスシナリオ、ブール条件ロジック、フラッピング保護、手動カットオーバー機構を通じてDCフェイルオーバーの判断を実装します。
DCのヘルスチェック状態が変化すると、関連するシナリオが再評価されます。シナリオの結果が変わると関連するDNSレコードが再生成され、異常なDCは応答から削除されます。
条件グループはAND論理で結合し、グループはOR論理で結合します。各ヘルスチェックには否定条件も定義可能で、「このチェックが異常な場合にこのレコードを有効化する」といった逆シナリオが構築できます。
DCが遷移中の間、前回の評価結果を保持できます。この動作により、短期間のアップ/ダウン変動がDNS応答を継続的に変更することを防ぎます。
計画メンテナンス時に運用者はメンテナンスモードでDCをオフラインにできます。DCが健全に見えても、DNS応答から除外し、他のDCにトラフィックを向けられます。
DCフェイルオーバーは、ヘルス状態に基づいて複数のデータセンター間でDNS応答を自動的に管理するGTMフェイルオーバーレイヤーです。
TR7は配列位置で順序付けされた優先チェーンとしてDCレコードを評価できます。プライマリDCが異常な場合はセカンダリが引き継ぎ、セカンダリも異常になればターシャリが対応します — より長いチェーンも同様にサポートされます。コードモデルは理論的に2エンドポイントに限定されません。この構造は金融、政府、大規模SaaS環境における多段階継続性設計を簡素化します。
TR7はDCレベルでヘルスシグナルを評価できます: wanAccess、lanAccess、access、internet、maintenanceMode。WAN到達性、LAN到達性、一般アクセス状態、インターネットアクセス、手動メンテナンス状態が個別にモデル化されます。したがってDCは単一のPing結果ではなく、複数のアクセス次元で評価されます。DNS応答はDCヘルスのより現実的な姿を反映します。
requiredSuccessとrequiredFailureはDCがアップまたはダウンと宣言される前に必要な連続結果の数を決定します。このモデルは一時的なパケット損失、短期間のネットワーク中断、瞬間的なサービス低下による不要なDNS変更を防ぎます。運用者は重要なサービスにはより厳しい閾値、ノイズの多いリンクにはより寛容な閾値を使用できます。RTOはこれらの閾値とチェック間隔と共に計画されます。
noResponseモードは通常条件下でパッシブDCを沈黙させます。onlyNewモードは長期間ダウンしていたDCが復帰時に古いデータで応答することを防げます。この動作により、フェイルオーバー時に到達可能なDCではなく、正しい状態のDCのみがDNS応答を生成することが保証されます。古いデータのリスクが懸念される環境では重要な保護層となります。
レコードごとのDRモードにより、DR条件が満たされた場合にのみ特定のレコードが有効になります。drCondシナリオまたはdrIfNoRecordsフラグは、プライマリとセカンダリのターゲットが尽きたときにDRレコードをトリガーします。このモデルは、リモート災害復旧IPアドレスを通常のDNS応答から除外しつつ、重要な状況に備えて待機させます。DR戦略はDNSレベルで制御されます。
健全なDCがない場合、fallbackRecords配列から応答を生成できます。これらのレコードはメンテナンスページ、静的緊急エンドポイント、代替復旧サービスを指すことができます。フェイルセーフ動作により、DNSは何も返さないのではなく、制御された最終手段の応答を生成します。運用者は組織の危機計画に従ってこれらのレコードを定義します。
TR7はローカルなヘルスチェックおよびシナリオ状態データをファイルレベルで保存できます。再起動またはサービスリロード後、前の状態が復元され、評価はゼロから始まりません。このアプローチは一時的な再起動中のフェイルオーバー判断における不要な振動を低減します。GTMサービスを再起動するメンテナンス作業中の一貫性維持に特に役立ちます。
wanAccessとlanAccessのターゲットリストはDCごとに定義できます。複数のアクセスターゲットがDCの外部および内部到達性のより正確な姿を提供します。単一ターゲットの一時的な問題は、必ずしもDC全体をダウンとマークするわけではありません。この構造によりデータセンターヘルスのより包括的なモデリングが可能になります。
maintenanceModeがアクティブになると、関連DCは意識的にオフラインになります。これはパッチ適用、メンテナンス期間、移行、制御されたDRテスト中に有用です。運用者はDCが健全な場合でもDNS応答から削除し、トラフィックを他のDCにリダイレクトできます。メンテナンスが完了するとモードは無効化され、通常の評価が再開されます。
DC状態はok、noInternet、noAccess、noWan、noLanとして表現できます。この分類は単に「ダウン」と言うのではなく、どのアクセス次元が問題かを示します。運用チームはインターネット出口、WAN到達性、LAN到達性の問題をより迅速に区別できます。フェイルオーバー判断の理由がより読み取りやすくなります。
ヘルスチェック状態が変化すると、関連シナリオが即座に再評価されます。シナリオにバインドされたレコードは動的な構成再生成パイプラインに入り、DNS応答が更新されます。この動作は手動ゾーン編集や外部スクリプトの必要性を低減します。変化は短いデバウンスでグループ化され、不要な繰り返し再生成を防ぎます。
HAクラスタシナリオでは、DNS構成書き込みはマスターロールを通じて制御されます。マスターノードに障害が発生した場合、スタンバイノードは定義された安全期間後に役割を引き継げます。このモデルは2つのノードが同時に異なるDNS構成を生成することを防ぎます。GTMの動作はクラスタ状態と整合します。
DCフェイルオーバー操作は、チェック間隔、連続閾値、HC ID構造、シナリオ条件、再生成パイプライン、RTOパラメータと共に計画されます。
accessPeriodはDCヘルスチェックの実行頻度を定義します。秒または分で構成可能です。短い周期はより速い検出を提供し、長い周期はより静かでノイズの少ない評価を提供します。
requiredSuccessはDCがアップとみなされる前に必要な連続成功数を定義します。requiredFailureはDCがダウンとみなされる前に必要な連続失敗数を定義します。これら2つの値がフェイルオーバー速度とフラッピング保護のバランスを設定します。
wanAccessとlanAccessリストはDCのアクセスターゲットを定義します。これによりDCが外部からだけでなく内部ネットワークからも到達可能かを評価できます。この区別はDC間およびハイブリッドルーティングシナリオで特に重要です。
自動HCレコードは`auto|
グループ内の条件はAND論理で結合し、グループはOR論理で結合します。この構造により、単純なプライマリダウンチェックから複雑な多次元DCヘルスシナリオまで、幅広い判断モデルをサポートします。運用者は単一のチェック結果に限定されません。
HC状態が変化すると、シナリオが再評価され、バインドされたレコードが特定され、動的構成の再生成がトリガーされます。パイプラインは短いデバウンスで実行され、急速な連続変更は単一の再生成パスに統合されます。DNS応答は現在のヘルス状態に従って再生成されます。
RTOはaccessPeriod、requiredFailure回数、再生成デバウンス期間、クライアントDNS TTL動作に依存します。単一の固定時間を主張するのではなく、フェイルオーバーウィンドウはサービス要件に合わせて計画されるべきです。重要なサービスでは短いTTLとより頻繁なチェックが有効です。
DC1をプライマリ、DC2をパッシブスタンバイとして定義します。DC1のインターネットまたはアクセスシナリオが失敗すると、DC1レコードはDNS応答から削除され、DC2が応答を開始します。
金融機関はDC1 → DC2 → DC3の順次フェイルオーバーチェーンを構築できます。各層は独自のヘルスシナリオで評価され、異常なDCは自動的にDNS応答から削除されます。
メンテナンスウィンドウでDC1はメンテナンスモードに置かれ、トラフィックはDC2に向けられます。メンテナンスが完了するとメンテナンスモードは無効化され、通常のヘルス評価が再開されます。
プライマリとセカンダリDCの両方が異常な場合、DRモードレコードを有効化できます。このシナリオではリモート災害復旧サイトは通常条件下ではパッシブのままで、定義された条件を満たした場合にのみDNS応答に追加されます。
長期間ダウンしていたDCが復帰した場合、古いデータで応答することは望ましくない可能性があります。onlyNew動作は古いDCをパッシブに保ち、古いレコードを公開するリスクを低減します。
最寄りのDCが最初に国または地域で選択され、そのDCが異常になるとスタンバイDCが有効化されます。このモデルはパフォーマンスベースのステアリングと継続性判断を単一のGTM構成に組み合わせます。
ヘルスシナリオ、DNS応答、手動カットオーバーが単一の決定パイプラインに統合されています。ご自身のDCアーキテクチャでライブセットアップをご覧ください。