Titanの故障の分析について発表するORNLのDevesh Tiwari氏

Oak Ridge国立研究所(ORNL)のTitanスパコンは、TOP500で2位の大型スパコンである。SC15において、このTitanの故障を分析した論文をORNLのDevesh Tiwari氏が発表した。

エクサスケールのスパコンでも数10時間以上かかる計算がある。しかし、エクサスケールの大規模ハードウェアは数時間に1回程度の頻度で故障して計算が中断されると予想される。このような計算を最後まで実行するためには、定期的に中間結果をストレージに書き出し、故障が起こると、故障前の中間結果をストレージから読み出して状態を復元し、そのエラー発生以前の状態に戻って計算を再実行するチェックポイント-リスタートという方法が取られる。

このためには、チェックポイントとなる中間結果を故障頻度よりかなり頻繁に書き出して置く必要がある。チェックポイントのデータ量はアプリに依存するが、エクサスケールのアプリでは0.1~1PBになり得る。例えば1PBのデータを10分ごとに書き出すとなると、平均1.7TB/sのバンド幅が必要になる。これは1.7GB/sで書き込めるSSDであっても1000台を並列に動作させる必要がある。また、チェックポイントの書き出し中は、計算が進められないとすると、少なくともこの2倍くらいのバンド幅がないと、チェックポイントを書き出しているのが主な仕事というマシンになってしまう。

また、故障した時に、故障ノードを修理しないと計算を再開できないのでは、ダウンタイムが長くなりムダが多い。このため、ネットワークの切り替えで、故障ノードを外し、予備ノードを組み込む。しかし、この時にチェックポイントを格納したSSDが故障ノードと共に切り離されてしまってはダメで、新たに組み込まれるスペアノードからチェックポイントを格納したSSDの読み出しができなければならない。

このように、原理的には単純なチェックポイントの作成、読み出し再開も容易ではなく、チェックポイントのI/Oのオーバヘッドをできるだけ減らすことが重要であるという。

天体物理、気象、燃焼などのアプリケーションでは定期的にチェックポイントを書き込むことが必要。エクサスケールアプリでは、最大60%の計算時間がチェックポイントの作成に使われてしまう

Titanシステムと検出するGPUエラー

Titanの計算ノードは16コアのAMD Opteron CPUとNVIDIAのK20X GPU各1個で構成されており、システム全体は18,688ノードで構成されている。この構成では、浮動小数点演算能力の大部分はK20X GPUが担っているので、この論文ではGPUのエラーだけを対象にしている。

GPUのエラーは、ハードエラーとソフト/ファームのエラーがあり、どのエラーが発生したかはXIDというコードで通知される。

GPUのハードエラー(上)とソフト/ファームエラー(下)のリスト。すべてのエラーがアプリのクラッシュやノードのリブートを惹き起こすわけではない (出典:SC15でのTiwari氏の発表論文)

次の3つの棒グラフは、CPU 2ビットエラー、Off the busエラー(ホストとの通信の途絶)、DPR(ECC Page Retirement)エラーの1カ月間の発生回数を示すものである。Off the Busエラーは稼働の初期にはかなり発生していたが、コネクタ接続をはんだ付けに変更して以来、ほとんど発生していない。また、DPRエラーは、1ページの中で、2ビットエラーあるいは1ビットエラーが2回起こったことを示すもので、そのページを切り離して使用しないようにする。しかし、エラーとしては、2ビットエラーは別途検出されており、2回の1ビットエラーはアプリケーションのクラッシュを惹き起こすものではないので、この記事では、詳しくは取り上げない。また、ソフト/ファームウェアのエラーについても割愛する。