Burst BufferのためのGfarmファイルシステム

全文

(1)Vol.2017-HPC-161 No.2 2017/9/19. 情報処理学会研究報告 IPSJ SIG Technical Report. Burst Buffer のための Gfarm ファイルシステム建部修見1,a). 概要：Burst buffer は HPC アプリケーションのバースト的な I/O 性能要求を満たすために多くの HPC システムで用いられるようになった．本研究では，計算ノードローカルのストレージで構成される分散 burst. buffer を効率的に利用する Gfarm ファイルシステムの提案を行う．計算ノードローカルのストレージはジョブの割当期間しか利用できないため，ジョブスクリプトにより一時的な分散ファイルシステムを構成する．一時的なファイルシステムであるため，メタデータの永続性，冗長性を省くことができ，これにより，メタデータ性能の向上とファイルシステムの構築，撤去の時間削減を図った．性能評価の結果，1 クライアントからのディレクトリ作成性能は毎秒 1,100 から毎秒 14,700 となり，性能向上は 13.4 倍であった．また，2 ノードでは構築に 0.31 秒，撤去に 0.19 秒であった．. 1. はじめに CPU 性能の向上に対し，ストレージ性能の向上は鈍く，. burst buffer の利用法が広がるとき，書込性能だけではなく，読込性能，メタデータ性能も重要となる．本研究では読込性能やメタデータ性能を犠牲とするこ. その差は開く一方である．そのため，そのギャップを埋め. となく，並列書込性能を向上させる，計算ノードローカル. るために burst buffer が用いられるようになった．HPC ア. のストレージで構成される分散 burst buffer を用いた分散. プリケーションでは I/O はバースト的に行われることが. ファイルシステムの提案を行う．Gfarm ファイルシステ. 多く，一時的なバースト I/O を burst buffer で処理し，次. ムは，元々計算ノードのローカルストレージを用いること. のバースト I/O までの間に並列ファイルシステムに保存. を前提に，データアクセスの局所性を活用したスケーラブ. する．Burst buffer は並列ファイルシステムに対する中間. ルなアクセス性能を特徴とする．それらの特徴を活かし，. 的なストレージ層であり，計算ノードのローカルストレー. 分散 burst buffer のための設計を行う．書込性能，読込性. ジを用いる分散 burst buffer，burst buffer 用のストレージ. 能の向上については，既に提案，評価を行っている [12]．. ノードを用いる共有 burst buffer などの構成がある．. メタデータ性能については，永続性，冗長性を省くことに. Burst buffer は，前述のバースト的な書き込みの一時バッ. より性能向上を図る．計算ノードローカルのストレージは. ファ的な使い方だけではなく，一時ファイルの読み書き，. ジョブの割当期間しか利用できないため，永続性，冗長性. 入力データのステージング，入出力データのキャッシング，. は重要ではないと考えられるためである．そして，提案す. 更には burst buffer におけるデータのフィルタリングやス. る分散 burst buffer のための Gfarm ファイルシステムに. トリーム処理などへの利用も検討されている [5]．しかしな. ついて，メタデータ性能，また構築，撤去の時間について. がら，burst buffer の利用法はまだ確立されておらず，発. 性能評価を行う．. 展段階といえる．. 2. 関連研究. Burst buffer は，PLFS [1] や I/O デリゲーション [6] などのアプリケーションと並列ファイルシステムの間の中間. 並列アプリケーションと並列ファイルシステムの間に中. 的なストレージ層の研究開発から始まっている．それら中. 間的なストレージ層を設けて性能向上するものとして，並. 間的なストレージ層はストレージへの書込みを整列させ. 列ログ構造化ファイルシステム (Parallel Log Structured. て，書込性能を向上させることを目的としている．特に，. File System; PLFS) がある [1]．PLFS は並列アプリケー. PLFS はチェックポインティングのためのファイルシステ. ションのチェックポイントファイルの書込みを高速化する. ムとして並列書込みに特化した設計となっており，読込. ことを目的として開発された．チェックポイントファイル. 性能，メタデータ性能を犠牲にしている．しかしながら，. の書込みは大きく三種類ある．N 並列プロセスがそれぞれ. 1. 別々のファイルを作成する N-N パターン，N 並列プロセス. a). 筑波大学計算科学研究センター [email protected]. ⓒ 2017 Information Processing Society of Japan. 1.

