Lustreのストライピングアクセスパターンに配慮した集団型MPI-IOの性能向上に向けた試み

全文

(1)Vol.2015-HPC-149 No.3 2015/6/26. 情報処理学会研究報告 IPSJ SIG Technical Report. Lustre のストライピングアクセスパターンに配慮した集団型 MPI-IO の性能向上に向けた試み辻田祐一1,a). 堀敦史1,b). 石川裕1,c). 概要：並列ファイルシステムの中でも，Lustre は近年 PC クラスタだけでなく，大型並列計算機でも利用されており，MPI-IO を含む並列入出力インタフェースを用いた高速な入出力が利用できる．MPI-IO の代表的実装として ROMIO が広く利用されているが，Lustre を用いた MPI-IO による集団型並列入出力において，ノードあたりに複数のプロセスを起動する場合に，Lustre のストライピングアクセスパターンに関して非効率な入出力になっている問題がある．そこで我々は，Lustre のストライピングアクセスパターンに最適化した高速化実装を提案する．我々は，Lustre のストライピングアクセスパターンと MPI プロセスが配置されているノード群の情報を基に，Lustre に対し入出力処理を行うプロセス群の最適なレイアウトを生成する機能を ROMIO の実装内部に追加した．評価試験として 4 台の PC クラスタを用い，HPIO ベンチマークによる派生データ型アクセスパターンに対する集団型書き込み処理において最大で約 3 倍の性能向上を確認した．キーワード：MPI-IO, Lustre, ROMIO, two-phase I/O, アグリゲータ. 1. はじめに. 性能向上においては，MPI-IO の性能向上が不可欠である．. MPI-IO インタフェースを実装した代表的なライブラリ. PC クラスタにおいて Lustre [1] は広く用いられている. として ROMIO [5] があり，Lustre を含む様々な並列ファ. 並列ファイルシステムであり，近年は大型並列計算機にお. イルシステムへの高速な入出力機能が利用できる．上述の. ける並列ファイルシステムとしても利用されるようになっ. HDF5 や Parallel netCDF などを用いた場合も含め，並列. た．Lustre は，ファイルの情報を管理する複数のメタサー. 計算において特徴的な入出力として多次元データを複数. バ（Meta Data Server：以下，MDS）とデータ自体を. のプロセス間で入出力を行うケースがあるが，この際に，. 管理するデータサーバ（Object Storage Server：以下，. MPI-IO のレベルでは不連続なアクセスパターンとなる．. OSS）から構成され，MDS にはファイル情報を保管する. 不連続パターンに対し，飛び飛びのデータ領域のみをアク. Meta Data Target（以下，MDT）が，OSS にはデータを. セスすると著しく性能が低下するため，ROMIO では，この. 保管する Object Storage Target（以下，OST）が繋がって. ようなケースにおいて高速な並列入出力を可能にする実装. いる．Lustre を用いたファイルアクセスでは，ユーザの設. として Two-Phase I/O（以下，TP-IO） [6] を用いている．. 定により複数の MDT および OST によるストライピング. この実装は飛び飛びのアクセスパターンに対して，最初に. アクセスによる高速な入出力が可能になっている．. ファイルから空白部分も含めてプロセス毎に等間隔に連続. 並列計算における入出力インタフェースとしては，MPI に. に分割して一時的なバッファ上に読出し，書き込むデータ. おける入出力インタフェースである MPI-IO に加え，アプリ. をプロセス間通信を通してこのバッファ上で上書きした後. ケーション向けの入出力インタフェースである HDF5 [2] や. にファイルシステム側に書き戻す read-modify-write の手. netCDF [3] などが利用されている．特に HDF5 や netCDF. 法を行っており，ファイル領域を全て網羅するまでこの処. の並列版である Parallel netCDF [4] では，並列入出力機能. 理を繰り返す．この際にファイルシステムとの入出力処理. を MPI-IO を用いて実装しており，これらの並列入出力の. を MPI プロセスの一部あるいは全てに行わせており，このプロセスを TP-IO ではアグリゲータと呼んでいる．. 1 a) b) c). 理化学研究所計算科学研究機構 [email protected] [email protected] [email protected]. ⓒ 2015 Information Processing Society of Japan. 現行の ROMIO 実装では，通常はノードに 1 個のアグリゲータを割り当てるが，ノードあたりに複数のプロセスを. 1.

