koie blog : IPABセミナー / Gfarm Workshop 2010

http://datafarm.apgrid.org/event/gfarm10/
http://datafarm.apgrid.org/event/gfarm10/program.html (当日の資料もここに)
東京工業大学東工大蔵前会館蔵前ホール http://www.somuka.titech.ac.jp/ttf/

TSUBAME2.0のスカラー・ベクター混合型アーキテクチャによるマルチ・ペタフロップス計算の可能性とバイオインフォマティックスへのインパクト / 松岡聡(東工大)

GPUをメインにしたい知見が話の中心。
1.0 Top5004期連続日本一7期連続性能向上世界初
アップグレード(GPU追加)をしたので寿命が伸びた。
CELLとかmulti-coreでない理由
strong scaling(強スケーリング)が重要
GPU=multithreaded vector
地球シミュレータはvector型だがスケールしない。
GPU: killer vector micro
vector型の復権か
vector型はピーク性能に対して実性能がいい→超まぬけ議論
latency bound vs. bandwidth bound?
もちろんアプリケーションによるが、だいたい95%はlatency bound。(メッセージバッファの埋まり具合から)
BGのように問題をどんどん大きくする方法はweak scalingだが、latencyは改善できない。
weak scalingでいいじゃん→でもO(n^2)の問題だと規模を大きくすると実行時間が問題になる。
latencyを短かく
- Fat nodeをつかう
- 近接通信をつかう
- RDMA
latency隠す
- dynamic multithreading OLD:dataflow NEW:GPUs (レイテンシの問題をバンド幅の問題にすりかえる)
アルゴリズムをlatency tolerantにする
- implicit解放をやめるとか
- 統計的手法にするとか
- global bandwidthを用意してあげる
計算密度とメモリアクセス密度
計算寄りn-body メモリアクセス密度寄りCFD/FFT
昔のスパコンはpower gatingをしてなかったのでピーク性能が低くなってた。
IOの90%はcheckpointかtemp(ジャガーのデータ)。ステージングにつかっているのは10%ということに。
なのでノードにflash mem 200GBをつけた。
とにかくネットワークバンド幅をリッチに。ふつうのPCだと弱い。あっても4Uの電力ばかぐい。
レイテンシをへらすには小さくまとめる必要がある→水冷ラック(部屋は人間用の空調のみ) マシン自体は空冷。PUEを上げる原因に加湿がる。冬場は冷却効率がいい。マシンは1Fか地下に置くのがいい。最上階に置くのはよくない。
計算ノードのアーキテクチャはかなり変態らしいが9月の製品発表までヒミツ。
ストレージサーバ RENKEI-PoP(point of presence)(アプライアンス) でデータ転送セキュティポリシの違いの吸収
地球シミュレータのデザインはたいへん参考にしている (vector machineの先輩として)
BG/Qに対抗できるぜ。
経済的な予測はできるか？テクノロジーがかわるとパラメータがかわったり、アーキテクチャがかわるとパラメータがかわったり、まだだれもできてない。

PUEが低いのは水冷ラックで加湿が必要ないのもある。加湿器が電気をくうらしい。

NVIDIA(R) Tesla(TM) BioWorkbenchのご紹介 / 平野幸彦(NVIDIA)

「ンビディア」とか「エヌビデオ」とか、なかなかちゃんと読んでもらえなかった。
GeForce ゲーム向けボードメーカーが1年間保証
Quadro OpenGL最適化 nvidia3年保証
Tesla nvidia3年保証
G80→GT200→Fermi パフォーマンスはだいたい2倍ずつふえている。
M2050 巨大ヒートシンク(ヒートパイプつき) 筐体のファンで冷す Data Center product
C2050 強制空冷 workstation
GTX480はC2050と比較してdouble precisionが半分程度の性能 (おなじfermi世代だが)
最近はC/Fortrunで普通に書くとGPUを使うようにしてくれる製品もあるが、普通はCUDAをつかって書く。

Gfarmファイルシステム最新機能概要 / 建部修見(筑波大)

広域でもスケールアウトする。NFSとしてつかえる。
サーバもクライアントも追加すればスケールアウトする。
ローカルアクセス優先。ファイル複製。
gfarm 10年目!
グローバルユーザ名がある(組織間の違いを吸収)
運用中にノード追加可能
自動ファイル複製
XML拡張属性 XPath検索
メタデータサーバは1台(active-standby可)。ただopen/closeのときだけ。
InTrigger(情報爆発)で大規模プラットフォーム 146TB 1年以上安定稼動。RTT ～50ms。
メタデータ操作性能ひたすらディレクトリをつくる max3500ops/sec(だいたい3000くらい平均)。100ノードくらいでサチってるか。
read性能 25000MB/s write性能4500MB/s メタデータサーバはだいじょうぶ。
1GBのフファイルを同時読み込み複製をもつことでスケールする 4GB/sくらい。
close時に自動コピーする。mount時に複製の数を指定する。
書き換えがないことがわかっているならより高速化できる。
quotaがはいった。複製も含めた物理制限もある。open時にチェックするので、append writeすると越えられる!
MDS障害: 書き込みopen中以外は復旧をまって続行可能。書き込みopen中のはclose時にエラーになる。
NOSPC対策: 残り少ないと書き込み対象にならない。readonlyにして書き込み不能にしてしまう。
Samba VFS for Gfarm
debian packaging
make + GXP並列シェル
Pwrakeワークフローエンジン。Rakeの拡張。
HDFSよりもgfarmがちょっとはやい。HDFSをつかわなくてすむとなるとgfarmだけで済むのでfile copyが不要に。

