クラスタ監視ソフトVGXPの開発・運用を通しての評価と課題
東京大学情報基盤センター
鴨志田 良和 kamo@cc.u-tokyo.ac.jp

Agenda
2



背景



クラスタ監視ソフトVGXP

実環境での評価と課題

まとめ・今後の方向性

2009/12/17 第9回 PCクラスタシンポジウム

背景
3



クラスタシステムの扱いづらさ 計算ノード数が多い しかも状況が時々刻々変化する場合がある →何が起きているか分かりづらい

システムの利用者・管理者の双方にとって問題 利用者: 並列プログラムのチューニングやデバッグを行う
 管理者: システムの異常検知、効率のよいジョブスケ

ジューリングを行う

クラスタシステムの現在の状態が見えると日常的なクラスタ利用の利便性が向上する

2009/12/17 第9回 PCクラスタシンポジウム

クラスタのリアルタイム監視
4

ノードごとにCPU、メモリの利用率など、さまざまなデータを細かい(100ms～数秒程度の)間隔で取得し、各ノードのデータを集約して可視化する 利点

 システム利用者にとっての利点 投入したジョブの実行中に異常を発見できる 負荷分散の時間変化を見ることができる システム管理者にとっての利点 全体的なリソースの利用状況を一目で把握できる

欠点

 大量のログファイルとの対峙からの解放 システムに与える負荷が大きい

2009/12/17 第9回 PCクラスタシンポジウム

VGXP(Visual Grid Explorer)5

分散環境向けの軽量な監視システム

 システムになるべく大きな負荷をかけずに、
 高いリアルタイム性(2秒程度の遅れ)で、
 複数のクラスタを監視ソフトウェア クラスタ用シェルGXPを使用して構築

http://sourceforge.net/projects/gxp/
 クライアントはJava(Java Web Start)とOpenGLを使用
 公開URL
http://www.logos.ic.i.utokyo.ac.jp/~kamo/vgxp/
2009/12/17 第9回 PCクラスタシンポジウム

VGXPの機能
6



VGXPが表示する情報
 CPU time Load average Memory usage(used,swap…)
 Network(sent, received)
 I/O (Block r/w, Swap in/out) プロセスごとの情報(cmdline, user, CPU time)

情報更新の頻度: 2sec.

2009/12/17 第9回 PCクラスタシンポジウム

VGXPの動作の仕組み
7

MonitoredNodesServerClients

監視対象ノード間で木構造のTCP接続を構築してデータを集約する
 集約したデータをサーバに転送し、サーバが各クライアントにデータを配信する
 ノードの追加や脱退の際は、木を再構築する

2009/12/17 第9回 PCクラスタシンポジウム

ネットワークの再構成
8

監視プロセスの状態を監視するメタ
監視用ネットワークを構成
 故障が発生した場合
 メタ監視プロセスが故障を検知
 他のノードの監視は続行

 監視用ネットワークを再構成したのち、監視プロセスを再起動

2009/12/17 第9回 PCクラスタシンポジウム

他のシステムとの比較
9

監視にかかる負荷に着目し、他のシステム監視ソフトと比較を行う
 Ganglia http://ganglia.sourceforge.net/

どちらも、そのままでは Munin
高頻度の情報更新に
 http://munin.projects.linpro.no/ は向いていない Real Time Monitor (GridPP内) http://www.gridpp.ac.uk/

クライアントの表示負荷に改善の余地あり
2009/12/17 第9回 PCクラスタシンポジウム

監視にかかる負荷 - Ganglia
10Ganglia 定期的にノード情報をクラスタ内でマルチキャスト
 1画面あたりのデータ転送量: 0.9MBytes (120nodes)
 グラフ生成の負荷はサーバ上に集中

2009/12/17 第9回 PCクラスタシンポジウム

監視にかかる負荷 - Munin
11



Munin

 普段は各ノードでは何も負荷は発生しない
 5分ごとに、サーバが全ノードのデータを収集し、グラフ画像を生成
 1.5～3分(120 nodes)

 グラフ画像のサイズ

1.99MBytes / node→300ノード程度で限界
2009/12/17 第9回 PCクラスタシンポジウム

