ストレージ・パフォーマンスを改善して
ソフトウェア・ボトルネックを追放しよう

Storage Magazine 2020年5月号より
George Crump

現在のストレージ・システムは、持てる力を活かしきれていない。
これを証明するには、ちょっとした計算が必要になる。

オールフラッシュ・アレイの各ドライブの生のパフォーマンス値を足して、そのアレイの公式パフォーマンス値と比較してみると、そこには大きな差があることに気が付くだろう。計算では、そのオールフラッシュ・アレイは数百万IOPSを生成できるはずなのだが、大部分のアレイはせいぜい数十万IOPSしか出ていない。

このパフォーマンスの差がなぜ出るのかを理解するには、ストレージ・システムアーキテクチャーを理解する必要がある。

現在、ほとんどのストレージ・システムは、CPU、メモリ、内部および外部のネットワーク、ストレージ・メディア、ストレージ・ソフトウェアから構成されるエコシステムになっている。ストレージ・ソフトウェアは、データストレージ管理者がメディアに保存されたデータをプロビジョニングし、保護する際に関わるものである。ソフトウェアを除けば、ストレージ・エコシステムの各コンポーネントは高速になりレイテンシも低下している。例えば、今やCPUはより多くのコアを持ち、ストレージ・メディアはハードディスク主体からフラッシュ主体に変わり、ネットワークの帯域はさらに大きくなっている。

ソフトウェア定義のストレージとして分類されるベンダー数の増加によって、ソフトウェアをそれ以外のストレージ・エコシステムから隔離することについての議論が盛り上がっている。主にターンキー・ストレージ製品を供給しているベンダーでさえも、現在はソフトウェア開発者としての顔を持つようになった。ただし、彼らのソフトウェアは、彼らのハードウェアでしか動かない。公正を期して言うならば、彼らの機器には何かしらユニークな機能や構成があるかも知れないが、これらのベンダーがやっているのは、いまだにストレージ環境を管理するためにソフトウェア・プログラムを書いているということだ。

ストレージ・ソフトウェアがもたらす課題は依然として残ったままであり、状況は10年前とほとんど変わっていない。大部分のストレージ・ソフトウェア製品やツールが提供する機能（RAID、スナップショット、レプリケーション）も同様だ。

ソフトウェアのボトルネックを克服し、ストレージのパフォーマンスを改善することは、ストレージ・ベンダーにとって重要な目標である。彼らがこれを達成しないと、ユーザーが高速なメモリ技術を採用しても無意味になってしまう。ベンダーがこの問題を解決するためにどのように取り組んできたのかを詳しく見て行こう。ストレージ・システム内のストレージ・メディアが潜在的に持っているパフォーマンスを、ユーザーが、フルに引き出すのを妨げているのは、ストレージ・ソフトウェアであることが、最近になって明らかになってきたからだ。

問題に対してハードウェアを投入する

ベンダーが最も一般的に行っているのは、問題に対してより多くのCPUやメモリを投入することだ。しかし、より高性能のCPUを投入するということは、問題を解決しないかも知れないハードウェアに、さらにお金を掛けるということだ。

CPUのメーカーは、コア当たりの生のパフォーマンスを改善することによって実行性能を上げるという手法をもはやとっていない。その替わりに、彼らはCPUに搭載されるコアの数を増やしている。しかし、8個以上のコアを持つマルチコア・プロセッサを活用するには、高度なソフトウェア・マルチスレッディングと、ほとんどの場合、プログラムを一（いち）から書き直す必要がある。ストレージ・ベンダーは、特定の機能を個別のコアに割り当てることで、この時間を食う作業を回避しようとしているが、この方法は多少パフォーマンスに貢献するものの、コアを並列に効率よく使うには至っていない。

もう一つのやり方は、CPUとフラッシュ・ストレージの間にキャッシュとしてメモリを追加する方法だ。メモリの追加、これもまた出費の増加である。また、一つのストレージ・システムがどれほどまでメモリを積めるか、という物理的な制限も存在する。さらに、メモリはもともと揮発性であるため、電源またはシステムの障害はデータの損失を招きかねない。揮発性メモリを絡めると、複雑さとコストが増えることになる。

ストレージのソフトウェア・ボトルネックは解決しなければならない問題なのか？

