仮想化環境のストレージ選び

第1回では、これまで構築してきた仮想化ホスティング基盤の技術要素を振り返りました。今回は、その中でも最も苦労したポイントであるストレージについて考察します。

ストレージ利用の変遷

仮想化環境においては、どのような接続方式の、どのようなストレージを選べばよいのでしょうか。共通の悩みだと思います。以下では、筆者が所属するITコアのストレージ利用変遷を示し、ストレージ選択のポイントを解説します。

GrowServer（GS）の第1世代は、仮想化に着手した初のサービスだったため、単体サーバーのローカル・ストレージで事業を開始しました。インタフェースはUltraSCSIだったと思います。

GSの第2世代と第3世代は、2GbのFibre Channel（FC）を使った共有ストレージを導入し、VMwareのライブ・マイグレーション機能であるVMotionを利用できるようにしました。

第3世代の時には、増設時にいったんはiSCSIを採用したものの、期待通りの性能が出なかったため、FCに戻したという経緯もあります。さらに、途中からはNASも併用するようになりました。

第4世代（ここからはGS9と、名前に西暦を付けるようになりました）では、iSCSI（GbE）を使っています。

GS10では、物理的にはInfiniBandを使用し、その中に10GbEのiSCSIや4GbのFCの仮想化コネクションを構成しました。また、10GbEのNASも併用しています。

このように、さまざまな接続方式を採用してきました。それぞれ一長一短があり、なかなか1つの方法に集約できていないのが現状です。

iSCSIについて

GS9の時には、「これからはiSCSIだ」と考えて、思い切ってFCからiSCSIに切り替えました。しかし、実際には以下のような課題があったため、本命とはなりませんでした。

• iSCSIドライバの出来が悪い（OS側、ストレージ側）
  - 高負荷で障害になったり、頻ぱんなバージョンアップがあったりする
• 10GbEのスイッチやケーブルが高価
  - 性能や安定性を考えるとFCの方が割安になることもある
• アーキテクチャの問題
  - TCP/IPの上位で動作するため性能上のロスが大きい
• ベンダーのマーケット戦略
  - FCとのすみ分けなどによりストレージの高性能化が進まない

このような問題が原因となり、iSCSIが唯一の本流となることはありませんでした。ただし、iSCSIは手軽であるため（既存ネットワーク機器を流用できるため）、小規模なシステム構成においては、かなり実用的に使えるでしょう。

FCoEについて

FCoE（Fibre Channel over Ethernet）は、まだITコアでは使用していません。FCoEとiSCSIとの関係を、以下に整理しておきます。

• iSCSIと同様にイーサネット・スイッチを使用するので、ストレージ接続とネットワーク接続の機器を統合できる。
• TCP/IP層を使わないので、FCと同じレベルの性能・品質が出せる（DCBによるロスレス）。
• 米Cisco Systemsと米Brocade Communications Systemsが強力に推進している。

上記の通り、FCoEは技術的には優れた規格です。しかし、ベンダーが少ないことと、コスト・パフォーマンスが既存の技術に比べて大して良くないことから、広い普及は難しいのではないか、と思っています。なお、iSCSIは現状のイーサネット規格の上で利用できますが、FCoEは、イーサネットを機能拡張したDCB規格のイーサネットが前提となります。

FCについて

FCは、一時期は高コストのために廃れそうになった規格ですが、以下の理由から、まだまだ主流で使われています。

• 新規開発コストがなくなり、価格が安くなってきた。
• 技術的にシンプルであり、安定してぎりぎりの高性能を出せる。
• 高性能ストレージが、事実上FCしかサポートしていない（iSCSIインターフェースは、あっても性能が出ない）。

FCの性能は、現在は8Gbになっています。この性能は、コネクションとしてはかなり高性能であり、これを使い切ることは、なかなか難しい状況です（サーバーやストレージ側がボトルネックになる）。

SASについて

最近はSAS（6Gb）で接続して使うストレージも出始めています。ただし、SASインターフェースは、安くて帯域幅が広いというメリットがある一方、複数のサーバーから共有するアーキテクチャには向いていません。1つのサーバーに増設するストレージとしては、良い選択になると思います。

NASについて

NAS（NFS/CIFS）は遅い、というイメージがありますが、それは古き良き時代の話です。現在のNASは、決して遅くありません。

同じストレージを使ってiSCSIとNFSを比較した場合、NFSの方が速いということも珍しくありません。第一感としてはブロック・デバイスのiSCSIの方が速いように思われますが、長い歴史の中でチューニングされてきたNFSの方が、隅々まで安定して性能が出るということでしょう。また、多くのサーバーからの「小パケット、多量トランザクション」のアクセスに強いという点も、クラウドでは大きな利点となります。

ITコアでは、NFSを、今後のコア技術の1つとして位置付けています。特に、ゲストOSがNASストレージをNFSで直接マウントして利用しています。

GSにおける構成例

第3世代では、すべてをFCで接続しました。

第4世代では、ミラー・パスに限ってFC接続としました。サーバーとの接続にはiSCSIを使いました。ストレージ内部に搭載するディスクは、ローカルのSAS接続としています。

