（様式 20）成果報告書

TSUBAME 共同利用 平成 27 年度 学術利用 成果報告書

利用課題名 スペアノードを用いた実行継続手法の通信性能評価
英文：Performance Evaluation of Spare Node Substitution
利用課題責任者 堀敦史
First name Surname Atsushi Hori
所属 理化学研究所 計算科学研究機構
Affiliation RIKEN Advanced Institute for Computational Science

邦文抄録（300 字程度）
ハードウェア規模の増大するエクサスケール環境では、故障発生率が増加するため、耐故障性の確保が重要である。我々はステンシル計算に対する故障復帰手法として、スペアノードを用いた手法の検討と評価を進めている。
スペアノードを用いた実行継続では、アプリケーションプログラムへの大きな変更無しにロードバランスを維持した実行継続が可能な一方、通信経路が変化することにより、通信性能が低下することを確認している。これまで我々は
Mesh/Torus ネットワークトポロジにおいて、スライド手法での実行継続後の通信性能の評価を行ってきたが、本課
題では、Fat Tree ネットワークトポロジを持つ TSUBAME2.5 を用いて評価を行った。
英文抄録（100 words 程度）

With the increasing fault rate on high-end supercomputers, the topic of fault tolerance has beengathering attention. We proposed failure recovery method using spare node for stencil application
named “sliding methods”. The sliding methods preserve load balancing and communication
pattern, however, communication performance is degraded on Mesh/Torus network topology. In
this project, we evaluated the sliding methods on TSUBAME2.5 having Fat-Tree network
topology.
Keywords: ５つ程度
fault tolerance, fault mitigation, spare node, communication performance
背景と目的ペアノードを利用したスライド手法の提案を進めてきた。

エクサスケール環境では構成するハードウェアが増スペアノードを利用することで、プログラムへの大きな大するために故障発生率が増加し、耐故障性の確保変更をすることなくロードバランスと論理的な通信パタが重要な課題となる。現在広く利用されているチェックーンを保った実行継続が可能となる。しかしその一方で、ポイント/リスタートによる実行継続は、規模の増大するネットワーク的に離れたスペアノードを利用することで、エクサスケール環境では I/O 時間が長期化するために物理的な通信経路が変化し、通信衝突の発生による通現実的ではないと言われており、ユーザレベルでの耐信性能の低下が生まれることが判明している。これま故障性の確保が注目されている。

でに我々は、Mesh/Torus ネットワークトポロジ上でのユーザレベルでの故障対策を実現するために、プログラム内での故障検知と挙動の定義が可能な ULFM

スライド手法について、その有効性を検討するために通信性能の評価を進めてきた。のようなライブラリの研究が進められている。しかしそ本プロジェクトでは、Mesh/Torus と並び並列計算機の一方で、実際にその研究成果を用いてどのように実で利用されるネットワークトポロジである Fat Tree ネッ

行を継続することが効率的であるかについては、あまりトワークトポロジを持つ TSUBAME2.5 を利用し、Fat研究がなされていないというのが現状である。

Tree ネットワークトポロジでのスライド手法の有用性をそこで我々は、ULFM のようなユーザレベルでノード検証するため、実行継続後の通信性能を評価した。

故障への対応を可能とするライブラリを用いた効率的

Thin ノードを最大 343 ノード用い、スライド手法によるな故障復帰手法として、ステンシル計算を対象とし、ス実行継続後の通信性能を測定した結果、

（様式 20）成果報告書
TSUBAME2.5 ではどの手法を用いた場合にも故障前のように利用し故障ノードと代替するか、その方式に大からの通信性能の低下は発生しないことを確認した。

きく依存する。我々はスペアノードの利用方式として、スライド手法を提案している。以下に基本となる nDSliding 手 法 と 、 そ の 組 み 合 わ せ で あ る Hybrid

概要
本課題では、我々が検討と評価を進めているスペアSliding 手法について簡単に示す。

