Storage Feed

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/02/01

ランサムウェアの被害が広まる??

日本国内でもランサムウェアの被害の件数と身代金の支払額が大幅に上がっているようです。

”ランサムウェア 2016”で検索するだけでもかなりの記事が出てきます。

被害は、一般企業よりも、医療公共教育関係が多く、全体の8~9割を締めています。報道される事例もあるわけですが、氷山の一角であろうと推測されます。

2016年の統計では、Q2からQ3で急激に件数が延び4倍に達したとの報告があります。

2017年も始まり1ヶ月が経ちますが、今年もウカウカしていられない状況が続きそうです。

また、身代金を支払っても、100%復旧できるかというとそうではないようです。 半数近くがデータが戻らない状況があったようです。 酷い話です。

始めから感染しなければ何も問題がないわけですが、お金を払った後でデータが元に戻らないのは問題です。

ついでに、偽のランサムウェア(感染していないけど攻撃したように見せかけて身代金を要求する)で身代金を支払った事例もあるようで、被害を恐れる心理面に漬け込む悪質な事例です。

インフルエンザと同様避けて通れない状況になってきていますので、感染しても大丈夫なように手立てを考えるべきだと思います。ネットワークには繋がり続けているわけですから、必要な対策をするべきでしょう。

セキュリティ面とデータ保護の2面から取り組むべきです。セキュリティ対策だけでは感染してからは手立てがないので、大事なデータは事前にバックアップが必要です。

それも出来る限り長い期間のバックアップを残すことが重要です。

今年もPCやスマホ、企業だけではなく個人のデータについてもバックアップを考えるよい機会だと思います。

是非、弊社のランサムウェア対策をご覧ください。

ランサムウェア対策:http://www.networld.co.jp/solution/ransomware/

Edit by :バックアップ製品担当 松村・安田

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のストレージの「パフォーマンス」と「キャパシティ」と「データサービス」を分離すべきであるという思想と完全に一致します。しばらくオールフラッシュ系の翻訳を続けます。次回も乞うご期待!

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/12

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

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


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

7vocbqxlurq9an61481180153_148118042


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


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

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

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

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

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

A9000qostest001


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

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

検証が進むにつれ

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

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


                        by:まいけル
        

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/10/27

ランサム[身代金ウィルス]ウェアの対策してますか?

身近な言葉になってきた”ランサム[身代金ウィルス]ウェアですが、企業でもアンチ・ウィルスソフト(セキュリティ対策ソフト、振る舞い検知、隔離用のサンドボックスなど)の導入で防御し対策を行っており、セキュリティの面で語られることが多いと思います。

ただ、セキュリティ対策ソフトからすると、常にパターンファイルの更新を行い、おかしな振る舞いを監視する事象を追いかける形になっています。 つまり、新種が出ると、対策についてはイタチごっこ、盾と鋒で新たな攻撃を受けた後の対策となり、即席では直らず時間が掛かることになります。 また進入の経路も多岐(メール、Webアクセス、ファイル転送)に渡り、その対策についての労力も馬鹿にならないものになります。

初期のウィルス・ソフトは悪戯が主目的で、悪意があってもウィルス・ソフト製作者の技量を見せつけるタイプのソフトが多くありましたが、2000年以降のウィルス・ソフトは企業内で問題となる事象(サイト攻撃やスパムメールの踏み台)が増えて来ました。また、サーバやPCに影響を及ぼし、業務に支障がでるようなウィルスも多くありました。昨今のウィルス:特にランサムウェアと呼ばれるものは、ファイルを暗号化することやPCを起動させなくすることで身代金を要求するウィルスであり、1回に要求される金額が小額(平均300米ドル)であっても、デジタルの環境(ビット・コインによる金銭授受)が整っていることもあり、不特定多数に対して金銭要求することでビジネス(ウィルス開発者が儲ける)になっている事が大きな違いであり、1件あたりの被害額は少なくても多数の被害の積み上げで被害額が拡大している事や特定が難しいのが特徴です。 

