「PCクラスタ」カテゴリーアーカイブ

AMD EPYC 7501 + 32GB DDR4-2666 性能評価

1CPU当たり32コアを持つEPYC 7501 x 2個と、32GB DDR4-2666 x 32枚（合計1024GB）を搭載するシステムPOWER MASTER Server S5081にて、姫野ベンチマークによる計測を行ってみました。

ちなみに、AMD EPYCには8coreのダイが4つパッケージに入っていて、各々のダイにはメモリ2chとPCIE x16 2本が接続できる構成となっているとのこと。1CPUでメモリ8chとPCIE x16 8本も持っているのです。

【環境】

【テスト】

① シングルスレッド評価

② マルチスレッド評価

【結果】

[TABLE=26]

[TABLE=27]

(SMT: Simultaneous MultiThreading)

Xeon E5-2680v4とEPYC 7501のシングルスレッド値で比較すると、 EPYC 7501は、Xeon E5-2680v4よりも約1.35倍の高い結果となっています。

並列計算でもスレッド数64で良い結果となっていますが、スレッド数128では値が少し下がっていて、このあたりがメモリ帯域の限界ではなかろうか？

いずれにしても、すでに持っているバイナリ（アプリケーション）で、パフォーマンス向上を目指すならば、AMD EPYCは良い選択肢となるかもしれません。

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クラスタ用ソフトウェア

DRBD8.4
Pacemaker+Heartbeat (Pacemakerリポジトリパッケージ (RHEL6) (1.0.13-1.2))

ネットワーク構成図

想定した故障は、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
～

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

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

となります。

◎ 動作確認

server1側で、eth2ポートとeth3ポートに取り付けられているLANケーブルを抜く。(これにより死活確認が出来なくなります。)

crm_monコマンドで、server2の再起動を確認。

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

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

Intel Xeon Phi

いよいよIntel Xeon Phiが近づいてきました。
HPC向けの位置付けはNvidia Teslaなどと同じですが、phiはx86アーキテクチャという特徴があります。
GPGPUへの移行を躊躇していたユーザさんの考え方も変わるかもしれませんね。
phiは、PCI Express 3.0 へ接続する方式です。この点はTeslaとも同様です。
このあたり参考になります。

Gluster ベンチマーク

分散ファイルシステムが注目されています。
複数の実装がありますが、今回はGlusterを動かしてみました。
Glusterは、クラウド環境やHPC環境にも使える分散ファイルシステムです。
ローカルファイルシステムをエクスポートし、メタデータサーバが存在しないのも大きな特徴です。
今回は、かなりリッチな環境なので、参考程度にしかならないかも。。。

■テスト環境
●Glusterサーバ 3台
CPU: x5675 2個
MEM: 72GB
RAID: Areca 1280
HDD: 3TB 24台 RAID6
Infinband: Mellanox_QDR
Ethernet: Intel 82574L

OS: Centos 5.5 x86_64
Local Filesystem: XFS
DFS: Gluster 3.2.4

●Glusterクライアント 3台
CPU: x5675 2個
MEM: 72GB
HDD: 2TB 1台 OS用
Infinband: Mellanox_QDR
Ethernet: Intel 82574L

OS: Centos 5.5 x86_64
MPI: mpich2, mvapich2
Benchmark: IOR

ベンチマークは、IORを使いました。
IORは、分散ファイルシステム向けのベンチマークプログラムです。
特徴としては、MPIを使った並列プロセスからのI/O測定ができます。
測定結果は最大値で出てくるようです。（Max Write, Max Read）
IORのパラメータが妥当かどうか？の問題がありますが、ネット上にあった情報を元にして実行しました。
使ってみてわかったのですが、IORは実行側ホストのキャッシュをほとんど使わないようです。
比較は以下としました。

Gigabit ストライプ型(72GBメモリ) VS infiniband ストライプ型(72GBメモリ)
infiniband ストライプ型(2GBメモリ) VS infiniband ストライプ型(72GBメモリ)
infiniband ストライプ型(72GBメモリ) VS infiniband 分散型(72GBメモリ)
infiniband ストライプ型(2GBメモリ) VS infiniband 分散型(2GBメモリ)
infiniband ストライプ型(72GBメモリ 36プロセス) VS infiniband ストライプ型(72GBメモリ 72プロセス)
infiniband ストライプ型 3台(72GBメモリ 36プロセス実行) VS infiniband ストライプ型 2台(72GBメモリ 36プロセス実行)

■fuseについて
Glusterはfuseを使いマウントをしている。
fuseはOS標準を使うことができるが、glusterからチューニングされたfuseが入手できる。

