Gfarm

Gfarmシンポジウム 2018

IMG_20181026_130956IMG_20181026_131153

[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]

休憩

IMG_20181026_170246

[2018-10-26 17:07]

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

建部
  1. ポストムーア時代に想定されるストレージへの要求と問題点
  2. その問題点を解決するために必要な技術、デバイス
  3. ストレージの向かうべき方向
佐藤
  • スパコン業界からは「ストレージなんでどうでもいい」とおもわれているのではないか。
  • 高速なメモリ(HBM)をどう生かすか
  • NVDIMMをチェックポイントにどうつかうか
  • HPCコンテナ -- オールフラッシュストレージ -- オブジェトストレージ オンプレ・クラウド
  • トラディショナルなストレージだとユーザ・グループ単位の認証になるが、APIキーの ようなものも必要。
住元
  • 電力vs性能が重要
  • アメリカでは many-core と gpgpu の二種類
  • さまざまなarch
    • ノイマン型
    • アナログ型
    • ニューロ関係
    • 量子
  • こういうコンピュータとストレージをどうつなぐ?
  • なにがひつよう?
    • 移動データを抑制する
    • 主記憶の電力を抑制しながら大量データ処理
    • 蓄積型からストリーミング型のデータ処理に
本橋
  • flash hdd tape が連携
  • NBC テープアーカイブをHDD化した。トランプの若いころの映像を探すのに手間どった 。
  • メタデータ データの中身の情報のこと タグ付け 自動で
仁戸
  • ムーアの法則が終わって何がこまるのか?
  • クラウドに資本が集中する
  • データはまだサービスにくっついている
  • 個人にデータのものになるとよいのではないか。(おくすり手帳のような)
原田
  • 地理的な壁を越えたい。
  • 軽いストレージがほしい。床の耐荷重が問題になる。半分くらいしか積めない。
建部
  • まとめ
質問
  • Q: コンピューティングのためのストレージとストレージとしてのストレージ ポストムーアで分散になってストレージのブレークスルーはなに?
  • A:
    • 佐藤 スパコン屋はデータの使い方を考えてないのが問題 データの整理を自動化する 方向に。
    • 住元 ストリーミングで計算 蓄積しない方向へ
    • 本橋 GPUもストレージもひとつの箱で客に提供したい
    • 仁戸 ひとつの箱にはおさまらないのでネットワークの中にストレージがふくまれる 融合する
    • 原田 スパコンセンターはバッチスケジューラだけでいいのか? データの場所で処理 する方向に。

[2018-10-26 17:53]

懇親会は鳥元。

IMG_20181026_180251IMG_20181026_183327IMG_20181026_200219

そのあと曽田さん・白水さんとエクセルシーオルへ。

IMG_20181026_203020

いってきた: Gfarmシンポジウム2017

IMG_20171222_132058

司会 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]

休憩

IMG_20171222_160305

[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]

P1160501xIMG_20171222_174505

Gfarmシンポジウム 2016

image

昼に茗荷谷に着いたら、ちょうど小学校の下校時間なのか、制服を着たちびっこでにぎやかだった。

P1110954x

[2016-12-09 13:29]

開会 / ベストシステムズ 西克也

  • gfarmシンポジウムも4回目

[2016-12-09 13:30]

Gfarmファイルシステムの概要と最新機能 / 筑波大学 建部修P1110956x

  • 18000download越え 2007/4から
  • Gfarm 2.7.0(201612/8 release): 2.6.0からはデータ完全性に重点
  • 運用: JLDG(Japan Lattice Data Grid(物理系);8PB越え), HPCI共用ストレージ(22.5PB越え), NICTサイエンスクラウド, クオリティアActive!world
  • HPCI: 東拠点東大東工大=13.0PB 西拠点AICS=9.5PB
  • Garm 2.7.0
    • InfiniBand RDMA
      • IB Verbs APIをつかってRDMAがあたらしい。(IPoIBではない)
    • ディレクトリクォータのサポート
  • IB RDMA
    • よみこみはremote write, かきこみはremote read
    • CPUを介在しないのでオーバヘッドがすくないメッリト
    • 最近のIB Verbsではメモリを事前に確保しなくても動的にいけるようになっているが、今は事前登録している。
    • staticなclient bufferをpin-downするか、ユーザのbufferを動的にpin-downするか、どちらかか。
    • IB RDMAにしっぱいしたらIPにfallbackする。
    • サイズがちいさすぎるとRDMAのオーバヘッドがあるのでパラメータrdma_min_sizeがある。が、実際にはstaticなbufferをつかうので意味ない?
    • 性能比較: rdma-read = 1.8 * ipoib-read, rdma-write = 1.2 * ipoib くらい。
      • POSIX APIだとfuseのオーバヘッドがあるが1GB/sくらいは出る(rdma-read)。
  • ディレクトリクオータ機能
    • ユーザ/グループごとの制限ではなく、ディレクトリ下の制限。制限の設定はユーザの権限でできる。
    • 設定はディレクトリセット単位になる。(grdirquotaコマンドでディレクトリセットの作成)
    • ディレクトリセットは1つのパーティションになっているイメージなのでパーティション間をまたぐ制限はパーティションにならうかんじ
  • データ完全性
    • サイレントデータ障害を検知する
    • 破損ファイルをreadするとEIOしつつlost+foundに移動してレプリカから修復する。
    • 書き込み後ベリファイはデフォルト6時間後に行なわれる。
    • JLDGでの運用例: md5。5ファイルの書き込み後ベリファイ(6時間後)で検出、複製作成で1ファイルの損傷(書き込み後即時)で検出。IO errorはおきていない。
  • Pwrakeによる性能測定スクリプトの紹介...