また、暗号化されたファイルやシステムが立ち上がらないような状態から、自力で元通りに復旧させるには時間も能力も必要です、その費用や労力の割には、要求される金額が小額であることから、一番の解決策が身代金を払う事と言われています。

セキュリティ対策としてアンチ・ウィルスソフトを導入するのは、個人でも、企業でも一般的だと思います。 ただ、アンチ・ウィルス対策は、最後の砦、突破されたらおしまいです。

それ以前の対策として、バックアップ有用性を考えてみてください。 以外と端末のバックアップは個人に任せていることが多くないでしょうか? やはり、怪我や病気、車の事故に対応した保険と同じく、データの保険は、やはり転ばぬ先の杖であるバックアップ(データ・コピー)が対策として有効な手段だと考えます。

ランサムに関しては個人の端末(スマフォ、タブレット)に波及するケースが多く、被害の範囲は狭いものの個人には打撃の大きいものとなります。 攻撃されても補える力(データの2次コピー)を持っていれば、余計なお金(身代金)を払わずに済み、被害の拡散防止にも役立ちます。

データのバックアップは、利益を生み出すことが無いですが、皆さんの心に安心を与えてくれます。 無くなって困らないデータであればコピーは必要ないですが、大事な個人のデータや企業のデータの消失対策としてのバックアップと、アンチ・ウィルスソフトとの2段階で防御/対策するのが望ましいでしょう。

バックアップもサーバ向けのバックアップ・ソフトだけではなく、PCや個人端末に対応したバックアップ・ソフトもあります。

是非、弊社のランサムウェア対策をご覧ください。

ランサムウェア対策: http://www.networld.co.jp/solution/ransomware/

Edit by :バックアップ製品担当 松村・安田

2016/09/28

VMware ESXi ストレージ IO パス

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

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

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

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

私にとってESXiの中をIOがどのように流れていくのは長い間謎に包まれたものでした。もちろん、私はパス選択ポリシー(PSP)がどういうもであるのかや、ストレージアレイタイププラグイン(SATP)がどういうものかということは知っていましたし、vSCSI statsについても聞いたことが有りましたが、それでもI/Oのフローについて深く説明するということは出来ませんでした。仮想マシンから出たI/Oがどうにかしてカーネルに入っていく、というぐらいしか知らないようなものだったのです。それでもESXTOPのようなstatsコマンドで特定のパフォーマンスの値を監視したり、PSPのレベルでベンダーが推奨する通りの設定を行い、パフォーマンスを監視するということは出来ます。そして、そう、RAWデバイスです。これはまた別のストレージプロトコルやキューが登場します。ですが、これは全体でどのようになっているのでしょうか?

このブログの記事はストレージ IO パスについて一定のレベルでの詳細をご説明します。エンジニアリング(製品開発部門)と緊密に動くことの良い点は日々非常に多くの事を知ることが出来ますが、それを自分のものにしていくことが難しくなるのです。ですから、この多くの情報をより深く調べ、最終的にはブログの記事にまとめることにしました。もちろん、ESXi 6 U1にはVAIO(vSphere API for IO Filtering)フレームワークが追加されていますが、これについては別の記事に後でまとめたいと思います。VAIOを利用すればベンダーはユーザーワールドのコンテキストで動作するフィルタドライバーを経由してしっかりとVMwareのコントロール下に置かれたやり方でI/Oに割り込む方法で開発を行うことが出来ます。今日の時点ではVAIOはまだ新しすぎて、殆どのベンダーはVAIOを利用する製品をリリースすることが出来ていません。どうしてこんなことを書くのかって? それはPernixDataの(そして、今はNutanixの)フラグシッププロダクトであるFVPとストレージ分析ソフトウェアであるArchitectはESXiのプラガブルストレージアーキテクチャ(PSA)で統合されています。更にVVOLによってストレージの管理は著しく簡単になろうとしています。ですが、私はテクニカルサポートエンジニアとして日々過ごす中で、VVOLについて考えはじめ、もしくはさらに次のインフラストラクチャが登場するのではないかと考え始めています。VMwareは既にVVOL以前にポリシードリブンストレージマイグレーションで素晴らしい結果を上げており、私の対峙している顧客は十分満足しています。結果として、VVOLについて考えるのが後回しになっているのです。