(2) Vol.2017-HPC-161 No.2 2017/9/19. 情報処理学会研究報告 IPSJ SIG Technical Report. が共有ファイルにブロック分割で書込む N-1 セグメントパターン，ブロックストライド分割で書込む N-1 ストライドパターンである．このうち，並列ファイルシステムへの書込みでは N-N パターンはスケールするが，N-1 パターンはいずれも性能が殆どでない．これを解決するため，N-1 パターンを並列にログを保持することにより実質的に N-N パターンとするための中間的な層を導入する提案を行った．また，Nisar らはデリゲーションベースの I/O 機構を中間的なストレージ層に設け，並列書込みの性能向上を図った [6]．デリゲーションプロセスを並列ファイルシステムの. 図 1. Gfarm ファイルシステムの構成．. ストライプに対し静的に割当てることにより，書込みロック競合を削減を行う．計算ノードローカルのストレージによる分散 burst buffer. 本研究では，Gfarm ファイルシステム [9] をベースにこ. を用いたファイルシステムの研究に BurstFS [11] がある．. れらの問題について検討する．Gfarm ファイルシステムの. BurstFS は PLFS を元にした設計となっており，メタデー. 構成を図 1 に示す．Gfarm ファイルシステムはメタデー. タ性能，読込性能を向上させるため，MPI を用いた分散. タサーバ (gfmd)，ファイルサーバ (gfsd) とクライアント. KVS の MDHIM [3] にいくつかの最適化を施している．ま. （アプリケーション）で構成される．gfmd は，マスター. た，MDHIM の各ノードでは LevelDB [2] を用いている. サーバと任意数の同期スレーブサーバ，非同期スレーブ. が，LevelDB のコンパクション処理が性能低下の原因と. サーバで構成される．各 gfmd ではメモリ内に最新のメタ. なっている．これを改善するため，メタデータ処理で典型. データを保持し，ジャーナルファイルとバックエンドデー. 的な局所性を活用し平衡二分木を導入して性能向上を図る. タベースで永続化を行っている．また，冗長性を確保する. MetaKV [10] の研究も行われている．. ため，メタデータの更新はスレーブサーバに送信される．. 本研究は，これまでの研究と違い，計算ノードローカル. 同期スレーブサーバに対しては受信確認を待つが，非同期. のストレージを用いる分散ファイルシステムをベースにし. スレーブサーバは待たずに処理が進む．gfsd はストレー. ている．そのため，読込性能やメタデータ性能を犠牲にし. ジをアクセスするためのサーバであり，計算ノードロー. ている訳ではない．一方で，本研究ではメタデータサーバ. カルのストレージを用いる場合は，各計算ノードで起動. は分散されていないため，スケーラビリティという点が問. される．各計算ノードのアプリケーションは gfarm2fs で. 題である．しかしながら，メタデータはインメモリで管理. Gfarm ファイルシステムをマウントして POSIX でアクセ. し，サーバあたりの性能は高いため，クロスポイントがど. スするか，Gfarm のライブラリである libgfarm を用いて. のあたりにあるかは興味深い問題である．. アクセスする．. 3. 設計. 3.1 アクセス性能の向上. 計算ノードローカルのストレージシステムは，. Gfarm ファイルシステムではローカルストレージに対. PCIe(NVMe) 接続の SSD や NVRAM などで構成され，. するアクセスは，デスクリプタパッシングにより，gfsd を. ストレージ性能は HDD に比べ格段に高い．そのため，分. 経由することなくクライアントアプリケーションが直接. 散ファイルシステムのアクセス性能を向上させるため，. アクセスする．そのため，オーバヘッドは低い．一方，遠. オーバヘッドの少ない設計とする必要がある．また，各計. 隔ファイルアクセスは，クライアントと gfsd 間の pread,. 算ノードのローカルストレージに分散して格納されている. pwrite の RPC で行われる．InfiniBand など Verbs [4] が. データを効率的にアクセスするためには，ネットワークア. 利用可能な環境においては RDMA read, RDMA write を. クセスも高速に行う必要がある．更に，分散するデータに. 用いた RDMA 用の pread, pwrite の設計，実装を既に行っ. アクセスするためのメタデータ処理を高速にする必要が. ている [12]．RPC の設計を大幅に変更せず，アクセスする. ある．. データ転送について RDMA を用いる．また，メモリ登録. 一方，計算ノードローカルのストレージはジョブが割当. の方式も静的登録と動的登録について性能評価を行い，動. てられて実行中しか用いることができない．そのため，永. 的登録の方が性能が高いことが分かっている．InfiniBand. 続性や冗長性はそれほど重要ではないと考えられる．ま. FDR とメモリ上のファイルシステムである tmpfs を用い. た，その場合，実行の度に一時的にファイルシステムの構. た性能評価により，6 並列アクセスで RDMA write のネッ. 築，撤去を行うこととなるため，構築，撤去の時間も問題. トワーク性能である 6 GB/s に近い性能を達成することが. となる．. 分かっている．. ⓒ 2017 Information Processing Society of Japan. 2.

