*Nutanix Feed

2017/03/29

Nutanixはたくさん買ってはイケナイ!

本記事はNutanix社のオフィシャルブログの翻訳版です。原著者はNutanix社のVP of Client Strategyとして活動しているSteve Kaplan氏です。

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

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

Fig192「それはつまり・・・Nutanixをたくさん買ってはイケナイと言っているのですか?」

東京でとあるCIOが私が経済的なモデル化の方法を説明した後に私に言った言葉です。私の隣には営業マンが座っていましたので、ちょっと具合が悪かったのですが、私は「そうです、経済性のモデルの観点から言うと、どうして必要以上にNutanixを買う必要があるのでしょうか?まず一つに、将来的に買収されたりすることもあるかもしれませんし、そうでなくても追加で購入するという必要性は出てきます。それ以上に今の実装が気に入ったとして、それを拡張したいと思うはずです、そのときには実際に製品が必要なタイミングまで待てばいいのです。最初にまとめて購入するときよりも、より少ないノード数で住むようになっているはずです。」

Nutanixの営業チームはなぜNutanixのエンタープライズクラウドがゲームを変える技術であるかをよく理解して、組織への提案を行います。クライアント戦略チームの役割はNutanixがどのようにゲームの経済原理を変えるのかをお見せすることです。

NutanixはITの経済原理と運用のあり方を無数の方法で再構築し、そのうちの多くが様々なアナリストのレポートとしてドキュメント化されています ー IDC(TCO/ROI)、IDC(組織の変革)、そしてESGなのです。もっとも強力な経済的なメリットはNutanixの1クリックのソフトウェア定義のアップグレードと段階的な消費の能力をムーアの法則と関連付けられて語られる継続的な技術の進歩と組み合わせたところにあります。

段階的な消費

オールフラッシュ装置を含むSANは拡張性に制限を持つこと以外にもいくつかの経済的な課題を抱えています。従来型の3階層のインフラストラクチャ(集中化されたストレージ+ストレージネットワーク+コンピューティング)では、新しいストレージを追加することは新しいインフラストラクチャのサイロの追加と苦痛を伴うデータの移行作業が必要になります。

結果としてSANを購入した場合には大抵、必要な以上に最初から多くの容量を購入して置かなくてはいけませんが、これはラックスペースや電力そして空調のコストが嵩む上に、余分なハードウェアの減価償却まで行う必要が出てきます。そして、必要以上のSANの容量があるにも関わらず、決められた製品の更新日時までには会社はフォークリフトアップグレード(機材の全取替)を行う必要があるのです。

Fig193

Nutanixはマウスを1回クリックするだけで追加ノードをクラスタに追加でき、古いノードはかんたんに退役、もしくは目的を変更することができるという根本的に異なる利用体験を提供します。これによってクラスタは「成長」し、サイロと苦痛を伴いデータ移行はなくなるのです。

Nutanixのキャパシティのフォーキャスティングとモデル化の能力によって、今後の需要を予測はとても簡単になります。そして一口で食べ切れるだけのサイズのインフラストラクチャを購入するほうが大きな単位での購入するよりもチャージバックもしくはショーバックシステムのセットアップは簡単になります。

1クリックのソフトウェア定義のアップグレード

もう一つのSANが抱える経済的な課題はファームウェアとその下のプロプライエタリハードウェアの密な連携の結果です。SANを利用しているお客様はSANのファームウェアの新しいヴァージョンをダウンロードすることができず、3年間経年した古い装置が新しい装置として振る舞うことはありません。

Fig194一方でNutanixを利用しているお客様では、それをまさに行うことができます。1クリックでいつ導入したのか、どこにあるのかにかかわらずノードをアップグレードすることができ、最新のNutanix Acropolis オペレーティングシステム(AOS)にするだけではなく、サーバのファームウェアやハイパーバイザーさえもアップグレードすることができます。これらのアップグレードは基本的に自動化されており、ローリングで行われ、1つのノードがオフラインになり、アップグレード検証されて、オンラインに戻り、次のノードへという動きをアップグレードが完了するまで繰り返します。

以下の写真は自身のNutanixノードをテスラ(電気自動車)からアップグレードしている際につぶやかれたツイートです。私は一度、あるお客様がビーチでバケーションを楽しんでいる最中にiphoneから本稼働環境をアップグレードしたと言っているツイートを見たこともあります。こうしたことをNutanixはベスト・プラクティスとして推奨しているわけではありませんが、1クリックアップグレードはそれができるほどにシンプルなのです。

Fig195

すべてのノードが同じAOSで動作し、単一のPrism管理画面から管理できるだけでなく、AcropolisブロックサービスやセルフサービスポータルなどのAOSの最新のリリースで登場した新しい機能を利用することも可能です。そしてNutanixは継続的に、そして劇的にそのソフトウェアを改善し続け、パフォーマンスとキャパシティの双方を改善させます。

先に出てきたMattias Sundling氏のツイートはその一例で、ディスク容量をTBの単位で改善させました。以下のHugh Devaux氏のツイートはAOS 4.5から4.72へのアップグレードの際にIOPSが40%も向上し、レイテンシが50%も低減したというものです。

Fig196このパフォーマンスとキャパシティの改善はノードあたりの仮想マシンの密度を更にあげられるということを意味します。Nutanixのお客様は、追加のコストなく ーそもそも全くハードウェアに触ることすらなくー保持しているノード全体で動作させられる仮想マシンの数を増やすことができるということです。Nutanixの環境を拡張するにつれて、徐々にSAN(英語?フランス語?の洒落・・・日本語にできませんでした・・・)時代に必要だったノード数よりも少ないノード数しか必要となくなり、1クリックアップグレードでそれが更に改善されていくのです。

ムーアの法則

ムーアの法則はプロセッサ上のトランジスタの数が18ヶ月ごとに倍になるということを宣言したものであり、長きに渡ってIT産業を牽引してきました。ノートPC、ワールドワイドウェブ、iPhone、クラウドコンピューティングそして、直近ではソフトウェア定義のインフラストラクチャがその例で、これまでにないスピードのCPUによって実現されてきました。

様々な懸案にもかかわらず、技術革新による継続的なパフォーマンスの向上に終わりは見えません。これはパフォーマンスをどのように達成するかという原理が例えばコアをより増やすこと、光通信やメモリスタなどと、当初と変わってきていたとしてもです。例えばNVMeはすでに利用できますし、3DXPointがすでに地平線から昇ってきつつあります。

Nutanixのお客様はご自身のプロジェクトを何年も先まで継続して拡張することができます、ハードウェアがその密度を上げ、同じワークロードを動作させるのに必要なノード数が減少していきます。この数字はソフトウェア定義の1クリックアップグレードで既存のノードの密度も追加することもできるため、より少なくなっていきます。

以下のテーブルはどのぐらいの能力を得ることができるのかということを経験則から導き出したものです。このチャートは組織がVDIへと移行する際のものですが、あらゆる仮想化ワークロード:Splunk、ビッグデータ、プライベートクラウド、サーバ仮想化、災害復旧、拠点、ユニファイドコミュニケーション、SAPまたはOracleベースのERP環境などについて適用することができます。この例では5,000台のPCが5年間かけて入れ替わっていきます。つまり平均して1,000ユーザーが毎年マシンを入れ替えていきます。

更新のタイミングでPCをアップグレードする代わりに、情報システム部門はそれをシンクライアントとして動作するようにロックダウンし、ユーザーは仮想化デスクトップをもらうようになります。この例では最初の1,000ユーザーが更新を迎え、データセンタ内の8ノードのNutanixノードで仮想化デスクトップを動作させています。

Fig197

ソフトウェア定義の1クリックアップグレードとハードウェア定義の技術革新の間で、もしも平均的に密度が毎年25%向上するとすると、次の2年目の1,000ユーザーの更新のためには6台のNutanixノードしか必要でなくなるということです。そして、最後の年の1,000ユーザが5年後に更新を迎えるときには仮想化デスクトップのためのNutanixのノードは3台しか必要なくなっているということになります。

VDIのプロジェクトのための初期導入コストはラックスペース、電源、空調などと関連づいています。ですが、おそらくそれよりも重要な事はNutanixはすべての3階層の構成で購入後に迎えなければならない、新しいSANへの効果で高くつく(すべてのハードウェアの)入れ替えのリスクを排除できるということです。Nutanixのエンタープライズクラウドプラットフォームにはフォークリフトアップグレード(ハードウェアの全入れ替え)は存在しない概念なのです。

プラットフォームを販売し、製品を販売しない

私が事前に多くのNutanixノードを買ってはいけないという私の宣言をした後に、数秒の空白があり、そのCIOは「でも、それって売上を害するよ」と言いました。私は「そう、お考えになるのは最もです、ですが、我々は絶対にそうならないということを知っています」と答えました。

実際、Nutanixのお客様は多くのノードを購入されます - 実際に多く、何度も。例えば2016年の10月31日に終えたNutanixの四半期の終わりに、当社はGlobal 2000のお客様のうちの376社は結果として最初の導入の7.3倍もの購入がなされたとレポートしました。

Fig198私はそのCIOに対して、購入が増える主な理由は2つであると説明しました。最初の原因はお客様がNutanixを新しいユースケースのために導入しますが、すぐに売上が増える、開発者のビルド時間が減る、社員の生産性が改善するなどのビジネスメリットを目にすることになります。その結果だけで情報システム部門がプロジェクトの展開を加速し、何年も全体の実装のために待とうということをしなくなります。

2つ目の原因は単に、Nutanixを最初のユースケースのために展開した後、情報システム部門が環境のシンプル化、ダウンタイムの削減、アプリケーションパフォーマンスの向上などを目の当たりにし、Nutanixのエンタープライズクラウドが組織全体へ広がって、追加のユースケースでのプラットフォームとして採用されていくからです。

少きは多きに勝る

Fig199

