Lenovo System x サーバー上でのHyperStore 動作検証レポート
2015 年 6 月

本資料は、Lenovo System x

サーバーを使い、クラウディアンが開発提供するソフトウェア定義（Software Deﬁned）のスケールアウト型オブジェクトストレージ製品である「CLOUDIAN HyperStore®」の性能及び安定性の動作検証結果をレポートしています。データサイズ毎に測定した性能、長期間運用における安定性、ノード追加時の動作のいずれの検証においても良好な結果を得ています。

1

本検証の目的本 検 証 で は、レノボ・ジャパ ン 株 式 会 社 様 の ご 協 力 を 得 て、Lenovo System x サーバーを使い、クラウディアンが開発提供するソフトウェア定義（Software Deﬁned）のスケールアウト型オ
ブジェクトストレージ製品である「CLOUDIAN HyperStore®（以下、HyperStore）」の性能及び安定性の確認を行いました。

《実施検証項目》
1. Cloudian YCSB を使用した、HyperStore パフォーマンス
測定（データ格納後のリペア性能テスト）
2. Cloudian YCSB を使用した、HyperStore パフォーマンス
測定（PUT/GET 操作のサンプルテスト）
3. Cloudian models3 を使用した、HyperStore に格納され

CLOUDIAN HyperStore は、 パッケ ージソフトウェア製 品と、CLOUDIAN HyperStore Ready プログラムに基づきクラウディ
アンが認定したハードウェアアプライアンス製品があります。本検証においては、System x サーバーを使った動作検証が目的であるため、パッケージソフトウェア製品を使い検証を行いました。
本検証においては、以下の試験を実施しました。

たデータの整合性確認
4. Cloudian YCSB を 1 週間実行し続け、エラーやプロセス・
ダウンが発生しないという安定性確認
5. 2 ノード構成の HyperStore ジオ・クラスターに、CMC 経
由で新規 1 ノードを追加した際の動作確認
上記試験により、HyperStore が System x 上で安定稼働することを検証しています。

2

本検証における CLOUDIAN HyperStore のハードウェア要件

HyperStore はビッグデータやバックアップ／アーカイブ・データ

スク・アクセスをご要望されるお客様向けとして、HyperStore のの格納先として、HyperStore を構成するノードを追加しスケール

データ格納領域を SAS ディスクで構成しパフォーマンス測定を実アウトさせていくことで、柔軟にかつ無停止でディスク容量を拡張施しています。

することが出来るスケールアウト型オブジェクトストレージ製品でなお、弊社が推奨している一般的なハードウェア構成要件（※パッす。通常は主に安価／大容量な SATA ディスクを、HyperStore

ケージソフトウェア製品の場合）を、以下に記載します。

のデータ格納領域として使用します。今回の検証環境は高速なディ表 1 ： 最小ハードウェア構成

OS
OS

Red
Red
Hat
Hat
EnterpriseEnterprise
Linux
Linux
(RHEL)(RHEL)
6.x,
6.x,
64-bit64-bit
CentOSCentOS
6.x,
6.x,
64-bit64-bit

OS
OS

Red
Red
Hat
Hat
EnterpriseEnterprise
Linux
Linux
(RHEL)(RHEL)
6.x,
6.x,
64-bit64-bit
CentOSCentOS
6.x,
6.x,
64-bit64-bit

CPU
CPU

Intel
Intel
互換
互換
1CPU
1CPU
／4
／4
コア
コア

CPU
CPU

Intel
Intel
互換
互換
1CPU
1CPU
／／
8 コア～
8 コア～
1616
コア
コア

メモリ
メモリ

16GB
16GB

メモリ
メモリ

32GB
32GB
～～
64GB
64GB

ディスク
ディスク

RAID
RAID

3

表 2 ： 推奨ハードウェア構成

6×
6×
2TB
2TB
HDD
HDD

※OS
※OS
／メタデータ領域用に／メタデータ領域用に2本
2本※データ領域用に※データ領域用に
4本
4本

[OS
[OS
／メタデータ領域／メタデータ領域] RAID1] RAID1[ データ領域[ データ領域
] ]
JBOD
JBOD
構成
構成

ディスク
ディスク

RAID
RAID

1212
××
4TB
4TB
HDD,
HDD,
2x
2 300GBx 300GB
SSD
SSD

※OS
※OS
／メタデータ領域用に／メタデータ領域用に2 本（SSD）
2 本（SSD）※データ領域用に※データ領域用に
1212
本本

