*Nutanix Feed

2017/01/18

フラッシュにとってネットワークは遅すぎる、どうしたら?

Fig163


本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はYour Network Is Too Slow For Flash And What To Do About Itをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

Fig162フラッシュの技術がデータセンタの形を変えつつあることに疑いを持つ方はもうおられないでしょう。ロックバンドのクイーンは30年以上も前にそれを理解していたようですが!フラッシュはハイパフォーマンスアプリケーションの展開のための経済性を変革しましたし、回転するディスクをベースとした従来型のストレージシステムには多くあったパフォーマンス上のボトルネックを取り除きました。実環境のデータでのハイブリッドストレージ(SSD+HDD)のデータの削減率という記事の中で示したとおり、データの削減のためにフラッシュを利用する必要はありません、ですが、データ削減とともにフラッシュストレージを利用すればフラッシュの容量の経済性を改善することが出来ます(ディスクを利用するよりも安く、フラッシュのパフォーマンスを利用することが出来ます)し、電源や空調を削減し、可動パートがないことによる信頼性の改善を同時に得ることが出来ます。みなさんはまだご存じないかもしれませんが、近年のSSDなどのフラッシュデバイスはハードドライブ以上の信頼性を誇っています。物理的な容量という観点からもSSDのキャパシティは期間あたりのでのダイあたりのトランジスタ数の収容量のおかげで、CPUのパフォーマンスが上がっていくのと同じようなスピードで増えていっています。あるベンダーは既に2.5インチのドライブで16TBという物を出荷開始しており、この価格は2.5インチのハードドライブよりも安くなっており、消費電力も低く、冷却コストも低く、スペースもより小さくすることが出来ます。記事の冒頭の画像はインテルのM.2デバイスのものですが、3.5TBものキャパシティをもち、恐ろしいほどの小さなフォームファクターを実現しています。では、ネットワークはこれにどう対処しなければならないのでしょうか?

ファイバーチャネルを利用しているのであれ、イーサーネットを利用しているのであれ、ネットワークはフラッシュの技術、そしてもっと重要なことにはアプリケーションを上手く動かすために大きな役割を担っています。この理由はとてもシンプルです。データベースの管理者にとっては随分前から知られていたことです。データがアプリケーションから遠くはなれてしまうことで、レイテンシが高くなり、スループットが落ちてしまい、それによってパフォーマンスとユーザーからのレスポンスタイムが劣化してしまうということが原因です。これはフラッシュによってより明確に浮かび上がります、特にキャパシティとパフォーマンスの技術がどんどん先へと進み、1本、もしくは数本のデバイスだけでネットワークのパフォーマンスを限界に追いやってしまうことになるからです。こうした理由は幾つかのエンジニアリングシステムがインフィニバンドのネットワークやRDMAを利用するための一つの理由ですが、それでさえ、遅いのです。以下は3つの異なるフラッシュデバイスと現在のイーサネットネットワーク技術のスループットを比較したグラフです。

Fig164

数多く目にする2.5インチのホットプラグ出来る一般的な形のフラッシュデバイスは今日では500MB/sのスループットを実現でき、最大で50K(5万)か、それ以上のIOPSを低遅延で実現することが出来ます。ですから、たったの2本のドライブで10GbEのイーサネットワークを飽和させますし、4本あれば16Gb/sのFCネットワークも飽和させてしまいます。幸いなことに、我々はサーバごとに複数のNICポートもしくはHBAを通常利用しています。しかし、これはストレージ装置が数十から数百のドライブもしくは、サーバ内、もしくはストレージシェルフで12~24のドライブを利用するようになると役には立ちません。もちろん、今日一般的なフラッシュの技術であったとしても、それをネットワークに接続するのであれば、そこがパフォーマンスのボトルネックとなり、全パフォーマンスに近い値をなし得ることはほとんど不可能です。

さて、今日のNVMeへと目を移しましょう。これは次世代のフラッシュテクノロジーであり、2016年の終わりまでには一層普及し、2017年にはメインストリームとなっていく技術です。それぞれのデバイスは40GbEのNICを飽和させるのに充分なスループットとIOPSになります。もし、システム内に2つのデバイスがあるとしても、デュアルポートの40GbEのNICを飽和させてしまいます。これがEMCのDSSDのようなNVMeベースのストレージシステムが従来型のネットワークでストレージとサーバを接続しない主な理由で、そのかわりにDSSDは多くの第3世代 PCIe接続を多く束ねて接続を実施しています。彼らは既にネットワークが大きなボトルネックで、NVMeベースのフラッシュが提供するようなパフォーマンス能力を届けるためにはおそすぎるということを認識しているのです。それぞれのNVMeデバイス自体は今日我々が目にする一般的なほとんどのエンタープライズストレージのフラッシュよりも6倍から8倍は高速です。今日どれだけのお客様が40GbEのNICや32Gb/sのFC HBAをデータセンタ内のサーバに搭載しているでしょうか?

SSDは速いです。NVMeをベースにしたSSDはもっと速いです、ですが、インテルとマイクロンが共同で開発している3D Xpointはブッたまげるほど速いのです。3D Xpointは2015年にアナウンスされ、エンタープライズのプラットフォームへの導入は2018年か2019年と期待されています。これは今日一般的なエンタープライズのシステムで利用されているSSDの1000倍高速です。3D Xpointが提供するパフォーマンスによって、マザーボード、プロセッサ技術、メモリバス、そしてそれ以外のすべてが強力にブーストされることになるでしょう。デバイス単独でもマルチポートの400GbEネットワーク(400GbEは100GbEの次に予定されています)を飽和させるのに充分です。これを今すぐにネットワークへと接続したとしても、ネットワークを1年は待たなくてはなりません。3D Xpointは150ナノ秒以下のレイテンシを提供すると予想されており、これは今日の40GbE、100GbEのスイッチポートよりも速いのです。Gen3/Gen4のPCIeを利用したとしてもこれほどのパフォーマンスへの対応には充分に速いとはいえません。インメモリデータベースの影響を考えなんて、とんでもない!これはDRAMのスピードで動作しているのです。

Fig165