仮想マシンからの全てのIOはユーザーワールドのコンテキストでvCPU、VMX、MKS、SVGAなどのそれぞれから、異なるスレッド(ワールド)で開始します。ユーザーとカーネルモードのち我について理解するためには私の最初の記事カーネル vs. ユーザーモードをご参照ください。仮想マシン自身のマネージャーはVMM(仮想マシンモニタ)です。

それからIOは基本的にはVMkernelを通じてどんなアクションが行われるか、そのストレージ実装が利用されているかによって様々なジャンクションを通っていきます。

  • Block Storage(ブロックストレージ):
    • Fibre Channel (FC)
    • Internet Small Computer Systems Interface (iSCSI)
    • Fibre Channel over Ethernet (FCoE)
  • File Storage(ファイルストレージ):
    • Network File System (NFS)

すべてのI/OはVMMレベルで開始されるため、ここまではスキップしてvSCSIフロントエンドからのI/Oフローをご説明していきます。I/OがユーザーワールドからvSCSIフロントエンドへ流れていく部分は非常に面白いです。そして、VMXNETやPVSCSI実装などの準仮想化実装とどう違うのかがわかります。

ESXi I/O フロー

  • vSCSI フロントエンド:
    • フラットバックエンド(VMDK)またはRDMバックエンドのIOの両方が流れてきます。
    • それからI/OはFSS(ファイルシステムスイッチ)へと流れ、その後、DevFS(スナップショット関連のI/O)、VMFSレイヤ、NFSレイヤのいずれかへと導かれます。
    • NFSの場合、その後、ESXiのSUNRPC実装とTCP/IPスタックを経由してVMカーネルインターフェイス(vmk)へとI/Oが進んでいきます。
    • VMFSの場合、道はFDS(ファイルデバイススイッチ)へと続き、そこで、ディスク(通常のスナップショットのないI/O)、スナップショットドライバ、またはLVM(ロジカルヴォリュームマネージャー)へと分岐します。
      • ディスク : 通常のVMDKのI/O。
      • スナップショットドライバ : 仮想マシンがスナップショットを発行するか、スナップショット上で動作している場合、すべてのI/Oは再度FSSへと送られ、スナップショットの連鎖はDevFSの実装を通してマウントされます。
      • LVM : ディスクが作成、拡張、結合された場合。
    • I/OはPSA(プラガブルストレージアーキテクチャ)へと進んできます
      • デバイスキューは2つのエリアに別れます:
        • SCSIデバイス
        • SCSI Sched キュー
      • ここへ至ったIOは殆どの場合、NMP(ネイティブマルチパシングプラグイン)かEMCがPowerPathと呼んで提供している完全なプラグイン実装へと流れていきます。今回はNMPのみにフォーカスします。
        • SATP(ストレージアレイタイププラグイン) ストレージシステムとの連携を実現するコントロールプレーン
        • PSP (パス選択ポリシー) ストレージ自身へのI/Oを制御するデータプレーン
      • 最後にI/Oは物理的なHBA、キューイング、SCSIエラーを管理するSCSI Midlayerへと到達します。ESXiのSCSI Midlayerについてもっと詳しく知りたい場合にはこのリンク先のVMware SAN System Design and Deployment Guideの58ページもご参照ください。

以下の図はI/Oフローの詳細をそれぞれのパーツを結合して顕したものです。

Fig028

ESXiのストレージ実装

VMM:

仮想マシンモニタ(x86 CPU、SCSIコントローラをエミュレーション、等)