[2016-12-09 14:02]

  • Q: RDMAはIPでもいける?
  • A: IBのネットワーク範囲内。IPがはさまると最初のチェックで弾いてIP通信になる。メタデータはIP。(ペイロードがおおきくないとうまみがない)

[2016-12-09 14:05]

[2016-12-09 14:07]

Gfarm Performance on Azure / HPCソリューションズ 河野証P1110957x

  • Microsoft Azure(アジュール)
    • windowsだけではなくlinuxの仮想マシンもつかえる
    • 仮想CPUは物理コアを占有する。ただしA0インスタンスをのぞく。
    • BLOB storageの冗長オプションもいろいろ: LRS, GRS, RA-GRS.
    • LRS: リージョン内レプリカに書き込み完了をまつ。
    • GRS: 外リージョンの書き込みは完了待たず(非同期)。
    • データディスク=BLOB, ストレージアカウント=set of データディスク, ストレージアカウントは実際の物理構成が透けて見えてるだけ、MAX20000IOPS、スループットは非公開。
  • Gfarm on Azureをつかうことで
    • オンプレとAzureで手元に頻繁にアクセスするデータをもってこれる
    • 容量の増減ができる
    • リージョン間レプリカで耐災害性
  • 性能テスト
    • サーバ1台: 11ディスクで700MB/sがピーク。そこまではリニアがが12ディスクから性能劣化で500MB/s。
    • サーバを増やしていくと5台くらいまではリニアに伸びて2700MB/s
    • サーバ500MB/s、ストレージ2500MB/sあたりが上限っぽい。
    • Azureの冗長オプションの違い(GrS,RAGRS,LRS))による性能差はない。
    • gfarmでリージョンをまたいでレプリカつくるとgfgrepが遅い。4倍くらいおそかった。

[2016-12-09 14:34]

  • Q: Azureでデータ完全性はチェックしてる?
  • A: silent data corruptionには対応しているとアナウンスされているが、具体的にはナゾ。
  • Q: ストレージでもネットワーク従量課金があるが、アカデミックな人たちには使いにくい(SINETと比べて高くてスパコンセンターの運用がなりたたなくなってしまう)。
  • A: Azureから出ていく方向(upload)は課金されるが、入ってくる方向(download)は無料。
  • X: クラウド内で処理を完結させる・クラウド内で可視化。(ユーザからはデータを見るのに時間がかかる)
  • X: 広域分散したときに各サイトで容量をあわせて増やしていかないと、データが偏ってしまう。拠点を増やすのも同じ問題がある。

[2016-12-09 14:44]

[2016-12-09 14:45]

Gfarmの高速化のための技術開発 / NICT 村田健史P1110958x

  • ひまわり8号リアルタイムWeb実績
    • 7号から8号でデータサイズが50倍になった。データが150TB/年で増える。ひまわりwebでさらに70TB増える。
    • ファイル数が2億/年。
    • 気象庁は自分でデータをためるのをあきらめて外部に利用させる代わりにデータを保存してもらうことに。
    • 8Kの10倍くらいの画像データとでかい。
    • 台風が来るとアクセスが増える。平時でも2千人くらいみてる(マニアと専門家)。日食のときにもアクセスが増えた(雨だったので)。沖縄からのアクセスがおおい(台風がおおいから)。平日は職場からスマホで、休日は自宅からPCで。
    • netCFD/HTTPでgfarmにもってくる。(Himawari Cloud)。
    • 研究者にはFTP,HTTPで配布。
    • ファイルの数が問題になっている。
    • 名古屋大学情報基盤センターの8Kディスプレイで静止画をOpenGLで連続レンダリングして疑似動画表示。ただデータをもってくるのに1分くらいかかる。
  • JHPCN2017: 京大・名大・九大・千葉大・愛媛大・NICT・筑波大
    • FWなしに通信できるのは限られる。
    • SINETが速くなってもFWやキャンパスネットワークがボトルネックになる。遅延・パケットロスも組織間でいろいろ。
    • クライアントサイドの並列化はメンドクサイのでさけたい。
  • HpFP(UDP独自)とxTCP(TCPの高速化;TCPインターセプター)
  • HpFP: 500ms loss数%なら10Gbpsはだせる(静止軌道の通信のめやす)
  • HbVRS: gfarmの上にHpFPを載せてファイル転送(gfpcopy相当)を高速化
    • UDT(UDPベースの通信;昔からあるやつ)と比較してみた: UDTはパケロスに弱い。
  • xTCPによるGfarm高速化実験
    • 遅延ロスなしならTCPの方がよい。あるならxTCPが圧倒的に速い。
    • 小さなファイルの転送は時間がかかる。もしかするとmetadata server--client間は素のTCPの方がよいのか?
    • 素のTCPはスループットがたちあがるのに5秒くらいかかる、HpFPでは3秒。
  • Amaterassプロジェクト
    • NPO太陽放射コンソーシアム
      • 1日あたり1000万ファイル・250GB

