WIDE Technical-Report in 2012

大規模ストレージソフトウェアの評価
wide-tr-cloud-distributed-storagemeasurement-00.pdf

PROJECT

WIDE Project : http://www.wide.ad.jp/

If you have any comments on WIDE documents, please contact toboard@wide.ad.jp

Title:Author(s):Date:

大規模ストレージソフトウェアの評価
島 慶一, 関谷 勇司, 宮本 大輔
2012-2-16

大規模ストレージソフトウェアの評価
島 慶一∗

関谷 勇司†

宮本 大輔†

2012 年 2 月 16 日

概 要

IaaS サービスなどを大規模広域ネットワーク環境で実現するために必要となる、大規模広域分散ストレージとその仮想環境での運用実現性を検証するために、sheepdog と GlusterFS を対象とした性能計測を実施した。実験の結果、sheepdog はディスクアクセス性能が GlusterFS より安定しているが、全体としての性能は低い事や遅延に弱いことなどが確認された。今後より詳細な計測を進め、広域環境に的した分散ストレージの研究に繋げていきたい。

1

評価の目的

IaaS サービスなどを大規模広域ネットワーク環境で実現するために必要となる、大規模広域分散ストレージとその仮想環境での運用実現性を検証する。現在広く利用されている仮想環境
KVM を基礎環境として、その上で分散ストレージシステム sheepdog と、GlusterFS を、最大128 台のノードを用いて運用性を検証し、さらに広域ネットワークのエミュレーションを用いて広域環境での運用性を検証する。

2

機器の仕様

検証には StarBED で提供されている Cisco UCS C200 M2 を用いた。表 1 に UCS の仕様を示す。

部品

CPU
Cores/CPU
MemoryDisk
NIC (0-3)
NIC (4-5)

表 1: 検証に利用した計算機の仕様
仕様

Intel(R) Xeon(R) X5670@2.93GHz × 2
648G
SATA 500GB × 2

Broadcom NetXtreme II BCM5709 1000Base-T
Intel(R) Gigabit Ethernet Network

NIC0 から NIC3 は Brocade MLXe-32 スイッチによって相互に接続されている。また NIC4は管理用セグメントに接続されている。NIC5 は本来未使用であるが、今回 sheepdog 検証のためのストレージエリアネットワークとして利用した (3.1 章参照)。

∗ 株式会社 IIJ イノベーションインスティテュート
† 東京大学1

3

sheepdog 検証

3.1

ネットワークトポロジ

図 1 に検証に用いたトポロジを示す。

㼃㻵㻰㻱㻌㻿㼠㼛㼞㼍㼓㼑㻌ᐇ㦂㻿㼔㼑㼑㼜㼐㼛㼓㻌㻔㻳㼞㼛㼡㼜㻌㻶㻕㻞㻜㻝㻞㻛㻜㻞㻛㻜㻟㻙㻞㻜㻝㻞㻛㻜㻞㻛㻝㻡㻿㼠㼍㼞㻮㻱㻰㻌㻹㼍㼚㼍㼓㼑㼙㼑㼚㼠㻌㼒㼛㼞㻌㻳㼞㼛㼡㼜㻙㻶㻝㻣㻞㻚㻝㻢㻚㻞㻞㻚㻜㻛㻞㻠㻚㻢㻣㻔㼑㼠㼔㻠㻕㻚㻞㻞㻚㻢㻣
㻔㼑㼠㼔㻡㻕

