Takeruでこのようなものを動かしてみました



1.はじめに〜背景

大規模で高速なストレージ評価の一環として、ISILON Cluster Storageを評価しましたので紹介いたします。
まず、評価結果の前に、どういった背景でこのようなストレージの必要性が出てきたのか、
またISILONとはどのような特長を持った製品なのかを説明します。

多数のユーザー、増え続けるデータ容量

増大の一途を辿るデータ容量、使用するユーザー数の増加、そしてCPUコア数の増加、
そうした状況でもパフォーマンスを低下させず、
逆にストレージを増やすことでパフォーマンスが向上する、
そんなストレージの必要性が高まっています。

分散ファイルシステム

そのようなストレージシステムを構築するためにオープンソースの世界でも
LustreやGlusterFS、Gfarmといったものをはじめ様々なものがあり
その種類や内容も多様化してきています。

それぞれ少なくない違いを特長として持ってはいますが、
ネットワーク上に存在する複数のストレージを、まとめて一つの領域として
各クライアントのマシンからマウントできる、という点では概ね共通しています。

例えば、5TBのファイルサーバーが4台ある場合に、クライアントマシンからは
これらをまとめて20TBの領域としてマウントできるようなものです。

ISILONとはどんなストレージなのか

簡単に言ってしまうと、アプライアンスの分散ファイルシステムと言っていいものです。
Isilon Nodeと呼ばれるストレージ筐体と、
Isilon Node間の通信に用いられるInfiniband Switchから構成されています。

クライアントマシンとなる計算ノードは、複数あるIsilon Nodeのある特定の一台をNFSマウントして読み書きを行います。
クライアントマシンからは、その一台がNFSサーバーとして存在している、という意識だけで使用できるため
構成は非常にシンプルです。

このように、クライアントマシンとIsilonを繋ぐ入口と出口はGigabit Ethernetであるため、その帯域以上の性能が出ることはありません。

一度Isilonに書き込まれたデータは、均等なサイズに分割されて全てのIsilon Nodeに配られます。
また、読み出しの際は各Isilon Nodeに分割されたデータを並列で読み込んできます。

これらのIsilon Node間の通信は、非常に高速なInfinibandで行われるため、複数のクライアントマシンから
同時に読み書きの要求が合った場合でも性能の低下がおさえられます。

また、オープンソースの分散ファイルシステムにはない運用面での簡易さ、利便性、安全性があります。
Isilon Node追加の際も、システムを止めることなく約60秒で追加可能ですし、
冗長構成もパリティの持ちかたをファイル単位で設定することができ柔軟性に富んでいます。 
 

NFSとの比較

NFSサーバーとNFSクライアント、そしてIsilon Cluster Storageとそのクライアントマシン、
この二つを図を使って比較してみます。

NFSサーバーとNFSクライアントの場合、
NFSサーバーとNFSクライアント間のNetwork(下図水色の部分)は、
ユーザー数とストレージ容量が増えても変わらないため、
ここがボトルネックとなって性能が低下してしまうことがあります。
(NFSクライアントの台数がある程度までの数であれば、10GbEやInfiniband、あるいは複数のGbEポートを持たせることで、かなりの改善ができます。)

Isilonを使った場合、ノードを増やした分だけネットワークの口が増え、帯域が増加するため
NFSにおけるボトルネックが解消されます。
  • 図1:NFSサーバーとNFSクライアント
    takeru_isilon_3small.pngユーザー数とデータ容量が増えると→→→takeru_isilon_4small.png
  • 図2:ISILON Cluster Storageとクライアントマシン
    takeru_isilon_6small.pngユーザー数とデータ容量が増えると→→→takeru_isilon_5small.png

2. テスト環境

ハードウェア環境

以下のようなハードウェアを用い、図2のような構成を組んで評価を行いました。

Isilon 1920X 5台
Infiniband Switch 2台 (冗長構成)

GbE Switch 1台
Linuxクライアントマシン 1〜10台

isilon_1.jpg

3. Isilon Cluster Storage 運用面に関する評価

Isilonノード追加時の動作について

IsilonノードをGbE、Infinibandに接続して電源を投入後、 前面ボタンの操作のみですぐに追加可能です。

60秒で追加可能と言われていますが、実際にはそれほどかからずに追加でき、クライアント側からもすぐに容量の増加が確認できました。

実際にはバックグラウンドでIsilonノード間でのデータ平準化処理が動きはじめていますが、
ユーザー側では特に意識することなく使い続けることができました。

マネジメントについて

WEBブラウザを使ってマネジメントができます。
IsilonノードはそれぞれIPアドレスを持っていますが、どのIPアドレスからアクセスしても同じように使うことができます。

Isilonノードの状態、各Isilonノードを参照しているクライアントの台数、
Isilonノードの追加や削除の設定、802.3adの設定、ファイル毎の冗長設定など
基本的にほとんどの設定はブラウザ経由で可能で非常に便利に使うことができました。

冗長設定について

