2020年11月22日日曜日

Nutanixにおけるデーター保護のあれこれ

Nutanixが提供するHCI製品は、サーバー・ストレージを統合した仮想化基盤であることは皆さんご存じだと思います。仮想化基盤の運用において課題の1つが仮想マシンのバックアップです。仮想化により高集約にすると、物理サーバーの台数に対して仮想マシンのバックアップ対象仮想マシンが多くなり、夜間の業務時間外にバックアップが終了せず、翌朝の始業時間を迎えてしまうといったことはよく聞かれる運用の悩みです。

Nutanixにおいては、従来からDataProtectionといわれる仮想マシン保護機能がついていましたが現在ではさらに多くの機能が搭載されています。今回は、様々なシーンにおいて利用できるデーター保護機能を改めて押さえていきたいと思います。


Nutanixにおけるレプリケーションの基本

Nutanixのストレージは、ストレージブロック単位でCopy on Writeによる制御を行います。ストレージブロックでのCopy on Writeを利用したスナップショットを利用するため、稼働ディスクファイルを分割するハイパーバイザーが提供するスナップショットと異なり、高い安全性を保ったまま差分データーブロックを保持することができ、その差分データーブロックをレプリケーションすることで、効率的なレプリケーションを実現します。


Async DRによる保護(非同期)

最もシンプルなレプリケーション方法です。Nutanixの全てのエディションで利用できる機能であり、仮想マシン単位でクラスター間のレプリケーションとDRが可能です。最短のレプリケーションサイクルは1時間に1回となります。レプリケーション先のNutanixクラスターで、仮想マシンを仮想マシンを稼働させることも可能です。



SNRTへの保護(非同期)

SNRTは、Single Node Replication Targetの略で、1ノードで構成されたNutanixクラスターで、主にレプリケーション目的で利用するNutanixクラスターのことを指します。
SNRT利用時のレプリケーションサイクル(RPO)は、6時間に1回となります。
Ansyc DRの時と同様に、SNRT側で仮想マシンを稼働させることができますが、SNRTにおける稼働する仮想マシン台数は、5台程度が推奨となります。
SNRTへのレプリケーションの制限として、転送元のクラスターのストレージコンテナに重複排除が有効化されていないことが条件となります。



NearSycnによる保護(非同期)

NearSyncは、Nutanixクラスター間を最小20秒で非同期レプリケーション行う仕組みです。Async DRは最小1時間のRPOでしたが、NearSyncは15分から20秒の間でレプリケーション設定が可能であり、よりクリティカルな環境におけるDRを実現します。
NeaySyncは、マルチサイトレプリケーションに対応していますが、NearSyncでのレプリケーションは1:1となり、その他のレプリケーション先はAsyncDRになります。また、NearSyncを利用するクラスターはノード当たり1.2TB以上のSSDを搭載する必要があります。ハイパーバイザーは,AHVとESXiのみがサポートされ、クロスハイパーバイザーレプリケーションは未対応です。
RPOは、NearSyncのみの利用時は最小1分であり、MetroAvailabilityとの併用利用時にESXiで構成されたNuatnixクラスターの場合、ストレージコンテナレベルでのレプリケーションとして20秒のレプリケーションが可能です。
Async DRと同様にレプリケーションを受け取ったバックアップクラスター側で仮想マシンを起動させることが可能です。



MetroAvailabilityによる保護(同期)

Metro Availabilityは、完全な同期レプリケーションを行う方式です。完全な同期レプリケーションのため、データーの差分無くメインクラスターが何らかの障害が発生した場合、セカンダリーのクラスターでHAが発動して仮想マシンが稼働する仕組みです。Metro Availabitilityには、いくつかの制限があります。まずは、2クラスター間の回線の遅延が5msec以内である必要があります。Metro Availavilityは、ESXi及びHyper-Vクラスターをサポートします。ESXi+AHVストレージノードで構成されたクラスターはサポートされますが、Hyper-V+AHVストレージノードで構成されたクラスターはサポートされません。また、WitnessVMにおける監視は、AHVストレージノードが構成されている場合、サポートされません。



Leapによる保護

Async/Near DRによる保護は、仮想マシンのレプリケーションと簡易的なDRを実現できます。一方で仮想マシンの自動起動や起動時のシナリオなど細かい設定はAsync/NearSyncでは設定できませんでした。その課題を解決すべく、現在ではPrismCentralを介して細かなDRを構成するLeapが提供されています。Leapを利用すると、仮想マシンのフェールオーバー時の細かい設定(起動順序や待ち時間設定)、DRのテストを行うことが出来ます。
Leapにおいても、同期レプリケーション及び非同期レプリケーションがサポートされていますが、同期レプリケーションはAHVのみの対応となります。一方NearSyncベースのレプリケーションは、AHVもしくはESXiクラスターのみがサポートされます。



Leapにより、仮想マシンのDRにおいてシナリオ(RunBook)に応じてDRを実現する方法が実現できるようになりましたが、Nutanixは、vSphere Site Recovery Manager (SRM)のSRA(アダプタ)を提供していますので、vSphere ESXi環境のNutanixにおいては、SRMを利用したRunBookを備えたDR環境が構築可能であることも忘れてはいけません。

Nutanixにおけるレプリケーション/DRの構成には様々な手法があり、かつ条件が複雑化してきています。以下の表のように簡単にまとめてみましたが、その他にも様々な仕様条件がありますので、特にNearSyncやMetro、Leapを利用する場合はNutanixから提供されるドキュメントを確認の上、環境条件が揃っていることを確認する必要があります。


▼レプリケーション/DRにおける機能毎のまとめ(表をクリックすると拡大表示できます)







2020年10月11日日曜日

AOS5.18の新機能(その3):右クリックメニューの登場

 AOS5.18になって変わったのは、ストレージ機能だけではありません。UIについても一部変更が入っています。

今日は、Prismに入った改善点の「右クリックメニュー」について紹介します。

従来Prismは。全ての操作が左クリックのみの操作で、非常にシンプルを売りにしていました。一方でPrism Centralを筆頭にPrismで操作する機能が増え、操作に対してわざわざアクションボタンまでマウスポインターを移動して操作を実行すると点に煩わしいという声も出ていました。

そのため、従来のアクションボタンからのメニューは残しつつも、対象のオブジェクトを選択して、右クリックを行うとActionボタンをクリックしたときと同様のメニューを出すことが出来るようになりました。

▼Prism Centralでの右クリックメニュー