上のCrehan Research Inc.のデータが示すように、10GbEと40GbEのポートの利用は増え続けており、100GbEのポートのコストも下がりつつ有ります。しかし、100GbEはまだ幅広く受け入れられているとは言い難く、今時点では40GbEのサーバもまだという状況です。Crehan Researchの2015年のレポートによると100GbEは2017年から広く利用され始めると予測しています。しかし、これはスイッチングやバックボーンでの話であり、サーバーでの利用ではありません。NVMeがメインストリームとなり、3D Xpointを数年先に控えても、それぞれのサーバ間のネットワーク接続はこの1000倍の隔たりを短い時間では吸収しきれません。本来でいえばデュアルポートのTbEの接続を備える必要があるのです。

ですから、こうした証拠からもしフラッシュをネットワークに接続するとしたら、パフォーマンスへ影響を与えるボトルネックと投資への有効性への制限をある程度は抱えてしまうことになるのです。それと同時にお持ちのフラッシュが叩き出す可能性があるスループットに近いレベルでのデータの保護についても保証がほしいと考えるでしょう。どうすれば両立できるのでしょうか? 高いパフォーマンス、低いレイテンシ、アプリケーションに可能な限り近いデータ、それでいてデータ保護を保証できる方法は?

簡単な答えはSSDをローカルのRAIDカードに接続する、ということになるでしょう。これは2.5インチのSSDであればうまくいくでしょう(もちろん、パフォーマンスの観点から複数のRAIDカードをサーバに搭載しなくてはなりません)、しかし、これはNVMeや3D Xpointでは上手く行きません。複数のローカルのRAIDコントローラーを全てのサーバに入れる、ということは個別に管理しなくてはならない数百、数千のストレージキャパシティのサイロを生み出します。我々は長い時間をかけてこの管理のオーバーヘッドを集中管理することで回避できるアーキテクチャを作り上げてきました。この新しいテクノロジーを活用すべきで、後戻りすべきではありません。

現実的な回答は2つです、一つ目は仮想化、そして二つ目は本来の意味で分散されているシステムアーキテクチャへの投資で、そのこころはデータローカリティという概念です。データローカリティを持つアーキテクチャはデータ保護のために分散しながら、一方でデータがアプリケーションにとってローカルにあるということを保証します。仮想化が必要な理由は膨大なまでの高いパフォーマンスを持つストレージがあり、単独のアプリケーションではそれを現実的に使いこなせないからです。仮想化を利用することで、コンピューティングとストレージのキャパシティとパフォーマンスを充分に利用することが出来るのです。幸福なことに、インテルはプロセッサの能力を毎年向上させ続けており、コンピューティングのためのコアを、ハイパフォーマンスストレージのためにも利用することが出来るようになっているのです(プロプライエタリなコンポーネントは必要ありません)。

データローカリティの概念は大きく成長し、拡張する必要がありながら、データ保護と高いパフォーマンスが必要となる多くのウェブスケールアプリケーションで利用されています。データローカリティの概念で、膨大なネットワーク負荷を減らすことが出来、それがボトルネックに成長することを防ぐことが出来て、新しいタイプのフラッシュテクノロジーの将来を保証することが出来るのです。データはアプリケーションからはローカルのPCIeバスを通じてメモリに読み込まれ、書き込み、もしくは変更だけがそのデータを保護するためにネットワークを経由します。データローカリティをベースとしたアーキテクチャが適切に実装されていれば、拡張はリニアに行え、想定通りの一貫したパフォーマンスが得られるのです。これによって多くの推測での作業やトラブルシューティング、ビジネスにおけるリスクを削減できます。これはアーキテクチャが環境へのシステムの追加や退役などの矢継ぎ早に変更される要件に適応する能力をより多く保持しているからです。

データローカリティをもつ分散アーキテクチャを利用して、カスタムメイドのアプリケーションや新しいウェブスケールのビッグデータアプリケーション(Hadoopやそれに準じるもの)へも対応が可能です。ですが、もしこうしたタイプのアーキテクチャからメリットを受けることが出来ない開発者がいない場合、どうしたメリットが有るのでしょうか?新しいストレージの技術に適応可能なアーキテクチャでかつ、変化の起こりつつあるデータセンタの将来を保証できるものは?その答えはSANではありません。ここで述べてきたとおり、フラッシュをネットワークの終端に接続するとしたら、その近く以外ではなにも実現ができないのです。現在存在する唯一のソリューションはハイパーコンバージドシステムで、サーバとストレージは単一のユニットに融合しており、それは分散アーキテクチャをなしているのです。

すべてのハイパーコンバージドシステムはデータローカリティの概念をその中に実装しているわけではありません。ですから、注意深くベンダーを選定してください。それぞれのベンダーをご自身の要件とビジネスのニーズにおいて評価し、どのベンダーが大きなアーキテクチャの変革無く、将来に渡って投資を保護してくれるのかをお考えください。幾つかのベンダーはアンチローカリティをプロモーションし、お客様へ単に多くのネットワークポートを購入しながらオールフラッシュを利用することを推奨しています。残念なことに、ネットワークカードはフラッシュのテクノロジーに対応ができません(400GbEでも遅いのです)。ですから、パフォーマンスは最高のものが保証されませんし、そのアーキテクチャではどんどんと変化していくフラッシュのテクノロジーをシームレスに採用していくことも出来ないのです。

さらに、一度フラッシュに投資を行い、それをアプリケーションの近くへと配置すれば、CPUの利用率も上昇させることが出来るということも付け加えさせてください。特定のユースケースにおいてこれは劇的です。これはストレージがもはやボトルネックではなくなったということが原因です。アプリケーションはIOの完了を待つ必要がなくなりますので、ユーザーへのレスポンスが良くなりますし、バッチジョブはより早く完了しますし、より短い時間で多くのトランザクションからなるプロセスを実行できます。結果として、CPUのアイドルの時間がより少なくなるのです。究極的にはより短い時間でより多くの有益なしことをこなすことが出来ます。ですから、フラッシュを利用して急にCPUの利用率が80%を超えたとしてもビックリしないでください。これは期待通りです。投資がすべて良い方向へ使われた結果に他なりません。それとも、もっと沢山の機材を購入されますか?

終わりに

この話とそれ以外の話をビールを飲みながらNutanixの開発エンジニアであるTony Allen氏としているビデオを以下から見ることが出来ます。以下のビデオはエンジニアとビールを飲もう!シリーズの1つです。(訳注:字幕は入れておりません)

