ファイル システムのパフォーマンスに関する考慮事項

  • 7 分

HPC ワークロードを実行したことがあれば、操作、ブロック サイズ、IOPS、スループット、待機時間という用語を目にした可能性があります。 ストレージを選ぶ際に、おそらくこれらの要因を検討したことがあるでしょう。

このセクションを終了すると、これらの 5 つのパフォーマンス要因と、それらが HPC ワークロードに与える影響についての実用的な知識を獲得しているはずです。

Operations

''操作'' という用語は、ホストまたはコンピューターと、ファイル システムまたはディスクとの間のすべてのアクティビティを指します。

たとえば、オペレーティング システムとそのローカル ディスクに関する以下の操作にはなじみがあるでしょう。

  • (ファイルの) 作成
  • 削除
  • [ファイル]
  • 閉じる
  • Read
  • Write
  • Append
  • 属性の取得
  • 属性の設定
  • [名前の変更]

NFS は、ファイル クライアントとサーバー間のネットワークレベルの連携を表します。 これらの操作のいくつかは、ローカル操作に似ているように見えることに注目してください。 ただし、NFS はネットワーク API なので、これらのネットワーク操作には複数のローカル操作が含まれる場合があります。

  • create (ファイルまたはリンクの)
  • mkdir
  • readdir または readdirplus
  • getattr
  • setattr
  • lookup (ディレクトリ内の filehandle の検索)
  • link/symlink/readlink
  • read
  • rename
  • remove
  • rmdir
  • write

操作が HPC ストレージに与える影響

操作がストレージ システムに与える影響について理解することが役立ちます。 たとえば、HPC ワークロードで、入れ子になったディレクトリ構造に多数の小さなファイルが作成されたとします。 このシナリオでは、ワークロードでは、少数の大きなシーケンシャル ファイルを読み取るワークロードの場合よりも多数の操作が必要になります。

これらのアクセス パターンについては、次のユニットで説明します。 create には複数の操作が含まれるため、ワークロードで作成されるファイルが多くなるほど、パフォーマンスへの影響が大きくなります。

ブロック サイズ

ブロック サイズとは、ファイル システムによって 1 回の操作で読み取りまたは書き込みを行うことができる最小のデータ サイズ (バイト単位) を表します。

ここの目的では、ブロック サイズは、NFS クライアントとサーバー間で転送可能な NFS データ チャンク (読み取り/書き込み) のペイロード サイズも表します。

NFS サーバーとクライアントでは、ブロック サイズがネゴシエートされ、相互にサポート可能な最大サイズが受け入れられます。 既定の設定は、4 KB から 64 KB の範囲になる可能性があります。 現在構成可能な最大値は 1 MB です。 個々のデータ パケットには、設定された値を超えないペイロードを含めることができます。

クライアントでブロックサイズを明示的に構成できます。 HPC クラスター コンピューターの完全な mount ステートメントをチェックして、値を判断します。 既定のサイズが設定されます。 mount ステートメントでは値を明示的に構成しません。

NFS ブロック サイズを構成するために使用される 2 つの引数は、rsize (読み取りサイズ) と wsize (書き込みサイズ) です

小さいブロック サイズを構成している場合があります。 または選択したファイル システムの最大ブロック サイズが小さく、ワークロードが大きなファイルで構成されています。 大きなファイルが余分にチャンクされるため、パフォーマンスが低下します。

IOPS

IOPS という用語は、''1 秒あたりの入出力操作'' の略です。 ストレージ環境の IOPS の数は、これらの属性によって異なります。

  • ストレージ メディアの種類。 ハード ディスク ドライブ (HDD) とソリッド ステート ドライブ (SSD) など。
  • ネットワーク接続によって取り込まれる待機時間。
  • ファイル システムで使用されているブロック サイズ。
  • ファイル システムで使用可能な同時アクセスの量。

ストレージ ソリューションの IOPS 数は 1 つです。 たとえば、5,000 IOPS をサポートする Azure マネージド ディスクを使用している場合は、1 秒あたり最大 5,000 操作行うことができます。 しかし、IOPS の数は、システム オーバーヘッドの読み取りと書き込みを含む、ディスクに対するすべての読み取りまたは書き込み操作の最大 ''合計'' の測定値です。

IOPS の値は、ディスクまたは NAS 環境でサポートできる操作の可能性のある最大数のガイドです。

この測定は一般に、ランダムとシーケンシャルの読み取りおよび書き込み操作で分けられます。

  • ランダム操作は、ディスクまたはファイルのさまざまなランダムなポイントでのデータの読み取りまたは書き込みです。 たとえば、ファイル内のどこかの特定範囲のバイトの編集などです。
  • シーケンシャル操作は、ファイルの先頭から読み取るファイルの連続アクセスです。

スループット

スループットとは、ファイル システムで処理できる、バイト/秒単位で測定された可能な合計転送速度を表します。

