バックアップだけでは不十分な理由
従来のバックアップだけに頼っていると、データセンター全体がダウンした際に「冷や汗をかく」ことになります。以前、ビンズン省の工業団地で停電が発生し、データセンターが12時間以上停止したのを目の当たりにしました。当時、バックアップは手元にあっても、200台の仮想マシン（VM）を手動でリカバリサイトに復旧させるのは不可能に近い作業でした。RTO（目標復旧時間）は24時間まで跳ね上がり、SLAで約束していた4時間を大幅に超過しました。この苦い経験から、私はすぐに VMware Site Recovery Manager (SRM) の導入を決めました。
現在、私は8台の ESXi ホストで構成される vSphere 7.0 U3 環境を管理しています。SRM は直接データをコピーするのではなく、復旧プロセスを指揮する「総司令官」のような役割を担います。夜通しで1台ずつ VM を起動したり、IP を修正したり、起動順序を確認したりする必要はありません。SRM を使えば、クリック一つでプロセス全体を自動化できます。
押さえておくべきコアコンセプト
設定で混乱しないよう、次の4つのコンポーネントを覚えておきましょう：
- 保護サイトとリカバリサイト (Protected & Recovery Site): 単純に、稼働中のメインサイトと、待機中のバックアップサイトのことです。
- vSphere Replication (VR): VM データを別サイトに転送する「右腕」です。ハイエンドな SAN を使用している場合は、アレイベースのレプリケーション（Array-Based Replication）も利用可能です。
- 保護グループ (Protection Groups): 関連する VM をグループ化します。例えば、会計ソフトのデータベースとアプリケーションサーバーはセットで移動させる必要があります。
- リカバリプラン (Recovery Plans): 詳細な「復旧シナリオ」です。どの VM を先に起動し、次にどれを起動するか、IP アドレスをどう変更するかを定義します。
実践的な導入手順
1. インフラの準備
両方の拠点に vCenter が必要です。API の互換性エラーなどの初歩的なミスを避けるため、SRM のバージョンは揃えておくのが鉄則です。8123 (VR トラフィック)、44046 (VR 管理)、636 (SRM 通信) などの重要なポートを事前に開放しておきましょう。ファイアウォールでこれらがブロックされていると、サイト間の接続は即座に失敗します。
2. インストールとペアリング
現在の SRM はアプライアンス形式 (Photon OS) なので、15分ほどで素早くインストールできます。完了後、「サイトペアリング（Site Pairing）」を行います。これは2つの vCenter 間で信頼関係を構築するステップです。
# PowerCLI を使用して SRM の接続状態を素早く確認
Connect-SrmServer -RemoteServer <リカバリサイトのvCenter_IP>
$srmApi = $global:SrmConnection.Extension
$srmApi.Runtime.ConnectionStatus3. インベントリマッピングの設定
ここが最もミスが発生しやすいステップです。マッピングにより SRM は「サイトAの VM が VLAN 10 を使っているなら、サイトBでは VLAN 110 に切り替える」といった動作を理解します。ネットワーク、フォルダ、リソース、ストレージポリシーの4項目を念入りに確認してください。マッピングが一つでもずれていると、リカバリサイトで起動した VM がネットワークから孤立したり、リソース不足になったりします。
4. 保護グループとリカバリプランの作成
データの同期が完了したら、VM を保護グループに追加します。ここでは優先度（Priority Groups）を設定するのが一般的です。データベースを最優先（優先度1）にし、最初に起動して準備が整うようにします。次にアプリケーション（優先度3）、最後に Web サーバー（優先度5）の順にします。これにより、一斉起動による「接続タイムアウト」エラーを防げます。
テスト（Testing） — 火事になってから消火栓を探さない
定期的にテストされない DR システムは、単なる「机上の空論」です。SRM の最大のメリットは テストリカバリ (Test Recovery) 機能です。リカバリサイトに隔離されたネットワーク環境（バブルネットワーク）を作成し、最新 babysitter のレプリカから VM をクローンして試運転を行います。本番サイトのシステムには一切影響を与えません。
私の会社では、四半期ごとにチーム全員でテストを実施しています。テストを行うことで、仮想ハードウェア ID の変更によるソフトウェアライセンスのロックや、内部 DNS の反映遅延などの問題が発覚することもありました。早期発見のおかげで、リカバリプランにスクリプトを追加し、本番の障害時にスムーズに動作するように改善できました。
安眠を勝ち取るための「血と汗の教訓」
多くのプロジェクトを経て、以下の3つの重要な注意点に辿り着きました：
- DNS が鍵: VM の IP が変われば、DNS も更新する必要があります。起動後のステップ（Post-power on steps）でダイナミック DNS を更新するスクリプトを組み込みましょう。
- レプリケーション帯域: 甘く見てはいけません。データの変更量（チャーンレート）が 100GB/日で、回線が 10Mbps しかなければ、RPO は数時間の遅延（ラグ）が発生します。
- vCenter ライセンス: SRM ライセンスの期限切れアラームを設定しておきましょう。ライセンスが切れると、全保護グループの保護機能が即座に切断されます。
まとめ
VMware SRM は、最初のマッピング設定で少し戸惑うかもしれません。しかし、一度使いこなせれば強力な「権限」を手に入れることになります。リスクの多い手動復旧を、正確で自動化されたシナリオへと変えてくれます。今 SRM に時間を投資することは、重大な障害が発生した際に IT チームの信頼を守るための最良の方法です。