[OS
[OS
／メタデータ領域／メタデータ領域
] SSD
] SSD
をを
RAID1
RAID1
[ データ領域[ データ領域
] ]
JBOD
JBOD
構成
構成

ネットワークネットワーク 2 ×
2×
1GbE
1GbE
ポート
ポート

ネットワークネットワーク 2×1GbE
2×1GbE
ポート
ポート＋＋
2×10GbE
2×10GbE
ポート
ポート

電源
電源

電源
電源

シングル構成シングル構成冗長構成
冗長構成

本検証ハードウェアシステム情報

Lenovo System x サーバー上での HyperStore の動作検証を実の動作検証は、レノボ・ジャパン株式会社内検証センターにて、以施するにあたり、Lenovo System x サーバー上での HyperStore

下のハードウェア構成で実施しました。

表 3 ：Lenovo System x サーバー 構成詳細
System x3650 M4 (7915) 構成詳細CPU

Xeon E5-2640 2.5GHz x2

メモリ

64GB

RAID

ServeRAID-M5110e コントローラー ( オンボード )ServeRAID-M5110 コントローラー (81Y4481)

Disk

SATA SSD 400GB x 2 ※OS ／メタデータ領域として使用
S3700 400GB SATA 2.5 型 MLC HS Enterprise SSD (41Y8336)
6Gb SAS 300GB x 12 ※データ領域として使用
300GB 10K 6Gbps SAS 2.5 型 Gen2 HS (90Y8877)※パススルーモードでの JBOD 接続、M5110e に 2 本の SSD、4 本の HDD、M5110 に 8 本の HDD を接続

Network

オンボー ド GbE (Intel)x 4 ポート
拡張 10GbE x 2 ポート
Qlogic デュアルポート 10GbE SFP+ VFA for IBM System x (90Y4600)※HyperStore のサービス提供用 I/F として、
1Gbps x2 bonding mode=0 (I/F 名 : bond1)
内部通信用 I/F として、10Gbps x2 bonding mode=0 (I/F 名 : bond0) を割り当て。

構成概要（物理構成）
ハードウェアの物理構成としては、同じ構成である System x サーています。

バーを 3 台使用し、各サーバーの 1GbE ネットワーク・インターHyperStore のインターフェース設定で、1GbE × 2 ポート構成

フェー ス × 2 ポ ート（I/F 名：bond1）と 10GbE ネットワ ーの bond1 をサービス提供用 I/F として、10GbE × 2 ポート構成

ク・インターフェース × 2 ポート（I/F 名：bond0）をそれぞれ、の bond0 を内部通信用 I/F として割り当てています。

Linux-OS の bonding 機能（モード 0）を使用してチーミングしマネージメント用 1GbE スイッチ
Rack Switch G8052

System x3650M4-3

インターコネクト用 10GbE スイッチ
Rack Switch G8124E

System x3650M4-2

System x3650M4-1

図 1図：1検証環境物理構成図： 検証環境物理構成図

図 2 ： Lenovo System x サーバー

構成概要（論理構成）
本検証環境では下図のように、System x3650 M4（7915）x 3

ク領域は、合わせて一つの仮想的なストレージ空間として認識され台を HyperStore ジオクラスターのノードとして構成しています。

ます。

ジオクラスターのノードとして組み込まれた各 System x のディスサービス提供用 N/W セグメント（1GbE）:192.168.0.0/24

.55

.56

.54

.1

.2

.3

内部通信用 N/W セグメント（10GbE）:192.168.1.0/24

図 3 ： 検証環境 論理構成図

クライアント（S3 対応アプリケーション等や管理者の PC 等）からHyperStore の複製やリペア処理等の内部処理を行うための通信の S3 API ／ Admin API 経由での HyperStore へのアクセスは、は、内部通信用 N/W セグメント（192.168.1.0/24）に接続さサービス提供用 N/W セグメント（192.168.0.0/24）に接続された 10GbE × 2 ポートのインターフェースによって行われます。

れた 1GbE × 2 ポートのインターフェースによって行われます。

4

本検証に使用した CLOUDIAN HyperStore® のバージョン

本検証では、上述の「3. 本検証ハードウェアシステム情報」記載

HyperStore® Ver. 5.1.0」をインストールしています。

の環境に、本検証時点での最新バージョンである「CLOUDIAN

5

本検証に使用したテストツール