(2) Vol.2015-HPC-149 No.3 2015/6/26. 情報処理学会研究報告 IPSJ SIG Technical Report. 起動する場合には，アグリゲータにならなかったプロセス. Data gaps. File. Data gaps. （非アグリゲータ）は，アグリゲータがファイルアクセスをしている間は次のデータ送信を開始しても処理がブロック. 1. File domain of process 0. File domain of process 1. Read. Read. され待ち時間が発生する．そこでノードあたりに複数のア長を短くできるため，非アグリゲータでの待ち時間の短縮. User buffer on process 0. 2. User buffer on process 1. Data exchanges and modifications of collective buffers. に繋がる可能性があり，ROMIO では，ノードあたりに複数のアグリゲータを配置させる機能がサポートされている．しかしながら，この機能を用いてノードあたりに複数. Collective buffer on process 1. Collective buffer on process 0. グリゲータを配置すれば，1 個のアグリゲータが扱う I/O. Collective buffer on process 0. 3. Write. Collective buffer on process 1 File. Write. のアグリゲータを配置した場合，現行の ROMIO の場合，. Lustre のストライピングアクセスパターンとアグリゲータのファイルアクセスや TP-IO 内のデータ交換等とのミスマッチにより大きく性能を落としてしまう問題がある．そこで我々は Lustre のストライピングアクセスパター. 図 1. TP-IO による集団型書き込みの処理の流れ（2 プロセス間での例）．図の上から下に向かって処理が行われている様子を示しており，1，2 及び 3 の処理は，それぞれファイルからの読出し，アグリゲータへのデータ送信，並びにファイルへの書き戻し処理を示している．. ンに配慮したアグリゲータ配置を実現させることにより，ノードあたりに複数のアグリゲータが配置された場合で. タ領域（File domain）を担当するプロセス間のデータの送. も性能向上を可能にする最適化実装を提案する．本実装は. 受信と CB 上でのデータの上書きが行われる（図中の 2）．. ROMIO 内部の実装に対し，アグリゲータ選定を行う機能. 書き込むべきデータが CB に上書きされた後，各プロセス. に MPI プロセスが配置されるノード情報と Lustre のスト. は CB 内のデータをファイル上の元の場所に書き戻す（図. ライピング情報の両方を利用した最適化配置を生成する機. 中の 3）．CB は有限の大きさのため，この一連の処理（以. 能を追加することで実現している．この機能を利用するこ. 下，TP-IO サイクル）を複数回繰り返して I/O 処理を完了. とによって，ユーザ側が指定する任意の MPI プロセス配. させる．この図では全ての MPI プロセスがアグリゲータ. 置に対して，これとは関係無く，PC クラスタのノードと. の役割を担っているが，ノード間の MPI プロセス配置な. Lustre の構成に最適化したアグリゲータ配置が実現でき，. どに応じて，一部の MPI プロセス群にのみアグリゲータ. その結果としてノードあたりに複数のアグリゲータを配置. を担当させることもできる．. する場合に，さらなる入出力性能の向上が実現される．今. PC クラスタにおける ROMIO を用いた Lustre への集. 回行った 4 ノードの PC クラスタでの性能評価では現行の. 団型 I/O においては，基本的に各ノードに 1 プロセスず. ROMIO に対し，最大で 3 倍程度の性能向上を確認した．. つアグリゲータとして割り当てる．さらに I/O 性能を高め. 本稿では，まず第 2 章において，本実装の開発背景にあ. る場合などに，ユーザ側で MPI Info set によりノードあ. る現行の ROMIO の実装とアグリゲータ配置の仕組みと. たりのアグリゲータの数を増やすこともできる．このアグ. 問題点について説明した後に，本提案手法について第 3 章. リゲータの割り当ては，使用するノードのホスト名のリス. で説明する．次に第 4 章にて今回行った性能評価試験の結. トを用いた ROMIO の実装内部の選出機能が担っており，. 果について報告する．第 5 章では関連研究について本提案. ノード毎に詰めてゆく形でアグリゲータを配置している．. 手法との比較検討を行い，最後に第 6 章で本稿のまとめを. ROMIO は様々な並列ファイルシステムにも対応するた. 行う．. 2. Two-Phase I/O. めに，下位レイヤに ADIO と呼ばれるファイルシステム向けドライバレイヤを持っている．この ADIO には MPI-. IO インタフェースレイヤとの接続部分になる共通インタ. TP-IO による集団型書き込みでの処理の流れを図 1 に. フェースレイヤがあり，その下に各ファイルシステムに特. 示す．この図では簡単な例として 2 プロセス間での処理. 化したドライバレイヤが置かれている．Lustre も ROMIO. を示している．I/O 処理を行う MPI プロセス間で対象の. の ADIO レイヤでサポートされており，Lustre 向けに最適. ファイル領域を空白を含め連続に均等に分割し，担当領域. 化された高速化実装が実現されている [7]．この高速化実. から一時的なメモリ領域へのデータ読出しを行う（図中. 装は，Lustre のストライピング情報を事前に取得しておく. の 1）．なお，この一時的なバッファ領域を TP-IO では，. ことで，各アグリゲータ上で Lustre のストライピングパ. Collective buﬀer（以下，CB）と呼んでおり，ファイルアク. ターンに合わせたデータ並べ替えを行っており，これによ. セスやプロセス間のデータアクセスの基本サイズになる．. り各アグリゲータは特定の OST へのアクセスに限定され. ファイル上の空白部分を含む CB 上に読み込まれたデータ. るため，アグリゲータ間での OST への書き込み処理の混. に対し，書き込むべきデータに関して予め計算しておいた. 雑が解消されている．. オフセットおよびデータ長の情報に基づいて，個々のデー. ⓒ 2015 Information Processing Society of Japan. しかしながらマルチソケット化やマルチコア化された. 2.