データローカリティは唯一の将来が保証されたデータセンタアーキテクチャであり、かつ、データセンタを継続的に破壊し続けるフラッシュテクノロジーの進化を取り込むことが出来るものです。Nutanix(私はそこで働いています)はデータローカリティをアーキテクチャのコア部分として本当に初期のリリースから取り入れています。この主な理由はアーキテクチャは拡張し続けられなくてはならないものであり、過去5年間に導入された異なる世代の環境にその下のアーキテクチャの変更無く受け入れられるものでなくてはならないからです。もちろん、起こりうる変化に対応して将来保証されていなくてはなりません。我々はお客様に様々なプラットフォームを組み合わせて使っていただくことが出来るようになっています。それでいてデータをアプリケーションにとってのローカルにし、データとアプリケーションの間のパスをできり短くし、アプリケーションのレイテンシを低くすることが出来るのです。

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

Ntc2017_2

さて、前回に引き続きオールフラッシュの内容ですが、その内容は衝撃ではありませんか? 今後はフラッシュデバイスがどんどん早くなり、SSDが安くなっていく・・・ここまでは様々なストレージベンダーもが口をそろえて同じ事を言いますが、フラッシュデバイスはもっと早くなり・・・SANでは対応ができなくなる(もしくは普及もしていないような高価な高速なNICを買い続ける?)ということです。

もちろん、普及しなければNIC値段は下がりませんのでジリ貧ですが、「データローカリティ」を備えたHCIであればこのネットワークを超えるスピードを持つフラッシュを効率的に(もちろん、Writeが極端に多いアプリケーションがあれば話は別ですが、いろいろな仮想マシンで負荷の平均化が出来るでしょう)データセンター内に取り込むことが出来るのです。

アプリケーションとデータを近くする以外にはネットワークのボトルネックを通さなければいけませんので、正にこの話はPernixDataが描いていたストーリーですし、それを買収したNutanixがどこを見ているのかが分かりやすい記事だと思いました。2017年、いよいよPernixDataのテクノロジーが入ったNutanixが楽しみです!

2017/01/11

実環境のデータでのハイブリッドストレージ(SSD+HDD)のデータの削減率

本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はReal World Data Reduction from Hybrid SSD + HDD Storageをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

Fig149

オールフラッシュベンダーからそして、別のタイプのハイパーコンバージド(ストレージとサーバをハイパーバイザと1つのパッケージにした)ベンダーからも多くの話が出てきていますが、常に湧き上がる疑問はどのタイプのシステムがより多くのデータ削減を行うことが出来るのか、というものです。残念ながら、殆どの場合、例に上がるのは現実からある程度簡略化されたものばかりです。

ある人はオールフラッシュでなければデータ削減機能は意味が無いと言いますし、別の人はハードウェアカードがなければデータ削減機能は意味がないと言います、また別の方は従来型のSANが必要だと言うでしょう。様々な技術と様々な異なるシステムを組み合わせ、より良いデータ削減率を得ることも出来ます。じゃあ一体何が正しいと言うんだい?真実はデータ削減率は保存されているデータのタイプに大きく依存し、逆に、どのようにデータ削減を行うかにはさほど依存しないということです。既に圧縮されているイメージデータや暗号化されたデータベースシステムに対してはどうやったとしても非常に小さな削減効果しか得られません。重複排除が簡単なVDIのイメージのようなデータを保存しているのであれば、もしくはテキストのような圧縮可能なデータを保存しているのであれば、その効果は非常に良いものになります。

あるベンダーはこの数字を例えばスナップショットは重複排除される、であるとか、テンプレートから展開されたデータは重複排除される、など巧みに操作していますが、いずれも誤解を招くことになります。スナップショットを取るということはデータを削減することにはつながりません(そしてバックアップでもありません)、しかしながら、テンプレートからの展開をスマートなメタデータ操作で実行することはデータの削減になります、ですが、これは重複排除ではありません。重複排除は流入してくるデータが新しいパターンであるということが認識されて初めて適応されるもので、過去にすでにパターンがシステム内に保存されている際には必要が無いものなのです。重複排除は特定のタイプのアプリケーションでは非常に効果が高く、逆に他ではさほどでもありません。これは圧縮が特定のものにはうまくいくし、別のものではうまくいかないということと全く同じです。

もっとも最低の議論というのはオールフラッシュを使えば良いデータ削減率が得られる、であるとか、それがパフォーマンスに影響を及ぼすであるとか、であり、これはベンダーのプラットフォームの設計を理解していない場合には全くの間違いです。これを示すために、ハイブリッドのソフトウェア定義のシステムでSSDとHDDを搭載しているものでも優れたデータ削減率とパフォーマンスへの問題がないことをお見せいたしましょう。では実際のお客様のホンモノの環境の結果について見ていきます。

私がこれから共有するすべての結果は私自身、もしくは私のNutanixの同僚へと送られてきたものので、その環境はすべて標準のハイブリッドシステムのものであり、そのユースケースは様々に異なったものです。私はNutanixのデータしか持ち合わせていないので、結果はNutanixを利用した場合のものですが、他のシステムでも似たような結果が得られるか、その結果が異なる場合もあるでしょう。これは動作させているシステムが異なれば結果も様々だからです。

以下の結果はサーバーワークロードのもので、簡単に圧縮できるデータを多く保持している場合のものです。ですから、非常に良いデータ削減率を示しています:

Fig149_2

このケースではデータはExchangeのJetStressテストを用いたものです。JetStressのデータは容易に圧縮ができるもの(メールデータ)ですから、圧縮にチューニングされたあらゆるシステムにおいて不適切な(以上に高い圧縮率)な結果を提示することになります。ですから、JetStressでテストを行う場合には圧縮をオフにするのが良いと思います。もしもストレージシステムが圧縮をオフに出来ないような場合には、実環境での結果を得ることはできません(JetStressの結果ではなく、実際の場合の結果です)。

次なる結果はOracle RACデータベースのものです。データベースはTPCCのようなトランザクショナルデータを格納しています。ですから、非常に良いデータ削減率を得られます。しかし、単なるテキストほどではありません。

Fig150

