2019年12月25日水曜日

2019年の私とNutanixの振り返り

2019年も残すところ後僅かとなりました。
今までこのブログではNutanixの技術情報を中心に書いてきましたが、Advent Calendar 2019の最後である25日は、せっかくの機会ですので自分の振り返りと反省の意を込め、私自身が2019年どのようにNutanixに関わったか（振り回されたを含む）を書いてみたいと思います。



2019年1月


2019年2月


2019年3月
  • Nutanix トレーニング受講
  • .NEXT Anaheimへの準備
  • Nutanix Certified Advanced Professional (NCAP) 5.5 取得


2019年4月
  • 書籍執筆活動佳境を迎える
  • 社内Nutanixイベント対応で検証作業に追われる


2019年5月


2019年6月


2019年7月
  • 社内Nutanixイベントの対応で環境作成等々に時間を要する


2019年8月


2019年9月


2019年10月


2019年11月


2019年12月


今年のNutanixとの関わりの代表的なものをピックアップしてみました。
もちろんそれ以外にも、通常の業務でNutanixとの関わり合いは多くありますが、今年もいろいろな意味でNutanixと関わることが多かった1年だったと感じております。
個人的には、アメリカでの骨折というのが、いろいろな意味での人生初な経験（二度と経験したくない）なところでしたが、そういったネタになる話しは毎度、Nutanix Meetupに登壇した際に話しております（資料の性質上、クローズドでないとお見せできない資料が多いので、いつも会場投影のみで対応させてもらっております）ので、まだNutanix Meetupに来られたことがない方は、是非参加してみて下さい。
（私は今年7回登壇していたようです...）

Nutanix Meetup　技術好きエンジニアのためのNutanix勉強会
https://nutanix.connpass.com/



来年もNutanixとのよいふれあいができる1年になればと思っております。




投稿者 時刻: 0 件のコメント:
ラベル:

HCIの苦手を克服するストレージ専用ノードの紹介

HCIは、CPU、RAMを搭載するコンピュートとHDD、SSDなどの記憶領域であるストレージが一体となった製品です。
一方で、HCIは、CPUやRAMよりもストレージ領域だけを多く利用した環境の場合、ストレージ容量を満たすまで、CPUやRAMも買い足さなければならないため、コスト的に割高になると言われることがあります。

この言葉は、HCIの概念だけで言うと当てはまることかも知れませんが、Nutanixにおいては、この考え方は必ずしも当てはまりません。

その答えとして、Nutanixは、ストレージ容量だけを増やすストレージノードが存在します。他社のHCIの場合、ストレージヘビーノードとして大きなストレージ容量を提供できるノードが販売されていますが、Nutanixの場合は、ストレージ専用ノードとして動作し、仮想マシンが稼働しないホストを提供します。

しかし、ストレージ専用ノードと行っても、HCIである以上ハイパーバイザーも必要ですし､Nutanixの場合、CVMも必須コンポーネントになります。では、ストレージ専用のノードがどのようなメリットがあるのでしょうか。

下の図を見て頂くと分かるのですが、Nutanixのクラスターは、ストレージ専用ノードと仮想マシンが稼働する部分のハイパーバイザーを混在して構成することが出来ます。

▼1つのクラスターでハイパーバイザーの混在が可能


では、ハイパーバイザーが混在した環境の場合、ESXiで稼動している仮想マシンがAHVにvMotion出来るかというとこれはできません。この環境の場合、ストレージ専用ノードは、AHVがインストールされたノードになります。AHVが稼動するノードはCVMだけが仮想マシンが稼動し、Nutanixクラスター内でストレージ機能のみを提供します。このAHV上で仮想マシンが動作することはできません。

Nutanixは異機種・異世代混在が可能ですから、ESXiで稼動する部分には、高速なCPUや多くのメモリーを搭載し、ストレージ専用ノードは最小限のCPUとメモリーを搭載することで、ストレージにおけるエンクロージャーの追加のように低コストでストレージ容量だけを増やすことが出来ます。
　また、ハイパーバイザーもAHVを利用するため、追加のハイパーバイザー費用は、かかりません。

HCIの悪いところを克服した、Nutanixのストレージノードは、従来「NX-6035C-G5」というストレージ専用ノードとして販売されていました。
現在では、ストレージ専用ノードは、Nutanixで販売されているどのノードでもストレージ線のようー度に設定することが出来ます。