㻚㻝㻠㻔㼑㼠㼔㻠㻕㻚㻢㻤㻔㼑㼠㼔㻠㻕㻚㻞㻞㻚㻢㻤㻔㼎㼞㻜㻘㼑㼠㼔㻡㻕㼀㼑㼙㼜㼛㼞㼍㼞㼥㻌㻿㼑㼓㼙㼑㼚㼠㻝㻥㻞㻚㻝㻢㻤㻚㻜㻚㻜㻛㻝㻢㼖㻜㻢㻥㼕㻜㻣㻥㻿㼔㼑㼑㼜㼐㼛㼓㻏㻌㻞㻿㼔㼑㼑㼜㼐㼛㼓㻏㻌㻝㻝㻚㻞㻞㻚㻢㻥㻔㼑㼠㼔㻡㻕㻚㻞㻞㻚㻣㻥㻔㼑㼠㼔㻡㻕㻚㻝㻚㻜㻙㻚㻝㻚㻝㻜㻔㼢㼕㼞㼠㼕㼛㻘㼑㼠㼔㻜㻕㼗㼢㼙㻜㻜㻝䡚㼗㼢㼙㻜㻝㻜䠄㻷㼂㻹㻙㻰㼛㼙㻜⎔ቃ䠅㻛㼡㼟㼞㻛㼎㼕㼚㻛㼗㼢㼙㻌㻙㼔㼐㼍㻌㻛㼣㼛㼞㼗㻛㼝㼑㼙㼡㻛㼐㼑㼎㼕㼍㼚㻙㼗㼢㼙㻜㻜㻝㻚㼝㼏㼛㼣㻞㻙㼔㼐㼎㻌㼟㼔㼑㼑㼜㻦㼗㼢㼙㻜㻜㻝㻚㼕㼙㼓 㻙㼎㼛㼛㼠㻌㼏㻌㻙㼙㻌㻝㻜㻞㻠㻙㼚㼑㼠㻌㼚㼕㼏㻘㼙㼛㼐㼑㼘㻩㼢㼕㼞㼠㼕㼛㻘㼙㼍㼏㼍㼐㼐㼞㻩㻡㻠㻦㻡㻞㻦㻜㻜㻦㻜㻜㻦㻜㻜㻦㻜㻝㻘㼢㼘㼍㼚㻩㻜㻙㼚㼑㼠㻌㼠㼍㼜㻘㼢㼘㼍㼚㻩㻜㻘㼕㼒㼚㼍㼙㼑㻩㼗㼢㼙㻙㻜㻜㻝㻘㼟㼏㼞㼕㼜㼠㻩㻛㼡㼟㼞㻛㼘㼛㼏㼍㼘㻛㼎㼕㼚㻛㼝㼑㼙㼡㻙㼕㼒㼡㼜㻙㼎㼞㻜㻌㻙㼘㼛㼏㼍㼘㼠㼕㼙㼑㻌㻙㼚㼛㼓㼞㼍㼜㼔㼕㼏㻌㻒㻰㼛㼙㻌㼁㻌㼛㼚㻌㼖㻜㻢㻤䝝䞊䝗䜴䜵䜰䝖䝷䝤䝹㼖㻜㻣㻢㻌㻦㻌㻮㻵㻻㻿୙ᑂ 㻔㻞㻛㻡㻘㻞㻛㻣㻕඲䝜䞊䝗䠖䝬䝹䝏䜻䝱䝇䝖ၥ㢟㻚㻝㻣㻔㼑㼠㼔㻠㻕䠄䝛䝑䝖䝽䞊䜽⎔ቃ䠅䠄㻿㼔㼑㼑㼜㼐㼛㼓⎔ቃ䠅㻰㻴㻯㻼㻦㻌㻝㻣㻞㻚㻝㻢㻚㻢㻡㻚㻞㻠㻝㻖㻺㼀㻼㻦㻌㻝㻣㻞㻚㻝㻢㻚㻞㻞㻚㻞㻠㻝㻖㻰㻺㻿㻦㻌㻝㻣㻞㻚㻝㻢㻚㻞㻞㻚㻞㻠㻝㻖㻼㼞㼛㼤㼥㻦㻌㼔㼠㼠㼜㻦㻛㻛㻝㻣㻞㻚㻝㻢㻚㻞㻝㻚㻟㻦㻤㻜㻤㻜㻛㻺㻲㻿㻦㻌㻝㻣㻞㻚㻝㻢㻚㻞㻝㻚㻟㻦㻛㼣㼛㼞㼗㻛㼟㼔㼍㼞㼑㻑㻌㻛㼡㼟㼞㻛㼟㼎㼕㼚㻛㼏㼛㼞㼛㼟㼥㼚㼏㻑㻌㻛㼑㼠㼏㻛㼕㼚㼕㼠㻚㼐㻛㼟㼔㼑㼑㼜㼐㼛㼓㻌㼟㼠㼍㼞㼠㻑㻌㼏㼛㼘㼘㼕㼑㻌㼚㼛㼐㼑㻌㼘㼕㼟㼠㻌䛷☜ㄆ㻑㻌㼏㼛㼘㼘㼕㼑㻌㼏㼘㼡㼟㼠㼑㼞㻌㼒㼛㼞㼙㼍㼠㻌㻙㻙㼏㼛㼜㼕㼑㼟㻩㻟㻑㻌㼝㼑㼙㼡㻙㼕㼙㼓㻌㼏㼞㼑㼍㼠㼑㻌㼟㼔㼑㼑㼜㼐㼛㼓㻦㼗㼢㼙㻜㻜㻝㻚㼕㼙㼓㻌㻠㻳㻑㻌㼏㼛㼘㼘㼕㼑㻌㼢㼐㼕㻌㼘㼕㼟㼠㻌䛷☜ㄆ