私はこの記事の冒頭で我々の営業マンの前でNutanixをたくさん買ってはいけないと言うのが具合が悪かったとちょっとしたジョークを言いました。こうしたタイプのユーモアはお客様が多くの余分なストレージ容量を購入するような典型的な3階層の環境ではもちろんですが、全く同じことが仮想化とそれにまつわる結果としての「シェルフウェア(棚に並べられたソフトウェア)」にも当てはまります。Nutanixは成長するときにだけ支払う(Pay-as-you-grow)モデルをお客様に推奨するだけではありません、我々の営業はRunwayやSizerのようなツールを用いてお客様に現在必要としている以上のものを購入しないようにお客様を誘導します。

そもそもの始まりから、Nutanixは「少きは多きに勝る」という哲学を持っています。インフラストラクチャ、管理、アップグレード、そして仮想化から複雑性を取り除き、クラウドのようにシンプルで俊敏性がありながらも、オンプレミスの統制のある状態を作り出しました。必要とされているだけの購入で済み、プロジェクトが拡張していくほどに必要なノード数が減っていく、お客様には自身のビジネスを変革していくだけの削減効果を残します。

以下もご参照を

Disclaimer: This blog contains links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

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

Ntc2017_2

3月末公開予定の記事ですので、次年度(当社は12月が期末ですが、一般的な日本企業に合わせて3月期末のつもりで書いています)を始めるにふさわしい記事を持ってきました。「Nutanixはたくさん買ってはいけない!」衝撃的なタイトルですが、Nutanixプラットフォームにおいて、これは当たり前です。売り手側の心理はたくさん売りたいとなるのですが、Nutanixの消費モデルはこの売り手の心理とは真逆、買い手側の最も都合の良いロジックそのままです。この考え方はムーアの法則によるハードウェアの価格の下落とソフトウェアでアップグレードし続けることができるという保証さえあれば永遠に続くロジック・・・そしてメリットです。

Googleはなぜ検索の王者になったか? かんたんに無料で検索ができるというだけではなく、検索結果に挿入される広告ですら、Googleの検索を利用する人にとって都合が良いものであったからだと私は思います。Nutanixの消費モデルも同様で、お客様が理想とするクラウドの利用モデルをいちばん身近なオンプレミスで利用できる。誰もこれに反対する人はいないでしょう。最初のこの記事を読んだときからいつこの記事の和訳を公開しようかと考えていましたが、年度末最後の記事として公開させていただきました!

さて、来年度もエンタープライズクラウドの啓蒙活動をがんばります!

2017/03/22

Nutanix上でのインライン圧縮のパフォーマンスへの影響とオーバヘッドは?

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はWhat is the performance impact & overheads of Inline Compression on Nutanix?をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

よくNutanixのデータ削減機能、例えば重複排除、イレイジャーコーディング、そして圧縮などについて聞かれることがよくありますが、もっとも(そして、特に競合している状況において)よく聞かれるご質問の一つは:

「Nutanixのインライン圧縮のパフォーマンスへの影響とオーバーヘッドは?」

と言うものです。短い回答をすれば、私がNutanixプラットフォームに関して、覚えている限りではメリットがデメリットを上回ります、ということになります。

過去に様々なアプリケーション、ノードの種類、クラスタのサイズそして構成を検証してきました。そしてNutanix(と私)がOracleやMS SQL、そしてMS Exchangeなどのビジネスクリティカルアプリケーションを含む殆どの環境においてインライン圧縮のオーバーヘッドとパフォーマンスへの影響について共有しておくほうが良いと思い当たりました。

今回、MS Exchangeのためのストレージパフォーマンスの検証にはJetstressを利用しています。

(競合によるFUDを避けるため)特段環境に追加の設定を施すことなく、検証はシンプルに行われています。Windows 2012の仮想マシンを1台とJetstressの構成を行いました。そして、3 回、15分で完了するデータベースのチェックサムを取る動作を実施しました。

その3回の検証のあと、インライン圧縮を有効にし、同じテストを3回繰り返しました。

以下の図はNutanix PRISM HTML 5 ユーザーインターフェースがクラスタ全体のIOPS、レイテンシ、そしてスループットをコントローラー仮想マシンのCPU利用率とともに表示したもののスクリーンショットです。

Fig190

見ていただいて分かる通り、6つのテストでのパフォーマンスはCVMのCPU利用率を含め、ほとんど同じです。以下のテーブルはそれぞれのテストでのMS ExchangeのJetstress検証における2つのキー要素であるデータベースのReadのレイテンシとログのWriteのレイテンシを含めたものです。

Fig191

注意 : 上記の数字はNutanixが提供できるピークでも最高の性能でもありません、単に私が走らせた多くの検証シナリオの中の一つに過ぎません。

圧縮なしとインライン圧縮の間の際はほとんどゼロだとわかります。この検証はインラインデータ削減にはI/Oパスにおけるオーバーヘッドがつきものだとみんなが知っているとおりですが、それがアプリケーションのパフォーマンスの低下に影響を与えるというほど重要ではないということを表しています。

今回の場合、Nutanixのインライン圧縮は非常に効率的で、MS Exchangeのようなアプリケーションにおいては素晴らしいデータ効率化を利用しながら、その実、パフォーマンスやCVM上のCPUの追加オーバーヘッドは殆ど無いということです。

おっと、今回、すべてのパフォーマンスはAcropolis Hypervisor(AHV)のものです!

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

Ntc2017_2

今回はインライン圧縮についての記事です。いろいろな会社がインライン圧縮をいかに効率的に行うか、パフォーマンスへの影響がない理由はどうしたアーキテクチャだからだ、という話をお話していますが、Nutanixの実装はこちらをご参照ください。Nutanixのインライン圧縮(Delayなし)では大きな(64K以上)シーケンシャルなWriteデータのみを圧縮し、ランダムWriteは圧縮を行いません(AOS 5.0以降は4K以上のブロックのみ圧縮)。ネットワーク越しにWriteを冗長化する必要が有るため、インライン圧縮を行ったほうがデータを高速に転送できるデータのみを圧縮し、そうでないものはそのままデータを圧縮せずに転送します。とすると、全然データが圧縮されないんじゃないか?という不安が出てくるかもしれませんが、残りのデータの圧縮はあとから(Delayで)実施され、データ永続領域へ書き出される際に実施されます(AOS 5.0では4Kを展開し、64K単位で再圧縮)。

つまりI/Oパスには影響のないところで実施されるので、パフォーマンスへ影響を心配することなく利用できるということになります。このあたり、現在は4Kや64Kという固定長での実施のようですが、買収した会社の特許などを見ていると更にいろんなチューニングが今後出てくる可能性があると思います!

2017/03/15

Nutanix Acropolis ファイルサービス(AFS) : 設計からみたパフォーマンスと拡張性

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr Solutions Performance EngineerであるDan Chiltonによるものです。原文を参照したい方はNutanix Acropolis File Services (AFS): Performance and Scalability by Designをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig186

Nutanixは最近Acropolis オペレーティングシステムの ヴァージョン 5.0 をリリースし、それとともに素晴らしいNutanixの製品機能 —Acropolis ファイルサービスまたは短くAFSが正式リリースされました。この新機能はNutanixプラットフォームにアプリケーションのように展開する事が可能です。この機能は堅牢な、エンタープライズでの利用を想定したSMBファイル共有ソリューションをNutanixクラスタ上に展開するというものです。Nutanixプラットフォーム内でこの機能を提供することで、別に単独で動作しているネットワークアタッチドストレージ(NAS)ソリューションをWindowsやSMBファイル共有のために維持していく必要はなくなります。

AFSはクラスタ化された、分散ファイルサーバでNutanixプラットフォーム上で動作するいくつかのファイルサーバ仮想マシンのグループとして動作しています。AFSはその柔軟な設計内にパフォーマンスの拡張性を備えています。ストレージのパフォーマンスを増強する必要がある場合には、AFSは容易にスケールアウト、又はスケールアップすることが出来るうえに、動的なロードバランシングの機能も備えています。AFSの更に奥深い詳細な機能とアーキテクチャについては我々の技術メモをご参照ください。

以下のようなワークロードはNutanixの設計したAFSで動作させるのに上手く合致しています。

  • Windowsユーザーのホームディレクトリ
  • 仮想化デスクトップユーザーのリモートプロファイル
  • 組織の共有領域
  • アプリケーションの共有領域

この記事では、ファイルサーバのパフォーマンス要件と検証方法、そしてAFSがこれらの要件に何故合致し、それ以上のものであるかをお伝えしていきます。

お客様がもっとも知りたいと考えるものの一つが、どんなときにファイルサーバソリューションを検討すべきで、それがどのように動くかというものがあります。私は日々の業務の中でソリューションのパフォーマンスについてお話する事が多い人間ですが、これがどんなに重要かということはよくわかります。ですが、この質問にお答えする前に、我々はまず最初にこのソリューションでお客様が何をしたいのか、ということを理解しなければなりません。お客様がファイルサーバとどのようにワークロードをやり取りするのかということです。

以下はワークロードの例です:

  • ファイルサーバへ1つの巨大なファイルを毎回コピーする
  • ディレクトリ内のファイルのリストを眺め、必要なファイルを読む
  • ファイルをファイルサーバからローカルクライアントのデスクトップへダウンロードする
  • マイクロソフトのWordで文書を編集し、その後に文書を保存する
  • 複数のユーザーが仮想化デスクトップへとログオンするが、そのリモートユーザープロファイルがファイルサーバ上に保存されている

我々は開発とリリースのサイクルを通して、こうしたワークロードや他のワークロードに対するパフォーマンスをテストするツールを利用しており、我々がターゲットとしているユースケースでパフォーマンスが高いことを保証しています。最初のワークロードについては我々はrobocopyつまりコピーアンドペーストを利用しており、2番目から4番目まではMicrosoft File Service Capacity Tool またの名を FSCT、そして 5番目には LoginVSIを利用しています。 

単独ファイルコピーテスト = パフォーマンステストとしてはお粗末

ファイルコピーは非常に簡単なテスト(大きなファイルをコピーアンドペーストするだけ)ですが、これはワークロードがシングルスレッドであるため、発行されるI/Oが多くなく、ファイルシステムのパフォーマンスを測るにはお粗末です。これはファイルコピーのテストではファイルサーバが何を行っているのかを正確にはテストできないという事を意味します。

