« 2017年2月 | メイン | 2017年4月 »

2017年3月

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のパートナーになれば誰でも直ぐに触ってみていただくことが出来ます。パートナーになりたいという方は、ぜひ当社へご相談いただければ幸いです。