Nutanixが提供するFoundationツールで、イメージングの際にストレージ専用ノードのチェックを入れてイメージングをすることで、任意のノードをストレージ専用ノードとして稼動させることが出来ます。

▼Foundation時に特定のノードをストレージ専用ノードに設定
　ストレージ専用ノード時に設定するAHVのバージョンも指定可能（Foundation 4.5.1）

このストレージ専用ノードのチェックは、Foundation 4.0から搭載されました。
また、Foundation 4.5からは、ストレージ専用ノードに対してイメージングするAHVのバージョンを指定できるようになりました。（4.4までは、インストールするAOSに搭載されたAHVバージョンが自動的に展開されていました）


Nutanixは、ユーザーが便利に、もっと言えば、ITインフラを気にしなくて良い環境を提供することが理念です。そのためHCIによってデメリットが出てくる部分において、そのデメリットを解消する技をちゃんと用意しているところが、Nutanixの魅力的なところの1つだと思います。




投稿者 時刻: 0 件のコメント:
ラベル: ,

2019年12月24日火曜日

Flashモードのご紹介

Nutanixは、AllFlashモデルやNVMeモデルもありますが、売れ筋はSSDとHDDのハイブリッドモデルです。
Nutanixは、SSDもHDDもキャパシティ領域として利用するいわゆるティアリングでよく使われるデーターをHOTデーターとしてSSDに配置し、使うことが少ないデーターをCOLDデーターとしてHDDにおく動きを自動的に行ってくれます。

この場合HOT、COLDの各データーはアクセスされている頻度によりますから、あまりアクセスされないデーターはCOLD扱いとなりHDD層に保存されることは理解できるかと思いますが、定期的にしかアクセスされないが、アクセスするときは高速に動作してほしいという仮想マシンも時々あるように思います。

例えば、月初に前月の請求書を一括でPDF出力する帳票サーバーやバッチサーバーなどがそれにあたると思います。

このような、普段は使わないけど、いざ使うときは負荷がかかるのでSSDに配置してほしいという希望を叶える機能として「Flash Mode」という機能がNutanixには存在しています。

このFlashModeは、「ピニングモード」と記載されているドキュメントもありますが、ピニングモードは従来の名称で現在は「Flash Mode」が機能の名称となります。

このFlashModeは、Extend Storeの25%までの領域をFlashModeで利用できる領域として利用できます。つまり、FlashModeを有効にすればかならずすべてのデーターがSSDに配置されるというわけではないことを理解しておきましょう。

Flash Modeは、仮想マシン単位の設定の場合、Prismの仮想マシン設定画面の一番下でFlash Modeの有効か設定が可能です。

また、Volume Groupにおいても同様にFlashModeの設定が可能です。

このFlash Modeは仮想マシン単位であればPrism上で設定可能です。
一方でREST APIを利用すれば、仮想ディスク単位で設定することも可能です。

この場合、まず仮想マシンで、「Enable Flash Mode」で仮想マシン全体を、Flash Modeの設定にした後、Flash Modeの対象から外したい仮想ディスクに対してFlash Modeを無効化するという作業になります。

なお、この作業はREST APIを利用して行います。
APIの発行は以下の通りです。（メソッドはPUTを利用します。）
https://CLUSTER-VIP:9440/api/nutanix/v2.0/virtual_disks/

投入するJSONは以下の通りです
{
  "uuid": "仮想ディスクUUID",
  "flash_mode_enabled": false
}

RestAPI Exploreからでも実行することが可能です。

この命令が成功するとステータス200が帰ってきます。

仮想ディスクごとのFlash Modeの設定状況は、Prism画面で仮想マシンを選択後、下側に表示される「Virtual Disks」で、確認することが出来ます。

様々なディスクの接続形態で試してみましたが、デフォルトであるSCSI以外にもSATAでもIDEも関係なく、Flash Modeの設定は可能なようです。