図 1: sheepdog 検証ネットワークトポロジ
sheepdog の検証には、グループ J と呼ばれる Cisco UCS から構成された物理計算機 11 台を用いた。j067 を制御用として利用し、j068 から j079(BIOS 不良が発生していた j076 を除く)を sheepdog ストレージを構成するクラスタノード群として利用した。また、j068 は KVM ハイパーバイザーとしても動作し、10 台の仮想計算機をホストしている。仮想計算機は j068 が提供する sheepdog ストレージを仮想ローカルディスクとして利用した。制御用、およびクラスタ構成機材では Ubuntu 11.10 (64bit)、仮想計算機では Debian6.0 (32bit) オペレーティングシス
テムを用いた。
本来ならば、NIC0 から NIC3(eth0 から eth3 に対応) を実験用として sheepdog クラスタ間の通信に利用するところであるが、Broadcom NetXtreme II BCM5709 のネットワークアダプタドライバのマルチキャストパケット処理の不具合と思われる現象が発生したため、Intel(R)Gigabit Ethernet で構成されている NIC5(eth5) をストレージネットワーク用インターフェー
スとして利用した。NIC5 の相互接続には D-Link DGS-3450 を用いた。

3.2

ソフトウェア構成

検証には Ubuntu 11.10 の APT パッケージシステムとして提供されているバージョンを用いた。表 2 に関連ソフトウェアの情報を示す。また、付録 A に sheepdog で利用されるクラスタドライバ corosync の設定ファイル例を示す。
sheepdog 用として、Cisco UCS に搭載されている 2 台の 500GB ハードディスクの一方を用いた。sheepdog はストレージクラスタ構成時に冗長化のための複製数を指定できるようになっ2

表 2: sheepdog 検証に利用したソフトウェアバージョン
パッケージ名 APT でのバージョン

sheepdog
corosync

0.2.3-0ubuntu1
1.3.0-3ubuntu1

libcorosync4

1.3.0-3ubuntu1ているため、今回は複製数を 3 として構成している。結果、500GB×11 台を 3 で割ったおよそ1.7TB がストレージの容量となる。

3.3

検証手順

sheepdog の検証には bonnie++を用いた。j068 上で稼働している仮想計算機で bonnie++を動作させ、表 3 に示す場合のディスク性能を計測した。

表 3: sheepdog 検証ケース
ケース 仮想計算機台数 遅延

110なし

21050ms

計測ケースは 2 ケースで、ケース 1 は sheepdog クラスタノード間 (j068 から j079、j076 を除く) の遅延なしで 10 台の仮想計算機による同時ディスクアクセス、ケース 2 は、クラスタノードのネットワークインターフェース出力方向に 50ms の遅延を入れた状態で、同様に 10 台の仮想計算機による同時ディスクアクセスとなっている。

3.4

結果の考察

表 4、5 にケース 1、2 の結果を示す。各仮想計算機の結果の値は、bonnie++を 5 回実行した平均値を使用している。50ms の遅延が入った場合、書き込み性能、特にブロック書き込み性能が著しく低下している (ブロック書き込みは 3.8%まで性能が下がっている) のがわかる。それに対して、読み込み性能は、キャラクタ単位で 79%、ブロック単位では 98%の性能が維持できていることがわかる

表 4: bonne++の結果 (sheepdog、ケース 1 (10VM, 遅延なし))

仮想計算機

kvm1
kvm2
kvm3
kvm4
kvm5
kvm6
kvm7
kvm8
kvm9
kvm10
MINMAXAVERAGESTDEV

put chr(K/sec)
571.6
570.0
584.4
588.0
554.6
565.8
562.6
595.8
585.6
590.4
554.6
595.8
576.8813.79

put blk(K/sec)3175.43174.83153.83159.03153.83164.83134.43155.83157.23173.43134.43175.43160.24
12.547

rewrite blk(K/sec)2809.42823.02802.82818.82820.02826.62807.42816.82807.22814.22802.82826.62814.627.74043

get chr(K/sec)2228.42166.8
1956.22203.02206.22168.81665.42053.82085.02162.2
1665.42228.42089.58
170.70get blk(K/sec)14669.6
13758.8
13875.813912.013854.014225.8
14355.813640.014336.6
14051.2
13640.014669.6
14067.96
321.099

表 5: bonne++の結果 (sheepdog、ケース 2 (10VM, 50ms 遅延))
仮想計算機

kvm1
kvm2
kvm3
kvm4
kvm5kvm6
kvm7
kvm8
kvm9
kvm10
MINMAXAVERAGESTDEV

put chr(K/sec)
175.0
180.8
185.8
169.4
183.8
182.6
185.0
177.6
182.6
169.0
169.0
185.8
179.16
6.185

put blk(K/sec)
333.4
335.2
335.6
334.0
335.0
335.4
333.8
335.4
334.6
332.4
332.4
335.6
334.481.050

rewrite blk(K/sec)
154.0
153.0
150.4
156.0
152.4
150.0
153.4
151.8
154.0
156.2
150.0
156.2
153.122.076

