SSD 8台 RAID0 でベンチマーク

SSD 8台でRAID0のシステムの評価中、ベンチマークしていますがこれは相当速いです。

・ハードウェア
RAIDカード：ARC-1883x　外部12G/s　2ポート
SSD：Samsung　MZ-7KE512B x8台
SAS JBOD (12G/sケーブルで接続)

・ベンチマーク環境
CrystalDiskMark 3.0.3 x64で4000MBを5回
Windows Server 2008 R2 SP1

———————————————————————–
RAID0 StripeSize 64KB

Sequential Read : 3107.352 MB/s
Sequential Write : 3748.819 MB/s
Random Read 512KB : 1610.638 MB/s
Random Write 512KB : 3402.341 MB/s
Random Read 4KB (QD=1) : 36.670 MB/s [ 8952.5 IOPS]
Random Write 4KB (QD=1) : 171.722 MB/s [ 41924.4 IOPS]
Random Read 4KB (QD=32) : 292.501 MB/s [ 71411.4 IOPS]
Random Write 4KB (QD=32) : 258.604 MB/s [ 63135.8 IOPS]
———————————————————————–

InfiniBandによるNFS/RDMAの速度検証

NFS/RDMAは、Infinibandの高速ネットワーク上で、NFSサーバ－NFSクライアント間において、メモリデータの遠隔転送(RDMA = Remote Direct Memory Access)を行う技術です。

InfiniBandアダプタ/スイッチを利用すると、高速ネットワークを構築することが出来ます。
さらに、RDMA (Remote Direct Memory Access) も利用することで、高速ネットワーク上のコンピュータ間でデータのメモリー間転送を行うことが出来ます。RDMAではCPU の介入がほとんどなく、コンピュータ間でメモリデータの遠隔転送が出来るそうです。これらをNFSで利用すると、データ転送速度アップを期待出来ます。

NFS/RDMAを利用する場合/利用しない場合で、どの程度違いがあるのか検証を行いました。

NFS/RDMA動作には、カーネルモジュールが必要で、モジュールsvcrdmaとxprtrdmaは、Kernel 2.6.25以降から共にマージされています。Infinibandドライバをインストールして、必要な設定を行えば、NFS/RDMAを利用できます。今回、OFEDのホットスタック(バージョン3.12-1)を使用しました。

検証環境

  • HCA：Mellanox MHQ19B-XTR (QDR)
  • CPU：Xeon E5-2630V2 1つ搭載
  • マザーボード：Supermicro X9DRi-F
  • OS：CentOS6.4 x86_64
  • Infinibandドライバ：
    OFED-3.12-1
  • NFSサーバのシステムメモリ：64GB(64GBメモリ内1GBをシステムで利用し、残りはtmpfsで使用。tmpfsを/nfsへマウント。)
  • NFSクライアントのシステムメモリ：1GB
  • HCAポートにIPアドレスを設定
    NFSサーバIPアドレス 192.168.1.1
    NFSクライアン IPアドレス 192.168.1.2
  • NFSサーバ－NFSクライアント間は一対一で接続しました。

設定

  1. OFEDをNFSサーバとNFSクライアントへインストール
  2. NFSサーバの設定
    3. # mount -t tmpfs -o size=63g tmpfs /nfs
    # vi /etc/fstab
    ～
    /nfs 192.168.1.0/24(rw,sync,no_root_squash,fsid=0,insecure)
    ～
  3. NFSサーバ側RDMAモジュールの動作開始
    4. # modprobe svcrdma
    # service nfs start
    # echo rdma 20049 > /proc/fs/nfsd/portlist
  4. NFSクライアント側RDMAモジュールの動作開始とマウント
    5. # modprobe xportrdma
    # mount -o rdma,port=20049 192.168.1.1:/nfs /mnt

テスト方法

  • iozoneを利用し、2GBファイル(システムメモリの2倍サイズファイル)の書き出し/読み出し速度を計測。
    • # iozone -Ac -s 2g -f /mnt/file

    なお、NFSサーバで、/nfsへマウントしたtmpfsに対して、iozoneにより同じファイルサイズで速度を計測するとWrite 3GB/sec程度、Read 6GB/sec程度でした。

結果

レコードサイズ4k〜16MBまでの結果の平均値をグラフ化しました。(標準偏差はNFS/RDMA使用時、未使用時ともにWriteで90くらい、Readで25くらい。)

Writeにはあまり違いがありませんが、Readでは倍以上の差を得られました。
Writeでも、差がもっと出て欲しいのですが、NFS設定ファイルは初期設定のままでしたので、チューニングすることにより、結果が変わるかもしれません。

サーバの監視でIPMI2.0準拠のマネージメントコントローラを利用する

当社のサーバ/ワークステーション製品の多くで、IPMI2.0準拠のマネージメントコントローラを利用出来ます。

マネージメントコントローラはOSとは独立に動作し、CPU温度、ファン回転数の監視したり、リモートでサーバの電源制御などができ、専用LANポート（もしくは、共用LANポート）を介して利用します。

