はじめに vExperts Advent Calendar 2025
この投稿は、vExperts Advent Calendar 2025 の 19日目です。
2025 の 2ndHalf にて vExpert 認定をいただきましたので参加させていただきました!
他の方の投稿もぜひご覧いただきたいと思います。
まえがき
この記事における Live Recovery は VMware Live Site Recovery (VLSR) を指します。
以前のバージョンでは、Site Recovery Manager と呼ばれ、災害対策（DR対策）の製品として活用されてきたものです。
VCF9がリリースされたため、VLSRもどのような動きになるのか確認するために環境を作成してみようと思います。
最低限必要な環境としては、vCenter (management, workload), それらを実行するESXi, Aria Ops, VMware Live Recovery (VLSR, VR 兼用) です。これを１セットとして、保護されるサイトと、災害時のリカバリ用に同様のセットが必要です。
保護したい仮想マシンを作る前に必要な環境の準備が大変手間ですが、HOL にちょうどいい環境が用意されていました。今回はこのHOLを使って災害時のリカバリを実行してみます。
vCenter 8.0 + VLSR 構成と同じような感覚でリカバリできます。
VMware Live Recovery – Disaster Recovery Use Case (HOL-2634-03-VCF-L)
ラボへのアクセス
ラボ環境のブラウザを起動してみると、サイトA(RegionA)とサイトB(RegionB)がすでに作成済みで、レプリケーション（仮想マシンのサイト間のデータ同期）も終わっている状況でスタートします。
vCenter はいつも通り。mgmt 用と workload 用のクラスタが見えています。
Live Site Recovery へのログイン
Live Site Recovery の操作画面にログインする認証はSSOなので、administrator@vsphere.local などでいけます。ラボではアカウントとパスワードも記録済みですぐにログインできます。
ログインすると、操作するサイトペアを選んで、VIEW DETAILS ボタンをクリックします。
今回は mgmt-a.site-a と、mgmt-b.site-b のペアを操作します。
ログイン下画面は vSphere 8.0 用と何も変わりません
Replications をみると、現在の保護サイト(SiteA)側で保護されている仮想マシンが見えます。
acct-app-01, acct-db-01, acct-web-01 と AP, DB, Web という基本セットが保護されているのがわかります。RPOは1時間となっているので、保護しているサイトが全停止するような自体に陥っても、１時間以内の状況に復元できることを意味しています。
保護グループ(Protection Groups)では、保護した仮想マシンの構成（vmdkやネットワークの配置先や接続先）を事前に構成しておくことができます。基本的には同名のポートグループを両サイトで用意しておき、同じポートグループに接続するように構成しますが、任意のポートグループに繋ぎ変えることもできます。
保護状態にあると、リカバリ先にあらかじめ同名の仮想マシンが作成され、同名の仮想マシンが誤って作成されないようになっています。この仮想マシンはプレースホルダ仮想マシン(Placeholder VM)と呼んでいます。
プレースホルダ仮想マシンは名前の重複を避ける目的のため、リカバリを行うまではディスクもネットワークもついていない抜け殻のような状態で配置されています。電源も入れられません。
「There is no network assigned to this virtual machine」という警告が表示されているところが特徴的。
リカバリプランの作成
リカバリプランでは、保護グループで保護された仮想マシンを実際にリカバリする際の設定を定義しておきます。リカバリ時の起動順序やIPアドレスを付け替えたい場合などもリカバリプラン単位でカスタマイズします。
早速作ってみます。「RP-acctvms」とacct の vm をリカバリするためのものだという感じで名前をつけるとわかりやすいです。SiteAからSiteBにリカバリするなどの方向も選んでおきます。
リカバリ対象にする保護グループを選びます。先程の Remote Acct PG を選択します。
リカバリプランは保護グループを扱うため、階層としては リカバリプラン > 保護グループ > 仮想マシンとなっています。
テストでリカバリプランを実行する際のネットワーク接続先を別途カスタマイズできます。
本番サイトのVMが実際に切り替わるのか本番サイトを止めずにテストできますが、リカバリサイトで本番のネットワークに接続してしまうと運用中はまずいという場合は、仮のネットワークに接続することで閉じた環境で動作テストできます。
全体のサマリで問題ないか確認
実際に出来上がったところ
リカバリプラン名のリンクを開き、「Recovery Steps」からリカバリのテストや実際のリカバリを行えます。
リカバリプランの実行
実際にリカバリして仮想マシンをリカバリサイトで起動してみます。
切り替え前に Ops で確認したところ。Site Bの web サーバはまだ停止中。
プランを実行すると戻せない（保護サイトの仮想マシン）ことに同意して続行します。
内容を全体的に確認して実行。
リカバリプランが順次実行されていきます。
パワーオンのフェーズ
Site B側の仮想マシンがパワーオン状態になっています。
実体化したのでネットワークやディスクも接続されています。
仮想マシンの起動は、仮のネットワークで起動 > IPの付け替え(必要なら) > 一旦停止 > 本番ネットワークで起動 > vmtools が起動するまで待つ というフェーズで進みます。
リカバリが完了したところ
Site B側でしっかり起動しています。
Site A側ではパワーオフ状態になっています。
リカバリプランの再保護
一度リカバリプランを実行してしまうと、保護が解除された状態になります。
Site A -> Site B を実行して Site B が現在のメインサイトです。
今度は Site B を保護サイトとして、Site A をリカバリサイトに設定します。
大掛かりな設定は必要なく、Reprotect(再保護)をリカバリプランから実行します。
無事に再保護が終わったところ
今度はSite A側のVMがプレースホルダ仮想マシンになり、ネットワークやディスクを持たない抜け殻になりました。
Ops 側でもパワーオンしている様子が見えます。
まとめ
このような感じでVCF9に置いても以前のバージョンと同様にリカバリプランの実行は可能になっています。Management Domain を跨ぐリカバリでも問題ありません。
ただ移動するだけなら Advanced Cross vCenter vMotion でいいじゃないかという話ですが、実際の災害時は保護サイト側が停止していて仮想マシンが操作できない、データストアのあるストレージにもアクセスできないという状況が起きますので、Live Recovery を使って保護しておくことで迅速にサービス復旧が行えます。
VCF9 環境でこのような動作を確認するためには構成に必要な作業が膨大ですが、HOLで手軽に手に入るので本当に便利ですね。
また、実際に触って気がついたのですが、このHOLは mgmt domain に vSAN OSA、workload domain に vSAN ESA と vSAN エンジニアにとっては喉から手が出るほど欲しい構成が作られています。おまけにレプリケーション用に vSAN DP、なぜか Site B には vSAN File Service まで用意されています。RAID５構成も試せるので、ぜひ Live Recovery 以外でも触ってみたいとおもいます。
コメント