sw

tmux: 画面分割

~/.tmux.confに

bind-key        /       split-window -hv
bind-key        |       split-window -h
bind-key        -       split-window -v
bind-key        _       split-window -vf

って書いておくと、縦分割横分割で、縦ってどっちだっけ?って悩む必要がなくなってよい。

tmux-logo-small

tmux: ドラッグ&ドロップでペイン入れ替え

~/.tmux.confに

bind-key -T root DoubleClick3Pane select-pane -m
bind-key -T root MouseDragEnd3Pane swap-pane -t= \; select-pane -M

というのを追加しておくと、右ボタンをダブルクリックしてドラッグするとペインの入れ替えができて便利。

tmux-logo-small

PCクラスタコンソーシアム(PCCC) 実用アプリケーション・シンポジウム2018

IMG_20180918_142901

IMG_20180918_124651

[2018-09-18 13:00]

挨拶
片桐孝洋 (名古屋大学)

  • 会場100名 参加登録100+名
  • 実用アプリケーション部会
  • 姫野さん立ち上げ アプリケーション高速化
  • 数値シミュレーション技術普及活動も
  • クラウドの提供
  • フリーソフトの普及 PCクラスタ スパコン クラウド をシームレスに
  • クラウドの提供 Azure 5件/年くらいで支援
  • 部会に登録すると連絡会に参加できる
  • 機械学習 GPU 1ノードあたりの資源量が大きくなってくる
  • そういうスケジューラは製品がほとんどない 各センターでこまっているんではないか

[2018-09-18 13:09]

HPC・AI/ビッグデータ処理の真の融合に求められるジョブスケジューリング・システ ムソフトウェア〜 産総研 ABCI・AAICの事例と将来課題
佐藤仁(産業技術総合研究所人工知能センター)

  • 8月にABCI AIのためのHPCシステム
  • AAIC aist AI cloud
  • アルゴリズム x ビッグエータ x 計算基盤 の一体的な進展が不可欠
  • NEDO NAIROBI(H28.6) -> AAIC(H29.6) -> ABCI(H30.8)
  • ABCI 簡素な建屋に 簡素な床で耐荷重をかせいで やぐらをくむ
  • 2.3MW 70kW/rack (ふつうのだと10〜30kw/rack)
  • 部屋はあつい
  • xeon 2socket NUMA IBも2枚 IOバランスを重視して
  • 34node/rack
  • ラック間は1/3 oversubscription BW
  • 大規模な分散機械学習だと精度が上がらないので、ネットワークの性能はコストを考えて落してある
  • local storeage: BeeOnd 複数ノードのSSDを1つのストレージとしてみえるようにして ある
  • Univa Grid Engine (UGE)
  • AAICでは95%が1GPUジョブ
  • コンテナ lang2rogram ACL2017 のDockerfileがそのままうごくか?
  • UGEがnativeにdockerをサポートしているのでそれをつかうか Singularityをつかう
  • ソフトウェアのデプロイがむつかしい
  • モジュールファイル(Modulefiles)を新規開発
  • サービス: Spot(バッチ;qsub)、On Demand(インタラクティブ;qrsh)、Reserved(期日指定,長期向け)
  • 資源タイプ: F,G.large,G.small,C.large,C.small
  • マルチノードジョブ、シングルノードジョブ・インタラクティブジョブ
  • 計算ノードのネットワークトポロジを考慮
  • 任意の時間を指定できるとスケジューリングがくるしくなってしまったので、時間粒度をあらくして、開始終了時間をそろえた
  • 公平性 UGEのfair shareではなくFIFO+Priority+バックフィル
  • ABCIはTSUBAMEとくらべてAI向けでネットワーク弱め
  • AI,BIO系はメイクスパン長め

[2018-09-18 13:40]

  • Q: 利用率は?
  • A: AAICはけっこう待たされる2node jobでも数日待たされる。ABCIはユーザ教育が足りてなくて(言うと暗殺されるレベル)。

[2018-09-18 13:42]

[2018-09-18 13:42]

