[目次] [1ページ目] [前ページ] [次ページ] [質疑応答]

理研スーパー・コンバインド・クラスタ(RSCC)の紹介と運用事例


  1. はじめに
  2. リプレースの背景
  3. システム構成
  4. システムの特徴
  5. RSCCにおける問題点     
  6. システムの性能
  7. 利用状況と障害件数
  8. おわりに
写真

独立行政法人理化学研究所 情報基盤センター
重谷 隆之

プレゼンテーション資料[PDF:1MB]

理化学研究所では、今年3月に2048CPUのLinux PC(Intel Xeon 3.07GHz, Dual CPU)を中核としたスーパーコンピュータシステム(理研スーパー・コンバインド・クラスタ:RSCC)を導入した。日本の計算機センターではLinuxクラスタの採用は初めてのことである。RSCCにはいくつかの新しい技術を導入している。本発表では、センターの計算機としてLinuxクラスタを採用した背景、システム設計における新しい試み、実際の運用形態と利用状況などを紹介する。

1. はじめに

理化学研究所・情報基盤センターでは、理研の研究支援を目的としてスーパーコンピュータ(スパコン)の導入・運用を行っている。これまでのスパコンとしては、1994年からベクトル並列型計算機を採用してきたが、今年の3月にベクトル並列計算機単一システムではなく、1024台のPCで構成した大規模Linuxクラスタと大容量メモリが利用可能なSX-7という2種類の計算資源を備えたシステム:理研スーパー・コンバインド・クラスタ(RSCC)を導入した。

2. リプレースの背景

ベクトル並列計算機から大規模Linuxクラスタを中心としたシステムへ大きく変更した背景には、情報基盤センターでのLinuxクラスタ・システムに関する調査・テストの結果、センターマシンとして十分な性能を発揮できると判断したことにある。また、旧システム(VPP700E/160)の利用状況、利用者からの要求などを踏まえた結果、出来るだけコスト性能比が良く、多くのフリーソフトが利用でき新規の研究分野の利用者を開拓できる環境を目指した。その結果、大規模Linuxクラスタを中心とし、さらに1CPUで大容量のメモリが利用できる環境として、大容量メモリ計算機(SX-7)を合わせた複合システムとした。

3. システム構成

RSCCのLinuxクラスタは、1024台(2048CPU)のPC(計算ノード)で構成されている。これらを1つのクラスタとするのではなく、512ノード(1024CPU)、128ノード(256CPU)×4という5つのサブ・システムに分割している。更に、理研で開発された分子動力学専用ボード(MDGRAPE-2)を20枚搭載した64ノード(64CPU)のLinuxクラスタをあわせて、6つのサブ・システムに分割している。これらのLinuxクラスタでは、MPIなどによる並列化されたプログラムを実行することを想定している。また、128台のサブ・システムは占有利用も可能としている。ジョブ実行時間は、これまでのVPP700E/160では最大でも50時間だったが、CPU数が劇的に増加したためRSCCのLinuxクラスタでは最大1週間のジョブクラスも用意している。RSCCにはLinuxクラスタ以外にアーキテクチャの異なるSX-7も配置している。SX-7は、共有メモリ型のベクトル計算機なので、並列化できないプログラムで大きなメモリを必要とするプログラムやベクトル・チューニングされたプログラムの実行を想定している。またVPP700Eで利用していたプログラムで、すぐにLinuxクラスタに移行できない場合には、このSX-7を"とりあえず"利用してもらい、将来的にはLinuxクラスタへ移行してもらう。つまり、VPP700EからLinuxクラスタへの中継的な役割と位置づけている。

4. システムの特徴

複数のサブ・システムで構成したRSCCでは、利用者の利便性やシステムの拡張性を考慮した設計を行い、新しい試みを行っている。


5. RSCCにおける問題点

実際に運用を開始して浮上してきた問題を2つ紹介する。1つは1ノードに2CPU搭載したSMPの計算ノードにおいて、計算リソースが効率的に利用出来ない。つまり、並列化されていない1つのジョブが1ノードを占有して、1CPUずつ利用することが出来ないという問題がある。Linuxクラスタで実行するジョブは、主に並列ジョブであると想定していたが、実際には並列化されていないジョブを高スループットで実行したいという要望が予想以上に多かった。この問題はバッチ・ジョブ・スケジューラとして採用した富士通製NQSの修正により解決の目処が立っている。
2つめは、ジョブ凍結機能の問題である。RSCCのLinuxクラスタでのジョブ凍結は、SCoreの機能を利用している。そのため、ジョブ凍結を可能とするためにはいくつかの制限がある。実際の運用でジョブ凍結に成功したのは、実行中のジョブの1割程度であった。ジョブ凍結できなかった原因については現在調査中であるが、将来的にはジョブ凍結の制限事項を減らす必要があると考えている。

6. システムの性能

