収集または推定：

日平均値ではなく、最高水位の値を使用してください。ビルドパイプライン、分析ジョブ、移行、および一時的なスクラッチワークフローは、多くの場合、短期間に最大の名前空間を作成し、その後クリーンアップしますが、inodeファイルとディレクトリファイルは、クリーンアップ後もハイウォーターマークを保持する可能性があります。

2つの異なる予測を維持します：

*一方の値から他方の値を導き出さないでください。*シャーディングされた名前空間（ファイルが複数のディレクトリに分割されている）は、大きなディレクトリを作成せずに `maxfiles`を使い果たす可能性があります。単一のフラットディレクトリは、ボリュームに数百万の空きinodeがある状態でも `maxdir-size`の制限に達する可能性があります。

*NTFSまたは高度にACLが設定された名前空間において、目に見えるファイル数のみに基づいてサイズを設定しないでください maxfiles。*ディレクトリ、ACL iノード、名前付きストリーム、その他の公開オブジェクトをプロジェクションに含めてください。ACLが多用されている場合は、予測されるファイルとディレクトリ数の最大2倍を保守的な開始見積もりとして `files`に使用し、ACL共有により実際の使用量が削減される可能性があるため、代表的なデータを用いて検証してください。

"ONTAP inode タイプ" および "Maxdir-size と large ONTAP ディレクトリ" を参照してください。

名前空間のレイアウトには、一般的に3種類あります。

アプリケーションが広範囲または深い階層構造を利用できる場合は、可能な限り、数百万もの名前を単一のフラットなディレクトリレベルに配置することは避けてください。フラットレイアウトはメモリとCPUの処理を集中させ、大量 GETATTR、 READDIR、検索、および削除操作時のレイテンシを増加させる可能性があります。FlexGroupボリュームでは、大きなフラットディレクトリはリモートエントリをさらに生成し、FlexVolでの同じ表示名数の場合よりも早くディレクトリファイルが上限に近づく可能性があります maxdir-size。

FlexGroupボリュームは一般的に、1つの大きなフラットなディレクトリよりも、多数の小さなディレクトリで構成する方がうまく機能します。約2MiB以下のディレクトリは、単純なスキャンパスに留まります。ONTAP 9.2以降では、より大きなディレクトリが自動的にインデックス化されるため、ターゲットを絞った検索が容易になります。インデックス作成によって、非常に大きなディレクトリがシャーディングされた階層構造と同等になるわけではありません。列挙、ワイルドカードスキャン、および単一ディレクトリ作成時のシリアル化は依然として適用されます。ONTAPは、親ディレクトリへのファイルのローカル性を優先しながら、FlexGroupの子ディレクトリをリモートに配置することができ、これによりそれらのファイルのリモートレイテンシを低減します。

ファイルを階層構造に分散させるということは、ディレクトリ数を増やし、各ディレクトリ内のファイル数を減らすことを意味します。

一般的なシャーディングキーには以下が含まれます：

ディレクトリ操作を管理しやすいように十分な数のシャードを選択しますが、ディレクトリ数自体が過剰になるほど多くのほぼ空のディレクトリを作成しないようにしてください。決定論的な方式では、ファイルの配置が予測可能になり、クライアントはすべてのシャードをスキャンすることなくファイルの位置を特定できます。

フラットなレイアウトと深いレイアウトは、どちらも有効です。完全なパス長は、NASプロトコル、クライアントのオペレーティングシステム、およびアプリケーションの制限内に収めてください。フラットなレイアウトが避けられない場合は、"maxdir-size と現在のディレクトリサイズの表示"で説明されているように、最大のディレクトリファイルの現在のサイズと `maxdir-size`ヘッドルームを監視し、制御された増加が適切かどうかを検証してください。

使用中のinode数または最大のディレクトリファイルの100%で定常状態の動作を計画しないでください。予期せぬ増加、一時オブジェクト、Snapshot保持メタデータ、ACLとストリーム、移行の重複、バックアップ作業、FlexGroup配置の不均衡、およびファイル名を変更するソフトウェアの変更のために余裕を確保してください。

inodeファイル、ディレクトリファイル、インデックス、Snapshot、およびアグリゲートメタデータをそれぞれ個別に予算化します。割り当てられたパブリックinodeごとに288バイトを基本inodeファイル推定値として使用します。"容量が及ぼす影響"を参照してください。 `files`を増やしても、そのスペースはすぐには割り当てられません。割り当てられたinodeファイルのピーク容量を永続的なものとして扱います。

少なくとも以下のテストを実施してください：

パスの長さとベース名の長さは互換性がありません。複数のディレクトリにまたがる長いパスは、プロトコルの制限や inode 数に影響を与え、各ディレクトリにはその直下のコンポーネントのみが格納されます。

連続的な帯域幅テストでは、ファイル数が多い場合の動作を予測することはできません。含む：