[2016-12-09 15:24]

  • Q: ディレクトリを分ければファイル数は増やせるが。
  • A: メモリを買う予算が。メタデータ圧縮がほしい。

[2016-12-09 15:26]

休憩

ドリンク購入。コーラがなかったので朝摘みオレンジ。

image

[2016-12-09 15:39]

Gfarmシステム運用におけるアウトソーシング活用の試み / 東京大学 中誠一郎P1110959x

  • アカデミック分野の運用現場
    • 現場に入って2年3ヶ月: いろいろ企業とは雰囲気がちがう。雇用形態の違いか?成果に対するインセンティブがない。
  • 保守管理業務の本質(ITIL)
    • 見える化(運用目標・運用成果・教務カタログ)・基盤(ドキュメント・スキル・ツール)・管理(情報管理・プロジェクト管理・予算管理 ・品質管理) 経営層との合意。CMSツールがつかえうる。
    • CMMで2,3あたりにとどまっている。
  • 最近の目だった障害: DNSダウン、ストレージ障害(IBのバッファサイズが不適切だった)、Gfarmレプリカ不正作成によるファイル消失、Gfarmメタデータサーバダウン(高負荷すぎてzabbixまで落ちてfailoverしなかった; zabbixがSPOFになってた)
  • アウトソーシング: 夜間(16:30-9:30)休日限定。作業内容は最低限の被害拡大防止のマニュアルベース。
    • 工数ベースではなく、遠隔運用監視サービスなどのメニューにもとづく契約。
  • 要員: 東大3名、委託先6名(ローテーションで15名)
  • 監視は時間帯を決めてログ取得するなど。
  • アウトソーシングすることで保守ノウハウの見える化をねらっている
    • 属人的な蓄積は組織としては無意味。
  • 障害時の対応: システムの更新を伴う作業はやらない、参照だけ。協議の結果、zabbixサーバの再起動はやってもらうことになった。
  • 外部pingによって障害切り分けに役立つはず(内部からのpingだとやりにくい)。
  • 見える化→改善サイクルの習慣化
  • Enterprise WiKi (CMS): atlassian Confluenceが人気→今回活用した。
  • 委託費用: 初期数百万、月額数十万(土日休日のみ)。
  • (管理画面デモ)
    • CMSベースの報告・マニュアル作成

[2016-12-09 16:24]

  • Q: メタデータサーバダウン
  • A: globusの設定の問題(globusをバージョンアップしたときに設定を追加しないといけなかった)
  • X: むしろ外部の人間がやったいいことの方があるのではないか? 間違いを発見しやすい。 セキュリティのチェックも外部の人をつかった方がよいのではないか?

[2016-12-09 16:28]

[2016-12-09 16:29]

次世代HPCI共用ストレージの設計とクラウド活用 / 理化学研究所 原田浩P1110960x

  • 10PB級のストレージを運用しながら短時間で機材更新した。
  • データ保護と安全性・サービスの継続性・メニューの多様化
    • データの破損があると再計算の必要→計算資源の提供(千万円単位の計算もあったり)
    • 年間350日以上のサービス提供: 測ってみたら初期の方が稼働率が高かった。電源二重化してたので電源断はなかったが漏電により全館ダウンがあったため定期的に検査することに。
  • 稼働率が数%しか違わなくても、1日8時間だとおもうとけっこうちがう。
  • 東大とAICSでデータに二重化してサービス継続性を上げるしかない。
    • MTBF: 400hour->2154hourに改善できそう (3ヶ月に1回メンテナンスするかんじ)
  • サービスレベル
    • 初期投資が巨額になる→需要拡大にこたえるのがむつかしい。
    • 容量が足りないので2015年度から完全二重化をやめてユーザにレプリカの設定をまかせるようにした。
    • 柔軟な機材設置→クラウドを活用するしかないか?
    • 負担の公平化: 大規模課題で資源を寡占されてしまう、非公開課題の扱い、長期保存データ(容量比40%超が1年以上の長期保存:atime調べ)
  • 2017年度
    • クラウド環境の調査・クラウドにGfarm環境構築・クラウドストレージとGfarm連携

