## Memo ## Memo with LLM ### 論文情報 - **論文のタイトル**: LPCC: Hierarchical Persistent Client Caching for Lustre - **著者と所属**: - Yingjin Qian (DataDirect Networks / DDN) - Xi Li (DataDirect Networks / DDN) - Shuichi Ihara (DataDirect Networks / DDN) - Andreas Dilger (Whamcloud Inc.) - Carlos Thomaz (DataDirect Networks / DDN) - Shilong Wang (DataDirect Networks / DDN) - Wen Cheng (Huazhong University of Science and Technology) - Chunyan Li (Huazhong University of Science and Technology) - Lingfang Zeng (Huazhong University of Science and Technology) - Fang Wang (Huazhong University of Science and Technology) - Dan Feng (Huazhong University of Science and Technology) - Tim Süß (Johannes Gutenberg University Mainz) - André Brinkmann (Johannes Gutenberg University Mainz) - **カンファレンス/ジャーナル名**: SC '19 – International Conference for High Performance Computing, Networking, Storage and Analysis - **発表年**: 2019（Denver, Colorado, USA, November 17–19, 2019） ### 論文概要 LPCCは、Lustreファイルシステム向けの階層型永続クライアントキャッシュ機構であり、クライアントノードに搭載されたSSDをLustreのグローバル名前空間を維持したままキャッシュ層として透過的に活用する。読み書きキャッシュ（RW-PCC）と読み取り専用の複製キャッシュ（RO-PCC）の2モードを提供し、LustreのHSM機構とレイアウトロック機構を再利用することで整合性を保証する。評価では多様なワークロードにおいてLustreやDoMを上回る性能を示し、RO-PCCでクライアント数に対してほぼ線形なスループット向上を達成した。 ### 詳細解説 #### 問題設定 - **入力**: Lustreファイルシステムに対するI/Oリクエスト（read/write/metadata操作） - **出力**: クライアントノードローカルSSDを活用した高速なI/O応答 - **前提条件**: クライアントノードにSSD（本評価では512GB Samsung 840 PRO）が搭載されている - **課題**: HPCクラスタではLustreなどの並列ファイルシステムが広く利用されているが、ストレージメディアは物理的にクラスタと分離されており、ネットワーク遅延やLDLMロックのオーバーヘッドが生じる。クライアントノードに搭載されたSSDはI/Oワークフローに十分に統合されておらず、未活用のままであることが多い。 #### 提案手法 ##### アーキテクチャ LPCCは以下のコンポーネントで構成される： - **Policy Engine**: UID/GID/ProjectID/ファイル名などに基づくルールベースのキャッシュ配置を決定 - **PCC Switch**: 各クライアントに設置され、キャッシュI/Oと通常I/Oの切り替えを行う - **Copytool**: Lustre HSMのCopytoolを再利用し、ローカルキャッシュとOST間のデータ同期を担う - **SSD**: ext4ベースのローカルファイルシステムとして構成されたキャッシュバックエンド 制御フロー・データフローの観点では、Policy Engineがキャッシュポリシーを管理し、PCC SwitchがI/Oをキャッシュされたパス（ローカルSSD）または通常パス（OST経由）に振り分ける。 ##### 2つのキャッシュモード **RW-PCC（Read-Write PCC）**: - 単一クライアントのみがアクセス・変更するファイルを対象 - ファイルをローカルSSDにattachし、以降のI/OはすべてローカルSSDに対して実行 - ファイルがattachされると、LustreレイアウトロックをDRM（Dominant Resource Management）によって排他的に保持し、他クライアントからのアクセスはdetachとOSTへの同期（restore）を経て実行 - HSM archiveとして動作: ローカルキャッシュファイルをOSTにrestoreする際はHSMのCopytoolを使用 **RO-PCC（Read-Only PCC）**: - 複数クライアントに読み取り専用レプリカとして配布 - O_RDONLY モードのみでオープンされるファイルを対象 - 複数クライアントが同一ファイルのコピーをそれぞれのローカルSSDに保持 - スループットはクライアント数に対してほぼ線形にスケール ##### HSMとの統合 LBun Pool 1PCCはLustreのHSM機構を再利用する： - 各LPCCノードはHSMエージェントとして動作し、Copytoolインスタンスを実行 - ファイルのattach時はHSM archiveリクエストでローカルSSDにコピー - ファイルのdetach時はHSM restoreリクエストでOSTに書き戻す - RW-PCC detach時: OSTへのrestore完了後、HSM removeリクエストを発行 - RO-PCC detach時: ローカルコピーを単純に削除 ##### レイアウトロック機構との統合 - RW-PCC attach時にLustreレイアウトロック（Layout Lock）を排他的に取得 - 他クライアントがファイルへアクセスしようとすると、レイアウトロックのrevocationが発生 - revocation発生時: LPCC側でdetachを実行してOSTにデータを書き戻し、通常I/Oにフォールバック - LRUによるロックシュリンクやinode回収によって、involuntarily（非自発的）にdetachされることもある ##### 自動プリフェッチとキャッシュ制御 - **Auto-prefetching**: Lustreのchangelogを定期分析し、open/closeイベントのパターンを解析。単一クライアントによるopen/closeはRW-PCC候補、O_RDONLYのみのopenはRO-PCC候補として判定 - **Changelog解析間隔**: 設定可能（評価ではseconds単位） - **フォールトトレランス**: ローカルデバイスが満杯またはI/Oエラー発生時は通常I/Oパスへ自動フォールバック ##### キャッシュ退避ポリシー - クォータ制限: UID/GID/Project単位でキャッシュ容量を管理 - **LRU**: atime/mtimeに基づいて最近最も使われていないファイルから退避（最高ヒット率） - **SIZE**: 大きいファイルを優先退避（退避ファイル数が最少） - **LOG2-SIZE**: LRUとSIZEの組み合わせ #### 新規性 既存手法との比較： | 手法 | 課題 | |------|------| | 標準Lustre (stripe=n) | ネットワーク遅延・LDLMロックのオーバーヘッドが避けられない | | Lustre DoM | 小ファイルのOST負荷を軽減するが、MDT上のデータはOSTより遅い | | FS-Cache (Linux) | カーネルページキャッシュの永続化にとどまり、グローバル名前空間の統合が弱い | | BWCC, Nache, Panache等 | 特定ファイルシステムに依存、または設計が古くHPC要件に不十分 | LPCCの新規性： 1. LustreのHSM機構を**再利用**することで、整合性保証をゼロから実装せず達成 2. レイアウトロック機構を活用した**透過的なattach/detach**によりグローバル名前空間を維持 3. RW/ROの2モードにより、単一クライアント向けとマルチクライアント向けの両シナリオに対応 4. ルールベースのポリシーエンジンと自動プリフェッチで運用の自動化を実現 #### 実験設定 ##### 実験環境 - **OS**: CentOS 7 / Linux 3.10.0 - **Lustre**: バージョン 2.11.53 - **クライアントノード**: - CPU: Intel Xeon E5-2650 - メモリ: 128 GB - キャッシュSSD: 512 GB Samsung 840 PRO（ext4ベースのLPCCキャッシュ） - **ストレージ**: - OSS: DDN SFA14KXE、10台のext4ベースOST（合計10 OST） - MDS: Toshiba 200GB SSD（ext4ベースのldiskfs） ##### 比較対象 - Standard Lustre: `stripe=n`（n=1またはn=4でストライピング） - Lustre Data on MDT (DoM): 小ファイルデータをMDT上に格納 - FS-Cache: Linuxカーネルのキャッシュ機構 ##### ベンチマークツール - **fio**: 単体スレッドI/O性能評価 - **IOR** (file-per-processor/FPPモード): 並列I/Oスループット評価 - **mdtest**: メタデータ性能評価 - **filebench**: ファイルシステムワークロードシミュレーション - **HACC I/O**: HPCアプリケーションシミュレーション（FPPモード） - **compilebench**: カーネルコンパイルをシミュレート（メタデータ・小ファイル操作） #### 実験結果 ##### シングルスレッドI/O性能（fio） ローカルSSDとOSTの単体性能比較（RW-PCC vs 通常Lustre）: - ローカルSSDはOSTに対して大幅な性能優位（定性的: SSD > OST） ##### RW-PCCスケーラビリティ（IOR FPPモード） - クライアント数増加に対してRW-PCCはスループットがほぼ線形にスケール ##### メタデータ性能（mdtest、Write Size = 0） 単位: ops/sec | Operation | stripe=1 | stripe=4 | DoM | RW-PCC | |-----------|----------|----------|-----|--------| | File create | 2,776 | 2,610 | 2,793 | 1,714 | | File read | 3,614 | 3,552 | 3,478 | 3,591 | | File remove | 2,974 | 2,573 | 3,126 | 3,271 | - RW-PCCのFile createはデータなし(Write Size=0)のため遅い（ローカルSSD書き込みが不要なケースでHSMオーバーヘッドが顕在化） - ただし小ファイルのwrite性能はローカルSSDの優位性が補償し、全体的にDoMや標準Lustreを上回る ##### 小ファイル性能（various sizes） - RW-PCCはファイルサイズを問わずDoMおよび標準Lustreを上回る（グラフより定性的） ##### compilebench - RW-PCCがDoMおよび標準Lustreを上回る結果（定性的） ##### 自動キャッシングによる読み取り性能 3つのモードで評価: - **Cold mode**: 初回読み取り（キャッシュへのロード） - **Warm mode**: Cold直後の再読み取り（ページキャッシュ有効） - **Cache mode**: ページキャッシュクリア後の再読み取り（SSDキャッシュのみ） ##### RO-PCCスケーラビリティ（IOR FPPモード） RO-PCCはWarm/Cacheモードでクライアント数に対してほぼ線形にスケール: | Client count | Cold (MiB/s) | Warm (MB/s) | Cache (MB/s) | |---|---|---|---| | 1 | 478 | 4,374 | 521 | | 2 | 688 | 8,746 | 1,042 | | 4 | 718 | 17,520 | 2,074 | | 8 | 1,389 | 34,943 | 4,029 | - Warm mode: 1クライアント4,374 MB/s → 8クライアント34,943 MB/s（約8倍、ほぼ線形） - Cache mode: 1クライアント521 MB/s → 8クライアント4,029 MB/s（約7.7倍） - Cold modeは初回読み取り（ネットワーク経由）のためスケールが限定的 ##### キャッシュ退避ポリシーの評価 - **LRU**: キャッシュヒット率が最高 - **SIZE**: 退避ファイル数が最少（大きいファイルを優先退避するため、小ファイル多数をキャッシュに保持） - **LOG2-SIZE**: 中間的な特性 #### 考察 ##### 結果の解釈 - RW-PCCのFile create性能が低いのは、Write Size=0（データなし）ケースではHSMのattachオーバーヘッドが支配的になるためである。実際のワークロードでは小ファイルの書き込みを伴うため、ローカルSSDの優位性が補償する - RO-PCCの線形スケールはクライアントが独立したローカルSSDを持つ設計に由来し、OSTのボトルネックを完全に回避できる ##### 優位性の根拠 - LustreのHSMとレイアウトロックを再利用することで、既存のLustreエコシステムとの互換性を維持しながら最小限の実装変更でキャッシュ整合性を実現 - PCC Switchによる透過的なI/Oルーティングにより、アプリケーション側の変更が不要 ##### 限界と例外 - RW-PCCは単一クライアントのみが書き込むファイルに限定（複数クライアントによる協調書き込みには対応不可） - LRUベースのキャッシュシュリンクやinode回収によって意図せずdetachが発生する可能性がある - クライアントノードにSSDが必要であり、SSDが搭載されていない環境では利用不可 #### 強み - LustreのHSM/レイアウトロック機構を再利用することで、整合性保証の実装コストを最小化し、既存Lustreとの高い互換性を実現 - RW-PCCとRO-PCCの2モードにより、単一クライアントの書き込みと多クライアントの読み取りという対照的なシナリオを一つのフレームワークで対応 - RO-PCCでクライアント数に対する線形スケールを達成し、読み取り多用HPCワークロードに有効 - ルールベースポリシーエンジンと自動プリフェッチにより、運用の手動介入を削減 #### 弱点・課題 - RW-PCCはファイルを単一クライアントが排他的に使用する場合にのみ有効であり、共有書き込みワークロードには適用不可 - File createメタデータ性能（Write Size=0）はDoMや標準Lustreより劣る（HSMオーバーヘッド） - SSDデバイスが満杯の場合はフォールバックするが、キャッシュ効率が低下する - 評価はCentOS 7 / Lustre 2.11環境に限定されており、他のLustreバージョンや環境への汎化性は未検証 - 論文はスライド形式での発表資料（pap112s5.pdf）であり、フルペーパー版は別途ACM DL (DOI: 10.1145/3295500.3356139)を参照 ## Abstract HPCクラスタの大部分は今日、高データスループットを実現するためにグローバルな並列ファイルシステムを使用している。並列ファイルシステムは一般に集中管理型であり、そのストレージメディアは計算クラスタから物理的に分離されている。並列ファイルシステムのクライアントとしての計算ノードは、しばしば追加のSSDを搭載している。ノード内部のストレージメディアはI/Oおよび計算ワークフローに十分統合されておらず、これらのストレージメディアを最大限かつ柔軟に活用する方法は価値ある研究課題である。 本論文では、Lustreファイルシステム向けの階層型Persistent Client Caching（LPCC）機構を提案する。LPCCは2つのモードを提供する：RW-PCCは単一クライアントのローカルSSD上に読み書きキャッシュを構築し、RO-PCCは複数クライアントのSSD上に読み取り専用キャッシュを分散配置する。LPCCはLustreのHSMソリューションとLustreレイアウトロック機構と統合し、クライアントノード上で実行されるI/Oアプリケーションに対して整合性のある永続キャッシュサービスを提供しながら、分散型の永続クライアントキャッシングのためにLustreファイルシステム全体のグローバル統一名前空間を維持する。 評価結果は様々なワークロードに対するLPCCの優位性を示し、いくつかの実世界のシナリオにおいてクライアント数に対して線形なスピードアップをも可能にすることを示している。