次の例はVMware環境のための管理クラスタのものです。ここにはvCenter、vCenterデータベース、VMwareの管理ツール、Microsoft AD、DNS、そしてSQLサーバやPostgreSQLデータベースのような他のシステムのバックアップコピーがおかれています。

Fig151

既に圧縮されているバイナリデータが多くあり、上記の結果となります。データ削減の効果としてはわずかです。

では、実際に本稼働しているExchangeシステムの環境ではどうでしょうか? ここにはExchange環境をNutanixで運用されているお客様の例を持ってきました。20,000以上のメールボックスの環境です。あらゆるタイプのメールデータが含まれています。

Fig152

eメールのデータと言うものは環境によっては他の環境と全く異なるデータになりがちです。ここには別のeメールのサンプルがありますが、今回はEnronのEmailデータベースのデータになります。Enronは上場倒産をしてしまった会社で、その後、負のバランスシート遺産や借金を抱えていました。eメールデータベースは裁判所の処理のために公開されることになったのです。ですから、データ削減技術のためのテストにはまたとないデータです。

Fig153

今回は圧縮を利用しています。圧縮はデータに共通部分が見つからないようなデータの場合には良い選択です。しかし、重複排除、圧縮、そしてイレイジャーコーディングのような他の削減技術を同時に利用して、できうる最高の削減率を得ることも出来ます。そもそもプラットフォームは実際のデータを下にして、最高の技術を提供すべきです。

VDI環境を含む特定のタイプのワークロードはフルクローンでも、リンククローンでもいずれの場合も重複排除から非常に良いデータ削減結果を得ることが出来ます。フルクローンの環境ではほとんどすべてのデータを重複排除できるため、重複排除で最高の削減結果を得ることが出来ます。重複排除と圧縮の療法を使って、可能な限りのデータの削減を行うことも出来ます。しかし、ここでは2つのVDI環境の例を挙げましょう。

Fig154

Fig155

上の2つの例は2つの異なるVDI環境で少しだけ異なるワークロードを動作させた結果の例です。しかし、圧縮と重複排除の技術の組み合わせによって、非常に大きな削減を実現していることがわかります。ですが、これらの環境は殆どがリンククローンの環境です。フルクローンのデスクトップではないのです。以下にフルクローンのVDIの環境における重複排除でのデータ削減の結果を示します:

Fig156見て明らかな通り、別々のワークロードのデータでの共通事項がほとんどであれば、極端なほどのデータ削減率を期待することが出来、こうしたワークロードのための物理的なスペースは非常に小さくて済むのです。

今までのところ、さほど異なるタイプのワークロードをのみしかカバーできていませんし、比較的小さな規模のものです。では、大きな環境へとスケールアップして、更にエンタープライズで利用されるようなタイプのワークロードになるとどうでしょうか?

Fig157

上のイメージは10ホスト、70台の大きい仮想マシンを運用しているやや大きな環境からのもので、大きなIOを多く行っています。この例では、削減されたデータサイズは175TBです。ですが、私はこれ以上の値も実現出来ると考えています。さぁ、もうちょっとだけ大きな本か同環境を見ていきましょう。

Fig158

上の例はSQLサーバとアーカイブデータを含む混在ワークロード環境となっている大きなNutanixからの例です。今回は全体としてのデータ削減は570TBです。

Fig159

上の2つのサンプルはそれぞれ32ノードのNutanixからなる2つのクラスタの例です。ワークロードは一般的なサーバ仮想化で、一方はマイクロソフトのアプリケーション、もう一方ではLinuxベースのアプリケーションが動作しています。

Fig160

上の例はLenovo HXアプライアンスで動作している4台のオールフラッシュノードからなるクラスタものです。データはOracleとSQLサーバデータベース、それから僅かなVDIデスクトップの混在環境です。

Fig161

上のイメージは26ノードのハイブリッドクラスタで様々なノードが混在しており、20TB以上のデータベースと他のアプリケーションがまたがったものです。

終わりに

オールフラッシュはデータ削減に必要不可欠なものではありません。上で見てきたように、大きなデータ削減とそれなりのパフォーマンスを得るためにオールフラッシュを使う必要はないのです。ハイブリッドストレージ環境でも優れた削減効果を得ることが出来ますし、オールフラッシュにしたいということであれば、そこでも同じような優れたデータ削減効果を得ることが出来ます。ですが、ハイブリッド化、オールフラッシュか、という事を決めるのはあなた自身です。いずれのタイプの環境でも同じ削減効果を得ることが出来ます。理由はこれは保存されているデータそのもので決まるからです。

特殊なハードウェアを用いなければ優れた削減効果とパフォーマンスを彫らないとうこともありません。上のすべての結果はソフトウェアのみで得られる結果で、特殊なハードウェアは必要としません。パフォーマンスと削減効果はデータのタイプに依存します。パブリッククラウドは特殊なハードウェアには依存しません、どうしてプライベートクラウドでだけ、それが必要なのでしょうか?

データ削減結果をきめるもっとも大きな要素は保存されているデータのタイプです。もちろん、データ削減の技術はベンダー毎に異なります、ですが、もっともデータ削減効果を決める最も大きな要素は保存されているデータのタイプです。スナップショットを利用してそうでもないのにそれを重複排除であると呼ぶようなおかしな比較はスルーして下さい。暗号化されたデータ、画像のような既に圧縮されているデータのような上手く削減ができないデータのタイプであればとても貧相な結果になってしまいます。同じOSや同じアプリケーション、ドキュメントとして保存されているデータ、テキストやデータベースのようなテキストタイプの削減のよく効くデータでは非常に優れた結果を得ることが出来ます。この結果から、システムは複数のデータ削減施術を利用できるということが重要な事になります。これによって実際に存在するデータに対して最高の削減効果を得ることが出来るからです。

圧縮が有効になっている場合、幾つかのベンチマークテストでは正しい結果が得られない場合があります。圧縮や重複排除をオフにすることが出来ないシステムの場合、Exchange JetStressのようなタイプのベンチマークテストでは正しい結果を得ることが出来ません。これはこうした結果を本稼働環境を選定する際には利用ができないということです。