では、最後にFlash Modeについて注意事項を含めてお知らせします。

  • Flash Modeは、仮想マシンのライブマイグレーションには影響しません
  • HOTデーター及びCOLDデーターの分析情報をストレージコンテナ事に持っているため、Storage vMotionを行うと、Flash Modeの効果が出るようになるまで時間がかかります。頻繁にStorage vMotionを行うと、Flash Modeの恩恵は受けにくくなります。
  • ストレージの圧縮及びキャッシュレベルの重複排除には影響しません。
    ただし、キャパシティの朝服排除設定時はFlash Modeは利用しないで下さい
  • クローンされた仮想マシンは、Flash Modeの設定は保持されません。（Flash Mode無効か状態でコピーされます）
  • スナップショットからリストアされた仮想マシンは、Flash Modeの設定が保持されないため、手動で有効の設定が必要です
  • 複数モデル混在のNutanixクラスターの場合、モデルによりSSD搭載容量が異なるため、Flash Modeの動作が必ずしもどのホスト上で稼動しても一定にならない可能性があります。
  • Flash Modeを利用するためには､Nutanix Clusterに対してUltimateライセンスが必要になります。


Flash Modeを活用しなくても、Nutanixは、SSDをキャパシティ領域として利用しているため、SSDの容量が一定以上になるまではSSD上にデーターを保存し、ハイブリッド環境であっても、オールフラッシュモデルに近いパフォーマンスを発揮します。
そのため今回ご紹介した、Flash Modeがすべての環境下において有効な機能では無いと思いますが、仮想マシンが多く稼働する環境下で、データーベースやバッチ処理を行うサーバーなど、利用状況に寄らずハイパフォーマンスを必要とする仮想マシンに対して、一定のパフォーマンスを提供するためには、有効的な機能の1つとなるかと思います。












投稿者 時刻: 0 件のコメント:
ラベル: ,

2019年12月23日月曜日

Nutanix Moveのよくある質問とポイントをご紹介

Nutanix Moveは、すごく簡単に仮想マシンをNutanixクラスターに移行してくれるというのは、ご理解いただけたと思います。今回はNutanix Moveでよく聞かれる質問をご紹介したいと思います。

Q.Nutanix Moveは、どういう課金方法で提供されますか？

Nutanix Moveは、Nutanix Cluster（有償製品）を保有している場合、無償で利用することができます。Nutanix CEをご利用でNutanix Moveをご利用になりたい方もいるかと思いますが、現状Community版のNutanix Moveは提供されておりません。


Q.Nutanix Moveで移行がサポートされないゲストOSはどうすればいいのでしょうか？

Nutanix Moveは原則、AHVが対応しているゲストOSの大半をサポートしていますが、一部サポートされていないゲストOSやそもそもAHVが本来サポートしていないレガシーなOSをAHVで稼動させたい場合があるかも知れません。
Nutanix Moveは、既存ゲストマシンに対して、VMware Tools/WinRM等を利用してVirt IO Driverなどの必要なものをあらかじめインストールするなど、ほぼ全自動で移行が終えられるように作られています。サポートされていないOSの場合これらの事前準備時点でエラーが出てしまい、そのままでは移行することが出来ません。
この場合、事前にVirtI/O Driverなどの必要ドライバーを手動でインストール後、Nutanix Moveの移行時に、Preparation Modeを「Manual」に設定し、仮想ディスクのデーターだけをAHVのNutanixクラスターにデーター移行を行うことも可能です。
出来た仮想ディスクを元に仮想マシンを作成し、あとは必要な設定を入れれば移行を完了させることが出来ます。データー転送だけ異をNutanix Moveにお任せする機能を使うだけでもファイル移動に比べて大幅に減らす事が出来ます。



Q.Nutanix Moveの仮想アプライアンスは、AHV側に立てた方がいいのでしょうか？それとも旧環境の3Tier環境に入れれば良いのでしょうか？

Nutanix Moveは、ネットワークを通じて既存クラスターのデーターをvSphereの場合はVADPを使って取得し、NutanixクラスターのストレージコンテナをNFSでマウントしデーターをマウントしたストレージコンテナに配置をします。
いわゆる仮想環境におけるバックアップとおなじ考え方でデーターを取得します。
この場合、既存3Tier環境とNutanixクラスターの間のネットワーク帯域を比較して配置するのがよいと思います。
3Tier環境とNutanixクラスターの間が10Gのネットワークで接続されている場合、3TierでもNutanixクラスターでもどちらにMove仮想アプライアンスを立てても速度に変わりは無いと思います。一方、3Tier環境とNutanixクラスターの間が1Gで接続されている場合は、Nutanix環境に配置すれば、バックアップデーターをNutanixに配置する際は、CVMとダイレクトに通信が出来る環境になるため、高速にバックアップデーターを配置できるようになります。


