この項では具体的に仮想マシンのレプリケーションを行う設定とリストアの手順を確認したいと思います。
まず、メインサイトのESXiで稼働している仮想マシンをDRサイトにレプリケーションする設定を行います。
PRISMのメニューから「Data Protection」選択し、右上の「Protection Domain」ボタンから、「Async DR」をクリックします。
バックアップ管理名称(ジョブ名)を入力し、Createボタンをクリックします。
今回は「Backup01」という名前で作成を行います。
左側の一覧からあがってくる仮想マシンを選択し、「Protect Selected Entities」をクリックし、右側のProtected Entitesの一覧に仮想マシン名が登録されていることを確認します。
続いて、レプリケーションのスケジュールを作成します。
右上の「New Schedule」をクリックします。
スケジュールは非常に柔軟に設定ができます。
数時間に1回という単位でのバックアップや数日に一回、毎週何曜日などの設定が可能です。
また、レプリケーション設定はまずローカルスナップショットデーターの転送となりますので、ローカル側のスナップショットの取得が必須となります。
ローカルとレプリケーション先で保持する世代数を変更するが可能ですので、要件に応じて世代数を設定しましょう。今回はローカルに5世代、レプリケーション先に3世代のスナップショットデーターのバックアップを保持する設定にしています。
スケジュール設定を行った後「Create Schedule」をクリックします。
設定したスケジュール情報が出ていることを確認し、「Close」をクリックします。
あとは、スケジュールで設定した時間まで待つばかりです。
待てない場合は、意図的にスナップショットを作成したいと思います。
作成したバックアップジョブを選択し、「Take Snapshot」をクリックします。
今回は取得したスナップショットをレプリケーション先に送りますので、"REMOTE SITE"の下に表示されるレプリケーション先(今回は、toDELL)を選択し、SAVEをクリックします。
スナップショットの作成が終わったら、いよいよDRサイト側のAHVのNutanixクラスターで仮想マシンを起動してみたいと思います。
AHV側のPRISMのメニューから「Data Protection」を選択し、ESXi側で作成したバックアップ上部が表示されていることを確認します。そのジョブを選択し、「Local Snapshot」のタブをクリックし、メインサイトのESXi側のスナップショットが一覧に上がっているのを確認します。
スナップショット一覧から、実際にAHV側で稼働させたい世代のスナップショットの右側にある「Restore」をクリックします。
リストア画面で、DRサイト側(AHV)で稼働させたい仮想マシンを選択し、How to Restoreで「Create new entities」選択します。
仮想マシン名に、AHVを頭につける形の設定をします。(こちらは任意です)
Exampleでリストア後の仮想マシン名が出るので、念のため確認をしておきます。
設定が完了したら、「OK」をクリックします。
リストア処理が開始されるとすると、PRISMの上部に「Snapshot restoration initiated successfully」と表示されます。スナップショットのリストアはストレージポインターの集合体を作るだけですので、一瞬で終わります。
PRISMのVMメニューから、Tableボタンを押し仮想マシン一覧を確認すると、先ほどリストアした仮想マシンが表示されているはずですので、その仮想マシンを選択し、「Power on」をクリックします。
Lunch Consoleをクリックすると、普通にOSが起動しているのがわかります。
OS起動後、デバイスの再検出等の画面も特に出ず、予期せぬシャットダウンの理由を求める画面が出てきます。仮想マシンは電源ONの状態でスナップショットを取得し、リカバリを行っているためこれは仕方がありません。適当な理由を選択し、OKをクリックします。
実はこれだけで、これ以降は何ら普通の仮想マシンと変わりなく利用することができます。
コマンド操作や変換操作などは一切不要です。
今回は、Nutanix的にはAHVではまだ非サポートなWindows Server 2016を利用しましたが、何ら問題なく動作しました。
投稿としては3回に分けての投稿となりましたが、これだけの一連の操作は、わずか12~3分で終了します。
DR環境だけでなく、vSphere上で稼働する仮想マシンをAHVに移行する時にもこの手法は可能です。
インフラ屋とアプリ屋を経験するSEのハイパーコンバージドやネットワークなどインフラ関連とインフラを操るアプリのネタメモ。 ※本内容は、個人の見解や調査による内容ですので、個人の責任おいて情報活用をお願いします。
2016年12月4日日曜日
Nutanixのクロスハイパーバイザーを試してみるその② まずはレプリケーションの設定
さて、前回はAHVとクロスハイパーバイザーの意味について紹介をしました。
実際のケースでクロスハイパーバイザーを使うシーンを元に実際に設定方法までをご紹介したいと思います。
クロスハイパーバイザーは実際、今動いている仮想マシンのハイパーバイザーを変更するという形でご紹介をしましたがそのパターン以外での適用方法をご紹介したいと思います。
それは、「DR」としてのクロスハイパーバイザー機能です。
本番サイトは、vSphere環境を利用しており、その環境のDR環境構築をしようとした際、DRサイト側にもvSphereやvCenter Serverなどのライセンスを用意しなければならず、いつ使うかわからない有事の際という名目だけで、ハードウェアやソフトウェアさらには構築費の予算を取るのは、経営層がコンピューターシステムを業務戦略における重要な位置づけである認識を持っていない限り、なかなか説得が難しいものです。
こんなケースに少しでもコストを下げる手法として本番サイトはESXiそのままで、DRサイトをAHVにして、DR構成をことができます。
今回はこのシナリオを元に、仮想マシンがESXiからAHVにどのようにフェールオーバーするかを見てみたいと思います。
構成イメージ図
まずは、2台のNutanixをレプリケーション設定を行います。
1.メニュー画面のData Protectionの画面から「Remote Site」を選択し「Physical Cluster」を選択します。
2.相手側のNutanixの名前とクラスターVIPをADDRESSに設定します。
(この画面では、AHV側のNutanixにDELLモデルを使っているため、AHV側のサイトをtoDELLと記載しています)
CAPABILITIESの設定で「BACKUP」と「Disaster Recovery」の2つが選択可能となっています。
データーのバックアップのみのレプリケーションの場合は、「BACKUP」を選択します。
今回は災害対策として、DRサイトで仮想マシンを稼働することが目的となりますので「Disaster Recovery」を選択します。
3.お互いのレプリケーションをしたい、コンテナを選択します。また、通信の圧縮したい場合、COMPRESS ON WIREを「Yes」にします。
4.レプリケーションの設定ができあがったことを確認します。
5.同様の設定を、レプリケーションされる側(今回ですとAHVが入ったNutanixクラスター側)から、設定を行います。ようは、クロスでレプリケーションの設定を行っておくことが必須となります。
次に、DR対象となる仮想マシンに、NGT(Nutanix Guest Tools)をインストールします。
VM Mobilityといわれる仮想マシン以降のために最低限必要なソフトウェアだけをインストールすることも可能ですが、AHV上で仮想マシンのパワーオン/オフなどの操作をPRISM上から行えるなどのメリットは、NGTを入れる必要がありますので、今回はNGTをインストールすることにします。
また、VMware Toolsあらかじめインストールされている環境下にNGTをインストールしてなんら問題ありませんので、事前にVMware Toolsのアンインストール等は必要ありません。
NGTをインストールするには、PRISMの画面から、VMメニューに入り、NGTをインストールしたい仮想マシンを選択し、仮想マシン一覧画面の右下にある「Enable NGT」をクリックします。
対象のかそうましんにNGTのISOが自動的にマウントされますので、そのままダブルクリックし、インストールを開始します。
インストーラー画面が表示されますので、ライセンスに同意し、「Install」をクリックします。
するとまず、Pythonのインストーラーが起動します。残念ながら自動インストール機能がありませんので、手動でインストールを行います。
続いて、pywin32のインストーラーが起動します。
こちらも、自動インストーラー機能はありませんので、手動でインストール作業を行います。
続いてVisual C++2010のランタイムがインストールされます。こちらは自動インストールが実行されます。
その後、「Nutanix VM Mobility」のセットアップが始まります。これが今回のキモになるツールです。
その後、Nutanix Guest Toolsのライブラリがインストールされます。
ここまでいくとインストールが完了します。
とくにここで再起動は必要ありません。
では、次の投稿で、具体的なVMのレプリケーション設定とAHV側でのリカバリを行ってみたいと思います。
実際のケースでクロスハイパーバイザーを使うシーンを元に実際に設定方法までをご紹介したいと思います。
クロスハイパーバイザーは実際、今動いている仮想マシンのハイパーバイザーを変更するという形でご紹介をしましたがそのパターン以外での適用方法をご紹介したいと思います。
それは、「DR」としてのクロスハイパーバイザー機能です。
本番サイトは、vSphere環境を利用しており、その環境のDR環境構築をしようとした際、DRサイト側にもvSphereやvCenter Serverなどのライセンスを用意しなければならず、いつ使うかわからない有事の際という名目だけで、ハードウェアやソフトウェアさらには構築費の予算を取るのは、経営層がコンピューターシステムを業務戦略における重要な位置づけである認識を持っていない限り、なかなか説得が難しいものです。
こんなケースに少しでもコストを下げる手法として本番サイトはESXiそのままで、DRサイトをAHVにして、DR構成をことができます。
今回はこのシナリオを元に、仮想マシンがESXiからAHVにどのようにフェールオーバーするかを見てみたいと思います。
構成イメージ図
まずは、2台のNutanixをレプリケーション設定を行います。
1.メニュー画面のData Protectionの画面から「Remote Site」を選択し「Physical Cluster」を選択します。
2.相手側のNutanixの名前とクラスターVIPをADDRESSに設定します。
(この画面では、AHV側のNutanixにDELLモデルを使っているため、AHV側のサイトをtoDELLと記載しています)
CAPABILITIESの設定で「BACKUP」と「Disaster Recovery」の2つが選択可能となっています。
データーのバックアップのみのレプリケーションの場合は、「BACKUP」を選択します。
今回は災害対策として、DRサイトで仮想マシンを稼働することが目的となりますので「Disaster Recovery」を選択します。
3.お互いのレプリケーションをしたい、コンテナを選択します。また、通信の圧縮したい場合、COMPRESS ON WIREを「Yes」にします。
4.レプリケーションの設定ができあがったことを確認します。
5.同様の設定を、レプリケーションされる側(今回ですとAHVが入ったNutanixクラスター側)から、設定を行います。ようは、クロスでレプリケーションの設定を行っておくことが必須となります。
次に、DR対象となる仮想マシンに、NGT(Nutanix Guest Tools)をインストールします。
VM Mobilityといわれる仮想マシン以降のために最低限必要なソフトウェアだけをインストールすることも可能ですが、AHV上で仮想マシンのパワーオン/オフなどの操作をPRISM上から行えるなどのメリットは、NGTを入れる必要がありますので、今回はNGTをインストールすることにします。
また、VMware Toolsあらかじめインストールされている環境下にNGTをインストールしてなんら問題ありませんので、事前にVMware Toolsのアンインストール等は必要ありません。
NGTをインストールするには、PRISMの画面から、VMメニューに入り、NGTをインストールしたい仮想マシンを選択し、仮想マシン一覧画面の右下にある「Enable NGT」をクリックします。
対象のかそうましんにNGTのISOが自動的にマウントされますので、そのままダブルクリックし、インストールを開始します。
インストーラー画面が表示されますので、ライセンスに同意し、「Install」をクリックします。
するとまず、Pythonのインストーラーが起動します。残念ながら自動インストール機能がありませんので、手動でインストールを行います。
続いて、pywin32のインストーラーが起動します。
こちらも、自動インストーラー機能はありませんので、手動でインストール作業を行います。
続いてVisual C++2010のランタイムがインストールされます。こちらは自動インストールが実行されます。
その後、「Nutanix VM Mobility」のセットアップが始まります。これが今回のキモになるツールです。
その後、Nutanix Guest Toolsのライブラリがインストールされます。
ここまでいくとインストールが完了します。
とくにここで再起動は必要ありません。
では、次の投稿で、具体的なVMのレプリケーション設定とAHV側でのリカバリを行ってみたいと思います。
Nutanixのクロスハイパーバイザーを試してみるその① そもそもAHVとは
Nutanixは、ハイパーバイザーが選べるのがその特徴の1つでもあります。
仮想化の長であるvSphere ESXiはもちろんのこと、HyperVやXen ServerもTechPreviewながらも対応となりました。なかでも、Nutanixが一押しのハイパーバイザーがAHVです。
AHVとは、「Acropolis Hyper Visor」の略で、NutanixがKVMをベースにカスタマイズを施したハイパーバイザーとなります。
AHVの魅力は、KVMベースであり無償で提供されるということと、Nutanixを購入するとハードウェアもNutanixのソフトウェア(AOS)もハイパーバイザーもすべてワンストップでNutanixのサポートが受けられるというのもその魅力だと思います。
AHVがサポートするゲストは現状以下の通りとなっています。
・SCSI及びIDEバスでのサポートゲストOS
・PCIバス及びIDEバスでのサポートゲストOS
最新のOSのほとんどがサポートされているためほぼ困ることはないですが、例えば、Windows2000や2003などP2V等で過去資産をvSphere上で使いづけている場合、AHVに対応することができない場合もあります。
上記のことを考えると、ハイパーバイザーは上物の仮想マシンのコンディションによって使い分けることがベストであると思います。
ここで出てくるのが、Nutanixが提供するクロスハイパーバイザーの機能です。
上記の通り、無理にvSphere上で稼働させる必要が無い仮想マシンは、Nutanix上でAHVで稼働させる方がサポートの面や利便性がよいというメリットはありつつも、今動いている仮想マシンをV2Vで変換するのは非常に面倒な作業であり、今順調に稼働している仮想マシンを、変換して正しく動作するかの検証やうまくいかない場合の調査などを考えると、そこまでリスクと手間をかけてまでハイパーバイザーを変更するのはメリットが少ないと思ってしまいがちです。
では、その手間はなければ、話しは早いということだと思います。
まさにこの手間を省いてくれるのがクロスハイパーバイザとして提供される、VM Mobility機能です。
次の投稿で、このVM Mobilityを使った、vSphereからAHVへの仮想マシンの移行方法をお伝えします。
仮想化の長であるvSphere ESXiはもちろんのこと、HyperVやXen ServerもTechPreviewながらも対応となりました。なかでも、Nutanixが一押しのハイパーバイザーがAHVです。
AHVとは、「Acropolis Hyper Visor」の略で、NutanixがKVMをベースにカスタマイズを施したハイパーバイザーとなります。
AHVの魅力は、KVMベースであり無償で提供されるということと、Nutanixを購入するとハードウェアもNutanixのソフトウェア(AOS)もハイパーバイザーもすべてワンストップでNutanixのサポートが受けられるというのもその魅力だと思います。
AHVがサポートするゲストは現状以下の通りとなっています。
・SCSI及びIDEバスでのサポートゲストOS
Windows 7, 8, 8.1, 10 |
Windows Server 2008 R2, 2012, 2012 R2 |
RHEL 6.4, 6.5, 6.6, 7.0, 7.1, 7.2 |
CentOS 6.4, 6.5, 6.6, 7.0, 7.1, 7.2 |
Ubuntu 14.04.x |
FreeBSD 9.3, 10.0, 10.1 |
SUSE 11 |
Oracle Linux 6.x, 7.x |
・PCIバス及びIDEバスでのサポートゲストOS
RHEL 5.10, 5.11, 6.3 |
CentOS 5.10, 5.11, 6.3 |
Ubuntu 12.04 |
最新のOSのほとんどがサポートされているためほぼ困ることはないですが、例えば、Windows2000や2003などP2V等で過去資産をvSphere上で使いづけている場合、AHVに対応することができない場合もあります。
上記のことを考えると、ハイパーバイザーは上物の仮想マシンのコンディションによって使い分けることがベストであると思います。
ここで出てくるのが、Nutanixが提供するクロスハイパーバイザーの機能です。
上記の通り、無理にvSphere上で稼働させる必要が無い仮想マシンは、Nutanix上でAHVで稼働させる方がサポートの面や利便性がよいというメリットはありつつも、今動いている仮想マシンをV2Vで変換するのは非常に面倒な作業であり、今順調に稼働している仮想マシンを、変換して正しく動作するかの検証やうまくいかない場合の調査などを考えると、そこまでリスクと手間をかけてまでハイパーバイザーを変更するのはメリットが少ないと思ってしまいがちです。
では、その手間はなければ、話しは早いということだと思います。
まさにこの手間を省いてくれるのがクロスハイパーバイザとして提供される、VM Mobility機能です。
次の投稿で、このVM Mobilityを使った、vSphereからAHVへの仮想マシンの移行方法をお伝えします。
登録:
投稿 (Atom)