専用LANポートには、サーバ背面のI/Oシールドに”監視”と表記されたシールが貼っています。(ただし、シールを貼ることが出来ない製品には貼っておりません。)

マネージメントコントローラを利用するには、動的もしくは静的にIPアドレスを割り当てて利用します。また、各種IPMIソフトウェアに対応していますので、ソフトウェア(※1)をインストールすれば、ターミナルからも利用出来ます。

◎ ターミナルで状態を確認

# ipmitool sdr list

System Temp | 37 degrees C | ok
Peripheral Temp | 45 degrees C | ok
CPU Temp | 0 unspecified | ok
FAN 1 | disabled | ok
FAN 2 | 1050 RPM | ok
FAN 3 | disabled | ok
FAN 4 | disabled | ok
FAN A | 3075 RPM | ok
Vcore | 0.76 Volts | ok
3.3VCC | 3.39 Volts | ok
12V | 11.98 Volts | ok
VDIMM | 1.52 Volts | ok
5VCC | 5.22 Volts | ok
-12V | -11.71 Volts | ok
VBAT | 3.10 Volts | ok
VSB | 3.33 Volts | ok
AVCC | 3.39 Volts | ok
Chassis Intru |0 unspecified | ok

◎ イベントをsyslogへ出力

ipmievdを用いるとipmiのイベント出力をsyslogにも出力することが出来ます。

# service ipmievd start

テストイベントを発生させ、syslogへの出力を確認します。

# ipmitool event 1
Sending SAMPLE event: Temperature – Upper Critical – Going High
0 | Pre-Init Time-stamp | Temperature #0x30 | Upper Criti

# tail /var/log/messages
～
Jul 2 15:45:33 less01 ipmievd: Temperature sensor – Upper Critical going high
Jul 2 15:45:36 less01 ipmievd: Temperature sensor – Upper Critical going high
～

※1 CentOS6.5でのツールのインストールを例として紹介します。

A OpenIPMIとOpenIPMI-toolsをインストールします。

# yum install OpenIPMI OpenIPMI-tools

B ipmiを起動させます。

# service ipmi start
Starting ipmi drivers: [ OK ]

C ipmiの起動を確認します。

# service ipmi status
ipmi_msghandler module in kernel.
ipmi_si module in kernel.
ipmi_devintf module loaded.
/dev/ipmi0 exists.

D ipmievdを起動させます。

# service ipmievd start
Starting ipmievd: [ OK ]

E ipmievdの動作を確認します。

# service ipmievd status
ipmievd (pid 2753) を実行中…

F ipmiとipmievdをOS起動時に開始するように設定します。

# chkconfig | grep ipmi
ipmi 0:off 1:off 2:off 3:off 4:off 5:off 6:off
ipmievd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

# chkconfig ipmi on
# chkconfig ipmievd on

ZFS on Linuxの動作検証

先日、POWER MASTER NAS S9524での、OpenMediaVault動作確認を依頼された時のこと、…..。

OpenMediaVaultは Debian 6.0 (Squeeze)ベースのOSなので、Debian 6.0 (Squeeze)で動作実績のあるPOWER MASTER NAS S9524でも、動作することは予想出来ましたが、念の為に動作確認を行いました。同時にZFS on Linuxも動作検証を行いました。

OpenMediaVaultへのZFS on Linuxのインストールについては、Debian用ZFS on LinuxをOpenmediavaultフォーラムで紹介されていた方法で、インストール可能でした。しかし、ウェブベースの管理システムへの統合がされていないので、まだ、ウェブブラウザからはZFSボリュームを管理出来ない。ZFSは高性能なだけに、残念。

FreeNASでは以前から統合されているので、NAS専用OSですぐにでもZFSを利用したい方は、FreeNASをご検討ください。Openmediavaultには、今後に期待です。

ZFS on Linuxは、Debian 以外のLinuxディストリビューションにも対応していて、CentOSやUbuntuなどでも利用出来ます。現在(2014/07/01)、ZFS on Linuxのバージョンは0.6.3ですが、0.6.1リリース時にはデスクトップからスーパーコンピュータまで展開出来る重要な節目に達したとアナウンスされていました。

管理しやすいデバイス名(※ 1)をつけたり、アドバンスドフォーマットディスクを利用するときにはセクターサイズ指定(※ 2)を気をつければ、使えます！！

※ 1
通常、リムーバブルHDDトレイには番号が表記されているので、/etc/zfs/vdev_id.confを編集してデバイス名とリムーバブルHDDトレイの番号を紐付ければ、HDDの管理をしやすくなる。

# vi /etc/zfs/vdev_id.conf
alias HDD0 /dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:1:0
alias HDD1 /dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:2:0
alias HDD2 /dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:3:0
alias HDD3 /dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:4:0

※ 2
アドバンスドフォーマットディスクを使う時には、セクターサイズを指定して、zfsボリュームを作成する。