Q.Nutanix Moveを利用するにあたって注意することは何かありますか？

ゲストOSを移行するにあたっては以下のことを確認することが大事です。
  • 対応しているハイパーバイザーのバージョンを確認
    （ESXi5.1/Hyper-V2012～）
  • 対応しているゲストOSの確認
    （既にOSメーカーがサポートを終了したOSは原則非対応）
  • VMware Toolsがインストールされていること
  • OSのAdministrator / root権限のアカウント情報がわかること
  • Windowsの場合、UACがオフになっていること
とくに、UACが向こうになっているかのチェックは、忘れがちですがこれは無効かしておかないと、VMware Toolsなどのツール経由で必要なファイルをゲストVMに送った後、インストールスクリプトが実行されますが、そこでUACの確認画面が裏で表示され、制御ができないため、途中で処理が中断してしまいます。

▼ゲストVMを移行前にUACは"通知しないに"しておきましょう



Q.vCenter Serverが存在しない単独のESXiホストの仮想マシンは移行できますか？

Nutanix Move 3.2以降で、ESXi単独環境でvCenter Serverが存在しない環境でもNutanix Moveを利用することができます。ただし、VDDKのAPIを利用する関係からESXiのライセンスがvSphere Hypervisor（無償ライセンス）では、Moveを使った移行は対応していません。


Q.3TierのvSphere ESXiの環境からNutanix+ESXiの環境移行で利用できないですか？（Nutanix Moveの移行先はAHVのみでしょうか？）

Nutanix Move 3.3から、移行元vSphere(ESXi)環境から、Nutanix+ESXiの環境においても、仮想マシンの移行が出来るようになりました。従来は移行元のvSphere環境からNutanixのストレージコンテナをNFSでマウントしてストレージvMotionなどを使って、ストレージを移行することで、仮想マシンの引っ越しを実現していました。
しかし、既存vSphere環境を触りたくない（設定変更が許されない）場合もあるかと思います。そういった場合に、Nutanix Moveを利用することで、既存のvSphereからNutanix+ESXi環境への仮想マシンの引っ越しを、短いダウンタイムで行うことが出来ます。なお、ESXiからESXiへの引っ越しとなるため、Driver等のツールの流し込みはなく仮想ディスクファイルの引っ越しのみの動作となります。


以上、Nutanix Moveについての注意点やよくある質問をまとめました。
Nutanix Moveは無償で提供されていますが、大変よく出来たツールだと思います。
従来のV2Vにおけるダウンタイムに比べ圧倒的にダウンタイムを短くすることが出来ますので、仮想マシン移行の際は是非活用をおすすめします。









投稿者 時刻: 0 件のコメント:
ラベル: ,

2019年12月22日日曜日

AHVへの引っ越しは、Nutanix Moveで　HyperV編（その２）

前回までに、Moveを使って仮想マシンの移行準備を行いました。
今回は、実際に仮想マシンをAHVにマイグレーションします。

移行前に、Hyper-V上でデスクトップにファイルを作成しておきましょう。

では、Moveの画面にいき、仮想マシンにチェックを入れCutoverボタンをクリックします。

カットオーバーを行うと、仮想マシンがシャットダウンされ仮想NICの接続が切断される旨が記載されています。このまま「Continue」をクリックします。

イベントログを見ているとチェックポイント処理が行われ最終のスナップショットが送られていることが分かります。


既に移行処理が完了していると出ていますので、Prismで確認をします。

移行前に作成したファイルもきちんとデスクトップ上に存在しています。
また、デバイスドライバーもきちんとVirtI/O Driverになっていることが確認できます。

Hyper-Vであっても、vSphere同様に簡単にAHVに移行が出来ました。

今回のポイントは、Hyper-V第２世代仮想マシンの移行ということです。
Hyper-V第２世代の仮想マシンは、 UEFIで作成されており従来のImage Serviceを使ったVHDXの変換だけではAHV上で仮想マシンを動かすことが出来ない状況でしたが、Nutanix Moveを利用すると、UEFIのまま仮想マシンを移行させることが出来ます。
AOS5.11から、UEFIに正式に対応しましたので、Hyper-V第2世代の仮想マシンを移行する場合は、AOS5.11移行の環境を原則用意頂くことになります。
（AOS5.10であっても仮想マシンに対してUEFIモードで起動させることは出来ますが、原則サポータブルではありません）