get chr(K/sec)
201.6
201.6
201.6
197.4
296.0
201.0
686.6
205.0
294.6
201.0
197.4686.6
268.64151.9

get blk(K/sec)
384.2
382.8
366.8
388.8
384.8
360.4
389.2
375.8
394.0
403.4
360.4
403.4
383.0212.64

表 6: 遅延が入った場合の性能低下 (遅延/無遅延)
MIN
MAX
AVERAGEput chr
0.433
0.427
0.421

4

GlusterFS 検証

4.1

ネットワークトポロジ

put blk
0.122
0.019
0.038

rewrite blk
0.109
0.022
0.044

get chr
0.827
0.766
0.798

get blk
1.031
1.004
0.983

図 1 に検証に用いたトポロジを示す。
GlusterFS の検証には、グループ I と呼ばれる Cisco UCS から構成された物理計算機 128台を用いた。i003 を制御用として利用し、i004 から i174(連番ではないため、詳細な構成は付録 B を参照) の 128 台を GlusterFS ストレージを構成するクラスタノード群として利用した。
また、i004 から i014(ただし、動作不良を起こしていた i012 を除く) の 10 台は KVM ハイパーバイザーとしても動作し、それぞれが 10 台の仮想計算機をホストしている。仮想計算機はハイパーバイザーが提供する GlusterFS ストレージを仮想ローカルディスクとして利用した。制御用、およびクラスタ構成機材では Ubuntu 11.10 (64bit)、仮想計算機では Debian6.0 (32bit) オペレーティングシステムを用いた。
本来ならば、NIC0 から NIC3(eth0 から eth3 に対応) を実験用として GlusterFS クラスタ間の通信に利用するところであるが、NIC0 から NIC3 の上流に配置してある Brocade MLXe-32で通信障害が発生しており、多数のパケットロス、およびラインカード間の通信不良が観測されたため、マネージメントセグメント NIC4(eth4) をストレージネットワーク用インターフェースとして利用した。NIC4 の相互接続には D-Link DGS-3450 を用いた。

4.2

ソフトウェア構成

検証には Ubuntu 11.10 の APT パッケージシステムとして提供されているバージョンを用いた。表 7 に関連ソフトウェアの情報を示す。
GlusterFS 用として、Cisco UCS に搭載されている 2 台の 500GB ハードディスクの一方を用いた。GlusterFS は、冗長構成を持たない「Distributed」型、冗長構成を持つ「Replica」型を利用することができるため、比較のためにこの 2 種類を構成した。なお、性能向上のための「Stripe」型も提供されているが、検証時点で動作が安定しないなかったため、今回検証対象には入れていない。
Distributed 型では、500GB×127 台でおよそ 58TB、Replica 型は、今回複製数を 3 に指定したため、その 3 分の 1 のおよそ 15TB を利用できる。

