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の良さの一面を感じます。











2020年3月20日金曜日

AHVのUEFIの対応と注意点

AOS5.16からUEFIのSecure Bootにも対応しました。
以前に、AOS5.11でUEFIには対応していましたが、UEFIへの対応強化となります。

では実際にUEFIで仮想マシンを作るところから見ていきたいと思います。

こちらはAOS5.16.1の環境の画面ですがAOS5.11以降、Prism画面からUEFIかBIOSかのどちらかを選択するモードが出てくるようになっています。

UEFIに関してはここから、UEFIを選択するだけです。

acliで確認すると、Prismで作成するとUEFIの領域が、ストレージコンテナが、ManagementShareに作成されます。

vm.get UEFITEST1
UEFITEST1 {
  config {
    agent_vm: False
    allow_live_migrate: True
    boot {
      firmware_config {
        nvram_disk_spec {
          create {
            container_id: 8
            size: 540672
          }
        }
        nvram_disk_uuid: "b329af2f-1ad6-4698-a989-f11f87888c23"
      }
      uefi_boot: True
    }
    cpu_passthrough: False
    disable_branding: False


では、A Sync DRで他のNutanixクラスターにレプリケーションをする際にManagementShareのストレージコンテナも一緒にレプリケーション対象にする必要があるかというと、実際に動きを見たところ、ManagementShareのストレージコンテナをレプリケーション対象に入れなくても、問題なくレプリケーション及びリストア可能です。

現行UEFIでの起動に対応しているOSは、以下の通りです。
  • Windows Server 2012R2/2016/2019 (x64)
  • Windows 10 Pro/Home (x64)
  • CentOS 7.4/7.5/8.0 (x64)
  • RedHat Enterprise Linux 7.1/8.0 (x64)
  • Ubuntu 12.04.x LTS Desktop/Server (x64)
  • Ubuntu 16.04.x LTS Desktop/Server (x64)
  • Ubuntu 18.04.x LTS Desktop/Server (x64)
  • SUSE Linux Enterprise Server 12 SP3 (x64)

なお、Prism上でUEFIで仮想マシンを作成しても、セキュアブートモードにはなりません。
セキュアブートを有効にするには、acliで以下のコマンドを実行する必要があります。

vm.update 仮想マシン名 secure_boot=true machine_type=q35

secure_boot=trueと共に「machine_type=q35」の設定が必要となります。
セキュアブートが有効になると、以下のようにacliで確認するとsecure_boot:Trueと表示が追加されます。

vm.get UEFITEST1
UEFITEST1 {
  config {
    agent_vm: False
    allow_live_migrate: True
    boot {
      firmware_config {
        nvram_disk_spec {
          create {
            container_id: 8
            size: 540672
          }
        }
        nvram_disk_uuid: "b329af2f-1ad6-4698-a989-f11f87888c23"
      }
      secure_boot: True
      uefi_boot: True
    }
=中略=
    hwclock_timezone: "Asia/Tokyo"
    machine_type: "q35"
    memory_mb: 6144
    name: "UEFITEST1"

なお、セキュアブートに対応したOSは、AOS5.16時点で以下の通りです。

  • Windows Server 2016
  • Windows Server 1809
  • CentOS 7.3
  • Red Hat Enterprise Linix 7.7

  • なお、私が試した限りAOS5.16.1では、セキュアブートを有効にした状態で、Windows Server 2019はインストーラー画面の表示がされない(おそらく固まっている)事象を確認しています。
    このあたりはドキュメントに従って、アップデートを待つ必要があるようです。

    ▼UEFI起動時の仮想マシンのブート画面


    一方、セキュアブートでの起動時は、XマークではなくTianoCoreのロゴが表示されます。

    ▼セキュアブート時の仮想マシンブート画面


    また、セキュアブートを有効にした環境では、IDEバスを利用したCDROMドライブや仮想ディスクのマウントとはサポートされていません。セキュアブートの対応によりNGT(Nutanix Guest Tools)は、SATAデバイスのCDROMドライブでも対応することがAOS5.16.1で確認できております。

    UEFI利用時に1点だけ注意点があります。
    UEFI利用時にWindows OSを利用する場合、画面の解像度が800×600に固定され変更することが出来ません。これは、AHV上でVGAドライバーを提供していないことに理由があります。サーバーオペレーションの場合ほとんどがRDPやSSHなどリモートからの操作のため大きな影響はありませんが初期設定が800×600ですと、少々操作し辛い感があります。しかし、UEFIの設定画面で変更することが出来ます。

    ▼画面解像度が固定されている

    仮想マシン起動時にF2キーを押してUEFIの設定画面に入ります。
    [Device Manager]→[OVMF Platform Configuration]から[Change Preferred]で
    画面解像度を変更します。

    設定完了後、「F10」キーを押し、「Y」を押し設定を保存し、その後「ESC」→「ESC」でメインメニューに戻り、[Continue]を選択肢「Enter]キーを押します。
    そのままOSが起動しますが、まだUEFIの設定が反映されていませんので、一度OSを再起動すると新しいUEFIの設定が反映されます。


    なお、AOS5.10であってもUEFIでの設定は可能ですが、UEFIへの対応は正式にはAOS5.11から、セキュアブートはAOS5.16からのサポートとなります。
    AOS5.10でのUEFIで仮想マシンを稼動した場合、先程ご紹介した解像度の設定変更が正しく反映されない制限事項があります。

    AHVにおけるUEFIの対応は、AOS5.11以降急速に進んでいます。
    まだセキュアブートにおいてサポートされるOSが一部少ないなどの課題事項もありますが、これらは近いうちに修正されると思われます。

    Hyper-V 第2世代の仮想マシンからの移行などの場合は、UEFIでの利用が伴いますが、そういった場合も万全に対応可能です。

    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年になればと思っております。




    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つだと思います。




    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つとなるかと思います。












    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におけるダウンタイムに比べ圧倒的にダウンタイムを短くすることが出来ますので、仮想マシン移行の際は是非活用をおすすめします。









    2019年12月22日日曜日

    AHVへの引っ越しは、Nutanix Moveで HyperV編(その2)

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

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

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

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

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


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

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

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

    今回のポイントは、Hyper-V第2世代仮想マシンの移行ということです。
    Hyper-V第2世代の仮想マシンは、 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を使った移行方法のご紹介でした。

















    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への移行を行ってみましょう。