[2016-12-09 17:00]

  • Q: クラウド活用はこれまでのテープアーカイブの代わり?
  • A: もうちょっと違う可能性もあるのではないか? 遠隔可視化とか。
  • Q: 遠隔可視化について:名古屋大小野先生によると:可視化の表示自体を遠隔で行う(クラウド側でOpenGL)のも良い解法。

[2016-12-09 17:03]

閉会

P1110962x

P1110963x

なにやら学生野球資格回復プロ研修会というのをやっていて報道関係者もきてた。

image

(懇親会には参加せず帰りました)

P1110964ximage

関係ないけど、駅前にTRC(図書流通センター)ってのができてた。ビルにパースがついてるように見えるのがおもしろかったので。

P1110953x

Gfarmシンポジウム2015

_1040022_1040024_1040025

朝に参加申し込みしようとしたらすでに締め切られていたので突撃。余裕もって出発したのに山手線が遅延して時間ぎりぎりに到着。会場はWiMAX圏外。お茶大もWiMAXつかえなかったし茗荷谷はWiMAXよわいな。

[2015-12-14 13:32]

特定非営利活動法人 つくばOSS技術支援センター / 筑波大学 建部修見_1040026

  • Gfarmをホームディレクトリにしてautomountする情報など提供

Gfarmファイルシステムの概要と最新機能 / 筑波大学 建部修見_1040027

  • JLDG(7PB,8拠点), HPCI共用ストレージ(22.5PB,3拠点): アーカイブ用途がメイン
  • 最新版: Gfarm2.6.7
    • ファイルシステムにノードグループ: 複製配置機能
      • グループにいくつ複製をつくるか指定できる。
      • 余剰複製の削除をするようになった。(ノードが止まった→ノードを追加→ノードが復帰→余計なノード削除)
    • クライアント透明なフェイルオーバ: クライアントにエラーを返さずに処理続行
      • 自動でサーバ切り替え。
      • ファイル書き込み中でもフェイルオーバも可。
      • closeのタイミングで競合状態があって、期待しないほうがlost+foundに入ってしまう可能性がある。
      • 運用中のソフトウェアアップデートもできる。(先日JLDGでライブ更新をした。問題なし。)
    • end-to-endのデータ完全性
      • こわれていたらread→EIOでlost+foundに移動→正しいデータをもってきて自動修復
      • write→ちょっとまつ→verify
      • クライアントでもチェックすることでネットワークエラーも検出できる
    • gfpcopyの高速化
      • BULKWRITE/BULKREAD: FTPのようなアプリ向けのAPIを新設。
    • 運用監視
      • Zabbixプラグイン→slaveフェイルオーバすることも
      • Gangliaプラグイン
    • automount
      • gfarm-sambaプラグイン (gfarm2fsなしにアクセスできる)
    • CentOS 7対応
    • Linuxカーネルモジュール
  • 分散並列処理
    • ワークフロー: データインテンシブ・サイエンスアプリでよくつわれる。
      • ファイルとプロセスに依存関係がある。
      • Rakefileをつかって依存関係を記述できる。
      • Rakefileなら14行のところDAXだと41行にもなる。
      • pwrakeで並列実行。データの移動が少なくなるように、ディスクキャッシュを効かせるようにスケジューリングする。(多制約グラフ分割問題)
      • LIFO+HRF
    • Pwrake 2.0.0リリース
    • gfarm Hadoopプラグイン: gfarm://で
      • HDFSとの比較: レプリカ増やしても性能劣化が少ない。
  • close-to-open一貫性
    • writeがcloseしたときにreadレプリカを更新する。

_1040028

[2015-12-14 14:18]

  • Q: pwrakeでのLIFOってなに?
  • A: 最近実行されたタスクの依存関係で次のタスクを優先的に実行する感じ。
  • Q: 大きいファイルから処理するオプションがあったらい便利かも。(ファイルのサイズで計算量がわかるケースで依存関係がない場合)
  • A: 次期リリースで

[2015-12-14 14:21]

[2015-12-14 14:23]

