« 2016年12月 | メイン | 2017年2月 »

2017年1月

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

2017/01/18

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

Fig163


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

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

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

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

Fig164

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

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

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

Fig165

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

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

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

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

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

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

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

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

終わりに

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

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

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

Ntc2017_2

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

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

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

2017/01/11

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

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

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

Fig149

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

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

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

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

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

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

Fig149_2

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

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

Fig150

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

Fig151

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

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

Fig152

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

Fig153

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

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

Fig154

Fig155

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

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

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

Fig157

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

Fig158

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

Fig159

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

Fig160

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

Fig161

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

終わりに

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

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

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

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

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

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

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

Ntc2017_2

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

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

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

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

2017/01/05

Nutanix関連記事まとめ

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

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

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

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


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


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


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


ROI関連


エコシステムベンダーソリューション


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


ファイルサービス関連


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


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


PernixData関連


その他