GXPとオーバーレイ分散ファイルシステムによる，データ集約的計算環境の実現 / 田浦健次朗，鴨志田良和，横山大作，柴田剛志，頓南，崔升準(東京大)

データ集約的計算: 第4のパラダイムとも (第3はシミュレーション)
プログラムは部品のあつまり(ブラックボックス)からなるので性能予想がむつかしい。
black-boxを簡単にくみあわせられる
エラー箇所の特定が容易
失敗したところから再開できるような耐故障性
環境(ノード数、ファイルシステムが共有かどうか)にあわせてワークフローを書き換えたくはない。
複数のファイルシステムをユーザレベルでつなぐアプローチ。
ssh/torque/sge/conder/sh → GXP → GXP make
make -jを分散環境に拡張したもの。

評価軸	nfs	Lustre(GPFS)	HDFS	Gfarm
posix API 無修正	y	y	n	y
para read/write	n	y	y	y'
para meta data io	n	n	n	n
domain nat/frewall	-	-	n	n*
colocation	y''	y''	y	y

ゴール: いつでもどこでもファイルシステム
fuse sshfs
gmount: sshfsベースのオーバーレイ分散ファイルシステム
ユーザの要求:自分の所とスパコンを簡単につなぐソリューションが欲しい。
- うちのスパコンですべて済まそうというのはまちがい。
プライバシーデータのことをかんがえると、こっから出してはいけない、とか制限はかけたい。
make以外のGXPフロントエンドもかんたんに書けるようになっている。
セキュリティー的にどうなのか: おれおれプロトコルはうけいれにくい。

GEO Gridにおける衛星データアーカイブの構築と運用 / 山本直孝(産総研)

どんな木をどれだけ植えればCO2がどれだけ吸収できるのかは、じつはよくわかっていない。
MODIS まいにち全球観測
ASTER より高解像度
gfarm ※write once/read many環境

	本数	故障本数	MTBF
500GB	448	36	41.6
750GB	144	4	253
1TB	888	17	28.2

これはだいたいメーカーどおり。
ストレージと計算を分ける方向で検討中。
ASTER(200TB)→PALSAR(2PB)大地にのっているやつ

Gfarmを用いた分散ログ解析環境とその利用 / 村上直(KEK)

狭域・中規模データ、better NFSの話
2TB、同一ハブを共有する規模
2TBは小さいけど工夫は必要なレベル
当初はデスクトップPCにためこんでいたが、データコピーの時間がかかるとか、解析をもっとちがうとこでやりたいとか。
NAS遅い、SAN高い、B社からの提案でgfarmに。
2ヶ月に1度ほどフリーズする。syslog-ngをgfarmに書く。log rotateは1日ごと。syslogをローカルに書いて圧縮してgfarmにコピーすることに。(1GB/day)これでA安定稼動している。
DBPowder
MDSのバックアップはとってないけど、データのレプリカはあるので復旧できるとおもっている。
ログ解析は一旦RDBMSに入れてやっている。直接hadoopとかつかってという研究もあるが、自分のところの研究がRDBなので。

ペタバイトスケール大規模データ処理にむけた東京工業大学の取り組み / 佐藤仁，滝澤真一朗(東工大)，松岡聡(東工大・NII)

tsubame: 0.02%が1TB以上をつかっている

NICT(情報通信研究機構)のサイエンスクラウド / 村田健史(NICT)

縦割りプロジェクトのよるメガサイエンスの孤立
異なるメガサイエンスの融合は衝突のみを生み出してきた。
クロスメガサイエンスデータハウス
オーロラは人工衛星で観測できるけど磁気圏はみえないからシミュレーション。これを合成する。
地球環境のセンシングは人間のいないところ→ネットワークは貧弱 (街中での観測は都市環境の観測) センサーネットワークの研究は理想的すぎ。
gfarmは大規模ストレージの面と並列処理の面とがある。
gfarm1で構築していたが24時間連続で計算しているが規模がおおきくなってきてだんだんおいつかなくなってv2にしたい。
NICTは大きな組織なので他のグループのことはよくわからない。

