koie blog : Gfarmシンポジウム 2018

日時: 2018-10-26(金) 13:30〜17:53
場所: 市ヶ谷AP
主催: 特定非営利活動法人つくばOSS技術支援センター
告知: http://oss-tsukuba.org/event/gs2018
配信: https://www.youtube.com/channel/UC1KnuA8JpenG7kdL-q_WLlQ
まとめ: https://togetter.com/li/1281389

[2018-10-26 13:30]

Gfarmファイルシステムの最新機能
国立大学法人筑波大学　教授　建部修見

https://www.youtube.com/watch?v=d2Ijv7PG3m4
外部配信中
他と違うところ：データアクセスの局所性を重視、サイレントデータ損傷に対応
利用(共用): JLDG(10.7PB,8site),HPCI(100PB,2site),NICT,クオリティアactive! world。
利用(解析): すばる望遠鏡のデータ解析,メタゲノム解析
2.7.10が最新リリース
2.6.8で書き込み後ベリファイ(数時間後にベリファイ)
バーストバッファ: ノードローカルなNVMeをつかって分散ファイルシステムを構築する
- NVMeはジョブが割り当てられたときしか使えない
- 永続性はすてて性能を重視メタデータはメモリに載せる (postgresqlをやめる)
- 196s → 20s
- 0.3sで構成をつくれる
データ移行支援: 運用を止めずに10PB→100PBに拡張するときに必要な機能を実装した
- 書き込み禁止: ファイルに書けないけどファイルは作れるとか
gfmdレスポンス改善: JLDG 数10PB/日のアクセス linuxのスレッドの実装の問題だったが
IB RDMA
- クライアントのユーザバッファをpin-downして直接サーバから転送できるようになった。
- 1.8倍性能向上
- posix apiだと1.2倍
quota
- グループクォータとディレクトリ単位のクォータを併用できる (xfsはできない)
データ完全性
- 書き込み時にダイジェスト(SHA1とか)を計算
- 読み込み時にチェック異なっていたら lost+found に移動修復
- JLDG 9.9PB 111Mfiles 書き込み後ベリファイで5ファイル検出

分散深層学習を支えるストレージ技術〜AI橋渡しクラウド ABCIの事例と将来課題
産業技術総合研究所人工知能研究センター　主任研究員　佐藤　仁

https://www.youtube.com/watch?v=CnfjLiaEaWc
東大柏に 0.550EFlops 37.2PFlops(DP) 19.88 PFlops(peak) 国内最速スパコン
gfarmも動く (サポートはしてないが検証はした)
建物から設計した
1node = tesla V100 x4 + Xeon Gold 6148 + 384GiB + NVMe 1.6TB + EDR IB HCA x2
1rack = 34 nodes + full-bisection BW fat-tree ; 70kW
inter-rack = 1/3 BWで接続されている
storage
- local: 1.6TB NVMe BeeOnd(like burst-buffer)でまとめることもできる
- parallel filesystem: GPFS (DDN SFA14K) x3
- object storage: GPFSの領域の一部でopenstack swiftをうごかしてS3 like APIを提供。グローバルからアクセスできる。暗号化も。
分散深層学習
- データ並列
  - 同期型パラメータを正確に更新できるので精度が高いデファクトスタンダード
  - 非同期型はやい
- モデル並列
GPU+CuDDN(演算), NCCL2(ネットワーク通信), MPI(プロセスの起動)
Chainer: forward->backword->optimize
ChainerMN: forward->backword->allreduce->optimize
汎化性能: 局所最適化を避けて全体最適化したい
ABCI Grand Challenge
いまどき: linear scaling rule, gradual warmup, LARS
IOのスループットだけでなくメタデータ性能も重要データセットが小さい 1画像70kB 弱程度
学習時にランダムネスを上げるようにする汎化性能のため
chainerだと配列のようにアクセスするのでopen+read+closeが大量発生してしまう。
フレームワークによってはDBをつかうものもある。
ファイルキャッシュを入れると1時間のものが30分くらいになる。
将来課題
- マルチテナントとセキュリティ
- 企業や医療データ
- 資源を動的にユーザグループ毎に棚貸し

[2018-10-26 14:32]

Q: キャッシュが有効なのはなぜ？何度も同じファイルを読んでいる？
A: もっと上のレイヤーでのAPIがあるといいかも。

