Vault DR プロモーション運用ガイド：フェイルオーバー手順と実務チェックリスト

本稿は Vault Enterprise の Disaster Recovery（DR）レプリケーション環境で、DR セカンダリをプライマリへ昇格（プロモーション）させる具体的な手順を、運用の現実と資格対策の出題傾向を踏まえて整理します。

コマンドは公式ドキュメント準拠の安定的なエンドポイントを用い、分断によるスプリットブレインを避けるための判断基準と、LB/DNS 切替の実務ポイントも併記します。

前提と用語：DR レプリケーションとプロモーションの位置づけ

Vault Enterprise にはパフォーマンスレプリケーションと DR レプリケーションがあり、DR は災害復旧のために待機系クラスターを保持し、障害時にセカンダリをプライマリへ昇格（プロモーション）させます。通常運用中は DR セカンダリは読み取りも受け付けない待機系で、切替時のみアクティブ化します。

DR プロモーションは API/CLI でセカンダリ側に対して明示的に実行します。切替の前後でクライアントの接続先（LB/DNS）を更新し、元プライマリをネットワーク的に隔離してから再参加させるのが安全策です。

• 対象は Vault Enterprise の DR レプリケーション（公式: sys/replication/dr/*）。
• プロモーション実行は DR セカンダリのリーダーノードで行う。
• 切替時は旧プライマリの隔離（LB から外す/FW で遮断）でスプリットブレインを回避。

DR トポロジ（切替前）

フェイルオーバー判断のための事前チェック

計画外フェイルオーバーでは、旧プライマリの部分的な復旧が最も危険です。DR プロモーション前に、DR 側の健全性と複製遅延、旧プライマリの到達性を必ず確認します。

確認は JSON 出力で自動化し、手動判断の属人性を排除します。

• DR セカンダリの状態確認: vault status（Sealed: false / HA Mode: standby or active-standby）, sys/replication/dr/status（mode: secondary, state: running など）
• DR セカンダリのリーダー確認: vault operator raft list-peers で leader/Voter を特定（Raft 使用時）
• 旧プライマリの遮断計画: LB 健康監視の停止/切替、FW/SG による一時遮断、メンテナンスフラグの周知
• レプリケーション遅延: sys/replication/dr/status の指標（例: healthy, last_index 等）を確認。遅延が大きい場合は RPO 受容可否を判断
• 運用権限: sys/replication/dr/secondary/promote への sudo 権限を持つトークンでログイン（必要最小限の権限ポリシーを用意）

DR プロモーション（フェイルオーバー）実行手順

以下は最小ダウンタイムで安全に切り替えるための標準フローです。LB/DNS の変更は事前に自動化しておくと復旧時間が安定します。

プロモーション操作は、DR セカンダリ・クラスターのリーダーノードで行います。

• 1. 旧プライマリのトラフィックを止める（LB から外す/ヘルスチェックを失敗させる/ネットワーク隔離）。
• 2. DR セカンダリの状態を最終確認（vault status, sys/replication/dr/status）。
• 3. DR セカンダリでプロモーションを実行（下記コード）。
• 4. モードが primary へ遷移し、HA が active になったことを確認。
• 5. LB/DNS の宛先を DR 側に切替。/sys/health で 200 を確認し、クライアントの再接続を監視。
• 6. 監査ログとメトリクス（auth 成功率、400/429/5xx）を観測。必要に応じてスロットリングやバックオフを案内。

Runbook（DR セカンダリでのプロモーション）

# 事前に VAULT_ADDR と VAULT_TOKEN を DR セカンダリのリーダーへ向けておく
set -euo pipefail

# 0) 旧プライマリを LB から外す（LB 側の自動化に委譲）
# ...（LB/DNS 自動化スクリプトを呼び出す）

# 1) DR セカンダリの健全性確認
vault status
vault operator raft list-peers || true   # Consul HA の場合は不要

# 2) DR ステータス確認（JSON で健全性を確認）
vault read -format=json sys/replication/dr/status | jq .

# 3) プロモーション実行（セカンダリでのみ有効）
vault write -f sys/replication/dr/secondary/promote

# 4) 反映待ちと再確認
sleep 3
vault read sys/replication/dr/status
vault status    # HA Mode: active / Cluster Mode: primary 等を確認

# 5) LB/DNS を DR 側へ切替（健康監視は /v1/sys/health を利用）
# 例: アクティブノードは 200、スタンバイは 429、シール時は 503 が既定（環境により調整可）

# 6) 主要パス動作確認（例: 認証、KV 読取、Transit サイン）
# vault login、vault kv get、vault write transit/sign 等のスモークテストを実行

切替後の検証とクライアント切替の実務ポイント

DR 側がプライマリ化した後は、クライアントの再接続とシークレット運用の連続性を確認します。特にトークン・リースの失効タイミングやバックグラウンド更新の動作に注意します。

ヘルスチェックは /sys/health を利用し、アクティブ 200、スタンバイ 429 の既定動作を前提とすると切替ロジックがシンプルになります。

• クライアント切替: LB/DNS の TTL を短めに、再解決までの時間を計測。
• 認証確認: 主要 Auth Method（OIDC、AppRole 等）でログインが成功するかを確認。
• シークレット確認: KV、Transit、Database 等の代表パスで読み書き/署名が機能するかをスモークテスト。
• 監査とメトリクス: audit デバイスのローテーション、メトリクス（Prometheus 等）が新プライマリを指すか確認。

旧プライマリの取り扱いとフォールバック（再参加）の考え方

旧プライマリが復帰した場合、直ちにネットワークへ戻すのは避け、まず隔離環境で状態を確認します。新プライマリ（DR 昇格側）を起点に、新たな DR セカンダリ・トークンを発行し、旧プライマリをセカンダリとして再登録するのが安全です。

再参加の具体的な操作手順や API パスはバージョン差異があるため、実環境のバージョンに対応する公式ドキュメントの手順に厳密に従ってください。データ分岐が疑われる場合は、スナップショット/再同期の計画を優先します。

• 旧プライマリはネットワーク隔離のまま起動し、誤ってクライアント流入しないことを確認。
• 新プライマリで DR セカンダリ登録用のトークンを発行（公式の secondary-token API を使用）。
• 旧プライマリにて DR プライマリ動作を停止し、発行トークンでセカンダリとして再有効化（バージョンに応じた API を使用）。
• 再同期完了と healthy を確認後にネットワークへ復帰。

試験で問われやすいポイントと運用の落とし穴

試験（運用系）では、エンドポイントの正誤や、どのノードで操作するか、スプリットブレイン対策などが頻出です。実運用でも同じ箇所でミスが生じます。

特に、DR プロモーションは DR セカンダリ側で実行する点、切替前に旧プライマリを確実に隔離する点は覚えておくと良いでしょう。

• 正しい API パス: sys/replication/dr/secondary/promote（セカンダリで実行）。
• 権限: 当該パスに対する sudo 権限が必要。root トークンや適切に絞った運用トークンを用意。
• ヘルスコード: /sys/health 既定で active=200, standby=429, sealed=503。
• LB 切替の順序: 旧系の切断 → DR 側プロモーション → DR 側を LB に組み入れ。
• 監査ログの連続性: 監査デバイスの出力先（S3, syslog 等）が DR 側でも到達可能か事前検証。

問題で確認

よくある質問