▼第2世代の仮想マシンを移行すると、AHVの仮想マシンも自動的にUEFIに設定される。

以上、Hyper-V環境でのNutanix Moveを使った移行方法のご紹介でした。

















投稿者 時刻: 0 件のコメント:
ラベル: , ,

2019年12月21日土曜日

AHVへの引っ越しは、Nutanix Moveで　HyperV編（その1）

前回までに、ESXiからAHVへの移行が簡単にかつ、ダウンタイムをかなり短く行うことが出来ることが分かりました。
では、今回はHyper-VからAHVへの仮想マシン移行についてご紹介します。

今回は、Nutanix Move 3.4を利用して作業を行います。
移行元環境は、Windows Server 2012R2で、第2世代の仮想マシン対応で構成された環境にWindows Server 2012 R2をインストールした仮想マシンを移行します。

まずは、Nutanix MoveのSourceにHyper-Vを登録します。

すると、add the environment と表示されしばらく待ちが発生します。
このタイミングでHyper-Vホスト側にWinRM機能を利用して、MoveのAgentがインストールされます。インストール場所は、上記のSourceを登録する際のユーザープロファイルの配下にできあがります。この環境は、Administratorで登録をしていますので、「C:\Users\Administrator\Nutanix\Move\3.4」になります。
併せて、「move-service.exe」 が、「Nutanix Move Agent」という名前でサービスに登録されます。

なお、Move3.2までは、このAgentが日本語版のWindowsですとうまくインストールが出来ませんでした。これは、インストール時に利用しているPowerShellのコードが日本語に対応していないことに由来していましたが、Move3.3.1以降では、問題なく日本語環境でもインストールが可能です。

もし、Agentのインストールに失敗し、Sourceの登録に失敗した場合、Agentを手動でHyper-Vホストにインストール後、再度Source登録することで成功する可能性が高いです。
Agentバイナリは、Moveアプライアンスにhttp経由でアクセスします。
http://<nutanix-move-ip>/downloads/agents/move-agent-installer.exe
ダウンロードしたバイナリを、Hyper-Vホストにインストールします。

なお、インストール時には以下のパラメーターを入力します。
move-agent-installer.exe -o install <nutanix-move-ip> -u Administrator
最後のAdministratorは、サービスを起動するユーザーに紐付きますので、Administratorと書きましたが、実際には管理者権限を保有したユーザーとなります。

なお、AgentをインストールするとWindows Firewallにて、8087番のポートが開放されるルールが追加されます。このポート番号は、MoveとAgentがやりとりするために利用され、ポート番号を変更することはできません。

では、続いて、マイグレーションプランを作成します。

続いてソース環境とターゲット環境のNutanixを登録します。

続いて、移行したい仮想マシンの「＋」マークをクリックし、移動対象のVMに登録します。ここで！マークが表示されます。
この内容は、セキュアブートに関する注意事項です。
第2世代の仮想マシンでは、カットオーバープロセス中及びカットオーバーが完了するまでは、仮想マシンのセキュアブート機能は無効になります。カットオーバープロセスが終了すると、セキュアブート機能が再び有効化されます。

▼Hyper-Vで第2世代仮想マシンを作成するとデフォルトでセキュアブートが有効になる

セキュアブートは自動的に無効にされ、移行終了後にHyper-V側のソース仮想マシンは元の設定に戻りますが、セキュアブートが必要でない場合はあらかじめチェックを外しておいてもよいかと思います。なお、セキュアブートの無効化は該当の仮想マシンがパワーオフ状態の時のみ設定変更が可能です。

続いてネットワークのマッピングを行います。
ここで出てくるにSource Networkは、Hyper-Vホストのアダプタになります。
割り当てるネットワークは、仮想マシンが通信したいネットワークになります。

この画面では、vSphere同様、ゲストOSへVirt IO Driverをインストールするためのcredential情報の入力を行います。vSphereの場合同様複数の仮想マシンを一括して移行する場合、仮想マシン個別のcredential情報を入力することも可能です。