次世代スーパーコンピュータ向けファイルシステムについて
富士通株式会社　次世代TC開発本部　ソフトウェア開発統括部
シニアアーキテクト　住元真司

https://www.youtube.com/watch?v=Mf1AocSM1uA
A64FX
- 1chip = (12core+1core) x4
- 1世代前のsparc chipに比べて2倍の性能
- Tofu2 -> TofuD
  - そのままもっていくとコスト(シリコンと電力)をくう
  - laneを半分に減らして数を増やした
FEFS for K computer
- 8万ノード 100PB 1TB/s 当時luster1.8
- 性能か信頼性かはユーザが選べる
- stage-in → 計算 → stage-outの3段階 3倍の容量が必要になってしまう
- ファイルの指定が手間
- 計算時間が短かいとデータの移動がムダ(利用効率が落ちる)
ローカルはよりアプリ寄のストレージ → luster-based → アーカイブ
データのライフタイム、アクセスパターン
1プロセスが1ファイルを読み書きするパターン、ファイルをつかってプロセス間のデータ通信するパターンが多い。
SSDの寿命の問題アプリが1日にどのくらい書き込むか重要
intel optaneは性能はいいけど書き込み信頼性はnandと変らず。素子自体は信頼性が上がっているが回路の部分がいまいち。
How SSD based storage shoud be used?
- lifetime, application's access pattern, data sharing in a job, data shareing among multiple jobs, ssd lifetime issue
LLIO (prototype) burst buffer nodeを用意する

[2018-10-26 15:06]

Q :メタデータは2nd storageをつかう？
A: キャッシュとしてつかうときだけ。ローカルなら

[2018-10-26 15:07]

休憩

[2018-10-26 15:16]

オブジェクトストレージ、AI＋IoT＋映像における利用事例
クラウディアン株式会社　取締役COO 本橋信也

https://www.youtube.com/watch?v=sZCT-W_xFCo
日本発だが海外の方が大きくなった。
オブジェクトストレージ
- 大手の通信事業者のメールシステム NOSQL
- amazon S3 とおなじものをつくった -> HYPERSTORE
- ベンチャー企業として賭けに勝った
クラウド事業者向けに販売
P2P 3ノードから
日本だとPBを要求する客は少ない。
容量はEBくらいまでは拡張できるのを確認している。
replication + erasure-coding
バスにカメラ5台をインターネット経由で保存。
AI向け: メタデータとblobをまとめて扱える。
実証実験: 高速道路を走る自動車をリアルタイムで識別してデジタルサイネージを出す。
→駐車場・ショッピングモールでつかいたいという客が。
GPUどうする？クラウドだとレイテンシが → AI BOXをつくった。
4Kカメラ圧縮すると意味がないエッジの処理が必要
交通量の測定をAIで
画角は手動で設定
自動で車線を認識車をカウント速度直進右左折 CSVでデータを送る。
エッジで学習用の画像を切り出してクラウドに貯める。
車の車種はロングテールで自動でタグ付けする必要がある。

Scalityと大規模オブジェクトストレージの運用の実際のご紹介
スキャリティ・ジャパン株式会社　セールスエンジニア　仁戸潤一郎

創業はフランス 2009
メールサービスのストレージからはじまった
製品: RING ZENNKO
データはつかって価値が出る。
データはオンプレに置いてワークロードはクラウド。
object storageは容量重視、flashは速度重視、NASはあまり市場はない。
NASは人間のスケール。flashはオブジェクトストレージはアプリが相手。
RING 汎用x86 linuxで動く。ソフトのみ提供。NFS,SMBでもオブジェクトにアクセスできる。
P2P CHORD
アプリケーション RINGコネクタサーバストレージサーバスーパーバイザー
コネクターはブートストラップノードリストをもっていてリクエストをなげる。
メンテナンスタスク
- balance ノードのつけはずしのときにデータを移動する
- proxy
- rebuild 最新のバージョンをもっているか定期的にチェックする
- repair ディスク障害時にインデックス情報から再レプリカをつくる
- purge 古いバージョンの物理削除
  - オブジェクトはコンテナファイルに保存しているのでinodeを消費しない
- relocation
  - デフラグ