(3) 䝥䝻䝉䝇㓄⨨䠖. 䝥䝻䝉䝇㓄⨨䠖ᥦ᱌ᡭἲ䛻䜘䜛. 䛷䛾䝕䞊䝍஺᥮䛾ᵝᏊ. 䛷䛾䝕䞊䝍஺᥮䛾ᵝᏊ Vol.2015-HPC-149 No.3 2015/6/26. 情報処理学会研究報告 IPSJ SIG Technical Report. Striping. Striping. i ii. OST #0 i iii ii iv. iv. (i). 0. 1 0. OST #0 i iii iv ii. OST #1 iii 4. (iii). 0. 5. 4. 1. (ii). 6. 3 2. 3. 6. 図 2 現行の ROMIO での Lustre へのアクセスパターンとアグリ. (iv). 2. 7 図 3. 表し，丸の中の数字は MPI ランクを表している．また，角の ᥦ᱌ᡭἲ䠄䝕䝣䜷䝹䝖䛾䜰䜾䝸䝀䞊䝍㓄⨨䠄䝥䝻䝉䝇䝜䞊䝗䠖㻌䝜䞊䝗䚸 ಶ䠅丸い四角は同じストライピングアクセスのラウンドで動作す. 1. 6. 5 3. (iii). (iv). 6. 3 4. ゲータ間のデータ送受信パターンの例．四角は一つのノードを. 4 2. (iii). 7. (ii). (i). 1 0. (iv). 2. (ii). (i). 5. OST #1 i iii iv ii. 7 5. 7. 提案手法による ROMIO でのアグリゲータのレイアウトとデータ送受信パターン例（2 ノードで各々のノードに 4 プロセ. 䛾䜰䜾䝸䝀䞊䝍㓄⨨䠄䝥䝻䝉䝇ス起動して 2 個の OST にアクセスする場合）. 䝜䞊䝗䠖㻌䝜䞊䝗䚸. るプロセスを明示している．. PC サーバを用いた近年のクラスタ環境では，ノードあたり. いる．. に複数の MPI プロセスを起動することも容易になり，その. • アグリゲータのレイアウトに関する最適化. 結果，ROMIO の TP-IO を用いた Lustre への並列入出力. • MPI Isend/MPI Irecv 対によるプロセス間データ通信. 処理が効率的に動作しないケースが出てくる．例えば図 2. 順の最適化. に示すように，各ノードに 4 プロセスずつで，2 ノード全体. 実装対象として，MVAPICH2 ver. 2.1rc1 を選択し，この. で 8 プロセスを起動して 2 個の OST を有する Lustre に対. 中にある ROMIO の実装の一部に対し，上記の 2 つの最適. し集団型書き込みを行う場合を考える．この図において，. 化を実現する改変を行った．以下，それぞれの実装の仕組. 同じラウンドでストライピングアクセスをするプロセス群. みについて説明する．. を角の丸い四角で囲んでおり，図中の (i) から (iv) はストライピングアクセスのラウンド番号と対応している．この. 3.1 アグリゲータのレイアウトの最適化. 場合，現行の ROMIO のアグリゲータ配置では，Lustre へ. 現行の ROMIO では，MPI プロセス群が配置されている. のストライピングアクセスにおいて，同じノードのアグリ. ノード群に予め指定された個数，あるいは指定が無ければ. ゲータからそれぞれの対象となる OST へのアクセス（読出. ノードあたり 1 個ずつアグリゲータを配置するが，いずれ. しおよび書き込み）が発生する（例えば，ランク 0 および. の場合もノード毎に個数分詰めて配置している．我々は，. ランク 1 から，それぞれ OST#0 および OST#1 へのアク. この機能に改変を加え，ノード間をラウンドロビンで巡回. セス：図中の i)．この場合，当該ノードからのネットワー. する配置リストを生成するようにした．全プロセスのラン. クの帯域を共有する格好になり，スループットが低下する. ク情報がこのリストに格納された後に，リストの先頭から. 恐れがある．また，アグリゲータとなるプロセスは担当す. 当該ランクのプロセスをアグリゲータとすることで，ノー. るファイルドメイン内で必要なデータを自分自身を含む全. ド間をラウンドロビン配置させるレイアウトになる．この. プロセスから MPI Isend と MPI Irecv 対によって受信す. レイアウトによって，2 章で述べた通信経路の混雑が解消. るが，このデータの送受信においても問題がある．例えば. される．. (i) のグループのランク 0 及び 1 のプロセスは，それぞれ自. 例えば 2 ノードを用いたケースで各ノードに 4 つずつプ. 身を含む 8 個のプロセスからデータを受け取るが，両者と. ロセスを起動して 2 個の OST へのアクセスをする場合に，. も同じノードにあるため，ノードへの通信が混雑する可能. このレイアウトを適用すると図 3 に示すようになる．図 2. 性がある．これによって TP-IO の性能が低下する可能性. とこの図の通信パターンを比較すると，前者ではストライ. がある．. ピングアクセスの各々のラウンドで 2 つのアグリゲータに. 3. Lustre のストライピングアクセスパターンを配慮した最適化実装. 全プロセスからデータが送られてくるので当該ノードへの通信経路の混雑が発生するが，提案手法を用いれば，ノード間で通信を分散できるので，各々のノードの通信経路の. 前述の TP-IO での Lustre への非効率的なアクセスが発. 混雑を緩和できる．また，ストライピングアクセスの各々. 生する問題に対し，我々はアグリゲータの配置方法に注目. のラウンドでのアグリゲータから Lustre のターゲットの. し，Lustre のストライピングアクセスに合わせた最適な配. OST へのアクセスにおいても，提案手法では別々のノード. 置方法を実現する実装を検討している．我々の改変実装で. からのアクセスになるため，ファイルアクセス時の通信経. は，以下の 2 つの最適化を現行の ROMIO に対し行って. 路の混雑を解消できる可能性がある．. ⓒ 2015 Information Processing Society of Japan. 3.