クライアント側の可視化
12

Real Time Monitor(2006)

 サーバは生データだけを送ってクライアントが可視化処理を行う
 3分遅れで情報を表示
 拠点ごとにジョブ情報を表示比較のまとめ
13Ganglia

Munin

RTM

VGXP

情報の粒度

Per node/Per site

Per node

Per site

Per node

収集されるデータの種類

Various info.(CPU,mem, net, disk…)

variousJobs
onlyvarious

プロセスごとのデータ

×××○

時系列データの表示○○××

表示更新の間隔

5min.

5min.

<1sec.

<1sec.

ノードごとの通信頻度

20sec.

5min.

1min.

~2sec.

可視化の遅延<5min.

<5min.

3min.

~2sec.

可視化が行われる場所

ServerServer

ClientClientリアルタイム監視システムは、より取得負荷が高い情報を必要とする

2009/12/17 第9回 PCクラスタシンポジウム

性能比較(CPU)14

Ganglia

Munin

RTM

VGXP

CPU(when monitoring500nodes)
更新頻度

20sec. --2sec.

Server CPU

9.1% --

1.1%

0.0324% --0.0460%--0.3286%

Nodes CPU(各ノードの平均値)
obtaining system-widedata
obtaining per process data-

VGXPは更新頻度が高い割にはCPU使用率はGangliaと同程度で済んでいる プロセス情報の取得負荷は高い

2009/12/17 第9回 PCクラスタシンポジウム

性能比較(ネットワーク)
15

Ganglia

Munin

RTM

VGXP

Network(client <-> server)
更新頻度
更新あたりの転送量

5min.

5min.

1min.

2sec.

0.9MB(per 1.9MB(per 90KB(raw) 50KB~rendering) rendering) 10KB(com 300KBpressed)

値の予測を行い、その予測が当たっている間はデータを送らないことで、転送量をさらに減らすことができる(Kamoshida et al. (CCGrid2008))

2009/12/17 第9回 PCクラスタシンポジウム

16

リアルタイム監視システムに求められること

大量の情報の効率的な収集

 運用中に明らかになった課題に対する取り組みについて紹介

分かりやすい情報可視化

多数のクライアントへの効率的なデータ配信

2009/12/17 第9回 PCクラスタシンポジウム

VGXPが運用されているシステム
17

InTriggerプラットフォーム

 http://www.intrigger.jp
 国内15拠点、約300ノード



HA8000クラスタシステム
 2009年2月まで運用
 無料の試行期間+α

2009/12/17 第9回 PCクラスタシンポジウム

見えてきた課題
18



ノードで情報収集デーモンを実行していると一部の並列アプリケーションが異常に遅くなることがある アプリケーション以外のOSプロセス(ノイズと呼ばれることがある)の影響として、以前から知られていた問題(Joneset al. (SC03)など)だが、同期を頻繁に行うアプリケーションの場合、比較的少ないノードのジョブでも大きな問題になるため、対策が必要
 極端なケースでは64ノードで3倍の時間がかかることも2009/12/17 第9回 PCクラスタシンポジウム

実験
19

並列アプリケーションを、監視プロセスの有無を変えて実行し、処理時間の違いを調べる アプリケーションの概要 不均質な物性値分布を有する立方体形状における三次元静的弾性問題を並列有限要素法(FiniteElement Method，FEM) で解く
 連立一次方程式はSGS(Symmetric GaussSeidel) を前処理手法として、共役勾配(ConjugateGradient，CG)法を使用して解く
2009/12/17 第9回 PCクラスタシンポジウム

通信の概要20

アプリケーション内で行われる通信 階層型領域間境界分割(HID)によって担当領域を分担
 (1)隣接領域を担当するプロセスと境界部分のデータを交換。 このために1対1通信による送受信を平均7 ～8回実行 (2)全プロセスでMPI_Allreduceを3回実行(全体の同期を伴う処理)
 (1),(2)を収束するまで繰り返す
 実験で与えた入力データでは1250回程度

2009/12/17 第9回 PCクラスタシンポジウム

監視プロセス(pinfo)21