大抵、現実世界で起こりうる状況としては多くのクライアントもしくはアプリケーションがデータを同時にリクエストしてくるというワークロードが発生します。これは単に私が行っているというだけではなく、MicrosoftのOneDriveチームメンバーであるJose Barrero氏のこのディスカッションを見てみてください

なぜ FSCTをつかうのか?

FSCTはMicrosoftによる実際のユーザーのホームディレクトリでの操作の分析をベースとしたパフォーマンステスト郡です。MicrosoftやNetAppそしてEMCなどのファイルサーバのベンダーがそのパフォーマンスを証明するものとして利用されてきました。FCSTが顧客ユーザーホームディレクトリ環境のシミュレーションを行うという点で優れているポイントは:

Windowsドメインコントローラー、クライアント、ユーザーアカウント、認証、そしてパーミッションなどのアクティブディレクトリ統合を検証してくれます。

  • ユーザーは複数のサブディレクトリのあるホームディレクトリ(270のファイル、フォルダ、~80MBのデータ)に接続
  • ユーザーはファイルサービスのメタデータを作成するシナリオを実行
  • コマンドラインによるファイルのダウンロード/アップロード、Windows Exploererによるファイルの削除、ドラッグ・アンド・ドロップ、MS Wordファイルの開閉、そして保存
  • スループットはIOPSやFileOPsではなく、同時実行ユーザー数で計測されます

我々はAFSがユーザー数が増えるに従ってスケールアップしていくホームディレクトリのためのソリューションであることを発見しました。

  • FSCTの検証から、我々はファイルサーバに制限を設け、必要に応じてファイルサーバ仮想マシン(FSVM)をスケールアップさせることで堅牢性を実現しました。
  • 我々はこのデータをNutanixサイジングツールへと翻訳し、サイジングに関する品質と将来の増強に合わせた幾つかの空き領域もご提案するようにしました。
  • 以下のチャートは単一のAFSファイルサーバノードが同時にヘビーユーザーのワークロードをこなすための能力を示しています。

Fig187

AFSソリューションは最低3つのVMから初められますが、我々は16ノードのクラスタ上の16のAFS仮想マシンへとスケールアウトする検証も上手く行えています。AFSの機能はストレージのキャパシティが余っているところへ追加、もしくは完全にスタンドアローンのファイルサーバクラスタとしても利用が可能です。

小さな4vCPUと16GBメモリのAFS仮想マシンのノードから数千ユーザーがAFSノード全体に分散で負荷をかけるような環境までスケールアウトすることが出来ます。

Fig188

何故 LoginVSIなのか?

我々はLoginVSIをよく利用される、業界標準のVDIサイジングツールとして構成し、仮想化デスクトップユーザーのリモートプロファイルがAFSソリューション上に配置されるようにしています。また、我々はCitrix Profile Management、堅牢なエンタープライズVDI環境のスイートも利用しています。ワークロードはWindows OS自身の操作とMicrosoft Outlookを含むようにしています。

VDIプロファイルとしてはAFSはほとんどの場合ブートのフェーズで利用が行われます。デスクトップがブートしてしまえば、ほとんどCPUとメモリの利用に変わります。ということになりますから、AFSはパフォーマンスの評価としては平均ログイン時間を主な評価軸として利用しています(もちろん、ログオン時間なので短いほうが良いわけです)。我々はローカルのC:\ドライブに格納するよりも、AFSのファイルシェアにクライアントが接続して、プロファイルをブート時に読み込むことでログオン時間が改善することを見たいと思っていました。

結果としては最小構成のAFSクラスタでも400仮想デスクトップ環境を容易にサポートできることがわかりました。以下の図をご参照ください。ローカルのC:\ドライブのログオン時間は7.2秒でしたが、リモートに保存されたプロファイルでは6.8秒に短縮されています。(念のためですが、LoginVSIの仮想化デスクトップの平均ログオン時間を単一のI/Oの応答時間とは混同しないでください。そちらはたいていミリ秒やマイクロ秒の単位です。)

Fig189

なぜAFSを選ぶべきなのか? 設計から見たパフォーマンスと拡張性

  • スケールアウト—AFSは設計レベルで最低3ノードでクラスタ化されており最大で16ノードまでをサポートしています。サイズに関係なくワークロードはNutanixクラスタ全体に分散されます。ストレージやコンピューティングリソースを追加するために更にファイルサーバ仮想マシンを追加することも出来ます
  • スケールアップ—特定のファイルサービスのワークロードには多くの処理能力(CPU)やキャッシュ(メモリ)が必要であるため、AFSのノードは追加のvCPUやRAMを追加して要件に合わせてスケールアップすることが可能です
  • ロードバランシング–ファイルデータが成長するのに合わせて、ストレージや処理の要求は特定ホストへの負荷集中(ホットノード)を生じさせます。AFSではこの問題をデータと処理をノード間でリバランスすることで容易に解決できます
  • 分析ベース—よく練りこまれた分析エンジンがAFSに組み込まれており、ファイルサーバ上で継続的にストレージとパフォーマンス消費の分析を行います。この分析からAFSはスケールアウト、スケールアップもしくはリバランスの必要性を推奨します。この機能は管理の時間とパフォーマンスのためのトラブルシュートを削減しTCOの低減を実現します。

我々の検証はAFSに柔軟性があり、クラスタとして設計されているため、SMBファイル共有について最高レベルの要件を持つようなエンタープライズが必要とするパフォーマンスと拡張性を、別に単独でNASアプライアンスを購入すること無く提供できることを示唆しています。Nutanixパートナーへ相談してAFSのデモを見せてもらい、ファイルストレージとその管理を我々に預けることをご検討ください。

もしもNutanixについてあまり知らないのであればNutanixのエンタープライズクラウドプラットフォームがあなたのIT環境にとってどんな効果をもたらすのかという会話から始めあせてください。info@nutanix.comへメールをくださっても構いませんし、 Twitter をフォローするか、 コミュニティのフォーラムへぜひご参加ください。 

Disclaimer: This blog may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

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

Ntc2017_2

前回に引き続きAFSの記事となります。AFSってファイルサーバとしてどのぐらいツオイの?コスパどうなの?こうしたところに注目が集まりますので、本当にタイムリーで良い記事だと思い、翻訳させてもらいました。読んでみていただいて分かる通りAFSは超強力なファイルサーバで最低構成でもVDI 400ユーザーの性能が十分に出てしまうほどです。(しかもNutanixのハードウェアの性能はx86サーバの性能とイコールですから、どんどん性能が上がっていき、値段も下がっていきます)

考えてみるとこれまで幅広く使われてきたファイルストレージにはx86サーバには入ってないような特殊な部品が幾つかあり、それは高値安定の希少部品でした。Nutanixは(もちろんFlashデバイスの進化という追い風もありますが)そうした希少部品と同じもしくはそれ以上の性能を大量生産部品(CPU/Memory/SSD/HDD)とソフトウェアだけで実現しているのです。ハードウェアのオープン化と価値のソフトウェアへの移行、どこまでいくんでしょうか。。。

さて、次回は5.0から圧縮アルゴリズムも変わったということもありますので、インライン圧縮の話を取り上げたいと思っています。

2017/03/08

Acropolis ファイルサービス(AFS)でのデータの分散について

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr Technical Marketing EngineerであるDwayne Lessner氏によるものです。原文を参照したい方はData Distribution with Acropolis File Services (AFS)をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

AFS(Acropolisファイルサービス)で作成の出来る共有(シェア)には2つのタイプがあります。それはホームシェア(Home Share)と一般シェア(General Share)です。一般シェアは作成時には6つのvDiskからなるヴォリュームグループによって形成されています。ホームシェアはクラスタを形成するファイルサーバ仮想マシン毎に5つのヴォリュームグループから構成されています。ですから、小さな構成のAFSでも15のヴォリュームグループでホームシェアを構成することになります。ホームシェアはAFSを展開すると自動的に作成されます。

Fig183AFSで利用されるヴォリュームグループ

ホームシェアはファイルサーバを構成するファイルサーバ仮想マシンのトップレベルディレクトリを分割することでデータを分散します。AcropolisファイルサービスはそれぞれのファイルサーバVMが内部のInsightDBと呼ばれるスケールアウト型データベースを利用してどのディレクトリをどのファイルサーバVMが担当するかのマッピングを行います。

Fig184ホームディレクトリシェアの分散

もしユーザーが「\\FileServer1\Users」というシェアを作成し、その中に「\Bob」、「\Becky」、「\Kevin」というトップディレクトリがあったとすると、「\Bob」はファイルサーバ仮想マシン1上に、「\Becky」はファイルサーバ仮想マシン2に、「\Kevin」は3にと、そのように配置されます。ファイルサーバ仮想マシンはディレクトリ名についての文字列のハッシュアルゴリズムをベースとして、トップディレクトリを分散します。

この分散によって、単一シェアを利用するユーザーが非常に大きくなっても対応が可能です。拡張性による問題から、従来からの設計では管理者はシェアを複数作る必要がありました。例えばその最たるものとしてラストネームがA~Mで始まるユーザーのためにコントローラーを一つ割り当て、N~Zまでの人に別のコントローラーを割り当てるというものです。この設計は管理のためのオーバーヘッドという苦痛を生み出し、不必要にアクティブディレクトリを複雑にしてしまっていたのです。こうした理由から、AFSはクラスタ全体で1つのホームディレクトリしか要らないという実装になっています。もしも1つよりも多くのホームディレクトリシェアが必要な場合、nCLIを利用して作成することが出来ます。

トップディレクトリは終結点となっており、基本的にはショートカットです。前の説明と合わせると、全てのユーザーフォルダをルートディレクトリに作成することで適切なロードバランシングが行えるようになります。ショートカットとして見えるため、シェアのルートディレクトリにはファイルを置くことは出来ないようにしています。また、ユーザーのフォルダを展開する前にシェアのルートフォルダのパーミッションの設定を推奨しています。

