Arcserve UDP 8.1でNutanix AHVの仮想スタンバイをしてみる① ～AHV to AHV 編～

今回は語り多めです。

前回までの記事では、Arcserve UDP 8.1にて、Nutanix AHVのエージェントレスバックアップを色々と紹介しました。今回は、NutanixにおけるArcserve UDPの仮想スタンバイについて気になったところを色々試してみた結果を紹介します。

1. 今回の環境

今回使用している環境は以下の通りです。

メインクラスター: NX-1465-G5
リモートクラスター: NX-1465-G4
AOS: 6.5 LTS
AHV: 20201105.30398
UDP Console & RPS: Windows Server 2019
Backup Proxy: Windows Server 2016
モニタサーバ: Windows Server 2019
バックアップ対象VM: Windows Server 2019

※ Arcserve UDP 8.1 は現状 AOS 5.20までのサポートとなりますが、今回はAOS 6.5で検証しています。ご了承ください。

2. 仮想スタンバイについて

仮想スタンバイの紹介については、以下の記事が参考になりますので詳細は割愛します。

Arcserve UDP 7.0 で AHV 上の仮想マシンをバックアップ Vol.3

今回は前提条件や要件の中でも以下の2つが気になり、実際に検証してみました。

気になる要件その①

Nutanix AHV に VM 用の NGT がインストールされており、VM をインポートする前に再起動されていること。そうしない場合、仮想スタンバイエージェントレスタスクが展開に失敗し、エラーメッセージが表示されます。（日文）

Installed NGT for a VM on Nutanix AHV and restarted before importing the VM. Otherwise, Virtual Standby Agentless task fails to deploy and displays error message.（英文）

引用元：前提条件と考慮事項の確認
　　　　 Review the Prerequisites and Considerations

英文のほうを私なりに解読してみると「AHV上の仮想マシンのためにNGTがインストールされていること、そしてそのVMをインポートする前に再起動すること」となります。（aとかtheとかを解釈するとそうなる）

なので、文章をもう少し日本語っぽくすると「AHV上でVMを起動させるために（外部からインポートする対象の）VMにNTGを事前にインストールして再起動しておいてね」と考えられました。（多分勘違い）

ただ、NGTはそもそもNutanix以外の環境のVMにはインストールできないはずなので、やはり仮想スタンバイ起動先のAHV上のいづれかのVMにインストールするのかなと思います。

他の方のブログや記事などを参考にしていると、NGTのインストール先は仮想スタンバイの仲介となるモニタサーバのことを指しているようなのですが、どうも腑に落ちないところがありました。

気になる要件その②

仮想スタンバイでは、ホストベース仮想マシンノード、リモート復旧ポイントサーバからレプリケートされたノードから取得された復旧ポイントスナップショットの電源を自動的にオンにできません。仮想スタンバイタスクのソースは別のサイトにレプリケートされたものです。このようなノードの復旧ポイントスナップショットは手動で電源をオンにする必要があります。（日文）

Virtual standby cannot automatically power on recovery point snapshots taken from host-based virtual machine nodes, nodes replicated from a remote recovery point server, and the Source of the Virtual Standby task is the one replicated to a different Site. You have to manually power on recovery point snapshots for such nodes.（英文）

引用元: プランへの仮想スタンバイタスクの追加
　　　 Add a Virtual Standby Task to the Plan

これも日文英文含めて難解でして、とりあえず、ホストエージェントレスバックアップや別のサイトからレプリケーションされたリカバリポイントで仮想スタンバイしてもソースノードにエージェントがインストールされてないとか、ハートビート送れないとかの理由で自動起動ができないということなのかなと思いました。

3. 今回の検証について

今回紹介する検証は、AHVのエージェントレスバックアップで取得したリカバリポイントからは仮想スタンバイを自動起動できないのか？逆にエージェントベースバックアップならAHVでも自動起動できるのか？ということです。

また、AHV to AHVの場合NGTは必要か？（多分いらない）というのも含めて、色々試してみます。

以下8つのパターンでプランを作成し、それぞれの仮想スタンバイVMが作成された段階で、すべてのバックアップ元のソースVMを一斉に停止させて動きを観察してみます。

参考までに、パターン①の構成図はこんな感じです。

期待しているのは、以下の結果です。

エージェントレスバックアップは自動起動されない
⇒対象パターン①②⑤⑥
エージェントベースバックアップは自動起動される
⇒対象パターン③④⑦⑧
AHV to AHVの場合、NGTは不要
⇒パターン①が仮想スタンバイで手動起動できたらOK
⇒パターン③が仮想スタンバイで自動起動されたらOK

4. 検証内容

UDP Consoleでそれぞれプランを作成するのですが、エージェントベースでプランを作成する場合はスタンバイVMを自動起動するかのチェックボックスが表示されるのに対して、エージェントレスベースでは表示されません。（この時点で結果は見えてそうですが・・）

作成した8つのプランは以下の通りです。

バックアップジョブ実行がされてしばらくしたのち、仮想スタンバイの作成先リモートサイトのPrismを確認してみると、8つの仮想スタンバイVMが作成されていることが確認できます。

UDP Consoleでも、仮想スタンバイVMのソースとなる実行中のソースVMが確認できます。ステータスが緑色になっているのは、ソースVMが起動していることをモニタ側からのハートビートで確認できているということです。

準備が整ったので、メインサイトの8つのソースVMを一斉に停止させてみます。

こんな感じですべて停止しました。これでハートビートがタイムアウトとなったはず。

停止させてから、30秒くらいでリモートサイトのPrismを確認してみると、無事にエージェントバックアップの4つすべてのプランの仮想スタンバイVMは自動起動していることが確認できました。ホストベースエージェントレスは停止のままなので期待通りの結果です。

UDP Consoleでも、エージェントベースバックアップのソースVMに関しては、ハートビートタイムアウトとなり、仮想スタンバイの実行が表示されます。

「スタンバイVM 実行中」画面でも、仮想スタンバイが実行中のソースノードが確認できます。

ここまでで、エージェントバックアップの場合は、仮想スタンバイVMが自動起動することと、NTGは無くても大丈夫そうなことが分かりました。

5. Proxy サーバを停止させてみる

先ほどお見せした通り、ソースノードはすべて停止したにもかかわらず、ホストエージェントレスバックアップの4つのソースノードについてはモニタサーバ側からハートビートのタイムアウトを検知できておらず、ステータスが緑になっています。

これについては、モニタサーバはBackup Proxyをハートビート監視している、といった情報を耳にしたことがあり、モニタサーバはバックアップを処理しているエージェントにハートビートを送っていると仮定するならば、エージェントレスバックアップの場合はエージェントとなるProxyがハートビートの送り先になっているからなのかな、と推測しています。（正確なソースや公式ドキュメント情報ではないので、Arcserveの中の人に教えていただきたいところ笑）

そこで、試しに今回ホストエージェントレスバックアップで使用しているBackup Proxyを停止させてみました。