ISC 2015では18件のポスター発表が行われ、その中で、理研AICSの庄司氏の「Long term failure analysis of 10 petascale supercomputer」がアジア最優秀ポスター賞を受賞し、記念講演が行われた。
おさらいであるが、京コンピュータは、82,944個のSPARC64 VIIIfxプロセサを使い、1.27PBのDIMMを搭載する巨大システムである。それに11PBのローカルファイルシステム(LFS)と30PBのグローバルファイルシステム(GFS)が付いている。
基本的な単位は4ノードを搭載するシステムボードで、これが1つのラックに24枚収容されている。このラックが864本あり、全体で20,736枚のシステムボードが使われている。システムボードには4個のCPUと4個のインタコネクトコントローラ(ICC)LSIが搭載されているので、CPUの総数は82,944個、ICCの総数も82,944個である。メモリのDIMMはCPU当たり8枚で、総数は663,552枚である。
京コンピュータが本格運用を開始した2012年9月28日から2015年6月30日までの稼働で、平均的には1日に109.4ユーザからの1193.2ジョブを処理してきた。下のパイチャートに見られるように、2001~5000ノードを使用するジョブが26.1%で最も多い。利用分野としては物質科学が28.9%と最多で、製造関係が19.4%、ライフサイエンスが17.6%、物理関係が14.7%、環境関係が13.2%と続いている。
次の図は運用開始からの月別のCPUの故障率を示している。フルノードを使用するLINPACK性能の測定と、Gordon Bell賞を狙う巨大ジョブの実行時には故障率が跳ね上がっているが、それ以外では0.004%程度の故障率で概ね安定している。なお、0.004%というと、毎月3.3個の故障であり、9日に1個という感じである。
DIMMの月別の故障率は、2013年6月以前は平均的に0.0016%であったが、ここで空調を改善して冷気の吹き出し温度を21℃から18℃に変更した後は、0.001%と故障率が下がっている。
この0.0001%の故障率は毎月66.6DIMMの故障であり、1日2.2枚程度という頻度である。メインメモリにはECCが付いているので、この故障はただちにノードの故障には繋がっていない。
システムボードの月別の故障率は次の図のようになっている。当初は0.15%程度の故障率であったが、徐々に低下し、現在では0.05%程度でほぼ安定している。しかし、CPUとDIMMの故障率はこのような漸減傾向を示しておらず、何故、システムボードの故障率が徐々に下がるのかは庄司氏の発表からはよく分からなかった。後述のLFSのソフトのバグの修正などの要素があるのではないかと思われる。
これを、故障率に関する論文が発表されているBlue Watersスパコンと比較すると、京コンピュータはCPUの故障率では約1/4、DIMMの故障率では約1/7となっている。但し、DIMMは容量が違うので、GBあたりの故障率で見ると1/2ということになる。
全体の93.59%の時間、システムは稼働しており、これに定期点検のための運用停止が4.19%あるので、故障による停止は2.23%である。中央のパイチャートがシステム停止の原因の内訳で、LFSの故障が全体の62%を占めている。これに続いて14%程度をGFSの停止が占めており、全体の3/4がファイルシステムの故障がシステム停止の原因となっている。
そして、右のパイチャードであるが、LFSの故障の40.7%はシステムソフトウェアのバグが原因となっている。一方、ディスクの故障は17.5%であり、原因調査中の13.3%を加えてもハードウェアの故障は全体の30%を超えないと思われる。
LFSの故障の考察であるが、LFSは高いバンド幅を実現するためにOSS(Object Storage Server)が2592台、OST(Object Storage Target)が5184ディスクという規模で単一のボリュームを構成しており、並列アクセスの制御が複雑である。このため、潜在的なバグが残ってしまった。
そして、LFSが止まると、システムが止まってしまうので、システムダウンの観点からはシングルポイント故障となっている。
まとめとして、京コンピュータはCPUの故障率としてはBlue Watersと比較して1/4、DIMMのGBあたりの故障率では1/2を実現している。システムの可用性は93%を超えており、CPUやICCの水冷と低温の空調が故障率を減らすことに貢献していると考えられる。
反省点としては、LFSの故障が稼働率を下げる主因になっており、巨大な単一ボリュームのシステムはバグが残りやすいので、避けるべきである。その単一ボリュームがソフトエラーで止まると、システム全体のダウンに繋がるという設計は避けるべきであるという。