HPCI共用ストレージにおけるデータ一貫性管理 / 理化学研究所 原田浩_1040029

  • 2015年3月末にユーザからデータ障害の報告
  • 5月に障害規模が特定
  • 2週間かけてチェックサム照合 (ディスク15PBの全チェック、ファイル容量としては8PBくらい)
  • 5課題5ユーザ922ファイルを消失していた。
  • 152392ファイルに破損あり。オリジナルからの復元可能。
  • 2014/8/20〜10/29のあいだに障害がおきていた。7ヶ月後に発覚。
  • 京740万ノード時間が再計算に必要になった。小規模なスパコンセンターの1年分の資源量に相当。
    • 年度を跨ぐと計算時間を与えたくても課題がおわってしまっていたり。
    • 論文のデータが失なわれてしまったらエビデンスがなくなってしまう。
  • ストレージコントローラだけでエラーログがでていると管理者が把握しにくい。
  • 運用上、ユーザのデータを読むのはむつかしい。
  • 対策: ユーザが一定期間オリジナルを保存する。
  • データ破損とデータ消失
    • 破損: どこかに正しいデータがのこっている
    • 消失: すべてデータが壊れている
  • 消失ファイルリストは1日2回管理者に通知(UIDとinum)。消失ファイルはメタデータから消して、新たな消失ファイルの見落としをなくすように。
  • gfspooldigestで毎日チェックした破損検出するようにした。
  • 原因はIBのsrpdの二重起動だった。

[2015-12-14 14:54]

  • Q: gfarmの問題ではなくHW障なのでネガティブキャンペーンにつかわれないようにしないと
  • Q: 書き込み後にエラーを検出できいなのでは?
  • A: 1日後など定期チェックで検出できる。

[2015-12-14 15:00]

[2015-12-14 15:01]

HPCI共用ストレージにおけるITIL視点でのGfarm運用分析 / 東京大学 中誠一郎_1040030

  • 8月からITIL(information technology infrastructure library)実施
  • 問題: 破損から検出まで時間がかかった・破損検知の監視運用が弱い・真の原因が判明せず
  • 各拠点のSIベンダーはばらばら(H/F/N)。ここまでマルチベンダーの例はあまりない。
  • 成熟度レベル(CMMI)
  • レベル2+αを参集レベルとしてガイドラインを策定
    • 構成ガイドラインと運用ガイドラインと
  • 参入レベル:メタデータサーバはなし、ストレージサーバのみ供出
  • ITIL: 運用の手本として民間では活用されている
    • サービスサポート: 日々の運用 (サービスデスク・インシデント管理・問題管理・変更管理・リリース管理・構成管理)
    • サービスデリバリー: 中長期 (維持管理)
  • gfmdフェイルオーバの運用ガイドラインも策定したい。
  • 運用4P(processプロセス,people要員,productsツール活用,patners外部組織連携)
    • それぞれについて成熟度レベルを目安を定義

_1040031_1040032

[2015-12-14 15:38]

休憩

_1040034_1040036

[2015-12-14 16:01]

Gfarm/Pwrakeを拡張した様々な科学研究アプリケーションとそれを支える高速データ通信プロトコルの開発 / 情報通信研究機構 村田健史_1040038

  • NICTサイエンスクラウド
    • 3PB どちらかというと小規模
    • アーカイブというよりは計算用途
    • 予算がつかなくてサーバがどんどん死んでいくけどシステムの可用性は保たれている。
  • 可視化: データが増えてもそれを表示するディスプレイが小さいままなのが問題。
    • これまではオンデマンドで可視化。でもレスポンスタイムが悪化するばかり。
    • 事前に想定される画像を作っておく。意外とバリエーションはない。
      • 大量の画像をつくるのにgfarm/pwrakeが役にたつ。
      • ひまわり8号: 遅延10分で新しい画像をどんどん作っている。時間軸があるのでgoogle mapよりもデータ量が多い。
      • 読売新聞の明治6年移行のカテゴリ毎の記事の出現率のグラフ。これも画像を大量生成しておく。
    • アプリの種類: リアルタイムかオンデマンドか
  • 高速化
    • HbVRS: high-andwidth virtual remote storage
    • UDTプロトコル
    • 日米間で7.2Gbps
    • HpFPプロトコル: http://hpfp.nict.go.jp
      • TCP比: 遅延やロスが大きくてもスピードがでる。(RTT500ms,loss1%でも)
      • ライバルは ASPERA/Fasp
    • でも1ファイル1GBもいかない。小さいファイル10MBとかが多い。HpFPでは性能がでる。
  • Gfarmはデカい話をしすぎているのではないか?コンパクトな話もすべき。

_1040039_1040040

[2015-12-14 16:37]

  • Q: なぜTCPより速い?
  • A: ウィンドウサイズの上限がない。
  • Q: APIは?
  • A: アプリレベル。
  • Q: TCPとの公平性は?
  • A: 実装してない。月とか南極で使う話が進んでいるので後回しになっている。狭帯域ではTCP friendlyで、広帯域で帯域つかうようにするか。難しいのでソフトのバージョン分けしちゃうかも

[2015-12-14 16:41]

[2015-12-14 16:42]

(株)クオリティアにおけるGfarm活用事例 / クオリティア 駒木義孝_1040041

  • メールホスティングサービス(SaaS)におけるストレージ
  • active! mail (パッケージソフト)
  • Active! World: 独自ドメイン・メールホスティングサービス
  • メールホスティングではIOPSを稼がないといけない。たいていのストレージベンダーがにげだすレベル。
  • dovecot