(4) Vol.2015-HPC-149 No.3 2015/6/26. 情報処理学会研究報告 IPSJ SIG Technical Report. 3.2 MPI Isend/MPI Irecv 対によるデータ交換順の最適. 表 1. 化支援前述のアグリゲータのレイアウト最適化機能とは別に，. 使用した PC クラスタおよび Lustre を構成するノード群の仕様. PC cluster (4 computing nodes) Computing. CPU. 1× Intel Xeon E3 1280 V2. node. Memory. 32 GiB. TP-IO 内部の MPI Isend/MPI Irecv 対の発行順の最適化支援機能も実装した．これは現行の Lustre 向けの ROMIO. Network. 実装で用いられている上記 2 つの非同期通信関数によるアグリゲータへのデータ送信（TP-IO のデータ交換フェー. MDS/OSS. CPU. MPI Irecv について，データを送信してくるプロセス全部. 1× Intel Xeon E3-1270 V3. Memory. 32 GiB. Network. 1× Mellanox InfiniBand FDR. Storage. CPU. 2× Intel Xeon E5-2640 V2. server. Memory. 64 GiB. Network. Mellanox InfiniBand FDR. Disk system. 4× RAID10 (∼ 4 TiB). RAID. LSI MegaRaid SAS 9260-4i. ズ）に関して，発行順を変えて通信時間の短縮を狙うものである．現行の ROMIO においては，アグリゲータは. 1× Mellanox InfiniBand FDR Lustre. に対し，先にランク順に発行すると共に，アグリゲータを含む全プロセスが MPI Isend をデータ送信対象のアグリ. (2 links). ゲータに対しランク順に発行している．この場合，ランクの先頭の方と後ろの方のプロセス間で通信時間のばらつき. controller. ⛉◊㈝䝔䞊䝬䛾⌧≧. が出る可能性がある．また，ノード内に複数のプロセスがある場合，ノード間通信とノード内通信が混在しているが，これらに配慮した設計になっていない．. MDT. 我々の提案手法では，現行の ROMIO の通信方式（以下，. MDS. Comp#0. OSS #0. さいノード間通信を先に発行させるが，ランク順に発行さ. Comp#0. せる方式（以下，aware-1）とノード間通信を先に発行し，. Comp#0. IB SW. normal）に加え，レイテンシーが大きく通信バンド幅も小. OST#0 OST#2. OSS #1. かつ各々のプロセスが自ノードより一つずつ後のノードに. Comp#0. 向かって通信を発行する方式（以下，aware-2）の 2 つを. OST#1. 実装した．aware-1 方式に比べ aware-2 方式は通信開始時に特定のノードに通信が集中しないように配慮したもの. Storage server 䠄iSCSI target). で，特にプロセス数が多く，かつノード内にもプロセス数が多いケースでは有利に働くと考えて実装した．. 4. 性能評価. OST#3. Lustre. 図 4. 試験環境の PC クラスタおよび Lustre のノード群の接続レイ. アウト ྛィ⟬䝜䞊䝗䠄. 䠅䠖㻌. 䝜䞊䝗䠈䝁䜰. 今回実装した ROMIO への拡張機能に対し，4 ノード構成の PC クラスタと 1 個の MDT と 4 個の OST を有す. ROMIO に対し，HPIO ベンチマーク [8] を用いて性能評. る Lustre を用いて性能評価を行った．使用した PC クラ. 価を行った．以下，それぞれの結果と考察を述べる．. スタおよび Lustre を構成するノード群の仕様を表 1 に示す．またネットワーク接続を含めた PC クラスタおよび. 4.1 Lustre での入出力時間の評価. Lustre のノード群の構成図を図 4 に示す．MDT は MDS. 試験環境での Lustre への入出力時間に関して，ストライ. のノードのハードディスク上に構築した．一方，2 つの. ピングカウントを 4，ストライピングサイズを 16 MiB に. OSS には，ぞれぞれ 2 個の OST が配置され，それらの. した時に，プロセス配置を変えながら計測した結果を表 2. OST は iSCSI によりストレージサーバにある RAID10 の. に示す．なお，プロセス全体での I/O 長は，後で述べる. ストレージにアクセスする構成にした．なお，Lustre を. HPIO ベンチマークでの評価での I/O 長に合わせており，. 構成するノードを含め全てのノードにおいて OS として. 全体で約 9 GiB の入出力を行った．この評価では TP-IO. Linux kernel ver. 2.6.32.431 を用い，InfiniBand による通. でアグリゲータとなるプロセス群のレイアウトが書き込. 信には OFED ver. 3.5.2 を利用した．実装対象の MVA-. み性能に与える影響を調べるため，ノード数とノードあた. PICH2 ver.2.1rc1 はこの OFED のドライバを用いて構築. りに起動するプロセスの数を変えて，4 個の OST を有す. した．この PC クラスタ環境を用いて，最初に本提案手法の. る Lustre への POSIX-I/O による入出力処理の時間を計測した．なお，各々の MPI プロセスが書き込むデータサイ. 評価に必要な基礎的な評価として，プロセス配置による. ズはストライピングサイズと同じ 16 MiB とした．また，. Lustre への入出力性能やデータ通信時間の計測を行った．. ファイルアクセスの領域は MPI ランク順に連続になるよ. 次に今回実装した最適化機能を有する ROMIO と現行の. うにした．ファイルをオープンした際のアクセスモードは. ⓒ 2015 Information Processing Society of Japan. 4.