共有リング:

共有リングはVMMとVMカーネルの間の共有キューで、VMMもしくはVMカーネルの両者はパフォーマンスのペナルティなくこの共有リングへアクセスが可能です。共有リングのサイズは発生させられるI/Oの数を決めてしまいます。VMカーネルが共有リング内のI/Oを見つけるとすぐに、このI/Oをキューから取り出し、vSCSIフロントエンドへと送ります。もっと詳しく知りたい方は以下のKBを参考にしてください。

ソース : VMware KB: 2053145

vSCSI:

VMカーネルのSCSIフロントエンドで、SCSIリクエストと仮想化されたファイルへのI/Oリクエストを送信します。

Flat Backend(フラットバックエンド):

ファイルをエミュレーションします。

RDM Backend(RDMバックエンド):

RAWのLUNへのポインタ/シンボリックリンクです。リンク内に識別子が埋め込まれます。

FSS (ファイルシステムスイッチ):

ファイルシステムのドライバを実装する際に利用できます。APIは公開されていません。

DevFS:

殆どのUNIXベースのファイルシステムと非常によく似ており、実デバイス、非実デバイスをエミュレーションします。

VMFS:

VMFSの3と5の両方を実装した単独モジュール。

NFS:

NFSプロトコルを実装しています。

FDS (ファイルデバイススイッチ - ブロックストレージ):

ディスク、スナップショット、そしてLVMの切り替えに利用されます。

ディスク:

すべてのディスクベースのブロックデバイスをエミュレーションします。ストレージスタックと直接やり取りします。

スナップショットドライバ:

フィルタドライバとして実装されています。フィルタドライバによって、FSSへとIOが戻るため、ディスクが再帰的にDevFSへとマウントされます。

LVM (ロジカルヴォリュームマネージャ):

削除、結合、作成などが発生した場合にはLVMへと司令が送られます。LVMはヴォリュームの結合を行い、論理領域としてヴォリュームを上のレイヤへ見せます。VMFSとしてデータストアをフォーマットすると以下のように動作します:

  • はじめにLVMに論理ボリュームが作成される
  • それから、そのヴォリュームがVMFSでフォーマットされる

このようになる理由はディスクが異なるLUNをまたがって拡張、結合される可能性があるからです。もちろん、再署名 例えば、スナップショットされたLUNでは同一のUUIDが利用されているので、LVMによって再署名される可能性があります。

PSA (プラガブルストレージアーキテクチャ):

SCSI デバイス:

すべてのローカル、そしてリモートのデバイスはSCSIデバイス構造になっています。(ターゲットあたり256以上のLUNは存在し得ない)


SCSI スケジュールキュー:

ストレージスタックは比例型の共有スケジューラ(シェア)を実装しています。SIOC(ストレージ I/Oコントロール)はこれをクラスタベースで行うものですが、SCSIスケジューラーキューを利用しています。シェアの値には全てのSCSIディスクの数が利用されます。

SATP (ストレージアレイタイププラグイン - コントロールプレーン):

ベンダー固有の機能を有しています。例: Trespass : LUNで利用可能なSP(サービスプロセッサ - ストレージシステムのコントローラ)のアクティブ-パッシブを制御します。また、I/Oが異なるSPから流れ込み、そのためにその異なるSPへと接続してI/Oを受けたなどを状態を理解することも可能です。SATPは障害時にもストレージとのコミニュケーションを行います。

PSP (パス選択ポリシー - データプレーン):