▼出てくるメニューはActionからのメニューと同じ内容となります


右クリックメニューはPrism Elementでも搭載されています。

▼Prism Elementの場合リストしたのアクションメニューと同様の物が表示されます


このため、マウスの右ボタンがないと操作出来ないと言うことはありませんので、従来通りタブレット端末からタップでの操作も可能です。


他の管理ツールにおいては右クリックというのはあって当たり前になっており、何を今更感がありますが、NutanixにおいてはPrismのシンプルさを実現するために右クリックでの操作は、Prismの登場以来搭載されていませんでした。

AOS 518になって搭載されても、右クリックしないと出来ないアクションはなく、従来の方法のまま操作することが出来るという点は押さえておくべき点だと思います。



2020年10月5日月曜日

2020年(2021年度版)Nutanix資格試験制度について

Nutanixは、7月が決算月になるため、2020年8月からFY2021(2021年度)となります。

FY2021になり、資格試験周りについても更新がありました。
今日は、新しくなった試験制度について見ていきましょう。
(正直毎年制度変わるので、これからNutanixを勉強しようという方にとっては、過去の情報との見分けを付けずにに情報を収集すると、わかりにくいことがあるかも知れません。過去のことは気にせず、2021年度は、この内容を見ておけば大丈夫です)

試験のカテゴリですが、以下のような形の分類となりました。

パートナー向け試験:
Nutanix Partner Network向けに、用意された試験として、
「NPSR Level1~3」と「NCSE-Core」の認定を受けることでより上位のパートナーランクを取得することが出来ます。パートナー制度やパートナー向けの試験制度についてはまた改めて記載したいと思います。

コンサルタント向け試験:
導入コンサルタントパートナー向けには、プロフェッショナル試験であるNCPを取得後、導入ソリューション毎に設けられた試験が用意されています。
詳細は、NPN向けかつ、サービスコンサルタント契約事業者に公開されています。

プロフェッショナル向け試験:
こちらはNutanixのパートナーにかかわらず受験することが出来る、Nutanix技術者向けの試験となります。従来NPPやNCPと言われていた技術者向けの試験はこのプロフェッショナル向け試験としてカテゴライズされます。


プロフェッショナル技術者向けの試験は、試験レベルが明確に定義されました。



試験レベルとしては、以下のようにまとめることが出来ます。
レベル難易度試験内容
EXPERT超超超難しいまず普通には難しい(かつ英語のみ)
MASTERかなり難しいNutanixの高度な知識と、
様々なユースケースや機能を熟知している
PROFESSIONAL難しいNutanixの基礎とアーキテクチャーを理解している
ASSOCIATE入門Nutanixの基本的なことを理解している

では、このレベルに合せた形の試験の名称について紹介致します。
ロゴレベル試験呼称試験正式名称
EXPERTNPXNutanix Platform Expert
MASTERNCMNutanix Certified Master
PROFESSIONALNCPNutanix Certified Professional
ASSOCIATENCANutanix Certified Associate

NPX
NPXは、Nutanixプラットフォームにおけるエンタープライズクラスのソリューション設計を提供する能力を証明します。プレゼンテーション等が試験内容に含まれるようで、その難易度はかなり難しいです。なお指名制の試験のため、希望を出せば受験が出来るという物でもありませんので、そういった面でもかなりハードルが高い試験となります。

NCM
NCMは、Nutanixにおける複雑なクラスター管理および運用が出来ることを証明します。NCMは、今までNCAPと呼ばれていた試験の後継となります。NCMにおいては、基本的なスキルの他に、ワークロードに応じたベストプラクティスやトラブルシューティングなどNutanixとその周辺の環境における内容が試験範囲となるため、単純にNutanixだけのスキルがあっても成立しないという特徴が有ります。NCMを保有していれば、Nutanixの基本的な展開に上に、アプリケーションに応じた展開方法やNutanixの高度な機能の利用方法についても知識を習得していることになります。

NCP
NCPは、Nutanixにおける基本的なスキルとアーキテクチャーを理解していることを証明出来ます。一般的なプロフェッショナル資格となり、NCPを持っていればNutanixの導入における必要な知識は習得していることになります。

NCA
NCAは、今回新たに制定された資格です。
NCAは、Nutanixの入門にあたる試験です。半年から1年程度のNutanixの利用経験がある方向けの試験となります。
本試験はまだβ版であり詳細はこれから出てきますが、Nutanixにおける基礎知識を持っていることが証明出来る試験となるようです。


また、今まではNutanixのコア機能に対しての試験となっておりましたが、今後は、各製品ソリューション向けに試験カテゴリが分かれます。

名称正式名称
MCIMulticloud Infrastructure
MCAMulticloud Automation
EUCEnd-User Computing
BCBusiness Continuity
DSData Services
SGSecurity & Governance
DBDatabase Modernization

今までのNCPやNCAPなどは、MCIのカテゴリに含まれます。
今後は、従来のNCPは、NCP-MCIに、NCAPは、NCM-MCIと言う名称になります。
今後、NCP-EUCやNCP-DSといった新しいカテゴリのNCP試験が登場するようです。
NCP-EUCは、VDIシステムを中心とした試験内容となるようです。
NCP-DSは、Files、Volumes、Objectsを使用したストレージ機能が試験内容になるようです。Nutanixのコアな機能だけでなくこういった周辺ソリューションの知識も持ち得ていることが証明出来る点は、試験の詳細化したメリットであると思います。

Nutanixの各種勉強コンテンツがまとまったサイトとして、Nutanix Universityサイトが新しくなりました。こちらからプロフェッショナル試験の受験勉強のためのコンテンツにアクセスが出来ます。また、模擬試験の受験や本番試験の予約もこちらから行えます。

試験は、従来通りPSIの試験システムを使った物で、オンライン(Webカメラによる有人監視)もしくはPSI定型の試験センターで受験することが出来ます。
試験センターの場所は以下から確認することが出来ます。

PSIテストセンター






2020年10月4日日曜日

Nutanix .NEXT の思い出

今年はワールドワイドの統合イベントとして開催された、Nutanix .NEXT。

昨今の世情を踏まえオンラインでの開催となり、アメリカの大きな会場でその臨場感を直接味わうことが出来ませんでしたが、登録すれば無料でNutanixの最新のコンテンツに触れることが出来きたのは、オンラインであるからこそのメリットだと思います。

Nutanix.NEXT 2020については、別のブログで記載をしておりますので、内容を把握したい方はこちらをご覧下さい。

