2016/12/14

Nutanix 5.0の機能概要(Beyond Marketing) パート3

本記事はNutanix Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

本記事の原文はNutanix社のPartner Innovation and Vertical Alliances, Sr. Directorを務めるAndre Leibovici氏によるものです。原文を参照したい方はNutanix 5.0 Features Overview (Beyond Marketing) – Part 3をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

また、以下のセミナーでも本記事の内容を詳しくご説明しますので、是非ご来場ください!

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線
ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

すでに東京での開催は終了していますが、大阪での開催もございます!

これは本シリーズの3番目の記事です。1番目はこちら、そして2番目はこちら。4番目はこちら

免責事項 : あらゆる将来の製品又はロードマップ情報は製品の方向性を示すことを意図しており、Nutanixが提供するあらゆる情報、コード、機能に対してコミット、お約束、法的な義務が生じるものではありません。この情報を用いて、購入を決めるべきではありません。また、Nutanixは将来の製品改善、機能が最終的に利用できるようになった際に追加での課金を行うことや、最終的に改善された製品や機能のために別途の課金を行うことを現時点では決定していません。

機能や時間軸についてのオフィシャルな情報についてはNutanixのオフィシャルなプレスリリースをご参照ください。(こちら)

以下はこのブログ記事でご紹介してきた機能です:

  • Cisco UCS B-シリーズ ブレード サーバ サポート
  • Acropolis アフィニティ と アンチ-アフィニティ
  • Acropolis ダイナミックスケジューリング (DRS++)
  • REST API 2.0 と 3.0
  • XenServerのサポート TechPreview
  • ネットワーク可視化
  • 新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)
  • ネイティブのセルフサービスポータル
  • スナップショット - セルフサービスリストアのUI
  • ネットワークパートナーインテグレーションフレームワーク
  • メトロアベイラビリティウィットネス
  • VMフラッシュモードの改善
  • Acropolis ファイルサービス 正式リリース (ESXi と AHV)
  • Acropolis ブロックサービス (CHAP認証)
  • AHVのOracle VM と Oracle Linuxへの認定
  • AHVのSAP Netweaver Stackへの認定
  • Prism サーチの改善(ブール表現のサポート)
  • I/O メトリクスの可視化
  • 1-クリックライセンシング
  • LCM – Lifecycle Manager(ライフサイクルマネージャー)
  • 追加のPrismの改善点
  • AHVの拡張性の改善
  • AHVのCPUとメモリのホットアド(Tech Preview)
  • コールドデータのアドバンスドコンプレッション
  • バックアップベンダーのためのAcropolis チェンジブロックトラッキング(CBT) 
  • 自発的なQoSによる期待通りのパフォーマンス
  • (New) NCC 3.0 の Prism への統合
  • (New) 1-ノード レプリケーションターゲット
  • (New) QoSによる混在したワークロードのサポートの改善
  • (New) SATADOMの交換ワークフローのシンプル化
  • (New) 適応型レプリカ選定によるノード混在のサポート
  • (New) 動的なイレイジャーコーディングのストライプの縮小 - ノードの削除時
  • (New) メタデータ用のノード上の利用可能な複数のSSDをメタデータディスクとしてサポート
  • (New) コンテナにおけるイレイジャーコーディング(EC)のレプリケーションファクタ(RF)の変更のサポート
  • (New) OpLogのインライン圧縮

さて、法的な免責事項に目を通したら、さぁ、初めましょう!

Prism

NCC 3.0 の Prism への統合

これまでNCCについては全てのやり取りをCVMからコマンドラインで実行する必要がありました。これはCLIに精通していないシステム管理者やGUIを好まれるお客様にとってはフラストレーションの元でした。AOS 5.0に含まれるNCC 3.0についてはNCCが完全にPrismに統合され、多くの改善点が追加されています。

  • NCCの実行にかかる時間は5分以下に
  • 既存のチェックについて多くの改善点が追加
  • バグが修正され、より堅牢なNCCインフラストラクチャに
  • 新しいプラグイン(2.3と3.0で15以上のプラグイン)
  • XenServerのサポート
  • 多くのNCCの機能がPrismから利用できるように
  • 300以上のNCCのチェックがPrism経由で管理できるように
  • 全てのチェックにアラートが関連付け
  • チェックはGUIから手動で実行可能になり、結果がダウンロード可能に
  • ログコレクターもGUIから起動できるように

Fig135

分散ストレージファブリック(Distributed Storage Fabric - DSF)

1-ノードレプリケーションターゲット

SMBのお客様は拠点のためのコスト効果の高いレプリケーションソリューションを必要とされています。AOS 5.0では単一のNutanixノード(NX-1155、1N2U、SSD2本 + HDD 10本)がNutanixクラスタの完全なるレプリケーションターゲットとして利用できるようになりました。このノードはシングルノードのクラスタで耐障害性のない、仮想マシンの起動できないノードですが、サポートされている全てのハイパーバイザのNutanixクラスタと統合しての利用が可能です。

Fig136

QoSによる混在したワークロードのサポートの改善

これは内部奥深くの改善では有りますが、複数の異なるアプリケーションを単一Nutanixノード上で異なるワークロードプロファイルで動作させた際に、システムの能力とパフォーマンスへ大きな影響を与えます。AOS 5.0はReadとWriteのIOキューを分離します。Writeが集中している(もしくはWriteがバーストした)ワークロードがRead操作を阻害しないことを保証、またはその逆を行います。この実現のために、アドミッションコントローラーとOpLogのキューが単一のフェアに重み付けされたキュー、優先順位伝播、最適化されたディスクキューへと置き換わっています。

詳細をご紹介して惑わせるつもりはありません。これは最初テクニカルな内容になり、おそらく別の記事で紹介することになると思います。ですが、この新しい機能はシステムがストレス下にある際にパフォーマンスとI/Oの信頼性を含むIOパス全体を通してパフォーマンスとI/Oの優先順位が維持されることを保証します。

Fig137

SATADOMの交換ワークフローのシンプル化

ホストのブートディスク(SATADOM)の交換は長時間に渡る、Nutanixのシステムエンジニアが行わなければならないマニュアルでの手順が含まれます。AOS 5.0はシステム管理者がPrism内で(ほとんど)ワンクリックで起動できるワークフローによってこれを自動化し、シンプル化します。

Fig138

適応型レプリカ選定によるノード混在のサポート

クラスタのバランスとパフォーマンスについて埋め込まれたもう一つの重要な機能です。AOS 5.0はドライブのキャパシティとパフォーマンスの利用状況を元にスマートにデータをコピーし、常に一定のパフォーマンスレベルと最適化されたリソースの利用率をノードが混在したクラスタにおいても提供します。例 : 通常ノード+ストレージヘビーノード またはNX1000+NX3000ノード。

スマート配置によってそれぞれのディスクのディスクの利用率とパフォーマンス状態を用いて、ディスクフィットネス状態をクラスタ内に作成します。このフィットネスの値はディスクの利用率のパーセンテージとディスクのキューの長さ(ディスクに対して操作中のIO操作の数)の関数として表されます。さらにデータ書き込み用のディスクは振る舞いが固定しないように重みのある乱数投票を用いて選択されます。

Fig139

動的なイレイジャーコーディングのストライプの縮小 - ノード削除時

イレイジャーコーディング(EC)はデータを細切れに分解して展開、冗長性のためのデータによってエンコードし、別々の場所やストレージメディアに保管することでデータ保護を実現する方法です。それぞれのNutanixのコンテナはレプリケーションファクタ(RF)を定義してRF2またはRF3でデータの信頼性と可用性を確保しています。EC-Xについて詳しくはこちら(リンク先は英語)をご参照ください。

AOS 5.0以前はクラスタにECコンテナがある場合にはノードの削除はある意味で制限事項が有りました。これはECのストライプがクラスタ全体に分散しているためです。ノードを削除する場合にはRFが最高で2の場合、最低7ノード、RFが最大で3の場合は最低9ノード必要でした。これを解決するためにはコンテナのECをオフにし、長時間をかけてECではない状態へと変換しなくてはならず、また、クラスタに十分な空き領域が必要でした。

AOS 5.0ではノード削除時もECでの保護を維持しつつ、保護の劣化のオーバーヘッドも限定的にすることが出来ます。ノードがクラスタから削除された場合、動的にECのストライプサイズを減らし、新しノードがクラスタに追加された際にECのストライプサイズを自動的に増やすのです。 

メタデータ用のノード上の利用可能な複数のSSDをメタデータディスクとしてサポート

AOS 5.0はノード内の利用可能なSSD全体(最大で4台)にメタデータを自動的に分散します。複数のSSDへのメタデータの自動的な分散はメタデータディスクを他のシステムコンポーネントが利用するようなピークイベント時のRead/Writeのプレッシャーを緩和に役立ちます。Read/Write負荷を分散することでIOPSが改善、レイテンシも小さくなり、単一SSDでのボトルネックを排除します。もう一つのメタデータ書き込み分さんのメリットはSSDメディアデバイスの摩耗を均一化することが出来ることです。

Fig140

コンテナにおけるイレイジャーコーディング(EC)のレプリケーションファクタ(RF)の変更のサポート

イレイジャーコーディング(EC)はデータを細切れに分解して展開、冗長性のためのデータによってエンコードし、別々の場所やストレージメディアに保管することでデータ保護を実現する方法です。それぞれのNutanixのコンテナはレプリケーションファクタ(RF)を定義してRF2またはRF3でデータの信頼性と可用性を確保しています。EC-Xについて詳しくはこちら(リンク先は英語)をご参照ください。

AOS 5.0ではEC-Xはイレイジャーコーディングが有効なコンテナに対してレプリケーションファクタ(RF)の変更が出来るようになりました。これによってデータ保護のレベルをアプリケーションライフサイクルに合わせて変更したいと考えるお客様はより大きな柔軟性を持って利用ができるようになります。ECが有効なコンテナはRF3からRF2又はその逆へと変更が可能で、ECの円コーディンすは自動的にそれに会うように変更されます。

Fig141

OpLogのインライン圧縮

AOS 5.0では、ランダムなWriteはOpLogへ格納される前に自動的にインラインで圧縮されます。OpLogはファイルシステムのジャーナルのようなもので、ランダムなWriteのバーストを取り回すための一時的な領域として作成されています。ここに格納されたWriteは結合されて、シーケンシャルにエクステントストアのデータへと取り込まれます。

動的な圧縮によって、Nutanixのクラスタはスペース利用率が改善し、継続するランダムWriteのバーストのためのOpLog領域の取り回しを改善します。OpLog領域は継続するランダムなWriteのバーストをより長い時間吸収し続けることが出来るようになったのです。

Fig142

以上が AOS 5.0 の莫大なリリースの中のパフォーマンス、信頼性、可用性、サポート性、それからユーザーエクスペリエンスについての主な改善点です。ほかにも小さな機能がリリースには含まれていますが、それはこの記事でご紹介していくには小さすぎるものです。

PM、R&D、QA、リリース管理、そしてサポートチームのこれらの「ファンタスティック」なプロダクトリリースを提供するための膨大な努力に敬意を評したいと思います。彼らは顧客、そしてパートナーへ私が知りうる限り今日のマーケット内で遥かに抜きん出たHCIプロダクトをもたらすために継続的に革新のための努力を続けています。本当にありがとう!

さて、みなさんはご自身にいつAOS 5.0へワンクリックでアップグレードするか、検討をし始めてください。リリース管理の列車は私にはコントロールできませんし、正確な日付を公開することも出来ません。ですが、それは間近です。さぁ、ご期待ください!!

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Advent Calenderに参加している都合で公開が遅れますが、翻訳時点(12月6日)ではまだAOS 5.0はリリースされていません。今回は本家更新と同時に訳し始めましたのでタイムリーに公開できるので一安心です。

前回、前々回はプラットフォーム化やUX、ストレージとしての新機能がメインでしたが今回は、内部アーキテクチャの変更に関連する内容が多く含まれています。IOキューの分散のチューニングやインテリジェントなレプリカの選択など、マニア受けとは思いますが、逆にこんなにもマニアック(正確に表現すると緻密に)に作り込まれたHCIも無いと思います。さぁ、5.0のリリースを待ちましょう。

2016/12/12

最新鋭、IBM FlashSystem A9000を大解剖!

IBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。


驚きのデータ削減!あらゆる電力喪失に対応する究極の電源機構!
何処をとってもワンランク上のA9000ですが性能も機能も一味違います!!
その噂の真相を確かめるべく、検証も次のステージへっ。

7vocbqxlurq9an61481180153_148118042


ここからはお待ちかねのA9000の持つ機能や性能について
さらに切り込んでいこうと思うっ♪


で、今回はズバリ QoS ですっ♪

クラウド基盤好きには、ハズせないマストアイテムがこのQoS
このA9000!、次のスケジュールもパンパンで、お借りできる期間もあとわずかっ!
限られた時間内(いろいろな検証の合間を縫ってこっそり決行っ!)に出来る限りの検証をおこなってみたよっ♪

ちなみにQoSってなにっ?って人もいると思うので簡単に説明しようっ。
QoSとは Quality of Service(クオリティ・オブ・サービス) の略でザックリ言うと
その名の通り、「サービスの品質!」 要は「ユーザーを満足させられる度」みたいな意味になりますっ。

したがって、ここで言うQoSは「ストレージアクセスの品質」ですねっ♪
例えば、「社内で野放しのワークロードが蔓延りクリティカルアプリケーションに影響がでてる!」のような
他の利用者の大きなI/Oに影響を受けるいわゆる“ノイジーネイバー”問題っ。
QoS 機能はこういった問題を解消するために無くてはならない機能っ!。