また、Move 3.4からタイムゾーンの設定項目も追加されました。
ここでは、「Asia/Tokyo」を選択します。

Hyper-Vの仮想NICに付与されたMac Addressをを引き継ぐ場合は、「Retain MAC Addresses form the Source VMs.」にチェックを入れます。

最後にサマリーを確認し、「Save and Start」をクリックします。

これで、Hyper-Vの仮想マシンにVirtI/O Driverなど必要なモジュールが、「C:\Nutanix」に配置されます。


Hyper-Vマネージャーで確認すると、vSphereと同様にチェックポイント（スナップショット）が順次取得されているのが分かります。


 では次回に実際に、カットオーバーを行いAHVへの移行を行ってみましょう。









投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2019年12月18日水曜日

AHVへの引っ越しは、Nutanix Moveで（その５）

前回までに仮想マシンの移行準備は完了しました。
では、実際に仮想マシンをマイグレートしたいと思います。

まずは、vSphereのスナップショットを見てみましょう。
一段階目のスナップショットは既に転送済みで、２回目以降のスナップショットが送信されています。
▼２回目のスナップショット

▼３回目のスナップショット

このスクリーン書ととを見ると分かるようにスナップショットは１０分に一度送られていますが、スナップショットが多段になってI/Oスピードの低下や仮想ディスクファイル破損を防ぐため、スナップショットは２段階までとなっており、順次古いスナップショットが新しいスナップショットを作成される際に削除されます。

では、データーの差分がちゃんと送られているかを確認すするため、移行する前に、移行元のWindows Server 2012 R2の仮想マシンにファイルを作成してみます。

この検証は12/1に行っておりますのでその日付と時刻をテキストファイルに書いてデスクトップに保存します。

続いてMoveの画面で、In Progressをクリックし、Windows Server 2008 R2をCutover処理を行います。

確認処理が走ります。

vSphere Clientを確認すると、移行元の仮想マシンは、シャットダウンスされ最終のスナップショットが送られていることが分かります。

移行作業が完了すると、自動的にPrism上に仮想マシンが登録され、移行された仮想マシンが自動起動します。

Prismを見ると仮想マシンが登録され起動していることが分かります。

仮想マシンにログインすると、先程vSphere上で作成した仮想マシンにも移行前最終で作成したテキストファイルがきちんと移行されていることが分かります。


今回はNutanix Moveの動きと共に移行方法を紹介しましたが、ユーザー側で操作することはMoveの画面で移行元と移行先を選択するぐらいで面倒な作業無く、任意のタイミングで切り替えが出来るというのは大変便利であることがわかります。




投稿者 時刻: 0 件のコメント:
ラベル: , ,

2019年12月17日火曜日

AHVへの引っ越しは、Nutanix Moveで（その４）

前回まででNutanix Moveの基本設定が終わりました。
では実際に、Nutanix Moveを使って仮想マシンを移行の設定をご紹介します。

まずは、Moveの管理画面の真ん中にある「Create Migration Plan」で移行の計画を作成します。


まずは、MigrationPlan名を入力します。


続いて、移行元のハイパーバイザーと移行先のNutanixクラスター、移行先のストレージコンテナを選択します。
ESXiに登録されている仮想マシンの一覧が表示されます。
移行対象にしたい仮想マシンの「＋」マークをくり行くすると、右側の移行対象一覧にと登録されます。
ここでは、ESXi5.1に登録されたWindows Server 2008R2とWindows Server 2012 R2の2台の仮想マシンを移行します。（仮想マシンインベントリ名表示がすべて入りきれていませんが、マウスポインタを当てると名称がフルで表示されます）
選択完了後、「Next」をクリックします。

続いて、移行先環境のVLANを選択し、Nextをクリックします。
続いて移行の詳細設定情報が出てきます。ここから紹介するオプションは非常に重要です。

Preparation Mode

こちらは仮想マシンの移行方法についてです。
Auto
Virt I/O Driverや移行ツールを移行対象の仮想マシンに自動インストールを行います。
Manual
本来Autoで実行される内容を、スクリプトで表示を行います。手動で移行元仮想マシン上で指定されたスクリプトを実行することで、Autoと同じ状態にすることが出来ます。
Mixied
上記の2つを混在させる場合に利用

Credentials for VMs