一般用途のシェア(ユーザーディレクトリではない)はトップレベルディレクトリでの分散を行いません。一般用とのシェアではファイルとサブフォルダは常に特定の単一のファイルサーバが所有権を持ちます。以下の図は2つの一般用のシェア(例:Accouting(経理)とIT(情報システム)部門)が同一のファイルサーバ上に配置されています。

Fig185

2つの目的の異なるシェアを同じファイルサーバ内に配置

ホームディレクトリシェアとは異なり、シェアのルートにファイルを保管することが出来ます。

気になることがありましたら、コミュニティフォーラムでお話しましょう。ご自身の経験をコミュニティでぜひご共有ください。もちろんTwitterでもご質問を受け付けております。ハッシュタグ「#AskNutanix」をご利用ください。

Disclaimer: This blog contains links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

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

Ntc2017_2

10つのシリーズは一旦終了ですが、今回は社内、社外でよく質問を受けるAFS(Acropolis ファイルサービス)についての記事を取り上げました。AFSはNutanixにネイティブに実装されている、、、結局のところABSをバックエンドにしているため、ヴォリュームグループと言う単位で管理を考える必要があり、Windowsのファイルサーバ仮想マシンを利用する場合の感覚とは少し違ってくる部分があります。ですが記事の中にある通り、巨大なホームシェアを(スケールアウトで!)取り扱うことが出来ますので多くのメリットがあります。実際の操作は仮想マシンを作るのと同じ感覚で作れますので特定のお約束だけ理解していればWindowsを立てるより簡単でしょう。次回もAFSの中身を掘り下げる記事を予定しています。

2017/03/01

ネットワーク可視化について知っておくべき9つの事

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

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

「10つの知っておくべき事」のブログシリーズを続けていきます。今回の記事で取り上げるのはネットワーク可視化で、我々の5.0ソフトウェアリリースに含まれています。

この新しい機能ではネットワークインフラストラクチャの包括的な表示を一つの画面で提供します。サーバ、仮想化、そしてストレージリソース間を可視化するだけでなく、Nutanixは仮想化の下の物理と仮想ネットワークレイヤについての可視化も行います。 

  1. ネットワーク可視化によって、IT管理者はネットワークのすべての要素とそれらの相互の関係性を視覚的に見ることが出来るようになります。ネットワークの可視化は高度なインタラクティブ性と、Nutanixクラスタ内のすべてのノードのネットワークトポロジの表示を備え、非常に使いやすいものになっています。
  2. 仮想マシンから、仮想NIC、物理NIC、そして物理スイッチのポートに至るまでのネットワーク全体の可視化の能力を備えています。これによってIT管理者はクラスタのネットワークの構成を可視化することが出来、VLANの構成ミスなどのネットワークに関連するトラブルシューティングをシンプルに行なえます。
  3. 管理者は単一の仮想マシンからドリルダウンして、どのホストでそれが動作しているのか、どの物理ネットワーク接続を利用しているのか、そのスイッチポートを利用しているのか、そしてどのVLANに所属しているのかを知ることが出来ます。
  4. 最初のヴァージョンではAHVのクラスタをサポートしており、Prism内の新しいネットワークのページから利用することが出来ます。将来的に我々はこの機能を他のハイパーバイザーへと拡張させる予定です。
  5. ホストのNICとスイッチポート間の関係性を表示して、IT管理者はスイッチポートの状態を含むネットワーク構成の完全な全体像を知ることが出来ます(スイッチ上でLLDPとSNMPを有効にする)
  6. ネットワークのページはフィルタ、グルーピング、そして要素の選択などで便利に使うことが出来、管理者はなにを監視、もしくはトラブルシューティングするのかによってカスタマイズすることが出来ます。
  7. ネットワークの要素それぞれについて掘り下げて表示することができ、各要素についての詳細情報をみることができます。例えば、ノードネットワークトポロジでは標準的な接続情報に加えて、選択可能な要素からインタラクティブに詳細情報を得ることが出来ます。
  8. Prismは階層化され整頓されたネットワーク構成表示を提供し、ユーザーは注目したい物を選択してさらに詳細へとドリルダウンすることが出来ます。
  9. 一般的なトポロジの可視化が組み入れられており、あらゆる関連するコンポーネントの可視化に利用することが出来ます。我々はクラスタ、ホスト、DRサイト、スナップショットなどの他のNutanixのUI部分についてもこれを利用して拡張していく計画です。

Fig182

Forward-Looking Statements

This blog includes forward-looking statements concerning product features and technology that are under development or in process and capabilities of such product features and technology, and our plans to introduce product features, including network visualization and extensions thereof, in a future release. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs.  The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: changes in our relationships with our partners, including Dell EMC and Microsoft; failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our registration statement on Form S-1, as amended, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this blog and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.  Any future product or roadmap information is intended to outline general product directions, and is not a commitment, promise or legal obligation for Nutanix to deliver any material, code, or functionality.  This information should not be used when making a purchasing decision.  Further, note that Nutanix has made no determination as to if separate fees will be charged for any future product enhancements or functionality which may ultimately be made available.  Nutanix may, in its own

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

Ntc2017_2

知っておくべき10つの事シリーズ、今回は9つですが、Nutanixのネットワーク可視化についての記事でした。今回の記事はUIチームが書いているようですが、今回のネットワーク表示は非常に使いやすく、見てわかりやすいものになっており、正にPrismのど真ん中、という印象です。最後の項目に挙げられているとおり、各要素の相関を上手く可視化することが出来たので、UIチームとしては今後他のところでもこのUIを利用できる部分に適応していくようです。ネットワーク表示が良い、パフォーマンス表示が分かりやすい、など各々の管理ツールの良い部分、悪い部分で製品を選んでおられる方もおられたと思いますが、Prismを作っているチームはこうしたUIのベネフィットを横展開することに積極的ですね。こちらの記事も是非ご参照ください。ぜひ触ってみていただきたいのですが、Nutanixのパートナーになれば誰でも直ぐに触ってみていただくことが出来ます。パートナーになりたいという方は、ぜひ当社へご相談いただければ幸いです。

2017/02/22

Nutanixのデータ保護と災害復旧について知っておくべき10つの事

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

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

10つの知っておくべき事ブログシリーズを続けましょう、次に述べていくのはNutanixの複雑で様々なサービスレベル要件(SLA)のアプリケーションを満たすために幅広いオプションで提供を行っているデータ保護と災害復旧についてのものです。

以前のリリースから継続して、我々の5.0リリースでもこれまでの多くの優れたデータ保護と災害復旧についての機能を利用することが出来ます。ですから、以下のNutanixのデータ保護と災害復旧の機能についての10つの事は5.0のリリースによる改善だけに限定されるものではありません:

  1. Nutanixは従来から古くからのLUN中心の考え方に見られた仮想マシンとLUNのマッピングと言う考え方を廃した、よく考えられた仮想マシン中心のスナップショットを提供しています。NutanixはRead-On-Write(ROW)をスナップショットの実装に利用しており、既存の保護されたデータに対する変更を新しい場所へとリダイレクトします。スナップショット内の既存のメタデータやデータに対してのコピーや移動は必要ありません。結果として、ROWスナップショットはCopy-On-Write実装では余計に必要になってしまうパフォーマンスからの影響に苦しむことはありません。
  2. Nutanixは個々の仮想マシンをプライマリシステムから1つもしくはそれ以上の別の場所にあるセカンダリシステムへと効率的にレプリケーションすることが出来ます。レプリケーションは柔軟であり、双方向、1対1、1対多、多対1のトポロジで実行可能です。仮想マシンのスナップショットを非同期で別のデータセンタにユーザーの定義したスケジュールでレプリケーション、又はバックアップすることが出来ます。
  3. これまでも、メトロ可用性によってデータを別の場所に同期レプリケーションすることで、リアルタイムのデータの別の場所へコピーされていることを保証する事ができていました。5.0のリリースからはメトロウィットネスによって、サイトもしくはネットワーク断絶障害の場合の自動的なセカンダリサイトでの障害復旧が実現できるようになりました。これによってほとんど100%のアプリケーションの稼働をデータロス一切無しで実現できるようになりました。
  4. Nutanixのデータ保護はその下のNutanixのエンタープライズクラウドプラットフォームの優れたインテリジェントな階層化、重複排除、イレイジャーコーディング、圧縮、そして分散自己修復などのエンタープライズストレージの機能によってより優れたものとなります。
  5. すべてのデータ保護の機能は単一のPrismのインターフェースを通して利用することが出来ます。バックアップのポリシーはほんの数クリックでスケジュールすることが出来ます。ローカルまたはリモートのスナップショットからの仮想マシンの復元も2つの簡単なステップにまでシンプル化されています。
  6. セルフサービスでのファイル復元によって、Nutanixの管理者がいなくても、仮想マシンのスナップショット内からアプリケーションの管理者が特定のファイルを復元することが可能となります。セルフサービスでのファイル復元はセットアップと管理が簡単で殆どの場合で仮想マシン全体を復元しなくてはならないという事態を避けることが出来ます。
  7. Cloud ConnectはAWSやMicrosoft Azureのようなパブリッククラウドサービスに対するデータのバックアップをサードパーティのソフトウェアやプラグインを利用すること無く実現します。 あたかもそれが遠隔地のNutanix環境であるのと同じように仮想マシンや仮想マシンのコレクションに対するスナップショットを複数のAWSやAzureのリージョンへ作成し、復元することが可能です。
  8. 5.0のリリースから、Nutanixは拠点・支店(ROBO)のための1ノードクラスタのオプションを提供し、レプリケーションターゲットとして利用可能にしました。このプラットフォームではHDDのRaw容量は40TBまでスケールアップ可能です。
  9. NutanixはvStorage API for Data Protection(VADP)のサポートを提供し、ヴォリュームシャドウコピーを利用したアプリケーションレベルで一貫性の取れたスナップショットとVSSを利用したSMBの共有を利用したHyper-V環境での仮想マシンレベルでのバックアップを提供します。ですから、Veritas NetBackup、CommVault、Veeam、その他のバックアップ環境とシームレスに動作します。
  10. NutanixはCommVaultとともにAHVプラットフォーム環境で動作しているワークロードに対するシームレスなバックアップと復元を提供します。これによって、ゲスト内でのバックアップ・復元エージェントなどの特殊な要件を排除することが出来ます。