A9000/A9000Rの
QoS機能は、接続先ごとのプライオリティーに応じて
柔軟できめ細やかな設定が可能ですっ。
例えばこの図ように「帯域」または「IOPS」を設定したり、また「その両方」を設定することもできます。
もちろん単一ボリューム単位だけでなく、複数のボリュームでシェアしたり
ストレージプール単位での設定だって出来ちゃいますっ♪

A9000qostest001


更にA9000/A9000Rは管理アカウントまで独立したマルチテナンシー機能も搭載され
クラウド基盤、クラウドサービス、そして流行のVDI環境にも最適な一台です!!

それでは、A9000の QoS機能の検証結果をご覧くださいっ♪

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

検証が進むにつれ

筆者はこの「グリッドコントローラー」の完成度の高さに驚いているっ。
特にパフォーマンスに関しては、驚きの結果(本当に想定外です。)を次々とたたき出してますので

そのへん、次回にでもお見せできればと思いますっ。


                        by:まいけル
        

VMware ESXiのロック機構とフリーズした仮想マシンの強制停止方法

本記事はvExperts Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はVMware ESXi locking and how to kill a frozen VMをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。VMware社製品についてはこちら

このブログの記事はフリーズした仮想マシンの強制停止方法についての内容です。テクニカルサポートとして勤務していると「何かがおかしい」としか言いようのないようなケースに出くわすことが有ります。これはストレージの問題であったり、特定のESXiで動作中のプロセスが他の多くの理由からファイルをロックしているということだったりします。この記事では様々なトラブルシューティング、例えばどのホストがロックを取得しているか、APD(オールパスダウン)が起こってはいないか、PDL(Parmanent Device Loss - 恒久的なデバイスの喪失)が起こっていないかなどのテクニックに続けて、どのように仮想マシンを強制停止するか様々な方法を体系立ててご紹介していきます。

まず最初は仮想マシンがどのように動作しているかを見てみましょう。以下の図はESXiの内部の一般的なプロセスを説明したものです:

Fig143

図1: ESXi内部のプロセス

これらのプロセスはそれぞれが別々のコンテキスト(context)から来ているため、別々のグループに分類することが出来ます。左上では仮想マシンがユーザーワールドで動作しているのがわかります。続いて幾つかのホストプロセスが動作していますが、ここでは2つだけを例に取り上げています: Hostdとシェルです。

ESXi シェル

ESXiがLinuxベースのものではないということを理解しておくことが重要です。これは最近ではあまり耳にしなくなりましたが、ほんの少しまでは多くの人々がESXiをLinuxベースだと勘違いして色々と試行錯誤したという話をしていました。理由は単に大抵のシェルコマンド(grep, less, more, ps, catなど)が利用でき、SSHでリモートアクセスしたときの挙動が似ているからというだけだったりするのです。ESXiがLinuxベースではないのだったら、どうしてこのようなLinux/Unix由来のコマンドが使えるんだい?それはとても簡単です。単にVMwareが「Busybox」と呼ばれるソフトウェア実装を利用することにしたからです。これはVMwareによる軽量なシェル実装で、典型的なシェルコマンドの実行をおこないます。BusyBoxはユーザーワールドのプロセスとしてVMKernel上で動作します。つまり、基本的にはWindows上のcygwinに似たようなものです。さて、これで何故コマンドがシェルの中で動作するのかがわかりました。Busyboxのおかげです。

"ps"(process status/プロセスの状態)コマンドを利用すると、特定の仮想マシンのサブコンポーネントがどのような状態かよくわかります。仮想マシンがフリーズしてしまった時、以下の2つを知ることが重要です:

  • 仮想マシンのステータスはどうなっているか?
  • その仮想マシンのロックを保持しているのは誰(何)か?
  • 問題がカーネルなのか、ストレージスタックなのか、それを知るためのコマンド(Commands in Flight - CIF)があるか?

フリーズした仮想マシンを強制停止する

フリーズした仮想マシンの強制停止の方法は多くあります。以下では4つの例を挙げてどのように仮想マシンを強制停止するかをご紹介します。例を上げながら、強制停止する方法をどのように適切なデータで特定しながら行うのかご紹介していきます。どのツールを利用するのが良い、悪いはなく、私は単に何が可能なのか、そのヴァリエーションをご紹介したいと思います。強制終了のパートのあと、更に、VMFSとNFSのロック機構についてもいくらかご紹介致します。

  • シェルツール (ps と kill)
  • esxcli
  • vim-cmd
  • ESXtop
  1. “PS”を“KILL”と組み合わせる

仮想マシンの状態を知るために、以下の"ps"コマンドを利用します(この例では仮想マシン名はam1ifvh029です)。ご覧のとおり、この仮想マシンは8つのvCPUを持つことがわかります。これは8つのvmm0~7、そして同じくvmx-vcpu-0~7と8つの仮想スレッドがmksとsvgaのスレッド以外に存在することからわかります。最後の列はグループID(GID)を示しており、これがメインとなるプロセスです。

~ # ps -jv  | egrep "WID|am1ifvh029"
WID      CID      WorldName                     GID
645172   0        vmm0:am1ifvh029               645137
645174   0        vmm1:am1ifvh029               645137
645175   0        vmm2:am1ifvh029               645137
645176   0        vmm3:am1ifvh029               645137
645177   0        vmm4:am1ifvh029               645137
645178   0        vmm5:am1ifvh029               645137
645180   0        vmm6:am1ifvh029               645137
645181   0        vmm7:am1ifvh029               645137
645219   645137   vmx-vthread-13:am1ifvh029     645137
645220   645137   vmx-mks:am1ifvh029            645137
645221   645137   vmx-svga:am1ifvh029           645137
645222   645137   vmx-vcpu-0:am1ifvh029         645137
645223   645137   vmx-vcpu-1:am1ifvh029         645137
645224   645137   vmx-vcpu-2:am1ifvh029         645137
645225   645137   vmx-vcpu-3:am1ifvh029         645137
645226   645137   vmx-vcpu-4:am1ifvh029         645137
645227   645137   vmx-vcpu-5:am1ifvh029         645137
645228   645137   vmx-vcpu-6:am1ifvh029         645137
645229   645137   vmx-vcpu-7:am1ifvh029         645137
プロセスを終了させるためにはkillコマンドを-9オプションとともに利用します。もしもkillコマンドの別のオプションについて詳しく知りたい場合にはこちらをご参照ください。基本的には-9はカーネルがプロセス自身に何も通知を行わずに終了を行うという意味になります。これは理論的にはプロセスが何をしているかによってはデータを喪失する可能性があり、終了方法ではもっともハードなものになります。もちろん最初は"kill -1"(ハングアップシグナルをプロセスに送る)、"kill -2"(CTRL+Cと同じ)を試した後に行うのが良いでしょう。
~ # kill -9 645137

"kill"コマンドはそれが出来てしまう場合には何も確認を返してこずにプロセスを終了させてしまいます。psコマンドでもう一度プロセスの動作を確認すると、プロセスIDがなくなっているという事になります。

  1. “ESXCLI VM PROCESS”を使う

ESXi上ではesxcliコマンドでハイパーバイザーの低レベルなインフラストラクチャの管理を行うことが出来ます。この先にご紹介するvim-cmdコマンドとは異なり、これは完全にESXiのその下のインフラストラクチャにフォーカスしたコマンドです。このコマンドはただひとつのコマンド(esxcli)に見えますが、様々なネームスペースを利用した広範なサブコマンドをもっています。ありがたく、また以前のesxcfg-コマンドよりも優れていることには、これはツリー階層構造にまとめられていることです。シェルにコマンドを入力し、いつでも利用可能なすべてのオプションを参照することが出来ます。このVMware KB: 2012964でよく使う組み合わせのコマンドを見つけることが可能で、esxcliとvim-cmdとPowerCLIがどのように違っているのかを見ることが出来ます。プロセスを停止させる前にそのプロセスがどの状態になっているのかということを確認してください。esxcliについてはSteve Jin氏によって書かれた素晴らしいブログの記事もあります。

~ # esxcli vm process list | grep -i -A 4 am1ifvh029
am1ifvh029
 World ID: 645172
 Process ID: 0
 VMX Cartel ID: 645137
 UUID: 42 21 23 10 79 c5 62 80-9b 06 74 21 81 9a fc 57
 Display Name: am1ifvh029
 Config File: /vmfs/volumes/55883a14-21a51000-d5e9-001b21857010/am1ifvh029/am1ifvh029.vmx

仮想マシンを強制停止するには"World ID"を利用しなくてはなりません。Worldを強制停止するには別のオプション(--type または -t)が用意されています:

  • soft
  • hard
  • force

~ # esxcli vm process kill -t=soft -w "645172"

なにもオプションを指定しない場合、標準では"soft"にて実行されます。"hard"または"force"を試してみてください。見ての通り、最初の例で"ps"コマンドで見たメインのプロセスIDとワールドIDは必ず同じものになります。これはいつもvmm0のIDです。

  1. “VIM-CMD”を利用して仮想マシンを強制停止する

もう一つの仮想マシンの状態を確認して、停止を行うコマンドはvim-cmdです。これは「hostd」上に実装されており、ESXiとhostdとが統合されているAPIとほとんど同じように利用することが出来ます。vim-cmdは多くの運用タスクにも利用することが可能です。Steve Jin氏によるもう一つのesxcli同様に素晴らしい記事はこちら
ESXi内部のvim-cmdは/bin/vim-cmdに格納されており、これ自身は実際にはhostdへのシンボリックリンクです:
~ # ls -l /bin/vim-cmd
lrwxrwxrwx    1 root     root    10 Mar  4  2016 /bin/vim-cmd -> /bin/hostd

vim-cmdにはいくつかのサブコマンドが有ります。それが何であるかを知るためには単にvim-cmdとシェルに打ち込めばすみます:

~ # vim-cmd

Commands available under /:

hbrsvc/       internalsvc/  solo/         vmsvc/

hostsvc/      proxysvc/     vimsvc/       help


見ての通り、7つのサブコマンド(とhelp)があります。それぞれが何のためにあるのかが分かりますし、ESXiの内部にどれだけの機能やオプションが取り込まれているのかを想像することも出来ます。svc(サービス)を取り除きたいのであれば、基本的にそれぞれのコマンドを利用します:hbr、internal、solo、vm、host、proxy、vimそしてhelpです。実際にはinternalsvcはほんとうの意味のESXiの内部APIではないということは覚えておいてください。

今は仮想マシンについて何らかの作業をしようとしていますので、"vmsvc"コマンドを使うということになります。vim-cmd vmsvcと打ち込むことで以下の結果を得られます :
~ # vim-cmd vmsvc

Commands available under vmsvc/:

acquiremksticket                 get.snapshotinfo
acquireticket                    get.spaceNeededForConsolidation
connect                          get.summary
convert.toTemplate               get.tasklist
convert.toVm                     getallvms
createdummyvm                    gethostconstraints
destroy                          login
device.connection                logout
device.connusbdev                message
device.ctlradd                   power.getstate
device.ctlrremove                power.hibernate
device.disconnusbdev             power.off
device.diskadd                   power.on
device.diskaddexisting           power.reboot
device.diskremove                power.reset
device.getdevices                power.shutdown
device.toolsSyncSet              power.suspend
device.vmiadd                    power.suspendResume
device.vmiremove                 queryftcompat
devices.createnic                reload
get.capability                   setscreenres
get.config                       snapshot.create
get.config.cpuidmask             snapshot.dumpoption
get.configoption                 snapshot.get
get.datastores                   snapshot.remove
get.disabledmethods              snapshot.removeall
get.environment                  snapshot.revert
get.filelayout                   snapshot.setoption
get.filelayoutex                 tools.cancelinstall
get.guest                        tools.install
get.guestheartbeatStatus         tools.upgrade
get.managedentitystatus          unregister
get.networks                     upgrade
get.runtime


今回は仮想マシンの強制終了ですから、実際のvmidの状態を見る必要があります:

~ # vim-cmd vmsvc/getallvms | grep -i 'vmid\|am1ifvh028' | awk '{print $1,$2}'
Vmid Name
4    am1ifvh028
現在の電源状態を得る場合には以下のコマンドを使います:
~ # vim-cmd vmsvc/power.getstate 4

さて、結果として、仮想マシンが動作しているというアウトプットが得られました。

Retrieved runtime info

Powered on

vim-cmdを利用して仮想マシンの電源を切るには以下のコマンドを実行します:

~ # vim-cmd vmsvc/power.off 4

  1. ESXtopを利用して仮想マシンを強制停止する

以下のコマンドを利用してesxtopユーティリティを起動します。
  1. esxtopを実行する(esxtopはCPU表示で起動します、"c"を押すことで別の表示からCPUリソース利用状況の画面へ戻ってくることが出来ます)
  2. "Shift+v"を押すことで、仮想マシンの表示へと限定することが出来ます。これによって時々多くのプロセスが表示されてしまい、仮想マシンについて全く見えないということを防ぎ、可読性が良くなります。
  3. "f"をおして、表示されるリストのフィールドを表示します。
  4. "c"をおして、"Leader World ID"の列を追加します。これはどの仮想マシンを強制停止するのか見極めるために必要です。
  5. 名前とLeader World ID(LWID)から目的の仮想マシンを特定します。
  6. "k"を押します。
  7. そうすると強制停止するWorld(WID)を聞かれます。ステップ5のLWIDを入力し、エンターを押します。
  8. 数秒の後、プロセスが消えてなくなります。

ESXiのロック機構