レイテンシ分布、CPU、キャッシュの動作、ネットワーク負荷、および完了時間を測定します。本番環境でSnapshot、レプリケーション、分析、バックアップ、セキュリティスキャンが同時に実行される場合は、これらの操作中にテストを繰り返してください。

初回取り込み以降のテスト：

ディレクトリインデックスは、転送先で作成または転送する必要がある場合があります。パブリックインデックス転送を有効にするのは、再構築を回避することでリカバリが大幅に改善される場合に限ります。ローカル検索の改善にはつながりません。参照："パブリックディレクトリインデックス転送を有効にするタイミング"

"maxfiles、EMSイベント、ONTAP機能強化のモニタリング"で説明されているように、 `files-used`を `files`および `inodefile-public-capacity`と比較して追跡します。 `files-used`が `files`に達する前にアラートを送信します。FlexGroupボリュームの場合、全体的な合計に余裕があるように見える場合でも、コンスティチュエント レベルのイベントを調査します。

ディレクトリファイルサイズを測定し、"maxdir-size と現在のディレクトリサイズの表示"の説明に従って EMS ファイル ID を解決します。警告が発生する前に、既知のフラットなディレクトリや頻繁に更新されるディレクトリをインベントリしてください。

inode の警告：

ディレクトリサイズに関する警告について：

ファイルを削除すると、パブリックinodeが解放されて再利用できるようになりますが、パブリックinodeファイルのサイズは縮小されません。同様に、ディレクトリから名前を削除すると、ディレクトリのスロットが再利用可能になりますが、通常はディレクトリファイルの最大サイズは縮小されません。

大規模な削除はメタデータを大量に消費する可能性があり、一時的にプライベートゾンビiノードを増加させる可能性があります。本番トラフィックと競合する場合は、クライアント側の再帰的削除をレート制限してください(rm -rf）。

ONTAP 9.8 以降、 volume file async-delete は NFS や SMB 経由ではなく、クラスタからディレクトリを削除することで、クライアントおよびネットワークの競合を回避します。これは FlexVol および FlexGroup ボリュームに適用されます。ONTAP はパスをスキャンし、最初にサブディレクトリの内容を削除し、並列削除タスクを実行します（デフォルトは 5,000 の同時タスク。50 から 100,000 まで設定可能）。TR-4571 のテストでは、24,000 エントリのツリーにおいてシングルスレッドの rm -rf と比較して約 10 倍高速でした。

制約事項：ボリュームはオンラインでマウントされている必要があり、パスはディレクトリである必要があり（単一のファイルではない）、非同期削除ジョブは一度に1つしか実行できません。

大きなスパースディレクトリが問題となる場合は、残りのエントリを新しいディレクトリにコピーしてください。 `maxdir-size`を低下させても、コンパクト化は行われません。"スパースディレクトリとホールパンチング"を参照してください。

ファイル数が多い処理は、データスループットが低い場合でも、CPU、メモリ、キャッシュ、ストレージI/Oを大量に消費します。以下のための余裕を確保してください：

ワークロードのバランスを取るには、容量やスループットだけでなく、観測されたメタデータの需要も考慮に入れてください。ネットワークとディスクの帯域幅が利用可能に見えても、ノードがメタデータによって制限されることがあります。

ファイル数の多いNASは、メタデータに制約を受けることが多いです。NFSまたはSMBマウントは通常、1つのTCP接続を使用して1つのデータLIFにアクセスし、そのLIFは1つのノード上に存在します。多数のクライアント、スキャナ、またはバックアップジョブが同じアドレスをマウントすると、クラスタの他の部分がアイドル状態であっても、そのノードはプロトコル処理にCPUを消費します。FlexGroupはファイル操作をクラスタネットワーク経由でリダイレクトできますが、クライアント接続を所有するノードへの負荷は解消されません。

NFS `nconnect`またはSMBマルチチャネルをサポートする単一のクライアントは、1つのマウント上で追加の接続を開くことができます。これはそのクライアントにとって有益ですが、多数のクライアントをLIFやノードに分散させる方法を置き換えるものではありません。

ONTAP の以降のリリースには、ディレクトリインデックス作成、inode 管理の改善、スパースディレクトリの最適化、ディレクトリインデックスの転送、その他ファイル数の多いシステム向けの機能強化が含まれています。アップグレードの決定にあたっては、プラットフォームのサポート状況、データ保護の互換性、およびアプリケーションの適合性を考慮する必要があります。

ファイル数が多いという理由だけで機能を有効にしないでください。

ONTAP 9.17.1 以降、ファイルシステム分析は、新しく作成された NAS SVM の新しいボリュームでデフォルトで有効にすることができます。無効になっていると想定するのではなく、チェック `-analytics-state`し、ファイル数の多いワークロードを評価する際には、その名前空間スキャンを考慮してください。

レコード：

アプリケーションのバージョン、ファイル名の形式、保持期間、プロトコル、またはデータ保護ワークフローが変更された場合は、モデルを見直してください。