

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

# ストレージ容量の管理
<a name="managing-storage-capacity"></a>

Amazon FSx for NetApp ONTAP は、ファイルシステムのストレージ容量を管理するために使用できる、ストレージ関連の機能を数多く提供しています。

**Topics**
+ [FSx for ONTAP ストレージ階層](#storage-tiers)
+ [適切な量のファイルシステム SSD ストレージの選択](#choose-ssd-capacity)
+ [ファイルシステムのストレージ容量および IOPS](storage-capacity-and-IOPS.md)
+ [ボリュームストレージ容量](volume-storage-capacity.md)

## FSx for ONTAP ストレージ階層
<a name="storage-tiers"></a>

ストレージ階層は、Amazon FSx for NetApp ONTAP ファイルシステムの物理的なストレージメディアです。FSx for ONTAP は、次のストレージ階層を提供します。
+ SSD 階層 — データセットのアクティブな部分専用に設計された、ユーザーがプロビジョニングする高性能ソリッドステートドライブ (SSD) ストレージです。
+ 容量プール層 — ペタバイト規模まで自動的に拡張する、伸縮自在なストレージで、アクセス頻度の低いデータに対してコストを最適化します。

FSx for ONTAP ボリュームは、フォルダと同様にストレージ容量を消費しない仮想リソースです。保存するデータ、そして物理的なストレージを消費するデータは、ボリューム内に格納されます。ボリュームの作成時に、サイズを指定します。サイズは、作成後に変更できます。FSx for ONTAP ボリュームはシンプロビジョニングされ、ファイルシステムストレージは事前に予約されません。代わりに、SSD と容量プールのストレージは必要に応じて動的に割り当てられます。ボリュームレベルで構成する[階層化ポリシー](volume-storage-capacity.md#data-tiering-policy)は、SSD 階層に保存されているデータを容量プール階層に移行するかどうか、いつ移行するかを決定します。

次の図は、ファイルシステム内の複数の FSx for ONTAP ボリュームにまたがって配置されたデータの例を示しています。

![FSx for ONTAP SSD と容量プールのストレージ階層は、ファイルシステムボリューム全体で論理的にプロビジョニングされます。](http://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/images/fsx-ontap-volume-virtual-resource.png)


次の図は、前の図の 4 つのボリューム内のデータによって、ファイルシステムの物理ストレージ容量が、どのように消費されるかを示しています。

![ファイルシステム内のすべてのボリュームでの、ファイルシステムの物理ストレージ容量の SSD (プライマリストレージ層) と容量プールストレージ層の使用状況の表示。](http://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/images/fsx-ontap-storage-tiers-physical-resource.png)


ファイルシステムの各ボリュームの要件に最適な階層化ポリシーを選択することで、ストレージコストを削減できます。詳細については、「[ボリュームデータの階層化](volume-storage-capacity.md#volume-data-tiering)」を参照してください。

## 適切な量のファイルシステム SSD ストレージの選択
<a name="choose-ssd-capacity"></a>

FSx for ONTAP ファイルシステムの SSD ストレージ容量を選択する際には、データの保存に使用できる SSD ストレージの容量に影響する次の項目を考慮する必要があります。
+ NetApp ONTAP ソフトウェアのオーバーヘッド用に予約されたストレージ容量です。
+ ファイルメタデータ
+ 最近書き込まれたデータ
+ SSD ストレージに保存する予定のファイルです (冷却期間に達していないデータや、最近読み込んで SSD に取り出したデータなど)。

### SSD ストレージの使用方法
<a name="how-ssd-is-used"></a>

ファイルシステムの SSD ストレージは、NetApp ONTAP ソフトウェア (オーバーヘッド)、ファイルメタデータ、およびデータの組み合わせに使用されます。

#### NetApp ONTAP ソフトウェアオーバーヘッド
<a name="ONTAP-overhead"></a>

他の NetApp ONTAP ファイルシステムと同様に、最大 16% のファイルシステムの SSD ストレージ容量は ONTAP オーバーヘッド用に予約されているため、ファイルを保存することはできません。ONTAP オーバーヘッドは次のように割り当てられます。
+ 11% は NetApp ONTAPソフトウェアに割り当てられています。SSD ストレージ容量が 30 テビバイト (TiB) を超えるファイルシステムでは、6% が予約されています。
+ 5% は、ファイルシステムの両方のファイルサーバ間でデータを同期させるために必要な、集約スナップショット用に確保されています。



#### ファイルメタデータ
<a name="file-metadata"></a>

ファイルメタデータは、通常、ファイルが消費するストレージ容量の 3～7% を消費します。この割合は、平均ファイルサイズ (平均ファイルサイズが小さいほど多くのメタデータが必要になります) と、ファイルのストレージ効率化で、どれだけ節約できるかによって異なります。ファイルメタデータはストレージ効率化による節約の恩恵を受けないことに注意してください。ファイルシステム上のメタデータに使用される SSD ストレージの容量を見積もるには、次のガイドラインが使用できます。


| 平均ファイルサイズ | ファイルデータに対する、メタデータサイズの割合 | 
| --- | --- | 
|  4 KB  |  7%  | 
|  8 KB  |  3.5%  | 
|  32 KB 以上  |  1～3%  | 

容量プール階層に保存する予定のファイルのメタデータに必要な SSD ストレージ容量をサイジングする際には、容量プール階層に保存する予定のデータ 10 GiB ごとに 1 GiB の SSD ストレージという控えめな比率を使用することをお勧めします。

#### SSD 階層に保存されているファイルデータ
<a name="file-data-on-ssd-tier"></a>

アクティブなデータセットとすべてのファイルメタデータに加えて、ファイルシステムに書き込まれたすべてのデータは、容量プールストレージに階層化される前に、最初に SSD 階層に書き込まれます。これは、**[すべて]** のデータ階層化ポリシーが設定されたボリュームで SnapMirror を使用する場合に、データがキャパシティプールに直接書き込まれた場合を除いて、ボリュームの階層化ポリシーに関係なく当てはまります。

容量プール階層からのランダムリードは、SSD 階層の使用率が 90% 未満であれば、SSD 階層にキャッシュされます。詳細については、「[ボリュームデータの階層化](volume-storage-capacity.md#volume-data-tiering)」を参照してください。

### SSD 容量の推奨使用率
<a name="ssd-utilization"></a>

SSD 層の使用率が継続的に 80% を超えないようにすることをお勧めします。第 2 世代のファイルシステムでは、ファイルシステムのアグリゲートの使用率が継続的に 80% を超えないようにすることをお勧めします。これらの推奨事項は、NetApp の ONTAP に関する推奨事項と整合性があります。ファイルシステムの SSD 階層は、容量プール階層への書き込みのステージングや容量プール階層からのランダムリードにも使用されるため、アクセスパターンが突然変化すると、SSD 階層の使用率がすぐに上昇する可能性があります。

SSD の使用率が 90% になると、容量プール階層から読み取られたデータは SSD 階層にキャッシュされなくなるため、残りの SSD 容量はファイルシステムに書き込まれる新しいデータ用に保持されます。これにより、容量プール階層から同じデータを繰り返し読み込むと、SSD 階層からキャッシュされて読み取られるのではなく、容量プールストレージから読み取られるようになり、ファイルシステムのスループットキャパシティに影響する可能性があります。

SSD 階層の使用率が 98% 以上になると、すべての階層化機能が停止します。詳細については、「[階層化のしきい値](volume-storage-capacity.md#storage-tiering-thresholds)」を参照してください。

### ストレージ効率
<a name="storage-efficiency"></a>

NetApp ONTAP は、圧縮、コンパクト化、重複排除などのブロックレベルストレージ効率機能をボリュームレベルで提供します。これらの機能により、パフォーマンスを低下させることなく、一般的なファイル共有のストレージ容量を最大 65% 削減できます。ボリュームごとにストレージ効率を有効にできます。これらの機能により、データが消費するストレージ容量が削減され、SSD、容量プール、およびバックアップストレージで消費されるストレージ領域を減らすことができます。SSD ストレージ内のデータに対して、各ボリュームで圧縮と重複排除を有効にできます。SSD ストレージの圧縮と重複排除によるストレージの節約は、データがキ容量プールストレージに階層化されている場合に維持されます。ファイルシステムのストレージ効率設定に関係なく、バックアップデータに対してストレージ効率は常に有効になります。

次の表は、一般的なストレージ節約の例を示しています。


|  | 圧縮のみ | 重複排除のみ | 圧縮と重複排除 | 
| --- | --- | --- | --- | 
| 汎用ファイル共有 | 50% | 30% | 65% | 
| 仮想サーバーとデスクトップ | 55% | 70% | 70% | 
| データベース | 65～70% | 0% | 65～70% | 
| データエンジニアリング | 55% | 30% | 75% | 
| 地理地震データ | 40% | 3% | 40% | 

ほとんどのワークロードでは、圧縮と重複排除を有効にしても、ファイルシステムのパフォーマンスに悪影響を及ぼしません。ほとんどのワークロードでは、圧縮により全体的なパフォーマンスが向上します。FSx for ONTAP ファイルサーバーは、RAM キャッシュからの高速な読み取りと書き込みを実現するために、ファイルサーバーとストレージディスク間で利用可能なものよりも高いレベルのネットワーク帯域幅をフロントエンドネットワークインターフェイスカード (NIC) に搭載しています。データ圧縮はファイルサーバーとストレージディスク間で送信されるデータ量を減らすため、ほとんどのワークロードでは、データ圧縮を使用するとファイルシステム全体のスループットキャパシティが増加します。データ圧縮に関連するスループットキャパシティの増加は、ファイルシステムのフロントエンド NIC を飽和させると制限されます。

Amazon FSx for NetApp ONTAP は、スナップショット、シンプロビジョニング、FlexClone ボリュームなど、容量を節約する他の ONTAP 機能もサポートしています。

ストレージ効率の機能はデフォルトでは有効になっていません。以下の手順で、有効にできます。
+ [ファイルシステムを作成する](creating-file-systems.md) 場合、SVM のルートボリュームで。
+ [新しいボリュームを作成する](creating-volumes.md) 場合。
+ [既存のボリュームを変更する](updating-volumes.md) 場合。

ストレージ効率が有効になっているファイルシステムのストレージ節約量を確認するには、「[ストレージ効率節約のモニタリング](view-storage-efficiency.md)」を参照してください。

#### ストレージ効率節約の計算
<a name="storage-efficiency-calculation"></a>

`LogicalDataStored` や `StorageUsed` FSx for ONTAP CloudWatch ファイルシステムメトリクスを使用して、圧縮、重複排除、圧縮、スナップショット、FlexClones によるストレージの節約量を計算できます。これらのメトリクスのディメンションは 1 つで、`FileSystemId` です。詳細については、「[ファイルシステムのメトリクス](file-system-metrics.md)」を参照してください。
+ ストレージ効率の節約をバイト単位でコンピューティングするには、特定の期間の `StorageUsed` の平均を取得し、同じ期間の `LogicalDataStored` の平均から減算します。
+ 合計論理的なデータサイズのパーセンテージとしてストレージ効率の節約をコンピューティングするには、特定の期間の `StorageUsed` の `Average` を取得し、同じ期間の `LogicalDataStored` の `Average` から減算します。次に、同じ期間の `LogicalDataStored` の `Average` で差を割ります。

#### SSD のサイジングの例
<a name="sizing-ssd-example"></a>

データのうち 80% へのアクセス頻度が低いアプリケーション用に 100 TiB のデータを保存するとします。このシナリオでは、データの 80% (80 TiB) が自動的に容量プール階層に階層化され、残りの 20% (20 TiB) は SSD ストレージに残ります。汎用のファイル共有ワークロードで、65% という一般的なストレージ効率の節約に基づいた場合、7 TiB のデータ量に相当します。SSD の使用率を 80% に維持するには、20 TiB のアクティブアクセスデータに対して 8.75 TiB の SSD ストレージ容量が必要です。次の計算に示すように、プロビジョニングする SSD ストレージの量も ONTAP ソフトウェアのストレージオーバーヘッドの 16% を考慮する必要があります。

```
ssdNeeded = ssdProvisioned * (1 - 0.16)
8.75 TiB / 0.84 = ssdProvisioned
10.42 TiB = ssdProvisioned
```

そのため、この例では、少なくとも 10.42 TiB の SSD ストレージをプロビジョニングする必要があります。また、アクセス頻度の低い残りの 80 TiB のデータには、28 TiB の容量プールストレージを使用します。