ですが、上のすべての選択肢が役に立たなかったらどうしたら良いのでしょうか?偶然に、他のホストが仮想マシンをロックしてしまったのでしょうか? もしも仮想マシンが応答しているものの、表示はされており、アクセス不能状態になっている場合には仮想マシンが現在動作しているホストがロックを保持している事になります。この場合、上のすべての方法は動作しません。たまたま、他のホストがロックをまだ保持したままになっているのです。過去に仮想マシンがどのホストで動作していたかということを知ることは常に重要な事です。以下のコマンドでどこに仮想マシンが登録されていたかということをvmware.logsから知ることが出来ます。

~ # find /vmfs/volume -name <vmname>
/vmfs/volumes/<DatastoreUUID>/<vmname>

findコマンドのあとは、当該のディレクトリへと移動するか、grepで検索を行います:


 # grep -i hostname vmware*

vmware-188.log:2016-08-11T14:45:26.065Z| vmx| I120: Hostname=am1ifvh004
vmware-189.log:2016-08-25T14:10:15.054Z| vmx| I120: Hostname=am1ifvh003
vmware-190.log:2016-09-02T01:39:45.934Z| vmx| I120: Hostname=am1ifvh003
vmware-191.log:2016-09-13T05:31:17.699Z| vmx| I120: Hostname=am1ifvh003
vmware-192.log:2016-09-13T15:55:42.495Z| vmx| I120: Hostname=am1ifvh003
vmware-193.log:2016-10-07T15:59:35.317Z| vmx| I120: Hostname=am1ifvh004
vmware.log:2016-10-10T17:04:38.627Z| vmx| I120: Hostname=am1ifvh003

仮想マシンが2016-10-10T17:04:38.627Zから am1ifvh003 ホストで動作していることがわかります。

どのデータストアで仮想マシンが動作していた家を見つけるもう一つの方法は既にご紹介したesxcliコマンドです。クラスタ内のデータストアにアクセス可能なホストのうちの一つから以下の例を使って、どこに仮想マシンが登録されているのか見ていきます。vCenterがダウンしている場合には仮想マシンが最後にどこにいたのかを知るためには上の例を使ってください。.vmxファイルがどこにあるのかは、このファイル自身がESXiからの.lckファイルになっているので2通りの方法があります:

  • esxcliでどこに構成ファイルがあるのかを探す:

~ # esxcli vm process list | grep -i -A 4 <vmname> | grep -i 'Config File' | awk '{print $3}'

--> /vmfs/volumes/<DatastoreUUID>/<vmname>/<vmname>.vmx

  • プロセスが半死の状態で、有益な情報を得られない場合にはlsofコマンドがもう少しだけ助けてくれる場合があります。
~ # lsof | grep -i <vmname>.vmx.lck | awk '{print $NF}'

--> /vmfs/volumes/<DatastoreUUID>/<vmname>/<vmname>.vmx.lck

VMFSのロック機構の説明

  1. 最初はチェックしたい仮想マシンのディレクトリへと移動し、誰がロックを保持しているのかを見ます。
~# cd /vmfs/volumes/<DatastoreName/<UUID>/<vmname>/
  1. vmkfstools -D を利用して2つのことを確認します:
  • どのMACアドレスがロックを保持しているか
  • そのファイルがどのオフセットを保持しているか
~# vmkfstools -D <vmname>.vmx.lck
Lock [type 10c00001 offset 189607936 v 46492, hb offset 3723264
gen 3377, mode 1, owner 57f7c8e2-8f5d86e3-efc8-001b21857010 mtime 110695
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 438, 118>, gen 46491, links 1, type reg, flags 0, uid 0, gid 0, mode 600
len 0, nb 0 tbz 0, cow 0, newSinceEpoch 0, zla 4305, bs 8192
  1. 最初の簡単な方はOwner IDの最後の部分001b21857010を確認することです。これはロックを保持しているホストのNICの一つのMACアドレスに関連しています。"esxcli network nic list"コマンドを利用して、誰がそのNICを保持しているのかを調べることが出来ますし、c#のvSphereクライアント、Webクライアント、もしくはシェルでも誰が<vmname>.vmx.lck ファイルのオーナーなのかを確認できます。
~# esxcli network nic list | awk '{print $1,$8}
Name Status
------ -----------------
vmnic0 38:63:bb:3f:19:48
vmnic1 38:63:bb:3f:19:49
vmnic2 38:63:bb:3f:19:4a
vmnic3 38:63:bb:3f:19:4b
vmnic4 00:1b:21:85:70:10
vmnic5 00:1b:21:85:70:11
  1. 2つ目のオプションはowner IDがゼロとして表示された際に利用するものです。この場合、<vmname>.vmx.lckファイルのオフセットを利用します。以下のコマンドを利用してください:
~# hexdump -C /vmfs/volumes/<datastore>/.vh.sf -n 512 -s <offset>
データストアは仮想マシンが動作しているデータストアです、ですから、一段戻ってデータストアレベルで実行してください。オフセットの値は以前のコマンド(上では 3723264)です。
  1. アウトプットの16進数のオフセット(黄色にハイライトしてあります)を利用してESX/ESXiホストのMACアドレスとロックの状態を調べることが出来ます:
~#  hexdump -C /vmfs/volumes/<datastore>/.vh.sf -n 512 -s <3723264>
0038d000  02 ef cd ab 00 d0 38 00  00 00 00 00 31 0d 00 00  |......8.....1...|
0038d010  00 00 00 00 fa 0f e1 f5  ee 00 00 00 e2 c8 f7 57  |...............W|
0038d020  e3 86 5d 8f c8 ef 00 1b  21 85 70 10 81 d1 0c 01  |..].....!.p.....|
0038d030  0e 00 00 00 3d 04 00 00  00 00 00 00 00 00 00 00  |....=...........|
0038d040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0038d200

7番目から12番目までのバイトがMACアドレスです :00 1b  21 85 70 10

それから"esxcli network nic list"を利用してそのオーナーを調べます。これが特定のホストの物理NICのものになります。こうして、仮想マシンが他のホストに登録されており、ロックされていることが確認できればロックを保持しているホストへと仮想マシンを再度移動させて、仮想マシンを起動させることが出来ます。DRSをマニュアルにしておくということを忘れないで下さい。そうしておかないと仮想マシンは他のホストで間違って起動されてしまいます。ここまでの全てができなかった場合、最終的な手段としてはロックを保持しているホストの再起動になります。

NFSのロック機構の説明

NFSの場合には誰がロックを保持しているのか問うことを確かめるにはちょっと事情が異なります。これはファイルベースのプロトコルですから、当たり前のことです。

  1. 仮想マシンのディレクトリへと移動します。( "esxcli vm process list"コマンドなどで同様にどこに仮想マシンがいるか見つけられます)
  1. VMFSとは異なり、ファイルでのすべての操作は対応する .lckファイルに対してのものになります。VMDKの数が少ない仮想マシンの場合でも、そこそこの数の .lckファイルが表示されます。ですからどれが.vmx.lckなのかを見つけなくてはいけません。".lck-3409000000000000"を例として取り上げましょう。
~# ls -lA | grep .lck-
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-3409000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-3d01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-4801000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-5301000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-5e01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-6901000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-7401000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-7f01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-8a01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-9501000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-a001000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-ab01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-e201000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-f208000000000000
  1. hexdumpコマンドで各.lckファイルのホスト名を調べなくてはなりません。
~# hexdump -C .lck-3409000000000000
00000000  fd 79 97 00 00 00 00 00  23 01 cd ab ff ff ff ff  |.y......#.......|
00000010  01 00 00 00 61 6d 31 69  66 76 68 30 30 33 00 00  |....am1ifvh003..|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 57 ac 79 10  71 18 c3 9e f3 16 00 1b  |....W.y.q.......|
00000040  21 85 70 10 00 00 00 00  00 00 00 00 00 00 00 00  |!.p.............|
00000050  00 00 00 ff                                       |....|
00000054
  1. 上の例では、このロックファイルがam1ifvh003で保持されています。これでどのホストがこの.lckファイルを持っているのことがわかりました。しかし、.lck-3409000000000000がどのファイルのためのロックなのかがわかりません。今度はエンディアンを以下の図にあるようにひっくり返さなければなりません。

    Fig144

図2: ビッグエンディアンからリトルエンディアンへの翻訳
  1. 次のステップは16進数から10進数への変換です。今回のサンプルでは、エンディアンは必要のない0で多く埋め尽くされています。翻訳はこの通り: 0x934 = 2356 (10進数)
  2. さて、続いて以下のコマンドでどのinodeを参照しているのかを調べます:
~# stat * | grep -B2 2356 | grep File
File: am1ifpt002.vmx.lck

つまり、最初のロックファイルは<vmname>.vmx.lck ファイルということになります。

  1. このコマンドを活用して、自動的に同じことをESXi上で行うことも出来ます。(この例では、エンディアンをひっくり返す必要もなくなります):
~# stat * | grep -B2 `v2=$(v1=.lck-3409000000000000;echo ${v1:13:2}${v1:11:2}${v1:9:2}${v1:7:2}${v1:5:2});printf "%d\n" 0x$v2` | grep File
File: am1ifpt002.vmx.lck

結論

仮想マシンがフリーズしてしまうのには数多くの理由が考えられます。誰がロックファイルを保持しているのかを様々な方法で見つけ出すことができれば、仮想マシンをどのように強制終了させるのか、フリーズした仮想マシンの問題をどのように解決するのか、多くの場合の糸口を見つけることが出来ます。もちろん、最初にご説明したようにストレージシステムやSCSI予約の問題、ストレージシステムのバグによる嘘のinode番号、などが原因ということも有ります。私の記事が気に入った、もっといい提案や推奨したい方法があるなど、いつでもお気軽にご連絡ください。

記事担当者: マーケティング本部 三好哲生 (@miyo4i)

今回はvExpertのAdvent Calenderということで、普段は絶対に訳さないようなテッキーな内容をお届け致しました。実は結構このあたり、お客様で発生したトラブルでPernixDataが悪さをしているという嫌疑をかけられ、その原因調査などで実際に使ったテクニックなんかも含まれていたりして。

いずれにしても、仮想マシンのフリーズ、あまり出くわしたくない事象ですが、万が一出くわしてしまった場合、盲に再起動するのではなく原因を調べ、再発を防ぐために何らか情報が欲しいものです。今回の情報はおそらく他にはないレベルでこれを説明した内容でしょう。Guidoさん、いつもありがとう!

2016/12/08

vRealize Network Insightができるネットワーク仮想化の見える化

皆さん、こんにちは。ソリューションアーキテクトをしている工藤です。この記事はvExperts Advent Calendar 2016に参加しています。

今日はは8月にリリースされたvRealize Network Insightを紹介します。
vRealize Network Insightは元々はスタートアップベンダーであるArkin社を2016年6月に買収して、vRealizeブランドとして製品化されたものになります。画面だけではなかなか伝えきれないこともあるため、各機能の動画を紹介しています。動画をご覧頂きvRealize Network Insightができることを理解いただければ幸いです。

■vRealize Network Insightとは?

vRealize Network Insightは、ざっくり言うとネットワーク版vRealize Operations Managerということができます。サーバ仮想化のリソースを見える化するのがvRealize Operations Managerだとすると、ネットワーク仮想化のリソースを見える化するのがvRealize Network Insightになります。何とかInsightというとvRealize Log Insightの印象がありますが、できることはvRealize Operations Managerに近いのです。

ざっくり言ってしまいましたが、もちろんvRealize Operations Managerだとネットワークの状態がわからない、vRealize Network Insightでは仮想マシンの状態がわからないといったことはありません。あくまでもvRealize Operations ManagerはvSphereのホストや仮想マシンを中心として、vRealize Network Insightはネットワークを中心にそれぞれ必要な機能にフォーカスしているだけですので安心してください。

vRealize Operations Managerは、性能情報仮想基盤のインベントリ情報を組み合わせて見える化します。

1_2

vRealize Log Insightは、ログ情報見える化します。

2_2

vRealize Network Insightは、パケット仮想基盤のインベントリ情報などを組み合わせて見える化することで仮想基盤のネットワーク管理にかかる運用工数を改善する製品です。

3

ではvRealize Network Insghtが実際にどんなアーキテクチャで、ネットワークの見える化を実現しているのか見ていきたいと思います。

■vRealize Network Insightのアーキテクチャ

vRealize Network Insightは現在2つの仮想アプライアンスから構成されます。

4

Proxy VMは、vCenterやNSX Manager、物理スイッチからインベントリ情報や設定を収集する役割と、vSphere上の分散スイッチのNetFlowで送られたフロー情報を収集する役割があります。

このときNetFlowでは通信パケット全てを送るわけではなく、パケットのヘッダ情報だけをやりとりしているためセキュリティ上も安心ですし、転送帯域も膨大には必要ありません。

Platform VMはProxy VMが収集したこれらの情報を解析して見える化する役割と、管理者にダッシュボードを提供する役割を提供します。

vRealize Operations Managerもそうですが、膨大な収集したデータを解析するため仮想アプライアンスに要求されるスペックが大きいので既存環境に追加する際には考慮が必要です。

■vRealize Network Insightで通信の可視化

vRealize Network Insightはこれまでの説明でもあったように、NetFlowを使った通信フローの可視化を行います。分散スイッチのレイヤで通信フローが収集されるため、ゲートウェイを介した通信だけでなく同一セグメントの通信はもちろん、同一ホスト内で物理的にはLANケーブルを流れていない通信まで可視化することが可能です。マイクロセグメンテーションを行う際に利用するVMware NSXの分散ファイアウォールのポリシー設計はもちろん、導入後のセキュリティ監査の目的で利用することができます。

5


YouTube: VMware vRealize Network Insight ネットワークフローの見える化

■vRealize Network InsightでNSX環境の健康診断

冒頭にvRealze Network Insightはネットワーク仮想化におけるvRealize Operations Managerのようなものですと説明しました。