スナップショットとクローンは上の結果には含めていません!スナップショットとクローンはメタデータ操作のみを利用し、データを増加させることはありません、ですから、データ削減の結果には含めておらず、Nutanixのプラットフォームではレポートしません。こうした操作では新しいデータを新しいWriteを受信するまではストレージの利用を増やすことはありません。ですから、いくらでもクローンやスナップショットを好きなだけ作ることが出来ますし、利用可能なストレージ容量に影響はありません。他のベンダーはデータ削減にこうしたデータを含めるという選択をしていることが有ります、しかしNutanixは実際のデータパターンに対しての現実の圧縮またはデータ重複排除の結果のみをレポートしています。

これらを全て加味してみてください。データ削減は保存しているデータ以外の何物にも依存しません。これによってご自身の環境での結果は様々になります。現実環境のデータと現実のワークロードで事前に検証をしてみる事をオススメ致します。そうでなければご自身の環境、ワークロードでの実際の削減効果を知ることは出来ません。記事内で匿名でイメージを送ってくださり、記事内での利用を許可してくださったお客様に大変感謝致します。

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

Ntc2017_2

本記事は実は、これから翻訳しようとしている記事からも引用されているのと、いよいよオールフラッシュの時代が到来しようとしている今だからこそ、読んでいただきたい内容です。オールフラッシュだから「重複排除や圧縮をやってもパフォーマンス的にOK!」という理論はこれは一見その通りに見えるのですが、実は非常に危険な誤解をはらんでいます。

上で述べられているとおり、削減効果はデータ次第なのですから、「オールフラッシュだから」というのはまったくもってナンセンスなのです。仮想マシンのためのIO(フロントエンド)さえ処理できてしまえば、後から遅延実行可能な重複排除や圧縮をおこなえますし、遅延実行しなくてはならないタスクが増えてきた場合でも、Nutanixのような分散アーキテクチャであれば、忙しいノードとは別のノードがその処理を行えばよいのです。(RF-2で冗長化している場合でも、データは仮想マシンが稼働しているホスト以外のノードにも必ず存在しますので、フロントエンド処理とバックエンド処理を分散できます。)

オールフラッシュなら重複排除や圧縮も可能! というのは何でもかんでも単一筐体の中で処理をしている従来型SANの理論で、逆を返すとオールフラッシュでないと重複排除や圧縮が間に合わない、ということになります。

どうでしょう? 実は、この話はPernixDataのストレージの「パフォーマンス」と「キャパシティ」と「データサービス」を分離すべきであるという思想と完全に一致します。しばらくオールフラッシュ系の翻訳を続けます。次回も乞うご期待!

2017/01/05

Nutanix関連記事まとめ

Nutanix関連記事が多くなってまいりましたので、まとめページを作成いたしました。

Nutanixの技術を知りたいといえば、まずここです。

翻訳をさせていただいている元記事のブログはこちら。

当社のNutanixチームのTwitterも是非フォローください!


Andre Leibovici氏のBeyond Marketingシリーズ和訳


Salle Designより: Nutanixの事例 ~Nutanix Prismが生まれるまで~シリーズ


知っておくべき10つの事シリーズ


エンタープライズクラウドソリューション


パフォーマンス・オールフラッシュ


ファイルサービス関連


ネットワールドSEによるやってみた! シリーズ


.NEXTカンファレンスレポート


PernixData関連


その他

2016/12/28

Nutanix Acropolis ファイルサービスについて知っておくべき10つの事

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のProduct Marketing Managerを務めるShubhika Taneja氏によるものです。原文を参照したい方はTen Things you need to know about Nutanix Acropolis File Servicesをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

我々はすばらしい機能それぞれについて、将来のリリースで含まれる機能をご紹介する新しいブログシリーズ「10つの知っておくべき事」をスタートします。以前のリリースで、この将来のリリースの機能の登場は多くの素晴らしい機能、例えばAcropolis ファイルサービス、セルフサービスポータル、ネットワーク可視化、その他たくさんなど、は予告されていたものです。ではまずAcropolis ファイルサービス(AFS - Acroplis File Service)についての10つの知っておくべき事から初めましょう:

  1. AFSを利用すれば別途ネットワーク接続ストレージ(NAS)アプライアンスを用意する必要はなくなります。AFSはソフトウェア定義のスケールアウト型ファイルストレージソリューションでSMB/CIFSの幅広いユースケースをカバーできるように設計されており、Windowsユーザープロファイルの格納や、ホームディレクトリ、組織間での共有を実現できます。あらゆるAVHまたはESXiのクラスタ上で有効にすることが出来、Nutanixの管理ソリューションであるPrismから2,3回クリックするだけで利用することが出来ます。
  2. AFSは完全にNutanixのエンタープライズクラウドプラットフォームのコアコンポーネントと統合されています。既存のクラスター上に展開すること、スタンドアローンのクラスタに展開することの療法が可能です。スタンドアローンのNASアプライアンスとは異なり、AFSは仮想マシンとファイルストレージを統合することが出来るため、別々のインフラストラクチャのサイロを作る必要はなくなります。AFSも仮想マシンサービスと同様にNutanix Prismから管理を行うことが出来るため、管理の統合、簡素化を実現します。
  3. AFSはそれを支えるNutanixエンタープライズクラウドプラットフォームからインテリジェントな階層化、重複排除、イレイジャーコーディング、圧縮、そして分散化による自己治癒などの優れたエンタープライズストレージの機能を継承しています。
  4. AFSは最低で3台のファイルサーバ仮想マシンを必要とし、それぞれのファイルサーバ仮想マシンは最低 4 vCPU、12GBのメモリを必要とします。AFSクラスタのパフォーマンスは簡単にスケールアップ(vCPUとメモリをさらにファイルサーバ仮想マシンへ追加する)またはスケールアウト(ファイルサーバ仮想マシンを更に追加する)によって、改善することが出来ます。
  5. AFSはSMBをサポートし、Active Directoryと連携して動作します。
  6. AFSはユーザーと共有のクオータをサポートします。
  7. AFSはアクセスベースのイニューメレーション(Access Based Enumeration - ABE)をサポートします。
  8. AFSはWindowsの以前のヴァージョンの復元をサポートしており、ユーザーによるセルフサービスでの復元を実現します。
  9. 共有領域の3rd パーティによるバックアップについてはCommvault社などのベンダーから提供される従来からのファイルバックアップを利用することが出来ます。バックアップは別のNutanixクラスタまたは、パブリッククラウド(AWSとAzure)に対して行うことも出来ます。
  10. AFSでは別のNutanixクラスタへの統合された自動災害復旧を利用することが出来ます。

