

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ボリュームストレージ容量
<a name="volume-storage-capacity"></a>

FSx for ONTAP ボリュームは、データをグループ化し、データの保存方法を決定し、データへのアクセスの種類を決定するために使用する仮想リソースです。ボリュームは、フォルダと同様に、ファイルシステムのストレージ容量自体を消費しません。ボリュームに保存されているデータのみが SSD ストレージを消費し、[ボリュームの階層化ポリシー](#data-tiering-policy) によっては容量プールストレージも消費します。ボリュームのサイズは作成時に設定し、後でサイズを変更できます。、 API AWS マネジメントコンソール、 AWS CLI ONTAP CLI を使用して、FSx for ONTAP ボリュームのストレージ容量をモニタリングおよび管理できます。

**Topics**
+ [ボリュームデータの階層化](#volume-data-tiering)
+ [スナップショットとボリュームストレージ容量](#managing-snapshots)
+ [ボリュームファイル容量](#managing-volume-file-capacity)
+ [ストレージ効率の管理](manage-vol-SE.md)
+ [自動サイズ調整の有効化](enable-volume-autosizing.md)
+ [クラウド書き込みモードの有効化](cloud-write-mode.md)
+ [ストレージ容量の更新](manage-volume-capacity.md)
+ [階層化ポリシーの更新](modify-volume-tiering-policy.md)
+ [最低冷却日数の更新](set-cooling-days.md)
+ [ボリュームのクラウド検索ポリシーの更新](set-cloud-retrieval.md)
+ [ボリューム上のファイルの最大数の更新](increase-volume-max-files.md)
+ [ボリュームストレージ容量のモニタリング](monitor-volume-storage-console.md)
+ [ボリュームのファイル容量のモニタリング](view-volume-file-capacity.md)

## ボリュームデータの階層化
<a name="volume-data-tiering"></a>

Amazon FSx for NetApp ONTAP ファイルシステムには、プライマリストレージと容量プールストレージの 2 つのストレージ階層があります。プライマリストレージは、データセットのアクティブな部分に合わせて設計された、プロビジョニングされ、スケーラブルでハイパフォーマンスな SSD ストレージです。容量プールストレージは、ペタバイトサイズまで拡張できる完全に伸縮性のあるストレージ階層で、アクセス頻度の低いに対してコストが最適化されます。

各ボリュームのデータは、ボリュームの階層化ポリシー、冷却期間、しきい値設定に基づいて、容量プールストレージ階層に自動的に階層化されます。以下のセクションでは、ONTAP ボリューム階層化ポリシーと、データが容量プールに階層化されるタイミングを決定するために使用されるしきい値について説明します。

**注記**  
FSx for ONTAP は、SnapLock タイプに関係なく、すべての SnapLock ボリュームの容量プールへのデータの階層化をサポートしています。詳細については、「[SnapLock の仕組み](how-snaplock-works.md)」を参照してください。

### ボリューム階層化ポリシー
<a name="data-tiering-policy"></a>

FSx for ONTAP ファイルシステムのストレージ階層をどのように使用するかは、ファイルシステムのボリュームごとに階層化ポリシーを選択することによって決定します。ボリュームの作成時に階層化ポリシーを選択し、Amazon FSx コンソール、、API AWS CLI、または [NetApp 管理ツールを使用して](managing-resources-ontap-apps.md)いつでも変更できます。どのデータを容量プールのストレージに階層化するかは (階層化するデータがある場合) 、以下のポリシーから選択できます。

**注記**  
階層化により、ファイルデータとスナップショットデータを容量プール階層に移動できます。ただし、ファイルメタデータは常に SSD 階層に残ります。詳細については、「[SSD ストレージの使用方法](managing-storage-capacity.md#how-ssd-is-used)」を参照してください。
+ **[Auto]** (自動) — このポリシーは、すべてのコールドデータ (ユーザーデータとスナップショット) を容量プール階層に移動します。データの冷却速度は、ポリシーの冷却期間 (デフォルトは 31 日間) によって決定され、2〜183 日の間で設定できます。基盤となるコールドデータブロックが (一般的なファイルアクセスのように) ランダムに読み取られると、ホットになり、プライマリストレージ層に書き込まれます。コールドデータブロックが (ウイルス対策スキャンなどで) 順番に読み取られると、コールドデータブロックはコールドのまま容量プールのストレージ階層に残ります。これは、Amazon FSx コンソールを使用してボリュームを作成するときのデフォルトポリシーです。
+ **[Snapshot Only]** (スナップショットのみ) — このポリシーは、スナップショットデータのみを容量プールのストレージ階層に移動します。スナップショットが容量プールに階層化される速度は、ポリシーの冷却期間によって決まります。冷却期間は、デフォルトで 2 日間に設定され、2～183 日の間で設定できます。コールドスナップショットデータが読み取られると、ホットになり、プライマリストレージ階層に書き込まれます。これは、、Amazon FSx API AWS CLI、または NetApp ONTAP CLI を使用してボリュームを作成するときのデフォルトのポリシーです。
+ **[All]** (すべて) — このポリシーは、すべてのユーザーデータとスナップショットデータをコールドとしてマークし、容量プール階層に保存します。データブロックが読み込み時には、コールド状態のまま、プライマリストレージ階層には書き込まれません。**[All]** (すべて) の階層化 ポリシーを使用してボリュームにデータを書き込むと、最初は SSD ストレージ階層に書き込まれ、バックグラウンドプロセスによって容量プールに階層化されます。既にデータが含まれているボリュームに** All **ポリシーが適用されている場合、既存のデータは SSD から容量プールに階層化されます。ファイルのメタデータは常に SSD 階層に残っていることに注意してください。
+ **[None]** (なし) — このポリシーは、ボリュームのすべてのデータをプライマリストレージ層に保持し、キャパシティプールストレージに移動できないようにします。他のポリシーの使用後にボリュームをこのポリシーに設定すると、容量プールストレージにあったボリューム内の既存のデータ (スナップショットを含む) は、バックグラウンドプロセスによって SSD ストレージに移動されます。このデータ移行は、SSD の使用率が 90% 未満で、クラウド取得ポリシーが`promote`または`on-read`に設定されている場合にのみ行われます。このバックグラウンドプロセスは、意図的にデータを読み取ることで高速化できます。詳細については、「[クラウド取得ポリシー](#cloud-retrieval-policies)」を参照してください。

ボリュームの階層化ポリシーの設定または変更の詳細については、[階層化ポリシーの更新](modify-volume-tiering-policy.md) を参照してください。

 ベストプラクティスとして、容量プールストレージに長期的に保存する予定のデータを移行する場合は、ボリュームで **[自動]** 階層化ポリシーを使用することをお勧めします。**[自動]** 階層化では、データは容量プール階層に移動する前に、少なくとも 2 日間 (ボリュームの冷却期間に基づく) SSD ストレージ階層に格納されます。ONTAP は、SSD ストレージ階層に格納されているデータに対してプロセス後の重複排除を定期的に実行し、ボリュームのデータ変更率に基づいて頻度を自動的に調整します。変更率が高いほど、プロセス後の重複排除ジョブがトリガーされます。

デフォルトでは、ファイルシステムの進行中のワークロードに対するパフォーマンスへの影響により、後処理圧縮は ONTAP では無効になっています。後処理圧縮を有効にする前に、ワークロードのパフォーマンスへの影響を評価する必要があります。後処理圧縮を有効にするには、ONTAP CLI で診断特権レベルを予測し、次のコマンドを実行します。

```
::> volume efficiency inactive-data-compression modify -vserver {{svm-name}} -volume {{vol-name}} -is-enabled true
```

ONTAP は、SSD ストレージに少なくとも 14 日間保持されるデータの後処理圧縮を実行します。より短い期間後にデータにアクセスする可能性が低いワークロードの場合、後処理圧縮を早く実行するように後処理圧縮の設定を変更できます。例えば、5 日間アクセスされていないデータに後処理圧縮の節約を適用するには、次の ONTAP CLI コマンドを実行します。

```
::> volume efficiency inactive-data-compression modify -vserver {{svm-name}} -volume {{vol-name}} -threshold-days 5 -threshold-days-min 2 -threshold-days-max 14
```

コマンドの詳細については、「[ボリューム効率非アクティブデータ圧縮の変更](https://docs.netapp.com/us-en/ontap-cli-9141/volume-efficiency-inactive-data-compression-modify.html)」を参照してください。

 SSD にデータを保持することで、SSD ストレージのデータ転送レートが高くなるため、作成したボリュームバックアップの転送速度を最大化できます。

### 階層化の冷却期間
<a name="tiering-cooling-period"></a>

ボリュームの階層化冷却期間は、SSD 階層内のデータがコールドとしてマークされるまでにかかる時間を設定します。冷却期間は、`Auto` や `Snapshot-only`、および階層化ポリシーに適用されます。冷却期間は 2～183 日の範囲の値に設定できます。冷却期間の設定の詳細については、[最低冷却日数の更新](set-cooling-days.md) を参照してください。

データは、冷却期間が終了してから 24～48 時間後に階層化されます。階層化はネットワークリソースを消費するバックグラウンドプロセスであり、クライアント側のリクエストよりも優先度が低くなります。クライアント側のリクエストが続いている場合、階層化アクティビティは制限されます。

### クラウド取得ポリシー
<a name="cloud-retrieval-policies"></a>

ボリュームのクラウド検索ポリシーは、容量プール階層から読み取られたデータを SSD 階層に昇格させるタイミングを指定するための条件を設定します。クラウド検索ポリシーを `Default` 以外に設定すると、このポリシーがボリュームの階層化ポリシーの取得動作よりも優先されます。ボリュームには、次のいずれかのクラウド検索ポリシーがあります。
+ **[Default]** (デフォルト) — このポリシーは、ボリュームの基礎となる階層化ポリシーに基づいて階層化されたデータを取得します。これはすべてのボリュームのデフォルトのクラウド検索ポリシーです。
+ **[Never]** (なし) — このポリシーは、読み取りがシーケンシャルかランダムかに関係なく、階層化されたデータを取得しません。これは、ボリュームの階層化ポリシーを **[All]** (すべて) に設定するのと似ていますが、他のポリシー - **[Auto]** (自動)、**[Snapshot-only]** (スナップショットのみ) - と併用することで、データを即時ではなく、最小冷却期間に従って階層化することができます。
+ **[On-read]** (読み取り時) — このポリシーは、クライアント主導のすべてのデータ読み取りに対して、階層化されたデータを取得します。このポリシーは、**[All]** (すべての) 階層化ポリシーを使用している場合は効果がありません。
+ **[Promote]** (プロモート) — このポリシーは、容量プールにあるボリュームのすべてのデータを SSD 階層に取得対象としてマークします。データは、日次バックグラウンド階層化スキャナーが、次回実行されたときにマークされます。このポリシーは、頻繁には実行されない周期的なワークロードがあるが、実行時には SSD 階層のパフォーマンスが必要なアプリケーションにとって有益です。このポリシーは、**[All]** (すべての) 階層化ポリシーを使用している場合は効果がありません。

ボリュームのクラウド検索ポリシーの設定については、[ボリュームのクラウド検索ポリシーの更新](set-cloud-retrieval.md) を参照してください。

### 階層化のしきい値
<a name="storage-tiering-thresholds"></a>

ファイルシステムの SSD ストレージ容量の使用率によって、ONTAP がすべてのボリュームの階層化動作を管理する方法が決まります。ファイルシステムの SSD ストレージ容量の使用状況に基づいて、以下のしきい値によって階層化の動作が説明どおりに設定されます。ボリュームの SSD ストレージ階層の容量使用率を監視する方法については、[ボリュームストレージ容量のモニタリング](monitor-volume-storage-console.md) を参照してください。

**注記**  
SSD ストレージ層のストレージ容量使用率が 80% を超えないようにすることをお勧めします。第 2 世代のファイルシステムの場合、この推奨事項は、ファイルシステムのすべてのアグリゲートの合計平均使用率と、個々のアグリゲートの使用率の両方に適用されます。これにより、階層化が適切に機能し、新しいデータのオーバーヘッドが発生します。SSD ストレージ層のストレージ容量使用率が一貫して 80% を上回っている場合は、SSD ストレージ層の容量を増やすことができます。詳細については、「[ファイルシステム SSD ストレージと IOPS の更新](storage-capacity-and-IOPS.md#increase-primary-storage)」を参照してください。

FSx for ONTAP では、次のストレージ容量のしきい値を使用してボリュームの階層化を管理します。
+ **SSD ストレージ階層の使用率が 50% 以下** — このしきい値では、SSD ストレージ階層は十分に活用されていないと見なされ、**[All]** (すべての) 階層化ポリシーを使用しているボリュームのみが容量プールストレージにデータを階層化しています。**[Auto]** (自動) ポリシーと **[Snapshot-only]** (Snapshot 専用) ポリシーが適用されているボリュームでは、このしきい値ではデータが階層化されません。
+ **SSD ストレージ階層の使用率が 50% を超える** — **[Auto]** (自動) および **[Snapshot-only]** (Snapshot 専用) の階層化ポリシーが適用されたボリュームでは、階層化の最小冷却日数設定に基づいてデータが階層化されます。デフォルト設定は 31 日間。
+ **SSD ストレージ階層の使用率が 90% 以上** – このしきい値では、Amazon FSx は SSD ストレージ階層のスペース確保を優先します。**[Auto]** (自動) および **[Snapshot-only]** (Snapshot 専用) ポリシーを使用するボリュームを読み取る場合、容量プール階層のコールドデータが SSD ストレージ層に移動されなくなりました。
+ **SSD ストレージ階層の使用率が 98% 以上** – SSD ストレージ階層の使用率が 98% 以上になると、すべての階層化機能が停止します。ストレージ階層からの読み取りは引き続き可能ですが、階層への書き込みはできません。

## スナップショットとボリュームストレージ容量
<a name="managing-snapshots"></a>

*snapshot* (スナップショット) は、ある時点での Amazon FSx for NetApp ONTAP ボリュームの読み取り専用イメージです。スナップショットは、ボリューム内のファイルの間違った削除や変更からの保護を提供します。スナップショットで、ユーザーは以前のスナップショットから個々のファイルやフォルダを簡単に表示および復元できます。

スナップショットはファイルシステムのデータと一緒に保存されるため、ファイルシステムのストレージ容量が消費されます。ただし、スナップショットは、前回のスナップショット以降に変更されたファイルの部分に対してのみストレージ容量を消費します。スナップショットは、ファイルシステムボリュームのバックアップには含まれません。

スナップショットは、デフォルトのスナップショットポリシーを使用して、ボリューム上でデフォルトで有効になります。スナップショットはボリュームのルート内の `.snapshot` ディレクトリに保存されます。スナップショットのボリュームストレージ容量を管理できます。
+ 「[Snapshot policies](snapshots-ontap.md#snapshot-policies)」 (スナップショットポリシー) — 組み込みのスナップショットポリシーを選択するか、ONTAP CLI または REST API で作成したカスタムポリシーを選択します。
+ 「[Manually delete snapshots](manually-delete-snapshots.md)」(スナップショットの手動削除) — スナップショットを手動で削除してストレージ容量を再利用します。
+ 「[Create a snapshot autodelete policy](snapshot-autodelete-policy.md)」(スナップショット自動削除ポリシーの作成) — デフォルトのスナップショットポリシーよりも多くのスナップショットを削除するポリシーを作成します。
+ 「[Turn off automatic snapshots](disable-snapshots.md)」(自動スナップショットをオフにする) — 自動スナップショットをオフにしてストレージ容量を節約します。

詳細については、「[スナップショットによるデータの保護](snapshots-ontap.md)」を参照してください。

## ボリュームファイル容量
<a name="managing-volume-file-capacity"></a>

Amazon FSx for NetApp ONTAP ボリュームには、ファイル名、最終アクセス時間、権限、サイズなどのファイルメタデータを保存したり、データブロックへのポインタとして機能したりするために使用されるファイルポインタがあります。これらのファイルポインタは inode と呼ばれ、各ボリュームには inode の数に対する有限の容量があり、これをボリュームファイル容量と呼びます。ボリュームの容量が少なくなったり、使用可能なファイル (inode) を使い果たしたりすると、そのボリュームに追加のデータを書き込むことはできません。

ボリュームに格納できるファイルシステムオブジェクト (ファイル、ディレクトリ、スナップショットコピー) の数は、その inode の数によって決まります。ボリューム内の inode の数は、ボリュームのストレージ容量 (および FlexGroup ボリュームの構成ボリューム数) に応じて増加します。デフォルトでは、648 GiB 以上のストレージ容量を持つ FlexVol ボリューム (または FlexGroup 構成要素) は、すべて同じ数 (21,251,126) の inode を持ちます。648 GiB を超えるボリュームを作成し、21,251,126 以上の inode をを含める場合は、ボリューム上のファイルの最大数を手動で増やす必要があります。ボリュームの最大ファイル数の表示の詳細については、「[ボリュームのファイル容量のモニタリング](view-volume-file-capacity.md)」を参照してください。

ボリューム上の inode のデフォルトの数は、ボリュームストレージ容量の 32 KiB ごとに 1 つの inode で、ボリュームサイズは 648 GiB までとされています。1 GiB ボリュームの場合:

ボリュームサイズ (バイト単位)×(1 ファイル÷バイト単位の inode サイズ)=ファイルの最大数

1,073,741,824 バイト×(1 ファイル÷32,768 バイト)=32,768 ファイル

ボリュームに含めることができる inode の最大数は、ストレージ容量 4 KiB ごとに最大 1 つの inode まで増やすことができます。1 GiB ボリュームの場合、inode またはファイルの最大数が 32,768 から 262,144 に増加します:

1,073,741,824 バイト×(1 ファイル÷ 4096 バイト)=262,144 ファイル

FSx for ONTAP には、最大 20 億の inode を含めることができます。

ボリュームが格納できるファイルの最大数の変更については、「[ボリューム上のファイルの最大数の更新](increase-volume-max-files.md)」を参照してください。