本検証では、3 ノード構成の HyperStore ジオ・クラスターに対えるようにしたツールです。

して負荷を掛けてパフォーマンスを測定するため、クラウディアン

本検証では、バージョン「5.1」の Cloudian YCSB ツールを使用

が YCSB をベースに開発した「Cloudian YCSB」というツールと、し、同一ネットワーク上に設置した HyperStore とは異なるマシン

HyperStore に格納されたデータの一貫性（整合性）を確認するから実行します。

ために、独自に開発した「Cloudian model3」というツールを使※「YCSB」の詳細は、下記 URL をご参照ください。

用しています。

http://labs.yahoo.com/news/yahoo-cloud-serving-

Cloudian YCSB ツール
YCSB と は、Yahoo! が 主 導 で 行 っ て い る“Yahoo Cloud
Serving Benchmark”プロジェクトの略称です。そのプロジェク
トの中で様々な、異なるクラウド・サービスの性能を評価することができる共通のパフォーマンス診断ツールを開発し提供しています。
「Cloudian YCSB」ツールとは、上述の YCSB をクラウディアン
が改修・機能追加をして、HyperStore のパフォーマンス測定を行

benchmark/

Cloudian models3 ツール「Cloudian models3」ツールとは、S3 API レベルで HyperStoreに格納されたオブジェクト（データ）の整合性（HyperStore に対して、S3 API より書き込まれたデータが、期待される複製数等の設定条件を満たし整合性の取れた状態で格納されているか）を確認するために、クラウディアンが開発したツールです。
本検証では、バージョン「201501」の Cloudian models3 ツー
ルを使用しています。

6

パフォーマンス測定（基本）■ 検証内容■ 検証結果・ 1 グループ× 1000 ユーザー× 1 バケット× 5000 オブジェクト・データ格納領域の 70% まで下記データを格納するのに約 5.5 時( 合計 500 万オブジェクト )・格納したオブジェクトのサイズ = 10240 バイト、1048576 バイ

間要しました。
・上記格納データの修復操作は約 2 時間で完了しました。

ト ( 交互に格納 )・6 スレッド (6 並行リクエスト ) でリクエストを送信[root@node2 ~]# time /opt/cloudian/bin/hsstool -h node2 repair allkeyspaces
Executing repair. computedigest=false keyspaces=allkeyspaces
primaryrange=false merkletree=true logging=false check-metadata=false
timestamp: 1423014212629
Repair command #781 completed.
Number of files repaired: 4real
116m8.151s
user
0m2.801s
sys
0m0.848s

7

パフォーマンス測定（サンプルテスト）

上述「5. 本検証に使用したテストツール」で説明した Cloudian

列処理を行います。

YCSB を使用して、指定したデータ・サイズ及び PUT と GET の割

テ ストは 各 パ タ ー ン の ケ ー ス（ PUT と GET の 割 合 比 率 が合比率により、HyperStore ノードに対してオブジェクトの書き込み「100%:0%」、「20%:80%」、「50%:50%」、「80%:20%」） 毎 に、及び読み取りを実行します。

15 分間実行し続けます。

その際に指定したスレッドを起動し、HyperStore ノードへは同時並■ 検証内容①・測定実施日時： 2015 年 2 月 4 日 15:11 ～ 16:58
・測定条件設定：PUT（書き込み）及び GET（読み取り）するオブジェクトのデータ・サイズを 100 バイトとし、同時に 10 スレッドの並行処理を 15 分間行う。

■ 検証結果①
表 4 ： 100 bytes / 10 threads / 15 mins のサンプルテスト検証結果■ オブジェクト・サイズ =100 バイト／スレッド =10
オペレーション数 / 秒 平均遅延時間 ( ミリ秒 ) 平均遅延時間 ( ミリ秒 ) 総オペレーション数(PUT と GET の合計 )
(PUT)
(GET)
(PUT)

100% : 0%1373.28

7.27

<N/A>

1235986<N/A>

20% : 80%

1774.37

6.71

5.27

319762

1277206

50% : 50%

1134.33

6.66

5.23

51092450980380% : 20%1485.62

7.07

5.32

1069801

267295

オブジェクト・サイズ＝100 バイト／スレッド＝10 によるオペレーション数 v.s. 待ち時間

オブジェクト・サイズ＝100 バイト／スレッド＝10 によるオペレーション数 v.s. OPS
200

1,800,000

180

1,600,000

160

1,400,000

140

1,200,000

120

1,000,000