_1040042_1040043

[2015-12-14 16:56]

「Active! World」におけるGfarm / クオリティア 根本昌孝_1040044

  • メリット: メールのデータでも性能がでる
  • デメリット: gfarmメタサーバに高スペックが要求される
  • dovecotはgfarm APIをたたくように改造。3台に書き込み(レプリケーションつかわず3回書き込み)。書けなかったらトランザクションエラー。
  • dovecotでactive→standbyにindex/cache転送している。
  • メタサーバのdiskにはfusio-io iodrive duo 640GB
  • ネットワークトラフィックで100Mbpsでてる。メールでこれはけっこうな量。
  • ファイルサイズ: 30KB 4億ファイル数

_1040045_1040046_1040047_1040048_1040049_1040050

[2015-12-14 17:07]

  • Q: なぜgfarm?
  • A: 当時は分散ファイルシステムがなかった。
  • Q: 次もgfarmをつかうか?
  • A: 価格と実績とIOに強いという点で最終選考にのこっている。
  • Q: 性能は?
  • A: 秒間60セッションをさばけるのが目安。(月曜朝)
  • postfix→dovecotはLMTPで。

[2015-12-14 17:12]

_1040051

懇親会

_1040052_1040053

海鮮居酒屋 はなの舞 茗荷谷駅前店。ビールたくさん飲んだ気がする。締めがえびせんというのはちょっと納得いかない。

_1040063_1040066

池袋でふらふら写真撮ってから帰宅。

Gfarmシンポジウム2014

_1250615x_1250617_1250618_1250619_1250620_1250621

一日中、冷たい小雨が降っていた。風も強めで体が冷える。

[2014-12-16 13:31]

理事長挨拶 / 建部修見 _1250622

  • サポートのためNPO昨年設立
  • gfarmファイルシステム
  • gfarm2fs
  • sambaプラグイン
  • zabbixプラグイン
  • Pwrake(プレイク) 大規模向け
  • gfarmをホームディレクトリとしてautomountする情報などを掲載

[2014-12-16 13:35]

Gfarm2.6の新機能 / 筑波大学 建部修見 _1250624

  • リリースする予定
  • 今朝sourceforge.netのCVSサーバにトラブルがありreadonlyになっててリリースできてない。。。
  • 2000年から研究開発している。14年。
  • 広域ネットワークで遅延があっても性能が落ちないように工夫。
  • 単一障害点がない。(自動ファイル複製、ホットスタンバイMDS)
  • ダウンロード数: 15175
  • これまで複製の数の指定はできたが、場所も指定できるようになった。
  • クライアント透明なフェイルオーバ:アクセスしている最中でもアプリにエラーを返さないようになった。(もっとも工数がかかってる! 異常系3年以上テストした! 自信あるよ!)
  • end-to-endのデータ完全性 (確実に書けて、確実に読める、データ化けがない、下のファイルシステムでデータ化けがあっても)
  • gfs_pio_sendfile: read/writeじゃなくてsendfile系apiでgfpcopy(並列コピー)が高速化。
  • CentOS7対応:起動ファイルがsystemdになったり。
  • Linuxカーネルモジュールがつかえるようになった(CentOS6.4で動作確認)
  • ファイルシステムノードグループによる複製配置指定機能
    • ノードグループの指定: gfnodegroup -s hostname groupname
    • 複数属性の指定: gfncopy -S GroupA:2,GroupB:1 directory グループごとの複製数を指定
    • 従来: gfncopy -s NUM directory 複製属性の方が優先、Σ複製属性<複製数なら、残りはてきとうに配置
  • フェイルオーバ
    • すべてのAPIが再接続して処理継続。クライアントにはエラーをかえさない。
    • フェイルオーバと書き込みが競合した場合(書いたのに消えるケース)は、lost+found に移動。
      • proc Aがファイル更新中(複製あり)にgfmdフェイルオーバ発生
      • proc Bが同一ファイルを更新(フェイルオーバ中のためproc Aが更新していることに気づかない)してcloseした。
  • end-to-end完全性
    • gfsdでチェックサム(md5)を計算してた。(gfarm 2.5.8.5以降) 逐次読み書きのみ。
    • ファイル複製のときにチェックサム計算ようにした。
    • クライアントライブラリでもチェックサム計算して、ネッーワークエラーもチェック。
    • sha256もサポート
    • チェックサム計算は連続アクセスか複製時。はじめて計算したときにMDSに登録。
  • gfpcopy高速化
    • BULKWRITE/BULKREADプロトコル新設。ftpのように連続転送。RTTが大きくても性能がでるように。
    • Q: 京大fwは遅いはずだが?
    • A: 実測値なので出ているはず。
  • 2.6は去年だす予定だったものをend-to-endを入れて遅れた。
  • 2.5.8系はバグフィックス中心にサポート