今日は、来年またアメリカの地で.NEXTに参加出来ることを願い、私が過去に参加したNutanix.NEXTの思い出をお話ししたいと思います。


2017年 ワシントン

私が初めて.NEXTに参加したのは、2017年6月に開催された.NEXT Washingtonでした。この当時、Nutanixと言う名前が日本でもようやく定着し始めたところでした。日本人ツアーの参加はまだ30人程度と少ない状況でした。

2017年 ワシントンの会場




この当時はまだKeynoteの会場もだいぶ小さいことが伺えます。



2017年の.NEXTのノベルティは大事に保管しています。



特にこの年話題だったのが、おもちゃのドローンでした。かなり操作が難しいと話題になっていたのを思い出します。それを聞いて、壊れたらもったいないと思った私は一度もさわること無く箱に入れて保存していました。



会場には、あちこちに置かれていた、光るヨーヨー。これは、今となってはちょっと貴重かも。





2018年 ニューオリンズ
2回目の.NEXTは、アメリカの南に位置するニューオリンズ。日本からの移動はかなりの時間がかかり移動だけで疲れたことはまだ記憶に新しいです。(アメリカ移動は毎回辛いですが)

.NEXT ニューオリンズの会場



会場も2017年に比べて相当に大きくなり、参加人数も2016年に比べ倍近くになったことを記憶しています。まさにNutanixが強く普及してきたと感じられる年でした。



2018年のノベルティも今でも大事に(食べずに)保管しています。

ニューオリンズの有名なお菓子、BEIGNETの粉とタバスコ発祥の地と言うことで、タバスコ、そしてスマートフォンのワイヤレスイ充電器とTシャツでした。BEIGNETの粉とタバスコは、もう賞味期限が怪しいですね...。


Tシャツは、ジャズの町ということで、管楽器が描かれています。


会場では、缶バッチが配られており、お土産にと言うことで多少多く頂きました。





2019年 アナハイム
この年は、Nutanix創業10周年を迎えるとても記念すべき年でした。
この年はアナハイムで開催されました。ディズニーランドも近く周辺は凄く整備されていたことが記憶しています。

.NEXT Anaheimの会場



会場はさらに広くなり、NutanixのEnterprise Cloudが世の中に浸透してきたことを感じます。この会場が満員になっていたことに驚いたのは記憶に新しいです。



なぜか、2019年のノベルティだけが、お家の中で見つかりませんでした...。
ただ、参加特典でいただけるスピーカーだけはまだ残っておりました。



この年は、.NEXTのストアがより大きくなり沢山のグッズを販売しており、会場限定のグッズも多くありました。


ストアで買ったバスタオルとマフラーは、今でも未使用のまま大切に保管しています。


Educationセンターに行くと、NCP/NCPAホルダーにはキャップをプレゼントしていました。(特に名前とか聞かれることなく、NCAPホルダーだと伝えたらそのままキャップをくれるという、チェックの甘さというか自称NCAPでも通じてしまうところが気になったのを覚えています)


今年はオンライン参加と言うことで、ノベルティや珍しいグッズに出会うことは出来ませんでしたが、来年は無事に楽しいNutanix .NEXTを開催出来るようになることを心から願っております。

Nutanix .NEXT 2020は、オンラインで、11/10まで登録をすれば無償でコンテンツを楽しむことが出来ます。

Global .NEXT Digital Experience






2020年9月1日火曜日

AOS5.18の新機能(その2):ストレージ容量の表示改善

AOS5.18からストレージの空き容量や表示方法の変更が行われました。
今日は、新しく改善されたストレージサマリーの改善について紹介致します。


Prismのダッシュボード画面にあるストレージサマリー画面が、よりわかりやすくなりました。最も大きい点は、N+1やN+2の耐障害性を意識した際に、ダウンして良いノードの分のストレージの空き容量を保持しておく必要があります。
今までのPrismでの空き容量表示では、全体のキャパシティに対して80%や90%といった閾値をもとに黄色や赤色で表示されていましたが、実際のNutanixクラスターの構成台数によって、1ノード落ちた際にも問題なく稼動できるパーセンテージは変わってきます。

以下を例にして考えてみましょう。例えば3ノードで構成されたNutanixクラスターがあります。1ノード当たりRF2で20TBの容量を提供できるように構成されています。
この場合、Nutanixクラスターとして利用できるストレージ容量は60TBですが、1ノードの耐障害性に絶えられるためには、1ノード分を差し引く必要がありますので、以下の計算式の通り、40TBまでが利用できる容量となります。

全体ノード(3ノード:20TB×3) ー 耐障害性(1ノード:20TB×1) = 利用できる容量(40TB)

となります。この場合、ストレージ容量を割合で考えると、3ノードのクラスターなので1ノード当たりのストレージ提供容量は33.3333・・・%となります。1ノードの耐障害性に絶えるためには、3ノード中2ノードで稼動できる必要があるため、以下の計算式の通り、「100%ー(100%/3)=66.6666・・・%」となります。
すなわち、2台分まで利用可能なので66.6666・・・%までが利用が可能となります。
全体ノード数(3ノード:100%)ー耐障害性ノード(100%/全体ノード:3)=利用できるストレージ容量パーセント
つまり3ノードの場合における、ストレージの利用上限値は、この構成の場合、66%までが利用可能であり、67%を超える利用量の場合、1ノードの障害に耐えられないことになります。

▼3ノード時における1ノード障害について


一方で、これが4ノードになった場合は、上記の式に当てはめると1ノード当たり25%の割合になるため、1ノード障害時には、75%までストレージを利用することができます。

▼4ノードにおける1ノード障害について



つまり、従来までのストレージですと、90%までストレージを利用していると容量枯渇とか、80%超えたら追加を考えないとといった運用を行うことが出来ましたが、NutanixをはじめとするHCI製品は、ノード障害=ストレージの部分障害と考える必要があるため、ノード数に応じて、ストレージの何%までを使って良いかが変わってきます。
Nutanixにおいては、ストレージの空き容量がN+1に耐えられなくなった場合、Data Resiliency Statusが、Criticalに変わるため耐障害性がなくなったことを知ることが出来ますが、事前にどの容量まで使って良いかは把握しておく必要があります。
今回AOS5.18から、耐障害性を考慮した際にどこまでのストレージ容量を利用して良いかが閾値の表示が出るように改善されました。

▼Storage Summaryに閾値が表示されている


