[添付資料3-2-2] SS研 Grid Computing 2004 WG セミナー資料

2005/7/5

広島大学および情報メディア教育研究センターについて•広島大学

広島大学におけるキャンパスグリッド事例•学生数：約15000、教職員数：約3000•中四国の基幹校（と自分たちは思っている）•1.5流らしい

広島大学情報メディア教育研究センター•SuperSINETあり•情報メディア教育研究センター(2001～)

庄司 文由•総合情報処理センター（1981～2001） ＋ 情報教育研究センター(1996～2001）•スタッフ：常勤20名•情報プロパーは少ない(HPCはゼロ)

SS研 Grid Computing 2004 WG 第4回会合•予算は厳しい•システム（メール・Web・教育端末・HPC）は一括で5年レンタル（直近のリプレースは2005年）
1

なぜキャンパスグリッド？

2

広島大学の端末環境
メディアセンター西分室/西図書館•進んでやろうとしたわけではない•演習室94台•マルチメディアフロア235台

メディアセンター本館•独法化後の予算配分事情•演習室93台•自習室41台•何か新しいこと・ユメがあること？
総合科学部J305教室•お金がかからない•演習室60台
中央図書館•端末スペース20台

Grid技術を使った教育用端末の計算資源化•

お金はかからない•

新しいしユメもある（かもしれない）•

石井センター長（当時）のプッシュ

東千田地区（経済学部）

霞地区（医学部）

端末室40台

端末室40台+108台

長期休暇はほとんどが閉室

PC約700台の潜在的計算資源

3

教育用端末の遊休時間を利用することについて

4

端末の利用方法についてメリット配慮した点•巨大な計算資源の創出•HPC資源は32GFLOPS（～2005）、730GFLOPS（2005～)

9

既存サービス（教育用端末環境）に影響が出てはいけない

9“使えるモノ”にしたい•理論性能はクロック周波数x2x台数（3TFLOPS以上）•導入コストが低い•既存端末＋α•計算資源化しやすい

9

一発屋は嫌だ

9

高信頼性

9

柔軟性

方針

•スペック/運用ルールが均一

9

別々のOS

•地理的にある程度集約されている

9

丸ごとクラスタはしない

9

夜間・休日・長期休暇に限る•新規アプリケーションへの柔軟な対応•スカラアプリ、分散並列アプリユーザーの新規開拓

開室時間：平日9：00～22：00、土曜9：00～17：00まで

5

6

[添付資料3-2-2] SS研 Grid Computing 2004 WG セミナー資料

別々のOS

2005/7/5

丸ごとクラスタはしない

9

責任問題の回避

9

Myrinet/InfiniBandは無理だし、ギガで組むと大規模構成は非現実的