(5) Vol.2015-HPC-149 No.3 2015/6/26. 情報処理学会研究報告 IPSJ SIG Technical Report 表 2 POSIX-I/O による複数の MPI プロセスによる Lustre への書き込み. 読み出し. 配置. 時間 (s). 時間 (ms). 1. 4. bunch. 3.2333. 1.6438. 4. 1. scatter. 1.3260. 0.5569. 4. 2. bunch. 1.2711. 2.5941. scatter. 1.4759. 0.4052. bunch. 1.2833. 1.8145. scatter. 1.5681. 0.2886. bunch. 1.5008. 1.2652. scatter. 1.8237. 0.2017. 4. 4. 8. ROMIO 内部の実装と同じ設定にしたため，buﬀered I/O で行われており，かつ Lustre のクライアントキャッシュや. read-ahead 機能が有効になっている．. Time / iteration (s). プロセス. /ノード. 4. Isend/Irecv (bunch, 256 KiB) 2.0E-02 1.5E-02 1.0E-02. normal aware-1 aware-2. 5.0E-03. 0.0E+00 0. 1.5E-02 1.0E-02. normal aware-1 aware-2. 5.0E-03. 0.0E+00 0. 3.0E-02 2.0E-02. normal aware-1 aware-2. 1.0E-02. 0.0E+00. 0. し，scatter 配置では，同じストライピングのラウンドのプロセスが別々のノードにあるため，bunch 配置に比べて通信の混雑が緩和されたためではないかと考えている．. 4.2 データ送受信に関する基礎評価. 30. 40. Isend/Irecv (scatter, 512 KiB) 4.0E-02. Time / iteration (s). きいため，読み出しと書き込みの両方を行う TP-IO にお. ドにあり，対象 OST 群との通信経路が共有されるのに対. 20. (c) bunch 配置: 512 KiB/process. scatter 配置における読み出し時間の短縮の方がずっと大. では同じストライピングのラウンドのプロセスが同一ノー. 10. MPI rank. ら，書き込み時間は bunch 配置の方がやや時間が短いが，. 大幅に短縮する原因は調査中であるが，bunch 配置の場合. 40. Isend/Irecv (bunch, 512 KiB). ス配置を変えて計測したものである．これらのデータか. 利になると思われる．なお，scatter 配置で読出し時間が. 30. 4.0E-02. 定して，ノードあたりのプロセス数を増やしながらプロセ. いては，アグリゲータの配置を scatter 配置にする方が有. 20. (b) scatter 配置: 256 KiB/process. Time / iteration (s). 3 つ目以降の欄のデータは使用するノード数を 4 個で固. 10. MPI rank. ずつ起動したときの処理時間である．前者は 4 つのプロセ. 示している．. 40. Isend/Irecv (scatter, 256 KiB). のケースは 4 つのノードを用い，1 ノード毎に 1 プロセス. Lustre にアクセスできるので，後者の方がより高い性能を. 30. 2.0E-02. 表の上の最初の欄のデータは全体で一つのノードに 4 つ. し，後者では各々のプロセスが個別の通信経路を使用して. 20. (a) bunch 配置: 256 KiB/process. の MPI プロセスを起動した際の処理時間で，その下の欄. ス間で通信経路を共有して Lustre にアクセスするのに対. 10. MPI rank. Time / iteration (s). 入出力時間ノード数プロセス数. 3.0E-02 2.0E-02. normal aware-1 aware-2. 1.0E-02. 0.0E+00 0. 10. 20. 30. 40. MPI rank (d) scatter 配置: 512 KiB/process 図 5 MPI Isend/MPI Irecv 対による全体全通信時間. 信するデータ長はアクセスパターンと CB の大きさによっ. 4 ノードを用い，1 ノードあたり 8 プロセスずつで全体で. て変わってくるが，ここでは後述する HPIO ベンチマーク. 32 プロセス起動して，MPI Isend/MPI Irecv 対によるプロ. による評価環境に近い設定として，このベンチマークで用. セス間全体全通信に要する時間を，MPI プロセスの配置方. いたアクセスパターンに近いサイズで 256 KiB と 512 KiB. 法を変えて計測した．ここでは，現行の ROMIO の通信方. の 2 パターンで計測した．その結果を図 5 に示す．この計. 式（normal）に加え，3.2 章で述べた今回実装した 2 つの改. 測では，プロセス個々に MPI Waitall による送受信完了ま. 変実装の効果を検証する意味で，これら 3 つの通信パター. でに要した時間を計測しており，送受信を 100 回繰り返し. ンを模擬したプログラムにより MVAPICH2 ver.2.1rc1 を. た際の平均時間をランクごとに示している．プロセス配置. 用いて通信時間を計測した．. は bunch と scatter の両方を確認した．2 つのプロセス. ROMIO による TP-IO において，各々のプロセスが送受 ⓒ 2015 Information Processing Society of Japan. 配置を比べると，scatter 配置が bunch 配置よりも時間が. 5.