72プロセスにすると、infinbandでもMax Writeの値がだいぶ落ちてくる。
これでfuseの差が出るかを見てみる。

●fuseは、centos標準
# mpiexec -launcher rsh -f mvapich2host -n 72 /home/work/bin/IOR -a MPIIO -b 4g -t 4m -i 1 -F -o /gluster/output
結果（Infinband）
Operation Max (MiB) Min (MiB) Mean (MiB) Std Dev Max (OPs) Min (OPs) Mean (OPs) Std Dev Mean (s)Op grep #Tasks tPN reps fPP reord reordoff reordrand seed segcnt blksiz xsize aggsize
——— ——— ——— ———- ——- ——— ——— ———- ——- ——-
write 233.77 233.77 233.77 0.00 58.44 58.44 58.44 0.001261.54440 72 24 1 1 0 1 0 0 1 0 4194304 309237645312 -1 MPIIO EXCEL
read 2829.12 2829.12 2829.12 0.00 707.28 707.28 707.28 0.00 104.24172 72 24 1 1 0 1 0 0 1 0 4194304 309237645312 -1 MPIIO EXCEL

Max Write: 233.77 MiB/sec (245.13 MB/sec)
Max Read: 2829.12 MiB/sec (2966.54 MB/sec)

●fuseは、gluster-fuse
# mpiexec -launcher rsh -f mvapich2host -n 72 /home/work/bin/IOR -a MPIIO -b 4g -t 4m -i 1 -F -o /gluster/output
peration Max (MiB) Min (MiB) Mean (MiB) Std Dev Max (OPs) Min (OPs) Mean (OPs) Std Dev Mean (s)Op grep #Tasks tPN reps fPP reord reordoff reordrand seed segcnt blksiz xsize aggsize
——— ——— ——— ———- ——- ——— ——— ———- ——- ——-
write 262.79 262.79 262.79 0.00 65.70 65.70 65.70 0.001122.22525 72 24 1 1 0 1 0 0 1 0 4194304 309237645312 -1 MPIIO EXCEL
read 2814.13 2814.13 2814.13 0.00 703.53 703.53 703.53 0.00 104.79704 72 24 1 1 0 1 0 0 1 0 4194304 309237645312 -1 MPIIO EXCEL

Max Write: 262.79 MiB/sec (275.56 MB/sec)
Max Read: 2814.13 MiB/sec (2950.82 MB/sec)

Max Writeが12%程度上がった。
fuseはOS標準のfuseよりGlusterからダウンロードしたものを使うのが良い。

■ベンチマーク
———-
Gluster ストライプ型 (ethernet gigabit)
ファイルサーバメモリ72GB
MPIライブラリ mpich2

[work@gluster5 ~]$ mpiexec -launcher rsh -iface eth0 -f mpich2host -n 36 /home/work/bin/IOR -a MPIIO -b 4g -t 4m -i 1 -F -o /gluster/output
IOR-2.10.2: MPI Coordinated Test of Parallel I/O

Run began: Mon Dec 19 12:49:50 2011
Command line used: /home/work/bin/IOR -a MPIIO -b 4g -t 4m -i 1 -F -o /gluster/outputMachine: Linux gluster5

Summary:
api = MPIIO (version=2, subversion=2)
test filename = /gluster/output
access = file-per-process
ordering in a file = sequential offsets
ordering inter file= no tasks offsets
clients = 36 (12 per node)
repetitions = 1
xfersize = 4 MiB
blocksize = 4 GiB
aggregate filesize = 144 GiB

Operation Max (MiB) Min (MiB) Mean (MiB) Std Dev Max (OPs) Min (OPs) Mean (OPs) Std Dev Mean (s)Op grep #Tasks tPN reps fPP reord reordoff reordrand seed segcnt blksiz xsize aggsize
——— ——— ——— ———- ——- ——— ——— ———- ——- ——-
write 203.89 203.89 203.89 0.00 50.97 50.97 50.97 0.00 723.22218 36 12 1 1 0 1 0 0 1 0 4194304 154618822656 -1 MPIIO EXCEL
read 209.22 209.22 209.22 0.00 52.30 52.30 52.30 0.00 704.80554 36 12 1 1 0 1 0 0 1 0 4194304 154618822656 -1 MPIIO EXCEL

Max Write: 203.89 MiB/sec (213.79 MB/sec)
Max Read: 209.22 MiB/sec (219.38 MB/sec)

Run finished: Mon Dec 19 13:13:56 2011

———-
Gluster ストライプ型 (infiniband QDR)
ファイルサーバメモリ72GB
MPIライブラリ mvapich2