vRealize Operations ManagerがvSphere環境の健康診断が行えるのと同じように、vRealize Network InsightではVMware NSX環境の健康診断を行うことができます。2016/12/1現在の最新版である3.1ではVMware社のベストプラクティスに基づいた40のチェック項目にわたる健全性確認を行い、ネットワーク仮想化基盤のトラブルを未然に防ぐことができます。

VMware vRealize Network Insight NSXの健康診断
YouTube: VMware vRealize Network Insight NSXの健康診断

■vRealize Network Insightで仮想基盤ネットワークのトラブルシューティング

vRealize Network InsightはNSXを導入した際の「NSXと物理ネットワークのトラブルシューティングが難しそう」といった相談を多くうけます。先ほど紹介したNSX環境の健康診断で安定したネットワーク仮想化基盤の維持ができます。

またvRealize Network InsightではNSXが構成するオーバーレイネットワークと物理スイッチが構成するアンダーレイのネットワークを一元的に管理することができます。


YouTube: VMware vRealize Network Insight 仮想ネットワークのトラブルシューティング

■まとめ

vRealize Network Insightを利用することで、VMware NSXが実現するネットワーク仮想化を低コストで運用していただくことが可能になります。
ご興味のある方は、VMware社が提供するオンラインラボを使ったハンズオン環境もありますので是非ご利用ください。
http://labs.hol.vmware.com/HOL/catalogs/lab/2894

2016/12/07

Nutanix 5.0の機能概要(Beyond Marketing) パート2

本記事はNutanix Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

本記事の原文はNutanix社のPartner Innovation and Vertical Alliances, Sr. Directorを務めるAndre Leibovici氏によるものです。原文を参照したい方はNutanix 5.0 Features Overview (Beyond Marketing) – Part 2をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

また、以下のセミナーでも本記事の内容を詳しくご説明しますので、是非ご来場ください!

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線
ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

すでに東京での開催は終了していますが、大阪での開催もございます!

こんにちわ。このブログ記事は私のNutanix 5.0の機能概要(Beyond Marketing)シリーズの2番目の記事で、もうすぐリリースされるNutanixソフトウェアで利用できるようになる機能をご紹介しています。この記事の1番目の記事はこちらです。

この記事は2番目の記事です。1番目の記事はこちら3つ目4つ目

これまでの記事のシリーズでご紹介してきた機能は以下のとおりです:

  • Cisco UCS B-シリーズ ブレード サーバ サポート
  • Acropolis アフィニティ と アンチ-アフィニティ
  • Acropolis ダイナミックスケジューリング (DRS++)
  • REST API 2.0 と 3.0
  • XenServerのサポート TechPreview
  • ネットワーク可視化
  • 新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)
  • ネイティブのセルフサービスポータル
  • スナップショット - セルフサービスリストアのUI
  • ネットワークパートナーインテグレーションフレームワーク
  • メトロアベイラビリティウィットネス
  • VMフラッシュモードの改善
  • Acropolis ファイルサービス 正式リリース (ESXi と AHV)
  • Acropolis ブロックサービス (CHAP認証)
  • AHVのOracle VM と Oracle Linuxへの認定
  • AHVのSAP Netweaver Stackへの認定
  • (New) Prism サーチの改善(ブール表現のサポート)
  • (New) I/O メトリクスの可視化
  • (New) 1-クリックライセンシング
  • (New) LCM – Lifecycle Manager(ライフサイクルマネージャー)
  • (New) 追加のPrismの改善点
  • (New) AHVの拡張性の改善
  • (New) AHVのCPUとメモリのホットアド(Tech Preview)
  • (New) コールドデータのアドバンスドコンプレッション
  • (New) バックアップベンダーのためのAcropolis チェンジブロックトラッキング(CBT) 
  • (New) 自発的なQoSによる期待通りのパフォーマンス
  • …さらに 3番目となる最後のパートで

免責事項 : あらゆる将来の製品又はロードマップ情報は製品の方向性を示すことを意図しており、Nutanixが提供するあらゆる情報、コード、機能に対してコミット、お約束、法的な義務が生じるものではありません。この情報を用いて、購入を決めるべきではありません。また、Nutanixは将来の製品改善、機能が最終的に利用できるようになった際に追加での課金を行うことや、最終的に改善された製品や機能のために別途の課金を行うことを現時点では決定していません。

機能や時間軸についてのオフィシャルな情報についてはNutanixのオフィシャルなプレスリリースをご参照ください。(こちら)

Prism

Prism サーチの改善(ブール表現のサポート)

すでにパート1をお読みいただいているのであれば、Prismがもはやデータセンタを一つの窓からすべて見通せるようになっていることにお気づきでしょう。管理者はコンピューティング、ストレージ、ネットワークをすべて管理出来るようになっています。それだけではありません。ネットワークとセキュリティパートナーが現在彼らのソリューションをREST 3.0でPrismへと統合を進めています。

AOS 4.6ではキーワードベースの検索と文脈を理解した結果表示を導入しました。今回、AOS 5.0ではよりリッチなアラートクエリ、表現クエリ、問題発見、動的なカンペ、全体的な検索エクスペリエンスのシンプル化が行われています。

これらの改善は「サービス品質の劣化」にフォーカスを当てています。今日、IT管理者はインフラストラクチャの問題の発見と隔離に多くの時間を費やしています。もしくはIT管理者は非常に複雑なフローで単純なタスクの実行にあたっているのです。 

  • よりリッチなアラートクエリのサポート
    • アラートのフィルタリング
    • 重要度によって(重大、警告)
    • 影響のタイプによって (可用性、キャパシティ)
    • 解決状態によって(解決済み、未解決)
    • 通知の状態によって(通知済み、未通知)
    • アラートのタイトルやタイトルの一部によって (CVMが再起動した、NICのエラー)
    • 上記の組み合わせ
    • 例) 解決済みの重大なアラート
    • 例) ホスト1の重大なアラート

Fig124

  • 表現クエリのサポート
  • 要素をブール表現(“>”, “<“, “=“, “<=“, そして “>=“)で指定てフィルタリング
    • 計測値をフィルタ (例 VMs IOPS > 100)
    • 属性をフィルタ (例 VMs “power state”=On)
    • 複数のフィルタを組み合わせ
  • 表現内の値を自動補完
    • 特定の属性についての値を自動補完
    • “Block type”= (利用可能なブロックタイプで自動補完)

Fig125

Fig126

Fig127

  • デザインを刷新し、改善されたカンペがPrism Centralで管理されている要素をベースに自動的に生成されます。カンペ、最近の検索履歴、保存した検索のレイアウトがキレイに改善されています。

Fig128

I/O メトリクスの可視化

NutanixはPrism UIで常々ストレージのパフォーマンス監視機能を提供してきました。Nutanixはさらに先進的なストレージパフォーマンス監視機構とワークロードのプロファイルについても全てのCVMのポート2009番で提供をしてきました。そこでは非常にきめ細やかな9日オスディスクの詳細情報を見ることが出来ます。AOS 5.0ではI/Oレイテンシ、I/Oパフォーマンス、分散度合い、ストレージの角層の利用率などの仮想マシンから見た重要なメトリクスをPrism内に表示するようになります。

Fig129

1-クリックライセンシング

AOS 5.0ではサポートとの接続を活用して、1-クリックでPrismから直ぐにライセンスを取得することが出来るようになりました。ポータルライセンシングAPIを利用して、Nutanixは自動的に管理者が行うことの出来るアクションを理解し、そのいずれもをシングルクリックで実行できるようにします。

  • アップグレード – 高いライセンスレベルへの移行
  • ダウングレード – 低いライセンスレベルへの移行
  • リバランス – 現在のノード数とライセンス数の同期
  • リニュー(更新) – 失効していないライセンスへとライセンスを入れ替え
  • 追加 – アドオンを追加
  • 削除 – アドオンを削除

Fig130

LCM – Lifecycle Manager(ライフサイクルマネージャー)

AOS 5.0では全てのクラスタコンポーネントの1-クリックアップグレードのオプションはライフサイクルマネージャーへと移動され、すべてのソフトウェア/ファームウェアのアップデートは単一画面管理で統合されています。この変更によって、インベントリとアップデートのコードがAOSから分離されることになり、全てのソフトウェア/ファームウェア/インベントリのアップデートを汎用的なフレームワークで行えるようになり、各々のクラスタコンポーネントの更新とは切り離してアップデートを当てることが出来るようになります。これらの変更は1-クリックアップグレードの処理を完全にシームレスにPrismへ統合したままで裏側で行われます。 

  • LCM はすべてのソフトウェア/ファームウェアのアップデートを一元管理できる
  • LCM のモジュールはAOS(ディスク/HBAのアップデート)とは別にリリースされる
  • LCM のフレームワークはLCMの操作をコントロールするメインモジュール
  • LCM のフレームワークはLCM アップデートモジュールで自己アップグレード出来る

Fig131

新しい LCM – Lifecycle Manager(ライフサイクルマネージャー)
 

Fig132

追加のPrismの改善点

  • Prism Central内の1年間のデータのリテンション (さらなる分析)
  • メニューとダッシュボードの静的文字列の国際化対応
  • Prism CentralのダッシュボードからPrism Elementのウィジェットへの迅速なアクセス
  • エンティティ(要素)ブラウザの改良:
    • テーブルとタイル表示からのデータのエクスポート(JSON/CSV)機能
    • 保存したクエリをサポート
    • サーチ <> エンティティブラウザの統合
  • Prism CentralのディスクI/Oと利用の削減による改善

 

 

アプリケーションモビリティファブリック(Application Mobility Framework - AMF)

AHVの拡張性の改善

Acropolisハイパーバイザの管理は要件の高いワークロードをサポートするために継続的に改善されています。AOS 5.0ではAcropolisハイパーバイザは12,500仮想マシンと150万件のアラートとイベントをサポートしています。

 

AHVの CPU と メモリ のホットアド (Tech Preview)

AHVはCPUとメモリのホットアドをサポートしました。AHVのメモリホットアドとCPUのホットプラグの機能はCPUとメモリを仮想マシンが起動して動作中に追加することが出来るものです。これによって、追加リソースが必要な際にいつでも仮想マシンを止めることなく追加することが出来ます。TechPreviewの最中はACLIでのみ利用可能です。

 

 

分散ストレージファブリック(Distributed Storage Fabric -DSF)

コールドデータのアドバンスドコンプレッション(圧縮)

AOS 5.0はコールドデータをキャパシティ効率の良いアルゴリズム(lz4とlz4hc)を利用して最高のストレージ効率を実現します。今回のリリースで導入された変更で圧縮率の改善、ゴミデータの削減、圧縮・解凍のスピードの改善がなされています。AOS 5.0ではこのポストプロセスでの圧縮はオールフラッシュクラスタでは標準で有効になり、ハイブリッドのクラスタでは手動で有効にすることが出来ます。

Fig133

バックアップベンダーのためのAcropolis チェンジブロックトラッキング(CBT)

AOS 5.0ではバックアップベンダーはNutanixのCBT(ハイパーバイザに依存しません)の恩恵を存分に活用することが出来、増分バックアップと差分バックアップの両方でディスクおよび仮想マシンを効率的にバックアップすることが出来るようになります。もしもVMware vSphereだけでクラスタを動作させているのであればハイパーバイザ由来のCBTを利用することはこれまでも出来ていました。しかし、NutanixのCBTでは同様の機能がマルチハイパーバイザーに対応したプラットフォームにおいてCBTを利用することが出来ます。管理者は同じバックアップツールと方法を全てのハイパーバイザーにおいて利用することができるようになるのです。

NutanixのCBTは新しいREST 3.0 APIを利用しており、あらゆる2つの仮想ディスク又は仮想マシンのスナップショットの変更メタデータ領域を問い合わせることができます。このアプローチでは増分と差分のバックアップに有益なことはもちろん、フルバックアップにも利用することが出来ます。これはAPIがスペア(ゼロ)の領域も特定することが出来るからで、Read操作を減らすことが出来るからです。

Nutanixは直ぐにプラットフォームにネイティブで統合されたバックアップパートナーをアナウンスします。 

 

自発的なQoSによる想定通りのパフォーマンス

自発的なQosは管理者がフロントエンドとバックエンドの操作のリソースの帯域を調整するその裏側で動作します。負荷の高いタイミングでは、すべてのフロントエンド(ユーザーによる)操作は高い優先順位を割り当てられ、負荷の低いタイミングではバックエンドの操作がより多くのリソースを割り当てられます。自発的なQoSはユーザーからの入力時に想定通りのパフォーマンスをユーザーアプリケーションに提供します。これは機械学習を用いて自動的に意思決定されます。

Fig134

  • 1-ノードのレプリケーションターゲット
  • ストレージヘビープラットフォーム上での1時間のRPOのサポート
  • ノードの削除時のEC保護の保持、保護オーバーヘッドの限定
  • 利用できる全てのノード内のSSDをメタデータに利用し、複数メタデータのディスクをサポート
  • ホストブートディスク(SATADOM)の入れ替え手順のシンプル化と自動化
  • コンテナにたいしてのイレイジャーコーディング(EC)でのレプリケーションファクター(RF)の変更のサポート
  • OpLogへのインライン圧縮
  • QoSによる複合ワークロードサポートの改善
  • 適応型レプリカ選択による混在ノードのサポート
  • Linux カーネルの更新 -  4.4.22