100

800,000

80

600,000

60

400,000

40

200,00020

0100% : 0%

20% : 80%

50% : 50%

80% : 20%

1,500,000

2,000

1,400,000

1,800

1,300,000

01,200,000

1,600

1,100,000

総オペレーション数

2,000,000

平均遅延時間（msec）

総オペレーション数

総オペレーション数
(GET)

1,400

1,000,000
900,000

1,200

800,000

1,000

700,000
600,000

800

500,000

600

400,000
300,000

400

200,000

200

100,000
00

オペレーション数（PUT）

オペレーション数（GET）

オペレーション数（PUT）

PUT 待ち時間（msec）GET 待ち時間（msec）

オペレーション数（PUT と GET の合計）

図 4 ： オペレーション数 v.s. 遅延時間（100 bytes / 10 threads / 15 mins）

OPS（PUT＋GET）

PUT 操作とGET 操作の割合

オペレーション数（GET）

図 5 ： オペレーション数 v.s. OPS（100 bytes / 10 threads / 15 mins）■ 検証内容②・測定実施日時： 2015 年 2 月 5 日 11:13 ～ 16:29
・測定条件設定：PUT（書き込み）及び GET（読み取り）するオブジェクトのデータ・サイズを 1,024（1K）バイトとし、同時に 10 スレッドの並行処理を 15 分間行う。

■ 検証結果②
表 5 ： 1,024 bytes / 10 threads / 15 mins のサンプルテスト検証結果■ オブジェクト・サイズ =1,024 バイト／スレッド =10
PUT 操作とGET 操作の割合

オペレーション数 / 秒 平均遅延時間 ( ミリ秒 ) 平均遅延時間 ( ミリ秒 ) 総オペレーション数(PUT と GET の合計 )
(PUT)
(GET)
(PUT)

総オペレーション数(GET)

100% : 0%1425.18

7<N/A>1282692<N/A>

20% : 80%

1814.67

6.47

5.25

3263711306869

50% : 50%1303.73

6.57

5.2

58677558654880% : 20%

1701.16

7.43

5.47

1225212305872

オブジェクト・サイズ＝1K バイト／スレッド＝10 によるオペレーション数 v.s. OPS

180

1,600,000

160

1,400,000

140

1,200,000

120

1,000,000

100

800,000

80

600,000

60

400,000

40

200,0002000100% : 0%

20% : 80%

50% : 50%

80% : 20%

1,500,000

2,000

1,400,000

1,800

1,300,000

1,200,000

1,600

1,100,000
1,000,000

1,400

900,000

1,200

800,000

1,000

700,000

600,000
500,000
400,000
300,000
200,000
100,000
0

800
600
400
200
100% : 0%

20% : 80%

オペレーション数（PUT）

オペレーション数（GET）

オペレーション数（PUT）

PUT 待ち時間（msec）GET 待ち時間（msec）

オペレーション数（PUT と GET の合計）

図 6 ： オペレーション数 v.s. 遅延時間（1 Kbytes / 10 threads / 15 mins）

OPS（PUT＋GET）

1,800,000

総オペレーション数200

平均遅延時間（msec）

総オペレーション数

オブジェクト・サイズ＝1K バイト／スレッド＝10 によるオペレーション数 v.s. 待ち時間
2,000,000

50% : 50%

80% : 20%0

オペレーション数（GET）

図 7 ： オペレーション数 v.s. OPS（1 Kbytes / 10 threads / 15 mins）■ 検証内容③・測定実施日時： 2015 年 2 月 5 日 14:02 ～ 15:23
・測定条件設定：PUT（書き込み）及び GET（読み取り）するオブジェクトのデータ・サイズを 1,048,576（1M）バイトとし、同時に10 スレッドの並行処理を 15 分間行う。

■ 検証結果③
表 6 ： 1 Mbytes / 10 threads / 15 mins のサンプルテスト検証結果■ オブジェクト・サイズ =1,048,576 バイト／スレッド =10
オペレーション数 / 秒 平均遅延時間 ( ミリ秒 ) 平均遅延時間 ( ミリ秒 ) 総オペレーション数(PUT と GET の合計 )
(PUT)
(GET)
(PUT)

100% : 0%

214.46

46.57

<N/A>

193016<N/A>

20% : 80%

416.26

30.03

22.38

74657

299986

50% : 50%247.63

33.4

16.62

11150511125780% : 20%259.07

42.16

23.91

18653846628

