1. No category

株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
1
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
本文書は、仮想分散ストレージ環境において、Fusion-io 社 ioScale を利⽤した際のストレージ IO 性能を評価したも
のである。本検証は付録 1 にある検証環境で実施したものである。当該環境における性能評価のための検証であり
ioScale に関する性能を保証するものではない。
目次
①
仮想分散ストレージの仕組み ............................................................................. 3
②
仮想分散ストレージの動作 ............................................................................... 3
③
クラウドサービスに適したストレージとは .................................................................... 4
④
クラウドサービスが仮想分散ストレージに期待するもの ................................................... 6
⑤
検証 ........................................................................................................ 8
⑥
付録 1. 評価を⾏った検証環境....................................................................... 13
.........................................................................................................................
※ 本文書に記載されている、商品・サービス名は、各社の商標または登録商標です。
2
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
① 仮想分散ストレージの仕組み
仮想分散ストレージは、仮想化環境にて一般的な IA サーバーを利⽤して共有ストレージ機能を提供する仕組みである。
SSD 及び HDD を内蔵した仮想化ハイパーバイザー搭載サーバー(以下、仮想化ホスト)同士でクラスタを組むことで、あ
たかも外付けの共有ストレージが存在するかのように利⽤することが出来る。簡単に⾔えば「ファイバチャネルや iSCSI、
NAS 等の共有ストレージ環境を用意しなくても、仮想ホストレベルの HA(High Availability) 及び仮想マシンのライブ
マイグレーション環境が組める機能である。
データミラーリングの為のデータは仮想化ホスト間のネットワーク上を流れる為、必要⼗分なネットワーク帯域が必要となる。
検証環境では 10Gbps Ethernet ネットワーク内にデータミラーリング用・仮想化ホスト管理⽤両⽅のトラフィックを同時に
通す構成とした。
SSD は HDD の前段のキャッシュとして動作し、デフォルトでは Read に 70% Write に 30%の⽐率となっている。IO は
SSD が受け持ち、余裕のある時に HDD へデータを移すという動作を⾏う。
今回は SSD の代わりに、さらなる高速デバイスである Fusion-io 社 ioScale 825GB(以下、ioScale)を使用し検証を
⾏う。ioScale を搭載した仮想化ホストに専用のドライバをインストールする事により、ioScale を SSD と同様に仮想化ホ
ストから認識させる。その為仮想化ホストからは ioScale である事を意識せず、SSD と HDD のペアが搭載されているよう
に⾒える。
② 仮想分散ストレージの動作
以下が冗⻑性を含めた仮想分散ストレージの大まかな動作である(許容される障害数を 1、ストライプ数 0 の場合)。
1) A と B という 2 つの仮想化ホストがあり、A と B はクラスタ構成を組んでいる。
2) ゲスト OS が A の上にいる時に書き込みを⾏うと、A は自身の SSD と B の SSD に同時にデータを書き込む。
3) 両 SSD への書き込みが完了すると、数秒後には HDD に自動的に書き込まれる。
4) A から B へのデータのコピー（ミラーリング）には専⽤のネットワークを利⽤する。
5) SSD だけで書き込みは完了する為、直接 HDD へ書き込むよりはるかに速い時間で完了する。
仮想化ホストが複数存在する場合、データがどの仮想化ホストにまたがって書き込まれるかを指定する事は出来ない。完
全⾃動選択となり、その都度選ばれた仮想化ホストに書き込まれる事となる。
読み込みの際の動作では、容量毎に読み込みに使う仮想化ホストが予め決められている。ここでは仮想化ホスト B が読
み込み用として選出されたとする。
仮想化ホスト B は SSD 上にデータを探しに⾏き、SSD にデータが存在すれば SSD から読み込みを⾏う。
SSD に無かった場合は自身の HDD から読み込みを⾏う。
その為、膨大な READ キャッシュを有する昨今のハイエンドストレージ群と比べると、(SSD 容量にも左右されるが)仮想分
散ストレージ環境でのキャッシュヒット率は低くなると予想される。
また、仮想化ホスト内蔵の HDD から読み込む場合は HDD の本数/構成によりおおよその IOPS が決定する。例えばも
っともシンプルに HDD を 1 本しか搭載していない仮想化ホストでは 100IOPS 程度が限界と考えられる。
3
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
③ クラウドサービスに適したストレージとは
クラウドサービスに求められるストレージ性能とは、第一に IOPS、第二にデータのリバランスであると言える。IOPS というのは
秒間あたり何回⼊出⼒を⾏えるか、を表す数値である。
一昔前であれば、何 MB/sec という転送速度そのものについて論じることもあったが、クラウドサービスにおいてはあまり重要
ではない。
クラウドにはそれを利⽤する多数の顧客が存在し、それぞれが必要な時に必要なだけストレージへの⼊出⼒を⾏っている。
つまり IOPS という一つのバケツに入ったリソースを湯水のごとく消費する、と考えればよい。
そして問題は、多くのお客様が IO を欲しがる時間帯は重なるという事だ。
「クラウド」が何故⾼効率だと⾔われるのか、それはまさに「資源の有効活⽤」であり、あまりサーバーを利⽤しない時間帯に
は他のサーバーへ余剰なリソースを振り分ける事が出来るからである。
だが残念ながら「サービス」としてのクラウドはそこまで効率よくリソースを配分する事は出来ない。
我々がサービスを使う時間というのはほぼ限られている。コンテンツでもゲームでも同じことで、昼休みと夜間に多くのサービス
利⽤が集中する。
⽇中はカフェで夜は居酒屋というような、キッチリ分けた⼆⽑作はまず不可能である。
連休中に⾼速道路が⼤渋滞するのと⼀緒で、では渋滞を避けて平⽇に出かければ良いかと⾔えば、ほとんどの⼈は不可
能であろう。
つまり、クラウドに利⽤するストレージの負荷というのは「常に集中」するものなのである。
ここで弊社クラウドサービスにおける IO の傾向を⾒てみよう。
図 1．クラウドサービスにおける IO 利⽤割合実績
4
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
このグラフはストレージに対して IN と OUT がどの程度⾏われているかの⽐較である。
対象となっている仮想化ホスト数は数百台、データ量は数百 TB 以上となっているので、決して偏ったデータでは無く、クラ
ウドサービスの IO 傾向を判断するのに相応しい材料と⾔える。
興味深いのは、Read が平均 500IOPS、Write が平均 2,800IOPS ほどとなっており、読み込みに対して書き込みが
数倍も多い事だ。
顧客サービスのオープン当初であれば、ゲスト OS 作成や構築などの為に書き込みが多くなるのも解るが、ここで示したグラ
フは 2 年以上運⽤中のものである。
多くのストレージベンダーはストレージの性能比較の際に Read70%/Write30%を掲げているが、この前提はクラウドサー
ビスを対象とした場合、あまり当てはまらないことになる。
新規顧客の初期構築分を考慮しても、Read は 3 割もあれば良いと考える。そこで今回は Read30%/Write70%をベ
ースとしてベンチマークテストを⾏う事にする。
5
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
④ クラウドサービスが仮想分散ストレージに期待するもの
仮想分散ストレージでは書き込まれたデータは、別の仮想化ホスト上の SSD へ同時に書き込み処理が⾏われる。書き込
む数は指定する事が可能で、書き込み先仮想化ホストが増えるほど流れるデータの量も増⼤する。また、その数(ミラー数)
が増える程パフォーマンスにも影響が発生する。
仮想化ホストの障害は仮想分散ストレージの障害に直結する為、冗⻑設計には注意が必要だ。
2 台の仮想化ホストが同時に障害を起こした場合を考え、RAID6 と同じように仮想化ホスト 3 台による 3 面ミラーとする
のが望ましい。と言いたいところだがここで考えなければならない事がある。
図 2. ゲスト OS 上で仮想 HDD をミラーリングする
仮想分散ストレージのデータのミラーリングはゲスト OS に割り当てられた「仮想 HDD」1 台毎に、ミラーの数だけ仮想化ホ
ストが割り当てられる。データが完全にアクセス出来なくなる場合というのは、下記の場合だけである。
・仮想 HDD を構成している仮想化ホスト 2 台が同時障害（障害時間帯が重なっている時）を起こした場合
もちろんそれでも他の仮想化ホストが構成した仮想 HDD に影響は無いし、それらを割り当てられたゲスト OS にも影響は
無い。
そう考えるとパフォーマンスの低下に目をつぶって安易に 3 ⾯ミラーとするのは必ずしも良い選択とは⾔えないのである。
ではクラウドサービスという観点で考えてみよう。
6
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
2 台の仮想化ホストに同時障害が起きた時は「どこかのお客様のいずれかのゲスト OS のいずれかの仮想 HDD のデータ
が消失する」とこととなる。
⾔葉にしてみるとすぐに解るが、「影響範囲」は狭いが「影響を把握」する事がとても難しいのだ。
以上の事から今回の検証では 3 面ミラー構成とした。
何を以てクラウドサービスとして利⽤可能か、判断する基準は非常に難しい。そこで今回は以下をその基準とする。
一般的には、仮想化ホストにとってディスクの遅延の許容範囲は 20ms といわれている。ディスクの遅延とはストレージに対
して多数の⼊出⼒が⾏われ、ストレージの IOPS の限界を超えた時、処理しきれない IO が待ち状態になることである。
20ms の遅延と言った場合、仮想化ホストが⼊出⼒を試みている最中、ストレージから「書き込みを完了した」という。応
答が 20ms 遅れて届いている状態と考えてよい。「書き込みたいデータがあっても少しずつ処理しきれない」状態である。
実際の運用経験から言わせて頂ければ、20ms 程度の遅延はほぼ問題にならない。経験上お客様のサービスに影響が
出始めるのは大体 100ms 位からである。
そこで今回ベンチマーク結果に限っては 100ms 程度の遅延は許容範囲とする。
もちろん運用中 100ms の遅延が継続するのは問題なのだが、ベンチマークソフトは常に IO を掛け続ける為、間欠的な
遅延が起こるようトラフィックを調整するのは難しい。
IOPS は 1 ゲスト OS あたり 50IOPS と試算し、1 仮想化ホストでは 500IOPS を確保できることが望ましい。通常
HDD1 本あたりの MAX IOPS は 40〜100IOPS である為、HDD を 1 本搭載した PC の IOPS もほぼその程度であ
ると考えられ、サーバーであっても HDD1 本あたりの IOPS は変わらない。
もちろん全てのゲスト OS が常に 50IOPS 使い続けるような状況は無いだろうが、実際には全く IO を⾏わないゲスト OS
も居れば、間欠的に 100IO 以上⾏うゲスト OS もあることだろう。
また、昨今の PC やサーバーには SSD が搭載されるものもあるが、それらは 1 本あたり 20,000IOPS を軽く超えてしまう
物もある。こういった特殊用途のサーバーを今回の基準にするのは少々乱暴であり、仮想分散ストレージのターゲットとして
ローエンド〜ミドルレンジの共有ストレージとしての利⽤があげられることからも、IO 偏重な用途に仮想分散ストレージを当
てはめるのは無理がある。
7
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
⑤ 検証
検証用には IBM 製のサーバー System x3550 M4 を 8 台用意し、全てに ioScale と HDD を搭載し、仮想化ハイ
パーバイザーのインストールを⾏った。
これらの仮想化ハイパーバイザー上で 1 つのクラスタを構成し、全ての仮想化ホストで共有する仮想分散ストレージデータ
ストアは 1 つとした。IOPS は合計 4,000IOPS 程確保出来れば良いと考えられる。
ベンチマークテストはゲスト OS 上で IOmeter を使用する。過去の実績から比較的安定しており、明らかにおかしな結果
を出したり、変なクセも無く動作も安定している。IO の多重度とブロックサイズを変えてのテストにも対応しており、多重アク
セスとさまざまなブロックサイズでのアクセスが多いクラウド環境には最適である。
Linux 用のベンチマークツールでは、OS 環境によりおかしな挙動をしたり、途中で強制終了するような不安定なものが⾒
受けられるが、Windows 用 IOmeter に関しては今のところそういった不具合は⾒られない。
多重度とは同時に⾏う IO の数で、多重度 10 であれば一気に 10 ファイルを書き込んでいるのと同じ状態である。数十
程度が性能を図るのに良いとされており、それ以上は多重度を上げてもパフォーマンスは伸びない。今回は多重度 50 とす
る。
ブロックサイズは⽐較的良く使われるサイズ 4k〜1MB とした。1MB 以上の書き込みは利⽤例も少なく、仮想化ハイパー
バイザー上では大きすぎて分割されてしまうことからもテストには使用しない。
検証環境をまとめると以下のようになる。
・仮想化ハイパーバイザーを搭載したサーバーから共有ストレージとして利⽤する
・仮想分散ストレージは仮想化ハイパーバイザーから「データストア」として提供されゲスト OS 領域を格納する
・仮想分散ストレージは、共有ストレージとして HA 機能にも利⽤される
・「クラウドサービス」に使用する共有ストレージである
・遅延は 20ms 程度までが理想、ただし 100ms 程度のスパイクは問題なしとする
（ベンチマークでは常に IO を掛け続ける為、100ms 程度で推移した場合でも実⽤には問題無いと判断する）
・IOPS の目標値は 1 ホストあたり 500IOPS とするが、一般的なクラウドサービスと比較した上で判断する
・冗⻑性は 3 面ミラー構成（ストライプ数：0）
・ベンチマークのアクセスパターンは Read30% Write70%とする
・ベンチマークのブロックサイズは 4k〜1MB とする
8
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
まず、一般的なクラウドサービス（＝国内の一般的なクラウドサービス）と IO 性能を比較した。一般的なクラウドサービス
では、共有ストレージには iSCSI や NAS 等の専用ハードウェア機器（ミドルレンジ〜ハイエンド）が使われていると考えら
れる。
図 2．一般的なクラウドサービスと仮想分散ストレージの比較（IOPS、レスポンス時間）
9
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
●一般的なクラウドサービスと仮想分散ストレージとの比較では、どのブロックサイズにおいてもほぼ仮想分散ストレージのほ
うが IO パフォーマンスは優れている。
特にブロックサイズが 4K〜64K の範囲では数千 IOPS 程出ており、理想とする 4,000IOPS を大きく上回り十分実用
的な速度と⾔える。256K 以上になると全体で 4,000IOPS という目標には届かないものの、それでも一般的なクラウドサ
ービス以上のパフォーマンスは得られている。
逆に問題となるのはレスポンスタイムで、ブロックサイズが 64K までは実⽤に耐える速度でレスポンスを返しているものの
256K を超えると 100ms を超え、512K では 200ms を超えてしまっている。1M では 500ms を超える結果となり、サ
ービスに影響が出始めるレベルの遅延となる。
おそらくデータをミラーする際、複数ホストの ioScale に書き込み、全ての書き込み完了を待って次の IO を⾏うという動作
が原因と考えられる。ホストをまたいだ Ethernet 経由のミラーリングを⾏うことによる⼤きなペナルティと⾔える。
なお、実サービス環境においては、複数台の仮想化ホスト機から同時に IO リクエストが発生する。よって今回の検証によっ
て得られた IOPS 値の N 倍の性能が出るものと考えられる。ホストの数による性能限界（×N 倍）は、今回の検証範囲
外である。
10
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
●ミラーのみの仮想分散ストレージとストライプを⾏った仮想分散ストレージの比較
仮想分散ストレージには冗⻑性の為のミラーリング機能とは別に、パフォーマンス確保の為のストライピングの仕組みが備わ
っている。
ミラーを RAID1 とするとストライプは RAID0 のようなもので、以下は両方を合わせて RAID10 の様に構成した場合の結
果となる。
図 3．仮想分散ストレージストライピングでの比較（IOPS、レスポンス時間）
11
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
今回の構成ではストライピングの対象は ioScale となるのだが、結果は振るわない。ブロックサイズ 32K〜256K の間は少
し上回るものの、ミラーのみの仮想分散ストレージとそこまで結果は変わらない。レスポンスタイムの結果も同様だ。
●結果まとめ
仮想分散ストレージで構成されたデータストアは、一般的なクラウドサービスよりも良好な IO パフォーマンスが得られた。ミラ
ーリングによる Ethernet ボトルネックを合わせて考慮すると、顧客側で完全にコントロールの利くプライベートクラウド環境に
おける選択肢に適していると考えられる。高価な共有ストレージを用意しなくても HA 環境を組むことが出来、比較的価格
がこなれてきた ioScale を利⽤することでより良好な IO パフォーマンスを得られることからも、プライベートクラウド構成の有
⼒な候補となるだろう。
ただし大きめのブロックサイズを IO した場合、遅延の問題が発生し、一般的に利⽤するアプリケーション等を選ぶと考えられ
る。なお、これはベンチマークテスト中にバッファが溢れて遅延を発生させた可能がある。検証時間の関係で今回は原因の
特定にはいたらなかったため、1MB ブロックサイズの数値は参考データレベルに留めたい。
懸念された HDD へアクセスする際のパフォーマンス劣化は⾒られず、仕様どおり SSD（ioScale）上で 1 次 IO は完結
していると考えられる。
●その他
今回は純粋にパフォーマンス⽐較を⾏っており、冗⻑性試験や運⽤設計は考慮していない。また仮想分散ストレージデー
タストアが仮想化 OS のクラスタ単位でしか構成出来ない制限や、ミラーが仮想ディスク単位であることなどは、利⽤に際し
ての注意点である。
株式会社ビットアイル エンジニア 中島秀平
12
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01
株式会社ビットアイル：Fusion-io を利⽤した仮想分散ストレージ性能評価
2014 年 7 月
⑥ 付録 1. 評価を⾏った検証環境
13
Copyright 2014 Bit-isle Inc. All Rights Reserved
ver1.01