乞うご期待!

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Part 1翻訳を出した2時間前にすでに公開されていたPart 2の翻訳記事です。Part 2の目玉はやはりPrism Searchの改善ではないでしょうか。ウィーンではNutanixはAWS for the Enterpriseではなく、Amazon for the Enterpriseである!という話でしたが、これはGoogle Search for the Enterprise Infrastractureとも呼べるものだと思っています。優れた(ソフトウェアを含む)インフラストラクチャのアーキテクチャはもちろん大事ですが、優れたエクスペリエンス(この場合は「ググれ」「Google先生」と一般化した言葉が物語るように)を取り入れていくことにも積極的です。こうした発想はやはりWebスケール由来のものでしょうし、インフラを発展させるという発想からは生まれにくいものですね。

また、Part 1のネットワーキング&セキュリティに引き続き、REST 3.0とCBTを利用してバックアップパートナーのソリューションを取り込んでいく方向性もでています。やはり単なるHCIとしての進化ではなく、ここでも「プラットフォーム化」が進んでいます。自発的なQoSに関してはPernixDataのフローコントロールなどを思い出しますが、優れたものはどんどん取り入れる、その中で自分でやるべきもの(HCI=コンピューティング、ストレージ)はもちろん、パートナーシップで実現していくもの(ネットワーキング、バックアップ)がしっかりと分かれてきているように思います。

Part 3の最終パートも待ち遠しいですね。乞うご期待!

2016/11/29

Nutanix 5.0の機能概要(Beyond Marketing) パート1

本記事の原文はNutanix社のPartner Innovation and Vertical Alliances, Sr. Directorを務めるAndre Leibovici氏によるものです。原文を参照したい方はNutanix 5.0 Features Overview (Beyond Marketing) – Part 1をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

また、以下のセミナーでも本記事の内容を詳しくご説明しますので、是非ご来場ください!

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線
ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

AOS 4.7のリリースから5ヶ月が立ち、Nutanixは多くの新機能と改善点を備えたメジャーリリースヴァージョンをアナウンスしようとしています。AOS 5.0は社内ではエンジニアリングコードネーム「Asterix」と呼ばれていたものです。Nutanixによるその機能や改善のリリースのスピードはAWSやコンシューマー業界としか比べることが出来ないほどで、その素晴らしい更新のペースがユーザーを感動させています。このブログの記事ではもうしばらくでリリースされるNutanixのソフトウェアについてご紹介していきます。もしも以前のリリースについてのアナウンスを見たいのであれば以下を読んで下さい。

※訳注 4.7以外の記事についての和訳予定はありません。

本記事は本シリーズの1番目の記事です。2つ目3つ目4つ目

本記事では以下の機能についてご紹介していきます:

  • Cisco UCS B-シリーズ ブレード サーバ サポート
  • Acropolis アフィニティ と アンチ-アフィニティ
  • Acropolis ダイナミックスケジューリング (DRS++)
  • REST API 2.0 と 3.0
  • XenServerのサポート TechPreview
  • ネットワーク可視化
  • 新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)
  • ネイティブのセルフサービスポータル
  • スナップショット - セルフサービスリストアのUI
  • ネットワークパートナーインテグレーションフレームワーク
  • メトロアベイラビリティウィットネス
  • VMフラッシュモードの改善
  • Acropolis ファイルサービス 正式リリース (ESXi と AHV)
  • Acropolis ブロックサービス (CHAP認証)
  • AHVのOracle VM と Oracle Linuxへの認定
  • AHVのSAP Netweaver Stackへの認定
  • ・・・さらにパート2で

今後の数週間でプロダクトマネージャやプロダクトマーケティングマネージャチームが数々のブログ記事を書き上げ、もっと詳細なAOS 5.0の情報が出てきます。その一つ目がShubhika TanejaによるTen Things you need to know about Nutanix Acropolis File Servicesです。

免責事項 : あらゆる将来の製品又はロードマップ情報は製品の方向性を示すことを意図しており、Nutanixが提供するあらゆる情報、コード、機能に対してコミット、お約束、法的な義務が生じるものではありません。この情報を用いて、購入を決めるべきではありません。また、Nutanixは将来の製品改善、機能が最終的に利用できるようになった際に追加での課金を行うことや、最終的に改善された製品や機能のために別途の課金を行うことを現時点では決定していません。

機能や時間軸についてのオフィシャルな情報についてはNutanixのオフィシャルなプレスリリースをご参照ください。(こちら)

さて、法的な免責事項に目を通したら、さぁ、初めましょう!

プラットフォーム

Cisco UCS B-シリーズ ブレード サーバ サポート

本日、 .NEXT EMEAの中でNutanixは今後のCisco UCS B-シリーズ ブレード サーバのサポートについてアナウンス致しました、以前にアナウンスしたC-シリーズのラックマウントサーバのサポートに加えてのサポートです。

Fig092

現在、UCS B200-M4ブレードは物理容量3.2TBのオールフラッシュストレージに限定されています。フラッシュの制限によってストレージ容量の要件に見合わないという事が多くの場合でいえます。Ciscoや他のハイパーコンバージド製造メーカーは結果としてそのソリューションをラックマウントサーバに限定してきました。

NutanixはB-シリーズブレードのストレージ容量の不足の問題をストレージ専用ノードをB-シリーズのブレードのクラスタに追加することで解決させました。リリース後はオールフラッシュのC240-M4SXのストレージ専用ノードをクラスタに追加することが出来、最大でノードあたり24本まで1.6TBのSSDを追加することが出来ます。Nutanix固有のコンピューティングとストレージを異なった割合で自由自在に組み合わせられるという能力がこれを実現しました。

ストレージ専用ノードはUCSのお客様のブレードとC240間でのバランスのチューニングも実現することになります。更にはコンピューティングとは独立したストレージの拡張も実現します。古い筐体が容量が一杯になる度に新しいストレージ装置に巨大な投資を行うのではなく、お客様は必要に応じて順次環境を拡張して行けるようになるのです。

ストレージ専用ノードはNutanix AHVを利用して動作しています、ですから、追加で仮想化ソフトウェアのライセンスのためのお金が必要になるということはありません。AHVのストレージ専用ノードはESXiのノードと同じクラスタ内に混在させることが可能です。

Fig093

AMF(Application Mobility Fabric - アプリケーション モビリティ ファブリック)

Acropolis アフィニティとアンチ-アフィニティ

仮想マシン-ホストの固定アフィニティ

管理者が特定のワークロードが同一ホスト内で動作する事を保証したいという場合。例えば、多くの会社では、アプリケーションを仮想マシン内で動作させていますが、特定のアプリケーションはライセンシングの規約から、特定のホストに紐付いているということが有ります。管理者は仮想マシンに対してホストアフィニティルールを設定し、これらの仮想マシンを特定のホストで動作させ、他のホストへと移行しないようにすることが出来ます。

  • Acropolisは以下のHAやメンテナンスモードの最中の仮想マシンをサポートすることが可能です。
    • 予約モードのHAでは、仮想マシンの再起動のためのリソースが別のアフィニティホスト上に予約されます。Acropolisはこの予約が保証されない場合には仮想マシンの電源が入ることを許可しません。
    • ベストエフォートのHAの場合、Acropolisは別のアフィニティホスト上で再起動が出来ない場合、仮想マシンの電源をオフにします。
    • メンテナンスモードの場合、Acropolisは仮想マシンが別のアフィニティホストへと退避できない場合には仮想マシンの退避を行いません。

仮想マシン-仮想マシン 優先的アンチ-アフィニティ

特定の仮想マシン同士が同じホストで動作するべきではないと言う場合です。例えば、殆どの組織ではドメインコントローラーはいかなる場合においても最低一つは残って稼働し続けて欲しいという要件があります。このために組織はパフォーマンスの観点からは同じホストで仮想マシンが動作するほうが良い結果になる場合であっても、仮想マシン同士にアンチ-アフィニティルールを設定し、仮想マシン同士が別々のホストで稼働するようにというルールを設定します。

  • 結果として
    • 仮想マシンは優先的アンチ-アフィニティポリシーを持つ。
    • スケジューラーによる配置の最中はポリシーに違反することもある。
    • もしDRSが違反を解消できない場合、警告が発報される。

アフィニティの説明はこちらも参照ください。http://www.virtualizationadmin.com/blogs/lowe/news/affinity-and-anti-affinity-explained.html

Acropolis ダイナミック スケジューリング(DRS++)

システム管理者はDRSのコンセプトは既にご理解いただいていると思います。DRSはコンピューティングワークロードを利用可能な仮想化環境内のリソースでバランスします。- 今日DRSはほとんどの仮想化スタックの一部といえるようになっています。

DRSはキャパシティプランニングと密接に関係しています - キャパシティプランニングはより長い時間軸を対象としたものであるという例外はありますが、DRSによる最適化はキャパシティの制約がある環境で、もっと短い間隔で実行されます。

AHVのダイナミックスケジューリングは最初は既存のDRSの実装とさほど大きく変わるものでは無いかもしれませんが、Nutanixは要素としてコンピューティング、メモリ、そしてストレージのパフォーマンスをも配置決定の考慮に加えます。Nutanixの管理者はAHVのDRSがリソース(CPU、メモリ、そしてストレージIO)の競合やその後の一時的なリソースCPU、メモリ、ストレージIOの競合を事前に回避(または、回避のための推奨事項の生成)して、仮想マシンの電源を入れてくれるので「心の平穏」をもって管理に当たることが出来ます。

REST API 2.0 と 3.0

NutanixのREST APIについての大きな変更が今回のヴァージョンに含まれており、これにはAPIのヴァージョン、後方互換性、APIの衛生化、そして標準化が含まれています。さらに、新しいREST 3.0もプラットフォームの一部として含まれています。

REST 3.0はスケールアウトを意図して作られているAPIであり、組み込みのロードバランサのゲートウェイとして動作します。実装の実際のスキーマ(これは変わる可能性があります)詳細を実現するのではなく、REST 3.0は高いレベルでのユーザーの意図する実際のユースケースのコンセプトを規定するものです。

ユーザーの意図をマッピングすることで ー つまりユーザーが実現したいことをマッピングすることで、NutanixはAPIをパラメーターをセットするだけで与えられた操作を実行できるようにする機会を得ることが出来るのです。Nutanixがここで実現したことは大変なNutanixに固有のビジネスロジックをその呼出元から削除し、Nutanix内部(あるべき場所)へ配置したということです。

新しいNutanix APIポータルは既に利用できるようになっており、開発者は古いものや新しいREST 3.0の意図する仕様を直ぐに見ることが可能です。ポータルではPython、Java、Go言語、PowerShellのサンプルが提供されており、http://developer.nutanix.comまたはhttps://nuapi.github.io/docsでアクセスできます。

Fig094

XenServerのサポート TechPreview

Fig095

これはアナウンスの再掲載となりますが、NutanixはXenServer上で動作しているXenApp、XenDesktop、NetScaler VPXそして、NetScalerを含むCitrixのアプリケーションに対するサポートをNutanixプラットフォームに上で提供することになります。AOS 5.0からXenServerのお客様はXenServer 7をテクニカルプレビューとしてNutanixプラットフォーム上で動作させることができるようになるのです。

プレスリリースについてはこちらをご参照ください。

Prism

ネットワーク可視化

もしもネットワークが誤って構成されたら、アプリケーションの仮想マシンは動作を止めるか、パフォーマンスの低下が起こります。例えばVLANが誤って構成された場合、アプリケーションはそれぞれお互いに通信ができなくなります。ネットワーク構成の不整合、例えばMTUの不整合やリンクスピードの不整合などが起こると、大量のパケットのドロップによってパフォーマンスの劣化が起こります。

ネットワークの問題のトラブルシューティングを難しくしているのは単一のネットワークのパス上にあるすべてのスイッチの構成のミスが原因を作り出す可能性があるからで、管理者はトラブルシューティングを行う際にネットワーク全体の構成を見なくてはならなくなるからです。

これがまさにネットワーク可視化が解決しようとしていることです。各々の仮想マシンから仮想スイッチ、物理ホストのネットワークカード、TOR(トップオブラック)スイッチなどに至るまでのネットワーク全体の表示を提供します。VLAN構成などのネットワーク構成の要素情報も直感的で使いやすいインターフェイスに表示します。管理者は例えば、ユーザーやプロジェクトやホストにグルーピングしながらネットワークを簡単に探索できます。

NutanixはLLDPと/もしくはSNMPを利用してネットワークトポロジを検証します。構成情報をスイッチから取得するためにSNMPを利用します。例えば、ネットワーク状態に加え、それぞれのポートのVLAN情報を収集するためにはSNMPを利用します。一旦仮想と物理のネットワーク要素から構成や統計とともにトポロジの情報を収集し終わると、Nutanixは利用しやすいインターフェイス上にその情報を表示します。(最初のリリースではAHVのみで動作します。)

Fig096

Fig097

新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)

Pay as you go(必要なだけ支払う)

  • クラスタ内であとどれだけの仮想マシンが動作するか?
  • もし1ヶ月後に新しくSQLサーバを追加するとしたら、クラスタは大丈夫か?
  • もし、現在のペースでワークロードが増え続けたらクラスタはいつまで大丈夫か?
  • 一定のワークロードがあり、新しくクラスタを作りたいがどのようなクラスタが必要か?

What-if分析は新しく将来に追加されるワークロードをその追加の時期とともに指定するものです。既存の仮想マシンを例えば、既存の仮想マシンと同じインスタンスが10つ追加されたとしたら、という具合に指定することも出来ます。または、既存のワークロードとの差異を%で指定することも可能です。そして、ワークロードの拡張と縮退の両方を指定することが出来ます。そして、ついに、事前定義されたよくあるワークロードをその一つとして指定することが出来るようになりました。