オブジェクト・サイズ＝1M バイト／スレッド＝10 によるオペレーション数 v.s. 待ち時間
2,000,000

200

1,800,000

180

1,600,000

160

1,400,000

140

1,200,000

120

1,000,000

100

800,000

80

600,000

60

400,000

40

200,0002000100% : 0%

20% : 80%

50% : 50%

80% : 20%

総オペレーション数

オブジェクト・サイズ＝1M バイト／スレッド＝10 によるオペレーション数 v.s. OPS

平均遅延時間（msec）

総オペレーション数

総オペレーション数(GET)

1,500,000
1,400,000
1,300,000
1,200,000
1,100,000
1,000,000
900,000
800,000
700,000
600,000
500,000
400,000
300,000
200,000
100,000
0

2,000
1,800
1,600
1,400
1,200
1,000
800
600
400
200
100% : 0%

20% : 80%

オペレーション数（PUT）

オペレーション数（GET）

オペレーション数（PUT）

PUT 待ち時間（msec）GET 待ち時間（msec）

オペレーション数（PUT と GET の合計）

図 8 ： オペレーション数 v.s. 遅延時間（1 Mbytes / 10 threads / 15 mins）

OPS（PUT＋GET）

PUT 操作とGET 操作の割合

50% : 50%

80% : 20%0

オペレーション数（GET）

図 9 ： オペレーション数 v.s. OPS（1 Mbytes / 10 threads / 15 mins）

■ 検証内容④
・測定実施日時：2015 年 2 月 5 日 12:28 ～ 13:49
・測定条件設定：PUT（書き込み）及び GET（読み取り）するオブジェクトのデータ・サイズを 5,242,880（5M）バイトとし、同時に10 スレッドの並行処理を 15 分間行う。

■ 検証結果④
表 7 ： 5 Mbytes / 10 threads / 15 mins のサンプルテスト検証結果■ オブジェクト・サイズ =5,242,880 バイト／スレッド =10
オペレーション数 / 秒 平均遅延時間 ( ミリ秒 ) 平均遅延時間 ( ミリ秒 ) 総オペレーション数(PUT と GET の合計 )
(PUT)
(GET)
(PUT)

100% : 0%60.83

164.26

<N/A>

54746

<N/A>

20% : 80%

117.26117.21

77.14

21193

84339

50% : 50%

78.52

141.65

70.84

35374

35247

80% : 20%70.1

155.12

91.44

50583

12504

オブジェクト・サイズ＝5M バイト／スレッド＝10 によるオペレーション数 v.s. OPS
200

1,800,000

180

1,600,000

160

1,400,000

140

1,200,000

120

1,000,000

100

800,000

80

600,000

60

400,000

40

200,00020

0100% : 0%

20% : 80%

50% : 50%

80% : 20%0

総オペレーション数

2,000,000

平均遅延時間（msec）

オブジェクト・サイズ＝5M バイト／スレッド＝10 によるオペレーション数 v.s. 待ち時間

総オペレーション数

総オペレーション数(GET)

1,500,000
1,400,000
1,300,000
1,200,000
1,100,000
1,000,000
900,000
800,000
700,000
600,000
500,000
400,000
300,000
200,000
100,000
0

2,000
1,800
1,600
1,400
1,200
1,000
800
600
400
200
100% : 0%

20% : 80%

オペレーション数（PUT）

オペレーション数（GET）

オペレーション数（PUT）

PUT 待ち時間（msec）GET 待ち時間（msec）

オペレーション数（PUT と GET の合計）

図 10 ： オペレーション数 v.s. 遅延時間（5 Mbytes / 10 threads / 15 mins）

OPS（PUT＋GET）

PUT 操作とGET 操作の割合

50% : 50%

80% : 20%0

オペレーション数（GET）

図 11 ： オペレーション数 v.s. OPS（5 Mbytes / 10 threads / 15 mins）■ 検証結果に対する評価に限っては、リクエストのトラフィックを 10Gbps の内部ネットワー

いずれの試験においても、良好な結果が得られています。

クを利用して送信した結果となっています。

オペレーション数 / 秒や平均遅延時間の情報から、SAS ディスクの総ディスク容量が比較的少ない環境なので、小さいデータ・サイ

高 IOPS や低遅延といった特性が明確に表れています（一般的なズで各種性能を測定しています。数 KB 単位のデータは一桁ミリ