+1〜+4までのパリティを持つことが可能です。
全体に同じパリティポリシーを適用することもできますし、
非常に重要なファイルは、+4のパリティ、通常のデータは+1、+2のパリティ、といったように
ファイル単位でパリティの持ちかたを定義することも可能です。

また、データを保持したままオンラインで冗長設定の変更を行うことも可能です。

4. Isilon Cluster Storage パフォーマンス面での評価項目

以下の4項目について評価を行いました。

  • 4-1.Isilonの台数による性能の違い
  • 4-2.クライアントの台数を増やしていった時の性能
  • 4-3.複数のクライアントが同時に同じファイルをコピーしてきた場合の性能

4-1. Isilonの台数による性能の違い

3台のIsilonをマウントした場合と、5台のIsilonをマウントした場合のそれぞれについて、
1台のクライアントマシンからbonnie++を実行して、その結果を比較しました。

write性能に関しては、5台のケースが若干上回る程度だったのですが、read性能に関しては、約40%〜60%程度性能が向上しました。
Isilonノード間に分割されたファイルを並列で読み込むために、Isilonの台数が多い方がパフォーマンス面で有利になることを示しています。
3 clients(KB/s)5 clients(KB/s)
Sequential Output (write) Per Chr99188100172
Sequential Output (write) Block6694472538
Sequential Input (read) Per Chr5480076002
Sequential Input (read) Block5820892260

4-2. クライアントの台数を増やしていった時の性能

5台のIsilonノードに対して、クライアントの数を1台〜10台まで複数台同時にbonnie++を実行した時の
結果の値を合計し比較しました。
クライアントの台数がIsilonノードと同じ5台となるまでは、台数を増やすことでスループットの和は
リニアに近い形で伸びていきました。
これは、クライアントAはIsilonノードAを、クライアントBはIsilonノードBを、といった具合に
クライアントは明示的に指定のIsilonノードを別々にマウントしていることから、予想通りの結果となりました。

クライアントの台数が10台となった時(各Isilonノードは2台のクライアントから参照されている状態)の結果は以下の表になります。
802.3adを用い、Isilonノード側のネットワークを2本束ねた状態で測定しました。
writeに関しては、2台のクライアントが競合する形となり約20%〜40%程度の伸びとなりましたが
readに関しては、特にBlock単位での結果は2倍を越える結果となりIsilonノード間のInfinibandが効いているようです。
5 clients(KB/s)10 clients(KB/s)
Sequential Output (write) Per Chr483213595665
Sequential Output (write) Block317603453873
Sequential Input (read) Per Chr250208449569
Sequential Input (read) Block280976591530

4-3. 複数のクライアントが同時に同じファイルをコピーしてきた場合の性能

Isilon上にある約21GBのディレクトリを各クライアントが一台ずつローカル領域にコピーした場合と
10台同時にコピーした場合を比較しました。
下の表は、それぞれのコピーの合計時間とスループット(目安)です。

10台同時にIsilon領域をreadしても性能がほとんど低下しないのは、すばらしい性能です。
合計時間(秒)MB/s
1台ずつ2818.5274.5MB/s
10台同時2907.0472.2MB/s

4. まとめ

運用面に関して

運用面に関して特に優れていると感じたのは以下の4点

  • Isilonノード追加の容易さ
  • Isilonノード間のInfinibandインターフェースを用いたデータの分割、平準化の機能
    オープンソースの分散ファイルシステムには、データの平準化機能がないため容量に偏りが出たりする結果、
    書き込めるデータ容量が、各一台のサーバーの残り容量に依存してしまう場合などがあるものもあるのですが、
    それらに比べるとこの平準化機能があるおかげで、ストレージを無駄なく最後まで使いきることができそうです。
  • 柔軟な冗長設定 : ファイル毎の設定も可能で+4までの冗長化が可能
  • わかりやすいWEBブラウザを用いての管理、設定

性能面に関して

各クライアントマシンが、ある一台のIsilonノードを入口としてIsilonのボリューム全体をNFSマウントしている、
という構造を考えると、性能に関してはある程度予想がつき易いのですが、上記の通り、実際にその予想に近いパフォーマンスが出ました。

Isilonノード間のInfinibandを用いてのデータ分割、平準化の機能はパフォーマンス、特にread性能の向上に大きく寄与していると言えそうです。

また、Isilonノード数が増えることで、パフォーマンスが向上する結果から、
Isilonを使うことで、データ容量の増加とパフォーマンスの向上という二つの項目が、同時に達成でき、
ユーザー数の増加にも対応できるストレージとして、Isilonが有効なシステムである、ということを示すことができたのは
大きな収穫となりました。

isilon_3.jpg

5 Takeruを含んだ構成例

IsilonはNetwork上のストレージですので、下記リンク先のTakeru製品と容易に組み合わせて使用することができます。

http://www.nabe-intl.co.jp/products/products.html

例えば、Takeru for Sequencer IIと組み合わせることで、シーケンサーからの大量のデータをIsilon領域に書き込みながら、
既存の別のデータについて解析を行う、といった使いかたをしても性能が落ちないことは確認済みです。

takeru_isilon_7.png