実際にPrismの画面では、StorageSummaryで、このクラスターで耐障害性(N+1)を保つために利用して良いストレージの容量はどこまでかと、閾値を基準にグラフの色が変わるように変更されました。
小さな変更点かも知れませんが、ストレージの使いすぎてしまい、ノードに障害が発生してしまった際にクラスターが一時的に停止してしまうような事故を、この機能により防ぐことが可能です。(もちろん利用者側の意識がないといけませんが)

このスクリーンショットの環境では、3ノードでN+1の構成で、ストレージの使用率は閾値に近い黄色で表示されています。この環境で1ノードを追加を行うと、両々の表示がグリーンに変わったことが分ります。4ノードにおいて1ノード障害が起きてもこの使用量であれば、問題が無いことがわかります。今までの全体容量に対する使用率%ではなく、ノード数に応じて、耐障害性を考慮した使用率表示に変わっていることがこのことから分ります。

▼同じストレージ利用率で4ノード時の表示

なおこのワーニングの設定値は、Storage Summaryのギアマークから変更することも出来ます。(これは、冗長化を加味した上での利用できる容量の75%となります)


また、View Detailsをクリックすると、実際にトータルのストレージ容量、現在利用している容量、耐障害性を考慮した際に利用できる容量をそれぞれ確認することが出来ます。



HCIにおいては従来のストレージと空き容量の考え方が考え方がすこし違うところがあります。この違いに気づきやすいようにAOS5.18のPrism空はこのように、ストレージの利用率についてわかりやすい表示で、運用におけるトラブルが発生しないように工夫がなされています。






2020年8月31日月曜日

AOS5.18の新機能(その1):仮想マシンゴミ箱機能の紹介

 AOS 5.18から仮想マシンを削除した場合、24時間以内であれば復活させることが出来る機能が搭載されました。

今回はこのゴミ箱機能について見ていきたいと思います。

まずこのゴミ箱機能の基本は、以下となります。

  • ゴミ箱機能はデフォルトで有効です
  • クラスターのストレージ空き容量が重要な閾値に達しない限り、コンテンツを最大24時間保持します。

ゴミ箱機能は、デフォルトで有効になっているとのことですが、ゴミ箱機能が不要の場合、以下のコマンドをCVMで実行することでゴミ箱機能を無効にすることが出来ます。
recycle_bin -operation update_time_to_live -recycle_bin_ttl_secs -1


なお、ゴミ箱設定は、「container_name」を指定することで、ストレージコンテナごとに設定することも出来ます。
ゴミ箱を空にするタイミングは、デフォルト24時間のようですが、-recycle_bin_ttl_secsを変更することで時間を変更することも可能です。

▼ストレージコンテナ「STG01」で48時間まで仮想マシンをゴミ箱で保持するコマンド

recycle_bin -operation update_time_to_live -recycle_bin_ttl_secs 172800 -container_name STG01


ゴミ箱を空にするには以下のコマンドを実行します。
この例では、ストレージコンテナ「STG01」のゴミ箱を空にしようとしています。

recycle_bin -operation delete -container_name STG01 -delete_all 

すると、以下のようにZookeeperとのやりとりが出力されたあと、Y/Nの質問受けますので、Yを入力することでゴミ箱が削除されます。
ainer_name STG01 -delete_all
I20200830 03:17:40.660087Z  1950 medusa.cc:1275] CreateGlobalMedusaBinaryLoggerRegistry
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@960: Client environment:zookeeper.version=zookeeper C client 3.4.3
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@964: Client environment:host.name=ntnx-17sm6c100126-a-cvm
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@971: Client environment:os.name=Linux
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@972: Client environment:os.arch=3.10.0-1127.13.1.el7.nutanix.20200722.cvm.x86_64
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@log_env@973: Client environment:os.version=#1 SMP Wed Jul 22 01:48:43 UTC 2020
2020-08-30 03:17:40,661Z:1950(0x7fb8fa20ad00):ZOO_INFO@zookeeper_init@1008: Initiating client connection, host=zk3:9876,zk2:9876,zk1:9876 sessionTimeout=20000 watcher=0x55f8f1524200 sessionId=0 sessionPasswd=<null> context=0x55f8f4078040 flags=0
I20200830 03:17:40.661561Z  1950 zeus.cc:2062] recycle_bin is attempting to connect to Zookeeper
2020-08-30 03:17:40,663Z:1950(0x7fb8fa066700):ZOO_INFO@zookeeper_interest@1954: Connecting to server 192.168.XXX.YYY:9876
2020-08-30 03:17:40,663Z:1950(0x7fb8fa066700):ZOO_INFO@zookeeper_interest@1991: Zookeeper handle state changed to ZOO_CONNECTING_STATE for socket [192.168.XXX.YYY:9876]
2020-08-30 03:17:40,663Z:1950(0x7fb8fa066700):ZOO_INFO@check_events@2191: initiated connection to server [192.168.XXX.YYY:9876]
2020-08-30 03:17:40,670Z:1950(0x7fb8fa066700):ZOO_INFO@check_events@2239: session establishment complete on server [192.168.XXX.YYY:9876], sessionId=0x27428bdbfab48ff, negotiated timeout=20000
I20200830 03:17:40.670706Z  1954 zeus.cc:2124] Received new client id: 0x27428bdbfab48ff
I20200830 03:17:40.670790Z  1954 zeus.cc:617] Connected to Zookeeper instance 192.168.XXX.YYY:9876
I20200830 03:17:40.670869Z  1950 zeus.cc:341] Zookeeper client health notification enabled
I20200830 03:17:40.670938Z  1950 zeus.cc:3207] Scheduling next shuffle leadership intent routine after 240 seconds
I20200830 03:17:40.670981Z  1950 zeus_connector.cc:169] Started zeus_connector with session id 27428bdbfab48ff
I20200830 03:17:40.672344Z  1954 zeus_configuration_ops.cc:588] Established Zeus watch id 0
I20200830 03:17:40.673498Z  1954 zeus_configuration_ops.cc:697] ReadConfigurationOp(0)[watch_cbks:1 watch_id:0 convert_ssd:1 sync:0]: Found config with timestamp 1056279
I20200830 03:17:40.673553Z  1954 zeus_connector.cc:377] Received a Zeus configuration update.
Clearing all recycle bin contents for container STG01
Proceed? (y/n) y
Clearing recycle bin for container STG01
I20200830 03:17:49.262601Z  1952 tcp_client.cc:293] Setting up new connection with 127.0.0.1:2049
I20200830 03:17:49.263690Z  1952 recycle_bin.cc:140] Recycle bin DeleteAll operation completed
I20200830 03:17:49.263725Z  1950 recycle_bin.cc:458] Exiting
I20200830 03:17:49.263742Z  1950 zeus_connector.cc:183] Closing down zeus_connector with session id 27428bdbfab48ff
I20200830 03:17:49.263751Z  1950 zeus.cc:355] Destroying Zeus
2020-08-30 03:17:49,364Z:1950(0x7fb8fa20ad00):ZOO_INFO@zookeeper_close@3104: Closing zookeeper sessionId=0x27428bdbfab48ff to [192.168.XXX.YYY:9876]
I20200830 03:17:49.464782Z  1950 tcp_connection.cc:645] TcpConnection with fd 12, conn_id 0 waiting for quiescing callbacks peer info 127.0.0.1:2049:TCP
I20200830 03:17:49.464963Z  1950 tcp_connection.cc:657] TcpConnection with fd 12, conn_id 0 wait for quiescing callbacks finished  peer info 127.0.0.1:2049:TCP