バックグラウンドタスクの負荷調整
国内事例: KDDI iphone mailでつかっている
キースペースの設計が必要でシミュレーションで確認する。障害時に負荷が分散するように配置しないといけない。サポート体制が重要。
オジェクトストレージはアプリケーションの関する知識が必要。

[2018-10-26 16:16]

Q: 物理的な配置は?
A: データセンターをまたいでも構成できる。スプリットブレインになってもデータはアクセスできるように複製している。ラック単位・シャーシ単位でも考慮できる。

HPCI共用ストレージにおけるディザスタリカバリ、
データ二重化運用による高可用性と災害対策の実現
国立研究開発法人理化学研究所　開発研究員　原田浩

https://www.youtube.com/watch?v=9i76p_njrOc
8/23 台風20号電源障害
8/31 落雷で停電
HPCI共用ストレージそろそろ運用もおわるけど
- 補足:運用が終わるのは京でHPCIは続くらしい。認証基盤だし。
通信はGSI(grid security infrastructure)で暗号化している
物理的には100PBくらい、二重化しているので使えるのは50PBくらい。
SINET5
メタデータサーバは東大と理研で二重化
フェイルオーバは自動化されてないのがつらい
データ破損があっても1営業日くらいで通知できる体制になっている。ユーザにはデータは1週間くらい保存するようにいってるけど。
スパコンでつくるデータはお金がかかるのでデータ消失は防ぎたい。
理研台風
- 受電設備に水が入って止まった
- 京コンピュータが止まったがストレージは止まらなかったのは幸運だった。
- 仮復旧で停電する可能性があるので全マシンを止める必要があったのでマスターを理研から東大にフェイルオーバー。readonlyに。
柏落雷
- 東大にマスターがなかったのでたすかった。
重度障害報告はしなくてすんだ。
IPアドレス変更・ドメイン変更のときはさすがに止めた。
次の増強時は容量に余裕があるのでサイト内で二重化できそう。
計算機センターに設置できるのはキャッシュメモリだけになって、ストレージは外部に、ということになりそう。場所の問題。
セキュリティレベルは民間レベルはむつかしいのではないか。お金の問題だとおもうけど。

[2018-10-26 17:01]

休憩

[2018-10-26 17:07]

パネル：ポストムーア時代のストレージシステム

建部

ポストムーア時代に想定されるストレージへの要求と問題点
その問題点を解決するために必要な技術、デバイス
ストレージの向かうべき方向

佐藤

スパコン業界からは「ストレージなんでどうでもいい」とおもわれているのではないか。
高速なメモリ(HBM)をどう生かすか
NVDIMMをチェックポイントにどうつかうか
HPCコンテナ -- オールフラッシュストレージ -- オブジェトストレージオンプレ・クラウド
トラディショナルなストレージだとユーザ・グループ単位の認証になるが、APIキーのようなものも必要。

住元

電力vs性能が重要
アメリカでは many-core と gpgpu の二種類
さまざまなarch
- ノイマン型
- アナログ型
- ニューロ関係
- 量子
こういうコンピュータとストレージをどうつなぐ？
なにがひつよう？
- 移動データを抑制する
- 主記憶の電力を抑制しながら大量データ処理
- 蓄積型からストリーミング型のデータ処理に

本橋

flash hdd tape が連携
NBC テープアーカイブをHDD化した。トランプの若いころの映像を探すのに手間どった。
メタデータデータの中身の情報のことタグ付け自動で

仁戸

ムーアの法則が終わって何がこまるのか？
クラウドに資本が集中する
データはまだサービスにくっついている
個人にデータのものになるとよいのではないか。(おくすり手帳のような)

原田

地理的な壁を越えたい。
軽いストレージがほしい。床の耐荷重が問題になる。半分くらいしか積めない。

建部

まとめ

質問

Q: コンピューティングのためのストレージとストレージとしてのストレージポストムーアで分散になってストレージのブレークスルーはなに？
A:
- 佐藤スパコン屋はデータの使い方を考えてないのが問題データの整理を自動化する方向に。
- 住元ストリーミングで計算蓄積しない方向へ
- 本橋 GPUもストレージもひとつの箱で客に提供したい
- 仁戸ひとつの箱にはおさまらないのでネットワークの中にストレージがふくまれる融合する
- 原田スパコンセンターはバッチスケジューラだけでいいのか？データの場所で処理する方向に。

[2018-10-26 17:53]

懇親会は鳥元。