# ストレージクォータ管理 Navigation: [[../index|index]] ## 定義 ストレージクォータ管理とは、ユーザ・グループ・プロジェクトといった主体ごとにディスク上のブロック(データ)量と inode(メタデータ)数の上限を設け、その使用量を計測・強制する運用機構である。単一ノードのローカルファイルシステムにおけるクォータは、使用量の会計(accounting)と制限の強制(enforcement)が同一ノード上で完結するため単純だが、分散ファイルシステムでは会計対象のリソース(ブロック・inode)が複数のストレージターゲットに分散して配置されるため、グローバルな制限を中央で保持しつつ各ターゲットへ実行時に枠を割り当てるという、集中管理と分散配布の折衷が必要になる(Source: [[@2026__Whamcloud__Lustre Operations Manual - Chapter 25 Configuring and Managing Quotas]])。 Lustre の実装では、この折衷は Quota Master Target(QMT。グローバルな制限を保持し MDT0000 上に 1 インスタンスだけ存在する)と、各 OST・MDT に置かれる Quota Slave Device(QSD。QMT から qunit 単位でクォータ枠を借用・返却するクライアント役)という 2 層構造で実現される。この構造ゆえに、ブロッククォータは OST 単位、inode クォータは MDT 単位で個別に消費が管理され、特定のターゲットの枠が枯渇すると、システム全体としては空きがあってもそのターゲットを経由する操作だけが失敗しうるという粒度の問題が生じる。さらに OST 側のグラントキャッシュ(書き込みを先行して成功応答する機構)はクォータ制限そのものを尊重しないため、分散ファイルシステムでクォータを「正確に」強制することは原理的に難しく、緩和策(ダーティデータ上限の縮小など)はあっても根絶する手段は無い(Source: [[@2026__Whamcloud__Lustre Operations Manual - Chapter 25 Configuring and Managing Quotas]])。 ## 未解決の問い - 単一の QMT インスタンス(MDT0000 上でのみ稼働)がグローバルクォータ管理のボトルネックや単一障害点になり得るか、他の分散ファイルシステム(BeeGFS、GPFS/Spectrum Scale、CephFS 等)はグローバルクォータ主体をどう配置し、単一障害点を避けているか。 - OST/MDT ごとの粒度でクォータ枠を分散配布する設計(qunit の動的縮小)は、ターゲット数やワークロードの偏りに対してどの程度スケールするか。他システムの類似機構(トークンバケットの分散配布など)と比較したときの得失は何か。 - グラントキャッシュのようにクォータ制限を一時的に迂回する最適化(書き込みの先行応答)は、他の分散ファイルシステムでも共通して採用されているか。クォータの正確性と書き込みレイテンシのトレードオフはどう設計されているか。 - プールクォータのように「グローバル制限 かつ サブセット制限」を階層的に組み合わせる設計は、Lustre 以外の分散ストレージ・クラウドストレージ(S3 バケットクォータ、Kubernetes の ResourceQuota 等)ではどのように一般化されているか。 ## 未編纂の観察 ## 関連 - ソース: [[@2026__Whamcloud__Lustre Operations Manual - Chapter 25 Configuring and Managing Quotas]] - 実体: [[wiki/entities/Lustre|Lustre]] ## 出典 - *Lustre Software Release 2.x Operations Manual*, Whamcloud, built 2026-05-26, Chapter 25. https://doc.lustre.org/lustre_manual.xhtml