標準出力の中に、オペレーションが必要なメッセージやステータスのメッセージが紛れているので見づらいのですが、メッセージを見ながら確認をしていく必要があります。

なお、Prismから仮想マシンを作成した場合、今までの画面と同じ画面で特に変更はありません。


実際にストレージコンテなのかを見ると、「.nutanix_recycle_bin」というディレクトリが新たに出来ていることが分ります。


この「.nutanix_recycle_bin」内に、削除した仮想マシンの構成情報と仮想ディスクが移動していることが分ります。

「.config」の拡張子は、仮想マシンの設定ファイルで、UUIDで表示されているのが仮想ディスクのようです。

なお、Prismを使用せず、ストレージコンテナのファイルを直接ファイル操作オペレーションで削除した場合においても、自動的に「.nutanix_recycle_bin」フォルダに移動します。


recycle_binコマンドには、実際に「-operation」に「restore」というオプションパラメーターが有り、「-source_path」と「-restore_path」のパラメーターがありファイル自体のリストアは出来るようですが、そこから仮想マシンとして再登録するオプションがまだ実装されていないようで、このためリストアにおけるオペレーションは、現行Nutanixサポートに依頼をする必要があります。




2020年8月30日日曜日

AOS 5.18の新機能を紹介

 AOS5.17がリリースされたまだ日が浅いですが、STSは3ヶ月おきのリリースがベースとなっているため、8月末にAOS 5.18がリリースされました。

AOS5.18にも多くの新機能が搭載されています。

  • Leap機能利用時のSelf Service Restore(SSR)のサポート
    Asycn DRでなくLeap機能を利用したスナップショット取得時に、SSRをサポートします。なお、NearSyncは未対応ですが、

  • ストレージコンテナのインライン圧縮のデフォルト有効化
    今まではストレージコンテナを新規作成すると、自動的に、Compression(圧縮)のチェックが有効でDelayが60でデフォルト値で表示されます。Compressionは、AOS Starterエディションすなわちどのエディションでも利用が可能ですが、Delayが0より大きい値の設定がなされると、ポストプロセス圧縮となりAOS Proライセンス以上が必要となります。そのため、AOS Starterライセンスでデフォルト値のままストレージコンテナを作成すると、ポストプロセス圧縮の設定となってしまいライセンスに抵触しているというアラートが出ていましたが、今回変更によりAOS Starterでデフォルトのコンテナ作成時に謝ってライセンスに抵触してしまうようなことは無くなりました。
    既に作成しているストレージコンテナに対して設定が変わることはありません。
    なおNutanixでは、パフォーマンスに影響がないため圧縮を有効にすることを推奨しています。

  • クロスハイパーバイザーDR(ESXi → AHV)でのNearSyncをサポート
    クロスハイパーバイザーDRにおいては、今までAsync DRでのサポートとなり最短のRPOは1時間でした。今回の変更により、NearSyncでのレプリケーションをサポートしました。

  • Nutanix Objectsでイレイジャーコーディングをサポート
    アーカイブデーターなど長期保存を目的とする利用の場合、Nutanix ObjectsによるS3互換のオブジェクトストレージ機能を利用も検討すると良いと思います。データーの長期保管となると、必要とするストレージ容量も多くなるためストレージ容量の効率的な利用が求められます。Nutanixには圧縮・重複排除の他にイレイジャーコーディング機能を保有しています。今回Nutanix Objects利用時において、ストレージコンテナにイレージャーコーディングが利用できる用になりました。

  • ゲストVM削除時の復元機能
    仮想マシンを誤って削除した場合24時間以内であれば復元する「ゴミ箱」機能が搭載されました。なお、現バージョンでは仮想マシンのリストアはNutanixサポートに依頼をする必要があります。本機能は次回に詳細にお伝えしたいと思います。

  • ストレージコンテナにおける仮想ディスク単位の消費情報表示
    いままでは、ストレージコンテナレベルでの空き容量や使用容量はわかりましたが、どの仮想マシンやVolumeGroupがどれぐらいの容量を消費しているのかを確認するには、仮想マシン一覧からそれぞれの容量を確認するしかありませんでした。
    今回PrimsのStorage画面から、ストレージコンテナごとにどの仮想ディスクがどれぐらいの容量を消費しているのかを確認が出来るようになりました。

    ▼仮想ディスクファイルごとの割当・消費容量一覧

  • ログタイムスタンプの変更
    通常利用時には気にする必要は無い機能ですが、NutanixのログはCVMのタイムゾーンで出力されるものが一部ありましたが、今回の変更で全てログはUTCタイムゾーンで記録されるようになりました。

  • NVMeドライブの活性交換時の動作改善
    AOS5.18からNVMeドライブ交換時にCVMが再起動するという仕様が変更となり、CVM再起動せずにNVMeドライブが交換できるようになりました。(CVMが再起動するのは、ディスクドライブが見えなくなった際にディスクを再度検知するためOSレベルで再起動する仕様であり、その際仮想マシンは他のCVMのI/Oパスを利用して継続稼動するため、稼動している仮想マシンにはCVMが再起動しても動作に影響はありませんでした)
    なお、本機能は、AHVのみのサポートとなります。

  • UEFIサポートの強化
    ハードウェアUEFIセキュアブートが有効になっているホストで、ESXiのセキュアブートがサポートされました。

  • NGTの下位互換サポート
    ゲストVMよりもCVMのNGTバージョンが低い場合でも、NGTを引き続き利用することができます。

  • NGTにおけるPython2からPython3への変更
    こちらも、ユーザーサイドとしては特に変わりは無いのですが、NGTのバイナリがPython3対応となりました。

  • OVAのサポート
    PrismCentaralを介して、AHV仮想マシンにおけるOVAエクスポート機能及ぶ、OVAインポートが可能となりました。
    AHV環境の場合仮想マシンを一時的に、ファイルとして保存したい場合などにエクスポートする機能が無く、サードパーティーのバックアップソフトを利用する等を行う必要がありましたが、今回の機能追加により、OVAでの吐き出しが可能となりました。