たとえば、ビジネスクリティカルな中規模サイズのOLTPのSQLサーバのワークロードを指定したりすることが出来、what-ifツールはそのワークロードのサイズを見積もることが出来ます。what-if分析ツールは正確なサイジングの見積もりを行うことが出来る理由は、このツールが我々が最初の導入時に推奨構成を割り出すためのNutanixのSizerと統合されているからです。つまり、what-if分析ツールは様々な事前定義されたSQLサーバやVDI、Splunk、XenAppなどのワークロードを利用することができるのです。

Nutanixは既にランウェイ(将来予測)コンポーネント表示を提供していますが、これはキャパシティプランニングのアルゴリズムで異なる様々なリソースのランウェイ(将来予測)を予測し、クラスタ全体のランウェイ(将来予測)を予測しているのです。これを下に、what-if分析は管理者にどうしたノードを追加するべきだという推奨事項を、いつまでに追加するべきだという情報とともに提示することが出来、ランウェイ(将来予測)が本来のランウェイ(あるべき姿)にまで拡張されるようにすることが出来るのです。

一度ワークロードとハードウェアを追加すれば、システムは推奨事項を提示します。what-ifのUIに表示されるものを皮切りに変更やチューニングを行うことも可能です。例えば、様々なハードウェアの推奨構成の追加のタイミングを予算上の制限と調整を行い、ランウェイがどのように変化するのかを見たり、同様にワークロードの追加のタイミングを調整したりすることが出来ます。プライオリティの低いワークロードであれば後からということも有りますよね。あなたにとって最適なワークロードとハードウェアのプランが出来るまで好きなだけチューニングを行うことが出来ます。

Fig098

Fig099

Fig100

Fig101

Fig102

Fig103

Fig104

Fig105

Fig106

Fig107

Fig108

ネイティブのセルフサービスポータル

AOS 4.6ではAHVへのNova、Cinder、Glance、そしてNeutronのドライバーの提供によってOpenStackのサポートが導入されました。OpenStackはマーケットに広く受け入れられつつ有り、Nutanixと完璧に協調動作しますが、OpenStackはネイティブなNutanixソリューションではなく、OpenStackはそれを支えるあらゆるインフラストラクチャとともに動くように作られているため、多くのNutanixの先進的な機能を活用できるようにはなっていません。

NutanixのネイティブなセルフサービスポータルはPrismに統合されており、ITリソースへのアクセス、ポリシー、セキュアなテナントベースのアクセスを実現します。ポータルによってテナントはIT(情報システム部)の介在なくアプリケーションを展開でき、組織は開発者やテナントへAWSのセルフサービスに似たエクスペリエンスを提供することが出来るようになります。

管理者ポータル

  • プロジェクトの作成/管理
  • ユーザーとグループの作成/追加
  • リソースのアサイン
  • アクションのアサイン
  • ショーバックレポートの実行

テナントポータル

  • カタログ(仮想マシンテンプレート、vDisk、Docker Hubのイメージ、アプリケーションテンプレート)からのアプリケーションの展開
  • アプリケーションの監視
  • アプリケーションのリソース利用率の監視

Fig109

スナップショット - セルフサービスリストアのUI

Nutanix AOS 5.0はついに仮想マシンのユーザーがファイルレベルでリストアを行うためのユーザーベースのPrism UIを追加しました。この機能によってユーザーは自身の仮想マシンのファイルやフォルダの復元をセキュアにまた、管理者の手をわずらわせることなく行うことが出来ます。

Fig110

Fig111

Fig112

本日、ウィーンで実施された.NEXTカンファレンスでNutanixはネットワーク接続サービスとネットワークパケット処理サービスを統合、拡張された新しいネットワークのフレームワークについてもアナウンスを行いました。

ネットワーキング、セキュリティパートナーの製品を活用することが出来るサービスの挿入、チェイニングそしてウェブフックの組み合わせによって提供される壮大な可能性を秘めた機能です。

パートナーと共に現在開発中の幾つかのユースケースは:

  • ネットワーク展開のワークフローと対応するNutanix上のワークロード展開のワークフローの自動化
  • パートナースイッチへのオンデマンドでのVLAN展開の自動化
    • アプリケーション(幾つかの仮想マシンの組)がNutanix上で起動する際に、対応する物理ネットワークスイッチが自動的にそのワークロードのための適切なネットワーキングポリシーのもとに構成される
    • Nutanix上からアプリケーションが削除される際に、対応したネットワークポリシーが自動的に物理ネットワークスイッチから削除される
    • Nutanix上の仮想マシンがNutanixクラスタ内の別のホストにライブマイグレーションされる際(同じTORの別のポートや別のスイッチへ接続されている可能性がある)に、対応する以前利用していたスイッチとこれから利用するスイッチの両方に変更を適切にネットワーク構成を行う
  • ネットワークの「仮想マシンからみた表示」をNutanixに収集しパートナースイッチベンダーの情報を元に表示、つまりネットワーク管理者がパートナーのスイッチを管理できるように
  • 「仮想マシン中心」のネットワークの運用表示を提供し、ネットワーク管理者による物理ネットワークのトラブルシューティングをより迅速、より正確なものにする。ネットワーク管理者はパス、フローの追跡、仮想マシン名、タグ、ラベルに対応する統計情報によって根本原因の解析を迅速に行えるようになる。このインテリジェンスはNutanixによって、物理ネットワークデータベースへ仮想マシンの特徴(仮想マシン名と紐付けられたラベル、そして仮想マシンのIPアドレスとMACアドレス情報)として提供されます。
  • LLDPによるトポロジのディスカバリのサポート(Nutanixのノードと対応するTORスイッチノードとのマッピング)

Fig113

単一ネットワークパケット処理(Network Packet Processing - NPP)サービス挿入

NPPはクラスタ全体にサービス挿入し、ネット枠サービスがAHVクラスタ上で動作することを実現するネットワークのフレームワークの一つです。NPPは以下をサポートします:

  • パートナーサービスのイメージとプラグインの登録ワークフロー
  • サービスの展開 - クラスタ全体またはクラスタ内のサブセットに対して
  • ネットワークレベル挿入 - 通信内への割り込みとタップモードでの挿入モード
  • ゲストOSのライフサイクルイベントのプラグイン起動によるパートナーサービスへの通知
  • 対象となる仮想マシンのプロパティの通知 - ネイティブなプロパティ(IPとMACアドレス)とメタデータプロパティ(ラベル、カテゴリ、名前)の両方をサポート
  • サービスへの選択的なトラフィックのリダイレクト(ゲストOSの仮想NICの一部を指定)

パケット処理サービスチェイニングフレームワーク

Nutanixのネットワーキングパートナーは今日ではパケットがAHVネットワークを流れていく際にそれを検査し、変更するか、または廃棄してしまう機能を利用できます。サービスチェインフレームワークはAHVの仮想スイッチを自動構成し、パケットをNutanixパートナーによって提供されてるパケット処理(パケットプロセッサ)仮想マシンイメージやサービスへとリダイレクトするようにします。それによって利用できるサービスは:

  • インライン処理 - プロセッサが仮想スイッチ経由で流れてくるパケットの変更又は廃棄
  • タップ処理 - プロセッサが仮想スイッチ経由で流れてくるパケットを検査する
  • プロセッサチェイン - 複数のプロセッサを利用、同一ベンダまたは複数ベンダで利用できる、別々のサービスを提供するそれぞれをつなげて(チェインして)利用できる

ウェブフックベースのイベント通知(ネットワークオーケストレーション)

Nutanixのネットワーキングパートナーはいつであれウェブフックのイベント経由でクラスタ、ホスト、仮想マシンで発生したイベントの通知を受けとり、すぐに対応することが出来るようになりました。例えば、あるネットワーキングパートナーは仮想マシンネットワークのVLANが変更されたり、仮想マシンがライブマイグレーションして別のホストへ移動した際にパケット検査のポリシールールを適応するようにという警告を上げたいとします。ウェブフックを利用することでパートナーは非常に先進的な問題解決方法を実装し、そのワークフローによって全データセンタを自動化することが出来るようになります。

Fig114

既に統合の終わっているパートナーのデモを幾つか御覧ください。

Brocade

Mellanox

分散ストレージファブリック(Distributed Storage Fabric - DSF)

メトロアベイラビリティウィットネス

Nutanixのメトロアベイラビリティはデータセンタ全体に及ぶ復旧に対してもシングルクリックで優れた仕事をしてくれます。しかしながら、いくらかのお客様はサイト障害なのか、もしくはネットワーク接続障害なのかが明言できない問題であるため、自動的な復旧についての機能を欠いていると感じておられました。ビジネスクリティカルアプリケーションを利用しており、DR手順を実行できるITスタッフがいない場合にはことさらです。

以前はNutanixは自動復旧の機能を備えていませんでした。これはサイトの障害とネットワークのそれの区別を行うことができなかったからです。AOS5.0はこの問題をウィットネス(証言者)仮想マシンを障害ドメインの外側に置くことで解決しました。このウィットネス仮想マシンはそれぞれのメトロサイトとメトロサイトの内部通信とは異なる通信を行い、メトロアベイラビリティにおける復旧の決断の自動化に役立てます。ウィットネス仮想マシンはメトロクラスタ間で自動的にリーダー選出を行うことで、スプリットブレーンシナリオの回避にも役立ちます。

Fig115

VMフラッシュモードの改善

VMフラッシュモードはPrism UIに戻って、更に改善されました! 仮想マシンフラッシュモードは管理者がハイブリッドシステムにおいて、レイテンシが重要となるミッションクリティカルなアプリケーションが動作している特定の仮想マシンをSSD層に置くことを実現します。改善点はハイブリッドシステムにおいて、重要な仮想マシンにオールフラッシュの一貫したレイテンシとIOPS、サービスプロバイダのためのQoSによる階層化やより高いIOPSを提供することです。以前VMフラッシュモードについて記事を書いていますので、興味があれば詳細はそちらへ。

Fig116

Acropolis ファイルサービス(AFS)

Acropolis ファイルサービスがいよいよ正式リリース (ESXi と AHV)

Acroplis ファイルサービス(またの名をAFS)はDSFにネイティブに統合されたコンポーネントであり、Windows ファイルサーバや外部のNetAppやEMC IsilonなどのNASストレージ装置を不要にするものです。AFSはAOS 4.6、4.7ではTech Preview扱いでしたが、AOS 5.0ではいよいよESXiとAHVハイパーバイザ上で正式リリースとなり、Nutanixのサポート対象として本稼働環境で利用できるようになります。

Acropolis ファイルサービス (非同期-DR)

AFSはNOSの非同期-DR由来のネイティブのデータ保護を提供します。仮想マシンとヴォリュームグループは保護ドメインを利用して保護され、他のすべてのDR関連の操作と同様にスナップショットのスケジュールやポリシーを保護ドメイン自身に適応することが可能です。

Acropolis ファイルサービス (AFSクオータ)

AFSはハード、およびソフトのクオータ制限が利用でき、メールによる警告の設定もできるようになりました。ハード制限を利用している場合、クオータを超えることは出来ず、もしもクオータ制限を超えるようなファイルの書き込みが発行された場合、その書き込みは失敗に終わります。ソフトクオータ制限を利用している場合、警告が利用者に送信されますが、データの書き込みは許可されます。

クオータのポリシーはクオータがユーザーか又はグループに対するものか、クオータの制限(GBでのサイズ指定)、クオータのタイプ(ハード または ソフト)、そしてクオータイベントをユーザーに通知するかどうかというルールの組み合わせて指定します。ポリシーの適応は1人のユーザーまたはADグループを含む特定のグループのすべてのユーザーで行うことが出来、標準ポリシーはユーザーもグループも指定されていない場合に適応されます。

Fig118

Fig119

Acropolis ファイルサービス (アクセスベースの一覧 - ABE)

AFSのアクセスベースの一覧では、ユーザーがアクセスの出来る権限を持つファイルとフォルダのみが表示されます。もし、ユーザーがRead(もしくはそれ相当)の権限をフォルダに対して持っていない場合、Windowsは自動的にそのフォルダをユーザーの表示から隠します。ABEはユーザーの共有フォルダの表示をREADアクセス権限によってコントロールします:

  • FIND(ディレクトリ一覧)を利用した場合の応答でユーザーがアクセスできるファイルシステムオブジェクトのみを表示
  • 機微なファイル、フォルダのタイトルをREADアクセス権のないユーザーから隠す
  • 共有レベルの構成パラメーター("hide unreadable(Read権がなければ隠す)")
  • トップレベルフォルダであるHOMEシェアの特別な取り回し

Acropolis ファイルサービス(パフォーマンスと拡張)

AFSは4CPU/16GBの仮想マシンのVMFSあたり500以上の接続が出来るように最適化されました。小さな3ノードで構成されるAFSクラスタでも最大6千万のファイル/ディレクトリまでのファイルサーバにまで拡張することができます。

Acropolis ファイルサービス(パフォーマンス最適化の推奨)

AFSは分散システムとして実装されているため、他のFSVMはアイドル状態にあったとしても幾つかのノード(FSVM)に負荷が偏る可能性があります。そのアクセス不可をノード間または追加のリソースで再分配することでAFSはクライアントにより良いパフォーマンスを提供できます。AFSは平均CPU利用率、SMB接続の数、メモリ割り当て構成、ヴォリュームグループのRead/Writeの利用帯域などを含むの多くの計測値を利用して利用状況を把握し、負荷のバランスを取って解決方法を決定します。

解決策には以下の可能性がありえます:

  • ヴォリュームグループの移動 : いくつかのヴォリュームグループを「ホットな」FSVMから対比し、負荷を下げる
  • スケールアウト : 既存のFSVMが忙しい場合には新しいFSVMを作成しヴォリュームグループを保持させます
  • スケールアップ : CPUとメモリリソースを全てのFSVMに追加します