[2014-12-16 14:03]

  • Q: チェックサムによる性能低下は?
  • A: 測ってないけど、ユーザから文句はでてない、数%も遅くなってないはず。

[2014-12-16 14:05]

WebGfarm: 分散ファイルシステムGfarmのHTTPインターフェース / 筑波大学 鷹津冬将 _1250627

  • 建部さんのところで研究
  • gfarmのインターフェース
    • libgfarm (低レベル)
    • gfarm2fs (FUSEベース)
    • mpiio_gfarm (MPI I/O)
    • gfarm_hadoop (ふつうはHDFSをつかうけど)
    • gfarm_samba
    • NEW: WebGfarm (REST API)
  • Apache HTTP serverモジュールとして実装
    • Apacheのシェアは37.05%。
    • mod_webgfarm: Cで700行ほど。
    • Rangeヘッダの処理がめんどくさい。
    • RESTゲートウェイとして動作。
  • https://github.com/fuyumacha/mod_webgarm
  • つかいかた
    • httpd.confに書くだけ。
      • WebGfarm on ← 有効
      • WebGfarmBase /v1/ ←URLのパスを指定 mod_rewriteのrewritebaseとおなじかんじ
  • GET → read, readdir
    • メタデータはヘッダにはいってくる。
  • PUT(idempotent) → create,mkdir,write(truncateしてからwrite)
  • POST(追記) → write
  • DELETE → unlink,rmdir
  • ステータス
    • 200 OK, 201 Created: 成功
    • 404 NotFound: ENOENT
    • 403 Forbidden: EPERM
    • 307 TEMPORARY_REDIRECT: 複数ノードのとき
    • 500 Internal Server Error: 実装できてないものとか
  • apacheとgfsdが異なるノードの場合は性能劣化→HTTPリダイレクトさせることで誘導。(ファイルサイズが小さいと無駄が大きいので注意)
    • WebGfarmRedirectSSL on
    • WebGfarmReadRedirect on
    • ...

[2014-12-16 14:34]

  • Q: httpユーザとgfarmユーザのマッピングは?
  • A: 認証でやろうとおもったが、現在はApache専用ユーザを用意してアクセスする。

[2014-12-16 14:35]

ZabbixによるGfarm障害監視 / SRA 笠原基之 _1250628

  • 止まらなくても高負荷で使いものにならなくなることともある。
  • zabbix
    • 監視対象はUNIX
    • デザインを意識したUI、多国語対応している。gfarm-zabbixは英語のみorz
  • テンプレート: 監視項目のセット (linux OS用のテンプレートとか)
  • ホスト: zabbixはホスト単位でしか監視できない。ホスト上でzabbixエージェントを動かす。
  • gfmdフェイルオーバ対応で、障害検出して自動フェイルオーバできる。
  • CentOS6対応。7は近日対応。
  • Gfarm: クライアントにパッチあててるので特定のバージョンじゃないと動かない。
  • Zabbix: 1.8と2.2 LTS。
  • テンプレート
    • gfsdが動いているか
    • 認証がとおるか
    • syslogになにか出てないか
    • スプールの空き
  • gfarm代表クライアント
    • このクライアントをとおしてGfarmの全ノードの監視をおこなう。zabbixの監視アプローチとはちょっとちがう。
  • gfarm一般クライアント
    • 認証がとおるかどうかチェック
  • gfarm-zabbix 1.x
    • 2012年4月に1.0をリリース
    • gfsdが20台以上の環境に投入された → アラート多発・master gfmdに負荷
    • master gfmdに障害があるとアラートメールの洪水になって問題が把握できなくなる。
    • 多数のエージェントがgfarmに問い合わせするのでgfmdの負荷上昇
  • gfarm-zabix 2.0
    • 2014年10月リリース
    • 代表クライアントをもうけることでgfrmdの負荷軽減
    • gfmd 4台、gfsd 28台の環境で運用中。スプール 5PB。ユーザ数100。

[2014-12-16 15:10]

  • Q: 代表クライアントの障害時は?
  • A: フェイルオーバはないが、zabbixサーバ上に置いておけばよい。

[2014-12-16 15:11]

休憩

自販機でココア購入100円。廊下は寒いのですぐに部屋に戻る。

_1250639

[2014-12-16 15:34]