AOS 5.18には様々な機能が追加されていることが分ります。

次回以降では機能絞って特徴を見ていきたいと思います。




2020年7月24日金曜日

AOS 5.17で改善された機能・NICのVLAN切り替え

AOS 5.17がSTSとしてリリースされました。
以前の記事で紹介したとおり、どちらかというとレプリケーション周りの機能追加が多いのですが、普段の利用においても利便性が向上する機能追加が行われています。

その1つが、AHV環境における、仮想マシン稼働中の仮想NICのVLAN変更です。

AOS5.16までは、パワーオン状態の仮想マシンにおいて、NICのVLAN変更を行うことが出来ませんでした。パワーオフの場合はVLAN変更が可能ですが、acliコマンドでの実行でしかできませんでした。

しかし、AOS5.17においては、待望のPrism UIから、しかも仮想マシンがパワーオン状態であってもVLANの切り替えが可能となりました。



何気ないというか、vSphereであれば何年も前から出来ていたことですが、やっとAHV環境でも出来るようになったことは、嬉しいことです。

実際、稼働中の仮想マシンにおいてVLANの変更というのはまずあり得ないと思いますが、検証環境やネットワークの動作確認を行う際には、VLANの変更機能は必要不可欠だと思います。

Nutanixは、ユーザーの意見を常に反映する機能アップデートを行っていますので、このような小さい機能であってもリクエストを上げることで、聞いてもらえるという、Nutanixがお客様視点で製品が作られているという一面を見ることが出来るところでもあると思います。






2020年6月6日土曜日

AOS 5.17がリリースされました

2020年5月に、AOS 5.17がSTSとしてリリーされました。
AOS5.17は、たくさん新機能が搭載されていますが、特にストレージにおけるレプリケーションや冗長化の部分にフォーカスが置かれて、機能追加がなされております。
本日は、AOS5.17における主な追加機能の紹介をしたいと思います。

新しく追加された機能
  • AHVにおけるメトロクラスターサポート
  • NearSyncにて30秒の対応(今までは1分)
  • オンプレ版Leapにおける、NearSyncのサポート
  • 単一PrismCentralでオンプレLeapの構築がサポート
  • メトロ(ESXi)にて、NeaySyncのサポート
    メトロクラスターを構成した環境で、AsyncとNearSyncを追加で設定可能
  • A Sync DR/NearSyncにおけるレプリケーションネットワークの分離
    (個人的には待望の機能!LeapおよびCloudConnectは未対応)
  • Leapにおける仮想マシンに対して、固定IPをサポート
    (今までは、IAPMによる動的IPかDHCPのみがサポートでした)
  • Leapにてリカバリプラン内に、スクリプトの実行が可能に
  • Hyper-Vでのラックアウェアネスサポート
  • Prismにおける冗長性のステータス表示機能の変更
  • AES環境にて入れージャーコーディングをサポート
  • リモート拠点にある新品のNutanixをそのままイメージングできる、Foundation Centralがリリース(Prism Centralで操作)
  • スナップショットメタデーターのマージによるReadアクセスの改善
  • PrismCentralの改善
    単一PCで25000仮想マシン、300クラスターをサポート
  • CAC認証の対応
  • Volume Groupにて、Windows ゲストOSにSCSIアタッチの形式の共有ディスクをサポート
  • Nutanix Flowにて、IdentityBase(AD)によるマイクロセグメンテーションの実装

ざっくりとトピックを記載をさせて頂きました。

MetroやNearSyncは、ミッションクリティカルな現場では便利な機能ですが、普段常用する機能では無いかと思います。
一方、レプリケーショントラフィックを別のネットワークに分離できる機能は、セキュリティの側面からしても大変便利な機能だと思います。

次回以降は、気になる新機能についてすこしだけ掘り下げて見ていきたいと思います。



2020年5月10日日曜日

インターネットにつながらない環境でLCMを利用する場合 AHV編

2019年12月に、LCMをダークサイト、いわゆるインターネットにNutanixクラスターが接続されていない環境下で利用する方法をお伝えいたしました。
AOS5.16がリリースされさらにLCMが2.3になったことにより、AHVもLCMでのアップデートが推奨のアップデート方法となりました。

しかし、このAHVのアップデートですが、今までのOne Click Upgradeでは、ダークサイトであってもNutanix Support PortalからAHVのバイナリとメタデーターのJSONファイルを予めインターネットが接続できる環境でダウンロードした後、Prismからこのファイルをアップデートすれば良かったのですが、LCM2.3以降は、ダークサイトでのアップデートの手順が異なっております。

まず、以前紹介した「インターネットにつながっていない環境でLCMのアップデート方法」を元にLCMのバイナリを配置したWebサーバーを用意します。その後、My Nutanix Supportの「KB8838」を参考に現在利用中のAOSにあわせたAHVのバイナリをダウンロードします。
※本KBは、My NutanixからSupport Portalにログインできるユーザーのみ参照可能です。

2020/5/10現在、以下のAOSバージョンに合せたLCMダークサイト用のAHVバイナリが提供されています。

AOSバージョンバイナリ
AOS 5.10.10lcm_darksite_ahv-builds_el6.nutanix.20170830.396.tar.gz
AOS 5.15lcm_darksite_ahv-builds_el6.nutanix.20170830.395.tar.gz
AOS 5.16 / 5.16.1ahv_darksite_bundle_96 + 110.tar.gz
AOS 5.16.1.1host-bundle-el7.nutanix.20190916.142.tar.gz
AOS 5.16.1.2lcm_darksite_ahv-builds_el7.nutanix.20190916.158.tar.gz

AOSのバージョンに合わせてダウンロードするバイナリが異なるため、事前によく確認をしておく必要があります。

ダウンロードした、tar.gzファイルを展開し、「ahv-build」フォルダとその配下を、LCMのバイナリを配置しているWebサーバーのドキュメントルートに配置します。

