技術情報」カテゴリーアーカイブ

Intel Xeon D搭載システム 姫野ベンチマーク評価

2015年5月に弊社でも販売を開始しましたIntel Xeon D搭載システムを姫野ベンチマークにて評価しました。

【環境】

  • CPU:Inte(R) Xeon(R) processor D-1540 (2.00GHz、8core)
  • メインボードSupermicro X10SDV-TLN4F
  • チップセットSystem on Chip
  • メモリ32GB(8GB DDR4-2133 ECC REG ×4)
  • OSCentOS7.1 x86_64
  • GNUコンパイラ:GCC 4.8.3
  • Intelコンパイラ:Parallel Studio XE 2015 Composer Edition for C++ Linux 15.0.3
  • OpenMPI:1.8.5
  • Intel(R) MPI Library:Version 5.0 Update 3
  • 姫野ベンチhimenoBMTxp_l size L
  • 姫野ベンチ並列バージョン:cc_himenobmt_mpi size L
※以下スコアは全て測定回数5回の平均値です。

①シングルスレッド評価

姫野ベンチ(himenoBMTxp_l)を各コンパイラにてコンパイルし測定しました。

コンパイラ スコア
gcc 3014.4 MFLOPS
icc 5388.6 MFLOPS

以前測定したIntel Xeon E5-2687W(3.1GHz)のスコア3525 MFLOPSと比較しても非常に高いスコアといえます。姫野ベンチはメモリに依存しているベンチマークですので、メモリがDDR3からDDR4になったことでスコアが大きく延びていると考えられます。また、インテルコンパイラではgccの約1.8倍のスコアとなりましたのでインテルコンパイラの使用が非常に有効といえます。

②マルチスレッド評価

コンパイラとMPIライブラリを組み合わせて姫野ベンチ並列バージョン(cc_himenobmt_mpi)をコンパイルし測定しました。

スレッド数 gcc+OpenMPI icc+Intel MPI
シングル 2995.6 MFLOPS 5346.2 MFLOPS
8 12672.6 MFLOPS 12939.4 MFLOPS
16(HyperThreading on) 11318.6 MFLOPS 12301.6 MFLOPS

両組み合わせにおいてシングルスレッドでは前項目のシングルスレッド評価と同等の信頼できるスコアが確認できます。8スレッドでは12600~12900 MFLOPS程度、「HyperThreading on」の16スレッドでも11300~12300 MFLOPS程度と12000 MFLOPS付近にてスコアが収束しているように見えます。

確認の為、「icc + Intel MPI Library」にて2~4スレッドの測定も行いました。

スレッド数 icc+Intel MPI
1 5346.2 MFLOPS
2 9894.2 MFLOPS
3 12003.6 MFLOPS
4 13248.0 MFLOPS

2スレッドではリニアに数値が倍増しているといえますが、3スレッドで既に収束範囲に到達しています。これも、姫野ベンチがメモリに依存しているベンチマークであるため、3スレッド以降ではメモリ帯域を使い切ってしまい収束範囲に達してからはスコアが伸びなくなったと考えられます。

【総評】

Supermicro X10SDV-TLN4Fに搭載のIntel Xeon D-1540は組込CPUに分類されますが、シングルスレッドのスコアでは、2世代前のワークステーション用CPUに迫るスコアを記録しました。マルチコア(8コア)CPUですので、メモリ帯域を多く使用しないプログラムであればマルチスレッドで性能が発揮されると期待できます。

以上、Intel Xeon D搭載マシンの姫野ベンチマーク評価でした。

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)
  4. NFSサーバ側RDMAモジュールの動作開始
  5. # modprobe svcrdma
    # service nfs start
    # echo rdma 20049 > /proc/fs/nfsd/portlist
  6. NFSクライアント側RDMAモジュールの動作開始とマウント
  7. # 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の動作を確認出来ました。