こちらは、ゲストOSの管理者アカウントを入力します。
こちらのテキストボックスに入れた場合、プランに登録されている仮想マシン一括でこのcredential情報を利用します。
仮想マシン個別でcredential情報を入力したい場合は、「Override individual VM settings」で個別設定を行います。

Retain MAC Address from the Source VMs.

移行元仮想マシンのMACアドレスを維持します。
（MoveはIPアドレスを引き継ぎますが、このチェックを入れた場合は複数NIC搭載された仮想マシンにおいてもIPアドレスの引き継ぎが正常に動作します）

Bypass Guest Operations on Source VMs.

このオプションにチェックを入れると、ゲストVMにDriver等の必要な情報を一切投入せず素のままの仮想マシンの仮想ディスクを移行します。（あらかじめVirt I/O Driverを移行もと仮想マシンに入れている場合などに選択）

上記2つのオプションは、Manage Settings for Individual VMsで仮想マシン個別に設定が可能です。

Schedule Data Seeding

データーの移行を開始する日時を指定します。チェックを入れない場合原則プラン保存後から開始されます。


設定が完了したら「NEXT」をクリックします。

Nextをクリックすると、移行元仮想マシンにスクリプト等必要なファイル等が送信出来るか確認が行われます。（credential情報が間違っている場合この時点でエラーが発生します）

vSphere Clientから見ると、VMware Toolsを経由してファイルを転送いているところが分かります。


最後にサマリーが表示されます。
Planを保存しこの時点での実行をしない場合は、Saveを、このままPlanをスタートする場合は「Save and Start」をクリックします。
Planが正常にスターとするとPlan一覧が表示され、実行中の時は「In Progress」が表示されます。

In Progressをクリックすると、進捗状態が確認出来ます。

最初はDriverのインストールを行っていることが分かります。


Driverインストールなどの下準備が終わるとデーターの移行が開始されます。

vSphere上では最初にVMware Toolsを経由したファイル転送が行われていることが分かります。
移行元仮想マシンで認証したアカウントのTempディレクトリに必要なドライバー等が送信されていることが分かります。

Driverのインストールが終わると、スナップショットが取得され読み取り専用仮想ディスクが読み出されていることが分かります。

スナップショットマネージャーを確認すると、Move用のスナップショットが取得されていることが分かります。

あとは、データーの移行を待つばかりです。
初期データー我の移行が終わると、カットオーバー（切り替え）準備完了状態になります。Cutover可能な状況になるとStatusの横に●表示が付きます。

もうここまで来れば準備はほとんど完了しています。
では、次回いよいよ仮想マシンの移行完了までご紹介したいと思います。





投稿者 時刻: 0 件のコメント:
ラベル: , ,

2019年12月16日月曜日

AHVへの引っ越しは、Nutanix Moveで（その３）

前回までに、Nutanix Moveの動きを紹介致しました。
では実際にNutanix Moveを導入方法をご紹介します。

今回は、Nutanix AHV上に展開する形をご紹介します。
ESXiへの展開の場合は、OVAでの展開とりImageService投入部分の方法が異なるだけで、設定方法はAHVとESXiで変わりはありません。

まずは、MyNutanixからSupport Portalから「Downloads」→「Nutanix Move」の項目に行きます。（MyNutanixへのアクセスはNutanixパートナーまたはNutanix保守締結ユーザーのみがアクセス可能です）

