> [!abstract] 概要(ACM Reference formatの要旨を日本語訳) > 高性能計算(HPC)では、データとメタデータが特殊なサーバノードに保存され、クライアントアプリケーションはネットワーク経由でサーバのデータ・メタデータにアクセスする。これによりネットワーク遅延とリソース競合が生じる。これらのサーバノードは典型的には(低速な)磁気ディスクを備えるのに対し、クライアントノードは高速なSSDや不揮発性メインメモリ(NVMM)に一時データを保存する。したがって、並列ファイルシステムの全潜在能力は、高速なクライアント側ストレージデバイスを全体のストレージアーキテクチャに組み込んだときにのみ達成できる。 > 本論文では、Lustreファイルシステム向けのNVMMベースの階層型永続クライアントキャッシュ(NVMM-LPCCと略す)を提案する。NVMM-LPCCは2つのキャッシュモードを実装する。読み書きモード(RW-NVMM-LPCC)と読み取り専用モード(RO-NVMM-LPCC)である。NVMM-LPCCはLustreの階層型ストレージ管理(HSM)ソリューションとLustreのレイアウトロック機構を統合し、クライアントノード上で動作するI/Oアプリケーションに一貫性のある永続キャッシュサービスを提供しつつ、Lustreファイルシステム全体のグローバル統一名前空間を維持する。本論文で示す評価結果は、NVMM-LPCCがネイティブLustreシステム比で平均読み取りスループットを最大35.80倍、平均書き込みスループットを最大9.83倍向上させ、優れたスケーラビリティを提供することを示す。 ## 論文情報 - **タイトル**: NVMM-Oriented Hierarchical Persistent Client Caching for Lustre - **著者**: [[Wen Cheng]]・[[Chunyan Li]]・[[Lingfang Zeng]]([[Huazhong University of Science and Technology]])、[[Yingjin Qian]]・[[Xi Li]]([[DDN]])、[[André Brinkmann]]([[Johannes Gutenberg University Mainz]]) - **媒体**: ACM Transactions on Storage (ToS), Vol. 17, No. 1, Article 6 - **発表年**: 2021年1月(受理: 2019年11月投稿、2020年3月改訂、2020年6月受理) - **DOI**: [10.1145/3404190](https://doi.org/10.1145/3404190) ## 概要 本論文は、HPC向け並列ファイルシステム[[Lustre]]のクライアントノードに搭載された不揮発性メインメモリ(NVMM)を、階層型永続キャッシュとして活用する仕組みNVMM-LPCCを提案する。著者らの前作LPCC(SC 2019)がSSDベースのクライアントキャッシュだった([24])のに対し、本論文はNVMMを対象にRW/RO 2モードを実装し、LustreのHSMとレイアウトロックでデータ一貫性とグローバル名前空間を両立させた上で、SSD比・ネイティブLustre比の双方で大幅な性能向上を実証した。 ## 問題設定 - **入力**: クライアントノード上で動作するI/Oアプリケーションからの読み取り・書き込みリクエスト。Lustreクラスタ(MDS 1台、OSS複数台、クライアント複数台)。 - **出力**: クライアント側NVMMキャッシュを経由した低レイテンシ・高スループットなI/O応答。サーバ障害時もキャッシュ済みファイルはアプリケーションへのサービスを継続できる。 - **前提条件**: HPCクライアントノードにNVMMが搭載されていること(著者らのテスト環境ではNVMM実機が入手できず、DRAMの一部をNVMMとしてエミュレートし、[[HiNFS]]と同様にRDTSC命令によるスピンループでNVMM書き込みレイテンシ(既定200ns)を模擬した)。Lustre自体は書き込み耐久性・データ一貫性を保証しないため、NVMM-LPCCがこれを補う必要がある。 ## 提案手法 ### アーキテクチャ NVMM-LPCCの設計思想は次の4点である。(1) グローバル名前空間の下で、LustreのHSM機構がサーバ側ストレージ層を「低速」層、クライアント側永続キャッシュ層を「高速」層として扱い、Lustre自身と同等の一貫性保証を維持する。(2) データアクセスが単一クライアントに集中する場合は読み書きキャッシュモードを、複数クライアントが同一の読み取り専用データにアクセスする場合は読み取りキャッシュモードを使い分け、アプリケーション特性(遅延感受性かI/O集約的か)に応じた最適化を行う。(3) NVMM向けのローカルファイルシステム([[NOVA]]等)を用いてキャッシュI/Oリクエストを処理し、NVMMの性能を最大限に引き出す。(4) Lustreのクォータ機能とルールベースの自動キャッシュ戦略を組み合わせ、クライアント側で満たすべきキャッシュルールを指定できるようにし、アプリケーションごとの差別化されたQoS保証を提供する。 **Figure 1: NVMM-LPCCシステムアーキテクチャ** ![[_attachments/2026_Unknown_NVMM_Oriented_Hierarchical_Persistent_Client/fig01-architecture.png]] (Figure 1. Coordinator(MDS)がファイル階層(fid1・fid2・dir1配下のfid3・fid4・file5等)のメタデータI/O・restoreリクエスト・attachリクエストをクライアントのCopy toolから受け、OSS(OSTs)へのデータオブジェクト生成・通常I/Oパス・データattach・データrestoreを仲介する構成を示す。Client AgentはNVMM-LPCC(HSM)としてfid1〜fidnのキャッシュファイル群を保持する。) ### RW-NVMM-LPCC(読み書きモード) 単一クライアントによるデータ局所性を最大限活用し、読み書き双方のアクセスを高速化するモード。Lustreのレイアウトロックと組み合わせてキャッシュの一貫性を保証する。 **RW-NVMM-LPCCのAttachフロー**: クライアントのローカルNVMM-LPCCキャッシュにキャッシュすべきファイルは、まずLustreのObject Storage Targets(OSTs)からコピーされる(attach操作)。`pcc_readwrite_attach`関数が下表のサブ関数を順に呼び出して完了する。OSTsのストレージ容量を節約するため、クライアントへのキャッシュ後はOSTs上のファイルデータが消去される。 *(Table 1. pcc_readwrite_attach)* | 関数 | 定義 | |---|---| | `pcc_inode_create` | ファイルのFile Identifier(FID)でローカルファイルを作成 | | `dentry_open` | ローカルファイルを開き、file構造体変数を取得 | | `pcc_copy_file` | ファイルデータをOSTsからローカルキャッシュファイルへコピー | | `hsm_coordinator` | EXレイアウトロックを取得、Lustreからファイルを解放し、HSMをreleased/archivedに設定 | | `pcc_inode_attach_init` | ファイルのキャッシュタイプを設定し、ローカルファイルのinodeプロパティを変更 | **RW-NVMM-LPCCのRestoreフロー**: RW-NVMM-LPCCモードでは、OSTsのストレージ容量を節約するためファイルデータのコピーは1部のみ保持される。あるクライアントが、既に別クライアントでRW-NVMM-LPCCモードにキャッシュ済みのファイルにアクセスしようとすると、キャッシュファイルの自動復元プロセス(restore操作)が起動する。クライアントのI/Oリクエストはrestore完了までブロックされ、この処理はLustre HSMがトリガーしアプリケーションに対して完全に透過的である。`ct_restore`関数が下表のサブ関数を順に呼び出して完了する。 *(Table 2. ct_restore)* | 関数 | 定義 | |---|---| | `ct_path_archive` | ファイルのFIDに基づきキャッシュ内のストレージディレクトリを構築 | | `llapi_get_mdt_index_by_fid` | MDS上でのファイルのインデックス位置を計算 | | `ct_begin_restore` | MDSからファイルのメタデータを取得し、一時ファイルを作成 | | `llapi_hsm_action_get_dfid` | 一時ファイルのFIDを取得 | | `llapi_hsm_action_get_fd` | 一時ファイルのファイルディスクリプタを取得 | | `ct_copy_data` | OSTs内で復元が必要なファイルデータをローカルから一時ファイルへコピー | | `ct_fini` | 一時ファイルと元ファイルのレイアウト情報を交換し、一時ファイルを削除 | ### RO-NVMM-LPCC(読み取り専用モード) RW-NVMM-LPCCは単一クライアントによる占有アクセスを高速化するが、複数クライアントが入力データ等として同一ファイル集合をほぼ変更せずに参照するケースには向かない。この用途向けにRead-Only NVMM-LPCC(RO-NVMM-LPCC)を実装する。 **RO-NVMM-LPCCのAttachフロー**: RW-NVMM-LPCCより単純で、バックエンドOSTs上のデータは消去されない(明示的なrelease操作も不要)。アクセス違反発生時もrestore操作は不要である。ファイルレイアウト情報の`cl_layout`構造体に`rdonly`フィールドを追加し、読み取り専用状態でキャッシュ可能かを示す。`pcc_readonly_attch`関数が下表のサブ関数を呼び出して完了する。 *(Table 3. pcc_readonly_attach)* | 関数 | 定義 | |---|---| | `pcc_readonly_attach_allowed` | クライアントにattach操作を許可するかを判定 | | `pcc_layout_rdonly_set` | ファイルレイアウト情報のrdonlyフィールドを設定 | | `pcc_inode_create` | ファイルのFIDをファイル名としてローカルファイルシステムにイメージファイルを作成 | | `pcc_copy_data` | 通常のI/Oパス経由でOSTsからキャッシュファイルへデータをコピー | | `pcc_inode_attach_init` | ローカルキャッシュファイルのinode情報を設定 | | `pcc_layout_xattr_set` | キャッシュファイルのレイアウトプロパティを設定 | | `pcc_layout_gen_set` | クライアントにファイルレイアウトのバージョン情報を保存 | **RO-NVMM-LPCCのファイル変更**: RO-NVMM-LPCCモードでキャッシュされたファイルの読み取りパスは単純(ローカルキャッシュから直接読み取る)だが、複数クライアントに同一ファイルがキャッシュされ得るため、変更操作は複雑になる。あるクライアントアプリケーションがファイルを変更しようとすると、キャッシュデータの一貫性を保つためキャッシュ状態が無効化される。`pcc_layout_invalild`関数がクライアントキャッシュのレイアウト情報を無効化しキャッシュタイプをクリアすることで、読み取り専用ファイルデータの一貫性を維持する。 ### NVMM向けキャッシュI/Oパス Lustreクライアントは、NVMMを[[NOVA]]や[[PMFS]]等のNVMM-FS(NVMMベースの永続メモリファイルシステム)と組み合わせてローカルファイルシステムとして扱い、クライアント側キャッシュを管理する。これらのファイルシステムの読み書き操作はカーネルのページキャッシュ層とcommon blockレイヤーをバイパスしファイルへの直接アクセスを提供するため、ソフトウェアオーバーヘッドを削減しNVMMの性能優位性を確保する。 クライアントが読み書きリクエストを発行するたびに、まず要求されたファイルがローカルキャッシュにあるかを判定する。キャッシュヒットならローカルキャッシュファイルで直接I/Oリクエストを満たし、キャッシュミスならOSTsへのRPCリクエストで通常のI/Oパス経由でファイルデータを要求する。メタデータ情報は常にMDSに保持され、Lustreシステム全体は統一名前空間を維持することでストレージ空間の柔軟な管理を保証する。キャッシュはファイル粒度で実行され、一度開かれたキャッシュファイルは、サーバ側ストレージ障害(ネットワーク切断やサーバ障害等)時にもアプリケーションへのサービスを継続できる。 **Figure 2: NVMM-LPCCクライアントソフトウェアスタック** ![[_attachments/2026_Unknown_NVMM_Oriented_Hierarchical_Persistent_Client/fig02-client-software-stack.png]] (Figure 2. User Application→VFS→Llite層の下で、通常I/O(Normal I/O)はLOV→OSC-1..N→PTR-RPC→LNETという既存Lustreパスを通り、キャッシュI/O(Cache I/O)はNVMM-FS→NVMMという新設パスを通ることを示す。両パスはLlite層で分岐する。) **キャッシュ構造の設計**: NVMM-LPCCはLustreのLlite層に`pcc_inode`構造体を追加し、キャッシュファイルの情報(キャッシュパス、キャッシュタイプ等)を保持する。この構造体は`ll_inode_info`に埋め込まれる。 *(Table 4. pcc_inode)* | フィールド | 型 | 定義 | |---|---|---| | `path` | `struct path` | ローカルパスでのキャッシュファイル | | `pccci_lock` | `struct mutex` | ローカルキャッシュパス変数の保護 | | `pcci_refcount` | `atomic_t` | アクセスカウント | | `pcci_type` | `enum lu_pcc_type` | キャッシュタイプ | | `pcci_layout_gen` | `__u32` | キャッシュファイルのバージョン情報 | | `pcci_active_ios` | `atomic_t` | キャッシュ内のアクティブI/O数 | | `pcci_state` | `enum lu_pcc_state_flags` | キャッシュファイルinodeの状態 | キャッシュモードは列挙型`lu_pcc_type`で保持される。`LU_PCC_NONE`はファイルが未キャッシュ、`LU_PCC_READWRITE`はRW-NVMM-LPCCモード、`LU_PCC_READONLY`はRO-NVMM-LPCCモードでキャッシュされていることを示す。 *(Table 5. lu_pcc_type)* / *(Table 6. lu_pcc_state_flags)* | lu_pcc_type | 定義 | | lu_pcc_state_flags | 定義 | |---|---|---|---|---| | `LU_PCC_NONE` | 未キャッシュ | | `PCC_STATE_FL_NONE` | 未キャッシュ | | `LU_PCC_READWRITE` | RW-NVMM-LPCCでキャッシュ済み | | `PCC_STATE_FL_ATTR_VALID` | inode属性がローカルにキャッシュ済み | | `LU_PCC_READONLY` | RO-NVMM-LPCCでキャッシュ済み | | `PCC_STATE_FL_CACHE_VALID` | 有効なキャッシュ | | | | | `PCC_STATE_FL_CACHE_INVALID` | 無効なキャッシュ | | | | | `PCC_STATE_FL_LAYOUT_INVALID` | 無効なキャッシュレイアウト情報 | キャッシュファイルのVFS層file objectとキャッシュタイプは`pcc_file`構造体に埋め込まれる。ファイルがキャッシュに存在すればその情報は`fd_pcc_file`フィールドに、存在しなければ元の`ll_file_data`フィールドに保持される。 *(Table 7. pcc_file)* | フィールド | 型 | 定義 | |---|---|---| | `pccf_file` | `struct file` | キャッシュファイルオブジェクト | | `pccf_type` | `enum lu_pcc_type` | キャッシュタイプ | **読み書き操作**: アプリケーションは`read()`・`write()`等のシステムコールでカーネルにトラップし、Lustreファイルシステムが定義する読み書き関数が処理を完了させる。ファイルがLustreクライアントキャッシュ内にあればローカルファイルシステムの読み書き操作(例: NOVAの`nova_dax_file_read`/`nova_dax_file_write`)が呼ばれ、そうでなければ通常のI/Oパスで処理される。読み取りフロー(Algorithm 1)は`pcc_file`フィールドの非NULL判定とレイアウトロックの有無で`aio_read`か`ll_file_io_generic`を選択する。書き込みフロー(Algorithm 2)は`pcci_type`がRW-NVMM-LPCCかどうかとレイアウトロックの有無で`aio_write`か`ll_file_io_generic`を選択する(Lustreの読み取り操作と異なり、書き込み操作のみ`pcc_inode`の`pcci_type`判定を要する)。 ### ルールベースキャッシュ戦略 NVMM-LPCCはLustreのクォータ機能を用いてルールベースの自動キャッシュ戦略を採用する。各クライアントはルールセットのリストを保持し、`pcc_dataset`構造体がキャッシュルールを定義してリンクリストに格納する。 *(Table 8. pcc_dataset)* | フィールド | 型 | 定義 | |---|---|---| | `porjid` | `__u32` | プロジェクトID | | `path` | `struct path` | ローカルキャッシュのパス | | `pcc_link` | `struct list_head` | 次のルールの`list_head`フィールドを指す | ルールセット内のプロジェクトIDがファイルに一致すると、一定条件下でファイルはクライアントにローカル自動キャッシュされる。`pcc_dataset_get`がリンクリストを走査してルールを取得し、`pcc_dataset_add`/`pcc_dataset_del`がルールの追加・削除を行う。RW-NVMM-LPCCモードでは新規作成ファイルを自動キャッシュしattach操作のオーバーヘッドを省略できる。RO-NVMM-LPCCモードも同様のルールベース機構を実装するが、データは依然OSTsに保存されるため、初回読み取り時のみOSTsからクライアントへのコピーが必要になる。 ## 新規性 - **著者ら自身の前作LPCC(SC 2019, [24])との差分**: LPCCはSSDを対象としたLustreクライアントキャッシュだったが、本論文はNVMMを対象に再設計し、NVMM向けローカルファイルシステム(EXT4-DAX・PMFS・NOVA)を統合できるキャッシュファイル情報構造をLlite層に新設した。attach/restoreの詳細プロトコルはLPCCを踏襲しつつ、NVMM特有の書き込み耐久性・データ一貫性問題(HiNFS [6]、NOVA [41]が指摘)への対応を組み込んでいる。 - **Panache([10])との対比**: GPFSとpNFSを統合したマルチノード読み書きキャッシュだが、ローカル・リモートデータ間の一貫性を保証できず統一名前空間も提供しない。NVMM-LPCCはHSM+レイアウトロックで一貫性と統一名前空間の両方を維持する。 - **FS-Cache([13])との対比**: 独立したファイルシステムではなく読み取りキャッシュのみをサポートするLinuxキャッシュフレームワーク。NVMM-LPCCはRW/ROの両モードを提供する。 - **BWCC([29])との対比**: マルチクライアント共有ディスクキャッシュだが読み取り専用モードのみ。NVMM-LPCCはRWモードも提供する。 - **バーストバッファ([5, 20, 31, 36])との対比**: 専用SSDアレイやノード内SSDを束ねる方式だが、並列ファイルシステムとの統一名前空間を提供せずアプリケーションに対して不透明で、管理が難しい。NVMM-LPCCは統一名前空間を維持する。 ## 実験設定 - **ハードウェア/ソフトウェア環境**: *(Table 9. The Hardware and Software Test Environment of the NVMM-LPCC)* | 項目 | 値 | |---|---| | CPU | Intel Xeon Processor E5-2620, 2.00GHz | | Memory | DDR3 128GB | | SSD | Kingston SA400S37/240G | | HDD | SAS Disks | | Operating system | Centos-7.5 | | Kernel version | 3.10.0-862.6.3 | | Network | 1GB Ethernet | | Lustre version | Lustre 2.11.53 | | Fio | fio-3.1 | | Filebench | 1.5-alpha3 | | IOR | IOR-3.2.0 | - **クラスタ構成**: クライアント8台、OSS3台、MDS1台。各クライアントはNVMMベースファイルシステムを永続キャッシュ媒体としてマウント(NVMMはDRAMでエミュレート)、比較のため標準SSDも併せてマウント。各OSSはメモリ28GB・OST2台(各300GB HDD)。MDSはメモリ28GB・256GB SSDでメタデータを保存。128GBのDRAMを通常DRAM 28GBとNVMM 100GBに分割し、NVMM書き込みには既定200nsの遅延を付与(RDTSCスピンループ、[[HiNFS]]と同じ手法)。 **Figure 3: NVMM-LPCCテスト環境のクラスタトポロジ** ![[_attachments/2026_Unknown_NVMM_Oriented_Hierarchical_Persistent_Client/fig03-cluster-topology.png]] (Figure 3. MDS(+MDT)を中心にClient1〜Client8が1GB Ethernet経由でOSS1〜OSS3(各OSSに2台のOST)へ接続する構成を示す。) - **比較対象**: ネイティブLustre、SSD-LPCC(SSD+EXT4)、EXT4-LPCC(NVMM+標準EXT4)、EXT4-DAX-LPCC、PMFS-LPCC、NOVA-LPCC(いずれもNVMM+NVMM向けファイルシステム)。 - **評価指標**: スループット(MiB/s)、IOPS、レイテンシ(マイクロ秒)。Fioは同期(sync)モード・プロセス数1・I/Oブロックサイズ1KB/4KB/64KB/512KB/1MB/4MBで、単一操作の総読み書き量を50GBに設定(DRAMの影響を低減するため)。 ## 実験結果 ### RW-NVMM-LPCCの性能評価 **Figure 4: RW-NVMM-LPCC読み取り性能評価** ![[_attachments/2026_Unknown_NVMM_Oriented_Hierarchical_Persistent_Client/fig04-rw-read-performance.png]] (Figure 4. (a)読み取りスループット、(b)読み取りIOPS、(c)読み取りレイテンシをI/Oサイズ(1K〜4M)ごとに示す。EXT4-DAX-LPCC・PMFS-LPCC・NOVA-LPCCは64KB以上のI/Oサイズで急激に性能が向上し安定する一方、Lustre・SSD-LPCC・EXT4-LPCCは低水準にとどまる。) **Figure 5: RW-NVMM-LPCC書き込み性能評価** ![[_attachments/2026_Unknown_NVMM_Oriented_Hierarchical_Persistent_Client/fig05-rw-write-performance.png]] (Figure 5. (a)書き込みスループット、(b)書き込みIOPS、(c)書き込みレイテンシ。読み取りと同様の傾向だが、書き込みは読み取りより性能改善幅が小さい。) 読み取り・書き込みの平均性能は以下の表のとおり(ネイティブLustreを1とした相対値)。 *(Table 10. Average Performance of Read in RW-NVMM-LPCC)* | 指標 | Lustre | SSD-LPCC | EXT4-LPCC | EXT4-DAX-LPCC | PMFS-LPCC | NOVA-LPCC | |---|---|---|---|---|---|---| | Throughput | 1 | 3.23 | 8.24 | 35.50 | 34.08 | 36.82 | | IOPS | 1 | 3.76 | 8.19 | 35.48 | 34.08 | 36.73 | | Latency | 1 | 0.30 | 0.12 | 0.027 | 0.029 | 0.027 | *(Table 11. Average Performance of Write in RW-NVMM-LPCC)* | 指標 | Lustre | SSD-LPCC | EXT4-LPCC | EXT4-DAX-LPCC | PMFS-LPCC | NOVA-LPCC | |---|---|---|---|---|---|---| | Throughput | 1 | 1.97 | 4.95 | 6.39 | 10.69 | 10.65 | | IOPS | 1 | 5.03 | 8.19 | 6.52 | 10.88 | 10.84 | | Latency | 1 | 0.51 | 0.25 | 0.32 | 0.13 | 0.16 | Latency行は値が小さいほど改善(ネイティブLustre比の比率)を示す。テキストでは、SSD-LPCC・EXT4-LPCC・EXT4-DAX-LPCC・PMFS-LPCC・NOVA-LPCCがLustre比で読み取りスループットをそれぞれ2.23倍・7.23倍・34.50倍・33.08倍・35.82倍(異なるI/Oブロックサイズでの平均)、読み取りIOPSを2.75倍・7.18倍・34.48倍・33.08倍・35.7倍、読み取りレイテンシを70%・88.2%・97.2%・97.1%・97.3%削減したと報告している。書き込みスループットはそれぞれ0.97倍・3.94倍・5.39倍・9.69倍・9.65倍、書き込みIOPSは0.99倍・4.02倍・5.51倍・9.88倍・9.83倍向上、書き込みレイテンシは48.9%・75.1%・68.3%・86.6%・84.26%削減。SSD-LPCC比では、EXT4-LPCC/EXT4-DAX-LPCC/PMFS-LPCC/NOVA-LPCCの読み取りスループットがそれぞれ1.55倍・9.99倍・9.95倍・10.39倍、書き込みスループットが1.15倍・2.24倍・4.42倍・4.40倍。EXT4-DAX-LPCC/PMFS-LPCC/NOVA-LPCCはEXT4-LPCC比で読み取りスループットが3.31倍・3.14倍・3.47倍、書き込みスループットが1.03倍・1.15倍・1.16倍向上した(DAXバイパスによるページキャッシュ層・ブロック層のオーバーヘッド削減が主因)。以降の評価では、NOVAを既定のローカルファイルシステムとして使用している。 Filebenchワークロード([[fileserver]]・[[webserver]]・[[varmail]])での評価: *(Table 12. Characteristics of Filebench Workloads)* | Workload | Average file size | Number of files | R/W ratio | |---|---|---|---| | fileserver | 128 KB | 300,000 | 1:2 | | webserver | 64 KB | 300,000 | 10:1 | | varmail | 32 KB | 300,000 | 1:1 | **Figure 6: Filebenchワークロード別IOPS** ![[_attachments/2026_Unknown_NVMM_Oriented_Hierarchical_Persistent_Client/fig06-filebench-iops.png]] (Figure 6. fileserver・webserver・varmailの3ワークロードでLustre・SSD-LPCC・NVMM-LPCCのIOPSを比較。webserverではNVMM-LPCC・SSD-LPCCがLustre比でそれぞれ9.2倍・8.3倍、varmailでは1.94倍・0.5倍、fileserverでは4倍・2倍のIOPS向上。) **Figure 7: RW-NVMM-LPCCスケーラビリティ評価** ![[_attachments/2026_Unknown_NVMM_Oriented_Hierarchical_Persistent_Client/fig07-rw-scalability.png]] (Figure 7. IORをFPP(file-per-processor)モードでクライアント数1〜8までスケールさせた際の(a)読み取り・(b)書き込みスループット。NVMM-LPCCとSSD-LPCCはクライアント数に対して線形にスケールし、NVMM-LPCCがSSD-LPCCを大きく上回る。ネイティブLustreはバックエンドストレージ・ネットワーク飽和のためほぼ横ばい。) ### RO-NVMM-LPCCの性能評価 **Figure 8: RO-NVMM-LPCCの読み取り性能** ![[_attachments/2026_Unknown_NVMM_Oriented_Hierarchical_Persistent_Client/fig08-ro-read-performance.png]] (Figure 8. (a)I/Oサイズ4KB・(b)1MBでの、データサイズ1G〜64GBキャッシュ済み時の読み取りスループット。4KBではNVMM-LPCCがSSD-LPCC比約3.54倍・Lustre比約12倍、1MBではSSD-LPCC比12.52倍・Lustre比44.20倍まで性能差が拡大する。) **Figure 9: RO-NVMM-LPCCのキャッシュオーバーヘッド** ![[_attachments/2026_Unknown_NVMM_Oriented_Hierarchical_Persistent_Client/fig09-ro-cache-overhead.png]] (Figure 9. 初回アクセス時にOSTsからローカルキャッシュへのコピーを伴う場合の読み取りスループット。(a)4KBアクセスではNVMM-LPCCはLustre比わずか9%低下、SSD-LPCCは24%低下。(b)1MBアクセスではNVMM-LPCCとLustreの差は5%まで縮小し、SSD-LPCCは16%(64GB時24%)低下する。) スケーラビリティ評価(IOR、FPP、1MB I/O、クライアント数1〜8、各50GBの読み取り専用キャッシュ済みファイル)でも、NVMM-LPCC・SSD-LPCCは線形スケール、ネイティブLustreは約110 MiB/sでほぼ横ばいという、RW-NVMM-LPCCと同様の傾向を確認した(本文中Figure 7(a)と類似傾向、専用の図は割愛)。 ## 考察 - ネイティブLustreのHDDはフラッシュSSD・NVMMに比べ読み書き性能が劣り、加えてネットワーク経由のI/Oリクエストによる遅延オーバーヘッドが性能を押し下げる主要因である。 - クライアント側キャッシュを持つLustreはネイティブLustreより高性能で、NVMMをキャッシュ媒体に使う場合の改善幅はフラッシュSSDより顕著である。 - ローカル読み取りはローカル書き込みより高性能。 - ページキャッシュ・common blockレイヤーをバイパスするDAXアクセス(EXT4-DAX・PMFS・NOVA)は、標準EXT4を用いたEXT4-LPCCより明確に優れる。特にNOVA・PMFSはNVMM専用設計のため書き込み性能でEXT4-DAXを上回る。 - RO-NVMM-LPCCの初回キャッシュ投入オーバーヘッドは、NVMMでは無視できる水準(1MBアクセスで5%)に留まるが、SSDでは無視できない(16〜24%)。データが1回しかアクセスされない場合、SSDキャッシュは全体キャッシュ性能を大きく損なう可能性がある。 - POSIXの`read()`/`write()`インターフェースはシステムコールオーバーヘッドを伴うため、小さいI/Oブロックでは性能が頭打ちになりやすい。`mmap()`によるアプリケーションアドレス空間への直接マッピングでこの問題を回避できる可能性を著者らは指摘している([22])。 ## 強み / 弱点・課題 **強み** - SSDベースの前作LPCCと比べ、NVMM専用ローカルファイルシステム(NOVA/PMFS/EXT4-DAX)を選択可能な柔軟なキャッシュ構造設計により、大幅な性能向上を達成した。 - RW/RO 2モードでアプリケーション特性(単一クライアント占有 vs 複数クライアント共有読み取り)に応じた最適化を提供する。 - LustreのHSM・レイアウトロックという既存機構を再利用することで、グローバル統一名前空間とデータ一貫性を保ちながらキャッシュを実現している。 **弱点・課題(論文が明示、または実験設計から読み取れる限界)** - 評価環境にNVMM実機がなく、DRAM+書き込み遅延エミュレーションによる代替評価であるため、実NVMMデバイス(3D XPoint等)での性能特性(非対称な読み書きレイテンシ、耐久性制約等)は未検証である。 - テストクラスタはクライアント8台・OSS3台・MDS1台という小規模構成であり、著者ら自身も「クライアント数がサーバ数を大きく上回る大規模HPC環境での挙動は本実験から推測されるに過ぎない」と述べている。 - ローカルファイルシステム間(EXT4-DAX/PMFS/NOVA)の一貫性保証の強度の違い(NOVAはPMFSより強い一貫性を提供)は言及されるが、性能差の要因としての定量分析は本論文のフォーカス外とされている。 - RW-NVMM-LPCCはファイルのコピーを1部のみ保持する設計のため、別クライアントからのアクセス時にrestore操作が発生し、その間I/Oはブロックされる。restoreのレイテンシそのものの定量評価は示されていない。