# zpool create -o ashift=12 tank raidz HDD0 HDD1 HDD2 HDD3

(4096セクターを利用したい場合には、 -o ashift=12 (2の12乗)を追加する。)

最後に、POWER MASTER NAS S9524で、Openmediavault 0.5.49の動作を確認出来ました。

HAクラスタ・NFSサーバでSTONITH機能の動作検証 (スプリットブレイン阻止)

POWER MASTER Server S4200には、3.5インチを4台と2.5インチを1台搭載でき、LANポートを4つとIPMI2.0準拠のマネージメントコントローラ用LANポートを1つ備えています。

S008 ラックマウント キットを使うと、1UスペースにPOWER MASTER Server S4200を2台搭載出来るので、HAクラスタ・NFSサーバを構築し、障害時の動作確認を行いました。

◎ 環境

ディスク構成

  • 120GB SSD x1台 (CentOS6.5 x86_64をインストール。)
  • 4TB HDD x4台 (ソフトウェアRAID5を構築。)

ネットワーク

  • bond0 (eth0とeth1でbond0を設定。)
  • eth2,eth3 (死活確認用。eth3はDRBD同期用も兼ねる。)
  • IPMIポート (STONITH機能で利用。)

HAクラスタ用ソフトウェア

ネットワーク構成図

想定した故障は、LANポート故障により2台のサーバ間で死活確認が出来なくなった場合で、その際、STONITH機能により実行されるスタンバイサーバ再起動の確認です。

構築したクラスタは、アクティブ/スタンバイ型のHAクラスタです。各サーバのeth2ポートとeth3ポートを利用して死活確認を行っています。

片方のサーバのeth2ポートとeth3ポート、server1のeth2ポートとserver2のeth3ポートなどいくつか組み合わせパターンが考えられますが、eth2ポートとeth3ポートが同時に正常に動作しなくなると、死活確認が出来なくなります。

死活確認が出来なくなっているだけで、アクティブサーバは停止しておらず、NFSサービスが継続して動作しています。

スタンバイサーバは、アクティブサーバが停止したと判断して、アクティブサーバへの昇格しようとします。もし、昇格するとサービスが二重起動するスプリットブレインが起きてしまいます。

スプリットブレインを防ぐために、STONITH機能によりアクティブサーバがスタンバイサーバを再起動させます。

以下は、pacemakerのCRM設定(一部)です。

～
primitive prmHelper1-1 stonith:external/stonith-helper ¥
params priority=”1″ stonith-timeout=”80s” hostlist=”server1″ dead_check_target=”IP addresses” run_standby_wait=”yes” standby_check_command=”/usr/sbin/crm_resource -r res_IPaddr2_1 -W | grep -q `hostname`” ¥
op start interval=”0s” timeout=”60s” ¥
op monitor interval=”10s” timeout=”60s” ¥
op stop interval=”0s” timeout=”60s” ¥
meta target-role=”started”
primitive prmIpmi1-2 stonith:external/ipmi ¥
params priority=”2″ stonith-timeout=”60s” userid=”ユーザーID” passwd=”パスワード” ipaddr=”IP address” hostname=”server1″ interface=”lanplus” ¥
op start interval=”0s” timeout=”60s” on-fail=”restart” ¥
op monitor interval=”3600s” timeout=”60s” on-fail=”restart” ¥
op stop interval=”0s” timeout=”60s” on-fail=”ignore” ¥
meta target-role=”started”
primitive prmMeatware1-3 stonith:meatware ¥
params priority=”3″ stonith-timeout=”600″ hostlist=”server1″ ¥
op start interval=”0s” timeout=”60s” ¥
op monitor interval=”3600s” timeout=”60s” ¥
op stop interval=”0s” timeout=”60s” ¥
meta target-role=”started”
group grpStonith1 prmHelper1-1 prmIpmi1-2 prmMeatware1-3
location loc-grpStonith1 grpStonith1 ¥
rule $id=”loc-grpStonith1-rule” -inf: #uname eq server1
～

簡単に設定した内容をまとめると、

  1. どちらのサーバがアクティブサーバであるか判定。(stonith:external/stonith-helperを利用。）
  2. アクティブサーバがスタンバイサーバを再起動させる。(stonith:external/ipmiを利用。)
  3. stonith:external/ipmiによりスタンバイサーバが再起動しない場合、サーバ管理者による再起動を求める。(stonith:meatwareを利用。)

となります。

◎ 動作確認

  1. server1側で、eth2ポートとeth3ポートに取り付けられているLANケーブルを抜く。(これにより死活確認が出来なくなります。)
    2.
  2. crm_monコマンドで、server2の再起動を確認。
    3.

アクティブサーバのeth2ポートとeth3ポートからLANケーブルを抜き取っても、STONITH機能によりスタンバイサーバの再起動が確認出来ました。また、HAクラスタ・NFSサービスも継続して動作していることを確認出来ました。

なお、実際に障害が起きた場合、故障箇所の特定には、サーバの動作ログなどの確認が必要となります。