4㼃㻵㻰㻱㻌㻿㼠㼛㼞㼍㼓㼑㻌ᐇ㦂㻳㼘㼡㼟㼠㼑㼞㻲㻿㻌㻔㻳㼞㼛㼡㼜㻌㻵㻕㻞㻜㻝㻞㻛㻜㻞㻛㻜㻟㻙㻿㼠㼍㼞㻮㻱㻰㻌㻹㼍㼚㼍㼓㼑㼙㼑㼚㼠㻌㼒㼛㼞㻌㻳㼞㼛㼡㼜㻙㻵㻝㻣㻞㻚㻝㻢㻚㻞㻝㻚㻜㻛㻞㻠㻚㻟㻔㼑㼠㼔㻠㻕㻚㻝㻠㻔㼑㼠㼔㻠㻕㻚㻠㻔㼑㼠㼔㻠㻕㼕㻜㻜㻠㼕㻜㻝㻠㻰㼛㼙㻜㻏㻌㻝㻳㼘㼡㼟㼠㼑㼞㻌㻏㻌㻝㻰㼛㼙㻜㻏㻌㻝㻜㻳㼘㼡㼟㼠㼑㻲㻿㻏㻌㻝㻜㻚㻝㻣㻔㼑㼠㼔㻠㻕㼕㻜㻜㻟ᐇ㦂ไᚚ㻗㻌㻺㻲㻿㻘㻌㻰㻴㻯㻼㻚㻞㻝㻚㻟㻔㼎㼞㻜㻘㼑㼠㼔㻜㻕㻚㻞㻝㻚㻠㻔㼎㼞㻜㻘㼑㼠㼔㻜㻕㻚㻞㻝㻚㻝㻠㻔㼎㼞㻜㻘㼑㼠㼔㻜㻕㻚㻝㻚㻜㻙㻚㻝㻚㻝㻜㻔㼢㼕㼞㼠㼕㼛㻘㼑㼠㼔㻜㻕㻿㼠㼍㼞㻮㻱㻰㻌㻱㼤㼜㼑㼞㼕㼙㼑㼚㼠㻔㼂㻸㻭㻺㻌㻢㻟㻕㻝㻥㻞㻚㻝㻢㻤㻚㻜㻚㻜㻛㻝㻢㻰㼛㼙㻌㼁㻌㼛㼚㻌㼕㻜㻜㻠㻰㼛㼙㻌㼁㻌㼛㼚㻌㼕㻜㻝㻠㼕㻝㻡㻡㻦㻌ᣲື୙ᑂ 㻔㻞㻛㻢㻕㻳㼘㼡㼟㼠㼑㼞㻲㻿㻏㻌㻝㻝㻳㼘㼡㼟㼠㼑㼞㻲㻿㻌㻏㻝㻞㻤㻚㻞㻝㻚㻝㻣㻠㻔㼎㼞㻜㻘㼑㼠㼔㻜㻕䠄㻷㼂㻹㻙㻰㼛㼙㻜⎔ቃ䠅㻛㼡㼟㼞㻛㼎㼕㼚㻛㼗㼢㼙㻌㻙㼔㼐㼍㻌㻛㼣㼛㼞㼗㻛㼝㼑㼙㼡㻛㼐㼑㼎㼕㼍㼚㻙㼗㼢㼙㻜㻜㻝㻚㼝㼏㼛㼣㻞㻙㼔㼐㼎㻌㻛㼓㼘㼡㼟㼠㼑㼞㻜㻝 㻙㼔㼐㼏㻌㻛㼓㼘㼡㼟㼠㼑㼞㻜㻞 㻙㼎㼛㼛㼠㻌㼏㻌㻙㼙㻌㻝㻜㻞㻠㻙㼚㼑㼠㻌㼚㼕㼏㻘㼙㼛㼐㼑㼘㻩㼢㼕㼞㼠㼕㼛㻘㼙㼍㼏㼍㼐㼐㼞㻩㻡㻠㻦㻡㻞㻦㻜㻜㻦㻜㻜㻦㻜㻜㻦㻜㻝㼩㻘㼢㼘㼍㼚㻩㻜㻙㼚㼑㼠㻌㼠㼍㼜㻘㼢㼘㼍㼚㻩㻜㻘㼕㼒㼚㼍㼙㼑㻩㼗㼢㼙㻙㻜㻜㻝㻘㼟㼏㼞㼕㼜㼠㻩㻛㼡㼟㼞㻛㼘㼛㼏㼍㼘㻛㼎㼕㼚㻛㼝㼑㼙㼡㻙㼕㼒㼡㼜㻙㼎㼞㻜㻌㻙㼘㼛㼏㼍㼘㼠㼕㼙㼑㻌㻙㼚㼛㼓㼞㼍㼜㼔㼕㼏㻌㻒䠄䝛䝑䝖䝽䞊䜽⎔ቃ䠅㼕㻜㻝㻞䠖䝤䞊䝖䛧䛺䛔 㻔㻞㻛㻢㻕㼕㻝㻣㻠㻚㻝㻚㻥㻝㻙㻝㻚㻝㻜㻜㻔㼢㼕㼞㼠㼕㼛㻘㼑㼠㼔㻜㻕㼗㼢㼙㻜㻥㻥䡚㼗㼢㼙㻝㻜㻜㼕㻜㻡㻞䠖㟁※㉳ື䛫䛪 㻔㻞㻛㻠㻦஦๓㻕㼕㻜㻝㻣㻚㻞㻝㻚㻝㻣㻔㼎㼞㻜㻘㼑㼠㼔㻜㻕㼗㼢㼙㻜㻜㻝䡚㼗㼢㼙㻜㻝㻜䝝䞊䝗䜴䜵䜰䝖䝷䝤䝹㻚㻝㻣㻠㻔㼑㼠㼔㻠㻕䠄㻳㼘㼡㼟㼠㼑㼞⎔ቃ䠅㻰㻴㻯㻼㻦㻌㻝㻣㻞㻚㻝㻢㻚㻢㻡㻚㻞㻠㻝㻖㻺㼀㻼㻦㻌㻝㻣㻞㻚㻝㻢㻚㻞㻝㻚㻞㻠㻝㻖㻰㻺㻿㻦㻌㻝㻣㻞㻚㻝㻢㻚㻞㻝㻚㻞㻠㻝㻖㻼㼞㼛㼤㼥㻦㻌㼔㼠㼠㼜㻦㻛㻛㻝㻣㻞㻚㻝㻢㻚㻞㻝㻚㻟㻦㻤㻜㻤㻜㻛㻺㻲㻿㻦㻌㻝㻣㻞㻚㻝㻢㻚㻞㻝㻚㻟㻦㻛㼣㼛㼞㼗㻛㼟㼔㼍㼞㼑㼓㼘㼡㼟㼠㼑㼞㼢㼛㼘㼡㼙㼑㻌㼏㼞㼑㼍㼠㼑㻌㼐㼕㼟㼠㼞㼕㼎㼡㼠㼑㼐㻌㼕㻜㻜㻠㻦㻛㼣㼛㼞㼗㻛㼓㼘㼡㼟㼠㼑㼞㼒㼟㻛㼐㼕㼟㼠㼞㼕㼎㼡㼠㼑㼐㼢㼛㼘㼡㼙㼑㻌㼍㼐㼐㻙㼎㼞㼕㼏㼗㻌㼐㼕㼟㼠㼞㼕㼎㼡㼠㼑㼐㻌㼕㻜㻜㻡㻦㻛㼣㼛㼞㼗㻛㼓㼘㼡㼟㼠㼑㼞㼒㼟㻛㼐㼕㼟㼠㼞㼕㼎㼡㼠㼑㼐㻔ྎᩘศ㻕㼢㼛㼘㼡㼙㼑㻌㼟㼠㼍㼞㼠㻌㼐㼕㼟㼠㼞㼕㼎㼡㼠㼑㼐㼙㼛㼡㼚㼠㻌㻙㼠㻌㼓㼘㼡㼟㼠㼑㼞㼒㼟㻌㼕㻜㻜㻠㻦㻛㼐㼕㼟㼠㼞㼕㼎㼡㼠㼑㼐㻌㻛㼓㼘㼡㼟㼠㼑㼞㻜㻝䈜 㻰㼛㼙㻜㻌䜒 㼓㼘㼡㼟㼠㼑㼞㼒㼟㻌䛻ຍධ䛧䛶䛔䜎䛩

