はじめに
この記事は、Nutanix Advent Calendar 2016 12月8日の分として作成しました。本記事の内容はこの日付の情報に基づいています。
またこの記事はNutanixが提供するデータ保護機能 (リモートレプリケーション編)の続編となります。前回の記事 1 はNutanixのAsyncDRの機能を用いて、複数のNutanixクラスター間でストレージのスナップショットを取得し、それを対向のNutanixクラスターに転送する手法をご紹介いたしました。
今回の記事では、複数の拠点をまたいで仮想マシンを復旧・移行する手法をご紹介します。
Nutanixクラスターをまたぐ仮想マシンの復旧・移行の概要
AsyncDR機能を用いてDRサイト側に転送されたスナップショットデータを復元します。特徴的なのは、単にデータの復旧を行うだけではなく、DRサイト側のハイパーバイザー上に自動的に仮想マシンのインベントリの登録も行われる点です。それによりDRサイト側で復旧オペレーションを行うだけで、仮想マシンとして電源を入れて使用することができます。
また、2016年2月にリリースされたNutanixのAOS4.6からは異種ハイパーバイザー間でも復旧・マイグレーションが可能になりました。例えば、本番サイトはESXiハイパーバイザーを使用し、DRサイトではAHV(Acropolis HyperVisor: Nutanixが提供するKVMをベースとしたハイパーバイザー)を使用する構成も可能となります。
スナップショットを転送する際に自動的に仮想マシンの形式をそれぞれのハイパーバイザーの形式、例えばESXiの場合はVMDK形式やAHVの場合はQCOW2形式に変換するため、異種ハイパーバイザー間でもシームレスな移行が可能です。クロスハイパーバイザーでのDRについては、ブログ「インフラ屋とアプリ屋のあいだ: Nutanixのクロスハイパーバイザーを試してみるその① そもそもAHVとは」にまとめられておりますので、ぜひご一読ください。
復旧・移行のパターン
復旧・移行には以下の3つのパターンがあります。
- 計画的な移行(Planned Failover): 本番サイト、DRサイトともに稼働している状態で、仮想マシンを本番サイトからDRサイトに移行します
- 災害による移行(Disaster Failover): 本番サイトが被災して完全に停止した状態で、DRサイトから仮想マシンを復旧します
- DRサイトから本番サイトへのフェイルバック(Failback): 本番サイトが復旧したのちに。DRサイトの仮想マシンを本番サイトに移行します。操作としては計画的な移行と同一です
それぞれの移行方法で必要となるオペレーションと、実行した時にどのような処理が行われるかを図示します。
計画的な移行(Planned Migration)とフェイルバック:
災害による移行:
どちらも最小限の手動オペレーションで移行・復旧が行われます。
留意点
サイト間での移行・復旧は非常に便利で強力な機能ですが、幾つか留意すべき点があります。
- IPアドレスを変更することができない: スナップショットを使用した機能のため、移行元と移行先の仮想マシンは同一IPアドレス設定となります。IPアドレス変更の自動化などはできません
- 仮想マシンの起動は手動: 本機能では仮想マシンの自動起動は行われません。起動は管理者が手動で実施する必要があります
- vCenterにはインベントリが残る: ESXiを使用している場合、仮想マシンの登録解除や削除はvCenterを介さず、直接ESXiサーバに対してオペレーションを行います。このため、vCenterサーバー上には親なしの状態で仮想マシンのインベントリが残ってしまいます
- コールドマイグレーションになる： 移行手順の図の通り、この機能での移行は仮想マシンの再起動を伴うコールドマイグレーションとなります
終わりに
Nutanixの災害対策機能の移行・復旧の概要と2つのNutanixクラスターを使用した移行・復旧手順をご紹介しました。
繰り返しの引用となりますが、異種ハイパーバイザー間のDR機能については、ブログ「インフラ屋とアプリ屋のあいだ: Nutanixのクロスハイパーバイザーを試してみるその① そもそもAHVとは」のシリーズで詳細に解説されていますので、ぜひ合わせてご一読ください。
次回は計画的な移行と、災害による移行のそれぞれの操作をご紹介します。
-
約1年前の記事です。ごめんなさい ↩