PSPはバックエンドのストレージにどのようにReadとWriteを提供するかを司ります。PSPには3つのフレーバがあります : MRU(もっとも直近で利用したパス)、Fixed(固定)、そしてRR(ラウンドロビン)。

  • Most Recently Used (MRU): VMW_PSP_MRUポリシーは利用可能な最初のパスを選択します。このパスはシステムのブート時に検知されます。パスが利用できなくなった場合、ESXi/ESXホストは別のパスへとスイッチし、新しいパスが利用できる限りはそのパスを利用し続けます。これはアクティブ/パッシブのストレージ装置において論理ユニット数(LUNs)の標準ポリシーです。ESXi/ESXは万一、パスが復帰したとしても以前のパスへと復帰しようとはしません。利用している障害が起きないかぎりは、です。
  • Fixed (Fixed): VMW_PSP_FIXEDポリシーは指定された場合にはそのフラグが立っているパスを固定的に利用します。もし指定がない場合、システムのブート時に検知したパスの最初の利用可能なものを利用します。ESXi/ESXがその選択したパスを利用できない、もしくは出来なくなった場合、ESXi/ESXホストは別のパスを選択します。ホストは自動的に事前に定義されたパスが復帰するとすぐさまそのパスへと復帰します。このポリシーはアクティブ/アクティブのストレージ装置を接続したときのLUNsの標準ポリシーです。
  • Round Robin (RR): VMW_PSP_RRポリシーは自動的にパスを選択し、利用可能な全てのパスの中で負荷を分散しながら設定されたパスを利用します。
    • アクティブ/パッシブストレージ装置では、アクティブなコントローラのパスのみがこのラウンドロビンポリシー時には利用されます。
    • アクティブ/アクティブストレージ装置では、全てのパスがこのラウンドロビンポリシーで利用されます。

ソース: VMware KB 1011340

このブログの記事が少しでもあなたのお役に立てば。もちろん質問があれば、いつもどおり気軽にコンタクトください。

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

さて、前回に引き続き、Guidoさんの記事です。VMwareのカーネルの中(といっても、ストレージ部分だけですが・・・)をこんなに解説してくださっている記事はなかなか無いと思いましたので、前回のものと合わせて翻訳させていただきました。前回とは異なって、I/OがESXiの中をどう流れていく?ということを順を追って解説してくれています。さすが、カーネルの中でI/Oを捕まえてぶん回している会社(PernixData/今はNutanix)のサポートチーム・・・詳しい!もちろん、VSANについてはまた上の図の中に別の枝が出て実装されていますし、今後はVAIOでもっと面白い実装も出てくるのではないかと思いますが、あくまでベーシックということで。技術的に深すぎてNutanixもPernixDataもVSANも違いがなくなってきています・・・そんな技術を組み合わせてソリューションを生み出していく各社・・・。そして、我々はそれを理解した上で、お客様に最適なソリューションをご紹介するソリューションディストリビュータです。

次回もGuidoさんのふかーい記事を翻訳予定です。まだまだ続きます。

2016/09/14

ウェブスケールインフラストラクチャ上のオールフラッシュのパフォーマンス

本記事の原文はNutanix社のGlobal Engineering / R&D TeamでManager Business Critical Appsを務めるMichael Webster氏によるものです。原文を参照したい方はAll Flash Performance on Web Scale Infrastructureをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig020_2

オールフラッシュストレージアレイは今日では人気を博し、従来からのミッションクリティカルなファイバーチャネルのアレイから大きくビジネスを移行させつつ有ります。そして、従来型の3層構造のアーキテクチャは少しだけですが、シンプルになりました。僅かな数の仮想マシンが大きなパフォーマンスを必要とするようなスケールアップ型のワークロードに対し、優れたパフォーマンスを提供し、さらに、データ削減のテクニックを利用してキャパシティの削減も同時に提供しています。オールフラッシュシステムがさらに優れているのは大きな負荷がかかったり、キャパシティが限界に近い状態であったとしても一貫したパフォーマンスと低遅延を提供するということです。しかし、従来型のアーキテクチャに比べて少しだけシンプルだ、ということはまったくもってシンプルであるとは程遠いのも事実です(FCの管理オーバーヘッドだけ)。そして、まだインフラストラクチャがインビジブルであるともいえません。まだ幾つかの制限があります。オールフラッシュが欲しくて、更に制限のないスケールアウトも欲しい、数千の仮想マシンを動作・サポートしなくてはならない、でも管理を従来型の3層構造よりも簡単にしたいとなったらどうしますか? 効率よくインフラストラクチャをインビジブルにしたいのです。