図 2: GlusterFS 検証ネットワークトポロジ
表 7: GlusterFS 検証に利用したソフトウェアバージョン
パッケージ名APT でのバージョン

4.3

glusterfs-client
glusterfs-common

3.2.1-1
3.2.1-1

glusterfs-examples
glusterfs-server

3.2.1-1
3.2.1-1

検証手順

GlusterFS の検証には bonnie++を用いた。i004 から i014 上で稼働している仮想計算機でbonnie++を動作させ、表 8 に示す場合のディスク性能を計測した。
計測ケースは 6 ケースで、ケース 1、3、5 は GlusterFS クラスタノード間の遅延なし、ケース 2、4、6 は出力方向に 50ms の遅延が入っている。ケース 1 と 2、3 と 4、5 と 6 はそれぞれ、1 台、10 台、50 台、100 台の仮想計算機からの同時ディスクアクセスによる計測となっている。
このケース 1 から 6 を Distributed 型と Replica 型それぞれで計測した。

4.4

結果の考察

表 9、10 に Distributed 型、ケース 1 と 2 の結果を示す。各仮想計算機の結果の値は、bonnie++を 5 回実行した平均値を使用している。また、表 11、12、13、14 にケース 3 から 6 の結果を示す。データ量が多いため、最小値、最大値、平均値、標準偏差のみを掲載する。
遅延を入れた場合、書き込み性能が落ちている事がわかる。また、遅延を入れた状態で 100台の仮想計算機から同時アクセスした場合、読み込み性能のばらつきが大きくなっている。仮想5表 8: GlusterFS 検証ケース
ケース 仮想計算機台数 遅延123101050なし

455010050msなし

610050ms

50ms
なし

計算機の数が増える事で、同じクラスタノードを利用している仮想計算機からの同時アクセスによる輻輳が原因と思われるが、正確な理由は今後の調査が必要である。

表 9: bonne++の結果 (GlusterFS、Distributed 型、ケース 1 (10VM、遅延なし))
仮想計算機

kvm1
kvm11
kvm21
kvm31
kvm41
kvm51
kvm61
kvm71
kvm81
kvm91
MINMAXAVERAGE
STDEV

put chr(K/sec)
772.4
708.8
753.2
685.0
669.2
776.2
668.0
664.2693.2
761.6
664.2
776.2
715.1845.91

put blk(K/sec)72777.09733.655373.4
9713.89568.252278.2
8629.09712.69750.653111.08629.072777.029064.74
25848.7

rewrite blk(K/sec)62407.4
12365.853991.012361.2
12364.054154.811317.4
12345.612440.852793.2
11317.4
62407.429654.1222680.7

get chr(K/sec)3098.02888.02901.42751.22909.62845.22812.82716.42804.22840.22716.43098.02856.7105.35get blk(K/sec)
699825661311660159619964576281612073685477549896631052643199549896699825633923.746653.5

