Debian etch においてLinux Kernel が提供する(つまりSoftware)RAIDを試してみました。
RAID専用のハードウェアが不要な方法です。安価にRAIDを構成可能です。またハードウェアの束縛のない柔軟な構成が構築可能です。
今回は物理ドライブ2台でRAID1(ミラーリング)を組むことにしました。
OSをインストール時に最初からRAIDを組むことが能です。あるいは、インストール後からRAIDを組むこともできます。
気になるのはミラーリングによる性能の低下です。どのくらい遅くなるのか、どのくらい重くなるのか。

使用ハードウェア

HP ProLiant ML115/
http://h50146.www5.hp.com/products/servers/proliant/ml115/
CPU: AMD Athlon 64 3500+ (2.2GHz, 512KB L2)
Mem: PC2-5300 unbuffered DDR2 667MHz) 512MB x4 = 合計2GB
HDD: Seagate Barracuda 7200.10 SATA 3.0Gb/s 80-GB Hard Drive
     ST380815AS
    * SATA 3Gb/s interface
    * 8-MB cache buffer
    * 78 MB/s maximum sustained data transfer rate
    * 5-year warranty
http://www.seagate.com/www/en-us/products/desktops/barracuda_hard_drives/barracuda_7200.10/

注 SATA-2の仕様上では最大転送速度は3.0Gb/sではある。
しかし、HP社上のテクニカル仕様
http://h50146.www5.hp.com/products/servers/proliant/ml115/
によれば、本システム(マザーボード)上では最大ポート転送速度は 1.5Gb/sある。


参考:
シリアル10ビットを1バイト(パラレル8ビット)に変換するので、
1.5Gb/s は 150MB/sとなる。
これにファイルシステムのオーバーヘッドが加わるので
それ以下の値となるはずである。

RAID1の構成内容

インストール時に以下の構成を行ないました。

SATA-1に接続された/dev/sdaとなる物理ディスクを4分割
10GB LinuxRAID物理ボリューム (sda1)
10GB LinuxRAID物理ボリューム (sda2)
30GB LinuxRAID物理ボリューム (sda3)
10GB LinuxRAID物理ボリューム (sda4)

同様に
SATA-2に接続された/dev/sdbとなる物理ディスクを4分割
10GB LinuxRAID物理ボリューム (sdb1)
10GB LinuxRAID物理ボリューム (sdb2)
30GB LinuxRAID物理ボリューム (sdb3)
10GB LinuxRAID物理ボリューム (sdb4)

RAID用のデバイス(MD)を作成しました。

/dev/md0 を sda1 sdb1 から構成し、ext3  /として使用
/dev/md1 を sda2 sdb2 から構成し、ext3 swap として使用
/dev/md2 を sda3 sdb3 から構成し、ext3 /home として使用
/dev/md3 を sda4 sdb4 から構成し、ext3 /test として使用

参考:EXT3ファイルシステムについては以下のURLを参照。
http://ja.wikipedia.org/wiki/Ext3

注:
ミラーリングするのだからサイズは等しいべきである。
もし、大小混在すると、小さい側にそろえられるので損?をしてしまいます。
スワップを使用するかどうか、もし使用する場合にはその領域にRAID構成を必要とするかどうか。
これは管理方針に依存します。


参考:
当初分割しないでインストールを実行、ディスク全体でRAID1を構成していました。
同期から外して再同期化させるのに40分/80GBも待たされてしまいました。
実験を迅速に円滑に進めるためであれば細かく分割しておいたほうがいです。

テスト方針

ext3ファイルシステム上にddコマンドを使ってファイルをアクセスし、
ddコマンドが表示するータ転送速度(単位:MB/second)を元に性能を比較する。

コマンド実行例:

time dd if=/dev/zero of=$TARGET bs=2048MB count=1 oflag=sync

1+0 records in
1+0 records out
2048000000 bytes (2.0 GB) copied, 75.1807 seconds, 27.2 MB/s
0.004u 7.900s 1:15.50 10.4%     0+0k 0+0io 0pf+0w

参考:

CPU使用率を簡単に得るためにcshが上でtimeコマンドを使用しています。

1) 予備実験

キャッシュがディスクアクセス性能に与える影響を調べるために、
サイズの異なるファイルの書き出しを行なった。
データは、CPU上のキャッシュ(L2:512KB)、
メインメモリ(2GB)、HDD物理ドライブ(8MB)にキャッシュされてしまう。
実運用上はその影響に期待するべきであるが、
当評価としては、望ましくない。
従って、キャッシュの影響を排除するためには、
十分な大きなサイズ(メインメモリの数倍以上)の書き込みを行なう
必要がある。
あるいは、ファイルオープン時のオプション(man 2 openのO_SYNCを参照)
を指定する必要がある。
このオプションはddコマンドにおけるoflag=syncに相当する。

Write oflag=syncが無い場合の予備実験結果

MB    MB/s
----------------------------------------
4    318
16   313
64   315
256  291
512  264
1024 30.1
2048 28.9
----------------------------------------

 Image

2) 書き込み性能の評価

ext3ファイルシステムとして構成された /test 上にファイルを作成する。

# dd if=/dev/zero of=outputfile bs=1024MB count=1 oflag=sync

但し、キャッシュの影響を回避するために、ddコマンドに
oflag=syncを指定して、実際に本当にディスクに書き込みを
発生させる。

syncフラグを指定することにより、
bsとcountの積が例え一定であったとしても、count回数により
性能は変わってしまうことに注意されたし。

条件を変えてddコマンドにより書き込み性能を評価してみました。
書き込むサイズは
4MB, 16MB, 64MB, 256MB, 512MB, 1GB, 2GBです。
実際に本当にディスクに書き込みを行ないますので、
ファイルサイズの影響の差はほとんどないはずです。

