本ブログエントリーはPernixData社のCTO、Co-FounderであるSatyam Vaghani氏のブログの翻訳版です。
本記事の原文はA portal into the planet's virtualized datacentersで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
背景
とある問題
2015年の6月に遡ります。私はPernixDataのビジョンとしてビッグデータやリアルタイム解析の技術を企業のデータセンタに融合させるというビジョンを公開しました。企業のインフラストラクチャチームはとりおり、｢ハムスターモード｣で運用を行っているということに気がついたのです。つまり、ネットワーク運用センター内で赤いライトの点滅として現れる新しい問題を追跡し、そのライトが緑に戻るまで様々なハックをためしてみるという状態です。動作させているワークロードについてより深い知識を得るためのソリューションを持ち合わせていないのです。さらにいえば、永遠に、データに基づいて仮想化されたインフラストラクチャの設計、運用、最適化を行うことなどはできないのです。
トラブルシューティングを減らし、もっとよく理解する。私はは映画マトリックスの以下のやり取りを思い出します。
ネオ : 何が言いたいんだ? それでピストルの弾丸を避けられるとでも?
モーフィアス : 違う。 出来るようになったらそう言う。出来るようになろうとしなくてもいい。
トラブルシューティングはこの弾丸を避けるようなものです。何が起こっているかを理解すれば、トラブルシュートをこれ以上やる必要はなくなっていくのです。
なにがおこったのか?
どうしてこれまでに上記のような問題を解決するソリューションが発明されなかったのか、不思議に思うかもしれません。技術的な理由と、そうではない理由があるのです･･･。
技術面からは、非常に多くのデータを、しかもほとんどリアルタイムに集めなくてはならなかったという点から、こうしたソリューションが発明されてこなかったのだと思っています。そして集めたデータをどのようにデータセンタが動作しているのかということを理解している解析エンジンに通す必要があります。結果としては問題発生イベント(赤の点滅ライト)のみならず、どのようにそれを沈静化するかという意味のある結論を導き出さねばなりません。それだけではありません、ワークロードがどのように変化していっているか、なぜ変わっているのか、その変化が上位層へどのような変化をもたらすかなど。これら全てはコードにすることが非常に難しいものです。
技術的でない面からは、私は赤い点滅ライトを見せることだけに過剰に執着したことによって、ソリューションの発明が遅れたと思っています。いわゆる、いにしえのデータセンタの運用方法です。運用だけではなく、データセンタの設計や最適化を手助けしてくれるツールにはフォーカスがあたっておらず、ハードウェアに依存する形でしか、これを実現しようとするベンダーはいなかったのです。
さて、もう一つの面です。我々はFVPの物語を発展させていくと、このことは非常に論理的であるということがわかっています。というのもFVP 1.0を発明した際から積極的にストレージ解析についての機能を組み入れてきており、大きな成果を上げているからです。そして、我々は我々自身がこのリアルな問題をハードウェアに依存しない形で解決するために非常によいポジションに位置していると考えています。すべてのアプリケーションと全てのインフラストラクチャの接合点、すなわちハイパーバイザーに位置しているからです。これが我々をPernixData Architectの創造へと駆り立てました。インフラストラクチャとアプリケーションをデータに裏打ちされた形で設計、運用、最適化するためのインフラストラクチャ解析プラットフォームです。今年Architectをリリースして以降、その反応は非常に大きなものです。
次なる一歩 : 惑星規模でのArchitect
おなじくVFD5で、私はPernixData CloudをArchitectの論理的な進化系としてお話しました。惑星全体のアプリケーションとインフラストラクチャに対しての可視性と解析を皆さんにご提供するものです。我々は自分自身のデータセンタ内で発生している出来事から学ぶことができますし、Architectのような製品はそれを手助けしてくれます。しかし、他のデータセンタで起こっていることから相互に学び合うことはこれまでにできなかったのです。理由は上手く情報を取りまとめ、共有するうまい方法がなかったからです。我々はそこに手を入れます。
我々が現在見ているものをチラ見せ
すでに我々は前に進んでいます。そして十分な量の情報を集めることができています。数万のホストと数千のストレージシステムにも及ぶ情報です。ご参加してくださった全ての方々に感謝します。我々が惑星の(データセンタから集めた)メタデータから学んだことのうちの幾つかは非常に興味深いものです。どんどんそうしたものを共有していこうと思いますし、もしリクエストが有ればTwitterで教えて下さい。我々が出来る限りの範囲でお教えします。
サーバ
人々は野生環境(実際に利用されている環境)に分散しているESXのヴァージョンについて、新しいリリースの度に関心を持っており、自分自身がアーリーアダプターなのか、それともレガードになってしまっているのかで一喜一憂します。これが3000弱の実際に利用されているESXのヴァージョンの統計的な分布です。
ESXi 5.0はほとんど絶滅しつつあり、それ以前のものは見る影もありません。ESXi 5.5が生態系の主力であり、ESXi 6.0が勢力拡大のステージにあります。
この統計的なサンプルがお見せできるのも、我々は我々の集めた非常に大きなデータセットに対してクエリを発行しているからです。そうすることによって複雑さを減らし、正確さを上げることが出来るのです。ですから、我々はどんな質問にお答えする際にも、統計的なサンプルを用いる戦略を選びます。求められる正確さと適切なレベルでの複雑さをもってお答えするのです。今回の場合、3000ホスト程度のサンプルがあれば十分であると事前の解析でわかっていました。まぁ、本題に戻りましょう。
サーバについてのトピックを続けましょう。6500弱のホストからCPUのトレンドを統計サンプルとして取り出しました。以下がそのグラフです :
仮想化の世界が2ソケットのマシンに席巻されていることに驚く人はあまりいないかもしれません。そう、私はそれでは大して驚かない、4ソケットのサーバの見積もりをとって、がっかりしたことが数年前にあったからです。私が顎を落とすほどびっくりしたのは8ソケットや10ソケットのサーバを利用しているという人がいたからなんです!
サーバあたりのコア数を見るともっと面白いことがわかります :
Ivy Bridge以前のテクノロジーもコア数のカウントから多くいることがわかります。これは別に驚くことではなりません。ハードウェアには更新のサイクルという期間がありますから。私はこのデータを枚クオーター新しいデータと比較し、2016年のサーバの更新のペースを見てみたいと思います。
それはさておき、分布の低い方(サーバあたり2,4,6コア)はホームラボだと想像しています。1ソケットサーバの割合はこの3つを合計したものと非常に近くなっています。もう一つ、2コアの棒グラフは惑星内にこっそりと潜んでいる仮想マシンとしてのESXサーバを掴まているかもしれないと思っています。
さて、メモリへと進んでいきましょう。64GBよりも大きく384GBよりも小さなサーバが流行です。x軸のメモリ分布は幅があることに注意してください。32GB以上、64GBまでという具合です。そして幸運な1TBから3TBをもメモリを積んでいる幸せな魂も見つけることができました。やぁ、データベースさん!
ブロックストレージ
ブロックストレージへと歩みを進めましょう。仮想化システムにおけるストレージについては素晴らしいまでの多様性を見ることができます。これと同時にPernixDataの製品がこれらのすべての環境に驚くべきスピードで導入されたことを誇りに思います。幾つかのベンダーではFCとiSCSIプロトコルを使うときそれぞれで別の製品ファミリであるというレポートを返してきますので、2つ別々にレポートされてしまっています。ご期待のとおり、EMCのVNXが仮想化の世界では丘の上の王さまです。ではその次は?
上記の分布は配備されたストレージの数を数えたものです。しかし、200TBのストレージでをベンダー1から、10TBのストレージをベンダー2からということもありますので、不公平かもしれません。データは適切に集計されていなくても我々の前でいたずらをしようとします。これはまた、マトリックスを思い出させてくれます。
エージェント ブラウン : おそらくは、間違った質問をしているのかもしれない。
我々はどれだけのデータがベンダーによって管理されているのか、というクエリにそれを修正しました。以下がその結果です :
この結果はもともとの結果と異なって大きな別の結果を表しています。例えば、Tegileは新しいランキングで大きく順位を落としています。あるJBODベースの共有ストレージソリューションが新たにランキングに入ってきたりなどなど、です。
今後はもっと
同僚のPrashant Saxena、Jason Lloyd、そしてChethan Kumarが解析の手伝いをしてくれました。この先、我々のデータセットに基づいた結果を公開していきます。そして、その際にはアプリケーションや仮想化レイヤー自体の次元での分析も行いたいと思います。以前にお伝えしたとおり、遠慮無く惑星のデータセンタについての興味深い質問を投げかけてください。
@SatyamVaghani
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