表 15、16 に Replica 型、ケース 1 と 2 の結果を示す。各仮想計算機の結果の値は、bonnie++を 5 回実行した平均値を使用している。Distributed 型の同ケースと比較すると、複製が必要な分、書き込みの性能が落ちる傾向が見られる。他のケースも、おおむね Distributed 型と同じ傾向がみられる。遅延を入れた場合の 100 台の仮想計算機からの同時アクセスで読み込み性能のばらつきが出ている現象は、Replica 型でも再現していた。

5考察

sheepdog と GlusterFS を比較すると、同じ環境では GlusterFS の方が高い性能を示す。例
えば、表 4 と表 15 において、sheepdog のブロック書き込み性能は最大値でも 3175.4K/sec なのに対して、Replica 型の GlusterFS のブロック書き込み性能は最大値で 26742.2K/sec と 8.4 倍近い差がある。読み込みに関しても同様の傾向があり、sheepdog の 14669.6K/sec と GlusterFSの 633579K/sec と、43 倍もの差がある。
これは、sheepdog はディスクイメージをブロック単位で分割、複製するのに対し、GlusterFSはひとつのディスクイメージが 1 ファイルになっているためと思われる。sheepdog の場合、ひとつの仮想計算機のディスクにアクセスするために、多数の sheepdog クラスタノードとの通信が必要なのに対し、GlusterFS の場合、Distributed 型ではひとつ、Replica 型では複製数と同じ数のクラスタノードにアクセスするだけですむ。
一方、仮想計算機ごとのディスクアクセス性能に関しては、sheepdog の方がゆらぎが少ない。GlusterFS の場合、仮想計算機が稼働しているハイパーバイザーと、対応する仮想ディスクが格納されている GlusterFS のノードの組み合わせによって、高い性能がでる場合と性能がでない場合が明確に分かれる。特にブロック読み書き時の性能のばらつきが大きい。

6

表 10: bonne++の結果 (GlusterFS、Distributed 型、ケース 2 (10VM、50ms 遅延))
仮想計算機

kvm1
kvm11
kvm21
kvm31
kvm41
kvm51
kvm61
kvm71
kvm81
kvm91
MINMAXAVERAGESTDEV

put chr(K/sec)
331.8
296.8
311.0
301.0
289.2
292.8
305.6
288.0
297.4
303.4
288.0
331.8
301.7012.80

put blk(K/sec)1397.21108.21083.21106.6
1093.41053.41096.21103.21098.61058.41053.41397.21119.84
99.307rewrite blk(K/sec)1391.81337.01239.61329.41309.81255.41326.01332.61329.41257.21239.61391.81310.82
46.735get chr(K/sec)2291.62252.02332.82246.62268.82373.22256.62281.42246.62267.22246.62373.22281.68
41.411

get blk(K/sec)567084610029685430617564585167598867702741597652620693650562567084702741623578.943459.3

表 11: bonne++の結果 (GlusterFS、Distributed 型、ケース 3 (50VM、遅延なし))
MINMAXAVERAGE
STDEV

put chr(K/sec)
669.6
781.2
724.0621.83

put blk(K/sec)6547.051083.821224.36
13721.5

rewrite blk(K/sec)6912.447192.020320.90
12542.9

get chr(K/sec)
2604.23013.22783.66
97.762get blk(K/sec)565291
700060646068.834265.2

謝辞
本検証作業にあたり、北陸リサーチセンターの三輪信介所長、宮地利幸博士、および中井浩氏には、実験機材の手配および構成に関して有用な助言をいただき、また作業環境の構築に尽力していただきました。ありがとうございました。