ストレージ・システムから最大限のパフォーマンスを引き出すという課題のために、ベンダーは自社のフォーカスを、管理の簡素化やQoS改善などの要素へとシフトさせた。ここでの基本的スタンスは、現行のシステムは十分に優れているので、パフォーマンスを改善する必要はない、というものだ。

多くのデータセンターでは、50万IOPS以上は必要としていない。実際、ほとんどが10万IOPS以上さえもいらないのだ。問題は、生のパフォーマンスを最大限に活用できなければ、メディアのコストが膨れ上がることだ。技術的に言うと、もし4台か5台のフラッシュ・ドライブで50万以上のIOPSが提供できるのならば、何故企業は24台以上のドライブを買わされなければならないのか、ということだ。

事態を複雑にしているのが、フラッシュ・ドライブの容量の増加だ。１年以内に、16TB以上のフラッシュ・ドライブが普通になるだろう。さらに、これ以上の容量がすぐ後に続いて出てくる。つまり、16TBのフラッシュ・ドライブが24台搭載されたアレイは、384TBのローキャパシティーを提供することになる。これは、ほとんどのデータセンターが必要としている以上の容量だ。それでも、ベンダーは彼らの製品がユーザーに許容しうるパフォーマンスを出すために、という口実でデータセンターにこの容量を買わせようとするだろう。

一方で、分析、AI、機械学習、ディープ・ラーニングのような新たなワークロードが、一般的なストレージ・アレイが提供する以上のパフォーマンスを要求している現実もある。この市場では、100万IOPS以上が必要となることも珍しいことではない。さらに、主流のワークロードも拡張を続け、データベースや仮想環境でさえも、どこかの時点で、パフォーマンスを向上させて得られるメリットを求めるようになるだろう。

ソフトウェア・ボトルネックを解決するには？

ソフトウェア・ボトルネックを解決し、ストレージのパフォーマンスを改善することは、ストレージ・ベンダーが最優先でやらなければならないことだ。でなければ、新規の高速メディアやネットワークの普及率は、微々たるものになってしまうだろう。特に新興のストレージ・ベンダーはこれらの課題を認識しており、課題解決のいくつかの方法が市場に出始めたところだ。

■筺体に入ったストレージ・システムという概念を捨て去る

現在ほとんどのワークロードは、（多くの場合、クラスターとして動作するサーバーの集合体として）VMwareクラスター、Oracle Real Application Cluster、Hadoopクラスターのように、環境の一部として稼働している。これらのクラスターを管理するソフトウェアには、ボリューム管理やデータ保護のような基本的なストレージ管理機能が入っている。ネットワークや先進的ストレージ・ソフトウェアはレイテンシを増やさないため、パフォーマンスは改善する。

しかし、個々のクラスター自身が行う運用と非効率的なストレージ・リソース使用率によって問題が発生する。ストレージ管理は個々のクラスター毎に別々の管理プロセスとなり、ソフトウェアがデータとI/Oロードをクラスターの全域に均等に分散していないために、ストレージ使用率は一般的に低くなる。

データ保護はクラスター内ノード間のデータコピーを必要とするため、容量の消費が大幅に増加する。

■コンポーザブル・クロスクラスター・ストレージを使う

クラスター化されたストレージ・アイランドの問題に対するソリューションとなる可能性を持っているのが、コンポーザブル・ストレージだ。コンポーザブル・ストレージは、ストレージ・システム内のコンポーネントの共有リソースと連携する。クラスターがストレージ・リソースを必要とするとき、コンポーザブル・ソフトウェアはそのクラスターに対して、仮想ストレージ・システムを割り当てる。

例えば、ストレージ管理者がVMwareクラスターに50台の使用可能なフラッシュ・ドライブの内の10台と2個のCPUを割り当て、次に別の20台をHadoopによって稼働する分析ワークロードに割り当てたとする。コンポーザブル・アーキテクチャーの長所は、ドライブが特定のサーバー用として縛られていないところだ。そのため、企業は必要に応じてドライブやサーバーに割り当てたユースケースを変更できる。