Fig148

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

さて、ネットワールドらぼではNutanixコミュニティではじまった「10つの知っておくべきこと」シリーズの翻訳を行っていきます。まずはAFS。これ自体はファイルサーバの機能を提供するだけ(もちろん、Nutanix流にスケールアウトしますので、サーバ1台単位でのPay-as-you-growなのは魅力です!)なのですが、素晴らしいのはNutanixクラスタ内に共存させることが出来るということです。仮想マシン用のストレージとファイルサーバストレージ、ほとんど似たような(もしくはユニファイドで同じ筐体にすることもあるでしょうが・・・)ソリューションを別々に管理したいとは誰も思っていないはずです。Nutanixではこれに加えて更に仮想環境の管理も統合することが出来ますので、社内のITインフラの管理をあの優れたPrismだけで行うことが出来てしまうのです。

今後も様々なSMB/CIFSのユースケースに対応するようなロードマップがひかれているようですので、今後ファイルサーバ専用機はなくなっていく、、、正にWikibonのServer-SANについての予測を象徴するような機能についての10つの知っておくべきことでした。

2016/12/23

NutanixでのVDI/SBCサイジングの実践

こんにちは、ネットワールドの海野です。

Nutanix Advent Calendarということで、 ネットワールドらぼ には初めての投稿です。

今回の記事ではNutanix環境におけるVDIとSBCについて、実践的なサイジングへのアプローチをご紹介しようと思います。

※注1 : NutanixのSizerは定期的にアップデートが行われ、画面や設定内容が変更や調整されます。ご利用時点の最新版とは異なる可能性がございますので、ご了承ください。

※注2 : ここでご紹介する構成やスペック値はサンプルとしてご提供する情報であり、何らかの保証を行うものではございませんので、ご了承ください。

自己紹介

ネットワールド入社当初からCitrixの製品を担当しており、ふだんはXenDesktop(VDI)/XenApp(SBC)のプリセールスSEとしてお問い合わせ対応や構築作業のほか、トラブルシューティングに関するご相談を受けたり、当社で開催しているセミナーや無償ハンズオントレーニングの講師をしています。

よくいただくご相談 : サイジング

その中でよくご相談をいただくのが「XenApp/XenDesktopの推奨スペックとハードウェア構成を教えてください!」というものです。

いわゆるサイジングのお話です。

今年のNutanix Advent CalendarではNutanix島崎さんがSizerに関する記事を寄稿されていますが、このSizerを利用することで複雑と思われがちなVDIやSBCのサイジングや機器選定という課題をシンプルかつスマートに解決することができます。

基本的なSizerの概要や使い方については島崎さんの記事をご覧ください。

Sizerを使ったサイジングの前に…! 要件を整理しましょう

サイジングと機器選定というゴールに向かうためには要件の整理が必要です。

まずは要件を整理し、Sizerへのインプットに落とし込んでいく作業を行います。

私がご相談を受ける際にお客様へお伺いする主な内容としては、以下の項目が挙げられます。

・利用目的と利用形態

・想定負荷とユーザー数

・仮想マシンの展開方法

・冗長性

・接続元

今回のサイジングシナリオはこちら

というわけで、シナリオ(お客様のご要望)を以下のもので想定します。

・利用目的と利用形態 : テレワーク実現のためのXenDesktop(VDI)環境

・想定負荷とユーザー数 : Officeドキュメントの編集やブラウザー閲覧などの300ユーザー

・仮想マシンの展開方法 : Machine Creation Services (MCS)

・冗長性 : あり

・接続元 : テレワーク実現なので、社内以外に社外からも接続する

実践その1 : Sizerにどう入力していくか? (ユーザー用のリソース)

では、このシナリオをもとにSizerに入力していきます。

Sizerを起動し、シナリオの名前(SCENARIO NAME)を入力します。

ここでは「VDI for Telework 300 Users」としました。

01

まずはユーザーさんが業務で利用するためのVDIリソースをXenDesktopのワークロードとして追加します。

02

今回のシナリオでは「Officeドキュメントの編集やブラウザー閲覧など」という使い方を想定しています。

Sizerではその用途にピッタリの"Knowledge Worker"という選択肢がありますので、これが300ユーザー分という入力をします。

なお、ここではワークロードのカスタマイズなどは行わず、冗長性に関する内容もデフォルトのままで進めます。

03

すると、このような結果が表示されました。

今回のシナリオのVDIリソースを賄うには、このNutanixがよいという指針になります。

04

管理コンポーネントのリソースを追加する前に… (コンポーネントの整理と確認)

XenDesktopを利用するためには仮想デスクトップだけを用意すればよいというものではなく、さまざまな管理コンポーネントが必要です。

Sizerを利用して管理コンポーネントのリソースを追加していきましょう。

XenDesktopの管理コンポーネントとして代表的なものをここにピックアップします。

・Delivery Controller

・StoreFront

・SQL Server

・Citrix License Server

今回のシナリオでは、論理的な障害に備えて各コンポーネントを冗長化する方針とします。

さらに、可能な限りWindows Serverの台数を削減するべく、複数のコンポーネントを同居させる構成とします。

それを踏まえ、弊社の無償ハンズオントレーニングでは以下のサーバー構成案をご紹介しています。

・サーバー1 : Delivery Controller / StoreFront / Citrix License Serverを同居

・サーバー2 : Delivery Controller / StoreFront / ウィットネス用のSQL Expressを同居

・サーバー3 : ミラーリングされたSQL Server (プリンシパル)

・サーバー4 : ミラーリングされたSQL Server (ミラー)

では、この1~4のサーバーですがどれくらいのスペックでサイジングをすればよいでしょうか?

詳細は弊社の無償ハンズオントレーニングで解説しておりますが、それぞれ次のようなスペックが目安となります。

・サーバー1 : 4vCPU / メモリ8GB / ディスク100GB 以上

・サーバー2 : 4vCPU / メモリ8GB / ディスク100GB 以上 (サーバー1と同じ)

