EMC ScaleIOのハイパーコンバージド環境にI/Oパフォーマンスの飛躍を

本記事はPernixData社のホワイトペーパーの翻訳版です。原文は｢Attaining Breakthrough I/O Performance In EMC ScaleIO Hyperconverged Environments｣にて参照可能です。

イントロダクション

ScaleIO

EMC ScaleIO はソフトウェアをベースとしたソリューションであり、vSphereホストに搭載されたディスクをプールし、ホスト間のインターコネクトを実現することで、ハイパーコンバージドインフラストラクチャ(HCI)を構成します。ホスト上の仮想マシン(VM)はScaleIOによってブロックストレージとして構成されたデバイスをVMFSデータストアやRDMデバイスとして利用することが可能です。HCIはコンピューティングレイヤ(仮想マシン)とストレージレイヤの間の距離を縮め、I/Oパスをホスト内だけに留めることができます。これによって、単一の物理レイヤであるサーバはコンピューティングプラットフォーム(VMware ESX ハイパーバイザーで管理)とストレージプラットフォーム(EMC ScaleIO)の両方として動作させることが可能となり、これはハイパコンバージドプラットフォームとして知られています。

ScaleIO ソフトウェアはサーバとクライアントコンポーネントから構成されています(下図)。サーバコンポーネントはLinuxベースの仮想マシンにインストールされており、ESXホスト上で動作します。サーバコンポーネントはScale IO Data Server(SDS)と呼ばれています。クライアントコンポーネントはScale IO Data Client(SDC)と呼ばれており、SDS仮想マシンが動作しているのと同じホストのESX kernel上の軽量なドライバーとしてインストールされます。ScaleIOのHCI環境では、コンピューティングに加えて、ストレージ機能を仮想マシンに提供するため、SDSとSDCの両方が全ての適切なホストにインストールされている必要があります。Scale IOについての更に詳しい情報についてはEMC VSPEX Private Cloudをご参照ください。

アプリケーションからのI/OリクエストはSDCからSDSに対して構成されている論理アダプタ(logical adapter)を経由して、上の図に記載の物理ストレージへ送られます。このパスはデータの格納箇所によっては長くなってしまうことがあり(EMC VSPEX Private Cloudの第3章 "Storage Layer"をご参照ください)、高いI/Oアクティビティが行われる場合には不必要な遅延がボトルネックとして露呈します。ScaleIO仮想マシンのCPU負荷もI/Oレイテンシが予期しない動きをすることへ影響を与える要素の一つです。Scale IOはSAN環境におけるパスと比較するとアプリケーションからのリクエストから物理ストレージまでを短くすることができていますが、そのパスはまだ長く、混雑しがちです。結果としてこのパスを通るI/Oのレイテンシはまた高いと言わざるを得ません。

FVP

PernixData FVP® ソフトウェアは高速なRAMやSSDのようなホストリソースを利用し、低遅延の耐障害性のあるデータ高速化レイヤをvSphere ホストのクラスタ全体に提供することが可能です。このレイヤは頻繁にアクセスされるデータの格納場所やアプリケーションによって書き込まれる新しいデータの高速なI/Oを完了させる場所として利用することができます。

ESXカーネル内で動作し、他の様々なソフトウェアソリューションよりもコンピューティングレイヤに非常に近いレイヤに位置する(上の図を参照)ことから、FVPはデータのReadを劇的に改善することが可能です。アプリケーションは様々なタイミングでデータにアクセスします。FVPはこうしたリクエストに対して高速化レイヤー内のデータで応答します。高速化レイヤー内にデータがない場合にだけ、FVPはプライマリストレージへとそのリクエストを転送します。ですが、そのプライマリストレージからリクエストに応じて読み込まれたデータのコピーはデータ高速化レイヤに書き込まれ、将来のリクエストに備えることになります。

FVPはデータが高速化レイヤに書き込まれた直後にACK(完了通知)を返すことによって、Writeも高速化します。バックグラウンドではFVPがプライマリストレージへと送信されることを保証しますが、プライマリストレージへ書き込むレイテンシは仮想マシンからは見えなくなります。

ScaleIOをFVPと一緒に利用することで、I/Oのパフォーマンスはそのキャパシティから分離された最高のパフォーマンスを誇るHCI環境となります。この分離はIT管理者がそれぞれの要件に対して独立して管理、そして成長できるということを保証します。FVPはReadデータを削減し、Writeのレイテンシを劇的に低減するだけでなく、ScaleIOストレージ構成や複数のストレージの混在にかかわらず、一貫した均一のレイテンシを提供するのです。本ホワイトペーパーは以下では、ScaleIOとFVPを統合したインフラストラクチャにおいて実施した検証における定量的な効果について述べることにします。

検証の構成

本ホワイトペーパーにおける検証では4ノード構成のScaleIOベースのハイパーコンバージドインフラストラクチャを利用しました。検証の構成は以下の図の通りです。

それぞれのノード上にWindows オペレーティングシステムが動作する仮想マシンを動作させました。4つ全ての仮想マシンにIOMeterをインストールしてあります。IOMeterはそれぞれのカオスマシンの仮想ディスクに対して事前に設定されたI/O負荷を生成して、負荷を与えるように構成されています。