Acorosync 設定ファイル# Please read the openais.conf.5 manual page
totem {
version: 2# How long before declaring a token lost (ms)token: 3000
# How many token retransmits before forming a new configuration
token_retransmits_before_loss_const: 10# How long to wait for join messages in the membership protocol (ms)join: 60

# How long to wait for consensus to be achieved before starting a new round of membership configuraticonsensus: 3600
# Turn off the virtual synchrony filter
vsftype: none7表 12: bonne++の結果 (GlusterFS、Distributed 型、ケース 4 (50VM、50ms 遅延))MIN
MAXAVERAGESTDEV

put chr(K/sec)289.6
382.4
309.9520.12

put blk(K/sec)1001.41505.21144.49
142.69rewrite blk(K/sec)1129.61495.41282.82
88.901

get chr(K/sec)2214.02369.42278.57
35.484get blk(K/sec)528388706130619416.835595.4

表 13: bonne++の結果 (GlusterFS、Distributed 型、ケース 5 (100VM、遅延なし)
MINMAXAVERAGESTDEV

put chr(K/sec)506.6
751.8
682.7742.95

put blk(K/sec)4398.458965.2
15235.99
8812.6

rewrite blk(K/sec)4472.056140.6
14820.16
8124.35

get chr(K/sec)2248.62980.82707.59
115.45get blk(K/sec)
229637700719539161.8113093# Number of messages that may be sent by one processor on receipt of the token
max_messages: 20# Limit generated nodeids to 31-bits (positive signed integers)
clear_node_high_bit: yes# Disable encryption
secauth: off# How many threads to use for encryption/decryption
threads: 0# Optionally assign a fixed node id (integer)# nodeid: 1234
# This specifies the mode of redundant ring, which may be none, active, or passive.
rrp_mode: none
interface {# The following values need to be set based on your environment
ringnumber: 0bindnetaddr: 192.168.22.68
mcastaddr: 226.94.1.1
mcastport: 5405}}
amf {mode: disabled}
service {# Load the Pacemaker Cluster Resource Manager
ver: 0name: pacemaker}
aisexec {user:root8

表 14: bonne++の結果 (GlusterFS、Distributed 型、ケース 6 (100VM、50ms 遅延))MINMAXAVERAGESTDEV

put chr(K/sec)252.8
766.2
320.4054.17

put blk(K/sec)772.4
57513.4
1740.47
5637.1

rewrite blk(K/sec)403.2
60969.4
1218.016037.7get chr(K/sec)
405.2
2910.81113.04
538.55get blk(K/sec)1032.860941164095.28
107610.3

表 15: bonne++の結果 (GlusterFS、Replica 型、ケース 1 (10VM、遅延なし))
仮想計算機 put chr put blk rewrite blk get chr
get blk(K/sec)(K/sec)(K/sec)(K/sec)(K/sec)

kvm1
kvm11

606.2
616.0

5574.05058.85455.46456.62799.82746.4623009572266

kvm21
kvm31

591.0
607.2

4698.25139.05974.26615.62725.62739.4588609558716

kvm41
kvm51
kvm61

729.0
734.0
609.4

26624.4
26742.2
5627.229706.2
29859.87146.23040.82828.22781.4581283557647633579

kvm71
kvm81

601.2
640.2

5347.05531.26684.86990.62803.62716.0567401611544

kvm91

634.6

5244.26670.62883.4585852MINMAX

591.0
734.0

4698.226742.2

5455.429859.82716.03040.8557647633579AVERAGE
STDEV

636.8851.98

9558.629029.711156.09829.252806.46
97.076587990.626579.5

group:

root}
logging {fileline: off
to_stderr: yes
to_logfile: noto_syslog: yessyslog_facility: daemon
debug: offtimestamp: on
logger_subsys {subsys: AMF
debug: off
tags: enter|leave|trace1|trace2|trace3|trace4|trace6}}9表 16: bonne++の結果 (GlusterFS、Replica 型、ケース 2 (10VM、50ms 遅延))仮想計算機 put chr put blk rewrite blk get chr
get blk(K/sec)(K/sec)(K/sec)(K/sec)(K/sec)

kvm1
kvm11
kvm21

301.4
258.8
262.4

1104
797.2
794.6

1087.2990.8
988.2

2279.42178.22212.2

569349585465571915

kvm31
kvm41

261.2
256.2

805.8
805.6

989.2
997.4

2240.02325.8531693587171

kvm51
kvm61
kvm71

252.0
265.6
251.0

805.8
815.0
791.6

1001.4999.2
993.2

2314.62278.62195.8567483541098540323

kvm81
kvm91

250.8
258.4

791.8
808.8

983.4
989.8

2306.02320.0621533543093

MIN

250.8

791.6

983.4

2178.2531693MAXAVERAGE

301.4
261.781104.0832.021087.21001.982325.82265.06

621533565912.3

STDEV

14.79

95.88

30.44

54.76227769.7

B

クラスタノードリスト

B.1

sheepdog クラスタノードリスト

j068, j069, j070, j071, j072, j073, j074, j075, j077, j078, j079

B.2

GlusterFS クラスタノードリスト

i004, i005, i006, i007, i008, i009, i010, i011, i013, i014, i019, i020, i021, i022, i023, i024,i025, i026, i027, i028, i029, i030, i035, i036, i037, i038, i039, i040, i041, i042, i043, i044, i045,i046, i051, i053, i054, i055, i056, i057, i058, i059, i060, i061, i062, i067, i068, i069, i070, i071,i072, i073, i074, i075, i076, i077, i078, i083, i084, i085, i086, i087, i088, i089, i090, i091, i092,i093, i094, i099, i100, i101, i102, i103, i104, i105, i106, i107, i108, i109, i110, i115, i116, i117,i118, i119, i120, i121, i122, i123, i124, i125, i126, i131, i132, i133, i134, i135, i136, i137, i138,i139, i140, i141, i142, i147, i148, i149, i150, i151, i152, i153, i154, i156, i157, i158, i163, i164,i165, i166, i167, i168, i169, i170, i171, i172, i173, i17410