Fig181

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

Ntc2017_2

今回の10つのシリーズはデータ保護と災害復旧についてです。Nutanixは優れたストレージ環境であるだけでなく、優れたデータサービス(重複排除、圧縮、レプリケーション、メタデータ操作によるスナップショットなど)を提供するプラットフォームです。データ保護という観点から考えると標準ソフトウェアでこれほどまでの機能を備えているプラットフォームは他にないのではないでしょうか。更に重要な点は前回、前々回の記事でご紹介したようなブロックストレージやファイルストレージへもこうした機能を利用できるということです。社内のITインフラを全てまとめ上げて管理コストを減らすだけではなく、社内のバックアップ復元の仕組みもまとめ上げることで優れたTCOを実現するのです。

2017/02/15

Nutanix™ on Cisco UCS®について知っておくべき10つの事

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のProduct Marketing Managerを務める EJ Bodnar氏によるものです。原文を参照したい方は10 Things to Know About Nutanix™ on Cisco UCS®をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

以下がNutanix™ on Cisco UCS®について知っておくべきトップ10つの事です。

 

1) Nutanix™ Enterprise Cloud Platform for Cisco UCS® は2016年のCRNのプロダクト・オブ・ザ・イヤーの勝者に選出されました

  • CRN® はNutanix Enterprise Cloud Platform™ for Cisco® Unified Computing System (UCS) をハイパーコンバージドインフラストラクチャカテゴリにおける2016年のプロダクト・オブ・ザ・イヤーに選出しました。

  • Nutanix Enterprise Cloud Platform™ はテクノロジーと顧客からの要望の2つのサブカテゴリで1位を獲得しています。

     

2) 他のすべてのハイパーコンバージド製品を合計したよりも多くのお客様はNutanix™を選択しています

  • Gartner(1)によるとNutanix™ はマーケットにおいて50%以上のシェアを獲得しています。

 

3) Nutanix™を利用しているお客様は71%も管理のための時間が短縮され、TCOは58%も削減されています

  • Nutanix™ は複数のハイパーバイザーのサポート、先進的なデータ最適化、スケールアウトストレージサービスを含むウェブスケールの設計、予測的キャパシティプランニング、ワンクリックソフトウェアアップグレード、それ以外にも多数の機能を搭載しています。

 

4) Nutanix™は完全な評価と検証を経て、現在、既にお客様環境のCisco UCS® C-シリーズサーバでワールドワイドに稼働しています

  • Nutanix™ は独自にNutanix™ ソフトウェアをCisco UCS® C-シリーズサーバで検証し、認定を行いました。それに加え、Nutanix™ と Cisco® のチャネルおよびSIパートナーが既にお客様とパートナー様の環境の両方でNutanix™ ソフトウェアをCisco UCS® C-シリーズサーバ上で評価、検証に成功しています。

  • 複数の国で、複数の業種にまたがった複数のお客様がNutanix™ on Cisco UCS® C-シリーズサーバを本稼働環境で稼働させています。

 

 

5) ラックマウントのCisco UCS®サーバがサポートされ、現在ブレードサーバをサポートするために開発中です

  • Nutanix™ は現在ラックマウントサーバのCisco® C220 と C240で利用可能です。

    2016年の11月、Nutanix™は将来Cisco® B200 ブレードサーバをオールフラッシュとストレージオンリーノードとしてサポートする計画があることを発表しました。

  • Cisco® のお客様からのご要望があればNutanix™は更に他のUCS®モデルの追加も計画しています。

 

6) Nutanix™ for Cisco UCS® はソフトウェア製品としてリリースされ、事前に展開しておくことも、後から追加することも可能です

  • Nutanix™ は従来からの“meet-in-the-channel”モデルを活用し、Cisco UCS®サーバと別にNutanix™ ソフトウェアを購入できるようにしました。

  • 世界中の有力なCisco®チャネルパートナーがNutanix™ on UCS®をご提供します。認定ディストリビュータとCisco®のリセラー、そしてNutanix™が自身の設備もしくはお客様サイトでCisco®ハードウェアとNutanix™ソフトウェアを一つにインテグレーションし、 Nutanix™ と Cisco® のお客様として期待通りの利用体験を保証します。

 

7) Nutanix™ software for Cisco UCS® の購入は簡単

  • The Nutanix™ software にはサポートが組み込まれており、Cisco UCS®のお客様にとって完全なソリューションとなっています。

  • Nutanix™ software はノード毎に、固定期間(1/3/5年)で価格設定されています。 

8) Cisco UCS® のお客様は業界標準のプロセスを活用し、最高の評価を得たサポートを利用することが出来ます

  • サポートはNutanix™ と Cisco® の業界をリードするカスタマーサポートチームによって提供されます。Nutanix™ はNutanixソフトウェアをサポートし、Cisco® はCisco UCS®ハードウェアをサポートします。
  • 殆どの場合において、明らかにハードウェアの問題であればCisco®へ、明らかにソフトウェアの問題であればNutanix™へと連絡を入れていただくことになりますが、Nutanix™ は常に最初の問い合わせをお受けする準備をさせていただいています。
  • Nutanix™ はCiscoのハードウェアサポートに対するケースをTSANet(Technical Support Alliance Network – www.tsanet.org)経由で行い、ここからCisco®へハードウェアのサポートと交換が引き継がれます。
  • お客様はNutanix™がネットプロモータースコアで90点以上を継続して達成している最高レベルのサポートを受けることが出来ます。

 

9) Nutanix™ はハイパーコンバージドインフラストラクチャを開拓しました

  • ハイパーコンバージドインフラストラクチャはx86ベースのコンピューティングとストレージのリソースをインテリジェントなソフトウェアでネイティブに結合し、サーバ、ストレージネットワーク、ストレージ装置に分断されたままの古くからのインフラストラクチャを置き換えるための柔軟なビルディングブロックを構成します。
  • ハイパーコンバージェンスはその実現が最終目的ではなく、最終目的地であるエンタープライズクラウドプラットフォームのための基盤となるビルディングブロックです。

 

10) Nutanix™ はエンタープライズクラウドプラットフォームを開拓しました

  • Nutanix™ はハイパーコンバージドインフラストラクチャの概念を開拓しました。しかし、他のベンダーそこを目的地としているのに対し、Nutanix™はハイパーコンバージドインフラストラクチャを完全なるエンタープライズクラウドプラットフォームを提供するための道のりの単なる通過点としてしか見ていません。
  • Nutanixの最終的な旅の目的はインフラストラクチャをインビジブルにし、お客様のビジネスを支えるアプリケーションとサービスにフォーカスしてもらうことです。
  • エンタープライズクラウドプラットフォームを提供することとは、お客様にオンプレミスに展開するか、パブリッククラウドに展開するかを強制してしまうような技術的な障壁を取り払うことであり、Nutanix™はCisco UCS®のお客様がこの双方へとまたがって展開できることを実現したのです。 
  • 結果として、どこにコンピューティングを配置し、どこへデータを格納するかという選択は究極的にシンプルになり、ビジネス状況での判断で決めることが出来ますし、自由にダイヤルを回すように行き来ができるようになるのです。 

 

Nutanix on Cisco UCS

Nutanix はコンピューティング、ストレージ、仮想化を直ぐに利用ができるエンタープライズクラウドプラットフォームにネイティブに融合させました。これによって30~60分での利用開始、あらゆるアプリケーションのあらゆる規模での稼働を実現させました。

Fig180

(1) Gartner Magic Quadrant for Integrated Systems Published: 10 October 2016

(2) IDC White Paper | Quantifying the Business Value of Nutanix Solutions, August 2015

 

© 2016 Nutanix, Inc. All rights reserved. Nutanix™ is a trademark of Nutanix, Inc., registered in the United States and other countries. Cisco® and Cisco UCS® are the registered trademarks of Cisco Technology, Inc. Nutanix is not associated with, sponsored or endorsed by Cisco.

 

Forward-Looking Statements

This blog includes express and implied forward-looking statements concerning product features and technology that are under development or in process and capabilities of such product features and technology, and our plans to introduce product features, including support for Cisco USC B-Series blade servers, in a future release. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs.  The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our registration statement on Form S-1, as amended, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this blog and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.  Any future product or roadmap information is intended to outline general product directions, and is not a commitment, promise or legal obligation for Nutanix to deliver any material, code, or functionality.  This information should not be used when making a purchasing decision.  Further, note that Nutanix has made no determination as to if separate fees will be charged for any future product enhancements or functionality which may ultimately be made available.  Nutanix may, in its own discretion, choose to charge separate fees for the delivery of any product enhancements or functionality which are ultimately made available.

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

Ntc2017_2

今回の10つの知っておくべきことシリーズは、プラットフォームについてです。NutanixがCisco UCSの上で動作する、しかもそれがCRNの2016でハイパーコンバージドインフラストラクチャでトップを取った!これは業界においては衝撃を持って迎えられたニュースでした。一方、そもそも(誤解を覚悟の上であえてこうした言い方をしますが)CVMとして動作しているNutanixのソフトウェアの大部分はハイパーバイザーに依存しない実装になっているでしょうし、Nutanix自身はNutanix CE(コミュニティエディション)でハイパーバイザー(AHV)を含めた様々なハードウェアでの動作に関する情報を吸い上げています。純正品がSuperMicroで、更にOpenComputingプラットフォームの動作も見据えているNutanixのソフトウェアは(サーバ機能部分は)ほぼそれを踏襲したUCSで動かないわけがありません。

一方でUCSを使っていて良いことはネットワークの巨人Ciscoさんならではのネットワーク関連の構成の簡単さです。これは将来的にはNutanix側でもそうした機能が提供される予定ですが、現時点では提供されていないものでNutanix on Cisco UCS、実は現時点では地球上でもっともOpEx(運用管理コスト)を削減出来るソリューションじゃないかと思います。