コンポーザブル製品はストレージ機能の提供を、未だにクラスター・ソフトウェアに依存している。つまり、ストレージの管理は依然としてそれぞれのクラスター内で実行されるということだ。このことはまた、機能の包括性とストレージのパフォーマンスは、いまだにクラスター・ソフトウェアのストレージ機能がどれくらい出来がよいかに大部分依存している、ということだ。最後に、ほとんどのコンポーザブル製品がNVMe-oFのような先進的ネットワーク・アーキテクチャーを必要としている点を記しておきたい。NVMe-oFは、人気は上がってきているものの、データセンターにおいてはいまだに普及とは程遠い状況にある。

■カスタム・ハードウェアを提供する

ストレージ・システムを無くす方法の代替として、ストレージ専用に設計されたより高性能のCPUを搭載したハードウェアを提供する方法がある。

数社のストレージ・メーカーが、ストレージのタスクをオフロードして、ストレージ・パフォーマンスの高速化に貢献するカスタムのFPGA（Field Programmable Gate Array）とASIC（Application Specific Integrated Circuit）を開発している。一部のネットワーク・ベンダーは、演算処理能力を持ったネットワーク・インターフェースカードを供給している。コアのCPUに依存する代わりに、そのカード上でストレージ・ソフトウェアを稼働してもらおう、という意図があるからだ。

ストレージ・ソフトウェアをFPGAまたはASIC上に置くことが、パフォーマンスを改善するのか、あるいは単に常駐アプリケーションがCPUをフルに使えるようになるだけなのかは、はっきりしていない。ハードウェアを追加して使用するのも、コスト的に顕著な欠点だ。さらに、専用のFPGAやASICに移行するということは、Intelが継続してきたCPUの開発サイクルのメリットを、ベンダーが享受できなくなることを意味する。

■ストレージ・ソフトウェアを一（いち）から書き直す

ほとんどのストレージ・ソフトウェアは、リリースされてから少なくとも10年は経っている。比較的新しいストレージ・システムでも、通常はオープンソースのライブラリを使っている。一から書き直すことによって、ベンダーはストレージ・ソフトウェアがプロビジョニング、参照、ストレージとデータの保護をどのように行うかなどのストレージ・アルゴリズムを再考する可能性も出てくる。最初からやり直すことによって、ベンダーがソフトウェアをよりマルチスレッドに適合したものにする事も可能になる。

しかし、このプロセスは非互換性を意味しない。このストレージ・ソフトウェアは、コネクターを使って従来型のブロック、ファイル、オブジェクトのユースケースをサポートすることができる。

課題は、製品が市場に出るまでにかかる時間だ。既存のソフトウェア・ライブラリを利用すれば、ベンダーは2、3年で新しい製品を提供できる。しかし、それでは既存製品と大きな差別化はできないだろう。「ゼロベース」のやり方で新規製品を開発する場合、最初のバージョンがテスト出来るようになるまで、おそらく5年以上はかかるだろう。既存のストレージ・ベンダーは、現状の製品を売りながら秘密裏にプロジェクトを遂行しなければならないだろう。

このやり方の良いところは、ストレージ・ソフトウェアがボトルネックにならない、という点だ。なぜならば、ソフトウェアが要求する全体のリソースは減少する一方で、システムにインストールされた各ドライブからはフルにパフォーマンスが引き出せるようになるからだ。

ソフトウェア・ボトルネックを克服することによってストレージのパフォーマンスを改善することは、全てのデータセンターおよびベンダーにとっての課題だ。ベンダーがボトルネックを解決できなければ、ネットワーク・ベンダーがより高速のネットワークを構築する事や、ストレージ・ハードウェアベンダーがより高速のメディアを開発する事が無駄になってしまう。

本記事で上げた4つの選択肢：

■ 筺体に入ったストレージ・システムという概念を捨て去る
■ コンポーザブル・クロスクラスター・ストレージを使う
■ カスタム・ハードウェアを提供する
■ ストレージ・ソフトウェアを一から書き直す


これらは、ボトルネック問題への実行可能な解決策を提供してくれる。しかし、各選択肢自身も課題を抱えている。いつものことだが、ITプロフェッショナルは、どの選択肢のトレードオフが最も受け入れやすいかを判断する必要があるだろう。

著者略歴：George Crump は、ストレージと仮想化を専門とするIT アナリスト企業Storage Switzerland の社長である。

 

 

 

Copyright 2000 - 2020, TechTarget. All Rights Reserved, *この翻訳記事の翻訳著作権は JDSF が所有しています。
このページに掲載されている記事・写真・図表などの無断転載を禁じます。