9デュアルブート(ディスクレス）システムは導入事例が多い

9

どうせ全体で使うのは最初のベンチマークだけ

9

株式会社ミントウェーブのＶＩＤシステムを採用

9

数十台規模でも、ある程度ニーズには応えられる

教育用端末時9

端末のギガNICは教育用・クラスタ/グリッド用で共用する

9Linux/Windowsのデュアルブート

9

ギガビットスイッチ（L2）24ポートを使う

9

電源断がデフォルト9

クラスタ構成のところはカスケードは2段までで、アップリンクが多くなるように

9

残りはＰＣグリッドで使う

99

クラスタ/グリッド時
専用Linux

9

ローカルディスクをワーク領域にクラスタD 実効64台(68)SCore サーバ端末40～50台に対し、VID-IO/NFSサーバ1台

メリット
9

原理的に1台分のボリュームイメージがあればよいので、ディスク容量が大幅に節約できる

9

端末個々のディスク障害が運用に影響しない

9

一度の作業で全端末分の設定変更が可能

9

複数のイメージを切り替えることで、クラスタのOSを瞬時に切り替えることができる

本館（2F演習室）
端末×93台、Printer×6台

本館（2Fオープンスペース）端末×41台、Printer×2台

夜間・休日・長期休暇に限る（原理的に）昼間のサービスに影響が出ない

9

夜間電力は安い（？）

9

夜は涼しい（？） ジョブ

昼

L2スイッチB (3)1G(T)×5

1G(T)×17

L2スイッチB (4)1G(T)×5

1G(T)×15

L2スイッチB (5)1G(T)×2

1G(T)×10
100M(T)×6

L2スイッチB (6)1G(T)×2

1G(T)×22

L2スイッチB (7)1G(T)×2

L2スイッチB (8)1G(T)×2

1G(T)×19

L2スイッチA(1)
24/24
<68>

L2スイッチA(1 prime)
10/24<66+8>

L2スイッチA(2)
15/24<11+2>

1G(T)×11

本館（スタッフ用）
端末×11台(10台）、Printer×2台(1台)

100M(T)×2

1G(T)×3

1G(T)×2

1G(T)×28

理想的には、
昼

夜

計算資源として稼動

管理サーバ/PCクラスタ

夜

夜
PC数百台

PC数十台

1G(T)×5

1G(T)×17

夜

コンパイル

○

○

小規模ジョブ（投入/実行）○○

大規模ジョブ（投入）○○大規模ジョブ（実行）×○

技術的問題点として、ジョブはいつでも投入可能

昼

1G(T)×5

L2スイッチB (2)問題点

昼端末として稼動

9

L2スイッチB (1)

1G(T)×17

100M(T)×271G(T)×1

1G(T)×17

基幹スイッチ9

配線図（抜粋）9•長時間ジョブをどう扱うか（逐次/並列）•一晩で終わらないジョブは永遠に終わらない？

•端末個々の障害対策（逐次/並列）•サービスの質を考えると本質的•並列ジョブと逐次ジョブの資源分配•潜在的なニーズは 逐次 >> 並列 のはず•テストラン/小規模ジョブおよび大規模ジョブの投入は24時間可能•大規模ジョブの実行は夜間のみ

逐次ジョブの場合

夜のみ稼動

Condorを採用

24時間稼動10

逐次ジョブの場合(2)①フロントエンドから実行モジュール、入力ファイル等が転送される

CondorがＰＣの状況を考慮しつつ、ジョブを自動的に振り分ける②ジョブを実行する
実行モジュール
入力ファイル③ジョブが終了したら、フロントエンドに出力ファイルを転送する
出力ファイル

実行モジュール

逐次ジョブ

入力ファイル

Condor

逐次ジョブ•静的分割はしたくない

9

逐次ジョブ

ジョブが実行できなくなった

逐次ジョブ

実行モジュール
入力ファイルユーザーがジョブを投入すると、

例えば、•稼働時間が終了した（教育用端末の場合）•障害が発生した

フロントエンド•ＰＣの負荷が（Condorジョブ以外の要因で）上がった②チェックポイントの情報をもとに、ジョブを継続して実行する(standard Universeの場合）②ジョブを実行する①稼動中の別のＰＣに実行モジュール、入力ファイル等が転送される

実行モジュール
入力ファイル

ジョブを割り当てられたＰＣ上では、①フロントエンドから実行モジュール、入力ファイル等が転送される②ジョブを実行する
実行モジュール
入力ファイル③ジョブが終了したら、フロントエンドに出力ファイルを転送する②ジョブを最初からやり直す（vanilla Universeの場合）

出力ファイルに戻る
実行モジュール
入力ファイル11

長時間ジョブ→○ 端末の障害→○12

[添付資料3-2-2] SS研 Grid Computing 2004 WG セミナー資料

長時間ジョブをどう扱うか（並列）端末個々の障害対策（並列）
SCoreのフォルトトラレント機能を利用する

SCoreのチェックポインティング機能を利用する
JOB

JOB

JOB

JOB

JOB

JOB

JOB

JOB

JOB

JOBJOBJOB

JOB

JOB

JOB

JOB

STOP

BackupBackup

JOB

JOB

昼

夜

JOB

夜

JOB

JOB

特徴
シングルユーザーモード

排他実行

マルチユーザーモード

排他実行/ギャングスケジューリング

PBSモードシングルユーザーモード＋PBSのジョブスケジューリング

端末群

ジョブ
管理

管理

管理

scored

管理

監視

SCoreのマルチユーザーモードを利用する
障害発生

端末群

管理

scoredハングアップ管理scoredsc_watch 夜まで待機○○

小規模ジョブ（投入/実行）○○

大規模ジョブ（投入）○○大規模ジョブ（実行）×○

チェックポインジョブ
トから継続実行

端末群

管理

管理

管理

scoredハング
夜scoredハングアップ検知

昼

ホストリストの書き換えscored 再起動

夜まで待機(sleep)-restart 付

sc_watch ホストリストの

sc_watch

sc_watch

書き換え

夜

13

sc_watchの動作

端末群

scoredハングアップ

監視-restart 付

sc_watch

大規模ジョブの24時間キューイング（並列）
コンパイル

管理

scored

夜

夜

ジョブ
待機状態

管理

scored 再起動

昼

昼

端末群

ジョブ

管理

ハングアップ検知

sc_watch

夜

ジョブの継続実行
は、チェックポイン
ティング機能により保証される※同時に2台の端末に障害が起こるとアウト

チェックポイントかジョブ
ら継続実行

端末群

ジョブ
待機状態

Recover!

JOB

JOB

SCoreのマルチユーザーモードを利用する
チェックポインティング機能、フォルトトラレント機能が利用可能

2005/7/5

scored再起動

14

並列ジョブと逐次ジョブの資源分配
STEP1
逐次ジョブが2つ実行されている状態で、SCoreのマルチユーザーモードでは、scoredに直接ジョブを投入する。しかし、昼間はscoredがハングアップしているため、ジョブを投入することができない。

逐次

逐次

逐次

並列
逐次

逐次

並列
逐次

STEP2
並列ジョブが投入されると、ジョブスケジューラに仲介させる
ジョブ

ジョブスケ
ジューラ
大規模ジョブ1.

SCoreとの連携

2.

ハングアップへの対応

3.

時間帯による動作切替

4.

・・・

SCoreマルチ
ユーザーモード

昼はジョブをプールし、夜にスケジューリングする

STEP3
逐次ジョブは、サスペンドまたはマイグレートされる

ジョブスケジューラの要件

SCoreマルチ
ユーザーモード
小規模ジョブサスペンド

とりあえずGenericNQS
を採用

1516

PCクラスタ/グリッドシステム構成図

ディスク配置図 2005/7/3
夜のみ稼動

実効96台(100)PCグリッド

24時間稼動

実効16台(17)×2

実効64台(68)

ＨＰＣ共通ファイルサーバ

実効96台(100)4クラスタ管理サーバ(scmgr1)

140GB x 2
/work[12]_scmgr1

ＨＰCサーバ実効64台(68)

マイグレート

逐次2

1
メディアセンター本館
2F演習室（93台）

メディアセンター本館2F
オープンスペース（41台）

2TB x 3

クラスタ1

SCore

クラスタ3

HDD:40GB
NIC:GbE

Generic
NQS

メモリ：2GB

20GB /node/work[123]クラスタ管理サーバ(scmgr3)/home/work[12]_scmgr3/work[123]/home
20GB /node/work[123]クラスタ管理サーバ(scmgr4)/work[12]_scmgr2

140GB x 2

SCore

クラスタ4

/work[12]_scmgr3/work[12]_scmgr4

SCore

クラスタ5/work[12]_scmgr4

/home

SCore

クラスタ2

ISVアプリ

クラスタ6

HDD:40GB
NIC:GbE/work[12]_scmgr2

PCクラスタ/グリッド用/work[12]_scmgr1

CPU:Pentium4 3GHz
メモリ：1GB2&6/home

140GB x 2

SCore

/work[12]_scmgr5

逐次ジョブ

CyberGRIP

本館2FOS

Condor

残りの端末•逐次専用：133(0)•並列優先：336（16）ボリュームの実体

17

NFSマウントしている
ボリューム

20GB /node/work[123]ボリューム

R/Wスピード

容量/work_local

高20GB/work[12]_scmgr5/work_scmgr?

中140GB x 2/home/work?

低2TB x 3

140GB x 2/work[123]/work_local
計算ノード

3/work[12]_scmgr3/work_local
計算ノード

4/work[12]_scmgr4

クラスタ管理サーバ(scmgr5)
並列ジョブ

計算ノード

/work[12]_scmgr2

フロントエンド(wing.media)
西図書館２F演
習室（100台）-スペック-

CPU:Xeon 3GHz

140GB x 2

/work[123]/work[123]3

西図書館3Fマルチメ
ディアフロア（235台）

グリッドサーバ(34台)/work_local

クラスタ管理サーバ(scmgr2)

5620GB /node/work[123]/home/home

1/work[12]_scmgr1

/home

2TB

計算ノード

20GB /node/work_local
計算ノード

5/work[12]_scmgr5

18/work_local

[添付資料3-2-2] SS研 Grid Computing 2004 WG セミナー資料

2005/7/5

運用ルール
端末 室

設置場所

平日

西図書館閉館日

土曜

日曜・祝祭日西図書3F MF

8:30～21:00

NOT available

8:30～17:00

NOT available

西図書2F演習

8:30～21:00

本館2F演習8:30～17:00

8:30～ 17:00•SCore/Condorの冗長機能を活用

8:30～22:00•運用時間の不規則性を隠蔽

NOT available
ID

平日

西図書館閉館日

土曜

日曜・祝祭日長期休暇•ジョブキューイングは24時間可能

Full time•実行は運用時間に依る

4
西図書3F MF235

5～8:00 , 21:30～

Full time～8:00 , 17:30～

Full time-西図書2F演習

100

本館2F演習93

本館2F OS41

GRIDサーバ

34

9まとめ•耐障害性を重視した設計

NOT available

GRIDサーバ
台数

NOT available

67台
NOT available

8:30～22:00

本館2F OS

設置場所

長期休暇
168台

3～8:00 , 17:30～～8:00 , 21:30～

1--～8:00 , 17:30～～8:00 , 22:30～-2
6

Full time～8:00 , 22:30～•並列（ＭＰＩ）ジョブ・逐次ジョブに対応

Full time

ＶＩＤシステムの運用スケジューラで端末毎に起動時間/起動ＯＳを管理

19

今後の課題
•どう使ってもらうか•現状は数人・・・・•講習会/説明会はこれから•コンサルティングが重要•新しい利用方法に期待•ソフトウェア的改善•NAREGIスーパースケジューラ•SunGridEngine, UNICORE, etc.

•教育用端末の未来•ノートＰＣの必携化•期間限定で占有利用？
•逐次ユーザーの爆発的増加に期待•ディスクI/O問題•クラスタファイルシステム?
•PVFS, lustre, GFS, etc.

•空調・電気代•ジョブは休止時間を挟んで継続実行可能•高柔軟性

Full time•故障の頻度•クラスタ１について（5/23～6/28）•起動できなかった端末：9台•最多で2台（ジョブの継続ためには1台まで）•大学側の締付けが厳しい•ジョブ実行中の障害はいまのところ無し•せめて空調は入れて欲しいのだが・・・・•夏が心配•ジョブ投入で電源ＯＮ
2120