当社は記事の中にもあるようにCiscoのリセラー(ディストリビュータ)かつ、Nutanix社のディストリビュータですのでこの優れたソリューションをご希望のお客様にご提供することが可能です。詳しく知りたいという方はお気軽にお問い合わせください。

さて、10つの知っておくべきことシリーズはまだまだ続きます。

2017/02/08

Prismセルフサービスについて知っておくべき10つの事

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

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

「知っておくべき10つの事」ブログシリーズを続けていきましょう。今回はPrismセルフサービスについての記事です。PrismセルフサービスはNutanixがご提供する新しい機能で5.0ソフトウェアのリリースに含まれます。 

  1. Prism セルフサービスはNutanixエンタープライズクラウドプラットフォームのコアコンポーネントとなります。開発者のようなエンドユーザーに対して、インフラストラクチャのリソースへの円滑なアクセスを提供することによって、AWSのような利用体験を実現します。
  2. PrismセルフサービスのためのUIであるPrismセルフサービスポータル(SSP)はPrismへと上手く統合されているため、アクセスのために別の管理ツールをインストールする必要はありません。Prismからワンクリックで起動することが出来ます。管理者はSSPで数クリックでNutanix環境をセルフサービスアクセスのためにセットアップすることが出来ます。
  3. エンドユーザーは非常にシンプルなやり方でリソースへアクセスが可能になります。インフラストラクチャのリソースへのアクセスのためにPrismへとアクセスする必要はありません。管理者はエンドユーザーにウェブポータルのURLを送り、ユーザーは自身の会社の認証情報を利用してログインし、リソースをセルフサービス方式で利用することが出来ます。
  4. SSPは強力なクラウドプラットフォームの利用体験をコンシューマーのデザイン哲学によって最適化します。仮想マシンのトラブルシューティングはワンクリックでアクセスできるパフォーマンス測定値や仮想マシンのディスプレイコンソールによって簡単なものとなります。
  5. プロジェクトはユーザーとそのユーザーと紐付けられたポリシーをフレームワーク内で一緒にしたグループ化のための単位です。プロジェクトはリソースのアサインと、グループになったユーザーへのリソースの利用のための権限を実現します。プロジェクトのクオータは管理者の管理下において、エンドユーザーによるインフラストラクチャの利用の制限とアクセス可能なネットワークを規定します。
  6. SSPはよく試行錯誤された末の操作と運用の権限を提供するアクセスコントロールレイヤを提供することでセキュリティを向上させます。管理者はシステム内のユーザーの操作の権限をコントロールするためにロール(役割)を作成することが出来ます。
  7. カタログは共有の仮想マシンのテンプレートとイメージへのアクセスを提供します。管理者はアクセス可能なアイテムを決定し、エンドユーザーはカタログ内の許可されたアイテムから自身の仮想マシンの作成を行うことが出来ます。
  8. 利用状況の分析機能によって、クラスタのリソースの管理はシンプルなものに変わります。SSPはマウスをあわせたその瞬間、そして時系列チャートでのリソースの割り当て状況を可視化します。ハグレものになってしまった仮想マシンを簡単に見つけ出すことが出来ます。
  9. 管理者とエンドユーザーは同様に自身のSSPの利用をRESTのドキュメントとサンプルコードが含まれた優れたSDKによる認証型のプログラミングされたクライアントで拡張することが出来ます。
  10. SSPは最初はWindows Active Directoryによる認証とAHVによって提供されるコンピューティングに対してのみで利用可能です。ですが、設計自体はハイパーバイザに依存しないように作られており、将来のリリースで他のハイパーバイザーでも同様のサポートを提供する予定です。

Fig179

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

Ntc2017_2

「知っておくべき10つの事」は今回の記事で4つ目です。AFS、All Flash、ABSとストレージ関連のソリューションが続いてきましたが、やはりNutanixは「クラウドプラットフォーム」ですね。SSPを利用することで社内のエンジニアはネットワークやコンピューティング、もちろんストレージなど様々なリソースについて各方面で調整を行うこと無く、自由に、すぐに自分自身の環境を作り出すことが出来ます。VMwareのvCloud Director、vRealize Automation、OpenStackなどの従来からクラウドOSなどと呼ばれてきたものに比べると自由度は(まだ)小さいですが、例えば当社が販売パートナー様に対して提供しているハンズオンの環境などはこのSSPの機能だけでも充分に行えてしまいます。

Prism由来の優れたインターフェイスも魅力ですね。(一方でREST APIも整備されているので、Prismを見ること無く、たとえばコマンドラインから自動化スクリプトを実行して自分なりの環境の展開方法を自動化することも出来ます。)

現在はAHVですが、今後他のパイパーバイザーへとサポートが拡充される予定ですので、開発環境、ステージング環境、本番環境とDevOps的な使い方も(ハイパーバイザを超えて)出来ますね。使い方が自由で制限がない、これは様々な発想の飛躍につながると思います。ぜひ開発者の方も触ってみてください!

2017/02/01

Nutanix Acropolisブロックサービスについて知っておくべき10つの事

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

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

さて、知っておくべき10つの理由のブログシリーズを続けていきましょう。次のステップはAcropolisブロックサービスです。Acropolis ブロックサービス(ABS)は4.7のリリースとともに発表されました(2016年6月)。それ以降、我々はその機能を継続的に改善し続けながら、更に顧客の要望に対応すべく、パフォーマンスの改善、そして認定するクライアントの種類を増やし続けています。さぁ、ABSについての「知っておくべき10つの事」のはじまりです:

  1. ABSは高可用性、拡張性、そしてパフォーマンスを阻害すること無く、ハイパーコンバージェンスと物理サーバのためのブロックレベルのiSCSIストレージを単一のソリューションとして解決できる共有インフラストラクチャの実装を可能にします。
  2. ABSはライセンス関連の制限、レガシーアプリケーションの移行の難しさ、既存の投資などの観点から、ベアメタル(物理)サーバ上に残ってしまっているワークロードであってもIT管理者がその既存サーバインフラストラクチャを存分に活用できるようにします。
  3. ABSを効率的なバックアップ、復元のテクノロジーのために利用し、本稼働データベースのクローンのシンプルをPrismのシンプルな運用を通して実現します。
  4. Nutanixは継続的にオペレーティング・システムやハイパーバイザーのサポートの幅を広げていきます:

    Fig177

  5. アプリケーションのパフォーマンスはフォークリフトアップグレード(訳注:インフラもしくはストレージの総取り替え)なしに、Nutanixクラスタのサイズと共にシームレスに拡張することが出来ます。新しいノードを追加すればパフォーマンスとキャパシティの両方を同時に追加でき、その場合でもクライアント側への再構成は必要ありません。
  6. キャパシティを追加している最中も運用を継続することが出来ます。新ヴァージョン(5.0)で追加のオンラインでのLUNのリサイズによって、環境への変更を最小に抑えながら、LUNのサイズの増強を行うことも簡単になります。
  7. 新ヴァージョン(5.0)でリリースされた動的なロードバランシングの機能によって、パフォーマンスのボトルネックを回避し、自動的にクラスタ内でトラフィックのリバランスが行われます。
  8. 新ヴァージョンではCHAP認証とIP/IQNベースのホワイトリストによる高セキュリティ化が実現され、認証されたクライアントのみが特定のiSCSIのLUNへとアクセス出来ることが保証されます。
  9. Microsoft Windows Server Failover Clusteringなどの高可用性アプリケーションは数秒以内にiSCSIのLUNをFail-over/Fail-Back可能です。
  10. ABSではOracle RACを含むOracleデータベースやMicrosoft SQLサーバ、IBM DB2などが動作しているNutanixクラスタ外のベアメタルサーバや仮想化サーバへとNutanixのストレージをエクスポートすることが出来ます。これによってNutanixのウェブスケールアーキテクチャの利点を用意に活用できるようになり、これらのアプリケーションのハイパーコンバージェンスへの移行をご自身のペースで行うことが可能となります。

Fig178

Forward-Looking Statements(原文よりそのまま転記)

This blog includes express and implied forward-looking statements concerning product features and technology that are under development or in process, capabilities of such product features and technology, and our plans to introduce product features, including support for certain third-party solutions, in a future release. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs.  The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; the introduction, or acceleration of adoption of, competing solutions; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our registration statement on Form S-1, as amended, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this blog and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.  Any future product or roadmap information is intended to outline general product directions, and is not a commitment, promise or legal obligation for Nutanix to deliver any material, code, or functionality.  This information should not be used when making a purchasing decision.  Further, note that Nutanix has made no determination as to if separate fees will be charged for any future product enhancements or functionality which may ultimately be made available.  Nutanix may, in its own discretion, choose to charge separate fees for the delivery of any product enhancements or functionality which are ultimately made available.

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

Ntc2017_2

今回は前回は11に増えてしまいましたが、また10に戻って10つの事シリーズ、今回はNutanixをブロックストレージとして使うことの出来る機能ABSについて知っておくべき10つの事です。管理する物は少ない方がいい!これは様々なものに共通することです。Nutanixに外部のストレージを接続できますか?というご質問をいただくこともまだ多いのですが、今後はその逆、外部のストレージが保守切れになるので、Nutanixを増設して外部ストレージの上のアプリケーションを延命したい、という話が増えてくるでしょう。

Nutanix(ABS)なら5年(または+α)で保守が切れてしまう従来型のストレージと違い、クラスタ内のノードは順次退役、新しいノードを追加して新陳代謝されますが、Nutanixクラスタとしては永遠に使い続けることが出来ます。5年毎のストレージ入れ替え(本文ではフォークリフトアップグレードと紹介されています)が将来に渡ってなくなることを歓迎しない方はいらっしゃらないでしょう。5年毎とは言え、あちこちにサイロがあれば結局毎年フォークリフトアップグレードしているかもしれません。一つづつこれを減らして管理の手のかからない真のプライベートクラウド(Nutanix流にいうとエンタープライズクラウドもしくはインビジブルインフラストラクチャ)を実現していきましょう。

2017/01/25

Nutanixが最高のオールフラッシュプラットフォームであるその11の理由

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のVP of Client Strategy at Nutanixを務めるSteve Kaplan氏によるものです。原文を参照したい方は11 Reasons why Nutanix is the Best All-Flash Platformをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

