マウント オプションとクライアント VM 構成

このモジュールでは、Azure NetApp Files で HPC または EDA アプリケーションを実行しているときにパフォーマンスを向上させるマウント オプションとクライアント VM 構成について説明します。

actimeo および nocto マウント オプションを使用してパフォーマンスを向上させる

次のマウント オプションを使用して、比較的静的なデータセットと大規模な読み取りシナリオのパフォーマンスを向上させることができます。

• actimeo: ディレクトリの NFS クライアント キャッシュ属性を制御します。 指定しない場合、NFS クライアントは 60 秒の既定の最大値を使用します。
• nocto: "no close-to-open" の略で、書き込みが完了する前にファイルを閉じて時間を節約できることを意味します。 既定では、 nocto は NFS マウント オプションでは設定されません。 つまり、すべてのファイルは書き込みの完了を待ってから閉じます。

このシナリオの EDA を含むほとんどの HPC アプリケーションには、比較的静的なデータセットがあります (つまり、データは頻繁に変更されません)。 その場合は、 nocto と actimeo を使用して、ストレージへの getattr またはアクセス操作を減らすことができます。これにより、アプリケーションの高速化に役立ちます。

たとえば、EDA ツールとライブラリ ボリュームの "nocto,actimeo=600" (600 秒または 10 分) を設定することをお勧めします。 これらのファイルは変更されないため、維持するキャッシュの一貫性はありません。 これらのマウント オプションを設定すると、メタデータ呼び出しが減り、全体的なパフォーマンスが向上します。

最適なパフォーマンスを得られるようにシステム パラメーターを調整する

Tuned は、Linux クライアントで接続されているデバイスを監視および構成するために使用できるデーモンです。 ほとんどの場合、 tuned は既定でインストールされます。 インストールされていない場合は、追加して有効にして、組み込みの既定のテンプレートを使用してクライアント側のチューニング パラメーターを簡略化できます。

次のコマンドを実行して、クライアント VM の基本的なサーバー チューニングと一般的な待機時間のチューニングを適用します。

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

次のシステム パラメーター (/etc/sysctl.conf) の一部またはすべてが、最適なパフォーマンスを得るための Linux クライアント VM に役立つ場合があります。 膨大な量の RAM を持つクライアント VM や、InfiniBand のようなネットワーク帯域幅が高い場合は、次の例に示す値よりもさらに高い値を設定できます。

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

これらのチューニングを永続的にするには、次のコマンドを実行します。

sudo sysctl -P

該当する場合は、nconnect マウント オプションを使用してネットワーク接続を拡張します

nconnect NFS マウント オプションは、Linux カーネル 5.3 以降で一般提供を開始しました。 クライアント VM の Linux カーネルを確認するには、次のコマンドを実行します。

uname -r

nconnectの目的は、クライアント上の TCP 接続またはマウント ポイントごとに複数のトランスポート接続を提供することです。 この手法は、NFS マウントの並列処理とパフォーマンスの向上に役立ちます。

クライアントの数が少ないほど、使用可能なすべてのネットワーク帯域幅を利用できる可能性があるため、パフォーマンスの向上に役立つ nconnect の価値が高まります。 クライアントの数が増えると、その値は徐々に減少します。合計で一定の帯域幅しかなく、TCP 接続の最大数が速く使い果たされ、TCP 接続が解放されるまでサービス拒否が発生する可能性があります。

Azure NetApp Files では、スロットルが発生する前に TCP 接続ごとに最大 128 個の同時処理中要求が許可されるため (リソースが使用可能になるまで新しい要求がキューに入れられます)、 nconnect は、マウント ポイントごとに使用可能な TCP 接続を増やすことで、許可される処理中の要求の数を増やすのに役立ちます。 たとえば、 nconnect が 8 つの TCP 接続を使用するように設定されている場合、1,024 (8x128) 要求がクライアントで使用できる可能性があります。

最新の Linux クライアントでは、接続あたり最大 65,535 要求 (動的な値) が許可されます。 これにより、Azure NetApp Files ボリュームの使用可能な実行中の要求キューがオーバーランする可能性があり、望ましくないパフォーマンスの結果が生じる可能性があります。これにより、クライアントは特定の時点で受け入れ可能な数を超える要求を送信します。 この動作によるパフォーマンスへの影響のリスクを軽減するには、sunrpc.tpc_max_slot_table_entries=256または512を使用している場合は、nconnect=8または16を低い静的な値に設定することを検討してください。 ガイダンスとして次の表を使用します。

パフォーマンスのみを考慮する場合は、NFSv4.1 の代わりに NFSv3 を使用します