この準備が出来たらPrism側のLCMで、Perform Inventoryを実行すると事で、新しいAHVのバイナリがアップデート対象として上がってきます。

今まで、バイナリをアップデートすればすぐ終わる話だったのが、LCMになることですこし手間になっているようにも感じますが、昨今は、管理系もインターネットにつないで、サポートから常に新しい情報を元に監視し疑わしい障害を早く発見するといった新しいアプローチがアメリカでは標準になりつつ有り、Nutanixもその考え方に基づいて設計されています。Nutanixクラスターがインターネットに接続できる環境の場合、LCM用のWebサーバーも必要なく、環境に合わせて必要な情報を自動で取得してきますので、ダークサイトでのLCM運用に比べかなりの手間を省くことが出来ます。
セキュリティを意識しながらもインターネットに管理系をつなぐことも今後は検討することもひとつかと感じます。





2020年5月9日土曜日

Move利用時に既存環境とNutanixクラスターが同じネットワークにいない場合の対処法(MoveでマルチNIC構成を行う)

Nutanix Moveは、既存の仮想化環境からNutanixクラスターへ仮想マシンを移行することが可能です。
このNutanix Moveはネットワークを利用して、既存の仮想環境から仮想マシンイメージを取得しNutanix側に転送する仕組みになっています。

では、既存仮想環境と新しく設置するNutanixがネットワーク的につながっていない場合、どのように移行を行えば良いかという疑問が出てきます。Nutanix Moveは、セカンドNIC構成(NIC2枚挿し)構成が可能です。
※この手法は、移行元仮想環境がHyper-Vの場合はサポートされていません。Hyper-VでNIC2枚構成を希望される場合は、「Nutanix MoveでHyper-V環境におけるNIC2枚挿し構成について」を参考にしてください。




セカンドNICを搭載した際、Moveアプライアンスの初期ウィザードでは設定内容としてあがってきませんので、手動で設定を行う必要があります。
今日は、セカンドNICの設定方法をお伝えします。
今回の環境は、Move 3.5を利用します。Move3.0.2以前の場合は一部の手順が異なりますのでご注意ください。
(なお、この手法は移行元ハイパーバイザーがHyper-Vの場合はサポートされていませんのでご注意ください)

まずは、「AHVへの引っ越しは、Nutanix Moveで(その3)」を元に、Moveアプライアンスを展開します。
Move 3.5現在、Moveアプライアンスの展開先は、AHVでもESXiの2つが選択可能です。

展開し、初期のNIC設定が終わった後、一度Move仮想アプライアンスをシャットダウンします。
その後、Move仮想アプライアンスにNICを追加し、再度Move仮想アプライアンスを起動します。
 
起動後、adminユーザーでMoveアプライアンスにログインを行います。

ログイン後、rootユーザーにスイッチします。
rs

※パスワードは、デフォルト「nutanix/4u」です。

ここで、初期に付与したNICと新たに追加されたNICの状態を確認します。
ip addr | more
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000    #新しく追加したNIC
    link/ether 50:6b:8d:2c:e2:10 brd ff:ff:ff:ff:ff:ff
    inet 192.168.XXX.YYY/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::526b:8dff:fe2c:e210/64 scope link
       valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 50:6b:8d:a2:d1:a3 brd ff:ff:ff:ff:ff:ff
4: docker0:  mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:0d:fe:93:43 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: br-4dd6ea78bbf6:  mtu 1500 qdisc noqueue state UP
    link/ether 02:42:e1:d3:47:34 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-4dd6ea78bbf6
       valid_lft forever preferred_lft forever
    inet6 fe80::42:e1ff:fed3:4734/64 scope link
       valid_lft forever preferred_lft forever
7: veth80212f5@if6:  mtu 1500 qdisc noqueue master br-4d
d6ea78bbf6 state UP
  

eth2が新たに追加されたNICであることがわかりますので、それを控えておきます。

続いて、/etc/network/interfaceを開きます。
vi /etc/network/interface
# Configured by /opt/xtract-vm/bin/configure-static-ip at Sat Oct  5 04:12:31 UTC 2019
# loopback configuration
auto lo
iface lo inet loopback

# eth0 Static IP configuration
auto eth0
iface eth0 inet static
        address 192.168.XXX.YYY
        netmask 255.255.255.0
        gateway 192.168.XXX.ZZZ

既存で初期に設定した、IPアドレスが設定されていますので、した側に以下のように設定を行います。

DHCPでIPを付与する場合
auto eth1
iface eth1 inet dhcp

固定IPアドレスを付与する場合
auto eth1
iface eth0 inet static
        address 172.16.XXX.YYY
        netmask 255.255.255.0
        gateway 172.16.XXX.ZZZ

ここで注意点ですが、デフォルトゲートウェイは1つのインターフェースにしか付与できません。
そのため、gateway項目は、eth0かeth1のどちらかにしか記載してはいけません。
それぞれに経路設定が必要な場合は、static routeを設定する必要があります。

入力後は、ネットワーク設定を再起動し新しい設定を読み込みます。
service networking restart
root@move on ~ $ service networking restart
 * WARNING: you are stopping a boot service
 * WARNING: you are stopping a boot service
 * Stopping busybox ntpd ...                    [ ok ]
 * Stopping networking ...
 *   eth0 ...                                   [ ok ]
 *   lo ...                                     [ ok ]
 * Starting networking ...
 *   lo ...                                     [ ok ]
 *   eth0 ...                                   [ ok ]
 *   eth1 ...
 * Starting busybox ntpd ...                    [ ok ]
root@move on ~ $

このような感じで、ネットワークサービスが再起動できていれば問題ありません。

再度、ipaddrコマンドでIPがNICに付与されているかを確認します
ip addr | more
root@move on ~ $ ifconfig | more
br-4dd6ea78bbf6 Link encap:Ethernet  HWaddr 02:42:E1:D3:47:34
          inet addr:172.18.0.1  Bcast:172.18.255.255  Mask:255.255.0.0
          inet6 addr: fe80::42:e1ff:fed3:4734/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7181 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6586 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8082154 (7.7 MiB)  TX bytes:7393655 (7.0 MiB)

docker0   Link encap:Ethernet  HWaddr 02:42:0D:FE:93:43
          inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 50:6B:8D:2C:E2:10
          inet addr:192.168.XXX.YYY  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::526b:8dff:fe2c:e210/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26937 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7973 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8926408 (8.5 MiB)  TX bytes:5183056 (4.9 MiB)

