

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

# Amazon FSx for Lustre のパフォーマンス
<a name="performance"></a>

本章では、Amazon FSx for Lustre のパフォーマンスに関するトピックを紹介し、ファイルシステムのパフォーマンスを最大化するための重要なヒントおよび推奨事項を提示します。

**Topics**
+ [概要:](#performance-overview)
+ [FSx for Lustre のファイルシステム用のしくみ](#how-lustre-fs-work)
+ [ファイルシステムのメタデータパフォーマンス](#dne-metadata-performance)
+ [個々のクライアントインスタンスへのスループット](#throughput-clients)
+ [ファイルシステムストレージレイアウト](#storage-layout)
+ [ファイルシステム内のデータのストライピング](#striping-data)
+ [パフォーマンスと使用状況のモニタリング](#performance-monitoring)
+ [SSD および HDD ストレージクラスのパフォーマンス特性](ssd-storage.md)
+ [インテリジェント階層化 ストレージクラスのパフォーマンス特性](intelligent-tiering-file-systems.md)
+ [パフォーマンスのヒント](performance-tips.md)

## 概要:
<a name="performance-overview"></a>

Amazon FSx for Lustre は、一般的な高性能ファイルシステムである Lustre をベースに構築されており、ファイルシステムのサイズに応じて直線的に増加するスケールアウトパフォーマンスを提供します。Lustre ファイルシステムは複数のファイルサーバーとディスクをまたいで水平にスケールします。このスケーリングにより、各クライアントは各ディスクに保存されているデータに直接アクセスして、従来のファイルシステムに存在するボトルネックの多くを取り除くことができます。Amazon FSx for Lustre は、Lustre のスケーラブルなアーキテクチャに基づいて構築され、多数のクライアントで高いレベルのパフォーマンスをサポートします。

## FSx for Lustre のファイルシステム用のしくみ
<a name="how-lustre-fs-work"></a>

各 FSx for Lustre ファイルシステムは、クライアントが通信するファイルサーバと、データを格納する各ファイルサーバに接続されたディスクのセットで設定されます。各ファイルサーバは、高速のインメモリキャッシュを使用して、最も頻繁にアクセスされるデータのパフォーマンスを向上させます。ストレージクラスに応じて、ファイルサーバーにはオプションの SSD 読み取りキャッシュをプロビジョニングできます。クライアントがメモリ内キャッシュまたは SSD キャッシュに格納されているデータにアクセスする場合、ファイルサーバーはディスクから読み取る必要がないため、レイテンシーが減少し、ドライブ可能なスループットの合計量が増加します。次の図表は、書き込み操作、ディスクから実行される読み取り操作、およびインメモリまたは SSD キャッシュから実行される読み取り操作のパスを示しています。

![\[FSx for Lustre パフォーマンスアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/fsx/latest/LustreGuide/images/LustrePerfDiagram.png)


 ファイルサーバーのインメモリまたは SSD キャッシュに保存されているデータを読み取る場合、ファイルシステムのパフォーマンスはネットワークスループットによって決まります。ファイルシステムにデータを書き込むとき、またはインメモリキャッシュに保存されていないデータを読み取る場合、ファイルシステムのパフォーマンスは、ネットワークスループットとディスクスループットの低い方によって決まります。

SSD および HDD ストレージクラスのネットワークスループット、ディスクスループット、および IOPS の特性の詳細については、「[SSD および HDD ストレージクラスのパフォーマンス特性](ssd-storage.md)」および「[インテリジェント階層化 ストレージクラスのパフォーマンス特性](intelligent-tiering-file-systems.md)」を参照してください。

## ファイルシステムのメタデータパフォーマンス
<a name="dne-metadata-performance"></a>

ファイルシステムメタデータ IO オペレーション (IOPS) は、1 秒あたりに作成、一覧表示、読み取り、削除できるファイルとディレクトリの数を決定します。

永続 2 ファイルシステムでは、ストレージ容量とは独立してメタデータ IOPS をプロビジョニングできるほか、クライアントインスタンスがファイルシステム上で生成しているメタデータ IOPS の数および種類をより詳細に把握することが可能です。SSD ファイルシステムでは、メタデータ IOPS は、プロビジョニングしたストレージ容量に基づいて自動的にプロビジョニングされます。インテリジェント階層化ストレージクラスのファイルシステムはは、自動モードをサポートしていません。

FSx for Lustre の 永続 2 ファイルシステムでは、プロビジョニングしたメタデータ IOPS の数およびメタデータ操作の種類によって、ファイルシステムがサポートできるメタデータ操作の速度が決まります。プロビジョニングするメタデータ IOPS のレベルによって、ファイルシステムのメタデータディスクにプロビジョニングされる IOPS の数が決まります。


| 操作タイプ | プロビジョニングされたメタデータ IOPS ごとに 1 秒あたりに駆動できるオペレーション  | 
| --- | --- | 
|  ファイルの作成、開く、閉じる  |  2  | 
|  ファイルの削除  |  1  | 
|  ディレクトリの作成、名前の変更  |  0.1  | 
|  ディレクトリの削除  |  0.2  | 

SSD ファイルシステムでは、自動モードにより、メタデータ IOPS のプロビジョニングを行うことができます。自動モードでは、Amazon FSx は、次の表に従ってファイルシステムのストレージ容量に基づいてメタデータ IOPS を自動的にプロビジョニングします。


| ファイルシステムのストレージ容量 | 自動モードでのメタデータ IOPS を含む | 
| --- | --- | 
|  1200 GiB  |  1500  | 
|  2400 GiB  |  3000  | 
|  4800～9600 GiB  |  6000  | 
|  12000～45600 GiB  |  12000  | 
|  48,000 GiB 以上  |  24000 GiB あたり 12000 IOPS  | 

ユーザープロビジョニングモードでは、オプションでプロビジョニングするメタデータ IOPS の数を指定できます。有効な値は次のとおりです。
+ SSD ファイルシステムでは、有効な値は、`1500`、`3000`、`6000`、`12000`、および `192000` までの `12000` の倍数です。
+ インテリジェント階層化ファイルシステムの場合、有効な値は `6000` と `12000` です。

メタデータ IOPS を設定する方法については、「[メタデータパフォーマンスの管理](managing-metadata-performance.md)」を参照してください。ファイルシステムのデフォルトのメタデータ IOPS 数を超えてプロビジョニングしたメタデータ IOPS については、別途料金が発生することにご留意ください。

## 個々のクライアントインスタンスへのスループット
<a name="throughput-clients"></a>

スループットキャパシティが 10 GBps を超えるファイルシステムを作成する場合は、Elastic Fabric Adapter (EFA) を有効にして、クライアントインスタンスあたりのスループットを最適化することをお勧めします。クライアントインスタンスごとのスループットをさらに最適化するために、EFA 対応のファイルシステムでは、EFA 対応の NVIDIA GPU 搭載クライアントインスタンス向けの GPUDirect Storage および ENA Express 対応クライアントインスタンス向けの ENA Express もサポートされています。

単一のクライアントインスタンスに対して得られるスループットは、選択したファイルシステムの種類およびクライアントインスタンスのネットワークインターフェイスに依存します。


| ファイルシステムタイプ | クライアントインスタンスのネットワークインターフェイス | クライアントあたりの最大スループット、Gbps | 
| --- | --- | --- | 
|  EFA 非対応  |  いずれか  |  100 Gbps\$1  | 
|  EFA 対応  |  ENA  |  100 Gbps\$1  | 
|  EFA 対応  |  ENA Express  |  100 Gbps  | 
|  EFA 対応  |  EFA  |  700 Gbps  | 
|  EFA 対応  |  GDS を使用した EFA  |  1200 Gbps  | 

**注記**  
\$1 個々のクライアントインスタンスと個々の FSx for Lustre オブジェクトストレージサーバー間のトラフィックは 5 Gbps に制限されています。FSx for Lustre ファイルシステムを支えるオブジェクトストレージサーバーの数については、「[ファイルシステムの IP アドレス](using-fsx-lustre.md#ip-addesses-for-fs)」を参照してください。

## ファイルシステムストレージレイアウト
<a name="storage-layout"></a>

Lustre のすべてのファイルデータは、*オブジェクトストレージターゲット* (OST) と呼ばれるストレージボリュームに格納されます。すべてのファイルメタデータ (ファイル名、タイムスタンプ、アクセス許可などを含む) は、メタデータターゲット (MDT) と呼ばれるストレージボリュームに保存されます。Amazon FSx for Lustre ファイルシステムは、1 つ以上の MDT と複数の OST で設定されます。Amazon FSx for Lustre は、ストレージ容量とスループットと IOPS 負荷のバランスをとるために、ファイルシステムを設定する OST にファイルデータを分散します。

ファイルシステムを設定する MDT および OST のストレージ使用状況を表示するには、ファイルシステムがマウントされているクライアントから次のコマンドを実行します。

```
lfs df -h mount/path
```

このコマンドの出力は以下のようになります。

**Example**  

```
UUID                             bytes       Used   Available Use% Mounted on
mountname-MDT0000_UUID           68.7G       5.4M       68.7G   0% /fsx[MDT:0]
mountname-OST0000_UUID            1.1T       4.5M        1.1T   0% /fsx[OST:0]
mountname-OST0001_UUID            1.1T       4.5M        1.1T   0% /fsx[OST:1]

filesystem_summary:               2.2T       9.0M        2.2T   0% /fsx
```

## ファイルシステム内のデータのストライピング
<a name="striping-data"></a>

ファイルストライピングにより、ファイルシステムのスループットパフォーマンスを最適化できます。Amazon FSx for Lustre は、データがすべてのストレージサーバーから確実に提供されるように、OST 間で自動的にファイルを分散します。複数の OST にまたがるファイルのストライピング方法を設定することで、同じ概念をファイルレベルで適用できます。

ストライピングとは、ファイルを複数のチャンクに分割して、異なる OST に格納できることを意味します。ファイルが複数の OST にストライプされると、ファイルへの読み取りまたは書き込みリクエストがそれらの OST にまたがって分散され、アプリケーションがそれを介して処理できる総スループットまたは IOPS が向上します。



Amazon FSx for Lustre ファイルシステムのデフォルトのレイアウトを次に示します。
+ 2020 年 12 月 18 日より前に作成されたファイルシステムでは、デフォルトのレイアウトでストライプカウントが 1 に指定されています。つまり、異なるレイアウトを指定しない限り、標準の Linux ツールを使用して Amazon FSx for Lustre で作成された各ファイルは 1 つのディスクに格納されます。
+ 2020 年 12 月 18 日以降に作成されたファイルシステムのデフォルトレイアウトは、プログレッシブファイルレイアウトであり、サイズが 1 GiB 未満のファイルは 1 つのストライプに保存され、大きいファイルにはストライプカウント 5 が割り当てられます。
+ 2023 年 8 月 25 日以降に作成されたファイルシステムのデフォルトレイアウトは、[プログレッシブファイルのレイアウト](#striping-pfl) で説明されている 4 コンポーネントのプログレッシブファイルレイアウトです。
+ すべてのファイルシステムでは、作成日に関係なく、Amazon S3 からインポートされたファイルはデフォルトのレイアウトを使用せずに、ファイルシステムの `ImportedFileChunkSize` パラメータにあるレイアウトを使用します。`ImportedFileChunkSize` より大きい S3 インポートされたファイルは、`(FileSize / ImportedFileChunksize) + 1` のストライプカウントで複数の OST に格納されます。`ImportedFileChunkSize` のデフォルト値は 1 GiB です。

`lfs getstripe` コマンドを使用してファイルまたはディレクトリのレイアウト設定を表示できます。

```
lfs getstripe path/to/filename
```

このコマンドは、ファイルのストライプカウント、ストライプサイズ、およびストライプオフセットを報告します。ストライプカウントは、ファイルがストライプされている OST の数です。ストライプサイズは、OST に保存されている連続データの量です。ストライプオフセットは、ファイルがストライプされる最初の OST のインデックスです。

### ストライピング設定の変更
<a name="striping-modify"></a>

ファイルのレイアウトパラメータは、ファイルが最初に作成されたときに設定されます。`lfs setstripe` コマンドを使用すると、指定したレイアウトで新しい空のファイルを作成します。

```
lfs setstripe filename --stripe-count number_of_OSTs
```

`lfs setstripe` コマンドは、新しいファイルのレイアウトにのみ影響します。これを使用して、ファイルを作成する前にファイルのレイアウトを指定します。ディレクトリのレイアウトを定義することもできます。ディレクトリに設定されると、そのレイアウトはそのディレクトリに追加されたすべての新しいファイルに適用されますが、既存のファイルには適用されません。作成した新しいサブディレクトリも新しいレイアウトを継承し、そのサブディレクトリ内に作成した新しいファイルまたはディレクトリに適用されます。

既存のファイルのレイアウトを変更するには、`lfs migrate` コマンドを使用します。このコマンドは、必要に応じてファイルをコピーし、コマンドで指定したレイアウトに従ってコンテンツを配信します。例えば、ファイルに追加されたファイルやサイズが増加しても、ストライプカウントは変更されないため、ファイルのレイアウトを変更するにはそれらを移行する必要があります。または、`lfs setstripe` コマンドを使用して、レイアウトを指定し、元のコンテンツを新しいファイルにコピーし、新しいファイルの名前を変更して元のファイルと置き換えます。

デフォルトのレイアウト設定がワークロードに最適ではない場合があります。例えば、数十個の OST と多数のマルチギガバイトファイルがあるファイルシステムでは、デフォルトのストライプカウント値である 5 OST を超えるファイルをストライピングすることで、パフォーマンスが向上します。ストライプカウントの少ない大きなファイルを作成すると、I/O パフォーマンスのボトルネックが発生し、OST がいっぱいになる可能性もあります。この場合、ファイルのストライプカウントが多いディレクトリを作成できます。

大きなファイル (特にサイズが 1 ギガバイトを超えるファイル) のストライプレイアウトを設定することは、次の理由で重要です。
+ 大きなファイルの読み取りと書き込み時に、複数の OST とその関連サーバーが IOPS、ネットワーク帯域幅、および CPU リソースを提供できるようにすることで、スループットが向上します。
+ OST の小さなサブセットが全体的なワークロードパフォーマンスを制限するホットスポットになる可能性を低減します。
+ 1 つの大きなファイルが OST を埋め尽くし、ディスクフルエラーを引き起こす可能性を防ぎます。

すべてのユースケースに単一の最適なレイアウト設定はありません。ファイルレイアウトに関する詳細なガイダンスについては、「Lustre.org ドキュメント」の「[ファイルレイアウト (ストライピング) と空き領域の管理](https://doc.lustre.org/lustre_manual.xhtml#managingstripingfreespace)」を参照してください。一般的なガイドラインを次に示します。
+ ストライプのレイアウトは、大きなファイル、特にファイルのサイズが数百メガバイト以上のユースケースで最も重要です。このため、新しいファイルシステムのデフォルトのレイアウトでは、サイズが 1 GiB を超えるファイルに対してストライプカウント 5 が割り当てられます。
+ ストライプカウントは、大きなファイルをサポートするシステム用に調整する必要があるレイアウトパラメータです。ストライプカウントは、ストライプファイルのチャンクを保持する OST ボリュームの数を指定します。例えば、ストライプ数が 2、ストライプサイズが 1 MiB の場合、Lustre はファイルの代替の 1 MiB チャンクを 2 つの OST のそれぞれに書き込みます。
+ 有効なストライプカウントは、実際の OST ボリュームの数と指定したストライプカウント値のうち小さい方です。特別なストライプカウント値の `-1` を使用できます。これは、ストライプをすべての OST ボリュームに配置する必要があることを示します。
+ 特定の操作では、ファイルが小さすぎてすべての OST ボリュームの容量を消費できない場合でも、Lustre はレイアウト内のすべての OST へのネットワークラウンドトリップを必要とするため、小さなファイルに対して大きなストライプカウントを設定することは最適ではありません。
+ プログレッシブファイルレイアウト (PFL) を設定して、ファイルのレイアウトをサイズに応じて変更することができます。PFL 設定では、各ファイルに対して明示的に設定しなくても、大小のファイルを組み合わせたファイルシステムの管理を簡素化できます。詳細については、「[プログレッシブファイルのレイアウト](#striping-pfl)」を参照してください。
+ ストライプサイズは、デフォルトで 1 MiB です。ストライプオフセットを設定すると、特殊な状況では便利ですが、通常は指定しないままにしておき、デフォルトを使用するのが最善です。

### プログレッシブファイルのレイアウト
<a name="striping-pfl"></a>

ディレクトリのプログレッシブファイルレイアウト (PFL) 設定を指定して、小さなファイルと大きなファイルに対して異なるストライプ設定を指定してから、それを入力できます。例えば、データが新しいファイルシステムに書き込まれる前に、最上位ディレクトリに PFL を設定できます。

PFL 設定を指定するには、`lfs setstripe` コマンドで `-E` オプションを使用して、以下のコマンドのように、異なるサイズのファイルのレイアウトコンポーネントを指定します。

```
lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname/directory
```

このコマンドは、4 つのレイアウトコンポーネントを設定します。
+ 最初のコンポーネント (`-E 100M -c 1`) は、最大 100 MiB のファイルのストライプカウント値 1 を示します。
+ 2 番目のコンポーネント (`-E 10G -c 8`) は、サイズが 10 GiB までのファイルのストライプカウントを 8 であることを示します。
+ 3 番目のコンポーネント (`-E 100G -c 16`) は、サイズが 100 GiB までのファイルのストライプカウントを 16 であることを示します。
+ 4 番目の要素 (`-E -1 -c 32`) は、100 GiB を超えるファイルのストライプカウントが 32 であることを示しています。

**重要**  
PFL レイアウトで作成されたファイルにデータを追加すると、そのレイアウトコンポーネントがすべて入力されます。例えば、上記の 4 コンポーネントコマンドで、1 MiB のファイルを作成し、その末尾にデータを追加すると、ファイルのレイアウトが展開され、ストライプカウントが -1 になります。これは、システム内のすべての OST を指します。これは、データがすべての OST に書き込まれるという意味ではありませんが、ファイル長の読み取りなどのオペレーションは、すべての OST に並行してリクエストを送信し、ファイルシステムに大きなネットワークロードを追加します。  
したがって、その後にデータを追加できる小またはミディアムの長さのファイルのストライプカウントを制限するように注意してください。通常、ログファイルは新しいレコードを追加することで増加するため、Amazon FSx for Lustre では、親ディレクトリで指定されたデフォルトのストライプ設定に関係なく、追加モードで作成されたファイルに、デフォルトのストライプカウント 1 が割り当てられます。

2023 年 8 月 25 日以降に作成された Amazon FSx for Lustre ファイルシステムのデフォルトの PFL 設定は、次のコマンドを実行して設定します。

```
lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname
```

中～大規模ファイルへの同時アクセスが多いワークロードを持つお客様は、前述の 4 つのコンポーネントのレイアウト例で示したように、ファイルサイズが小さい場合はストライプカウントが多いレイアウトを使用し、ファイルサイズが最大の場合はすべての OST にまたがるストライピングのレイアウトを使用することでメリットが得られます。

## パフォーマンスと使用状況のモニタリング
<a name="performance-monitoring"></a>

Amazon FSx for Lustre は 1 分ごとに、各ディスク (MDT および OST) の使用状況メトリクスを Amazon CloudWatch に発行します。

ファイルシステムの総使用状況の詳細を表示するには、各メトリクスの Sum 統計を調べます。例えば、`DataReadBytes` 統計は、ファイルシステム内のすべての OST で見られる総読み取りスループットを報告します。同様に、`FreeDataStorageCapacity` 統計は、ファイルシステム内のファイルデータに使用可能なストレージ容量の合計を報告します。

ファイルシステムのパフォーマンスのモニタリングの詳細については、「[Amazon FSx for Lustre ファイルシステムのモニタリング](monitoring_overview.md)」を参照してください。

# SSD および HDD ストレージクラスのパフォーマンス特性
<a name="ssd-storage"></a>

SSD または HDD ストレージクラスを持つ FSx for Lustre ファイルシステムがサポートするスループットは、そのストレージ容量に比例します。Amazon FSx for Lustre ファイルシステムでは、数 TBps のスループット とと数百万の IOPS に拡張できます。Amazon FSx for Lustre では、何千ものコンピュートインスタンスから同じファイルまたはディレクトリへの同時アクセスもサポートしています。このアクセスにより、ハイパフォーマンスコンピューティング (HPC) で一般的な手法であるアプリケーションメモリからストレージへの迅速なデータチェックポイントが可能になります。ファイルシステムを作成した後、いつでも必要なときにスループットキャパシティとスループットキャパシティを増やすことができます。詳細については、「[ストレージ容量の管理](managing-storage-capacity.md)」を参照してください。

FSx for Lustre ファイルシステムは、ネットワーク I/O クレジットメカニズムを使用してバースト読み取りスループットの値を提供し、平均帯域幅使用率に基づいて、ネットワーク帯域幅を割り当てます。インスタンスでは、帯域幅がベースライン帯域幅を下回るとクレジットを獲得し、クレジットをネットワークデータ転送を実行するときに使用できます。

以下の表は、SSD および HDD ストレージクラスを使用した FSx for Lustre の展開オプションが想定して設計されたパフォーマンスを示しています。


**SSD ストレージオプションのファイルシステムパフォーマンス**  

| デプロイタイプ | **ネットワークスループット (MBps/TiB のプロビジョニングされたストレージ)** |  **ネットワーク IOPS (プロビジョニングされたストレージの IOPS / TiB)** |  **キャッシュストレージ (GiB の RAM / TiB のストレージのプロビジョニング)** |  **ファイルオペレーションあたりのディスクレイテンシー (ミリ秒、P50)** | **ディスクスループット (MBps/TiB、プロビジョニングされたストレージまたは SSD キャッシュ)** | 
| --- |--- |--- |--- |--- |--- |
| **** | **[Baseline]** (ベースライン) | **[Burst]** (バースト) | **** | **** | **** | **[Baseline]** (ベースライン) | **バースト** | 
| --- |--- |--- |--- |--- |--- |--- |--- |
| SCRATCH\$12 | 200 | 1300 | 数万規模のベースライン数十万規模のバースト | 6.7 |  メタデータ: sub-ms データ: sub-ms  |  200 (読み取り) 100 (書き込み)  | ‐ | 
| --- |--- |--- |--- |--- |--- |--- |--- |
| PERSISTENT-125 | 320 | 1300 | 3.4 |  125  | 500 | 
| --- |--- |--- |--- |--- |--- |
| PERSISTENT-250 | 640 | 1300 | 6.8 |  250  | 500 | 
| --- |--- |--- |--- |--- |--- |
| PERSISTENT-500 | 1300 | ‐ | 13.7 | 500 | ‐ | 
| --- |--- |--- |--- |--- |--- |
| PERSISTENT-1000 | 2600 | ‐ | 27.3 | 1000 | ‐ | 
| --- |--- |--- |--- |--- |--- |


**HDD ストレージオプションのファイルシステムパフォーマンス**  

| デプロイタイプ | **ネットワークスループット (MBps/TiB のストレージまたは SSD キャッシュのプロビジョニング)** |  **ネットワーク IOPS (プロビジョニングされたストレージの IOPS / TiB)** | **キャッシュストレージ (GiB の RAM / TiB のストレージのプロビジョニング)** | **ファイルオペレーションあたりのディスクレイテンシー (ミリ秒、P50)** | **ディスクスループット (MBps/TiB、プロビジョニングされたストレージまたは SSD キャッシュ)** | 
| --- |--- |--- |--- |--- |--- |
| **** | **[Baseline]** (ベースライン) | **[Burst]** (バースト) |  | **[Baseline]** (ベースライン) | **バースト** | 
| --- |--- |--- |--- |--- |--- |
| PERSISTENT-12 | 
| --- |
| HDD ストレージ | 40 | 375\$1  |  数万規模のベースライン 数十万規模のバースト  | 0.4 memory |  メタデータ: sub-ms データ: 一桁ミリ秒  | 12 |  80 (読み取り) 50 (書き込み)  | 
| --- |--- |--- |--- |--- |--- |--- |--- |
| SSD キャッシュの読み取り |  200  | 1,900 |  200 SSD キャッシュ  |  データ: sub-ms  | 200 |  -  | 
| --- |--- |--- |--- |--- |--- |--- |
|  PERSISTENT-40 | 
| --- |
| HDD ストレージ | 150 | 1,300\$1  |  数万規模のベースライン 数十万規模のバースト  | 1.5 |  メタデータ: sub-ms データ: 一桁ミリ秒  | 40 |  250 (読み取り) 150 (書き込み)  | 
| --- |--- |--- |--- |--- |--- |--- |--- |
| SSD キャッシュの読み取り |  750  |  6500  | 200 SSD cache |  データ: sub-ms  | 200 |  -  | 
| --- |--- |--- |--- |--- |--- |--- |


**旧世代の SSD ストレージオプションのファイルシステムパフォーマンス**  

| デプロイタイプ | **ネットワークスループット (プロビジョニングされたストレージの TiB あたり MBps**) |  **ネットワーク IOPS (プロビジョニングされたストレージの TiB あたりの IOPS)** |  **キャッシュストレージ (プロビジョニングされたストレージの TiB あたり GiB)** |  **ファイルオペレーションあたりのディスクレイテンシー (ミリ秒、P50)** | **ディスクスループット (プロビジョニングされたストレージまたは SSD キャッシュの TiB あたり MBps)** | 
| --- |--- |--- |--- |--- |--- |
| **** | **[Baseline]** (ベースライン) | **[Burst]** (バースト) | **** | **** | **** | **[Baseline]** (ベースライン) | **[Burst]** (バースト) | 
| --- |--- |--- |--- |--- |--- |--- |--- |
| PERSISTENT-50 | 250 | 1,300\$1 | 数万規模のベースライン数十万規模のバースト | 2.2 RAM |  メタデータ: sub-ms データ: sub-ms  | 50 | 240 | 
| --- |--- |--- |--- |--- |--- |--- |--- |
| PERSISTENT-100 | 500 | 1,300\$1 | 4.4 RAM | 100 | 240 | 
| --- |--- |--- |--- |--- |--- |
| PERSISTENT-200 | 750 | 1,300\$1 | 8.8 RAM | 200 | 240 | 
| --- |--- |--- |--- |--- |--- |

**注記**  
\$1 以下の永続的ファイルシステムは、ストレージの 1 TiB あたり最大 530 MBps のネットワークバースト AWS リージョン を提供します。アフリカ (ケープタウン）、アジアパシフィック (香港）、アジアパシフィック (大阪）、アジアパシフィック (シンガポール）、カナダ (中部）、欧州 (フランクフルト）、欧州 (ロンドン）、欧州 (ミラノ）、欧州 (ストックホルム）、中東 (バーレーン）、南米 (サンパウロ）、中国、米国西部 (ロサンゼルス）。

## 例: ベースラインとバーストスループットの集計
<a name="example-persistant-throughput"></a>

次の例は、ストレージ容量とディスクスループットがファイルシステムのパフォーマンスに与える影響を示しています。

ストレージ容量が 4.8 TiB、ストレージ単位あたりのスループットが 1 TiB あたり 50 MBps の永続型ファイルシステムでは、合計ベースラインディスクスループットが 240 MBps、バーストディスクスループットが 1.152 GBps となります。

ファイルシステムのサイズについては、Amazon FSx for Lustre は、ファイルオペレーションに対して一貫したミリ秒未満のレイテンシーを提供します。

# インテリジェント階層化 ストレージクラスのパフォーマンス特性
<a name="intelligent-tiering-file-systems"></a>

FSx for Lustre のインテリジェント階層化ストレージクラスは、従来 HDD ベースまたは HDD/SSD 混在型の高性能ファイルストレージファイルシステムで実行されるワークロード向けに、弾力性がありコスト最適化されたストレージを提供します。インテリジェント階層化ストレージクラスを使用するファイルシステムは、完全に弾力性のある、インテリジェントに階層化されたリージョナルストレージを利用しており、ワークロードの変化に応じて自動的に容量が増減します。データの階層化方法については、「[インテリジェント階層化ストレージクラスがデータを階層化する方法](using-fsx-lustre.md#how-INT-tiering-works)」を参照してください。

インテリジェント階層化ストレージクラスを使用する FSx for Lustre ファイルシステムがサポートするスループットは、ストレージ容量に依存しません。インテリジェント階層化ファイルシステムは、複数 TBps のスループットおよび数百万の IOPS までスケール可能です。インテリジェント階層化ストレージクラスを使用するファイルシステムは、頻繁にアクセスされるデータへの低レイテンシアクセスのために、オプションとしてプロビジョニングされた SSD 読み取りキャッシュも提供します。デフォルトでは、Amazon FSx for Lustre は頻繁にアクセスされるメタデータ用に SSD 読み取りキャッシュをプロビジョニングします。ほとんどのワークロードは読み込み量が多く、データセット全体の小さなサブセットのみと常にアクティブに連携する傾向があるため、Intelligent-Tiering ストレージクラスを使用するファイルシステムで Intelligent-Tiering ストレージと SSD リードキャッシュのハイブリッドモデルを使用することで、ほとんどのワークロードに対して SSD ファイルシステムに相当するレベルで実行されるストレージを提供しつつ、SSD および HDD ストレージクラスよりもストレージコストを削減できます。

Intelligent-Tiering ファイルシステムへのデータの読み取りと書き込み、特に最近または頻繁にアクセスされていないことでファイルサーバーのインメモリキャッシュに存在していないデータの場合、パフォーマンスは SSD 読み取りキャッシュのサイズによって異なります。Intelligent-Tiering ストレージからのデータアクセスでは、time-to-first-byte レイテンシーが約数十ミリ秒、リクエストあたりのコストがかかります。一方、SSD リードキャッシュからのアクセスでは、ミリ秒未満のレイテンシーとなり、リクエストあたりのコストなしで返されます。

ファイルシステムの SSD 読み取りキャッシュのサイズを設定するときは、ワークロード内のアクセス頻度の高いデータセットのサイズと、アクセス頻度の低いデータの読み取りに対するワークロードの高いレイテンシーの感度の両方を考慮する必要があります。ファイルシステムの作成後に SSD 読み取りキャッシュのサイズ設定モード間を切り替えて、キャッシュをスケールアップまたはスケールダウンできます。SSD 読み取りキャッシュを変更する方法の詳細については、「[プロビジョニングされた SSD 読み取りキャッシュの管理](managing-ssd-read-cache.md)」を参照してください。

FSx for Lustre がインテリジェント階層化ストレージにデータのブロックを書き込むと、書き込みリクエストが発生します。ファイルシステムへのデータ書き込み時には、書き込みリクエストが集約されてインテリジェント階層化ストレージへ書き込まれるため、スループットが向上し、リクエストコストが削減されます。読み取りは、ファイルサーバーのインメモリキャッシュ、SSD 読み取りキャッシュ、またはインテリジェント階層化ストレージから直接提供できます。インテリジェント階層化ストレージから読み取りが提供されると、取得されたデータのブロックごとに読み取りリクエストが発生します。データを順番に読み取ると、FSx for Lustre はパフォーマンスを向上させるためにデータをプリフェッチします。

インテリジェント階層化ストレージクラスを使用するファイルシステムのインメモリキャッシュからのデータは、*ネットワーク I/O* としてリクエスト元のクライアントに直接提供されます。 クライアントがインメモリキャッシュにないデータにアクセスすると、SSD リードキャッシュまたはインテリジェント階層化ストレージから*ディスク I/O* として読み取り、ネットワーク I/O としてクライアントに提供されます。

## インテリジェント階層化のファイルシステムパフォーマンス
<a name="data-access-intelligent-tiering"></a>

以下の表は、FSx for Lustre のインテリジェント階層化ストレージクラスを使用するファイルシステム向けに設計された性能を示しています。


| プロビジョンドスループットキャパシティ (MBps) | **ネットワークスループット (MBps)** |  **ネットワーク IOPS** |  **インメモリキャッシュストレージ (GB)** |  **SSD キャッシュディスクの最大スループット (MBps)** | **SSD キャッシュディスクの最大 IOPS** | 
| --- |--- |--- |--- |--- |--- |
| **** | **[Baseline]** (ベースライン) | **[Burst]** (バースト) | **** | **** | **** | **[Baseline]** (ベースライン) | **[Burst]** (バースト) | 
| --- |--- |--- |--- |--- |--- |--- |--- |
| 4000 ごと | 12500 | ‐ | 数十万 | 76.8 | 4000 | 160000 | ‐ | 
| --- |--- |--- |--- |--- |--- |--- |--- |

# パフォーマンスのヒント
<a name="performance-tips"></a>

Amazon FSx for Lustre を使用する場合は、次のパフォーマンスのヒントに留意してください。サービスの制限については、「[Amazon FSx for Lustre の Service quotas](limits.md)」を参照してください。
+ **平均 I/O サイズ** - Amazon FSx for Lustre はネットワークファイルシステムであるため、各ファイルオペレーションはクライアントと Amazon FSx for Lustre の間でラウンドトリップされるため、レイテンシーのオーバーヘッドが小さくなります。このオペレーションあたりのレイテンシーのため、通常は平均 I/O サイズの増加に応じて全体のスループットが向上します。大量のデータにオーバーヘッドが分散するためです。
+ **リクエストモデル** -ファイルシステムへの非同期書き込みを有効にすることで、保留中の書き込みオペレーションは、Amazon FSx for Lustre に非同期で書き込まれる前に、Amazon EC2 インスタンスでバッファリングされます。非同期書き込みは、通常レイテンシーが低くなります。非同期書き込みを実行するとき、カーネルはキャッシュの追加のメモリを使用します。同期書き込みを有効にしているファイルシステムは、Amazon FSx for Lustre に同期リクエストを発行します。各オペレーションはクライアントと Amazon FSx for Lustre の間のラウンドトリップを通過します。
**注記**  
選択したリクエストモデルでは、整合性 (複数の Amazon EC2 インスタンスを使用している場合) と速度にトレードオフがあります。
+ **ディレクトリサイズの制限** – 永続 2 FSx for Lustre ファイルシステムで最適なメタデータパフォーマンスを実現するには、各ディレクトリを 100K ファイル未満に制限します。ディレクトリ内のファイル数を制限すると、ファイルシステムが親ディレクトリのロックを取得するのに必要な時間が短縮されます。
+ **Amazon EC2 インスタンス** - 多数の読み取りおよび書き込みオペレーションを実行するアプリケーションは、そうでないアプリケーションよりも多くのメモリまたはコンピューティング容量ーを必要とします。コンピューティングを多用するワークロードのために Amazon EC2 インスタンスを起動するときは、アプリケーションが必要とする量のリソースを持つインスタンスタイプを選択します。Amazon FSx for Lustre ファイルシステムのパフォーマンス特性は、Amazon EBS 最適化インスタンスの使用に依存しません。
+ **最適なパフォーマンスを得るために推奨されるクライアントインスタンスの調整**

  1. メモリが 64 GiB を超えるクライアントインスタンスタイプでは、次の調整を適用することをお勧めします。

     ```
     sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000
     sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs>
     ```

  1. 64 vCPU コアを超えるクライアントインスタンスタイプでは、次の調整を適用することをお勧めします。

     ```
     echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf
     echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf
                 
     # reload all kernel modules to apply the above two settings
     sudo reboot
     ```

     クライアントをマウントした後、次の調整を適用する必要があります。

     ```
     sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32
     sudo lctl set_param mdc.*.max_rpcs_in_flight=64
     sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50
     ```

  1. ディレクトリリスト (ls) のパフォーマンスを最適化するには、次の調整を適用する必要があります。

     ```
     sudo lctl set_param llite.*.statahead_max=512
     sudo lctl set_param llite.*.statahead_agl=1
     if sudo lctl get_param llite.*.statahead_xattr > /dev/null 2>&1; then
         sudo lctl set_param llite.*.statahead_xattr=1
     else
         echo "Warning: Xattr statahead is not supported on this Lustre client. Please upgrade to the latest Lustre 2.15 client to apply this tuning"
     fi
     ```

  注: `lctl set_param` は再起動すると持続しないことが知られています。これらのパラメータはクライアント側から永続的に設定することはできないため、ブート cron ジョブを実装して、お勧めの調整を使用して設定することをお勧めします。
+ **OST 間でのワークロードバランス** - 場合によっては、ワークロードによってファイルシステムが提供できる総スループット (ストレージ TiB あたり 200 MBps) が駆動されないことがあります。その場合は、CloudWatch メトリクスを使用して、ワークロードの I/O パターンの不均衡によってパフォーマンスが影響を受けるかどうかをトラブルシューティングできます。これが原因であるかどうかを特定するには、Amazon FSx for Lustre の最大 CloudWatch メトリクスを参照してください。

  場合によっては、この統計は 240 MBps のスループット (単一の 1.2 TiB Amazon FSx for Lustre ディスクのスループットキャパシティ) 以上の負荷を示します。このような場合、ワークロードはディスク全体に均等に分散されません。この場合、`lfs setstripe` コマンドを実行して、ワークロードが頻繁にアクセスしているファイルのストライピングを変更します。最適なパフォーマンスを得るには、ファイルシステムを設定するすべての OST で、スループット要件が高いファイルをストライプ化します。

  ファイルをデータリポジトリからインポートする場合は、別の方法を使用して、高スループットファイルを OST 全体で均等にストライプできます。そのためには、次の Amazon FSx for Lustre ファイルシステムを作成するときの `ImportedFileChunkSize` パラメータを変更できます。

  例えば、ワークロードが 7.0 TiB ファイルシステム (6 x 1.17 TiB OST で設定されている) を使用し、2.4 GiB ファイル間で高いスループットを駆動する必要があるとします。この場合、`ImportedFileChunkSize` の値を `(2.4 GiB / 6 OSTs) = 400 MiB` に設定できます。これにより、ファイルがファイルシステムの OST 全体に均等に分散されます。
+ **Lustre メタデータ IOPS 用クライアント** – ファイルシステムにメタデータ設定が指定されている場合は、Amazon Linux 2023、Amazon Linux 2、Red Hat/Rocky Linux 8.9、8.10、または 9.x、CentOS 8.9 または 8.10、6.2、6.5 または 6.8 カーネルを持つ Ubuntu 22 以降、または Ubuntu 20 のいずれかの OS バージョンを持つ Lustre 2.15 クライアントまたは Lustre 2.12 クライアントをインストールすることをお勧めします。

## インテリジェント階層化 のパフォーマンスに関する考慮事項
<a name="intelligent-tiering-performance-considerations"></a>

インテリジェント階層化 ストレージクラスを使用してファイルシステムを操作する場合の重要なパフォーマンス上の考慮事項を以下に示します:
+ I/O サイズが小さいデータを読み取るワークロードは、インテリジェント階層化 ストレージ階層からのレイテンシーが高いため、I/O サイズが大きいワークロードと同じスループットを実現するために、より高い同時実行性を必要とし、より多くのリクエストコストが発生します。小さい IO サイズを使用する場合、より高い同時実行性とスループットをサポートするのに十分な大きさの SSD 読み取りキャッシュを設定することをお勧めします。
+ インテリジェント階層化ファイルシステムでクライアントが駆動できる最大ディスク IOPS は、ワークロードの特定のアクセスパターンと、SSD 読み取りキャッシュをプロビジョニングしたかどうかによって異なります。ランダムアクセスのワークロードでは、データが SSD リードキャッシュにキャッシュされている場合、クライアントは通常、データがキャッシュにない場合よりもはるかに高い IOPS を駆動できます。
+ インテリジェント階層化ストレージクラスは先行読み込みをサポートし、シーケンシャル読み込みリクエストのパフォーマンスを最適化します。データアクセスパターンを可能な限り順番に設定して、データのプリフェッチとパフォーマンスの向上を可能にすることをお勧めします。