(6) Vol.2015-HPC-149 No.3 2015/6/26. 情報処理学会研究報告 IPSJ SIG Technical Report. 短くなる傾向が見られる．この結果を踏まえると，我々の提案手法ではアグリゲータとなるプロセスが丁度 scatter. np=32@4x8, # aggregators=4 bunch. 14 12. 配置と同じレイアウトで配置されるので，bunch 配置と同 Time (s). 10. じレイアウトでアグリゲータを配置させる現行の ROMIO に比べてアグリゲータへのデータ収集時間の短縮が計れる. 8. 6 4. ものと考えられる。. 2. さらに非同期通信関数の発行順に関して見てみると，今回. 0. 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30. 評価した 2 つのプロセス配置のいずれでも，aware-2 のパ Write. ターンが最も通信時間が短くなることが分かった．TP-IO. MPI rank Exch. Read. (a) アグリゲータ：4 個（bunch 配置）. ではこのようなパターンの通信をファイル領域を網羅する. np=32@4x8, # aggregators=32 bunch. まで TP-IO サイクル数分だけ繰り返すため，TP-IO サイ 14 12. れる．. 10. Time (s). クル数が多いほど時間削減効果は大きくなることが期待さ. TP-IO における通信時間の割合は，アクセスパターンにもよるが，一般に割と大きい割合を占めるので，以上の結. 8 6 4 2. 果から，ROMIO において，我々が提案するアグリゲータ. 0. の配置と非同期通信関数の発行順変更機能が性能向上に繋. 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30. がることが期待できる．. Write. MPI rank Exch. Read. (b) アグリゲータ：32 個（bunch 配置）. 4.3 HPIO ベンチマークによる ROMIO の評価空白部分を含んだ派生データ型によるアクセスパターン. 14. による集団型書き込みの性能を評価するために，HPIO ベン. 12. np=32@4x8, # aggregators=4 scatter. 10. Time (s). チマークを用いて MPI File write all の性能を評価した．この評価では ROMIO の現行の実装と今回実装した拡張機. 8 6 4. 能を有する ROMIO の 2 種類に対して行い，MVAPICH2. 2. による MPI プロセスのノード間の配置方法を変えて計測. 0 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30. を行った．各ノードには 8 プロセスを起動し，4 ノードで. Write. 合計 32 プロセスにより，4 つの OST を有する Lustre に対. MPI rank Exch. Read. (c) アグリゲータ：4 個（scatter 配置）. する性能を評価した．. np=32@4x8, # aggregators=32 scatter. まず始めに現行の ROMIO に関して TP-IO 内部の主 14. な 3 つの処理であるファイル読出し（read），データ交換. 12. （exch），並びにファイル書き込み（write）に要する時間 Time (s). 10. を計測した．その結果を図 6 に示す．bunch 及び scatter の 2 種類の配置方法で計測しており，図 6(a) 及び (c) は，. 8 6 4. ノードあたりに 1 個のアグリゲータを起動し，4 ノード全. 2. 体で 4 個配置したケースで，図 6(b) 及び (d) は，ノード. 0 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30. あたりに 8 個のアグリゲータを起動し，4 ノード全体で 32. MPI rank Write. 個配置したケースを示している．図 6(a) では，ランクが. Exch. Read. (d) アグリゲータ：32 個（scatter 配置）. 0，8，16，及び 24 の 4 つがアグリゲータとなっているため，これらのみファイルアクセスをしているのが分かる．一方，他のプロセスはこれらのアグリゲータへデータを集. 図 6. 現行の ROMIO による集団型書き込みにおける TP-IO 内部の処理時間. めるための通信のみ行っており，通信完了の待ち時間を含. ず，入出力処理の分散化がうまくできておらず，全体とし. め約 9 秒程度を要していた．. て書き込みおよび読出し時間の短縮に繋がっていない．そ. 次に全てのプロセスがアグリゲータとなった図 6(b) で. の結果，3 つの処理時間の和が増加していることからも分. は，全プロセスがファイルアクセスと通信の両方を行って. かるように，アグリゲータが 4 個の場合に比べて後述する. おり，前の方のランクのプロセスで書き込みあるいは読出. HPIO ベンチマークでの入出力性能も低下していることを. しに時間を要している様子が分かる．アグリゲータ数を増. 確認している．scatter 配置の場合でも，図 6(c) 及び (d). やしアグリゲータあたりの I/O 長を短くしたにも関わら. に示すように同様の振舞いが確認できる．アグリゲータ数. ⓒ 2015 Information Processing Society of Japan. 6.