eth1      Link encap:Ethernet  HWaddr 50:6B:8D:A2:D1:A3
          inet addr:172.16.XXX.YYY  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::526b:8dff:fea2:d1a3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10513 errors:0 dropped:0 overruns:0 frame:0
          TX packets:323 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:793805 (775.2 KiB)  TX bytes:3130560 (2.9 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

ただしく、eth1にIPが付与されていることが分ります。

続いて、iptablesの停止とDocker Serviceの再起動を行います。
service iptables stop
svcstop
service docker restart
svcstart

eth1から、MoveのUI画面を開くことも出来ますが、eth0を利用してNutanixクラスターのターゲットストレージコンテナをマウントするため、Nutanixクラスターのインターフェイスは、eth0に向けておくことが必須となります。

これで、Nutanixと既存の移行元環境が別のネットワークであってもMove仮想アプライアンスを介して、移行を行うことが可能です。








2020年5月8日金曜日

Nutanix Move 3.5の紹介とテスト機能について

Nutanix Move 3.5が2020年4月末に公開されました。
今回のバージョンでは、バグフィックスの他に新たな機能が追加されました。
今回は新しい機能について紹介したいと思います。

<新機能>
  • AWS環境からNutanix ESXi環境への仮想マシン移行がサポートされました。
  • 仮想マシンの完全な移行の前に、ターゲット環境で移行テスト機能が追加されました。
  • VMware vSphere 6.7 Update3 の対応
  • ESXiからAHVへの移行対象ゲストの追加
    (RHEL 6.10 /CentOS 7.5~7.7/Windows Server 2019)

AWS環境からESXiへの移行は、読んで字のごとくです。
大きな点は、本番移行前にテスト機能が搭載されたことだと思います!
今回は、このテスト機能について、もう少し深く見ていきたいと思います。

Nutanix Moveで移行をする際によく言われるのは、もし失敗したら?という不安と、それを払拭するためのテストです。
失敗しないのか?という点については、どこについて失敗する可能性があるかを考える必要があります。
Nutanix Moveは、vSphereのバックアップ時に利用するAPI(VDDK)を利用して、仮想マシンイメージのスナップショット差分を取得することで、移行元の仮想マシンはパワーオンのまま仮想マシンを移行する仕組みを持っています。この場合、失敗する可能性があるとすれば、MoveアプライアンスとESXiとの疎通(ネットワーク)の問題であったり、スナップショットが既に大量にあり、VDDKのイメージの取得に失敗するなどいろいろな要因が考えられるため、簡単に失敗するしないという話の前に、Moveの仕組みを知った上で考慮点を洗い出すことが大事だと思います。

話がそれましたが、では実際に正しく動くかテストをしたいという希望に対して、Nutanix Moveは、移行に失敗しても元の仮想マシンは残っていますので、再度元の仮想マシンを起動することでサービスを継続することは可能です。しかし事前のテストのタイミングで、本番の仮想マシンが一時的であってもシャットダウンされてしまうのは、作業を行う時間も限られてしまいますし、あまりスマートではありません。
今まで、Moveを利用したいと言われる方でテストをしたいという要望を言われた場合、元の仮想マシンをクローンしてもらい、それをMoveで移行できるか試してくださいという形で案内をしておりました。元の仮想マシンには何の変更も入れることが無くテストを自由な時間で行うにはおそらくこの方法をとるのが良いかと思います。

一方で、Nutanix Moveに新たについたテスト機能は、実際に稼動している仮想マシンのデーターを移行しつつ、今移行しているデーターを元にその仮想マシンが、Nutanix上で正しく稼働するかをテストすることができます。この段階でテストで正常動作しないことが分れば、一度その移行ジョブを取り消し原因を調査する必要がありますが、本番の仮想マシンを停止すること無く判断をすることが出来ます。
このテスト機能は、AHVからAWSの移行を除く組み合わせの全てをサポートしています。つまり、ESXiからAHV、Hyper-VからAHV、AWSからAHV、ESXiからNutanix+ESXiの環境であれば、このテスト機能が利用可能と言うことになります。

実際のMoveの画面を見ながら変更点を確認しましょう。
まず、Migrationジョブ作成画面で、移行後のNutanix側に登録されたVLAN選択画面の下に、テスト用のVLANを選択する画面が追加されています。こちらは、Target Networkで選択したVLAN以外しか選択できないようになっています。(移行先の本番VLANでテストは出来ない仕様になっているようです)

移行自体の動作は今までのバージョンと特に変わることはありません。
後変更となったところは、実際の移行画面となります。

あらたに、Test Actionというメニューが追加されています。このメニューには、「Create Test VM」、「Recereate Test VM」、「Remove Test VMの3つのメニューが用意されています。
初回テストは、「Create Test VM」を選択肢、まずテストで稼動を行います。

するとこのような形でメッセージが表示されます。移行元のVMに何も影響が無いことと、本来のMoveは、移行元の仮想マシンをシャットダウンして最終のスナップショットを取得しますが、これはテスト機能で稼動するため、クラッシュレベルでのスナップショットからの起動となる旨の注意点が記載されています。
テストが実行されると、View Test VMと言う形で、Prsimのリンクが表示されます。

Prism上を見ると仮想マシン名の末尾に「-MoveTest」という文字列が付与された仮想マシンが存在していることが分ります。
自動的にパワーオンされ、既に起動しております。

仮想マシン自体も、正しく起動していることが分ります。
なお、移行元の仮想マシンがパワーオフの場合、テスト後も仮想マシンはパワーオフのままとなります。
(移行元仮想マシンのパワーステータスに応じて、移行後の仮想マシンもパワーオン、パワーオフが判断されます)


テストが終わったら、仮想マシンはそのままで、Moveの画面から、「Remove Test VM」で、仮想マシンを削除します。


ちなみに、Test Actionで、Create Test VM実行中に、Cutoverボタンを押した場合、自動的にTest VMは削除され、カットオーバー処理が行われるようになっています。

なお、Cutover後のテストは当然ながら出来ません。

テスト機能は今までもなんとか回避は出来ていましたが、手間無く手軽に本番環境に影響なくテストが出来るというのは、移行に対するハードルが下がることに違いは無いと思います。

Nutanix Moveは、移行における大変便利な機能ですが、テスト機能などちょっとかゆいところに手が届く機能が増えて生きているのは、ユーザ視点であるNutanixの良さの一面を感じます。