九州大学スーパーコンピュータシステム ITOにおけるジョブスケジューリングの課題
南里豪志(九州大学情報基盤研究開発センター)

  • 資料
  • スパコンシステム ITO
  • 今年1月に稼動
  • フロントエンドを用意したのでバッチに専念できるように
  • フロントエンド: 対話型、webよやく
  • サブシステム: バッチ (ネットワークはフラットなので考慮しなくてよい)
  • 予算のでどころでグループをつくって運用
  • スケジューラ: 富士通 Technical Computing Suite
  • 月額定額制を採用 (従量制ではない)
  • 利用負担金定額制の利点・欠点
  • 利点 利用グループの予算計画が用意
  • 欠点 つかったもの勝ち (従量制の場合よりも公平性が重要になってくる)
  • フェアシェアによる優先度管理 つかったらそのぶん優先度がおちるが 月初にリセット
  • ノード固定タイプでジョブ実行待ち時間をなくすこともできる 1時間以内にジョブが流れることを保証 ただし8倍の値段 利用申請は前年度末に締め切って調整している
  • 占有タイプだとノード稼働率が落ちてしまうのでノード固定タイプにして1時間以内に 共有タイプのジョブキューを用意している
  • バックフィルスケジューリング: 他のジョブを遅らせない範囲でジョブの追い越しを認める
  • 利用者から苦情 ジョブの開始予想時刻が優先度の高いジョブにわりこまれて遅れる
  • 対策 開始12時間をきったらフェアシェアによる割り込みをしないようにする → 苦情 はなくなった(あきらめ?)
  • 苦情: 大規模ジョブがなかなか流れない
  • 対策検討中: 優先度低い小規模ジョブは12時間以内になっても後回しにできるように

[2018-09-18 14:08]

  • Q: バックフィルで苦情はきてないか?
  • A: フェアシェアとバックフィルをくみあわせると公平性がわるくなる。フェアシェア やめちゃう?
  • Q: 定額制の割合は?
  • A: ノード固定は800/2000。のこりでフェアシェアをやっている。
  • 西: ユーザにジョブの価値を決めさせて課金を変える。TSUBAMEでは2倍4倍しか用意し なかったので4倍に張り付いてしまった。青天井にすべきだった。
  • Q: シングルコアのジョブばかりになってしまわないか?
  • A: メモリ量も減るので、ユーザは必要なメモリ量からコア数を選んでいる。シングル ノードの方が通信しなくてよいぶん全体のスループットが上がるし。

[2018-09-18 14:16]

休憩

[2018-09-18 14:29]

Univa Grid Engine:マシンラーニング時代のジョブスケジューラの重要性について
ワイス・ハワード(パシフィックテック マネージングダイレクター)

  • 大学を卒業してすぐ日本に
  • gridware -> sun -> oracle -> univa
  • UGE8.5.0 GE 6.2(最後のオープンソース)にくらべてジョブのスループットが高い (倍 くらい?)
  • 1ノードあたりの資源量が増えてきている
  • TSUBAME3用の特別バージョンをUNIVAでつくった。ノード内トポロジ(numa,omnipath,gpu)を考慮する
  • docker対応 coreバインディング gpuわりつけ
  • singularityはdockerよりもHPC向け
  • BeeOND 複数のNVMeを1つのnamespeceとしてあつかえる。
  • BeeGFS

[2018-09-18 14:52]

[2018-09-18 14:53]

ハイブリッドクラウド環境を実現するPBS Works
久保 博次(アルテアエンジニア リング株式会社 ビジネス開発本部 Enterprise Computing事業部 Technical Manager)

  • 資料
  • まだ入社したとこ試用期間中なんだけど
  • それまではHPCのハードウェアベンダーにいた
  • PBS works suite = PBS access + PBS professional + PBS control
  • psb professional
    • docker root問題を緩和
    • multisched パーティションごとにポリシー設定
    • cgroups gpuはcuda7から
  • pbs access
    • gui
  • pbs control
    • workload simulator 履歴データから拡充を最適化
  • アプライアンス vs バースティング
  • PBScloud.io: PSBworksとクラウドをつなぐもの
  • デモ

