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