SATA のディスクで構成したシステムの場合、数 KB 単位のデータ秒で処理を行なえること、5MB のデータでも 200 ミリ秒未満ででも二桁ミリ秒の平均遅延時間となります）。特記事項として、処処理できており、ファイル共有目的のネットワーク・ストレージとし理性能が高いため MB 単位のデータを扱う際、1Gbps のサービス・ても、十分に使用できる性能を示しており、効果を発揮できると考ネットワークからリクエストのトラフィックを流した場合、ネットワー

えられます。

クがボトルネックとなってしまいました。そのため、この性能試験

データの分散度確認■ 検証内容各ノードに搭載されている全ての（HyperStore のデータ格納領
域に割り当てられている）ディスクに対して均等にデータが分散さ

HyperStore ジオ・クラスターが認識しているデータ格納領域のれ、各ディスクに作成されたファイルシステムの使用率がほぼ均一

ほぼ全てを使い切るように Cloudian YCSB の（オブジェクトのになるかを確認します。

PUT に関する）処理を実行します。実行後、ジオ・クラスターを構成しているノードが搭載しているディスクに対してデータが均等■ 検証結果に分散配置されるかを検証します。

下表のとおり、各 HyperStore ノード上の物理ディスクに紐づく

本検証環境の HyperStore データ格納領域は JBOD で構成されファイルシステム（マウント・ポイント）のディスク使用率は、全ているため、各ノードに搭載されている 300GB SATA ディスク ×てのディスク（計 36 本 = 12 本 / ノード × 3 ノード）でほぼ同12 本はそれぞれ右表のように物理デバイスとファイルシステム（マ様の使用率を示しており、オブジェクト（データ）は各ノードの各

ウント・ポイント）が対応しています。

ファイルシステム/sas/cloudian07/dev/sdh/sas/cloudian08/dev/sdi/sas/cloudian09/dev/sdj/sas/cloudian10/dev/sdk/sas/cloudian11/dev/sdl/sas/cloudian12

node2

20

node3

10
0

ファイルシステム（マウント・ポイント）/sas/cloudian12/dev/sdg

node1

30

/sas/cloudian11/sas/cloudian06/sas/cloudian10/dev/sdf

5040/sas/cloudian09/sas/cloudian05/sas/cloudian08/dev/sde

7060/sas/cloudian07/sas/cloudian04/sas/cloudian06/dev/sdd80/sas/cloudian05/sas/cloudian03

90/sas/cloudian04/dev/sdc

100/sas/cloudian03/sas/cloudian01/sas/cloudian02/sas/cloudian01/dev/sda/dev/sdb

ディスク使用率から見る HyperStore ノードでのオブジェクト・データ配置の分散渡合ディスク使用率（%）

物理デバイス

ディスクに均等に分散配置されています。

/sas/cloudian0289HyperStore システムの安定性確認■ 検証内容■ 検証結果Cloudian YCSB を使用して、HyperStore に対して 1 週間、デー

1 週間、無停止で HyperStore へのデータ書き込み／読み取り

タの書き込み（PUT）、データ一覧情報の読み取り（LIST）とデー
タの読み取り（GET）及び削除（DELETE）を間断無く連続で行い、何らかしらのエラーや HyperStore を構成するプロセスのダウンが発生しないことを確認します。

10

処理を実行し、・ エラーログの出力 → 無し
・ HyperStore を構成するプロセスの停止 → 無しという結果になりました。

リペア処理性能確認
後、手動で“hsstool repair”コマンドを実行します。“hsstool■ 検証内容HyperStore ノ ー ド 3 台 の う ち 2 台 の デ ー タ 領 域（/sas/cloudian0X）に格納されている全てのデータを削除し、そのrepair”は、コマンドのオプションで指定したノードの複製デー
タを修復するコマンドです。

実行したコマンド/opt/cloudian/bin/hsstool -h node1 repair allkeyspaces

コマンドの出力

Executing repair. computedigest=false
keyspaces=allkeyspaces primaryrange=false
merkletree=true
logging=false check-metadata=false
timestamp: 1423214154352
Repair command #895 completed.
Number of files repaired: 17180386
real

1118m4.012s■ 検証結果1700 万件強、約 3.5TB のオブジェクトが複製対象であり、このデータ修復が完了するまでに、約 18.6 時間掛かりました。

データ格納に掛かった時間と同等の時間が、修復に掛かります。
この結果は、事前に取得していた性能試験と、遜色のない修復時間と考えられます。

11