(3) Vol.2017-HPC-161 No.2 2017/9/19. 情報処理学会研究報告 IPSJ SIG Technical Report. 3.2 メタデータ性能の向上メタデータサーバは，メタデータ更新時には，永続化の. 高速化という観点では，バックエンドデータベースを構築しないことにより，データベースの初期化を省くことが. ためのジャーナルファイルの書込みと，冗長性のため同. できる．これにより，構築時には，設定ファイルの作成，. 期スレーブサーバへの更新の送信を行い，それらの完了. サーバの起動，停止スクリプトの作成，サーバの起動，撤. を待って，クライアントに返事を返す．また，ジャーナル. 去用スクリプトの作成を行うだけでよく，時間がかかる処. ファイルは非同期的にバックエンドデータベースに反映さ. 理が殆どなくなる．. れるが，ジャーナルファイルの大きさには制限があり，反. 4. 実装. 映が遅くその最大の大きさに達するとジャーナルファイルへの書込みはバックエンドデータベースへの反映を待つこととなる．一方，計算ノードローカルのストレージを用いる場合，. 計算ノードローカルのストレージで構成される分散 burst. buffer のための Gfarm ファイルシステムのために，バックエンドデータベースを用いない構成の実装と，バッチジョ. 分散ファイルシステムの利用期間はジョブの割当期間とな. ブスクリプトによりジョブの実行前後で Gfarm ファイル. る．そのため，永続性や冗長性はあまり重要ではないと考. システムの構築，撤去を行うためのスクリプトの実装につ. えられる．そこで，まずバックエンドデータベースを用い. いて述べる．. ない構成を考える．この場合，ジャーナルファイルへの書込みにより永続化を行うことができるが，一方でジャーナ. 4.1 バックエンドデータベースを用いない構成. ルファイルのサイズに制限があるため，バックエンドデー. gfmd では，データベースをアクセスするための共通. タベースがない場合は，ジャーナルファイルのサイズを越. インターフェースとして，db access という層を持ってい. えての永続化はできなくなる．しかしながら，同期スレー. る．その層で，PostgreSQL に対するアクセスを行うため. ブサーバあるいは非同期スレーブサーバを用いることによ. の db pgsql が実装されている．この層において，バック. り冗長性を保持することは可能である．. エンドデータベースを用いないインターフェースである. 冗長性が必要ない場合は，（非）同期スレーブサーバを. db none を実装する．. 用いない構成が考えられる．このとき，ジャーナルファイ. Gfarm ファイルシステムでは，殆どのメタデータはイン. ルの書込みによる永続化はジャーナルファイルのサイズ制. メモリで保持するが，拡張属性，また Gfarm 独自の XML. 限までとなり，それを越えると永続化ができなくなる．更. 拡張属性はサイズが大きくなる可能性があるため，一部を. に，全く永続性が必要ない場合は，ジャーナルファイルの. 除いてメモリでは保持していない．そのため，バックエン. 書込み自体を行わないことも考えられる．. ドデータベースを持たない場合は，それらのデータについ. 従って，以下のような構成をとることができる．. ( 1 ) 永続性なし，冗長性なし. ても全てインメモリで持つ必要がある．また，ジャーナルファイルを用いる場合，gfmd 起動時に. ( 2 ) ある程度の永続性あり，冗長性なし. ジャーナルファイルをバックエンドデータベースに全て反. ( 3 ) ある程度の永続性あり，冗長性あり. 映して，バックエンドデータベースを読み込んでインメモ. ( 4 ) 永続性あり，冗長性あり. リのメタデータを構築している．バックエンドデータベー. 永続性なしは，ジャーナルファイルの書込みを行わない構. スがない場合，この処理を行うことができない．そのため，. 成，ある程度の永続性ありは，ジャーナルファイルの書込. gfmd 起動時にジャーナルファイルを直接読込み，インメ. みは行うが，バックエンドデータベースは持たない構成，. モリのメタデータを構築する．. 冗長性ありは，（非）同期スレーブサーバを持つ構成である．なお，永続性ありは，バックエンドデータベースを持つ構成である．. 4.2 ファイルシステムの構築バッチジョブの実行前に，Gfarm ファイルシステムを構築し，終了後に撤去を行う．ファイルシステム構築にあ. 3.3 ファイルシステム構築の高速化. たり，各計算ノードにおけるローカルストレージは環境変. ファイルシステムの構築においては，各計算ノードの. 数 TDIR で与えられるとする．また，ユーザ名は環境変数. ローカルストレージに読み書き可能なファイルシステムが. USER，Gfarm ファイルシステムをマウントするマウント. 必要となる．また，実行ユーザ権限で構築ができると，管. ポイントは環境変数 MDIR で与えられ，Gfarm のコマンド. 理者権限を必要としないため，より容易に構築することが. 類は環境変数 BINDIR にインストールされているとする．. できる．Gfarm ファイルシステムでは，一般ユーザ権限で. 本節では，バッチキューイングシステムとして slurm [7]. ファイルシステムを構築することが可能である．従って，. を対象とするが，他のバッチキューイングシステムでも同. ユーザのジョブスクリプトの実行前後で，構築，撤去を行. 様のことは可能であると考えられる．. うことができる． ⓒ 2017 Information Processing Society of Japan. 図 2 に slurm による Gfarm ファイルシステムの構築ス. 3.

