※この記事は「AOS 7.3 AHV10.3 Prism Central pc.7.3」時点の情報をもとに作成しています。その後の機能アップデートについてはメーカーの公開情報をご確認ください。
今回は、Nutanix「Disaster Recovery」で仮想マシンの自動フェイルオーバーをしてみます。
目次
1.今回の環境
AOS: 7.3
AHV: 10.3
Prism Central: pc.7.3
Wintness VM 7.3
▽今回の環境のイメージは以下の通りです。
Nutanix Disaster Recoveryでは、「AHV Metro Availability」という同期レプリケーションをもとにしたDR機能が提供されており、Witnessという監視用のサービスを使用することで、プライマリクラスターの障害時に、リカバリークラスターに自動でフェイルオーバーをすることが可能です。
AHV Metro Availability
https://portal.nutanix.com/page/documents/details?targetId=Disaster-Recovery-DRaaS-Guide-vpc_7_3:ecd-ecdr-metroavailability-pc-c.html
Witnessの構成は大きく分けて2つのパターンがあります。
- Prism Central上で動作するローカルWitnessサービス
- AHVやESXi上にデプロイできる外部Witness VM
違いについては、上記のリンクをご参照ください。
今回は、外部Witnessを別のESXi上にデプロイして、AHV Metroの対象となる2つのクラスターを監視する構成として環境を作成しました。
作成した環境にて、仮想マシンの自動フェイルオーバーを試してみます。
2. 同期レプリケーションスケジュールの作成
▽Disaster Recoveryの有効化やプロテクションポリシーによる同期レプリケーションの作成については、以前の記事をご参照ください。
今回は、以下の通り異なる2つのAHVクラスター間で同期（Synchronous）レプリケーションスケジュールにてプロテクションポリシーを作成しました。
3. Witness VMのデプロイ
今回は、ESXi上にNutanixからダウンロードしたOVAファイルでWitness VMをデプロイする方法を試してみます。
▽ESXi用のWitness VMはNutanixのサポートポータルからダウンロードできます。
https://portal.nutanix.com/page/downloads?product=witnessvm
▽ダウンロードしたOVAから、ESXi上に仮想マシンとしてデプロイします。詳細手順はBroadcom社のドキュメントをご確認ください。
▽デプロイした仮想マシンはこちらです。
なお、Witness VMデプロイ後は電源を投入し、コンソール画面やSSHでログインしてWitnessクラスターサービスを作成するコマンドを実行したり、DNSやNTPサーバを設定したりする必要があります。
▽実際の手順はリンク先をご参照ください。
Deploying Witness Service on ESXi through Web Console
https://portal.nutanix.com/page/documents/details?targetId=Disaster-Recovery-DRaaS-Guide-vpc_7_3:ecd-ecdr-configuration-wsvm-esxi-pc-t.html
Witness VMが利用可能になったら、対象のクラスターを管理するPrism CentralにWitness VMを登録します。今回は、プライマリもリカバリも同じPrism Central管理下にあるため、1つのPrism Centralに登録します。
▽Prism CentralのWitness Service画面にて、作成したWitness VMのIPアドレスを指定して登録します。
▽登録された外部Witness VMは以下の通りです。なお「PC-AZ01 Local」というのは、PCのローカルWitnessサービスの事で、この同じ画面で確認できます。
これで、このPCでは外部Witness VMが利用可能となりました。
4. 自動フェイルオーバーのリカバリプランを作成
▽リカバリプランの作成画面で、Cluster-02→Cluster-01へのフェイルオーバーを作成します。
下にスクロールします。
▽ここが重要なポイントです。フェイルオーバーの実行モードで「Automatic」を選択し、先ほど登録した外部Witnessを選択します。下の数字では、Witnessがプライマリクラスターの応答なしを検知してから何秒後に自動フェイルオーバーを実行するかを設定できます。今回は30秒にしました。
▽この後の手順は割愛しますが、今回は仮想マシン1台を追加してリカバリプランを作成しました。作成したリカバリプランは以下の通りです。
これで、準備は完了です。
5. 仮想マシンの自動フェイルオーバー
今回は、Windows Serverを1台用意して同期レプリケーションのプロテクションポリシーや自動フェイルオーバーのリカバリプランに追加しています。
▽以下の通り、対象の仮想マシンがプロテクションポリシーに追加され、同期レプリケーションとなる「Synced」のステータスが確認できます。
この仮想マシンは画面の通り「cluster-02」で起動し、「cluster-01」に同期レプリケーションされているので、今回は「cluster-02」で模擬的なホストダウンを発生させてみます。結果として仮想マシンが自動フェイルオーバーされるか確認します。
▽ホストダウン方法ですが、cluster-02のCVMで全ホストの強制シャットダウンコマンドを実行してみました。
nutanix@cvm]$ hostssh sudo shutdown -h now
これですべてのAHVが強制的にシャットダウンされ、Witnessからはクラスターダウン状態として認識されます。
▽cluster-01のPrism Central画面を監視してみると、設定した30秒を経過した後に「Automatic Failover triggered by Witness」というアラートが確認できます。
これにより、自動フェールオーバーが実行開始したことが分かります。
▽タスク画面でも、フェイルオーバーに関する処理が実行されているようです。
▽しばらくすると、cluster-01へ自動フェイルオーバーした仮想マシンが起動していることが確認できます。コンソールにもログインできました。
なお、画面にフェイルオーバー元のcluster-02で起動していた同じ名前の仮想マシンが見えておりますが、これは障害が発生して停止しているクラスターなので画面上は起動状態で見えるだけで動作しておらず、IPが重複するといったことは起こりません。
同じPrism Central配下のクラスター間のフェイルオーバーなのでこれは表示上の仕様かなと思います。異なるPrism Centralに登録されているクラスター間のフェイルオーバーであれば、このように表示されることはないです。
▽なお、障害クラスターを復旧させると、フェイルオーバー元のcluster-02の仮想マシンは自動で削除されます。フェイルオーバー先のcluster-01の仮想マシンのみ起動指定状態となります。
▽あとは、自動でリバースレプリケーションが開始されるので、フェイルバックしたい場合はプライマリクラスター側に「計画されたFailover」で移行処理すれば戻すことも可能です。
今回はここまで。