NFSv3 はステートレス プロトコルです。つまり、クライアントとサーバーは使用中のファイルについて相互に通信しません。 ロックは、ネットワーク ロック マネージャー (NLM) によってプロトコル スタックの外部で実行されます。これは、ロックが古くなり、手動でクリーンアップする必要がある場合にいくつかの課題が発生します。 ロックはアプリケーションによって要求されたときにのみ確立されるため、ロックをネゴシエートする必要がない場合があります。 クライアント ID、状態 ID、セッション ID、ロック状態などが追跡されないため、NFSv3 は、一部のワークロード (特に EDA やソフトウェア開発など、高いファイル数/高メタデータ ワークロード) で NFSv4.1 よりも少し優れたパフォーマンスを発揮する傾向があります。

NFSv4.1 は、ロックを含むファイルの状態を追跡します。 NFSv4.1 で多数のファイルが一度に使用されている場合、各ファイルには状態 ID が割り当てられ、ロックが受け取ります。 ステートフルになると、各状態とロックを NFS サーバーで処理する必要があり、ワークロードのパフォーマンスにオーバーヘッドが生じます。 一部のワークロード (EDA など) では、NFSv4.1 のパフォーマンスは、25% から 75%まで影響を受ける可能性があります。 大きなファイル、ストリーミング IO、データベースなどの他のワークロードでは、NFSv4.1 を使用してもパフォーマンスが低下せず、プロトコルで使用される複合操作の恩恵を受ける場合もあります。

Azure NetApp Files では、NFSv3 と NFSv4.1 の両方がサポートされています。 NFS バージョンの類似点と相違点 (およびテスト) を比較し、適切なバージョンを使用してボリュームを作成することで、アプリケーションに必要なバージョンを検証する必要があります。 必要に応じて、作成後に Azure NetApp Files ボリュームを別のプロトコル バージョンに構成できます。

rsize および wsize マウント オプションの適切な値を選択する

マウント オプション rsize (読み取りサイズ) と wsize (書き込みサイズ) によって、送信されるパケットごとに NFS クライアントとサーバーの間で送信されるデータの量が決まります。 たとえば、 rsize または wsize を 65,536 に設定すると、パケットあたり最大 64 K のデータを送信できます。 アプリケーションがより小さなチャンク (8 K など) でデータを送信する場合、送信されるデータの量は、使用されるマウント オプション ( sync など) によって異なります。

Azure NetApp Files のベスト プラクティスは、 rsize と wsize を同じ値に設定する方法です。 通常、マウント オプションの rsize および wsize の値を両方とも 262144 (256 K) に設定することをお勧めします。

同期と非同期マウントのオプションについて

syncが使用されている場合、各WRITE呼び出しは FILE_SYNC コマンドで送信されます。 つまり、次の WRITE が発生する前に、すべての WRITE がサーバーによって確認され、ディスクにコミットされる必要があります。 Sync は、アプリケーションがすべてのデータがディスクにコミットされることを保証する必要がある場合に使用されます。 WRITE 呼び出しは、アプリケーションのブロック サイズで指定された量のデータのみを送信します。つまり、ブロック サイズが小さいほど、マウントの wsize 値と rsize 値に関係なく NFS トラフィックが多くなり、パフォーマンスに影響を与えます。

(既定) asyncマウント操作を使用する場合、クライアントは WRITE コマンドを使用して NFS 経由で複数のUNSTABLE呼び出しを送信できます。 このシナリオでは、タイムアウト期間後にデータがディスクにフラッシュされます。 NFS クライアントは、次の WRITE を開始する前に、サーバーでデータをディスクにコミットするのを常に待機しているわけではありません。そのため、非同期マウントへの書き込みのジョブ完了時間は、同期の場合よりもはるかに少なくなります。 rsize 値と wsize 値を大きくして使用するブロック サイズが小さい場合、 WRITE 呼び出しは、1 回の NFS 呼び出しで許可される量のデータを送信します。 たとえば、64 K の wsize/rsizeで 8 K のブロック サイズが使用されている場合、各 NFS WRITE 呼び出しはパケットごとに 8 ブロック (64 K/8 K) を送信します。 書き込みがディスクにフラッシュされると、NFS サーバーは NFS クライアントに FILE_SYNC 応答を送信します。 これにより、ジョブを完了するために必要なネットワーク経由の WRITE 呼び出しと応答の合計数が減り、パフォーマンスが向上します。