(7) Vol.2015-HPC-149 No.3 2015/6/26. 情報処理学会研究報告 IPSJ SIG Technical Report. np=32@4x8, # aggregators=32 bunch, agg(aware-2). 6. 2000. 5. 1500. 4. Time (s). I/O Throughput (MiB/s). np=32@4x8 (Isend/Irecv), bunch 2500. 1000. 3. 2. 500 1. 0. 0. 1. 2 4 8 # Aggregators / Node orig agg(normal) agg(aware-1) agg(aware-2). 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 Write. MPI rank Exch. Read. (a) bunch 配置，agg(aware-2). (a) bunch 配置 np=32@4x8, # aggregators=32 scatter, agg(aware-2). 6. 2500. 5. 2000 Time (s). I/O Throughput (MiB/s). np=32@4x8 (Isend/Irecv), scatter. 1500 1000 500. 4 3 2 1 0. 0. 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30. 1. 2 4 8 # Aggregators / Node orig agg(normal) agg(aware-1) agg(aware-2). (b) scatter 配置図 7 HPIO ベンチマークによる集団型書き込み性能. MPI rank Write. Exch. Read. (b) scatter 配置，agg(aware-2) 図 8. アグリゲータ配置の最適化と非同期通信発行の順番を配慮したケースでの TP-IO 内部の処理時間（32 プロセス全てがアグリゲータの場合）. を増やした際に現行の ROMIO ではノード毎に配置予定数に達するまで順番に割り当ててゆくために，ノードあたり. べて性能が向上する様子も見られたが，ノードあたりに起. に複数のアグリゲータが配置される場合，アグリゲータ配. 動するプロセス数やノード数を増やしてさらに検証を進め. 置は bunch 配置となるため，4.2 章で述べたように，通信. る必要があると思われる．この件については，今後，より. において性能低下を招いている可能性がある．. ノード数を多くした環境で引き続き確認を進める．. 次に，今回提案する手法を実装した ROMIO および現行. 今回行った最適化により，図 8 に示すように，現行. の ROMIO に対する HPIO ベンチマークによるスループッ. ROMIO での図 6(b)(d) に示した TP-IO 内部の処理時間と. ト値を図 7 に示す．この図の横軸はノードあたりのアグ. 比較して，特に通信完了待ち時間を含むデータ交換時間の. リゲータの数を表しており，1 ノードあたり 8 プロセス起. 大幅な短縮が確認できた．また，Lustre からの読出し時間. 動しているために横軸の最大値は全てのプロセスがアグリ. も，現行の ROMIO の場合と比較して半分程度時間が短縮. ゲータとなる場合に相当する 8 となっている．この評価で. されていることが確認できた．これらは 4.1 章や 4.2 章で. はノードあたりのアグリゲータの数を 1，2，4，6 及び 8 の. の評価でも確認した通り，アグリゲータの配置をノード間. 5 通りについて 2 つのプロセス配置それぞれで計測した．. でラウンドロビンに配置させたことが大きな要因と考えら. なお，図中の orig は現行 ROMIO を，残りの 3 つはアグ. れる．. リゲータ配置の最適化を施した ROMIO を表しており，括弧内は今回評価した 3 つの非同期関数の発行順を表している．また，参考として，この時の agg(aware-2) のケースでの TP-IO 内部の処理時間を図 8 に示す．図 7 に示すスループットに関しては，2 つの MPI プロ. 5. 関連研究 TP-IO における高速化に向けた様々な取り組みがある中で，特にファイルビューの取扱いに関する最適化による高速化を実現したものとして View-based I/O [9] がある．. セスの配置方法のいずれにおいても，アグリゲータの配置. TP-IO では，処理サイクルの繰り返しにおいて，サイクル. を最適化したケース（agg(normal)，agg(aware-1) 及び. ごとにプロセス間でデータを入れ替える際に必要な各プロ. agg(aware-2)）では大幅なスループットの向上が確認でき. セスでのオフセット・データ長の情報をプロセス相互に通. た．しかしながら，TP-IO 内の非同期通信の発行順が性能に. 信している．それに対し View-based I/O はファイル I/O. 与える影響については，agg(aware-1) 及び agg(aware-2). 開始時に全サイクル分のオフセット・データ長の情報を集. のケースにおいて，アグリゲータ数を増やした場合に，単. めておくことで，TP-IO サイクルごとに行うプロセス間の. 純にランク順に発行しているケース（agg(normal)）に比. 通信を無くし，全体の性能を向上させている．. ⓒ 2015 Information Processing Society of Japan. 7.

