マウント オプションとクライアント VM 構成
このモジュールでは、Azure NetApp Files で HPC または EDA アプリケーションを実行するときのマウント オプションとクライアント VM 構成について説明します。
Note
NFS クライアントのベスト プラクティスは、使用するアプリケーションによって異なります。 以下の提案は絶対的なものではなく、アプリケーションの推奨事項やワークロード テストを優先させることができます。 運用環境にデプロイする前に、これらのプラクティスをテストすることを強くお勧めします。
マウント オプションの actimeo と nocto を使用してパフォーマンスを向上させる
次のマウント オプションを使用して、比較的静的なデータセットおよび大量の読み取りのシナリオでパフォーマンスを向上させることができます。
actimeo: ディレクトリの NFS クライアントのキャッシュ属性を制御します。 指定しない場合、NFS クライアントでは既定の最大 60 秒が使用されます。nocto: "no close-to-open" の略で、書き込みが完了する前にファイルを閉じて時間を節約できることを意味します。 既定では、noctoは NFS マウント オプションに設定されません。 つまり、すべてのファイルは、書き込みが完了するのを待ってから閉じられます。
このシナリオの EDA を含めてほとんどの HPC アプリケーションには、比較的静的なデータセット (つまり、頻繁に変更されないデータ) があります。 その場合、nocto と actimeo を使用して、ストレージへの getattr または access 操作を削減でき、それによってアプリケーションを高速化できます。
たとえば、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 で最適なパフォーマンスを得るのに役立つ場合があります。 クライアント VM に大容量の RAM が装備されている、または 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 ボリュームの使用可能なインフライト要求のキューが限度を超え、結果的に望ましくないパフォーマンス (クライアントが、特定の時点で許可される以上の要求を送信する状態) が生じるおそれがあります。 この動作によるパフォーマンスへの影響のリスクを軽減するには、nconnect=8 または 16 を使用している場合は sunrpc.tpc_max_slot_table_entries=256 または 512 をより低い静的な値に設定することを検討してください。 次の表をガイダンスとして使います。
Note
Linux クライアント OS の種類に応じて、この値の設定方法が異なる場合があります。 詳細については、OS のドキュメントを参照してください。
nconnect 値 |
推奨されている TCP の最大スロット テーブル エントリ数 |
|---|---|
| 0-1 | 128 |
| 2-4 | 256 |
| 6 - 8 | 512 |
| >8 | 変更不要です |
Note
nconnect オプションは、Linux kernel 5.3 以上の VM にのみ使用できます。 カーネルをアップグレードするときに VM の再起動が必要になる場合があります。 つまり、場合によっては適用されないおそれがあります。
パフォーマンスのみを考慮する場合は、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 マウント操作を使用する場合、クライアントでは UNSTABLE コマンドを使用して NFS 経由で複数の WRITE 呼び出しを送信できます。 このシナリオでは、タイムアウト期間が過ぎた後にデータがディスクにフラッシュされます。 NFS クライアントでは、次の WRITE を開始する前にデータをディスクにコミットするのをサーバーで常に待機しているわけではないため、非同期マウントへの書き込みのジョブ完了時間は、sync の場合よりもはるかに短くなります。より大きな 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 マウント オプションを使用する場合のパフォーマンスへの影響を併せて考慮すると、ほぼすべてのユース ケースで async が望ましい選択肢となります。
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、intr に適切な設定を選択する
hard または soft マウント オプションは、NFS サーバーが利用できない場合に、NFS を使用するファイルを使用するプログラムが次のいずれかのアクションを実行する必要があるかどうかを指定します。
- NFS サーバーを使用できない場合、サーバーを停止して、オンラインに戻るまで待機する (
hard)。 このオプションは、クライアント上でマウント中止として表示されますが、ネットワークの停止時に、進行中の操作が失われないようにします。 代わりに、クライアントでは、サーバーが使用可能になるまで、またはアプリケーションがタイムアウトになるまで、要求の再試行を続けます。 - エラーを報告する (
soft)。 マウントは中止されませんが、進行中の操作が失われるおそれがあります。
intr マウント オプションを使用すると、マウントが hard マウントとして指定されている場合に、NFS プロセスを中断できます (CTRL+C など)。 データの信頼性と管理容易性の最適な組み合わせを実現するために、hard マウントで intr を使用することをお勧めします。
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
Note
NFS マウントは既定で async に設定されるため、Async は指定されません。