ノードを用いた実行継続手法について、Fat Tree ネット
ワークトポロジを持つ TSUBAME2.5 を用いて評価を（手法の図を入れる）行った。
スペアノードを用いた実行継続では、アプリケーショ

スペアノードを利用した故障復帰は、故障の前後でノンプログラムへの大きな変更無しにロードバランスを維ードの物理的な配置が変更されることによって通信経持した実行継続が可能な一方、通信経路が変化するこ路が変化する。Mesh/Torus ネットワークトポロジ上でとにより、通信性能が低下することを確認している。 図のステンシル計算に適用した場合、故障前には存在し1 は、2D Mesh ネットワーク上での 5 点ステンシル計算なかった通信経路の共有が発生し、メッセージ衝突にプログラムの、スペアノードを利用した故障復帰例であより通信性能が低下する可能性がある。一方、スペアノり、最上行のノードがスペアノードである。故障前の状ードを利用したスライド手法を Fat Tree ネットワークト態(a)では、通信は衝突せずに行われているが、故障ポロジに適用した場合、故障前後でノードの配置は変後にスペアノードを用いて実行継続した例の(b)では、更されるが、トポロジの特性上通信経路の衝突は発生通信経路が変更となり、丸で囲んだ部分において通信しない。そのため Mesh/Torus ネットワークトポロジ上で衝突が発生しており、通信性能が低下する可能性があスライド手法を適用した場合とは異なり、スペアノードをる。

利用した故障復帰後も通信性能は変化しないと考えられる。また，この特徴は代替先ノードの配置によらず保たれるため、どの Sliding 方式を用いたとしても性能に差は現れないと考えられる。そこで、TSUBAME2.5 上でスライド手法を適用した場合の故障復帰後の通信性能について、通信実験を行い評価した。

結果および考察TSUBAME2.5 を用いて、スライド手法による実行継(a) 故障前の通信

続 後の 通 信 性 能 評価 を 行 った 。 評価 に は 4x4x4、5x5x5、7x7x7 の三次元形状のジョブを利用し、スペアノードは 3D(2,1)方式と呼んでいる、X または Y 座標が最大となる 2 平面に確保する形をとった。なお、ジョブの形状による差異がほぼ見られなかったため、以降の評価結果は 5x5x5 のものだけを示す。評価対象の通信パターンとして 7 点ステンシル計算における通信パターンと Barrier、Allreduce の 2 種類の集団通信を、実(b) 故障復帰後の通信
図 1 スペアノードを利用した故障復帰
故障復帰後の通信衝突の発生は、スペアノードをど行継続手法として 0D 及び Hybrid の 2 手法を利用した。また、Mesh/Torus ネットワークトポロジとの比較を行うため、同様の実験を京でも行い比較した。
実験では、TSUBAME2.5 の予約キューを用い、連（様式 20）成果報告書続したノードを確保し利用した。また、ログインノードや

図 3 および図 4 は、それぞれ Barrier と Allreduce

ファイルシステムの接続されている 1st Rail ネットワーについて同様に測定した結果である。こちらもステンシクは利用せず、2nd Rail のみを用いて実験を行った。

ル通信の場合と同じく、どちらの手法を利用した場合もなお、実際に故障を発生させることは不可能であるた

TSUBAME2.5 では故障復帰後の通信性能の低下はめ、故障後のプロセス配置をシミュレーションにより求ほぼ見られなかった。

行う。
京においては 3 次元ジョブを 6D メッシュ/トーラスネッ
トワークトポロジに隣接関係を保持したランクマッピングとなる形で投入している。一方 TSUBAME2.5 ではそRel. Comm. Time

め、その配置を実環境上に再現し、通信性能の測定を

21.5
10.50のようなマッピングはないため、ランク番号は京のものを踏襲し、X→Y→Z の順に座標を変化させたものを利用した。このため、TSUBAME2.5 ではスペアノードは02040# Failed Node

K_HY

Tsubame_0D

図3Barrier の性能

K_0D

60
Tsubame_HY不連続なノードに確保されることとなる。