データ一貫性（整合性）確認の各種 S3 リクエストには、PUT や GET、DELETE といった単純■ 検証内容この検証は、「Cloudian models3」ツールを用いて実施します。
「Cloudian models3」は、ランダムに各種 S3 リクエストを生成・送信すると同時に、その応答内容を含めた状態を全てツール
側で記録していきます。結果、HyperStore に格納された内容と、ツール側で記録した内容が同じであることを確認し、データの一貫性（整合性）が常に保たれていることを保証します。
例えば、一度書き込み要求に OK で応答されたデータは、以降必ず読み出せることと、読み出した内容が、ツール側で記録してな API はもとより、マルチパートアップロードやバージョニングといった高レベルな API まで確認対象となっています。
このツールを利用しつつ、1 ノードのデータを全て削除・修復処理を行なった後も、期待通り HyperStore の応答が返されることを確認します。

■ 検証結果
期待通り、全ての応答が確認できました。

おいた内容と一致することの確認を行なうことができます。冒頭
init → base → check■generate 5000 → check → check → check: OK

init → base → check

12■

generate 10000 → check → check → check: OK■

delete all hsfs data from node2 → check → check → check: OK■

hsstool repair node2 → check → check → check: OK

CMC 経由で 2 ノード構成の HyperStore システムに 1 ノードを追加■ 検証内容■ 検証結果

本検証実施前に、3 ノード構成であった HyperStore ジオ・クラス

期待どおり、再配置が実行されました。

ターから 1 ノードを削除し、2 ノード構成にします。2 ノード構成

以下に本検証での操作を実施した際のログ（/var/log/cloudian/になった状態で、CMC（Cloudian Management Console）をcloudian-ui.log）出力を、添付します。

使用して新たに新規のノードを一台追加します。

[root@node1 CloudianPackages]# tail -f /var/log/cloudian/cloudian-ui.log
2015-02-16 17:13:53,492 INFO [http-bio-8443-exec-12] CurrencyCodes:<init>(37) Currency is not supported for Locale ''2015-02-16 17:22:19,192 INFO [http-bio-8443-exec-7] root:<clinit>(30) Loading mime types from file:/opt/cloudian-packages/apachetomcat-7.0.54/webapps/Cloudian/WEB-INF/classes/mime.types
2015-02-16 17:31:54,970 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(111) Command to execute: mkdir -m 700 -p /root/.ssh
2>&1, to host: 192.168.0.56
2015-02-16 17:31:54,976 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(125) Sent command: mkdir -m 700 -p /root/.ssh 2>&1,
to host: 192.168.0.56. Command output:
2015-02-16 17:31:55,017 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(111) Command to execute: cat /root/cloudianinstallation-key.pub >> /root/.ssh/authorized_keys, to host: 192.168.0.56
2015-02-16 17:31:55,023 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(125) Sent command: cat /root/cloudian-installationkey.pub >> /root/.ssh/authorized_keys, to host: 192.168.0.56. Command output:
2015-02-16 17:31:55,094 INFO [http-bio-8443-exec-3] SSHManager:connect(86) SSH connect to to host: node1
2015-02-16 17:31:55,095 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(144) Command to execute: cd /root/CloudianPackages/;./cloudianInstall.sh -a "region1,node3,192.168.0.56,DC1,RAC1" 2>&1, to host: node1, inputBuffer:yes
yes
2015-02-16 17:33:34,609 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(163) Sent command: cd /root/CloudianPackages/; ./cloudianInstall.sh -a "region1,node3,192.168.0.56,DC1,RAC1" 2>&1, to host: node1. Command output:
Adding region1,node3,192.168.0.56,DC1,RAC1 host configuration to Cloudian HyperStore(R) cluster
Check if host node3 is reachable at 192.168.0.56...
Checking connectivity to host node3 at IP 192.168.0.56 ... OK
Add [region1,node3,192.168.0.56,DC1,RAC1] to survey file ./survey.csv for further processing.
Processing cluster host information in ./survey.csv file.
Checking connectivity to host node1 at IP 192.168.0.54 ... OK
Checking connectivity to host node2 at IP 192.168.0.55 ... OK
Checking connectivity to host node3 at IP 192.168.0.56 ... OK
Service role assignment depends on the number of nodes in your cluster. You may
wish to save role assignments from previous configuration runs even if you areadding or removing some nodes.
Node role assignments are preserved for this task.
Please review configuration settings carefully before proceeding with Puppet agent runs.
Your existing Puppet manifest files are backed up in ./manifests.20150216173155
Updating /etc/hosts file on node1.
/etc/hosts file on node1 updated.
Starting up Puppet master process on host node1.
Puppet master process on host node1 started
Configuring agent nodes using Puppet server node1.
Configuring agent node node3.
Ready to run Puppet agent on host node3.