HPCI共用ストレージの歩み / 理研 原田浩_1250641

  • http://www.mext.go.jp/a_menu/kaihatu/jouhou/hpci/1307375.htm
  • 各大学でアカウントをとって利用していたのを、HPCI事務局で一括管理。シングルサインオン。
  • レプリカ数2で運用。1PBくれといったユーザは2PBの割り当てになる。
  • 2年運用して1度データ消失があった。
  • ストレージ容量は21.5PB。
  • 利用は活発。そろそろ枯渇しそう。資源割り当ての見直しを実施。
  • 2011/5に東大に納入。Lustre/IBで納入されたのを2012/4にGfarmに改修。
  • テープストレージも入れている。
  • 2012/5にHPCI共用ストレージのリハーサル。HPCI構成機関からのgfarmマウント。
  • IPoverIBで外に見えてる。
  • 最初はあまり利用されなかった(1PB)が、初年度後半では研究成果を残す目的で利用されるようになった。
  • 京コンピュータからは直接書けない。ログインノードからのみ読み書き。IPリーチャブルじゃないとだめなので。
  • 2.7PBくらいつかってる課題が3課題もあって60%くらい占めてる。
  • HPCIのヘルプデスクがある。そこでトラブルは一元管理。
  • FUSEマウントを推奨。予想以上に使ってくれている。GSI認証にたどりつくところの敷居が高いようだ。
    • マニュアルにはgfコマンドも書いてある。
    • マウントすることが難しいのではないか? マウントポイントに(マウントする前に)ファイルを書いてしまって(マウントが)EBUSYなってしまうとかあった。京のように複数ログインノードがあると、毎回マウント・アンマウントしなくてはいけなかった。(今はautomounterがあるけど)
    • 複数ノード使わないユーザはsshをつかってしまう。GSI認証の普及が課題。
  • 2013/11ごろから2014/1にかけて4ユーザ135ユーザでデータ消失。レプリカをつくるまえにデータが消えた。
  • xfsをふくむパッチをあてまくって今は安定。
  • SATAの信頼性はおもったよりも高い。4800台のうち故障は月1桁台。
  • サーバの一斉起動でUPSの容量越えたり障害はヒューマンエラーが多い。ハードやソフトは少ない。
  • mdsは冗長化しているがファイルデータはランダム配置なので片側運転ができない状況。
  • 国プロでオープンソースはどうなの?
    • うまくいっている。
    • ベンダー単独ではむつかしいシステム規模。
  • HCPI共用ストレージはHPC向けとしては世界最大級(参加組織・容量・実績)。

[2014-12-16 16:27]

  • Q: xfsの問題でgfarmデータ消失なら、もっとxfsの事故を調査しては?
  • A: 事故のあと、毎週データ整合性のレポートを取るようにしている。

[2014-12-16 16:30]

NICTサイエンスクラウドでのGfarm利活用及び開発事例紹介 / NICT 村田健史 _1250651

  • JGN
  • データ消失を経験してからは、ユーザはフロントエンドのNASをさわる。バックエンドにGfarm。スパコンからは直接Gfarm。
  • 観測系がファイル数が多い、シミュレーション系がファイルサイズが大きい。
  • サーバは随時追加している(google方式)。
  • (水増しできる)ユーザ数で比較するのではなく(ごまかせない)論文数で利用規模を比較しよう。
  • ファイルの操作履歴とっている(トレーサビリティ)。
  • タイムスタンプサーバをつかって、インテグリティチェックを実装中。コピーが改竄されているかどうかチェックできる。インターネットからの問い合わせも可能。
  • ひまわり8号のデータをサイエンスクラウドで受けることになっている。
  • 3次元レーダの可視化はMPIだと遊びができちゃうのでpwrakeをつかって計算をつめこむ方が効率がよい。
  • HPCスパコン的 ⇔ Many-Task-Computing (MTC)クラウド的
  • 4K 900fps:FT-ONE 自動車の衝突解析など 2TBでも10秒しか記録できない。90Gbps。
    • 10Gbpsを5本たばねて50Gbpsくらいは出るようになった。
    • カメラからのRAWデータを保存しながら計算できるメリット
  • GPFS/Lustreのシステムが圧倒的におおい。

[2014-12-16 17:07]

_1250652x

総括 / ベストシステムズ 西克也 _1250662

  • ベンチャーでお金をほしかったら国からもらう→しかしまきとられてしまう問題。大企業はうまいことやるけど。
  • そのなかでGfarmは奇跡的に生きのこった。
  • NICTのGfarmはちょこちょこ増築していった。データ消失のときにはネガティブキャンペーンがひどかった。大きなお金はつかわないようにしている。
  • オープンハウスのときにはタイムスタンプとトレーサビリティが人気だった。
  • REST API: HEADでメタデータをとれる。今後S3互換のものもつくっていきたい。

[2014-12-16 17:24]

懇親会

  • くいもの屋 わん 九州自慢 茗荷谷店 にて 18:00〜20:00

_1250663x

二次会

  • 白木屋 茗荷谷駅前店 20:00〜22:00

image_1250666

記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2018-11-15
    • 今日の練習 2018-11-15
    • 今日の練習 2018-11-13
    • 今日の練習 2018-11-11
    • 今日の練習 2018-11-11
    • 今日の練習 2018-11-10
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