システムの実効性能の例として、「姫野ベンチマーク」と「LINPACKベンチマーク」を用いた結果を紹介する。姫野ベンチマークは、非圧縮性流体解析ソフトのカーネルを抜き出したベンチマーク・プログラムで、非常に簡単なソースコードとなっている。Webページ(http://accc.riken.jp/)からは、オリジナルに以外にも、MPIやVPP Fortran(XP Fortran)により並列化したバージョンもダウンロードが可能である。今回は、MPIとXP Fortranにより並列化されたものを用いた実効性能を示した。特にMPIバージョンでは、計算サイズを変化させ、インターコネクトとしてInfiniband(IB)とMyrinetを用いたときの性能を256CPUまで示した。ネットワーク帯域の理論値はIBが片方向8Gbps、Myrinietが片方向2GbpsとIBの方が有利であるが、レイテンシーはMyrinetの方が僅かに小さい。計算サイズが小さい場合、各計算用PCが担当する計算量に比べてデータ通信量の比率が大きいので、並列度(利用CPU数)を大きくしていくと、レイテンシーの小さいMyrinetの方が高い実測値を出すことがわかる。そのため、大規模な計算量で通信量が多い場合、IBを用いたが方が良い。実測値をみると、256CPU用いた場合に約100GFLOPSと非常に高い性能を示している。
次に、VPP Fortranバージョンの姫野ベンチマークを用いて、XP Fortranの性能を測定した。RSCCの計算用PCは1ノードあたり2CPU搭載している。並列計算は2CPU/1nodeを使用して計算を実行させているが、XP Fortranの場合2CPU/1nodeでジョブを実行するより、1CPU/1nodeで実行する方が高性能なことが分かる。これは、VPP システムのDTU(ハードウェア)が行っていたデータ通信処理を、XP Fortranではソフトで処理するために、データ通信用のスレッドがCPU資源を必要とするからである。データ通信用スレッドのために、ベンチマークを1CPU/1nodeで実行した結果は、VPP700E/160の結果より高い性能を示している。
TOP500リスト(
http://www.top500.org/)を決定するために用いられているLINPACKベンチマークの測定では、5つに分割したLinuxクラスタ全てを用いて、1024台(2048CPU)での測定を行った。各Linuxクラスタ内はIBもしくはMyrinetを利用し、各クラスタ間は、16node単位でGigabit Ethernetを利用するように工夫して測定を行った。その結果、8.728 TFLOPSという非常に高い結果を出し、6月に発表されたTOP500では7位にランクされた。今回のLINPACK測定では、異なるネットワークを備えた複数のLinuxクラスタを同時に利用した初めての試みということで、高い評価を受けた。

7. 利用状況と障害件数

3月に運用を開始したRSCCの利用状況を、各サブ・システムごとに紹介する。導入直後ということもあり、平均して50%前後のCPU利用率は比較的良いスタートである。3月から5月までの3ヶ月間はテスト運用を行った。6月からの本運用では、「スパコン課題審査委員会」による審議の結果、許可された申請者だけが利用出来ることになっている。本運用開始にあたってシステム設定の変更などを行ったために、6月当初は利用率が一時的に低迷したが、7月に入ってからは徐々に上昇してきている。今後情報基盤センターでは、ユーザー教育・プログラム相談などのサポートを強化するだけでなく、MPI、スカラーチューニング、可視化などの講習会の実施や、潜在的な利用者を発掘するための「プログラム高速化・並列化支援」、「プログラム高度化支援」などのサービスを強化していく予定である。
次に、Linuxクラスタを計算機センターで運用する上で重要となる、ハードウェア故障について報告する。RSCCでは、システムの状態把握を目的としたログの収集と、障害検知を目的とする自動監視を行っている。ログの収集には、理研で開発したログ収集&解析ソフト「Pitsaw」と、Linuxクラスタに実装されているハードウェア「IPMI(Intelligent Platform Management Interface)」の2つにより行っている。また、障害検知のための監視は、ハードウェア、ネットワーク、OS、ミドルウェア、ソフトウェアなど様々なレベルで行い、障害検知を行っている。
実際に起こったハードウェアの故障台数は、3月からの約5ヶ月間で33台であるが、全て個々の計算用ノードでの障害であったため、全システム停止ということは無い。また、33台のうち、19台の故障はLINPACK測定中に起こったものである。事後の調査によりそのうちの16台のハードウェアには潜在的な問題があったことが判明し、まだ故障していないハードウェアも全て予防交換した。また、実際に障害は起こらなかったが、IBのケーブルに潜在的な問題があることも判明し、512ノード(1024CPU)のサブ・クラスタのIBケーブル1024本のうち半分を予防交換した。

8. おわりに

これまで運用してきたベクトル型並列計算機から大規模Linuxクラスタを中心とした複合システムへのリプレースは、我々にとって大きな挑戦であった。日本で初めて計算機センターのマシンとしてLinuxクラスタの採用であればなおさらである。そのため、RSCCの設計においては、不足していた機能を補い利便性を高めるために、いくつもの新しい機能と試みを取り入れた。導入後のベンチマークによる実効性能は非常に高く、ハードウェア障害も予想以上に少なく安定稼動している。しかし、バッチ・ジョブ・スケジューラの修正、ジョブ凍結機能の改善などという課題が残っている。これらの課題を克服し、RSCCとしてのより効率的なシステム運用を可能とし、利用者の研究活動を支援するシステムを目指していきたい。


[目次] [1ページ目] [前ページ] [次ページ] [質疑応答]