[2018-09-18 15:11]

[2018-09-18 15:12]

FUJITSU Software Technical Computing Suiteのご紹介
三鴨利彰 (富士通株式会社 次世代テクニカルコンピューティング開発本部 ソフトウェア開発統括部)

  • 資料
  • TCS Technical Computing Suite
  • TCS = 運用(ジョブスケジューラを含む) + ファイスシステム(FEFS) + プログラミング環境(MPIとか)
  • 京のときに8万ノードをあつかえるスケジューラがなく開発がはじまった
  • 京はノード数では世界第2位の規模。
  • ジョブ選択ポリシーと資源選択ポリシー
  • 緊急ジョブを流す(デバッグ時とか) プロセスをスワップアウトさせる?
  • 論理スワップを利用することでデバッグジョブをはしらせる
  • JSCAPS job scheduling aware power save
  • スケジューリング情報から計算ノードの電源停止 (これまでは過去のデータをベースに電源管理するものはあった)
  • dockerイメージを管理者が用意して利用者は指定するだけで実行できる。
  • 利用者が自分のイメージを指定してリポジトリからとってくることもできる。

[2018-09-18 15:30]

  • Q: API
  • A: ジョブの状態遷移のときにフックをいれられる(課金で利用)。ジョブの中からイベ ントをつくることもできる。

[2018-09-18 15:32]

[2018-09-18 15:33]

NEC Network Queuing System V (NQSV)のご紹介
鷲尾 拓也(日本電気株式会社 AIプラットフォーム事業部)

  • 資料
  • NQSV NEC Network Queuing System V(ブイ)
  • ベクトル機SX用
  • NQSIIの後継
  • Vはベクトルだけどベクトルだけではない
  • SX-Aurora TSUBASAに向けて開発
  • 最大稼動ノード数・最小稼動ノード数を設定できる。
  • 実行: mpirun -ve 4-5 -np 2 ve.out
  • PCIeのスイッチをまたがないようにVEを選択
  • ワークフロー実行 エスカレーションもする
  • openstackやdockerの環境で実行可能
  • dockerはテンプレートを指定して実行

[2018-09-18 15:53]

  • Q: linuxならNEC以外でもうごくか?
  • A: yes

[2018-09-18 15:53]

[2018-09-18 15:54]

IBM Spectrum LSF ~分散コンピューティング環境における厳しい要求に対応するワ ークロード・マネージャー~
大澤暁(日本アイ・ビー・エム株式会社IBMシステムズ ・ハードウェア事業本部SDIテクニカル・セールス)

  • 資料
  • LSF
  • Spectrum Computing = high performance computing + cognitive and deep learning + high performance analysis
  • クラスター仮想化ソフト
  • cloud bursting: ポリシーにもとづきクラウドにジョブを転送。resource connectorで自動的にprovisioning。データのコピーはstatingで。IBM Asperaによる高速転送。GPFS もつかえる。
  • LSF&Kubernetes
  • モバイル端末からジョブの管理ができる
  • http://www.theedison.com/pdf/2014_IBM_Platform_LSF_WP.pdf
  • SGE/Torque/SlarmとくらべてLSFはやはい
  • LSFシミューレータが公開されている

[2018-09-18 16:15]

  • Q: シミュレータのデータは?
  • A: LSF以外の場合は自前で変換する必要あり。

[2018-09-18 16:16]

休憩

[2018-09-18 16:29]

パネルディスカッション

  • モデレータ 片桐
    • スケジューリングの公平性 AIが必要?
    • 電力
    • ユーザ教育
    • 分散
    • ヘテロ

[2018-09-18 16:34]

  • 佐藤
    • 共有計算環境でデータを秘匿するか 計算も秘匿?
    • セキュリティ監査もうける?
    • プライベートデータのあつかい
    • 暗号化ストレージもクライアントサイド・サーバサイドがある
    • 計算ノードだけでなくストレージのスケジューリングもやりたい
    • 資源ブローカー+スケジューリング+セキュリティ

[2018-09-18 16:40]

  • 南里
    • 省電力、パブリッククラウド、コンテナ
    • 稼働率・公平性・利便性を維持しつつ
    • ピーク電力をおさえる(契約) 電力量(料金)