推奨事項が生成された後に、「Load Balancing」というボタンがファイルサーバタブのRecommendationカラムに表示されますが、管理者はその推奨事項を選択することも、別のもので上書きすることも出来ます:

  • ヴォリュームグループの移動をスケールアップで上書き
  • スケールアウトをスケールアップで上書き
  • スケールアップの推奨事項は上書きができません

一度ユーザーがロードバランスアクションを選択するとタスクが生成されアクションが実行されます。

Fig120

Fig121

Acropolis ブロックサービス(スケールアウトSAN)

Acropolisブロックサービスは高い可用性、拡張性、そして高パフォーマンスのiSCSIブロックストレージをゲストへと提供します。ABSはAcropolisヴォリュームグループサービス上に構成され、AOS 4.5以降利用が可能です。ヴォリュームグループはブロックストレージを提供し、NFSデータストアではサポートされない、もしくはブロックストレージのインスタンス間での「共有」が要件となるようなエンタープライズアプリケーションにとってはとても重要な機能です。ユースケースとしてはESXi上のMicrosoft Exchange、Windows 2008ゲストクラスタリング、Microsoft SQL 2008 クラスタリング、Oracle RACなどがあります。

Acropolis ブロックサービス (CHAP 認証)

  1. Challenge-Handshake Authentication Protocol(CHAP認証プロトコル)
  2. 共有の"秘密"の認証コードと接続元
  3. 相互のCHAP – クライアントがターゲットを認証
  • CHAPは識別子とその試行値を順次変更し、接続元が「録画再生」型の攻撃を仕掛けてくることに対する防御を提供します。CHAPを利用する場合、クライアントとサーバが平文の秘密鍵を知っている必要があり、もちろんこれはネットワーク経由で送っては絶対にいけません。
  • 相互のCHAP認証。ターゲットとイニシエータが相互に認証しあうというセキュリティのレベル。別々の秘密鍵を相互にターゲットとイニシエータにセットします。

その他のABSの改善点:

  • ダイナミックロードバランシング
  • ヴォリュームグループのフラッシュモード
  • IPベースのイニシエータのホワイトリスト
  • イニシエータの管理
  • 幅広いクライアントのサポート - RHEL 7, OL 7, ESXi 6
  • オンラインでのLUNのリサイズ

ワークロードの認定

NutanixはAHVがABS上でOracle VMとOracle Linuxの認定を得たこと、そしてSAP Netweaver stackの認定を得たこともアナウンス致しました。これはビジネスクリティカルアプリケーションをNutanixプラットフォーム上に移したいと考え、OracleとSAPのサポートを待っていたエンタープライズのお客様にとって恋い焦がれたニュースでした。

Fig122

また、本日NutanixはAHVの1-クリックでのネイティブなマイクロセグメンテーションをあなうんすしています。しかしながらこの機能は今後のリリースに含まれることになります。機能と公式な時間軸についての情報はNutanixの公式プレスリリースをご参照ください(こちら)。

Fig123

なんとまぁ、長い機能リストでしょうか、しかも、これで全部ではないのです・・・。直ぐに更に多くの機能で満載のこの記事の第2弾をリリースします。お楽しみに!

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

久しぶりのAndreさんの記事ですが、ようやく公開することが出来ました。先週までのPrismの記事ではとことんまで突き詰めるコダワリを感じさせるものでしたが、今回の内容は正に怒涛のようにリリースされる新機能の嵐。

記事の最初の方にも有りますが、これほどの機能追加はコンシューマー向けのアプリケーションやAmazon Web ServiceやSales Force.comなどのクラウドでしか見ることが出来ません。ストレージ機能はブロック、ファイルサービスと既存のストレージベンダーを置き換えるものになりつつありますし、新たに加わったネットワーキングについてもかゆいところに手が届いている感じ、これが一番必要だよね、というどストレートな機能を直球勝負です。エコシステムパートナーとの連携を見ているといよいよHCIというインフラを脱して完全に「プラットフォーム」になってきていると思います。

やっと訳し終えたのに、Andreさんはもう次の記事に取り掛かっているそうです。次はタイムリーに公開できるようにがんばります!

2016/11/24

EMC UnityはVeeamファーストで行こう!

今年5月に「EMC VNX/VNXe」の後継として、日本で販売が開始された「EMC Unity」ですが、VMwareのストレージとして既に利用されている方やこれから導入しようと計画している方も多いと思います。そこで、Unityと相性ピッタリのバックアップソフトであるVeeam Backup & Replication (以下、VBR)を一緒に使うと、どのようなメリットがあるのかをご紹介します。


■Unityスナップショットからのリストア

Unity自体にスナップショット機能があり、CIFSのファイルサーバー用途では、WindowsのVSSと連携してファイル単位でのリストアが可能です。しかし、VMwareのデータストアとして利用している場合は、データストア丸ごとのリストアとなってしまい、1つのデータストア上に多数の仮想マシンがある環境では気軽に利用することができません。

Veeam14_7

 

 そんな時に便利なのが、VBRのVeeam Explorer for Storage Snapshotsです。Unityのスナップショットから仮想マシンの中のファイルをリストアすることができます。

Veeam02


Explorerから元の仮想マシンに対して直接リストアすることもできますし、任意の場所にファイルをコピーすることもできます。

Veeam15_3


更に、同様の手順で仮想マシンの中のアプリケーション単位(Active Directory,Exchange,SQL Server,SharePont Server,Oracle)でリストアすることも可能です。

Veeam03_2


例えば、Active Directoryのドメインコントローラの仮想マシンの場合には、ストレージスナップショットからユーザーやグループポリシー、DNSレコードをリストアできます。

Veeam04_3


短い間隔でスナップショットスケジュールの設定をしていれば、より最新のスナップショットデータから簡単にリストアすることができ、同じデータストア上の他の仮想マシンにも影響がないため、気軽にスナップショットを利用できます。


■Unityスナップショットの活用

Veeam Explorer for Storage Snapshotsのメリットは、Unityのスナップショットからのリストアだけではありません。インストタントVMリストア機能と組み合わせて、Unityのスナップショットから仮想マシンを直接起動することも可能です。これにより、仮想マシンに障害が発生した場合でも、リストアするよりも短時間で仮想マシンを立ち上げて、業務を継続することが可能です。

Veeam05


ストレージスナップショットから起動した仮想マシンはVBRのコンソールからStorage vMotionを実行することで、そのまま本番環境として利用することも可能です。

Veeam20_3

 
障害が発生していない場合でもスナップショットから起動した仮想マシンは、本番環境の完全に分離されたコピーになりますので、アプリケーションのインストールやパッチ適用のテスト環境、仮想マシン上で障害が発生している場合には、トラブルシューティング用の環境としての利用など、スナップショットを様々な用途で活用することができます。

最近では、バックアップデータから仮想マシンを直接起動できるバックアップ製品も増えてきていますが、VBRでは2010年にリリースされたバージョン5からインスタントVMリカバリ機能を提供しており、更に他社の上を行くストレージスナップショットからの起動を提供しています。


■Unityのスナップショットと連携したバックアップ

スナップショットは便利な機能ですが、ストレージ筐体そのものに障害が発生した場合には、全てのデータが消えてしまいます。そのため、別の媒体にデータを保存する”バックアップ”を行うことが重要ですが、バックアップにおいてもUnityにVBRを組み合わせるメリットがあります。

それは、Unityのスナップショットと連携してバックアップができることです。他社の仮想環境用のバックアップソフトでもUnity上の仮想マシンをバックアップすることはできますが、他社製品はストレージがUnityかどうかは見ていません。どのストレージを使っていても全て同じです。

しかし、VBRはデータストアがUnityのストレージであることを理解し、vSphereのスナップショットだけでなく、Unityのスナップショットと連携してバックアップをしてくれます。vSphereのスナップショットだけの場合、仮想マシンの容量が大きく、バックアップ時間がかかるケースや、バックアップ中に仮想マシンへの変更が多いケースでは、デルタファイル(Redoファイル)の肥大化やスナップショット削除時のマージ処理で問題が起きる可能性がありますが、Unityのスナップショットと組み合わせれば、このような問題を解決することができます。

バックアップジョブの設定もチェックを付けるだけです(デフォルトでチェックが付いています)ので、意識することなく簡単にストレージスナップショットと連携してのバックアップが可能です。

Veeam19_2

※Unityの接続(FC,iSCSI,NFS)にあわせて、VBRのサーバがUnityのストレージにアクセスできるようにUnity側やVBRのOS側の設定は必要になりますので、ご注意ください。

■どうやってUnityVeeamを組み合わせるの?

Unityと連携するには設定が難しいのでは?と思う方もいるかもしれませが、設定ウィザードに従い、Unityを登録するだけでVBRが自動的にストレージを検出してくれます。ウィザードの流れを見ていきましょう。

 ①[EMC]を選択します。

Veeam17_2


②[Unity]を選択します。

Veeam08_3

 
③Unity管理用のホスト名かIPアドレスを入力します。

Veeam09_2


④Unityの認証情報を入力します。

Veeam10_2


⑤自動でUnityが使用しているプロトコルを認識し、プロトコルにチェックが付きます。

Veeam11_2


⑥Unityの情報がサマリーで表示されますので、Finishで完了です。

Veeam12_2


⑦Unityの作成済みスナップショットと仮想マシンが表示されます。

Veeam13_3

このように簡単にUnityを登録できますが、vSphereとUnity、Veeamと複数の製品が絡むため不安だという方は、弊社の導入サービスをご利用いただければ、vSphere・Unity・VBR全て弊社で設定させていただきますので、ご安心ください!
http://www.networld.co.jp/support/introduction/


ご紹介した全ての機能はUnityだけでなく、VNXやVNXeでも利用できますので、VNX/VNXeを既にご利用の方は今からでも遅くありません。今のうちに、VBRを導入しておけば、何年後かにVNX/VNXeをUnityにリプレースする際にも、引き続き、VBRを利用することが可能です。

VMware環境でEMCストレージをご使用の際には、Veeamを真っ先に思い出していただければ幸いです。

 担当:臼井

2016/11/23

Salle Designより: Nutanixの事例 ~Nutanix Prismが生まれるまで~(Part 5)

本記事の原文はNutanix社のProduct Design DirectorのJeremy Sallee氏によるものです。

原文を参照したい方はCASE STUDY NUTANIXをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

Nutanix製品の優れた部分はインフラストラクチャの高度な自動化や優れたソフトウェアアーキテクチャによってもたらされていることはもちろんですが、Nutanixのもう一つの魅力はその優れたユーザーインターフェイスであるNutanix Prismです。

Prismにどんな思いが込められているのかを表したビデオに字幕を入れさせていただきましたので、合わせて御覧ください。

今回は、そのPrismがどのようにして生まれたのかを解説した記事をお届けします。原文が非常に長いので分割しての投稿になりますが、ご容赦ください。本シリーズの過去の投稿はこちら。

クラスタ健全性(ヘルス)

もう一つの解決すべき主だった機能としてはクラスタ健全性(ヘルス)が有りました。私がこれについて動き始めた際にはこの新しい機能について一から作り始めて4ヶ月以上もかかることになるとは思いもつきませんでした。すべての始まりはpythonコードによるページが私に送られてきたときからです。開発を行っているエンジニアはこの新しい機能のために平均して毎分数百ものテストシステムの全ての要素に対して実行していたのです。クラスタは非常に複雑な親子関係を含んでおり、各要素は独立させることは出来ません。特にそれが障害系のテストとなったら。このツール全体の目的は膨大かつ複雑な要素の塊から問題を引き起こしている根本的な原因となる要素へとナビゲーションを行うことです。要素間の相互依存が連鎖反応を作り出し、ユーザーを惑わせることで問題を見ているユーザーを別の要素へと導いてしまいます。一週間もあれば問題を解決できると確信してデザインを開始しました。2~3週間、膨大な数のデザインを作成しましたが、それは一瞬でボツになりました。アイディアについては経営メンバー、フロントのメンバー、バックオフィスのメンバー、プロダクトマネージャーなどから入り続けていましたが・・・。以下はその頃に作成されたフォトショップやワイヤフレームです:

Fig054

Fig055

幾つかの試行錯誤や失敗、そして多くのミーティングの後、ようやく解決の糸口が見えました。メモリや親となる他のパラメーターと各要素をグルーピングするのです。これはユーザーがシステムの概要を迅速にひと目で把握しながら、更にその問題の解決への具体的な見識がある際には役に立ちます。たとえば、仮想マシンをメモリでグルーピングすることで、多くのメモリを利用している状態の仮想マシンに対して更にスペースを利用させるのか、その総量を減らすべきなのかを決めることが出来ます。これが本当のクラスタ健全性(ヘルス)についての始まりとなりました。ついに頭のなかに明確な絵をイメージすることが出来たのです。残りは全てのページについてエンジニアやプロダクトマネージャと毎日のようにミーティングを繰り返して、その進化を共有しながら仕上げていけばよいのです。以下は2ヶ月が立った頃のデザインの様子です。

Fig056

ようやく我々はインテグレーションの手順を開始しました。これについてはとても長い時間が必要で、さらに、私の関与はインテグレーションの進行のうちのほんの最初の概要だけでした。殆どが終わった後にようやく、私は最終的なインテグレーションについて関与することになります。完全に実装されたCSS、画面遷移、アニメーションそして、ユーザーエクスペリエンスが良いかどうかの確認です。これによって私のフォトショップファイルとおなじになるようにアプリに対して小さなチューニングが多く出てきました。