・サーバー3 : 2vCPU / メモリ4GB / ディスク100GB 以上

・サーバー4 : 2vCPU / メモリ4GB / ディスク100GB 以上 (サーバー3と同じ)

この情報を使ってワークロードを入力してみましょう。

※注3 : 上記のスペックはあくまで一例です。シトリックス社からはサイジングについて以下のホワイトペーパーが提供されていますので、こちらもご参考としてください。

Citrix VDI Best Practices for XenApp and XenDesktop 7.6 LTSR

実践その2 : 管理コンポーネント用のリソースを入力

ここでは入力をシンプルにするために、Workload Typeを「Server Virtualization」で進めます。

ワークロードの名前は「Management Resource」としました。

05

先ほど紹介したスペックの目安を満たすために、Server Profileは「Large」を選択します。

Server Profileについては島崎さんの記事に解説があります。

06

また、ここでもワークロードのカスタマイズなどは行わず、冗長性に関する内容もデフォルトのままで進めますと、入力した結果が反映された内容が表示されます。

07

実践その3 : NetScaler Gateway VPXのリソースを入力

社内でXenDesktopを利用する分には以上の内容で十分ですが、今回の想定シナリオは「テレワーク実現のためのVDI」ということで、社外から社内への接続を実現する仮想アプライアンスであるNetScaler Gateway VPX(以下、NS VPX)のリソースを追加していきます。

なお、NS VPXを利用する場合、ユーザーデバイスに対し画面転送データのみをやり取りするためファイルが手元の端末に残らないような使い方ができるなど、一般的なVPNと比較して非常にセキュアであるということが強力なメリットとして挙げられます。

ここでは、NS VPXのワークロードもServer Virtualizationで入力します。

08

NS VPX バージョン11.1のデフォルトの仮想マシンスペックは、Server Profile : Mediumで満たすことができます。

また、XenDesktop管理コンポーネントと同様に冗長化を考慮して、2台のNS VPXを配置します。

09

最終的なXenDesktop環境のサイジング結果

Sizing Summaryはこのようになりました。

リソースの使用率は上がりましたが、変わらず4ノード構成でOKという結果が表示されました。

検討に必要な材料(要件)があれば、とてもカンタンにサイジングと機器選定ができるということがお分かりいただけるかと思います。

10

XenAppはどうする?ユーザー数の変更はどうする? : シナリオのクローン

Sizerではシナリオのクローン機能を使うことで、簡単にいろいろなパターンを検討することができます。

いま作成したシナリオをそのままXenAppでの300ユーザー構成に置き換えてみましょう。

まず、作成したシナリオのクローンを行います。

ここでは「XenApp for Telework 300 Users」としました。

11

既存のWorkloadsからVDI用に設定した「User Resource」を削除し、新たに「XenApp Resource」を作成します。

Workload Typeは「RDSH/XenApp」を選択します。

12

Windows Server 2012 R2上で動作するXenAppの想定で入力を進めます。

13

ここではサンプルとして以下の値を入力しました。

なお、ドキュメントを編集するユーザーを想定していますので、ユーザープロファイルなどは大きめに見積もっています。

14

そのままデフォルト設定を前提とすると、数クリックでサイジングの結果が出力されます。

15

その他、ユーザー数の変更であれば同様にシナリオをクローンし、ユーザー数を調整するだけでサイジングを行うことが可能です。

まとめ

Sizerを使えばとてもカンタンに複数のサイジングや機器選定のプランニングをすることができます。

XenDesktopやXenAppの基盤をNutanixでご提案いただき、スピード感のあるサイジングと機器選定を試していただければと思います。

 

しかしながら、どのコンポーネントをどういったスペックで組むかというのは、ノウハウや経験が必要な部分であり、難しく感じている方もいらっしゃるのが実情かと思います。

当社では定期的にXenApp/XenDesktop/NetScalerの無償ハンズオントレーニングを実施しており、当社の経験に基づく最新情報をご提供しております。

さらにNutanixについてもイベントを開催しておりますので、今後も当社のイベントにもご期待いただければと思います。

2016/12/21

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

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

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

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

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

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

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

これは本シリーズの4番目の記事です。最初の記事はこちら2つ目3つ目

免責事項 : あらゆる将来の製品又はロードマップ情報は製品の方向性を示すことを意図しており、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による期待通りのパフォーマンス
  • NCC 3.0 の Prism への統合
  • 1-ノード レプリケーションターゲット
  • QoSによる混在したワークロードのサポートの改善
  • SATADOMの交換ワークフローのシンプル化
  • 適応型レプリカ選定によるノード混在のサポート
  • 動的なイレイジャーコーディングのストライプの縮小 - ノードの削除時
  • メタデータ用のノード上の利用可能な複数のSSDをメタデータディスクとしてサポート
  • コンテナにおけるイレイジャーコーディング(EC)のレプリケーションファクタ(RF)の変更のサポート
  • OpLogのインライン圧縮
  • (New) Linux カーネルアップグレード

私はNutanix 5.0の新機能についてのアナウンスは全て終えたと思っていましたが、読者のうちの一人 Tom Hardy氏がAHVのLinuxカーネルアップグレードについて紹介し忘れているよ!と教えてくれました。間違いを犯したときに喜んでサポートしてくれたり、注意をしてくれる素晴らしい読者がいるのはありがたいことです。Tomさんありがとう! 

Linux カーネルのアップグレード

NutanixのAHV(またの名をAcropolisハイパーバイザ) はLinux カーネルをヴァージョン4.4.22へとアップグレードしました(現在のLinuxカーネルは2.6.1です 更新:これは間違いでした、現在AHVのLinuxカーネルは3.10.0-229.26.2でした)。Linux 4.4の全ての新しい機能と改善点はこちらをご参照ください。このリリースの素晴らしい機能はもちろん、様々なバグやセキュリティの修正がKVM、QEMU、そしてlibvirtへと含まれています。

Fig146

カーネルについてのヴァージョン3.10.0とヴァージョン4.4.22の間すべての変更についてはこちら。ですが、AHVの一部としてすべての機能を取り込んでいるわけではなく、NutanixはNutanixソリューションに必要な部分のモジュールのみを取り込んでいます。これは小さく固めることで、攻撃対象ととなりうる部分を減らし、ソリューションとしてより安定、よりセキュアにするためです。