スループットの基本の計算を実行するには、システムの IOPS にブロック サイズを乗算します。

たとえば、3,000 IOPS をサポートするディスクがあり、ブロック サイズが 4K の場合、可能な合計スループットは 12 MBps です。

この計算により、ファイル システムの全般的なパフォーマンスの可能性についての基本的な理解が得られます。 ただし、実際のスループットは異なる場合があります。 多数の小さなファイルを作成または削除する場合は、ネットワーク オーバーヘッドのようなものを含めて、他の要因がスループットに影響を与えます。

Latency

待機時間とは、操作の完了にかかる時間を表します。 待機時間が長くなるほど、ワークロードの実行が遅くなる可能性が高くなります。

1 つのアーキテクチャ内には多数の待機時間の発生源があり、それぞれが全体の待機時間に影響を及ぼす可能性があります。

ファイル システムの待機時間は、これらの状況で発生する可能性があります。

  • クライアントとサーバー間の低速のネットワーク接続。
  • 多数の同時要求によって引き起こされる、ネットワークまたはファイル サーバーでの輻輳。
  • クライアントとサーバー間の距離 (WAN 経由など) による自然な待機時間。
  • ファイル サーバー自体の低速のディスク サブシステム アクセス。

待機時間は常に一貫していて、明確に文書化されているとは限りません。 HPC クラスター コンピューターとストレージ エンドポイント間の待機時間を判断するには、テストを実行する必要があります。

待機時間は、累積的な問題でもあります。 ネットワーク パフォーマンスは一因になる可能性がありますが、正しく構成されていないコンピューター オペレーティング システムや、ワークロードのコード自体の非効率性など、その他の要因がある可能性があります。 これらの各要因は全体の待機時間に影響します。

待機時間は、ファイルシステムの実際のパフォーマンスを評価する際に最も重要な要因です。 待機時間が長くなるほど、IOPS が少なくなることを意味します。 IOPS が小さいほど、スループットが低くなる可能性があります。

テストとベースライン値の計算

HPC ワークロードの正確なパフォーマンス構成を選択すると、ワークロード自体に重大な影響があります。

Azure ファイル システム オファリングにより、期待される IOPS とスループット値が提供されます。 独自の NAS ソリューションを構築するように選択した場合は、各仮想マシンとマネージド ディスク SKU に対して文書化されているメトリックを使用します。

ローカル データセンター HPC 構成をパフォーマンスの予想の開始点として使用できます。 クラウド ソリューションでは、ワークロードを実行する複数の環境を作成できることに注意してください。 そのため、Azure ではワークロードごとの柔軟性が高まる可能性があります。 それに対して、ローカル環境は、簡単に (動的に) 拡張できない特定の容量に基づいて構築されています。

ping、fio、iozone、iometer などの基本的なツールを使用して、Azure ファイル システムのベースライン数値を判断できます。

アプリケーション プロファイリング

効率的に実行するために大量の IOPS とスループットを必要とする、I/O を集中的に使用するワークロードがある場合があります。 または、ワークロードが起動され、ライブラリとソース データをメモリに読み込み、最小限のストレージ I/O で続行される場合もあります。 おそらく、前のリストにある最初のワークロードでは、他の HPC コンピューターで読み取る必要のある中間データが書き出されます。 これらの各動作が、ストレージ ソリューションへのアプローチ方法に影響します。 確実にコンピューターが可能な限り迅速にそのデータを読み取れるようにするために、読み取り待機時間の短縮に重点を置きます。 ただし、ワークロードでディスクに中間またはスクラッチ情報を書き込んでいる場合は、確実に各 HPC コンピューターで、それらの書き込みのためにローカル ディスクまたは高速の共有 NAS ソリューションに迅速にアクセスできるようにする必要があります。 これらの中間書き込みを読み取る必要がある可能性のあるコンピューターによって異なります。

ストレージ I/O を使用するために、アプリケーションのプロファイルに投資する必要がある可能性があります。 HPC クラスターのワークロードのサイズと数が増加するにつれて、プロファイルがますます重要になります。

プロファイルには、HPC コンピューターとストレージ環境で実行されるツールの使用が含まれます。 このようなツールでは、ストレージ環境に対して実行される操作の量、種類、およびサイズについて報告します。

生成されるデータの量が膨大であるため、ワークロードのプロファイルが困難になる場合があります。 iostat や sar などのツールでは、時間の経過と共に大量の出力が作成される可能性があります。 結果は分析する必要があり、結果をさらに解析して、ヒストグラムの生成が必要になる場合があります。

NAS ソリューションを使用している場合、プロファイルの実行中にベンダーのインターフェイスから統計情報を収集する必要があります。 その後、その情報を HPC コンピューターのデータと関連付けて I/O パターンを検証します。

I/O 分析に役立てるためにサードパーティ プロファイル ツールを利用でき、一部は HPC アプリケーション ベンダーによって提供されています。