答えはとても簡単です。インフラストラクチャが将来そうなるのと同じで、Nutanixを選択すればよいのです。Nutanixは1年前にオールフラッシュソリューションを打ち出しました、そして一貫した高パフォーマンスと想定通りの低遅延優先度の高いワークロードに対して望むお客様に大きな人気を博しています。NX 9040ノードは6本のIntel S3700というエンタープライズクラスのSSDとE5 v2を2ソケット、最大で512GBのメモリを融合させています。このソリューションは2ラックユニットのスペースに2ノード(最大でラックあたり364TBの物理フラッシュストレージ)収めることが出来ます。これはOracleデータベースやSQLサーバ、SAP、Temnos T24 core Bankingなどにうってつけのプラットフォームで、これら全てを動作させているお客様までいます。特に、Nutanixのデータ削減機能やデータ回避機能と組み合わせると、同じ物理ストレージ内で更に多くのキャパシティを利用することが出来ます。Josh Odgers氏(NPX #001)はEC-Xと呼ばれる新しい機能(訳注:リンク先は英文、現在のところ翻訳予定なし)についての記事を公開しています。

Nutanixのデータ削減

データ削減には圧縮、データ重複排除そして、EC-Xなどが含まれます。データ回避機能は例えばVAAI統合、シンプロビジョニング、そしてスマートクローンとスナップショットなどで、不必要なデータや重複したデータを最初に作成しない機能です。データベースやビジネスクリティカルアプリケーションでは、圧縮は推奨されています。重複排除については大規模なデータで異なるデータが多い場合にはさほど効果的ではないというケースも有ります。こうした手法によってそのまま利用するよりも、もっと利用できるキャパシティが増える可能性がありますが、その効果はワークロードによって様々です。2:1、3:1もしくはもっと高い割合のことも有ります。単一の手法だけでも、ワークロードに向いている手法であればもっと高い割合になることもあるのです。

データベースにおいてSQLサーバで透過的データ暗号化(TDE)やOracleでアドバンスドセキュリティ暗号化を利用しているような場合、これほどには効果が出ない場合もあります。NX9040を含む、同じプラットフォームでデータ最終暗号化をサポートしており、これによってアプリケーション自身での暗号化を不要にする事も可能です。暗号化されたワークロードにおいてキャパシティを効率的に削減するのは難しいものです。以下のイメージはNX9040の単一クラスタでNutanixのPRISMユーザーインターフェイスから見た際のOracle RAC データベースがどれほどの削減がなされたかを表しています。これは実現出来ていることのほんの一例でもちろん、ワークロードに依存します。効果は様々なのです。

Fig021

上記のイメージからはデータベースが5.57TiBのキャパシティをデータ削減前に利用していたということが分かります。データベース自身は3TBですから、データ保護やデータ保全性のためのオーバーヘッドがあることが分かります。データ削減が行われた後のキャパシティは1.95TiBのみです。この削減効果は圧縮からの効果のみです。もしも圧縮とEC-Xを組み合わせれば、もっと大きな削減効果を得ることが出来るはずです。Nutanixクラスタが大きくなれば、データ削減の手法は更に効率的なものになります。

もう一つ圧縮の例を上げましょう。今回はExchangeにJetStress Databaseで負荷をかけたものです。(注意 : JetStressは実際の世界ではあり得ないワークロードでここでのデータ削減率は実際のExchange環境での物よりも高い可能性があります。)

Fig022

殆どの環境では検証・開発のワークロードが本稼動系とともに動作しています。Nutanixのやり方では、ワークロードのスナップショットの作成やクローンの作成してもストレージ消費は増えることはありません。これ等の操作ではデータに変更がないからです。これはテンプレートを展開する際にもESXiとVAAI(VMware API for Array Integration)で同様に実現されます。新しい仮想マシンを欲しいだけ展開しても、実際にデータが書き込まれるまではストレージの消費は増えないのです。

こうした手法を利用して、100%完全なデータを開発・検証環境で利用しながら、ストレージの消費を抑えることが可能です。高いレベルでコードが動くという確信を持ちながら、本稼動系へとワークロードを移行することができ、いつでも検証環境の状態へと戻ることも出来るのです。全ては数秒で追加ストレージキャパシティを消費するという心配は必要ありません。

Nutanixのデータ削減とデータ除外手法についてはNutanixバイブルの分散ストレージファブリックのセクションもご参照ください。

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

データ削減や回避の手法によってワークロードのパフォーマンスも様々に変化します。単一のアプリケーションからのIOパターンが単一であるということはほとんどありません。ですから、パフォーマンスを検証するのにもっともよい方法は実際のアプリケーションを利用することです。実際のアプリケーションは4KBサイズのIOだけを生成するということは一般的にはありません。ですから、今回はNutanixのオールフラッシュのパフォーマンスを検証するためにSLOB(SLOBのオフィシャルページはこちら)、SwingbenchBenchmark Factory for DatabaseHammerDBのようなツールを利用しました。ここではSLOBを利用して取得したイメージを例に提示します。

IOパフォーマンスを検証する際に、文脈を無視して、単独の計測値だけを見てはいけません、そうしなければ検証は意味が無いものになってしまいます。IOPSを例に取ると、IOサイズ、レイテンシ、スループットが異なれば劇的に値が変化します。ですから、IOPS単独だけでは確かな計測ができているとはいえません。今回のテストでは、Oracle RAC環境に対して、SLOBを利用して大量の小さなReadを生成しました。それぞれのReadは8Kで、これはデータベースの生のページサイズです。このIOパターンは100%ランダムです。トランザクションログのIOはかなり大きなIOサイズであり、当然シーケンシャルです。

以下のダイアグラムのテストを行ったシステムは2ノードのOracle RACクラスタ(それぞれのノードで 48 vCPU、192GBメモリ)を2台のNX4170(4 x E-4657L v2, 512GBメモリ)と4台のNX9040(2 x E5-2690 v2 512GBメモリ)で構成されたNutanixクラスタ上で動作させています。いずれのシステムも旧世代のIntelのIvy Bridgeのプロセッサ技術を利用しています。ハイパーバイザーはESXi 5.5を利用しており、後にESXi 6.0にアップグレードしたところ、更によいパフォーマンスを示しました。

Oracle RAC SLOB IOPS

Fig023

上のイメージでは2つのテストが行われています。一つ目は30%がupdate(更新、データ書き換え)であるというワークロード、もう一つは100% select(選択、データ参照)のワークロードです。updateのワークロードではきっかり70K IOPSが生成されています。

Oracle RAC SLOB レイテンシ

Fig024

異なるベンチマークの最中のレイテンシが上に表示されています。updateの多いテストではレイテンシは高くなり4ミリ秒ほどになっており、ピークでは7ミリ秒になっています。selectの多いワークロードに於いてはレイテンシは0.45ミリ秒です。2つ目のテストでのレイテンシが低いのはハイパーバイザーを最新ヴァージョンにアップグレードすることによって更に低くなりました。

Oracle RAC SLOB スループット

Fig025

上のグラフから読み取れるのはupdateが多いテストではスループットはカッチリ800MB/秒で、selectが多いテストでは1.13GB/秒でした。思い出して欲しいのはこれはNutanixのハイパーコンバージドアプライアンスであり、全体で8ラックユニットのスペースにコンピューティングとストレージの両方が収まっているということです。近い将来、Nutanixはもっとこうしたパフォーマンスを実現するための物理的なスペースと電源要件を削減する予定です。もっと小さなスペースで、そして、もっとシンプルな環境でオールフラッシュのワークロードを動作させることができる様になります。

オールフラッシュが必要なのか?

利用するか、利用しないかは当然皆様のご選択です。Nutanixは強力なオールフラッシュのオプションをNX9040で提供しています。将来のプラットフォームではこれをさらに推し進め、もっと極端なワークロードへも対応できるようにしていきます。Nutanixのプラットフォームではあらゆるノードのタイプでいくらかのフラッシュが搭載されています。データはフラッシュとハードディスクにおいてブロックレベルでのアクセス頻度に応じた階層がが行われます。オールフラッシュが必要か、そうでないかということは結局のところ、ソリューション全体のライフタイムの中で予想通りの結果を売ることが出来るか、というところに帰結します。アプリケーションがホットデータしかなく、フラッシュの上にすべてデータが有ることを保証したい場合にはオールフラッシュはそれに答えてくれます。オールフラッシュプラットフォームはオーバーヘッドが小さく、データ階層化の必要性がありません。ですが、ほとんどのワークロードにおいてはデータ階層化は非常に効率的で、充分です。

現段階で、オールフラッシュに向いているのはデータベースやアプリケーションサーバのような、低遅延サービスの保証が必要とされるものです。特に、パフォーマンス以外にも、仮想化によって物理ノードあたりのシステム数を上げることでライセンス上のメリットを受けられるような場合、更に多くのアプリケーションをノードに仮想化することが出来ます。OracleやSQLサーバを考えてみてください。

Nutanixは最近ハイブリッドのノードにおいても、フラッシュピンニングという機能をアナウンスしました。まだリリースされていません(原文執筆時、現在はリリース済み)が、リリースされた暁には仮想マシンや仮想化ディスクをフラッシュ層にピン留めすることが出来るようになります。この機能は標準のハイブリッドとオールフラッシュオプションの中間に位置するようなものです。時が経つにつれ、ほとんどのシステムはフラッシュの寡占状態になり、ハードディスクはスナップショットやバックアップ、アーカイブなどでのみ利用されるようになるのではないかと予想しています。

おわりに

今回の記事に掲載したイメージのとおり、ハイパーコンバージドのウェブスケールプラットフォームのオールフラッシュは特筆すべき管理の簡単さ、低遅延、制限のないスケールアウトが必要な環境において、優れたパフォーマンスを提供します。プラットフォームにより多くの利用可能なストレージキャパシティを提供するデータ削減と回避の手法は他のオールフラッシュアレイと同様にNutanixでも動作します。これが唯一上手くフィットしないところがあるとすれば単一の極端なワークロードまたは仮想マシンがアレイのパフォーマンスの全てを必要とするというようなケースでスケールアウトできない、計画もないというような場合だけです。こうした状況であればPure Storageのような物を選択する方が良いでしょう。それ以外のすべての場合、Nutanixは他のものに比べ遥かにシンプルなソリューションで優れたパフォーマンスと無制限の拡張性を提供することが出来ます。

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

いかがでしょうか? 既に様々なベンダーからオールフラッシュストレージソリューション、オールフラッシュハイパーコンバージドソリューションが提供されていますが、今回あえてこの記事を翻訳したのはいくつかのブロク/ニュースに記載されているように当社が国内で提供を行ってきた(そして私の大好きな!)PernixDataのテクノロジーが上でお見せしてきたような優れたパフォーマンスに加えて利用ができるようになるとの期待からです。PernixData社のソリューションはFlashだけではなく、メモリ、そしておそらくは今後多く登場してくるメモリクラスストレージ(または大容量不揮発性メモリ)のテクノロジーにまで利用することが出来るようになっています。Nutanix社のCVM(VSA)の実装とPernixData社のin-kernelの実装が今後どうなっていくかなど、興味はつきませんが、PernixData社が大好きな私以外の皆様の興味にも答えられるように、今後も面白い記事を選びながら更新していきたいと思います! 引き続きよろしくお願いいたします。