[2018-09-18 16:45]

  • ハワード
    • 様々なハードウェアに対応しないといけない
    • docker imageも考慮したノード選択とか
    • ノード内ファイルシステムの連携(揮発ではなく)
    • 安定性(セキュリティとか人命がかかわるとか)

[2018-09-18 16:50]

  • 久保
    • 客:運用の希望はあるが手間はかけたくない → AIで管理者にアドバイス

[2018-09-18 16:55]

  • 三鴨
    • A64FXでは周波数以外に演算パイプライン・メモリバンド幅も操作可能
    • AIをつかうとき、何を最適化するのか? 稼働率?満足度?研究成果? システム価値とは?

[2018-09-18 17:00]

  • 鷲尾
    • どんなジョブでも自由に一時停止、実行場所の変更、再開を可能に
    • 現状緊急ジョブ(防災、おかねもち)があるのできれいにつめてもくずれてしまう。
    • チェックポイントだとユーザの手間がかかる。システムレベルでケアしたい。
    • チェックポイントファイルが巨大 それのスケジューリング

[2018-09-18 17:04]

  • 大澤
    • いろんなワークロード
    • いろんなハードウェア

[2018-09-18 17:08]

  • 秘匿データ秘匿計算
    • 病院関係
    • どうなったらいいか、聞き取り調査してもはっきりしない
    • アカウンティングはsshだけではなくポリシーベースでできるといいなぁ
    • ストレージ・ネットワークの課題の方が大きい。そのあとスケジューラかなぁ。
    • おおきなストレージにデータを置くのを嫌う客は多い。BeeONDでローカルなNVMeに置 くなら許されるかも。
    • フロントエンドにストレージをつないでバッチノードからマウントしてつかった経験 はある

[2018-09-18 17:20]

  • 東大 伊藤
    • データサイエンスの同期計算しないもの(通信しないもの)と、MPIのものをおなじバッチスケジューラにつっこむのは、充填効率がおちるか、スケジューリングが複雑になってしまう。
    • スケジューラをジョブノードでうごかしてそのなかで細粒度のスケジューリングする のはどうか
    • ジョブの投入数を抑える設定をしている。小さいジョブをたくさんなげてまる。ユー ザ教育: シェルスクリプトでbgつかう、MPIで個別プログラムを実行、gnu parallels
    • MPIでノード占有してバルクジョブを実行するものを提供したことがある。
    • システムをわけてしまう。
    • メタスケジューラ

[2018-09-18 17:34]

終了

[2018-09-18 17:35]

void (*(*f[])())()の解読のしかた

C言語の演算子の優先順位はけっこう複雑な方だとおもう。

宣言の読み方が難しいのは宣言に出てくる演算子の優先度がわかりにくいのもあるが、ポインタのデリファレンス演算子 * が前置演算子になっているのが原因だとおもう。他の演算子 関数呼び出しの ()・配列アクセスの [] は後置演算子で、ポインタの * よりも優先度が高いのでポインタ演算子を先に効かせたい場合に括弧が必要になって見た目が複雑になる。

void (*(*f[])())() の読み方

f は変数
f[] fは配列
*f[] 配列の要素はポインタ
(*f[])() ポインタは関数を指している
*(*f[])() 関数はポインタを返す
(*(*f[])())() 返ってきたポインタは関数を指している
void (*(*f[])())() 関数の戻り値はvoid

仮にポインタデリファレンスが前置 の * ではなくて後置の @ だとしたらどうなるか。

void (*(*f[])())()

void f[]@()@()

と書けて、最初の型以外は左から右に直線的に読むだけで済む。

IMG_20180606_001314

いってきた: 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

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

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2019-03-18
    • 今日の練習 2019-03-18
    • 今日の練習 2019-03-18
    • FINA/CNSG Diving World Series 2019 Sagamihara,JPN
    • FINA/CNSG Diving World Series 2019 Sagamihara,JPN
    • FINA/CNSG Diving World Series 2019 Sagamihara,JPN
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