JGN2plusとGfarmによるNICTサイエンスクラウド広域分散ストレージ / 森川靖大(NICT)，山本和憲(愛媛大)，佐藤建，井上諭，坪内健(NICT)，建部修見(筑波大)，崔超遠，加藤久雄，亘慎一(NICT)，木村映善(愛媛大)，村田健史(NICT)

容量単価を最適化したデータ保管用FSN dell server + eSATA RAID5箱を RAID0で組む
データ処理用CN/FSN スピード優先
データ参照用CN gfarm2fs,samba,http,ftp
gfarmを東京ー沖縄(L2)だと9MB/sくらいしかでない。NASとしては使えない。
ユーザによってつかうディスクを制限したい。(たとえば大規模データ保存と計算用とでディスクセットを変えたい)
スパコンだと10GB/sくらいのデータをさばけるようにならないとだめ(貯められるだめではダメ) by 松岡
ステージングする時間も考えよう by 松岡

サービス共通基盤としてのGfarmの利用と課題 / 大岸智彦，西谷明彦，寺下雅人(KDDI研究所)

顧客は直接gfarm clientにはならず、アプリケーションサーバ経由で利用。
運用コストがさがればいいかなぁと。運用スキルを含めて。

初めてのGfarm --- 初心者のためのGfarm / 江波均(ベストシステムズ)

v1はfindかければMDSが死んでも復旧できるけど
v2はパスが戻せないのでlost+foundに回収できるくらいのコマンドはある。

パネル「皆が欲しいストレージクラウドとは」

モデレータ
- 小西史一(東工大)
パネリスト(left to right)
- 高杉英利(NTTコミュニケーションズ)
- 建部修見(筑波大)
- 西谷明彦(KDDI研)
- 松岡聡(東工大)
- 村田健史(NICT)
- 山本直孝(産総研)

クラウドストレージのユーザ像について
ストレージクラウドが持つべき機能について
あなたにとって、理想のクラウドスレージとは

= 1.クラウドストレージのユーザ像について

高杉
- 金融関係は1ビットもちがってはいけない。
- 大容量はスパコンがひっぱっていたが、いまは商用の方がひっぱっている。いまは300PBくらい。はやくEBがほしい。
建部
- e-scienceの研究者、mapreduceつかい、facebook/gmail/dropbox/picasa...
西谷
- 機密情報をクラウドに移すのは不安。クラウドに暗号化するよりも自社設備で平文。(自前主義) クリティカルじゃない方面でつかわれていくのか。
松岡
- ストレージってなに？
- 計算能力(flopos) vs データ処理能力(io,space)
- HPC in the Cloud.
- データセンターとスパコンとの違いはあるのか? 規模の違いはちがわない。
- Top500にクラウドがはいったことはない。
- why?
  - Macho factor
  - Technical
  - Financial
  - Operational
- 現状はHPCではクラウドはつかいものにならない。
村田
- センサーネットワークの研究
- センシングの研究
- 数100の画像をみてなにがたのしいのか!
- まずはネズミがかじらないケーブルがほしいとか、1Gbpsのネットワークとか、現場の観測している人はそういうレベル。
- 個別対応できるストレージがないとだめだ。現場の要求は多様。
山本
- ユーザがふつうにつかえることが重要。とりあえずposix API。

高杉
- ネットワークのQoSはおとせばいいけど、ストレージは時間軸がある。どのくらい保存しなければいけないとか。
松岡
- インターネットはたくさんのユーザの同時利用でスループットはでるようにアーキテクチャができている。
- パラメータサーベイでもBWはいる。gaussianはtmpファイルをどんどんつくるのでたくさんのユーザが動くとたいへん。
- クラウドはスモールビジネス+B2Cに特化している。CPUの割り当てもばらばら。これは耐故障性もある。でもBWがでなくなる。
- クラウドでハイエンドアプリケーションをどうやったら動かせるようになるか研究がベンダーは始めている。

= 2.ストレージクラウドが持つべき機能について

高杉
- クラウドはサービス。うれてるものがいいもの。だからdebianに登録した!
- 30件くらいまずそうな特許がある。10件くらいは継続監視中。
- 品質とか保守とか重要
建部
- 高速、高可用性、高信頼、安全性、green,,,
西谷
- 物理的な分散。移動体のときでも最適なとこから。
松岡
- 技術で安くするか、高付加価値か。でないと中国アメリカにのみこまれてしまう。
- じつはクラウドストレージはとてもボッタクリ。
村田
- 地球観測はデータは絶対失いたくない。
- シミュレーション屋はそこまでは。再計算すればいいから。
- 個人がデータをかかえこんでしまって、その人が死んだらデータも死んでしまうこともよくある。
- クラウドとかアクセス方法が標準化されたらありがたい。
山本
- 重要だけどあまりつかわれないものアーカイブして電気をくわないようにしたい。