- http://oss-tsukuba.org/event/gs2017
- 2017年12月22日(金)
- 筑波大学東京キャンパス文京校舎 122講義室
- 主催: 特定非営利活動法人つくばOSS技術支援センター
- https://togetter.com/li/1182456
司会 NPO 松山
[2017-12-22 13:31]
Gfarmファイルシステムの概要と最新機能 / 建部 修見（筑波大学）
- 19000 downloads since 2007/03.
- オーストラリアでもサポート(Libre solutions Pty Ltd; 主にdebian package担当)
- HPCI共有ストレージ 大学間 〜100PB
- release 2.7.8が最新
- 書き込みキャッシュストレージ支援
- クライアントとストレージのあいだにキャッシュをはさむ。
- write back
- キャッシュの仮想負荷よりもストレージの仮想負荷を上げてキャッシュに書き込まれるようにする。
- データ移行支援
- ストレージを書き込み禁止にできる。
- 書き込み禁止だけどファイルの複製はつくれる。
- Gfarm/バーストバッファ
- 計算ノード上のNVMeを分散ファイルシステムにする。
- 一時データ用
- メタデータは永続化しない・冗長化しない (どうせジョブの動いているあいだだけでいいので)
- 5400 iops (pgsql+journal+slaveMDS) -> 12000 iops(-slaveMDS) -> 15000iops (永続化なし)
- ファイルシステム構築撤去の高速化
- 構築0.31s 撤去0.19s
- InfiniBand RDMA
- 内部バッファをつかった転送とユーザバッファ(pin downed)に直接転送するのもできる。
- max 1.8GB/s
- max 1.2GB/s (POSIX API)
- ディレクトリクォータ
- ディレクトリ単位のファイル数・サイズの制限
- XFSのとはちょっとちがう
- パーティションにみせかけているので、ディレクトリ間のmv/linkはできない
- 完全性
- digestを書き込み・読み込みで計算してチェック。
- 破損していたらlost+foundに移動。
- 書き込み後6時間後に読んでチェッックしている。
- 性能は -10%
- 実際にIOエラーがないのにファイルが壊れたことがあった。
- クラウドストレージとの連携も進行中
[2017-12-22 13:57]
大規模言語資源を活用した自然言語処理 / 井之上 直也、山口 健史（東北大学）
- 乾研究室でgfarmをつかって研究している。
- 言葉がわかるコンピュータ
- メンバー 40名
- 形態素解析、構文解析、述語構造解析・照応解析・省略語解析
- 言葉がわかるとは? -> 行間を読むこと
- 「庭に洗濯物を干したとたんに雨が振ってきた」
- 目的・条件を知識からみちびいて、残念だったという推論ができる。
- どうやって膨大な知識をあつめるか?
- トレンド: webから知識をあつめてくる。
- 言語構造解析による大規模知識獲得: パターン(フレーズ)とインスタンスのマトリクスから知識を抽出
- 意見解析: 文章からトピック賛成・反対しているのかを推論する。うまくいかない例: 言論弾圧 vs 言論の自由を抑圧 表現がちがいすぎてうまくマッチングできない例
- サイレントマジョリティの意見の予測: ソーシャルネットワークから意見を表明してない人の意見を推定する。
- 論述問題の自動添削: 記述力を養うためには添削によるフィードバックが必須
- うまく言語表現の多様性のせいでマッチングできない問題はdeep learningで解決する方向.
- 例: the girl gasped -> she heard the news.
- 典型的な処理
- SNSデータ: JSON圧縮で14TB。これを基本的解析+フィルタ+頻度して実験データをつくるところまでgfarmで。そのあとはCPUサーバへ。
- gfarm+GbEで構築。データの局所性が利用できるのがメリット。
- 学生はまずpython。makeになじみがない。pwrakeをつかってもらうのはむつかしい。 -> シェルをたたいてがんばる。
- gfwhereでデータがあるノードをさがしてsshで計算させる、というのがメイン。
[2017-12-22 14:21]
休憩
[2017-12-22 14:30]
HPCI共用ストレージ東拠点の機材更新に伴うデータ移行について / 中 誠一郎（東京大学）
- 5年ぶりの機材更新: 西:理研(AICS) 東:東大 SINET5
- 東大のスパコン室に空きがなく、新旧のストレージ機材の共存は不可
- パイロットストレージのラックをつかってデータ移行
- データ移行が終了->撤去->新規ストレージを設置 を順にくりかえしていく
- データ移行方式
- 複製数1のファイルが多数存在 平均1.3 (ユーザまかせにしたら、こうなってしまった)
- moveではなくcopyで。 gfprep --mmオプション + 余剰レプリカを残す
- replicainfo方式: COMPLEMENT_GROUP=移行元以外 こっちの方が速度が出た
- まる1年かけて移行: 最初のころは並列度1で 17T/day。並列度あげて96TB/dayまででた。
- gfprepはファイル数が増えると遅くなるっぽい。 -> 建部先生に相談して replicainfo に。
- replicainfoで 3-15TB/dayしかでないレスポンスも悪化(gfarm 2.6.21)。 改良して 152TB/day (gfarm 2.6.23)
- 移行ストレージはもったいないのでログインノードに転用予定。
[2017-12-22 14:50]
- Q: サイレントデータコラプション対策した?
- A: write verifyで確認している。
[2017-12-22 14:51]
[2017-12-22 14:52]
HPCI共用ストレージにおける階層型ストレージの導入構想 / 原田 浩（理化学研究所）
- Gfarm日本征服計画
- AICSも機材更新中
- azureにアーカイブサービス実証実験中
- RAID6(8D2P;100TB/disk) x 58set x11set
- UNCAIによるクラウド基盤の提供
- Gfarmの階層化支援機能
- 余剰レプリカ自動削除機能をつかてキャッシュぽくする。
- replica_check_remove_grace_used_space_ratio & replica_check_remove_grace_time
- 二次ストレージへの一次書き込み抑制
- 一次書き込み先選択アルゴリズム: busy hostには書かないようになっている
- 手離れのいいGfarmサービス/Gfarmサーバのワンストップサービスが求めれれる。。。
- 文科省から3年間はエビデンスを残すように指導がある -> スピードよりも容量がもとめられている -> クラウド
- Azure(西日本リージョン)にgfarmスプールサーバをおいて実証実験中 (メターデータは東大)
- azure VM -> client: 2Gbpsでている(たぶん帯域制限をくらっている)
- 速度が出てないが調べてみたらおそいプロセッサがまざってるっぽい。
- クラウドストレージはバイト単価も安くなってきたし、予算の年度区切り問題がなくなれば。
[2017-12-22 15:15]
[2017-12-22 15:17]
Gfarmを加速するDDN GfarmScaler / 橋爪 信明（DDN）
- SFA4KXE,SFA7700XE: バックエンドはXFSで、Gfarmをコントローラ上でうごかす。
- 14KXE/1VM: wriet 7GB/s read 8.5GB/s
- pacemaker/corosync で XFSフェイルオーバー
[2017-12-22 15:30]
- Q: 1MBからブロック変えたら?
- A: 1MBより小さいとダイレクトIOがつかえなくて性能が落ちるはず。ブロックサイズはRAIDを組むときのchunksizeに関係。
[2017-12-22 15:32]
[2017-12-22 15:33]
ひまわりデータ解析を支えるPwrake/Gfarm / 村田 健史（NICT）
- 気象災害は人口あたりでみるとアジアは多い。
- http://himawari.asia
- 公開されてないデータがあるのでは? -> データを1bitも隠さない・リアルタイム更新・だれでも見られるをポリシーに。
- 日本なら10分以内に更新される。年間100万アクセスある。最大のユーザは気象庁?
- ズームインしたときの画像は常につくりつづけている -> 3年間で73TB。ファイル数が多いのでinodeが足りなくなる。
- 映像IoTがGfarmに期待すること
- カメラをあらゆるところに設置する
- raspinihaH264のエンコーダが載っていて高性能
- ドライブレコーダのようにリアルダイム伝送できている
- hpvt(high-performance vide transfer)映像伝送ツール
- ACK 300msごとにネットワーク帯域を監視して、動的にエンコードパラメータを変えている。映像が途切れない。
- raspiをつかっているのはOpenCVで画像処理できるため。
- 2.5GB/day
- 処理・保存でpwrake/gfarmの利用可能性
- パッケージングして売れそうな予感
[2017-12-22 15:51]
- Q: raspiはくるしくない?
- A: FHD 30fpsはくるしい。730p 30fpsくらいならなんとか。
- Q: ディレクトリ毎にメタデエータサーバを変えたら解決するのでは?
- A: そんな金はないし、そこまでしてgfarmしてつかわなくても。。。
[2017-12-22 15:56]
休憩
[2017-12-22 16:11]
パネル討論「ファイルシステムのこれから」
- モデレータ: 建部 修見（筑波大学）
- パネリスト:
- 住元 真司（富士通） Post京
- 井原 修一（DDN） Luster
- 曽田 哲之（SRA） gfarm
- 石橋 拓也（創夢） gfarm
- 守分 淑子（数理技研） gfarm
守分
- 数理技研の紹介
- UNIXの移植
- 1983年 socketがでてきた
- 1993年 mosaicがでた
- ファイルシステムをやるようになった
- 2003年 gfarmの開発に関係するように
- ディレクトリの名前管理は難しい。1ディレクトリに1万個もファイルつくられてこまる。（曽田さんコメント：Gfarmのディレクトリ構造は、オンメモリ・赤黒木なので、1万でも100万でも困りません)
- readdirとファイル削除の競合は難しい問題 readdirのAPIが変えられないのがつらい
- mmapは癌 マップされているとread/write権を剥奪できなくてつらい
- 50年前のAPIをひきづっていて、変わらないのはいいけど、そろそろ変わってもいいのでは?
- hard linkはなくてもいい。
- ビッグデータで小さな大量のファイルのあつかいをなんとかしたい
石橋
- 2002年 gfarm v1 の開発にかかわる
- 当時はsyscallをフックしてたのをfuseをつかうように
- もっとも大切なことは: 簡単に普通につかえること。普及していること。
- 分散ファイルシステムはローカルディスクよりも速い!?
- 無限のファイル数をあつかえるように。メタデータアクセスも分散させて。
- ユーザ管理・アクセス制御・セキュリティを簡単に。
- Gfarmの利点: POSIXインタフェースの妥協なき実装
曽田
- 1996-2000 SCore
- 2000/11- Gfarm v1
- 2004-2007/3 Gfarm v2初期実装
- (予算が...)
- 2008/10- Gfarm
- だいじなこと: 信頼性、性能、スケーラビリティ、拡張・移行が用意(リバランスが不要)
- クラウドベンダーごとのストレージ、アプリケーションごとのストレージ、用途別のストレージが乱立しすぎ
- 汎用の並列ファイルシステムに収束してもいいのでは メタデータ集中型・メタデータ分散型
- 同期複製機能がほしい (現状はgfarmは非同期複製)
- fine-grained lock (理研の64coreだと性能が出せてない)
- メモリ外メタデータ (gfarmはメタデータがメモリに載っているのでスケールしなくなってる原因)
- おもってたよりメモリが安くならず
- リモートアクセスでの性能向上
- 遠隔ファイルシステムとしては使われているほう
- できる最適化ができてないものがある
- 各クライアントでうごかすNFS gateway
井原
- 2010年 DDN入社 (その前はSUN; OracleではHPCできないということで)
- LustreとH/Wをインテグレーションして販売してた
- 欲しい機能が実装されるのを待つのではなくDDN内でLustreの開発をするように
- 開発メンバーは6人くらい
- オープンソースの開発ではプライオリティづけがむつかしい
- 欲しいデータに安全に確実にアクセスでいることが重要
- Lustreをみているとかなり足りない機能がおおい (性能にふりすぎている)
住元
- 1986-1997まではUNIXいじり 分散FTフィルシステムつくた(log based)
- SCore
- RCCS
- PACS-CS
- 京 MPI FS
- ファイルシステムの現状と課題
- VFSがでて作りやすくなったけどkernelオーバヘッドが
- メモリ階層を考慮すべき
- OSのプロセスだけでなく、仮想マシンとかコンテナとかLWKの考慮
- Luster: posixセマンティック確保のほか、linuxオーバヘッド回避の話題がおおい
- 用途別につかいわける時代になっている
- ローカルは軽く・高速に
- VFSじゃま: アプリケーション特化型・OSバイパス → ユーザレベルのファイルシステム
- NVMeが持つ機能をもっとつかおう
- ネットワークファイルシステムはユーザレベルでOSバイパス。
建部
- POSIXやめましょう。
- Q: (西) gfarmの普及を阻害している原因は?
- A: むつかしそうだから? ユーザが構築できない。 CentOS/RHのバイナリ配布がないのが問題。 世界に配信すべき。
- Q: (原田) gfarmの最大のライバルはクラウドストレージでは? ここ数年でAPIが高度化している。 scatter/gatherもできる。 データ移行もしやすく。 gfcopyを拡張して。
- A: gfarmもMacからつかえるといいなぁ。 クラウドストレージはGとかAとか以外は共通APIがでてきてもいいなぁ。標準化活動が必要。
[2017-12-22 17:33]