本ブログ記事に関連して、Nutanix社、Mellanox社に協賛をいただき、セミナーを実施致します。ここではお話できないもっともっとDeepな内容も!!

Nutanix x Mellanox 次世代フラッシュメモリと高速ネットワークセミナー

次世代フラッシュの登場でデータセンターアーキテクチャーに何が起ころうとしているのか?PernixData社を買収したNutanix社は何を目指しているのか?

お申込みはこちらから。ぜひ足をお運びください。

Fig166

オールフラッシュ装置 : 死刑囚が(処刑台に向かって)歩く

オールフラッシュ装置(AFA)を製造メーカーは確実な回転ディスクの陰りに感極まっていることでしょう、しかし、ハイパーコンバージドインフラストラクチャ(HCI)が全ストレージカテゴリーを逆さまに飲み込んでしまいそうにもなっています。AFAは従来型のストレージ装置に比べ高速で、管理が簡単ではあるものの、依然としてSANなのです。NutanixのエンタープライズクラウドはAFAよりも優れたフラッシュのためのプラットフォームであるだけでなく、その他のHCIソリューションよりも優れたものです。以下にその11の理由を挙げます :

1) ネットワークレイテンシの効果を劇的に削減

NutanixのHCIは既にネットワークのレイテンシを削減することで最高のAFAのパフォーマンスを誇っています(@vcdxnz001の記事を見てください。ネットワークは遅すぎる、どうしたら?)。NVMeや3D Xpointのような革新はハイパーコンバージド環境で、データをコンピューティングのすぐ傍らのフラッシュやもしくは他のストレージクラスメモリ(SCM)上に置くその効果をより強調することになります。従来型のモデルである、オールフラッシュ装置から低速のネットワークを経由してデータにアクセすることは高速なフラッシュ/SCMからのメリットを阻害することになります。

Fig167※訳注 NVMe = 30マイクロ秒のレイテンシ、40GbE = 40マイクロ秒のレイテンシ、ネットワークはフラッシュには遅すぎる!

コンピューティングの傍らではなく、ネットワークに接続された磁気メディアのレイテンシのために設計されたプロプライエタリの装置へとフラッシュを追加するということは全く意味をなしません。これは単に距離の問題であるという簡単な物理の問題へ帰結します。フラッシュはアクセスのために直接(ダイレクト)接続されるべきであり、複数のホップ、プロトコル、パフォーマンスを制約するコントローラが必要な間接(リモート)で接続されるべきではないということです。単なる物理です!

Fig168

NutanixとAFAのI/Oパスの長さの比較

AFAのベンダーは高速なネットワークとNVMeをファブリックに利用することで、低遅延で高帯域を実現できるという提案をしてくることも有ります。Nutanixはお客様へ高価で従来からの複雑性を継続させるような新しいストレージファブリックを買うこと無く、フラッシュのメリットを最適化して利用することを実現します。

Fig169

Michael Webster氏のLong Virtual White Cloudsからの引用画像

2) 統合率の優位性

Nutanixは全てのサーバのリソースに加え、92TBまでのフラッシュをたった2Uに積み込むことを実現しています。AFAはその装置以外にもコンピューティング、ストレージファブリック、そして、大抵は(※バックアップ用?)低コストのディスクストレージも必要とします。これははそれぞれ更に電源、ラック領域、空調が追加で必要です。

3) コモディティのハードウェア

PureなどのほとんどのAFAはプロプライエタリのハードウェアを利用しています、しかし、これは新しいハードウェアの革新を迅速に取り入れようとする場合には通行止め標識になってしまいます。オールフラッシュ装置はテクノロジの飛躍的な進化によって製品が古臭いものとなり、次にキャパシティが必要なタイミングでフォークリフトアップグレード(訳注 : 全てフォークリフトで取り外されて、別のものを入れ替えること)されてしまい、顧客が離れていくのを危険視しています。今日の早いペースのテクノロジ環境において、成功するのは世界で最も大きなコモディティハードウェアの製造メーカーによって駆り立てられた革新を活用したグローバル経済の規模での拡張を足がかりにした会社のみです。

サン・マイクロシステムズのケースを取り上げましょう。業界がよりコスト効率の良い、パーソナルコンピューターで人気を博したインテル互換のマイクロプロセッサへと舵を切っているにも関わらず、サンはプロプライエタリのハードウェアに賭けました。サンは投げ売り状態でOracleに買収される前にはその価値を80%も落としていました。

ヴァイオリンメモリがもう一つの例です。ヴァイオリンは市場へオールフラッシュメモリソリューションをいち早くもたらした最初の会社の一つです。これは非常にクールで、高速なテクノロジであり、優れたエンジニアリングに支えられて10年ほど前に創業しました。

しかし、コンシューマは別の考えを持っていました。彼らはソリッドステートドライブ(SSD)の速さと信頼性を愛し、今日ではほとんど全てのノートPC、デスクトップ、メモリ装置の中でそれが使われています。SSDの価格が急落しても、ヴァイオリンは自身のプロプライエタリのフィールド-プログラマブル ゲート装置(FPGA)を利用する設計を選択しました。洗練されたソリューションでしたが、おそらくは、SSDの急速な改善についていけなくなったのです。ヴァイオリンのプロプライエタリのハードウェアは急速に力を失い、会社はNYSEのリストから消えてしまうことになりました。

ハイパーコンバージドのビジネスはいみじくもコモディティハードウェア上で唯一、活況を呈しているエンタープライズテクノロジーであると言えるでしょう。すべての有力なクラウドプロバイダーもコモディティサーバを利用しています。プロプライエタリのハードウェアは一時的には会社の革新を保護する基盤となった時期もありますが、今は製造メーカーの競争力の邪魔に、もしくはその破壊すら行いつつ有ります。

4) 分散されたストレージコントローラ

ほとんどのAFAは物理の、分散されていないストレージコントローラを利用しており、これはトラフィックによって容易に飽和してしまいます。コントローラーがボトルネックになることによって、それ以降はいくらSSDのシェルフを追加してもパフォーマンスが向上することはありません。

単独のエンタープライズのSSDが最高で500MB/sほどのスループットが出ると仮定すると、デュアルの4GbのFCアダプタを利用している場合ではコントローラはSSDが2本でボトルネックとなります。デュアルの16Gb FCアダプタへとアップグレードしたとしても、8本をさばけるだけです。

これらの制限に打ち勝つために、AFAは複数のアダプタを用意する必要があり、結果としてファブリックの構成は複雑になります。しかし、これは確実にコントローラーの制限にかかってしまい、お客様は更にAFAシステムを購入しなくてはならず、さらなるサイロを生むことになります。

これとは対象的にNutanixは常にクラスタにノードを追加する事になりますが、この度に仮想ストレージコントローラを追加することにもなります。これによってすぐさまパフォーマンスを上げることが出来ます。信頼性も著しく向上し、一つのコントローラが失われたとしても影響は非常に小さなものになります。これがNutanixが環境を破壊すること無く、1クリックで小さな影響のみでアップグレードとメンテナンスを行うことが出来る理由です。

5) データローカリティ

ロサンゼルス市内の車の75%が道路から突然なくなったとしたらなにが起きると思いますか? 渋滞があっという間に無くなるだけではなく、市は事故の減少、道路保全工事の削減、汚染の削減など他にも多くのメリットを得ることになるでしょう。

Nutanixのデータローカリティはデータセンタ環境においてこれと似たように作用します。ほとんどのReadのトラフィックをネットワークから削減し、そのかわりにReadはノード内のローカルSSDから提供されるようになります。Writeやエンドユーザーのアプリケーションが利用できるネットワーク帯域は効率的に増え、ストレージのパフォーマンスのみならず、ストレージが提供しているアプリケーションのパフォーマンスまでもが改善するのです。

Fig170

6) 拡張性

キャパシティパフォーマンス : AFAは大抵は2つの物理ストレージコントローラしか持ち合わせておらず、システム内に搭載されているRAM/NVRAMの総量によってメタデータのキャパシティの拡張がボトルネックとなってしまいます。SSDを追加しても、殆どの場合、パフォーマンスが向上することはありません。

同様に、AFAのお客様はもっと大きな処理能力をもつ多きなユニットへアップグレードするか、複雑なファブリックの相互接続を追加するか、もしくはサイロを作る以外に方法がありません。AFAの製造メーカーは既存のコントローラーを新しく高速なものに置き換え可能だとしていますが、その際の停止や出費を差し置いても、これはボトルネックをネットワークへと移動させるか、既存のフラッシュメディアに対してしか効果はありません。

Nutanixでは対象的に、AFAとは異なり、2つの物理ストレージコントローラによってボトルネックを生じることはありません。それぞれのノードの仮想マシンはそのノード上のコントローラー仮想マシン(CVM)によってサービス提供されます。クラスタにノードが追加される度に1つのCVMも追加されます、ですからキャパシティがリニアに拡張されるん見ならず、パフォーマンスと信頼性とが、管理スタック機能とともに拡張されていくのです。Acropolis ブロックサービス(ABS)とAcropolis ファイルサービス(AFS)はNutanixがお客様が拡張可能な物理と仮想のワークロードに使えるだけではなく、同じNutanixクラスタからファイルサーバとしても使えるということも実現しました。これによって非効率なサイロを削減できるのです。

Fig171

重複排除/圧縮パフォーマンス : Nutanixのユニークな重複排除と圧縮の実装はパフォーマンスへのオーバーヘッドを最小化します。Nutanixは物理リソースをより多く利用し、また結果に関係なくすべてのIOへ影響を及ぼす総当りでのすべてのデータの重複排除/圧縮は行いません。

信頼性 : 信頼性と高可用性の両方が全てのNutanixのスタックを通じて組み込まれています。レプリケーションファクター2(RF2)またはRF3をイレイジャーコーディング(EC-X)とともに利用することでディスクに対して優れた耐障害性を実現できます。ブロックアウェアネスはノード障害の回避を実現しますし、同期と非同期のレプリケーションはデータセンタ全体の信頼性を提供します。