1月ごろでしょうか、ようやくアプリケーションが充分ユーザーの検証に耐えうるレベルにまで達しました。我々は幾つものユーザー検証を行いました。これによって多くの問題がユーザーインターフェイスに生じてきます。視覚的な問題のみに限られたものではなく、ナビゲーションやユーザーエクスペリエンスに関するものも有りました。ユーザーセッションから学び、ユーザーからのフィードバックを実装して、それぞれのページを改善し続けました。これによって問題が解決することもありましたが、全てではありません。アプリケーションが複雑になりすぎて、最初に利用の仕方を示すことが明確な解決策でした。我々はCSSチームとともに泡のように発生する情報とマウスによる対話を上手く実装する方法を模索しました。すべての体験をよりわかりやすくするためです(例を上げて説明させてください、多くの例がありますが、プロジェクトマネージメントのアプリケーションはフェイクのプロジェクトを作成してどのようにアプリケーションを使い始めるかをガイドします)。技術的に何かが優れていると決めた後も、私は説明的なデザインを最終的に統合することにしました。一度コーディングが終わった後にプロダクトマネージャにより良いものを届けたかったのです。

Fig057

マルチクラスタとクラスタ健全性(ヘルス)に取り組みながらも、全体のデザインにもこれを踏襲する必要があると思い至りました。この2つの機能はアプリケーションの他の部分へも一貫性のための改修を行う必要を生じさせたのです。ですが、更に私はレイアウトとデザインをシンプルにする必要も感じました。サイドデザインに立ち戻り、4.0の立ち上げのために加わった新しいCSSスペシャリストともにこの課題に当たりました。

Fig058

ヴァージョン4.0に関連するプレスリリースの幾つかは以下をご参照ください:

http://www.nutanix.com/nos-4-launch/
http://www.reuters.com/article/2014/04/15/
http://www.tomsitpro.com/articles/nutanix-nos-prism-central

ヴァージョン4.0のリリースに関する完全なアーカイブはこちら

教え、雇い、管理する

9月の3.5のリリース以降、私は管理と採用に継続的に関わり続けています。大量のコードとデザインを活用するためにCSSスペシャリストをフロントエンドのエンジニアリングチーム内に採用しようとしています。2ヶ月にも渡っての再構成を経験し、私自身が全ての「ビジュアル関連」のインテグレーションに必要なコミニュケーションは取れるようになりましたが、コードについては未だによくわかりません。このためには我々2人の間にうまい教育と風通しの良いコミニュケーションがなくてはなりません。そして、今のところ、上手く行っています。

そして、私自身はデザイナーを雇用し、チームを作ることにも深く関与しています。2014年の1月に1名のデザイナーを雇い、私はリモートで彼の法的な問題が解決するまで彼のマネージャーを務めていました(その時、彼は上海にいました)。既にもう一名のデザイナーともサインを終え、デザインの研究を7月末に終えれば合流する予定になっています。

我々はもっと別のメンバーも求めています。我々のすぐれた能力を持つ方にとって魅力が滾るように、デザインとコードについては自由なポジションを募集しています。

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

全5回にも及ぶ大作シリーズになってしまいましたが、Prismについての記事はこれでオシマイです。記事としてはオシマイになりますが、Prismは現在進行系のプロダクトです。

ここで述べられていたように新しい機能を追加して、その機能のためのデザインが追加される度に、全体のデザインへもそれが波及します。ユーザーエクスペリエンスの一貫性を保つことが如何に難しいか、そして逆に一貫したデザインによってどれだけの管理工数を削減できるかということをご理解いただけたのではないかと思います。Acropolis以上の魅力を持つこのPrism、インフラストラクチャの世界では比較の対象がないためにあまり語られない機能ですが、是非Prismの良さを立ち止まって考えてみてください。このアイコンがもしここになかったら、今なんとなくクリックしたけど、何故自分がそれを直感的にクリックしたのか?

エンタープライズクラウド製品を使っているときに触っている画面、それは全てPrismです。そして、これだけの労力、インスピレーション、デザインを経て完成した、単なるUIに収まらない、まさにソリューションなのです。

2016/11/16

Salle Designより: Nutanixの事例 ~Nutanix Prismが生まれるまで~(Part 4)

本記事の原文はNutanix社のProduct Design DirectorのJeremy Sallee氏によるものです。

原文を参照したい方はCASE STUDY NUTANIXをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

Nutanix製品の優れた部分はインフラストラクチャの高度な自動化や優れたソフトウェアアーキテクチャによってもたらされていることはもちろんですが、Nutanixのもう一つの魅力はその優れたユーザーインターフェイスであるNutanix Prismです。

Prismにどんな思いが込められているのかを表したビデオに字幕を入れさせていただきましたので、合わせて御覧ください。

今回は、そのPrismがどのようにして生まれたのかを解説した記事をお届けします。原文が非常に長いので分割しての投稿になりますが、ご容赦ください。本シリーズの過去の投稿はこちら。

2013年9月~今日 ヴァージョン4.0へ向けて

ヴァージョン3.5のリリースの前においても、既に4.0で登場する新しい機能に向けての活動をスタートさせていました。2つの主だった機能がありました。マルチクラスタのためのユーザーインターフェイスでPrism Centralと呼ばれる機能です。ヴァージョン3.5では単一のクラスタの管理が出来るようになっていました。4.0では複数のクラスタが管理できるようになるのです。全てにおいて、その内部のメニューが利用できなくてはなりません。また、2クラスタから数百のクラスタまで拡張することが出来なくてはなりません。もう一つの機能はクラスタの健全性(ヘルス)です。システム内の数千の異なる要素に対して、数百にも及ぶテストが動作しています。インターフェイスはシステム内での根本的な問題を複雑なアーキテクチャの中から正しいテストを用いて特定し、ナビゲーションするために必要になるのです。

マルチクラスタ

マルチクラスタについてはナビゲーションシステムを再構成する必要があるというところからスタートしました。幾つかの試行錯誤の後、サイドメニューをスライドさせることにしました。このメニューはクラスタのリストから構成されており、ユーザーがクラスタからクラスタへといつでもアプリケーション内で切り替えることが出来るようにします。そして、アラートシステムも考え直すことにしました。古いものはアラートや進捗、アラート数の間を行き来する上で誤解を招きやすいものでした。新しいデザインではこれも解決しなくてはなりません。

繰り返しになりますが、これは大きなページではありませんが、ナビゲーション中に繰り返される重要な部分ですので、フォトショップで作成したデザインとエンジニア、そしてサポートエンジニア(パワーユーザー)とのミーティングで、以下に一貫した進捗状況とアラート表示がいかに重要で、有用なのかを理解しながら行われました。

最初の段階でのヘッダーの状態は以下のとおりです:

Fig052

そして、これが最終的なデザインで、クラスタからクラスタへと移動が楽になったナビゲーションです:

Fig053

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

今回はPrism Centralに関する内容です。最初のデザインとスライドして出て来るデザイン、皆さんどうお感じになられますか?

クラスタを切り替える際に、アラートや進捗状況を見て切り替えるというのはとても直感的ですので、クラスタを切り替える画面でそれが表示されているのは無駄なクラスタ切り替えがなくて済むことをよく考えてくれているUIになっていると思います。

また、一旦クラスタを切り替えてしまえば、他のクラスタのことは気にせずに作業に集中したいはずなので、このスライド式のUIはまさに理にかなっているといえるでしょう。

単に美しいだけではなく、ユーザーの(確認)作業も減らしてくれる、そんな優れたUIは管理コストの削減はもちろん、イライラを抑え、生産性の向上を導くのです。

さて、次回はヘルス表示についての記事となります。乞うご期待。

2016/11/15

ウィーンから速報 : Nutanix .NEXT EUROPE 2016 番外編~PernixData記事最終章

本記事はウィーンから速報 : Nutanix .NEXT EUROPE 2016 前半ウィーンから速報 : Nutanix .NEXT EUROPE 2016 後半の続編です。是非、最初からお読みください。

すでに帰国しておりますが、最後にNutanix社に買収されたPernixData社の情報についてお伝え致します。PernixData関連の記事はフラッシュ仮想化プラットフォームの基本要素 パート1から100以上も更新してきました。今回の記事はその最終章になります。若干以上に自己満足な記事でもありますが、是非おつきあいください。

PernixData社のその後の情報を含め、もっと詳しく知りたいという方は以下のセミナーへ是非お申し込みください。

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線

ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

VMware と AWSの戦略的なパートナーシップ発表直後の10月17~20日で開催された「VMworld 2016 EMEA」参加メンバーによる VMware の最前線情報 と、Cisco UCS や Citrix XenDesktop ファイルサービスへの対応など矢継ぎ早に進化を続ける Nutanix 社の最新の「.NEXT」イベント「Nutanix .NEXT Conference EUROPE」参加メンバーによる、Nutanix 社の最新情報が2つまとめて聞ける日本で唯一のセミナーです。

「.Next on Tour Tokyo/Osaka」や「vForum Tokyo/Osaka」では語られなかったレアな情報や、より新しい情報が目白押し!両社の販売代理店必見の内容をお届け致します。

Nutanix社によるPernixData社の買収

PernixData社とNutanix社の間に何かありそうだ、という記事が出たのは2016年の7月1日のことです。当時はNutanix社も非上場企業ですし、PernixDataも創業から4年(製品出荷開始から2年半)を経ていますが、まだまだスタートアップ企業で詳しく詳細が語られることはありませんでした。そして後日明らかになりますが、PernixData社はオフィシャルには8月3日にNutanix社に買収されています。買収額は公表されていません。

なぜPernixDataを買収したのか? これに関しては開発責任者であるSunil Potti氏のブログにも記載が有ります。「データとアプリケーションを物理的に近づけるべきである」というアーキテクチャ的な思想が共有されており、更に「ハイパーバイザを通じて全てのIOの特徴を見ることができる」という点も買収の評価ポイントのようですが、何より「こうした思想を共有できており、かつ優れたメンバーがグループになっている」ことが重要ということが記載されています。

つまり、PernixDataはテクノロジーはもちろん、そのメンバーを含めて、業界の反乱者/革命者であるNutanixファミリーに足る会社であると言う理由で一緒になったのです。

今回の.NEXT EUROPEではそうしたメンバーがNutanixで元気にしている姿を目にすることが出来ました。

PernixDataのメンバーは?

まずオーストリアに出発前に確認できた情報ですと、PernixData社のCTOだったSatyam氏とVP Product ManagementだったBala氏はNutanix上にスケールアウト型のファイルサービスを提供するAcropolis File Serviceのセッションのスピーカーとして登録されていました。

Fig087

さすがウィーン、部屋の名前がマーラーとかブルックナーという作曲家になっています・・・ではなく、PernixDataの技術の中心にいたこの2名は既にNutanixの一大プロジェクトであるAcropolis File Serviceをリードするポジションで活躍しています。セッション内の詳しい情報はセミナーなどでお伝えしていきますが、仮想化サイロの統合の時代を経て、時代はストレージサイロの統合の時代へと移ってきています。Nutanixは仮想化のためのボックス(HCIまたはHCI++)から既にエンタープライズのためのボックス(エンタープライズクラウド)へとかじを切っており、ファイルサーバの統合(AFS)、ブロックストレージの統合(ABS)と矢継ぎ早に新しいテクノロジーを生み出しています。この重要なポジションがこの二人によってリードされているのは大変素晴らしいことだ!と思い私はウィーンへの旅路につきました。

再会、more big things!

ウィーンではいくつかブログを翻訳させていただいているサポートエンジニアのGuidoさん、そしてPernixData社の元CEOのPoojan氏と再会することが出来ました。見てください! せっかくなのでPernixProのTシャツを着ていきましたが、外気温4℃のウィーンでは寒かった!

Fig088

Poojan氏とはMeetingでいろいろなことをお話いたしましたが、PernixData社の製品についてはこちらのURLのレターのとおり、既存のお客様は安心して今後もFVP/Architectの利用、増設を行うことが出来ます。また、前半のレポートでお伝えしたとおり、Nutanixへの統合も進んでいるのでしょうか?これについては詳しいことはきくことは出来ませんでしたが、PernixDataの技術でNutanixはもっと早くなるし、新しいフラッシュ(メモリクラスストレージ)が出てきたらそれも取り込んで、どんどん上がっていくよ!とのことでした。今年はWikibonの予測によるとFlashとHDDの容量単価がクロスオーバーする年です。まさに今後のストレージは激変していく、その最前線のメンバーとしてNutanixに合流したのです。

Fig091

Poojan氏によるとPernixDataのメンバーはPernixDataの技術の統合はもちろん、ブロックサービス(ABS)とファイルサービス(AFS)に携わっているということです。ファイルサービスのみならず、そのバックエンドに利用されているブロックサービスもこれまでのストレージの常識の枠を超えた機能を持つストレージでエンタープライズのストレージサイロの統合に今後大きな役割を果たすことでしょう。まさにWikibonの予測のとおり、エンタープライズのストレージはNutanixのようなServerSANになっていくのです。

Fig090

AFSのセッション終了後は質問攻めで近づくことも出来ませんでしたが、BalaさんとSatyamさんも会場で見かけたので一緒に写真を取ってきました。

Fig089

PernixData社はNutanix社と合流しましたが、その思想、技術は今後より大きな変革のために既に動き始めていました。Nutanix社のディストリビュータとして日本でこれから起こる、もしくはもうはじまっているこの変革の一端でも担えればと、決意を新たに帰国の途についたのでした。

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX)

Nutanix .NEXT関連記事はこの番外編でオシマイです。残ったコンテンツはセミナーにてご披露しますので、是非足をお運びください。また、2年以上に渡って書き続けてきたPernixDataの記事もおそらく今回で最後になります。上で述べられているとおり製品の統合が進んでおりPoojan氏の言葉を借りると「PernixData will be invisible.」になっていきます。

さぁ、新しくPernixDataの技術が中にはいったNutanixの製品の登場を待ちましょう!