ベースラインテストの後、FVPをそれぞれのScaleIOノードにインストールしました。FVPとホストメモリを利用して、すべての4つのノードをまたがった高速化レイヤを作成しています。IOMeterを動作させているテスト仮想マシンを順次FVPクラスタへと追加します。｢Write-Back高速化｣として知られるポリシーを用いて、仮想マシンのReadとWriteの双方を高速化します。IOMeterを高速化した仮想マシン内で動作させ、繰り返し、それぞれのスループットの総計とレイテンシの平均を記録しました。

検証

本ホワイトペーパーの検証で利用したI/Oワークロードのプロファイルは以下の図の通りです。ワークロードはReadとWriteのバーストを定期的な間隔で生成するように構成してありますが、同時には発生しないようにしてあります。バーストしていない期間におけるReadとWriteの操作はピーク時におけるものよりもかなり低く設定してあります。このIOmeterのワークロードはIOPSが定期的にスパイクするような一般的なワークロードのプロファイルを模したものであり、ReadとWriteのバーストは予期せずに発生します。

検証はReadとWriteのピーク性能を図ることとその際のそれぞれのテストケースにおけるレイテンシを図ることを主目的とします。それぞれの仮想マシンのIOMeterはI/O負荷を同時に発生させるように構成してあります。それぞれの仮想マシンのピーク性能は合計されて全クラスタに対して発生するため、全てのノードのレイテンシの平均値はクラスタレベルでの平均値を表すことになります。

検証結果

IOMeterはReadとWriteの両方のリクエストを同時に生成するため、この｢検証結果｣のセクションではそれぞれの操作を個別に見ていくことで理解しやすいようにしています。

ReadとWriteに対するFVPの影響

ScaleIOベースのHCI環境においてのFVPのReadとWrite操作に対しての影響を理解しやすように、単一の仮想マシン内でIOMeterを動作させるという検証を実施します。

Read

ベースラインとFVPを利用した場合のReadのパフォーマンスを以下の図に示します。図の上のグラフはピーク時のベースラインとFVPを利用した場合とそれぞれのReadの平均レイテンシを比較しています。

IOMeterの仮想マシンがFVPによって高速化された際にはReadのレイテンシは対応するベースラインでの結果に対して86%低減されています。これによってピーク時のIOPSはFVPによって8倍分増加しています。

Write

ベースラインとFVPを利用した場合のWriteのパフォーマンスは以下の図に表されています。図の上のグラフはピーク時のベースラインとFVPを利用した場合とそれぞれのWriteの平均レイテンシを比較しています。

Writeがピークに達した際のWriteのレイテンシはWriteが高速化されている場合には55%低減されており、このレイテンシの低減によってピーク時のWriteのIOPSは1.2倍分増加しています。

FVPによるパフォーマンスの拡張

ScaleIOのハイパーコンバージドインフラストラクチャはノードを追加することでリニアにI/Oパフォーマンスを拡張していくことが可能です。これは一極集中のアーキテクチャではないためです。巨大なScaleIOインフラストラクチャは強力な並列ストレージシステムとなります。

前出のセクションで、FVPが単一のScaleIOノードのI/Oパフォーマンスを劇的にブーストさせることが出来ることを示しました。ScaleIOのアーキテクチャを考慮すると、FVPをそれぞれのScaleIOノードにインストールして高速化レイヤを拡張させることで、ScaleIOインフラストラクチャ全域にわたってパフォーマンスをブーストさせることが可能となります。4ノードのScaleIOインフラストラクチャと4つのIOMeter仮想マシン(各ノードに1つづつ)において実施した検証によってこれを定量的に示すことができます。

2つの棒グラフが示すとおり、ReadのIOPSとWriteのIOPSの両方がFVPの有無に関係なくScaleIOノードを追加するごとにリニアに拡張されています。さらに、それぞれのノード上の仮想マシンをScaleIOノード上に構成されたFVPクラスタに追加することでFVPによって線形にパフォーマンスはブーストされながら、それに対応するレイテンシはほぼ一定に低く保たれています。

ReadとWriteの双方は仮想マシンがFVPで高速化されている場合には同じレイヤから供給されるということを付け加えておきます。IOMeterでのレイテンシはReadとWriteで同じになっています。見てわかるほどのReadとWriteのレイテンシの低減は殆どのアプリケーションにとって劇的な効果をもたらします。アプリケーションはRead-変更-Writeという操作を大量に実行しているからです。ReadまたはWriteもしくはその両方のレイテンシが高い場合にはアプリケーション全体がスローダウンし、エンドユーザーはより多くの時間を待たなくてはならなくなります。

サマリ

ScaleIOはソフトウェアベースのソリューションでvSphereホストのローカルストレージとホスト間のインターコネクトを活用して、既存のvSphereベースのクラスタをハイパーコンバージドインフラストラクチャへと変革することが可能です。ScaleIOベースのハイパーコンバージドインフラストラクチャはインフラストラクチャ内のノードを増やすことでI/Oパフォーマンスをリニアに拡張することが可能です。PernixData FVPはメモリやSSDのような高速なサーバリソースを活用し、ScaleIOノード個々のI/O性能を劇的に向上させることが可能です。

本ホワイトペーパーの検証では超並列で拡張可能なサーバベースのストレージインフラストラクチャをScaleIOで構成した上で、FVPによってこのインフラストラクチャのパフォーマンスとキャパシティを分離させることで、非常に高いIOPSと低いレイテンシを実現できることを示唆しました。高速化したHCIはReadとWrite操作双方に一貫した均一のレイテンシを提供しながら、パフォーマンスをリニアに、そしてその下のストレージハードウェアとは独立して改善拡張することが可能です。