たとえば、8 K ブロック サイズを使用して 1 GiB ファイルが作成されたテストでは、262,144 WRITE の呼び出しと応答が生成され、 sync マウント オプションを使用すると 70 秒で終了します。 8 K ブロック サイズと async マウント オプションを使用した同じファイル作成では、16,384 回の WRITE 呼び出しと応答のみが送信され、6 秒で完了しました。

Azure NetApp Files では、バッテリベースの NVRAM ストレージを、受信 NFS 書き込みのバッファー キャッシュとして使用します。 NVRAM 内のデータは、10 秒ごとに、またはバッファー キャッシュがいっぱいになるまで (どちらか早い方) ディスクにフラッシュされます。 NVRAM はバッテリによって支えられているため、Azure データセンターの電源が失われる可能性が低い場合など、データを保持しながら、予期しない停止を少なくとも 72 時間存続させることができます。 Azure NetApp Files のデータの回復性と、 sync マウント オプションを使用した場合のパフォーマンスへの影響の組み合わせにより、ほぼすべてのユース ケースで非同期を優先します。

wsize と rsize の値の影響を理解する

NFS 経由でマウントする場合、 wsize 値と rsize 値によって、NFS サーバーへの NFS 呼び出しごとに送信できるデータの量が決まります。 マウント オプションで指定されていない場合、値は NFS サーバーで構成されているものに設定されます。 Azure NetApp Files では、 wsize と rsize の両方で最大転送サイズが 1 MB (1048576) 使用されます。 この値は、Azure NetApp Files では変更できません。 つまり、NFS マウントで wsize 値と rsize 値が指定されていない場合、マウントの既定値は 1 MB になります。 EDA ワークロードでの NFS マウントの推奨 wsize 値と rsize 値は 256 K です。

アプリケーションが Azure NetApp Files NFS マウント上に 1 GiB ファイルを作成する必要がある場合は、1048,576 KiB をストレージに書き込む必要があります。 数値演算演習では、より効率的な wsize 値または rsize 値を使用してパフォーマンスが向上する理由を示すことができます。

• wsizeが 64 K に設定されている場合、1 GiB ファイルの書き込みに必要な操作/パケットの数は 1048576/64=16384 になります。
• wsizeが 256 K に設定されている場合、1 GiB ファイルの書き込みに必要な操作/パケットの数は 1048576/256=4096 になります。

パケット/操作の数が少ないほど、ネットワーク待機時間 (RTT に影響を与える) がワークロードに与える影響が小さくなり、クラウド デプロイで重要になる可能性があります。 ただし、アプリケーションが wsize/rsize 値より小さいファイルを書き込む場合、 wsize/rsize 値が大きいほどパフォーマンスには影響しません。

データのチャンクが大きくなると、クライアントとサーバーでの処理サイクルが増えますが、最新の CPU のほとんどは、これらの要求を効率的に処理するのに十分な機能を備えています。

Azure NetApp Files のベスト プラクティスは、 rsize と wsize を同じ値に設定する方法です。 マウント オプションでは、 rsize 値と wsize 値の両方を 262144 (256K) に設定することをお勧めします。 この設定では、アプリケーションの読み取りと書き込みのサイズ値の配列について説明します。

ハード、ソフト、イントルのマウント オプションに適した設定を選択する

hardおよびsoftマウント オプションでは、NFS を使用するファイルを使用するプログラムが次のいずれかのアクションを実行するかどうかを指定します。

• NFS サーバーが使用できない場合は、サーバーがオンラインに戻るのを停止して (hard) 待ちます。 このオプションは、クライアント上でマウント中止として表示されますが、ネットワークの停止時に、進行中の操作が失われないようにします。 代わりに、サーバーが使用可能になるまで、またはアプリケーションがタイムアウトするまで、クライアントは要求の再試行を続行します。
• エラー (soft) を報告します。 マウントは中止されませんが、進行中の操作が失われるおそれがあります。

intr マウント オプションを使用すると、マウントが hard マウント (CTRL+C など) として指定されたときに NFS プロセスを中断できます。 データの信頼性と管理容易性の最適な組み合わせに該当する場合は、intrマウントでhardを使用することをお勧めします。

MTU の変更を考慮しない

Azure VM の既定の最大伝送ユニット (MTU) は 1,500 バイトです。 ジャンボ フレームの VM MTU を増やすことをお客様にお勧めすることはできません。

マウントの例

次のコード例では、 actimeo、 nocto、 NFSv3、 nconnect、 rsize、 wsize、 hard、 intr、 tcp、および既定の MTU (1,500) に関する前述のベスト プラクティスを使用して、Azure NetApp Files ボリュームをマウントします。

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol