TSUBAME2.0のペタスケールデータ処理基盤
東京工業大学佐藤仁

情報爆発時代 人類の扱う情報量の爆発的増大

2000年以降は指数的な増加 例. CERNのLHC実験では１年に15PBのデータが生成 他の科学技術分野(バイオインフォマティクス)なども同様
 解析器などのデバイスの性能向上も影響→・常に大量の(ペタスケールの)データが生成される・生成された大量のデータに対する解析が必要

ペタスケールのデータを処理するための課題
 スパコンのストレージの設計
 大規模データ処理基盤の整備
 大規模データ共有方法

スパコンのストレージ

東工大TSUBAME2006
TSUBAME 1.0
85TFlops/1.1PB

2007
TSUBAME 1.1
100TFlops/1.6PB

アジアNo.1「みんなのスパコン」
x86 CPU+アクセラレータ

2008
TSUBAME 1.2
160TFlops/1.6PB

ストレージ・アクセラレータ
GPUアクセラレータ
増強
680枚増強2010/11/01
TSUBAME 2.0
2.4PFlops/7.1PB
日本初のペタコン、TSUBAME1.0の30倍の性能
TOP500 4th ,Green500 2nd (Nov 2010)
 TSUBAME初の完全リプレース

TSUBAME2.0 システム概念図
ペタバイト級HDD ストレージ： Total 7.13PB(Lustre+ home)
並列ファ イルシステ ム領 域
5.93PBx5

ホーム領域
1.2PB

MDS,OSS
HP DL360 G6 30n odes
Storage
DDN SFA100 00 x 5( 10 en closu re x 5)
Lu stre（ 5File System）
OSS: 2 0 OST: 5.9PB
MDS: 10 MDT: 30TB
OSS x 20

MDS x 10Sun SL8500
テープシス テム~8PB

Storage ServerHP DL380 G6 4n odes
Blu eArc Mercu ry 100 x 2Storage
DDN SFA100 00 x 1（ 10 en closu re x 1）

NFS,CIFS 用 x 4

Titenet3

NFS,CIFS ,iS CSI用 x 2

E-Science
Renkei-PO P
高速デー タ交換

ノード間相互結合網: フルバイセクション ノンブロッキング 光 QDRInfiniband ネットワーク
Core Switch

Edge Switch

12s witch es
Voltaire Grid Director 4700 12s witch es
IB QDR: 32 4port

Edge Switch (10GbE port付き)

179 sw itch es

6s witch es

Voltaire
Grid Director 4036 179 sw itch es
IB QDR : 36 port

Voltaire
Grid Director 4036E 6 sw itch es
IB QDR:3 4port
10GbE: 2port

管理サーバ群

Sinet3

計算 ノード： 2.4PFlops(C PU+G PU)，224.69TFlops( CPU), ~100TBメモリ、~200TB SSD
Th in 計算ノ ード

・ ・ ・ ・・ ・Mediu m計算ノ ード

HP Prolian t SL390s G7 14 08n odes
CPU In tel Westmere-EP 2.93G Hz（ Tu rbo boost 3.196 GH z） 12Core/n ode
Mem:55.8 GB(=5 2Gi B)
103GB(=9 6Gi B)
GPU NVID IA M205 0 515 GFlops ,3GP U/n ode
SSD 60GB x 2 120G B ※55 .8G Bメモ リ 搭載n ode
120GB x 2 240GB ※10 3GB メモ リ搭 載n ode
OS: Su se Lin u x En terprise Server
Win dows HPC Server

Fat計算ノ ード

HP DL580 G 7 24n odes
CPU In tel Neh alem-EX 2.0GH z
32Core/n ode
Mem:13 7GB( =12 8Gi B)
SSD 120G B x 4 480GB
OS: Su se Lin u x En terprise Server
CPU Total: 6.14TFLOPSHP DL580 G 7 10n odes
CPU In tel Neh alem-EX 2.0GH z
32Core/n ode
Mem:274GB(= 256 GiB) ※8n odes
549GB(=512 GiB) ※ 2n odes
SSD 120GB x 4 480 GB
OS: Su se Lin u x Enterprise Server
CPU Total: 2.56TFLOP S

CPU Total: 215.99TFLOPS(Tur bo bo ost 3.2GHz)
PCI – E gen2 x1 6 x2 slot /n o de

CPU+GPU: 2391.35TFlops
1408n odes

(32n ode x 44 Rack)

6Memory T otal：80.55TB (CPU) + 12.7TB (GPU)SSD Total：173.88TB

GSIC:NVIDIA T esla S1 07 0GP U

TSUBA ME 2.0 ガ イダ ンス

TSUBAME2.0 Nov. 2010 w/ NEC/HP

2.4 PF Next gen multi-core x86 + next gen GPGPU

0.7 Petabyte/s aggregate mem BW,

Effective 0.3-0.5 Bytes/Flop, restrained memory capacity(95TB)

Optical Dual-Rail IB-QDR BW, full bisection BW(FatTree)

1432 nodes, Intel Westmere/Nehalem EX
4224 NVIDIA Tesla (Fermi) M2050 GPUs
~100,000 total CPU and GPU “cores”, High Bandwidth

200Tbits/s, Likely fastest in the world, still scalable

Flash/node, ~200TB (1PB in future), 660GB/s I/O BW
>7 PB IB attached HDDs, 15PB Total HFS incl. LTO tape

Low power & efficient cooling, comparable to TSUBAME
1.0 (~1MW); PUE = 1.28 (60% better c.f. TSUBAME1)
 Virtualization and Dynamic Provisioning of Windows HPC+ Linux, job migration, etc.
Storage problems in Cloud-based SCs
 Support for Various I/O workloads
 Storage Usage Usability

I/O workloads
 Various HPC apps. run on TSUBAME2.0
Concurrent Parallel R/W I/O MPI (MPI-IO), MPI with CUDA, OpenMP, etc.

Fine-grain R/W I/O Checkpoint, Temporal files
 Gaussian, etc.



Read mostly I/O Data-intensive apps, Parallel workflow, Parameter survey
 Array job, Hadoop, etc.

 Shared Storage

I/O conc entration

Storage Usage Data life cyclemanagement

Few users occupy most of storage volum es onTSUBAME1.0
 Only 0.02 % of users use more than 1TB of storage volumes



Storage res ource characteristics
 HDD : 〜 150MB/s, 0.16 $/GB, 10 W/disk
 SSD : 100 〜 1000 MB/s,4.0 $/GB, 0.2 W/disk Tape : 〜 100MB/s, 1.0 $/GB,low power consumption

Usability Seamless data access to SCs

Federated storage between private PCs, clusters in lab andSCs
 Storage service for campus like cloud storage services How to deal large data sets

Transfer big data between SCs
 e.g.) Web data mining on TSUBAME1 NICT (Osaka) →TokyoTec h (Tokyo) : Stage-in 2TB of initialdata
 TokyoTech → NICT : Stage-out 60TB of res ults
 Transfer data via the Internet : 8days
 Fedex?

TSUBAME2.0 Storage Overview
TSUBAME2.0 Storage 11PB (7PB HDD, 4PB Tape)

HomePhome
GPFS (GridScaler)

NFS, CIFS,iSCSIHP DL380 G6 × 4
HP DL360 G6 × 4

HP DL380 G6× 4BlueArc
Me rcury 100×2

DDN SFA 1 0K × 2
2.4 PB
2T B SAT A
× 2400 disks

1.2PB

DDN SFA 1 0K
2T B SAT A × 600 disks

Work

LustreHSM
with GPFS, Tivoli St orage Manager

2.4 PB HDD + 〜4PB Tape

MDS : HP DL360 G6 × 6
3.6 PBOSS : HP DL360 G6 × 20
DDN SFA 1 0K × 3,
2T B SAT A × 3550 disks, 600GB SAS × 50disks

ScratchGrid Storage

Thin node
SL8500 × 2
4PB LT O4 5000 roles

SSD

RENKEI-PoP

130 TB〜

Medium and Fat node

190 TB

60GB × 2 (120 GB/node)120GB × 2 (240 GB/node)
RD 460 MB/s WR 720 MB/s

SSD
120GB × 4 (480 GB/node)
RD 920 MB/s
WR 720 MB/s

TSUBAME2.0 Storage Overview
TSUBAME2.0 Storage 11PB (7PB HDD, 4PB Tape)

HomePhome
GPFS (GridScaler)

NFS, CIFS,• Home for computeiSCSInodes
HP DL380 G 6• Storage servic es×4for campus BlueArc

HP DL380 G 6 × 4
HP DL360 G 6 × 4
DDN SFA 10K × 2
2.4 PB
2TB SATA× 2400 dis ks

Mercury 100×2
DDN SFA 10K
1.2PB
2TB SATA × 600 dis ks

Work
Concurrent Parallel I/O (e.g.
MPI- IO)

LustreHSM
Read mostly I/O (data-intensiveapps,with GPFS, Tivoli St orage Manager

MDS : HP DL360 G6 × 6

parallel workflow, parameterOSSsurvey): HP DL360 G6 × 20

2.4 PB HDD + 〜4PB Tape

ScratchGrid Storage

Thin node

Data transfer
service betweenSCs/CCs
RENKEIPoP

SL8500 × 2
4PB LT O4 5000 roles

Backup

130 TB〜

3.6 PB

DDN SFA 10K × 3,
2TB SATA × 3550 disks , 600G B SAS ×50 disks

Medium and Fat node

190 TB
SSD
Fine-grain
R/Wnode)I/O SSD
60GB × 2 (120GB/
120GB × 4 (480 G B/node)(check120GB ×point,
2 (240GtemporalB/node) RD files)
920 MB/s WR 720MB/s
RD 460MB/s WR 720MB/s

大規模データ処理基盤の整備

大規模データ処理環境
 ワークフロー

ジョブのワークフローをDAGとして表現
 ex.) DAGMan, Pegasus, Dryad, GXP Make, etc.
 MapReduceex.) Google MapReduce, Hadoop, etc.

GXP / GXP make
 http://www.logos.ic.i.u-tokyo.ac.jp/gxp
 GXP :


並列シェル (プロセス起動) GXP make :(並列)ワークフロー,makeでワークフローを記述
GXP make
GXPsshPBS Pronodenode

TorqueSGECondor

node

nodenodeTSUBAME2.0上でのGXP makeによるMontage (天文アプリ)の実行

MapReduce (Hadoop) Hadoop

ApacheプロジェクトによるOSSのMapReduce処理系
 MapReduce ＋HDFS

エコシステム Mahout (機械学習)
 HAMA (BSP処理)
 PEGASUS (グラフ処理)

TSUDOOP⑤ run Map・Reduce tasks on the TaskTracker nodes

TS UBAME上でのHadoopの実行
Job
Tracker

PBS ProTask
Tracker

Task
Tracker

Task
Tracker

JobJobJobJob

nodenodenodenodenodeTask
Tracker② acquire computing nodes using PBS Pro③ invoke JobTracker and TaskTrackers via PBS Pro④ submit a MapReduce job to the JobTracker

LUSTRE
file

file

file

file

file

file

① run tsudoop script by user
⑥client⑦

direct I/O to Lustre FS

kill JobTracker and TaskTrackers

MapReduce
for GPU-based Heterogeneous Clusters
Pr oblems :• Map Task Scheduling for efficient execution–Depends on running task characteristics and underlying environments• Hybrid Map Task Scheduling– Automatically detects map task characteristics by monitoring– Scheduling map tasks to minimize overall MapReduce job
execution time

1.93 times faster than the Hadoop
original scheduling大規模データ共有

Grid Storage RENKEI Cloud

RENKEI: REsources liNKage for E-scIence
PoP : Point of Presences

High-performance data transfer service for e-Sc ience Seamless data access between S Cs/CCs
 w/ Grid security, Authentication

 Multi-protocol data access scp, gridftp, gsiscp 164TB of Gfarm FS

RENKEI-PoP
 大容量ストレージを持ったサーバアプライアンス
 個々の拠点にPoPを1つ設置
 拠点リソースにアクセスするためのゲートウェイ 拠点間ポリシーと拠点内ポリシーの調停 認証，情報サービスなど

 拠点間の高速データ転送，共有環境を提供
 ストレージを転送時のキャッシュ的に使う
 RENKEI-PoP間Disk-to-Disk理論転送性能を1GBpsで設計

ファイルシステムIO性能
Write
16GB

Re-Write

750

1030

単位 (MB/s)
Read

Re-Read

800

810

CPU

Core i7 975 Extreme (3.33 GHz)

Memory12GB (DDR3 PC3-10600 , 2GB*6)NIC

10GBAS E-SR or LR

Sy stem Disk

500GB HDD

Storage

30TB (RAID 5, 2TB HDD x 16)

OS

CentOSRENKEI-POP配備状況
RENKEI-POP設置拠点（設置順）
東京工業大学 (titech, titech2)
大阪大学 (osaka)
国立情報学研究所 – 千葉 (nii)高エネルギー加速器研究機構 (kek)名古屋大学 (nagoya)
筑波大学 (tkb)
産業技術総合研究所 (ais t)
東北大学 (thk)Storage Federation in RENKEI Cloud A single system image by using Gfarm FS
 File movement & replication between RENKEI PoPs via

SINET3
 GSI-based user authentication

Account integration with SCs (TokyoTech etc.)
RENKEI-PoP accountGfarmファイルシステム
 オープンソース広域分散ファイルシステム

http://sf.net/projects/gfarm/ 広域で性能がスケールアウトするファイルシステム
ファイルサーバ，クライアント追加によるスケールアウト ローカル（近いサーバへの）アクセス優先，(自動)ファイル複製 Better NFSとしても利用可clientclient

gfmd
clientclientclient

clientclientclientclientgfmd
clientclientclientclient

gfsd

gfsd

gfsd

gfsd

gfsd

gfsd

disk

disk

disk

disk

disk

disk

ファイル自動複製機能
 Gfarm-2.4.1以降でサポート（祖先の）ディレクトリの拡張属性で複製数を指定
 Close時に自動的にファイル複製を作成% echo -n 3 | gfxattr -s / gfarm.ncopy

更新型複製間一貫性制御
 Gfarm-2.4.0以降でサポート
 ファイル更新時，古いファイル複製を自動的に更新
 ファイルを更新しても複製数は変わらないクオータによる利用制限
 Gfarm-2.3.1以降でサポート
See doc/quota.en 管理者（gfarmadm）が設定可能
 ユーザ，グループごと

利用容量，ファイル数の制限
 ファイルによる制限と複製も考慮した物理制限
 ハードリミットと猶予期間のあるソフトリミット
 ファイルオープン時にチェック

注意：越えたら作成できないが，既にオープンしているファイルは容量制限を超えることが可能

XML拡張属性 Gfarm-2.3.0以降でサポート
 通常の拡張属性に加え，XMLを valueとする% gfxattr -x -s -f value.xml filename xmlattr
 Xpathによるdirectory treeのXML拡張属性の検索% gffindxmlattr [-d depth] XPath path

障害対応
 メタデータサーバのリブート，故障，フェールオーバ


書込オープン中のファイル以外は，アプリケーションはメタデータサーバの復旧を待って正常続行

 ファイルシステムノードのリブート，故障

そのファイルシステムノードのファイルをオープン中のプロセスを除き，ファイル複製，利用可能なファイルシステムノードがある限り正常続行

 アプリケーションの障害

オープン中のファイルはその時点でクローズ

局所的ディスクのNo space対応
 Minimum_free_disk_space

デフォルトでは空きが128MB以下の場合，書込対象とならない Readonly

空きが少なくなってきたらreadonly（＝強制的に利用率100%）にすることによりリスクを減らせる
 見かけ上利用率100%にしているだけなので削除は可能
Samba VFS for Gfarm
 Gfarm2fsを利用しなくてもSambaからGfarmを利用するためのモジュール
 2011/12/30に実験的公開

Gfarm GridFTP DSI
 Globus GridFTPで Gfarmを利用するためのストレー

ジI/FGridFTPはGSI認証，データ接続認証，EBLOCKモード導入による並列転送などFTPの拡張[GFD.20]

 http://sf.net/projects/gfarm/ JLDG (Japan Lattice Data Grid)で利用
 GSI認証であるため，サーバにアカウントを作成する必要なし
 Anonymousおよびclear textでの認証も可能

Debian packaging
 Squeezeのパッケージへの取り込み

Gfarmの運用事例
 InTrigger（情報爆発科研プラットフォーム）
 はこだて未来大，東北大，筑波大，東京大，NII，東工大，早稲田大，慶応大，京都大，神戸大，広島大，九州大，九工大
 Gfarmファイルシステム
 メタデータサーバ（MDS）：筑波大ノード
14拠点，239ノード，146 TBytes
 RTT ~50 msec
 一年以上安定稼働中！！
% gfdf -a
1K-blocks
Used
Avail Capacity
Files
119986913784 73851629568 46135284216 62%802306

メタデータ操作性能[Operations/sec]

筑波大
15 nodesはこだて未来大6 nodes
東北大
九工大
16 nodes 10 nodes

4000
神戸大
京大
2 nodes 11 nodes

3500
3000

京大
25 nodes慶応東大
13 nodes 11 nodes

2500

広島大
11 nodes

2000
1500

3,500 ops/sec

1000 NII
16 nodes500

51015
2025303540455055
60
65
70
75
80
85
90
95
100
105
110
115
120
125
130
135

0

1GBのNファイル書込・読込性能
東北大
10 nodes

25000

九工大
16 nodes九大
9 nodes20000
京大
2 nodesRead
はこだて未来大6 nodes

東大
13 nodes15000
広島大
11 nodes10000

慶応
11 nodesNII
16 nodes

5000

Write

91

86

81

76

71

66

61

56

51

46

41

36

31

26

21

16

11

60
1

[MByte/sec]

30000

1GBの共有ファイル読込性能[MByte/sec]

6000

5,166 MByte/sec

5000

九工大
8 nodes

4000

2000

九大
8 nodes

東大
8 nodes

3000

慶応
8 nodes

広島大
8 nodes

筑波大
8 nodes

東北大
8 nodes1000

r=456514641

r =236

26

r=131

21

16116

10

r=8

RENKEI-PoP上でのGfarmデータ転送性能
 MontageデータセットをGfarmで転送した時のスループットを計測
各RENKEI-PoPからtitechへgfrepで複製作成

 単一ファイルにアーカイブ（非圧縮）して転送した結果を紹介
gfarm構成
バージョン

2.3.2

gfarm mds

管理用サーバ@東工大

gfarm fs

CSI-Grid接続RENKEIPoP

認証

ホスト間: 共有秘密鍵
ホスト – ユーザ: gsi認証

通信パラメータ
暗号化通信

gfarm デフォルト
なし

データ特徴
総容量

14GB

総数

6756個

最小サイズ

292B

最大サイズ

27MB

平均サイズ

2MB

平均分散

400KB

Gfarmデータ転送性能 – 結果

750

 titech2, NIIではStorage Write性能に律速

RENKEI-PoP 将来計画
 新学術領域研究「ゲノム支援」のデータ転送基盤として
http://www.genome-sci.jp/
 新型DNAシーケンサにより大量の小容量(数MB〜数百MB)データをバースト的に生成し，データベース化．遺伝研，東大(柏)，宮崎大，東工大で共有

 乱流データ解析プロジェクト
名大ストレージにある乱流データを筑波大に転送して解析

RENKEI-PoPでの研究開発，ノウハウをHPCIストレージへ応用まとめ スパコンのストレージの設計


TSUBAME2.0のストレージ構成の紹介

 大規模データ処理基盤の整備
TSUBAME2.0上でのデータ処理環境の紹介

 大規模データ共有方法


RENKEI-PoP → HPCIのストレージへ