(8) Vol.2015-HPC-149 No.3 2015/6/26. 情報処理学会研究報告 IPSJ SIG Technical Report. アグリゲータの動的な選定手法による TP-IO の高速化が. 配置の問題を解決するために，Lustre のストライピングア. OpenMPI で利用できる MPI-IO ライブラリの一つである. クセスパターンに配慮した最適なアグリゲータ配置方法を. OMPIO において実現されている [10]．この実装ではファ. 提案し，MVAPICH2 ver.2.1rc1 の ROMIO に実装し，そ. イルビューやプロセス数，プロセスのノードへの配置トポ. の有用性を確認した．現行の ROMIO のアグリゲータ配置. ロジ，データサイズなどに加え，並列ファイルシステムの. では Lustre へのストライピングアクセスにおいて性能低. ストライピングなどを考慮した上でアグリゲータの数を動. 下を招くだけでなく，TP-IO 内のデータ通信でも性能低下. 的に決定している．しかしながらこの実装では，計算ノー. を招く可能性があった．これに対し我々の提案手法では，. ドと通信回線の設定を反映させていない点で我々の実装と. アグリゲータをラウンドロビンの並びでノード間に配置し. は異なる．. ており，Lustre への POSIX-I/O による入出力処理評価に. アグリゲータとなるプロセス間で担当するアクセス領域. おいて，読出し処理において提案手法の配置方法がより処. を並列ファイルシステムでのストライピングアクセスパ. 理時間を短縮できることが分かった．また，アグリゲータ. ターンに配慮したレイアウトにすることで高速化を狙った. となるプロセスへのデータ通信に関連して行った非同期通. ものとして LACIO がある [11]．これはユーザから見える. 信関数に関する基礎評価データからも，提案手法の方が通. ファイルレイアウトではなく，並列ファイルシステムの物. 信時間を短縮できる可能性があることが分かった．以上の. 理的な分散データレイアウトに合わせたデータレイアウト. 結果を踏まえて行った HPIO ベンチマークによる不連続ア. を各アグリゲータで取り入れることでファイルシステム. クセスパターンでの集団型書き込みの評価でも，我々の提. 側へのアクセスにおける通信経路の混雑を避けている．同. 案手法が現行の ROMIO に対して最大で 3 倍程度の大幅. 様の最適化は Lustre 向けの ADIO 実装 [7] でも行われて. な性能向上が実現できることが確認できた．さらに我々は. いる．一方，我々の研究は，ノードあたりに複数のアグリ. データ通信での非同期 MPI 通信関数に関して，ノード毎. ゲータが起動された場合での最適なアグリゲータ配置方法. のプロセス配置に配慮した発行順に変更させる改変実装も. を提案するものであり，これらのデータレイアウトの最適. 行った．今回行った評価試験では，僅かながら性能が向上. 化実装の上に立ち，さらにアグリゲータの配置を並列ファ. する様子が確認できたが，今回使用した PC クラスタ環境. イルシステムのデータレイアウトに最適な配置を実現する. ではノード数やノードあたりのコア数が少なく検証が不十. ことでさらなる性能向上を狙っている．. 分のため，今後，より多くのノード数およびノードあたり. アグリゲータの最適化配置については，Blue Gene/P. のコア数を持つ環境での評価を検討する予定である．. （BG/P）における実装において有効性が報告されてい. 謝辞本研究の一部は科学研究費（基盤研究（C））課題. る [12]．この実装では，MPI-IO による集団型 I/O を利用. 番号 25330148 の支援を受けております．また本研究を進. するプログラムにおいて，BG/P の計算ノード間のネット. めるにあたり，理化学研究所計算科学研究機構研究部. ワークトポロジと MPI プロセスの配置を考慮して，アグ. 門システムソフトウェア研究チームの皆様から数々のご. リゲータとなるプロセスがサブグループ化された各々の. 支援やご助言等を頂きました．この場をお借りして感謝を. 領域に配置されるように工夫しており，既存の MPI-IO 実. 申し上げます．. 装に比べて性能が向上することが報告されている．また，本研究とは別に我々の研究チームでは，京コンピュータで. 参考文献. の FEFS 向け高速化 MPI-IO 実装を行っている [13], [14]．. [1]. この研究では京の Tofu インターコネクトのトポロジーと. FEFS のストライピングレイアウトに配慮した最適なアグリゲータの配置方法や FEFS へのファイルアクセスの最適. [2] [3]. 化などにより，FEFS 向けに導入されている MPI-IO ライブラリに対しての性能向上を実現している．一方，本稿で. [4]. 報告した我々の提案手法は，一般的な PC クラスタでの利用を念頭に置いた設計になっており，マルチソケットやマ. [5]. ルチコア環境での InfiniBand や Ethernet 等の汎用的なインターコネクトを用いた場合での高速化手法を提案する点で異なる．. 6. 本稿のまとめ我々は，ROMIO による Lustre に対する MPI-IO による集団型書き込みにおいて，現行の ROMIO のアグリゲータ. ⓒ 2015 Information Processing Society of Japan. [6]. [7] [8]. Lustre: http://wiki.lustre.org/index.php/Main_ Page. The National Center for Supercomputing Applications: http://hdf.ncsa.uiuc.edu/HDF5/. Rew, R., Davis, G., Emmerson, S., Davies, H. and Hartnett, E.: NetCDF User’s Guide, Unidata Program Center (2006). Parallel netCDF: http://cucis.ece.northwestern. edu/projects/PnetCDF/. Thakur, R., Gropp, W. and Lusk, E.: On Implementing MPI-IO Portably and with High Performance, Proceedings of the Sixth Workshop on Input/Output in Parallel and Distributed Systems, pp. 23–32 (1999). Thakur, R., Gropp, W. and Lusk, E.: Optimizing noncontiguous accesses in MPI-IO, Parallel Computing, Vol. 28, No. 1, pp. 83–105 (2002). Lustre: Lustre ADIO collective write driver, Technical report, Lustre (2008). Ching, A., Choudhary, A., keng Liao, W., Ward, L. and Pundit, N.: Evaluating I/O Characteristics and Methods. 8.

(9) 情報処理学会研究報告 IPSJ SIG Technical Report. [9]. [10]. [11]. [12]. [13]. [14]. Vol.2015-HPC-149 No.3 2015/6/26. for Storing Structured Scientific Data, Proceedings 20th IEEE International Parallel and Distributed Processing Symposium, IEEE Computer Society, p. 49 (2006). Blas, J. G., Isaila, F., Singh, D. E. and Carretero, J.: View-Based Collective I/O for MPI-IO, CCGRID, pp. 409–416 (2008). Chaarawi, M. and Gabriel, E.: Automatically Selecting the Number of Aggregators for Collective I/O Operations, 2011 IEEE International Conference on Cluster Computing (CLUSTER 2011), IEEE, pp. 428–437 (2011). Chen, Y., Sun, X.-H., Thakur, R., Roth, P. C. and Gropp, W. D.: LACIO: A New Collective I/O Strategy for Parallel I/O Systems, Proceedings of the 25th IEEE International Parallel and Distributed Processing Symposium (IPDPS ’11), IEEE Computer Society, pp. 794–804 (online), DOI: http://doi.ieeecomputersociety.org/10.1109/IPDPS.2011.79 (2011). Vishwanath, V., Hereld, M., Morozov, V. and Papka, M. E.: Topology-aware Data Movement and Staging for I/O Acceleration on Blue Gene/P Supercomputing Systems, Proceedings of 2011 International Conference for High Performance Computing, Networking, Storage and Analysis, SC ’11, ACM, pp. 19:1–19:11 (2011). Tsujita, Y., Hori, A. and Ishikawa, Y.: Locality-Aware Process Mapping for High Performance Collective MPIIO on FEFS with Tofu Interconnect, Proceedings of EuroMPI/ASIA’14, ACM, pp. 157–162 (2014). 辻田祐一，堀敦史，石川裕，” 集団型 MPI-IO の高速化に向けた I/O リクエスト発行方式の最適化,” 情報処理学会研究報告 2014-HPC-146, 17 (2014).. ⓒ 2015 Information Processing Society of Japan. 9.

(10)