(参考）Nutanix Support Portal / Nutanix Move Download
https://portal.nutanix.com/#/page/NutanixMove

今回は、2019/12/16現在Moveは、3.4が最新版ですが、ここでは3.31のバイナリを元にデプロイ方法をご紹介します。なお、3.4でも3.31でもデプロイ方法に変わりありません。

Move ZIP file for AHVファイルをダウンロードします。

ダウンロードしたZIPファイを解凍し拡張子が「qcow2」のファイル（この場合move-3.3.1.qcow2）をNutanix Prism画面からImage Serviceに投入します。



Prismのギアアイコンから、Image Configurationを開き、qcow2を投入します。

投入が完了し、Imageの一覧に表示されていることを確認します。

Imageが登録されたことを確認し、PrismのVMメニューに移動し、「+ Create VM」で仮想マシンを作成します。

仮想マシンスペックは、以下のように作成します。
vCPU : 2
Numbber Of Cores Per vCPU : 2
Memory : 4GB

Disksで、「+ Add New Disk」をクリックし、「Clone from Image Service」から先程投入したNutanix Moveのイメージを選択します。

Add下のち、Network Adapters (NIC)で「+ Add New NIC」で、移行元環境と移行先環境が通信可能なVLANを選択します。

最終的に以下のような構成で仮想マシンを作成します。

仮想マシンの作成が完了したら、仮想マシンをパワーオンし、Nutanix Moveの仮想アプライアンスを起動します。

ログイン画面になったら、初期アカウントで以下のユーザー名・パスワードでログインします。
ユーザー名：admin
パスワード：nutanix/4u

初回ログイン時は
「You are required to change your password immediately (administrator enforced)」と表示され、パスワードの変更が要求されます。

まず、現在のパスワード「nutanix/4u」を入力し、その後希望するパスワードを入力します。

続いて、IPアドレスの固定化を聞かれますので、必要に応じてYを入力し、IPアドレスを設定します。この作業は、SSH経由ではなく必ずコンソールで行ってください。
Welcome to Alpine Linux 3.9
Kernel 4.19.75-0-virt on an x86_64 (/dev/tty1)

move login: admin
Password: nutanix/4u
You are required to change your password immediatelly (administrator enforced)
Changing password for admin.
Current password: nutanix/4u
New password:自分が希望するパスワード
Retype newe password:再度自分が希望するパスワードを入力


Alpine Linux v3.9 (3.9.4) - Nutanix Move

Welcome to Nutanix Move. Please refer to the Move documentation
to know more about the console usage and troubleshooting.

    https://www.nutanix.com/products/move/

Do you want to configure static IPv4 address? (y/N)
y
>Enter Static IPv4 Address (e.g. 192.168.1.3)
192.168.X.X (希望するIPアドレス）
Enter Netmask (e.g. 255.255.255.0)
255.255.255.0 （サブネットマスク）
Enter Gateway IP Address (e.g. 192.168.1.254)
192.168.X.X　（デフォルトゲートウェイ）
Enter DNS Server 1 IP Address (e.g. 128.91.2.13)
8.8.8.8　（プライマリDNS・必須）
Enter DNS Server 2 IP Address (e.g. 128.91.2.14)
8.8.4.4　（セカンダリDNS・必須）
Enter Domain (e.g. my.dc.domain)
toriten.oita（ドメイン名・必須）
Static IPv4 configuration provided:
****************************************************
* ipaddress    *    192.168.X.X
* netmask      *    255.255.255.0
* gateway      *    192.168.X.X
* dns1         *    8.8.8.8
* dns2         *    8.8.4.4
* domain       *    toriten.oita
****************************************************
Configuring static IPv4 ...

なお、間違えてNを入力してしまった場合は、以下のコマンドで再度IP固定設定を呼び出せます。
/opt/xtract-vm/bin/configure-static-ip

IPアドレスの設定が終わったら、Moveアプライアンスに設定したIPアドレスを、インターネットブラウザーで開きます。

ブラウザで開くと一番最初にEULAが表示されますので、同意してContinueをクリックします。

続いて収集データーに関する情報が表示されます。

続いて、初期パスワードの設定を行います。
仮想アプライアンスで設定したパスワードは、あくまでのシェルログイン用のパスワードであり、Nutanix Moveを利用するためのパスワードはこちらで設定します。

ログインすると、Moveの操作画面が表示されます。
では、さっそく移行元のESXiを登録してみましょう。
「+Add Source」をクリックします。

今回はソースはvCenterなしのESXi5.1を登録してみます。
Source Environment Typeに「ESXi」を選択し、ESXiのホストIPとcredential情報（ユーザー名とパスワード）を入力します。


登録が完了すると、左側に登録したソースが表示されます。
続いて移行先のNutanix環境も登録します。
「+ Add Target」をクリックし、ターゲットを登録します。

Nutanix側は、PrismのIPアドレスとユーザー名、パスワードを入力します。
Prism Centralで一括管理をしている場合は、Prism Centralの情報でもかまいません。

登録が完了すると、Source、Target共に登録が完了したことが分かります。
これで移行に伴う事前準備が終わりました。


次回は、具体的な移行の方法をご紹介致します。









投稿者 時刻: 0 件のコメント:
ラベル: , ,
登録: 投稿 (Atom)