(4) Vol.2017-HPC-161 No.2 2017/9/19. 情報処理学会研究報告 IPSJ SIG Technical Report. 1: 2: 3: 4: 5: 6: 7: 8:. GFARM_CONFIG_FILE=$TDIR/etc/gfarm2.conf srun mkdir -p $TDIR/etc config-gfarm --prefix $TDIR -S -A $USER -b none sbcast -p $GFARM_CONFIG_FILE $GFARM_CONFIG_FILE sbcast -p $TDIR/etc/gfsd.conf $TDIR/etc/gfsd.conf sbcast -p $TDIR/etc/usermap $TDIR/etc/usermap srun $BINDIR/config-gfsd --prefix $TDIR -S srun $BINDIR/mount.gfarm2fs $GFARM_CONFIG_FILE $MDIR 図 2. 1: 2: 3: 4:. srun $BINDIR/umount.gfarm2fs srun $TDIR/etc/unconfig-gfsd.sh -f $TDIR/etc/unconfig-gfarm.sh -f srun rm -rf $TDIR 図 4. Gfarm ファイルシステムの撤去手順．. 16000. none none journal none slave pgsql pgsql journal pgsql slave. 14000. Gfarm ファイルシステムの構築手順．. 計算ノードローカルのストレージである TDIR 以下のディレクトリを用い，Gfarm ファイルシステムを構築する．3 行目で gfmd の構築と起動を行っている．ユーザ権限で構. operations per second. 12000. クリプトを示す．本スクリプトは bash で記述されている．. 10000 8000 6000 4000. 築するために，-S オプションをつけ，またバックエンド. 2000. データベースを用いないために，-b none オプションをつけ. 0 0. ている．また，TDIR 以下のディレクトリを用いて設定するため，–prefix オプションにより TDIR を指定している．. config-gfarm により，いくつかの設定ファイルが作成さ. 図 5. 20. 40. 60. 80. 100 120 [seconds]. 140. 160. 180. 200. 1 クライアントで 300,000 ディレクトリを作成する時の性能．. れる．これらは全計算ノードで必要となるため，4 行目か. 起動準備が整うため，8 行目で gfmd を起動する．9 行目か. ら 6 行目において sbcast により割当てられた全計算ノー. ら 12 行目は全計算ノードで必要な設定ファイルをコピー. ドにコピーしている．なお，2 行目で srun により全計算. しているが，ここで共有秘密鍵もコピーしている．あとは. ノードで TDIR/etc ディレクトリを作成しているが，この. 図 2 のスクリプトと同じである．. 処理は sbcast によるコピーを成功させるためにあらかじめ. 図 4 に，Gfarm ファイルシステムの撤去スクリプトを. 行っている．7 行目で，全計算ノードで gfsd の設定と起動. 示す．まず 1 行目で，割当てられた全計算ノードにおいて. を行っている．こちらも gfmd の設定と同様に–prefix オプ. Gfarm ファイルシステムをアンマウントする．2 行目で，. ションと-S オプションをつけている．srun により，割当て. 全計算ノードにおいて gfsd を停止し，設定を削除する．3. られた全計算ノードで実行される．最後に 8 行目で，全計. 行目で gfmd を停止し，設定を削除する．最後に，全計算. 算ノードの MDIR に Gfarm ファイルシステムをマウント. ノードにおいて TDIR 以下の全てのエントリを削除する．. している．. 5. 性能評価. スパコン，あるいはクラスタ内において Gfarm ファイルシステムを構築する場合，認証方式として共有秘密鍵. 計算ノードローカルの burst buffer を用いる Gfarm ファ. 方式を用いるのが適している．認証が軽く，また，安全に. イルシステムに対する性能評価を行う．なお，ファイルア. 秘密鍵を共有できるためである．図 2 のスクリプトでは，. クセス性能については既に [12] で報告しているため，本研. この共有秘密鍵はユーザのホームディレクトリに置かれ. 究では，メタデータ性能，ファイルシステムの構築，撤去. る．従って，全計算ノードからホームディレクトリがアク. 時間について性能評価を行う．. セス可能であればこのスクリプトで問題ない．しかしながら，JCAHPC の Oakforest-PACS など大規模システムで. 5.1 メタデータ性能. はホームディレクトリは計算ノードからはアクセスできな. メタデータサーバの性能評価を行うため，1 クライアン. い．この場合，共有秘密鍵の格納場所を設定ファイルで変. トで 300,000 ディレクトリを作成する時の性能を図 5 に示. 更する必要がある．. す．このグラフは X 軸が経過時間を表し，Y 軸は秒間に作. 図 3 に，共有秘密鍵の格納場所を変更した Gfarm ファ. 成されたディレクトリ数を表す．評価で用いた各ノードは，. イルシステムの構築スクリプトを示す．1 行目で環境変数. 2.4GHz の 12 コア Xeon E5-2695v2×2 ソケット，64GB メ. GFARM CONFIG FILE を export しているが，これは 7. モリ (1866MHz 8GB DDR3×8) であり，InfiniBand FDR. 行目で実行する Gfarm コマンドにおいてデフォルトとは違. で接続されている．ストレージは，ストレージ性能がボト. う設定ファイルを参照するためである．3 行目の gfmd の. ルネックとならないように tmpfs（メモリ上のファイルシ. 構築において，-N オプションを追加し，gfmd の起動を抑. ステム）で構成している．. 制している．4 行目から 6 行目において，必要な設定ファ. まず，PostgreSQL をバックエンドデータベースとして. イルに共有秘密鍵の格納場所の指定を追加する．7 行目の. 用いる場合，スレーブ gfmd を用いる構成では 20 秒ほど，. gfkey コマンドで共有秘密鍵を作成する．ここで gfmd の. 用いない構成では 10 秒ほどで，ディレクトリ作成性能は毎. ⓒ 2017 Information Processing Society of Japan. 4.