個人的に、カーネルのアップグレードに付随して重要になると考えている幾つかの改善点を取り上げます。 

仮想GPUドライバーによる3Dのサポート

virtio-gpuは仮想化ゲストのためのドライバーで、ホストに搭載されたグラフィックスカードを効率的に利用できるようにするためのものです。今回のリリースでは仮想化ゲストがホストのCPUを3Dのレンダリングの高速化に利用できるようにする機能が含まれています。実際のところ、これは仮想化されたLinuxのゲストOSがOpenGLのゲームをホストのGPU高速化機能を使って動作させる事ができるようにする、というもので、こちらや tこちら でビデオを見ることが出来ます。 (重要 – GPUによる高速化はAOS 5.0ではまだサポートされていません、しかしこのアップグレードによってAHVは今後のサポートのための足がかりを作ることになります。

ヒュージ(巨大)ページのサポート (または ラージページのサポート)

ヒュージページはLinuxカーネルが近年のハードウェアアーキテクチャにおける複数のサイズのページを取り扱うことが出来るようにするメカニズムです。ヒュージページはオペレーティングシステムが標準(大抵の場合4KB)よりも大きなページのメモリをサポート出来るようにします。非常に大きなサイズのページを利用することで、システムリソースの総量を減らし、システムのパフォーマンスを向上させることが出来ます。

ヒュージページは32ビットでも64ビットの構成でも有効です。ヒュージページのサイズは2MBから256MBまで、カーネルのヴァージョンとハードウェアのアーキテクチャに合わせて変更することが出来ます。

One more thing!

ここで親愛なるPlexxiと共に作り上げた素晴らしいソリューションをご紹介したいと思います。Plexxiは自身のファブリックの利用率をNutanix Prismへ統合しまし、Prismを根本的にデータセンタ全体に渡るコンピューティング、ストレージ、そしてネットワークファブリックの単一コンソールにしてくれました。これは実際に非常に賢く、とても優れています。今後テクノロジーパートナーが新しいNutanixのヴァージョン3.0 APIを利用してもっと面白いソリューションが出てくることを期待しています。

Fig147_4

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

Part 3で終わりと思いきや、Part 4があるという。。。Nutanixの機能は底なしです!今回はLinuxカーネルについてのアップグレードですが、ラージページ、GPUなどオープンソースからの恩恵でどんどん良くなっていきますね。GPUについては現在はESXiしか選択肢がありませんが、XenServer、行く行くはAHVでも利用ができるようになりそうです。また、最後のソリューションのPlexxi、ウィーンの展示会場でも見てきましたが、なかなか面白いですね。もともとGoogleのために作っていた、ということでした。何よりPrismがプラットフォームとして他社の製品情報を表示するようになってきていますので、今後はこの美しいインターフェイスだけみていれば良くなる・・・と嬉しいなぁ。プラットフォーム連携しても統一感のあるインターフェイス、ユーザビリティを実現するのは難しいと思いますが、是非頑張ってほしい。

2016/12/16

vSphere DRSとNutanixの親和性は悪いっていう都市伝説は本当なのかやってみた ~前編~

vSphere DRSとNutanixの親和性は悪いってどういうこと?


弊社でも今年の9月からNutanixの販売を開始しましたが、よくある質問の1つにNutanix上でvSphere DRSを使っちゃいけないの?というものがありました。

私はvSphereもvSANもNutanixもちょっとわかるくらいの知識はありますので色々考えてみたのですが、なんかそんなことを言われる技術的要因もあまり心あたりがないので「都市伝説です!」ということにしています。

ただこんな都市伝説が流れるということは、何か正しく伝わっていないのだろうということで、弊社のWebセミナーのやってみたシリーズでお話した内容をこうしてブログで公開してみたいと思います

vSphere DRSとは?


まずNutanix云々という前にvSphere DRSについておさらいをしてみましょう。
皆さんvSphere DRSの機能というと「vSphereクラスタ内のホストの負荷の偏りをなくすために仮想マシンを自動的にvMotionする機能」と認識していると思います。ところがvSphere DRSがvMotionする条件はなかなか知られていないのが実情です。

例えば、ホストが3台あって、ホストAがCPUが50%、ホストBがCPU利用率が10%、ホストCがCPU利用率が0%の場合、ホストAで稼働する仮想マシンをホストCに移動するのでしょうか?

50:10:0なので不均衡なのでDRSのトリガーとなってホストA上の仮想マシンが数台、ホストCにvMotionされると思うかもしれません。いかがでしょうか?

ところがこの程度の利用率ではDRSが自動的に仮想マシンをvMotionすることはありません

なぜでしょうか?vMotionは確かに無停止で仮想マシンを違うホストに移動することができます。しかし何のデメリットもないわけではありません。

vSphereのバージョンアップでvMotionの進化につれて小さくなっていますが、稼働するホストを切り替えるときに多少の性能劣化が発生するのです。

そのためDRSは性能に困ってない仮想マシンを無理に移動するようなことをして例え瞬間的とはいえ性能劣化を起こすようなことはしないのです。

先ほどの例でいうと、ホストAがCPU90%、ホストBがCPU利用率50%、ホストCがCPU利用率10%というような、特定のホスト上で性能劣化が発生するくらい負荷が
高くなり、クラスタ内にリソースの余裕がある移動先ホストがあるときだけvMotionするのです。非常によく考えられていると思いませんか?

Drs_2

こうしてみると、vSphere DRSは「仮想マシンが遅くなるくらいリソースが不足してきたとき、事前に自動的にvMotionする機能」ということができます。

vSphere DRSは頻繁にvMotionするわけではないということはご理解いただけたでしょうか。なのでもっと皆さん怖がらずに積極的に使ってください…。

こうしたDRSのアーキテクチャの詳細はvSphere 6.5に対応した以下のドキュメントで解説がされています。興味のある方は是非1度読んでみることをお勧めします。
DRS PERFORMANCE VMware vSphere 6.5

では今回はここまでにして次回の最終回で、Nutanix側のアーキテクチャと弊社の検証結果についてまとめたいと思います。お楽しみに!

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/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さんはもう次の記事に取り掛かっているそうです。次はタイムリーに公開できるようにがんばります!