オールフラッシュのストレージオンリーノード : ストレージオンリーノードによって、Nutanixのお客様はコンピューティングとストレージを別々に拡張することが出来るようになり、これによって自身のオールフラッシュ環境のコストを最小化することが出来ます。

7) シンプルさ

Nutanixのワンクリックアップグレードはアップグレードに関わる複雑さとリスクの両方を削減します。複雑な相互の組み合わせマトリックスや運用のガイドなどはありません。NutanixはフラッシュベースのアーキテクチャをLUNを排除し、ストレージの構造ではなく、その表示のフォーカスを仮想マシンにして、集中管理とキャパシティプランニングを含めることで、さらなるシンプルさを提供しています。

Fig172

8) ワークロードの統合

AFAはフラッシュ装置から情報をネットワーク越しに処理のためにコンピューティングまで送信する必要があります。以前に述べたレイテンシが追加される以外にも、これによってさらなるキュー管理とオーバーヘッドが追加されることになります。CPUはアプリケーションの要求で小さなブロックを同時に高いIOPSで受け取る、または大きなブロックを高いスループットでを受け取ると簡単に過負荷状態になります。一貫したパフォーマンスを保証するため、AFA管理者は頻繁に同じプラットフォームで動作しているOLTPとOLAPのワークロードを分離しなくてはなりません。

Nutanixはコンピューティングからダイレクトにアクセス可能なストレージを提供できます。限られたオーバーヘッドでリクエストをさばき、混在したワークロードに一貫した低遅延をもたらします。そして、Nutanix Acropolis ブロックサービスを利用すれば、Nutanixは異なるタイプのアプリケーションにたいしてまとめて対応が可能なストレージのバックプレーンとなります。お客様は物理のワークロードと下層のワークロードを同一クラスタ内で統合することさえできるようになるのです。

加えて、AFAはブロックのためのブロックストレージデバイスとファイルのためのフラッシュ装置を搭載しています。Nutanixでは、ストレージはブロックとファイルで共有されます。

Fig173

9) ミッションクリティカルアプリケーションの展開実績

Nutanixはたとえ、それが幾つかのワークロードの混在であったとしてもクリティカルアプリケーションのための適切なパフォーマンスを箱から出してすぐに提供することが出来ます。ストレージアクセスの障害回避、自己回復、常に行うデータの整合性のチェックなどを実装し単一障害点を排除しています。ストレージのパフォーマンスは想定通りで、複雑な構成やチューンングは不要です。

非破壊的なソフトウェアの更新で、計画的なダウンタイムを排除し、ミッションクリティカルアプリケーションをホストしているNutanixに新たな機能をもたらします。ソフトウェアのアップグレードや拡張のためのメンテナンスウィンドウはもはや過去のものとなりました。他の殆どのHCIとは異なり、NutanixはエンタープライズにSplunk、Oracle、SAP、SQLサーバ、Exchange、そして、他にも多くのミッションクリティカルアプリケーション(NutanixとVxRackのみがSAP認定を取得しています)での導入の数年もの実績と成熟が有ります。

Fig174

10) 総所有コスト(TCO)の低減

AFAは最終的にはコントローラーのキャパシティ不足に陥ります。テクノロジーは既存のAFAソリューションが比較しても経済的ではないと言うところまで進歩するか、もしくは、単に機材が古くなってしまうかです。いかなる場合であってもAFAを所持している場合にはフォークリフトアップグレード(完全入れ替え)ー その手順は大抵の場合、高価で複雑かつ、時間のかかるものですーに直面することになります。その結果として、AFAを所持していた人は殆どの場合、最初に必要な以上のキャパシティを購入し、4年か5年後に利用を終えるまで、要件に見合うリソースが充分かどうか、祈り続けることになるのです。

Nutanixを利用している人はフォークリフトアップグレードを今後経験することはなくなり、そのときに必要としている以上のノードを購入する必要はなくなります。テクノロジーが変化ても、新しいノードはクラスタにマウスクリックだけで追加が可能です、他の全てはソフトウェアが面倒を見てくれます。Nutanixはその下のリスクも排除してくれるのです。

ストレージ装置そしてストレージファブリックとそれに付帯して最初に購入しなくてはならない必要以上のキャパシティの必然性を完全に排除することで、Nutanixは導入コストの低減のお役に立ちます。プロジェクトがその後数年にわたって拡大したとしても、ムーアの法則とNutanixソフトウェアのパフォーマンス面での改善の両面に支えられ、ノードあたりの統合率は向上し、同じワークロードを動作させるのに必要なノード数は少なくなっているのです。

Fig175※ 訳注 : VDIのためのNutanixを4.5から4.7.2にアップグレードしたら、IOPSが40%向上し、レイテンシが50%も下がりました。ユーザーは「私のVDIセッションは今日はより早くなった」とコメントしています。私はhappy01です。

11) エンタープライズクラウドプラットフォームの先進性

最終的には、業務そのものについてだけではありません。どのようにそれを行うか、なのです。ウェブスケールアーキテクチャの利用はNutanixのユニークな差別化要素であり、ハイパーコンバージェンスをエンタープライズクラウドプラットフォームの一部へと昇華させています。Sassandra、NoSQL、MapReduce、そしてCuratorなどの分散テクノロジーはオールフラッシュ環境を最適化して、優れたパフォーマンスと効率性を実現しています。

データアクセス : 古くからある樹木構造でのメタデータのクエリアーキテクチャ(BtreeとR&B)はメタデータがそれぞれの物理コントローラに保存されているような装置環境では上手く動作しましたが、オールフラッシュのHCI環境では最適とはいえません。HCIでは、メタデータは多くのノードに分散されてー樹木構造での検索は非効率ですーいます。この非効率さに対処するため、NutanixはCassandraとNoSQLのようなビッグデータのテクノロジーを利用し、非常に高速な検索と、高い耐障害性を実現しています。単一障害点はありません。

データの保存 : 古の3階層や他のHCIのIOパス内でデータを並び替えるアプローチとは異なり、Nutanixはそれをバックグランド処理として行い、より高いパフォーマンスを実現します。ノードが追加される毎にシステムは拡張され、重複排除と圧縮はより高速になり、さらにデータのローカリティは増加します。シームレスな拡張性によって、データをメモリか利用可能なストレージ層に置くべきかという昇格、降格の評価も迅速になります。

分析 : オールフラッシュの環境であっても異なる階層のフラッシュ(パフォーマンスと耐久性)が存在します。メタデータは継続的に増え続けるため、メモリやもっとも高速な層へおいておくのはコスト効率的に難しくなります。

Nutanixはここでもビッグデータのアプローチでこの課題を解決しています。NutanixのためにカスタマイズされたヴァージョンのMapReduce/Curatorがデータのホットデータか否か、圧縮できるか否か、重複排除出来るか否かなどの主要素情報を決定するために利用されます。同様のフレームワークを用いて、ローカリティのために、どのデータを別のノードへ移すべきなのか、どのデータを消すべきなのか、どのデータが再配置または再均一化されるべきなのか決定されます。これは特に障害イベント時に利用されます。

こうした解析は傾向分析、リアルタイム分析、事前的な監視、根本原因の分析、アラートの発行のための深い知見を実現します。

タイミング : 最適とはいえない、インラインでの圧縮やプロプライエタリハードウェアによる重複排除などに依存している他のソリューションとは対象的に、NutanixはオフラインでのMapReduce/Curatorによるソートに対応しています。これによって圧縮するか、重複排除するかの判断をする以前に、より多くのWriteを実行でき、一極集中しているデータベースのパフォーマンス要件の制限を回避しています。

ユニファイドキャッシュ : キャッシュはローカリティを実現します。重複排除はより多くのデータをこのパフォーマンス層に格納することを可能にし、ローカルキャッシュのヒットの可能性を最大化します。パフォーマンスに制限をうけることなく効率性を最大化するため、Nutanixはインラインでコンテントキャッシュのローカルでの重複排除を行います。

Fig176

NVMe : 死刑囚が(処刑台に向かって)走っている?

少なくとも1つの従来からのストレージ製造ベンダーがNVMeをそれこそが未来だとしてプロモーションしています。しかし、NVMeへの移行は今まで以上にデータはコンピューティングの隣りにあるべきで、ネットワークの彼方ではないということを強調することになるでしょう。これはすべてのファブリックを延長しただけの一枚板の滅亡への道のりを早めるだけです。ーもちろん、AFAもそれに含まれます。

コンテンツと編集について以下のメンバーに謝辞を述べたいと思います。@joshodgers @briansuhr @_praburam @Priyadarshi_Pd @sudheenair @binnygill @vcdxnz001 @RohitGoyal

もっと詳しく

NutanixのFlash ForwardウェブサイトのランディングページとeBook

Ten Things You Need to Know About Nutanix Acropolis Block Services (後日翻訳予定)

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

免責事項: このブログはNutanix.com以外へのコンテンツへのリックが含まれています。Nutanixこうしたサイトへの統制は行うことが出来ないため、全ての外部サイトのコンテンツと正確性について、免責とさせていただきます。外部サイトへのリンクはこうしたサイトのコンテンツへの承認を表明するものではありません。

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

Ntc2017_2

さて、10つの事シリーズですが、いきなり11つあります。前回、前々回とMichael Webster氏の記事を翻訳してきたのはこの記事のための伏線だったわけです(単に、引用を辿っただけとも言う・・・)。Nutanixの(特にI/O周りの)技術を知れば知るほど「一つ一つの技術」ではなく、それを積み上げた「アーキテクチャ」であるということが言えると思います。特にストレージのパフォーマンスに関しては色々と痛い目を見てきたり、その技術自身の素晴らしさに夢中になって学んでしまったり(かくいう私もそうですが・・・)と、一筋縄ではいかない人間が集中しています。今回の記事はそんな方に読んでいただきたい内容です。若干いろいろなところで(理解のしやすさのために例を上げているのだと信じていますが)バチバチと火花を飛ばすような表現も有りますが、実によくまとめていると思います。ぜひセミナーへも足をお運びください!