果である。横軸は故障ノード数、縦軸は故障前の通信時間を基準とした通信時間比であり、故障数毎にシミュレーションで得た 20 パターンのランク配置で通信性能の測定を行い、その最悪値を示している。
TSUBAME2.5 では故障後の通信時間の増加が最大でも 1.2 倍程度となり、京の 4.1 倍を大きく下回った。これは、京とは異なり衝突によるペナルティがほぼ発生しRel. Comm. Time

図 2 は、4MiB の 7 点ステンシル通信の性能測定結

5432
100
K_0D

2040
# Failed Node
K_HY

Tsubame_0D60
Tsubame_HYなかったためと考えられる。また、京では特に故障数が少ない場合に Hybrid 手法が高性能を示していたが、図4Allreduce(64KiB)の性能TSUBAME2.5 の場合はどちらの手法でもほぼ同性能を示しており、手法の違いによる性能差は無いと言えここまでの実験では、スペアノードを不連続で確保して測定をしたが、TSUBAME2.5 は Fat Tree 接続である。

るため、スペアノードをどこに確保した場合でも故障復Rel. Comm. Time

5

帰後の性能に影響は無いと考えられる。そこで、スペア4ノードを連続する形でまとめて確保した場合の性能を3測定し、比較と検証を行った。

21002040# Failed NodeTsubame_0D

60

K_0D

K_HY

Tsubame_HY

図27 点ステンシル(4MiB)の性能

（様式 20）成果報告書

11.2

0.8

Rel. Comm Time

Rel. Comm Time

1.20.6
0.40.20Stencil

Barrier

sep.

10.8
0.6
0.40.2Allreduce

0Stencilcont.

Barriersep.

Allreducecont.

図 5 は、スペアノードの確保方式が非連続(sep.)の場
図5合と連続(cont.)の場合とで、故障前の通信性能に差がスペアノード確保方式による性能差あるか実験した結果である。縦軸は非連続で確保した

Rel. Comm. Time状態での通信性能を基準とした通信時間比である。結果から分かる通り、スペアノードの確保方式による性能差は見られなかった。
たRel. Comm. Time

ま、

1.5

1.5

10.5

00

1204060# Failed NodeTsubame_0D
Tsubame_HY0.5

図6002040

7 点ステンシル(4MiB)の性能・スペア連続確保

60

まとめ、今後の課題# Failed NodeTsubame_0D
Tsubame_HY

本プロジェクトでは、故障復帰後の実行継続手法とし

図 6 に、スペアノードを連続で確保した上で、7 点ステンて我々が提案している、スペアノードを用いたスライド

シル通信パターンに対してスライド手法による故障復帰手法について、Fat Tree ネットワークトポロジをもつを適用した場合の通信性能を示す。結果を見て分かる

TSUBAME2.5 を用い、故障復帰後の通信性能の評通り、非連続でスペアノードを確保していた価を行った。実験の結果、TSUBAME2.5 ではスペアノードを利用した故障復帰後には Fat Tree ネットワーク

Rel. Comm. Time5の特性上新たな通信衝突は発生せず、通信性能はほ4ぼ低下しないことを確認した。また、この特徴はスペア3ノードの利用方式によらず、どのスライド手法を利用し2た場合でも差異の無いことを確認した。また、スペアノ1ードを確保する位置による影響を調査するため、連続と00

K_0D

2040
# Failed Node
K_HY

Tsubame_0D60

不連続の二つのパターンでスペアノードを確保し、その差異を確認したところ、方式による性能差は見られなかTsubame_HYった。
今後の並列大規模環境を見据え、様々なトポロジで

図 2 の場合とほぼ同様の性能を示しており、スペアノーの故障対策について考慮するために、今回はドの確保方式による性能差は出なかった。

Mesh/Torus と同様に HPC 環境で広く用いられる Fat（様式 20）成果報告書
Tree トポロジでのスライド手法の評価を行った。今後はDragonfly 等のネットワークについても性能評価を進める予定である。