次に、ストレージの性能について解説します。

性能指標

IA（インテル・アーキテクチャ）の世界では、CPUのロード・アベレージによって性能を管理することが一般的でした。これは、I/Oも含めてサーバーのCPUに依存する処理が多く、1つの指標で全体を把握しても大きな間違いはない、という前提に立っています。

しかし、現在は、いろいろな処理がオフロード（サーバーのCPUから処理負荷を切り離すこと）するようになっているため、サーバー単体の負荷だけではシステム全体の負荷を把握することが出来なくなっています。

汎用機（メインフレーム）も含めたエンタープライズ・ストレージの性能管理指標には、以下のようなものがあります。

• 応答時間（レスポンス・タイム）
• スループット（トランザクション量、データ転送量）

仮想化環境において重要な指標は、レスポンス・タイムとトランザクション・スループットです。複数の仮想サーバーからの多数のI/Oに対して、安定して速い応答を実現することが重要です。一方、大量のデータ転送を行うようなアプリケーションは、仮想化環境には向かないといえます。

したがって、データ転送量の性能指標（MB/s）については、それほど気にする必要はないでしょう。目標トランザクション・スループット（IOPS）を実現できていれば、結果的にデータ転送量も問題ないと考えてよいと思います。

IOPS

IOPSは「入出力（Input/Output）回数 Per Second」の略であり、1秒あたりにいくつのトランザクション（I/Oパケット）を処理できるかを示しています。

仮想化環境のストレージ管理は、IOPSの管理に尽きるといっていいでしょう。高いIOPS処理能力を実現していれば、おのずと応答時間も速くなります。IOPSを高めても速くならないI/O処理は、仮想化環境はやめて単独のシステム構成を採用すべきです。

しかし、各ストレージ・ベンダーは、IOPSを公表していません。このため、事前に検証テストをさせてもらい、ある程度は推測（期待）で導入することとなります。ホワイト・ペーパーなどで「高いIOPSを実現した」とアピールしている場合もありますが、以下のような落とし穴があるため、注意してください。

• IOPSのブロック・サイズが小さくないか。
• ディスクを最大構成としていないか。

ベンダーが公表しているベンチマーク・テストというのは、非現実的な構成のケースが多いので、あまり真剣に受け取らないほうがよいでしょう。実際の運用現場で出すことができる性能値に関しては、よく注意して検証する必要があります。

LinuxのWebアプリケーションにおけるI/Oブロック・サイズは、通常は4KB程度です。このため、4KB程度のトランザクション性能を重視してください。高価格で高性能なエンタープライズ・ストレージは、もっと大きなブロック・サイズ向けにチューニングされていることが多いので、注意が必要です（特にメインフレームやUNIX系の製品）。

ストレージ・ラインナップへの反映

GS10-IIでは、仮想サーバーへのIOPS処理能力ごとに、異なるストレージを適用したメニューを用意しました。アプリケーションのI/O要件に合わせて（ストレージ性能が異なる）仮想サーバーを選択できるようにしました。

図2に示したレスポンスの数値は、あくまでも目安であり、この数値を保証するものではありません。また、IOPSの値は、sarコマンドから取得できる512B単位の値を換算して求めた数値であるため、実IOPSとは異なる点に注意してください。

性能管理について

ストレージ性能がいくら高くても、そこにアクセスするI/O量（仮想サーバー数）が多ければ、パンクしてしまいます。このため、GrowServerでは、以下の2つの指標で運用管理を行っています。

応答時間

各仮想サーバーからの応答時間が50ms（ミリ秒）以内になるように監視する。常時50msを越えるようなサーバーについては、アプリケーションのチューニングやリソースの追加、高性能ストレージの利用などを提案する。

ボリュームあたりのIOPS

仮想化環境では、1つのボリュームを複数の仮想サーバーで利用する。同じボリュームを使っている仮想サーバーのトランザクション量を合計した数値をもとに、ストレージ・ボリュームの性能を管理する。この値が性能限界を超える場合は、仮想サーバーの再配置を行う。

今回（第2回）の最後に、今後のクラウドにおけるストレージについて展望します。

エンタープライズ・ストレージの限界

これまで、ハイエンド級のストレージは、エンタープライズ・システム（主に大企業の、全社的な企業情報システム）向けに発展してきました。高価なストレージは性能も信頼性も高いですが、クラウド環境においては、いくつかカバーできないところがあります。

余裕を持った設計ありき

エンタープライズ・システムにおいては、厳密に予測（要求）されたシステム性能要件に対して、完全な解決策を提供するのが普通です。裏を返すと、前提となっている処理量を超えた場合は性能を保証しないということです。

ところが、クラウドでは、処理量はコントロールできません。クラウド環境は、常にレッド・ゾーンぎりぎりで走っている車のようなものです。時には、レッド・ゾーンを振り切っても壊れずに走り続けられることが重要です。パンクしても走り続けられるタイヤのようなタフさが必要です。

計画停止