(5) Vol.2017-HPC-161 No.2 2017/9/19. 情報処理学会研究報告 IPSJ SIG Technical Report. 1: export GFARM_CONFIG_FILE=$TDIR/etc/gfarm2.conf 2: srun mkdir -p $TDIR/etc 3: config-gfarm --prefix $TDIR -S -N -A $USER -b none 4: echo shared_key_file $TDIR/etc/.gfarm_shared_key >> $TDIR/etc/gfmd.conf 5: echo shared_key_file $TDIR/etc/.gfarm_shared_key >> $TDIR/etc/gfsd.conf 6: echo shared_key_file $TDIR/etc/.gfarm_shared_key >> $GFARM_CONFIG_FILE 7: gfkey -c 8: $TDIR/etc/init.d/gfmd start 9: sbcast -p $GFARM_CONFIG_FILE $GFARM_CONFIG_FILE 10: sbcast -p $TDIR/etc/gfsd.conf $TDIR/etc/gfsd.conf 11: sbcast -p $TDIR/etc/usermap $TDIR/etc/usermap 12: sbcast -p $TDIR/etc/.gfarm_shared_key $TDIR/etc/.gfarm_shared_key 13: srun $BINDIR/config-gfsd --prefix $TDIR -S 14: srun $BINDIR/mount.gfarm2fs $GFARM_CONFIG_FILE $MDIR 図 3. ホームディレクトリを計算ノードからアクセスできない場合の Gfarm ファイルシステムの構築手順．. 構築. 撤去. PostgreSQL. 11.90. 2.05. 0.35. none 0.05 0.01 Gfarm ファイルシステムの構築，撤去時間 (sec)．. 秒 1,100 ほどになっている．ジャーナルファイルあるいは内部バッファが最大となったときに，更新はバックエンド. mount.gfarm2fs config-gfsd sbcast start gfmd gfkey config-gfarm mkdir. 0.3 0.25 time [second]. 表 1. バックエンド DB. データベースへの反映を待つ必要があるためである．一方，. 0.2 0.15 0.1. バックエンドデータベースを用いない場合は，そのような. 0.05. 待ちは存在しない．スレーブ gfmd とジャーナルファイル 0. を用いる構成で平均毎秒 4,960，ジャーナルファイルを用いる構成で平均毎秒 8,360，ジャーナルファイルを用いない. config. 図 6. 計算ノードへの Gfarm ファイルシステムの構築時間の内訳．. 構成で平均毎秒 14,700 の性能であった．300,000 ディレクトリを作成する時間は，PostgreSQL とジャーナルファイ. 次に，slurm を用いて，計算ノードのローカルストレージ. ルを用いる構成で 196 秒，PostgreSQL と内部バッファの. を用いる Gfarm ファイルシステムの構築，撤去時間につい. 構成で 132 秒であった．バックエンドデータベースをもた. て評価する．評価で用いた各ノードは，2.0GHz の 14 コア. ない構成では，スレーブ gfmd とジャーナルファイルを用. Xeon E5-2660v4 (Broadwell-EP)×2 ソケット，64GB メモ. いる構成で 60 秒，ジャーナルファイルを用いる構成で 36. リ (2400 8GB DDR4×8) であり，InfiniBand EDR で接続. 秒，ジャーナルファイルを用いない構成で 20 秒であった．. されている．各ノードでは Linux 3.10.0 (CentOS 7.3.1611). 5.2 ファイルシステム構築時間. SSD DC P3608 を RAID0 で用い，ファイルシステムは. を用いている．ストレージは，NVMe 接続の 1.6TB Intel 次に，ファイルシステムの構築時間を評価する．評価で用いたノードは 2.4GHz の 12 コア Xeon E5-2695v2 (Ivy. Bridge-EP)×2 ソケット，64GB メモリ (1866MHz 8GB. XFS である．スクリプトは図 3 と図 4 を用いた．また，評価では計算ノードを 2 ノード用いた．. DDR3×8) であり，Linux 2.6.32 (CentOS 6.9) を用いてい. 図 6 に計算ノードへの Gfarm ファイルシステムの構築. る．ストレージは tmpfs で構成している．このとき，Gfarm. 時間の内訳を示す．構築では，全計算ノードで実行する. ファイルシステムの構築と撤去の時間を表 1 に示す．. gfsd の初期化と起動，マウント処理にもっとも時間がかか. PostgreSQL は，PostgreSQL をバックエンドデータベースとして構築するもの，none はバックエンドデータベー. り，初期化では 0.097 秒，マウント処理で 0.085 秒かかっている．トータルでは 0.31 秒であった．. スを用いないものである．構築，撤去の時間はそれぞれ. 図 7 に計算ノードに構築した Gfarm ファイルシステム. config-gfarm と unconfig-gfarm.sh の実行時間である．構. の撤去時間の内訳を示す．撤去では，全計算ノードで実行. 築については，PostgreSQL の場合，12 秒ほどかかってい. するアンマウント処理と gfsd の停止にもっとも時間がかか. るが，バックエンドデータベースを用いないと 0.05 秒で完. り，それぞれ 0.059 秒，0.069 秒であった．また，トータル. 了している．撤去もバックエンドデータベースを用いない. では 0.19 秒であった．. 場合は 0.01 秒である． ⓒ 2017 Information Processing Society of Japan. 5.