This could take some time.

Puppet agent run on node node3 successful.
All Puppet agent runs completed successfully in region1 region.
Puppet agent daemon is now running on node1.
Puppet agent daemon is now running on node2.
Puppet agent daemon is now running on node3.
Puppet agent run ended for region1.
New node [region1,node3,192.168.0.56,DC1,RAC1] record added to survey file ./survey.csv.
Puppet configuration run was successful on host node3.
Restarting RedisMonitor service ...
On host node1:
Starting redis monitor ...[
On host node2:
Starting redis monitor ...[

OK

]

OK

]

If RedisMonitor service did not start correctly, you must manually restart it.
Starting Cassandra process on node3 ...
Cassandra process on node3 started and running.
Please complete any remaing tasks associated with cluster expansion on Cloudian Management Console.
2015-02-16 17:34:04,670 INFO [http-bio-8443-exec-3] SSHManager:connect(86) SSH connect to to host: node3
2015-02-16 17:34:04,671 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(111) Command to execute: /etc/init.d/cloudianhyperstore start, to host: node3
2015-02-16 17:34:05,770 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(125) Sent command: /etc/init.d/cloudian-hyperstore
start, to host: node3. Command output: Starting HyperStore ...[ OK ]2015-02-16 17:34:05,830 INFO [http-bio-8443-exec-3] SSHManager:connect(86) SSH connect to to host: node3
2015-02-16 17:34:05,830 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(111) Command to execute: /etc/init.d/cloudian-s3
start, to host: node3
2015-02-16 17:34:07,073 INFO [http-bio-8443-exec-3] SSHManager:sendCommand(125) Sent command: /etc/init.d/cloudian-s3 start, tohost: node3. Command output: Starting Cloudian S3 and Cloudian admin ...[ OK ]CMC …“Cloudian Management Console”の略称。HyperStore の管理用 Web ユーザーインターフェースで、ユーザーやグループ（テナント）の管理、課金管理、QoS
設定等の豊富な機能を持ち、かつ各ユーザーが Dropbox のように自分の HyperStore にアップロード／ダウンロードできる機能（データ・エクスプローラー）も装備しています。
標準搭載の機能ですので、無償でご使用頂けます。

13

総評

このたび実施した全ての検証項目において、たいへんに良好なさ ら に、 ソ フト ウェ ア 定 義 ストレ ー ジ（Software Deﬁned

結果が得られました。 通常は、SATA のディスクを利用したノー

Storage) ならではの利便性、地域冗長を考慮した巨大なストレー

ド構 成 が 採 用 されます が、SSD や SAS ディスクでも 問 題 なくジ空間を構築できる拡張性の高さや、HTTP を利用したアクセス

HyperStore は動作すること、また SAS ディスクを利用することに性の良さをそのまま継承しつつ、Lenovo System x サーバーをより、より高速なストレージ・システムを組むことができました。

用いて構成される CLOUDIAN HyperStore システム構成と更なまた、本検証実施中にハードウェアに起因する問題や障害、パフォー

る高速アクセス仕様の新しい構成を検証できました。今後の幅広

マンス劣化は発生しておらず、Lenovo の System x サーバーのい利用シーンが期待されます。

安定性と CLOUDIAN HyperStore との相性の良さ・親和性の高さが実証されました。

日本と米国を開発拠点とするクラウディアンは、パブリッククラウド、プライベートクラウド、オンプレミス環境でハイブリッドに活用できる SDS（Software Deﬁned Storage: ソフトウェア定義ストレージ）である「CLOUDIAN HyperStore」をソフト

クラウディアンについて

ウェア製品及びアプライアンス製品により提供しています。国内外大手プロバイダー、エンタープライズが採用する CLOUDIAN
HyperStore は、複数データセンター間を含み、データの複製・分散配置によるデータ保護をすることで、DR/BCP 対策を担保したオブジェクトストレージを構築できます。汎用サーバ 2 台からペタバイト超級にまで経済的に、柔軟にスケールアウトします。
統計・課金・管理機能も実装済みであり短期間に利用開始できます。