この操作でも、HDD物理ディスク上の8MBのキャッシュの影響は排除できない。

2.1) RAID1 同期済

MB    MB/s
----------------------------------------
4    12.1
16   23.0
64   25.5
256  26.2
512  27.1
1024 27.7
2048 27.2
----------------------------------------

2.2) RAID1 同期なし(意図的に片側をミラーから外す)
#mdadm --manage /dev/md3 --fail /dev/sdb4

MB    MB/s
----------------------------------------
4    17.2
16   25.2
64   26.8
256  26.8
512  27.4
1024 27.7
2048 27.4
----------------------------------------

2.3) RAID1 同期なし、同期処理中
#mdadm --manage /dev/md3 --remove /dev/sdb4
した後に
#mdadm --manage /dev/md3 --add /dev/sdb4
にて、同期化を開始

MB    MB/s
----------------------------------------
4    16.5
16   24.2
64   25.8
256  25.6
512  26.7
1024 27.4
2048 26.6
----------------------------------------

2.4) RAID1なし、ミラーを外した/dev/sdb4を直接/mntにマウント

MB    MB/s
----------------------------------------
4    15.7
16   24.5
64   25.4
256  26.0
512  26.9
1024 27.7
2048 28.1
----------------------------------------

Image 

raid_UU:RAID1 同期済

raid_U_:RAID1 同期なし(意図的に片側をミラーから外す)

raid_UI:RAID1 同期なし、同期処理中

no-raid:RAID1なし

 

 

3) 読み出し性能の評価


ext3ファイルシステムとして構成された /test 上に2GBのファイルを作成する。
その後で、そのファイルを読み出す。

サイズは次の通り。
2MB, 4MB, 16MB, 64MB, 256MB, 512MB, 1024MB, 2048MB

ファイルシステムによるファイルキャッシュの影響を排除するために、
書き込んだ後にumountしてmountする。
あるサイズの読み込みを行なった後にumountしてmountする。
という操作を行なった。
この操作でも、HDD物理ディスク上の8MBのキャッシュの影響は排除できない。

3.1) RAID1 同期済

MB    MB/s
----------------------------------------
2    34.2
4    31.6
16   45.0
64   50.2
256  49.5
512  50.9
1024 51.2
2048 42.4
----------------------------------------

3.2) RAID1 同期なし(意図的に片側をミラーから外す)
#mdadm --manage /dev/md3 --fail /dev/sdb4

MB    MB/s
----------------------------------------
2    46.0
4    35.8
16   45.8
64   53.1
256  51.0
512  53.5
1024 52.1
2048 43.5
----------------------------------------

3.3) RAID1 同期なし、同期処理中
#mdadm --manage /dev/md3 --remove /dev/sdb4
した後に
#mdadm --manage /dev/md3 --add /dev/sdb4
にて、同期化を開始

MB    MB/s
----------------------------------------
2    31.5
4    51.1
16   48.1
64   48.3
256  48.6
512  48.8
1024 47.4
2048 41.7
----------------------------------------

3.4) RAID1なし、ミラーを外した/dev/sdb4を直接/mntにマウント

MB    MB/s
----------------------------------------
2     46.2
4     47.0
16    50.5
64    51.6
256   48.5
512   51.1
1024  51.3
2048  42.8
----------------------------------------

Image

raid_UU:RAID1 同期済

raid_U_:RAID1 同期なし(意図的に片側をミラーから外す)

raid_UI:RAID1 同期なし、同期処理中

no-raid:RAID1なし

 

考察

ddコマンドのoflag=syncを指定すると、書き込みサイズに関わらず、書き込み速度がほぼ一定する。
これはキャッシュの影響が最小限度に抑えられていることを意味する。

 ソフトウェアでRAID1を構成することによるアプリケーションの性能低下を観測することはできなかった。
しかし、システム全体の負荷が増える可能性は否定できない。
10回ほど実験を行ないその平均を求めると、より正確な性能低下を観測することができるかもしれない。

同期処理の間であったも、アプリケーションの性能低下を観測することはできなかった。
これは同期処理が計算機資源を明け渡しているからである。
その結果、同期に達する時間が長くなってしまう。

cat /proc/mdstatにより同期処理の速度と終了予定時刻をリアルタイムで観測することができる。

同期化処理開始直後、ddによる転送直前では
recovery =  0.3% (68480/19551040) finish=9.4min speed=34240K/sec

同期化処理中、ddによる転送直後では
recovery =  2.9% (582784/19551040) finish=73.3min speed=4306K/sec

同期化処理中、ddによる転送後からさらにしばらく経過すると
recovery =  9.2% (1808768/19551040) finish=11.3min speed=26031K/sec

障害が発生してHDDの交換後やホットスペアの同期開始時には、システム全体が高い負荷の
状態が長時間発生する可能性があることを示しています。
そして、その時間はアプリケーション側のディスクアクセス頻度に影響を受けてします。
同期終了時間の予測は難しいことを意味しています。

20GBで10分、80GBで40分というのが当環境で得られた値です。
160GBで80分、250GBで2時間、500GBで4時間です。
RAID1を実験する、試してみるときには、小さなパーティションで実験するのがいいです。

実運用では、同期処理に関わる時間を覚悟した上で、どのサイズを切り出すのか、切り出さないで
そのまま使うのかを決めるべきです。
 

参考URL

RAIDについて
http://ja.wikipedia.org/wiki/RAID 

ご本家
http://www.linux.or.jp/JF/JFdocs/The-Software-RAID-HOWTO.html#toc2 

mdadm解説(日本語)
 http://www.ioss.jp/sohodiy/mdadm8-1_5.html

Debian etch RAID1構成例、インストール時の画面写真あり
http://www.nilab.info/zurazure2/000763.html