エンタープライズ・システムは、計画停止によるメンテナンスを前提としています。例えば、BIOSのアップデートやディスク・エンクロージャの追加など、停止が必要となるメンテナンス作業があります。クラウドでは、ワールド・ワイドで多様なシステムが稼働するため、計画停止できるような余裕はありません。

設定変更リスク

無停止で設定を変更できる場合であっても、大幅な性能低下が起こることが少なくありません。これは、ベンダーもほとんど認識していない場合が多く、クラウドの本番環境でいきなり遭遇する危険性があります（エンタープライズ・システムでは、深夜などのアクセスが少ない時間にメンテナンスを行うため、問題にならない）。

また、共有ストレージは仮想化環境の要であるため、性能障害が発生した時の影響は計り知れません。

コスト競争力

言うまでもないことですが、今後のクラウド・システムにおいては、これまでのハイエンド・ストレージは高価過ぎます。また、これまでのハイエンド・ストレージはベンダー技術者のエンジニアリング・コストも非常に高価です。クラウドではビジネス的に成り立たないでしょう。

クラウド向けに設計されたストレージ

3PARに代表されるように、最近はクラウドに最適化されたストレージが開発されています。まだ発展途上ですが、いくつか実用的なストレージを紹介します。

• クラウド・ストレージの特徴
  • IOPS処理能力が高い。
  • 設定変更時（例えばボリューム作成時など）の性能低下がほとんどない。
  • シン・プロビジョニング機能により、ディスク実容量の節約とプロビジョニング時間の短縮（これが意外に重要）を図れる。
  • 無停止のメンテナンス
  • ディスク単体性能に依存しない、データ分散機能

    図3: データを複数ディスクに分散配置する

• 代表的な製品
  • 3PAR（米Hewlett-Packardが買収）
    - 今お薦めなクラウド・ストレージ。iSCSIもあるがFC接続が良い
  • EqualLogic（米DELLが買収）
    - iSCSIテクノロジをじゅうぶんに生かしたストレージ
  • XIV（米IBMが買収）
    - 元EMCのコア技術者による新アーキテクチャ採用ストレージ

SSDの脅威

GS10-IIにおいて「superストレージ」と位置付けている半導体ストレージは、今後のキラー・テクノロジです。半導体ストレージと表現しているのは、いわゆる一般的に売られているSSDの形態に限らないからです。現時点では、大きく3つの種類があります。

DRAMストレージ

いわゆるDRAMメモリーをストレージとして使用する。最も高速だが、コストが高いうえに電源断リスクがある。

PCI直結NANDフラッシュ

米Fusion-ioが先行。非常に高速で高信頼性だが、価格が結構高い。そこまで高性能が必要なアプリケーションは少ない。PCI Expressバス直結なので、RAID（ミラー）ができない。歴史が浅いため、本当に高信頼なのかを実証できていない。

エンタープライズ用SSD

STEC MACH8、INTEL X25-Eなど、SATAインターフェースのSLC SSD。一般的にいわれるSSDのこと。SSDの性能はピンキリ。

SATA用のRAIDコントローラでRAIDを組むことができるが、古いRAIDコントローラでは動かない場合もある。単体では米Fusion-io（PCIe直結）よりもかなり遅い（それでも、ハード・ディスクよりは高速）。ストライピング構成をとれば速くなるが、SATAインタフェースやRAIDコントローラの性能ネックに注意。

SLC（Single Level Cell）とMLC（Multi Level Cell）があり、通常のサーバー用に使う場合はSLCを利用する（書き込み速度および高信頼性）。SSDには書き込み寿命があるが、通常の利用で実際に寿命がくるのかどうかは、歴史が浅くて分からない。

SSDは日々進化しているので、数年後にはハード・ディスクを置き換えるかもしれない（ハード・ディスクは大容量に限って生き残る、など）。

SSDソリューション

SSDは高価で容量が少ないので、安価で大容量なSATA接続のハード・ディスクと組み合わせるのが今後のトレンドです。3PARでは、ストレージのホット・スポット（アクセスが集中する部分）に限ってSSDに割り当てて、それ以外の領域はSATAのハード・ディスクを使うという最適化機構を備えています。

また、オープンソースでも利用できるZFSファイル・システムでは、L2ARC（Read用の拡張2次キャッシュ）にSSDを使用して、SATAのハード・ディスクと組み合わせられます。ZFSアプライアンスとして、米Oracle（ZFSを開発した米Sun Microsystemsを買収）だけでなく、さまざまなベンダーが発売しています。もちろん自社で構築することも可能です。

上位レベルでのHA

VMwareに代表されるサーバー仮想化ソフト（ハイパーバイザ）では、HA（High Availability）機能を使うために、外部の共有ストレージが前提となります。このことが、ストレージがボトルネックになる原因となっています。

しかし、米Googleに代表されるようなクラウド・アプリケーションは、より上位レベルで冗長化をとっているので、仮想化レイヤーのHA機能に頼る必要がありません。今後一般に開発されるシステムも、クラウド仕様として、より上位レイヤーで冗長化をとる手法がとられていくと思います。そうなると、ストレージの選択肢も、大きく変わります。より低コストで高速なストレージ環境が得られることになります。