監視プロセスの動作概要

 定期的(500msに1回)に動作
 VGXPのデフォルト頻度の4倍

 システム情報(メモリ使用率やLoad averageなど)と各プロセスの情報(プロセスごとのCPU使用率など)を取得
 1回の情報取得時間は15～20ms
2009/12/17 第9回 PCクラスタシンポジウム

実験環境
22



東大 HA8000クラスタシステム(T2Kスパコン東大版)
 32GB memory, Myri-10G x4

Linux kernel 2.6.18

Quad-core Opteron(2.3GHz) x4
MemoryMemoryL3L2L1L3L2L1L2L1L2L1L2L1L2L1L2L1L2L1Core Core Core Core

Core Core Core Core

Core Core Core Core

Core Core Core Core

L1L2L1L2L1L2L1L2L1L2L1L2L1L2L3L3Memory

MemoryL1L22009/12/17 第9回 PCクラスタシンポジウム

実行時間
23120

監視プロセスがある場合、特にノード数が多い場合に遅延が大きくなる

Elapsed Time(sec)

100
80
60

BASE
PINFO

40
20
08(各ノードで16プロセス実行)

1632

4864

Number of Nodes 2009/12/17 第9回 PCクラスタシンポジウム

ノイズのアプリケーションへの影響
Processors

24

Processors

理想的には、アプリケーションプ
ロセスだけに動作してほしいTime

実際は、デーモ
ンプロセスの影
響で、同期待ちの時間が発生する

Barrier

ComputeNoise

Wait

並列プログラム遅延への対策
25(Kamoshida et al. (SWoPP2009))
 監視プロセスについて以下の改良を行う
 ノード間の同期

 他のノードとなるべく同時にスケジュールされるようにする



個々の処理の効率化

 呼び出すシステムコールの回数を減らす
 プロセスごとの情報収集負荷を下げる

2009/12/17 第9回 PCクラスタシンポジウム

実験26



ベンチマーク 各ノードで16プロセス実行

 約1.25msのローカル計算
 全プロセスでAllreduce 以上を8192回繰り返し



実行環境

 東京大学HA8000クラスタシステム
 8～256ノードを使用

 監視なし(BASE)・監視あり(PINFO)・改良版監視プロ

セスあり(PINFO_OPT)を比較

2009/12/17 第9回 PCクラスタシンポジウム

実行時間
27

180

Elapsed Time(sec)

160
140

元のPINFOでは256ノードで140秒程度の遅延

BASE
PINFO

120

PINFO_OPT

10080
60
40
20
08163264

Number of Nodes

128256

2009/12/17 第9回 PCクラスタシンポジウム

実行時間(除くPINFO)
28

35

Elapsed Time(sec)

30
25
20
15

PINFO_OPTでも2~3割遅くなる(256ノード)

BASE
PINFO_OPT

BASEも8ノードと比べると2倍以上遅い

105081632

64

Number of Nodes

128

256

2009/12/17 第9回 PCクラスタシンポジウム

実験結果(まとめ)29256ノードでの実験結果

 元のPINFOでは256ノードで140秒程度の遅延
 改良版PINFOでも2~3割遅くなる(256ノード)

 監視プロセスがない場合でも8ノードと比べると2倍以上遅い



BASEのデータの揺れも大きい 標準偏差が2割程度

 改良版PINFOでも大差ない

2009/12/17 第9回 PCクラスタシンポジウム

その他の課題30



効率的なデータ配信

 サーバ負荷の集中を避ける転送アルゴリズム

 いろいろなクエリを受け付けられる枠組みの構築(cf.

Content-based pub-sub system)必要な情報を可視化 大量の情報から意味のある変化を自動的に選択 対象のクラスタリング

2009/12/17 第9回 PCクラスタシンポジウム

まとめ31



クラスタ監視ソフトVGXPの仕組みと設計の背景を説明

 数百～1,000ノード規模のクラスタシステムで稼働している

運用中に見えてきた課題とそれに対する対策を説明

 並列プログラムの遅延の問題は大きく改善されたが、それでも、256ノードで20%程度遅くなる場合もまだ存在する 遅延の原因を、監視システムによるものとそれ以外に分けて分析する必要がある
2009/12/17 第9回 PCクラスタシンポジウム