(6) Vol.2017-HPC-161 No.2 2017/9/19. 情報処理学会研究報告 IPSJ SIG Technical Report 0.2. rm -rf stop gfmd stop gfsd umount. 0.18 0.16. [4]. time [second]. 0.14 0.12 0.1. [5]. 0.08 0.06. [6]. 0.04 0.02 0 destroy. 図 7. 計算ノードに構築した Gfarm ファイルシステムの撤去時間の内訳．. [7] [8] [9]. 6. まとめ. [10]. 計算ノードローカルのストレージで構成される分散 burst. buffer を効率的に利用する Gfarm ファイルシステムの提案を行った．ファイルアクセスを高速化するため， pread,. pwrite プロトコルに RDMA を用いた．また，計算ノード. [11]. ローカルのストレージは，ジョブの割当期間しか利用できないことから，永続性，冗長性を持たない構成を提案し，メタデータ性能を向上させた．永続性，冗長性を持たない場合，1 クライアントでのディレクトリの作成性能は毎秒. 14,700 であった．永続性，冗長性を持つ場合は毎秒 1,100 であったため，性能向上は 13.4 倍であった．また，ジョブ. [12]. Parallel Key/Value Framework for HPC, 7th USENIX Workshop on Hot Topics in Storage and File Systems (HotStorage 15), Santa Clara, CA, USENIX Association (2015). Hilland, J., Culley, P., Pinkerton, J. and Recio, R.: RDMA Protocol Verbs Specification (2003). https://tools.ietf.org/html/draft-hilland-rddp-verbs-00. NERSC: Burst Buffer Architecture and Software Roadmap. http://www.nersc.gov/users/computationalsystems/cori/burst-buffer/burst-buffer/. Nisar, A., k. Liao, W. and Choudhary, A.: DelegationBased I/O Mechanism for High Performance Computing Systems, IEEE Transactions on Parallel and Distributed Systems, Vol. 23, No. 2, pp. 271–279 (2012). SchedMD: Slurm Workload Manager . https://slurm.schedmd.com/. Tatebe, O.: Gfarm File System. http://sourceforge.net/projects/gfarm/. Tatebe, O., Hiraga, K. and Soda, N.: Gfarm Grid File System, New Generation Computing, Vol. 28, No. 3, pp. 257–275 (2010). Wang, T., Moody, A., Zhu, Y., Mohror, K., Sato, K., Islam, T. and Yu, W.: MetaKV: A Key-Value Store for Metadata Management of Distributed Burst Buffers, 2017 IEEE International Parallel and Distributed Processing Symposium (IPDPS), pp. 1174–1183 (2017). Wang, T., Mohror, K., Moody, A., Sato, K. and Yu, W.: An Ephemeral Burst-buffer File System for Scientific Applications, Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC ’16, Piscataway, NJ, USA, IEEE Press, pp. 69:1–69:12 (2016). 建部修見, 佐々木慎, 高橋一志, 大山恵弘: Gfarm ファイルシステムにおける RDMA アクセスの設計, 研究報告ハイパフォーマンスコンピューティング (HPC), Vol. 2017HPC-158, No. 12, pp. 1–6 (2017).. スクリプトにより計算ノードローカルのストレージを用いる一時的な Gfarm ファイルシステムを構成し、2 ノードでは構成に 0.31 秒，撤去に 0.19 秒であった．なお，RDMA でアクセスを行う Gfarm ファイルシステムは，2016 年 12 月に Gfarm 2.7.0 として，バックエンドデータベースを利用しない Gfarm ファイルシステムは，. 2017 年 2 月に Gfarm 2.7.2[8] としてリリースした．今後は，より大規模な環境で性能評価を行っていきたい．謝辞本研究の一部は JST-CREST JPMJCR1303 「EBD：次世代の年ヨッタバイト処理に向けたエクストリームビッグデータの基盤技術」，JST-CREST JPMJCR1413 「広域撮像探査観測のビッグデータ分析による統計計算宇宙物理学」，JSPS 科研費 JP17H01748 による．参考文献 [1]. [2] [3]. Bent, J., Gibson, G., Grider, G., McClelland, B., Nowoczynski, P., Nunez, J., Polte, M. and Wingate, M.: PLFS: a checkpoint filesystem for parallel applications, Proceedings of the Conference on High Performance Computing Networking, Storage and Analysis, pp. 1– 12 (2009). Ghemawat, S. and Dean, J.: LevelDB . https://github.com/google/leveldb. Greenberg, H., Bent, J. and Grider, G.: MDHIM: A. ⓒ 2017 Information Processing Society of Japan. 6.

(7)