この記事は、マウント オプションと、それらを Azure NetApp Files で使用するためのベスト プラクティスについて理解するのに役立ちます。
Nconnect
nconnectマウントオプションを使って、NFSクライアントとNFSエンドポイント間の接続(ネットワークフロー)数を最大16まで指定してください。 従来、NFS クライアントでは、クライアントとエンドポイント間には 1 つの接続が使用されます。 ネットワークフローの数を増やすことで、I/Oとスループットの上限が大幅に増加します。 自分の環境に最適な設定を見つけるために、可能であればアプリケーションを本番環境に投入する前に nconnect のさまざまな設定をテストしてください。 ほとんどの環境では、最適な結果は nconnect=4です。
実稼働用にマルチノード SAS グリッド環境を準備する際に、実行時間が8時間から5.5時間へと30%短縮されることに気付くかもしれません。
| マウント オプション | ジョブの実行時間 |
|---|---|
nconnect なし |
8 時間 |
nconnect=8 |
5.5 時間 |
両方のテスト セットで同じ E32-8_v4 仮想マシンと RHEL 8.3 を使用しており、先読みは 15 MiB に設定されています。
nconnect を使用する場合は、次の規則にご注意ください。
nconnectは、Azure NetApp Files ではすべての主要な Linux ディストリビューションでサポートされますが、新しいリリースでのみとなります。Linux リリース NFSv3 (最小リリース) NFSv4.1（最低リリース） Red Hat Enterprise Linux RHEL8.3 RHEL8.3 SUSE SLES12SP4 または SLES15SP1 SLES15SP2 ウブントゥ Ubuntu18.04 注
SLES15SP2 は、
nconnectが Azure NetApp Files for NFSv4.1 でサポートされる最小の SUSE リリースです。 指定されている他のすべてのリリースは、nconnect機能を導入した最初のリリースです。次のシナリオに示すように、1 つのエンドポイントからのすべてのマウントで、マウントされた最初のエクスポートの
nconnect設定が継承されます。シナリオ 1:
nconnectは最初の取り付けで使用されます。 そのため、同じエンドポイントに対するすべてのマウントでnconnect=8が使用されます。mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8mount 10.10.10.10:/volume2 /mnt/volume2mount 10.10.10.10:/volume3 /mnt/volume3
シナリオ 2:
nconnectは最初のマウントでは使用されません。 そのため、同じエンドポイントに対するマウントでnconnectは使用されません。そのマウントにnconnectが指定されていても同様です。mount 10.10.10.10:/volume1 /mnt/volume1mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8
シナリオ 3:
nconnect設定は個別のストレージ エンドポイント全体に反映されません。nconnectは、10.10.10.10からのマウントで使用されますが、10.12.12.12からのマウントでは使用されません。mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8mount 10.12.12.12:/volume2 /mnt/volume2
nconnectは、特定のクライアントからストレージの並行性を向上させるために使用される場合があります。
詳細については、Azure NetApp Files 用の Linux の同時実行のベスト プラクティスに関するページを参照してください。
Nconnect の考慮事項
nconnect と sec=krb5* のマウント オプションを一緒に使用することはお勧めしません。 これらのオプションを一緒に使用すると、パフォーマンスの低下につながる場合があります。
Generic Security Standard Application Programming Interface (GSS-API) は、ピア アプリケーションに送信されるデータを保護する方法をアプリケーションに提供します。 このデータは、あるコンピューター上のクライアントから別のコンピューター上のサーバーに送信される可能性があります。
Linux で nconnect を使用する場合、GSS セキュリティ コンテキストは特定のサーバーへのすべての nconnect 接続間で共有されます。 TCP は信頼性の高いトランスポートであり、GSS ストリーム内の順不同のパケットに対処するために、シーケンス番号のスライディングウィンドウを使用します。 シーケンス ウィンドウにないパケットを受信すると、セキュリティ コンテキストが破棄され、新しいセキュリティ コンテキストがネゴシエートされます。 破棄されたコンテキストで送信されたメッセージはすべて無効になるため、メッセージの再送信が必要になります。
nconnect のセットアップでパケット数が多いほど、ウィンドウ外パケットが頻繁に発生し、上記の動作がトリガーされます。 この動作では、特定の低下率を指定することはできません。
Rsize および Wsize
このセクションの例では、パフォーマンス チューニングにアプローチする方法について説明します。 特定のアプリケーションのニーズに合わせて調整が必要になる場合があります。
rsize および wsize フラグでは、NFS 操作の最大転送サイズを設定します。 マウント時に rsize や wsize が指定されていない場合、クライアントとサーバーでは、その 2 つでサポートされる最大サイズをネゴシエートします。 現在、Azure NetApp Files と最新の Linux ディストリビューションの両方で、1,048,576 バイト (1 MiB) の読み取りおよび書き込みサイズがサポートされています。 ただし、全体的なスループットと待機時間を最適にするために、Azure NetApp Files では rsize と wsize の両方を 262,144 バイト (256 K) 以下に設定することをお勧めします。 256 KiB より大きい rsize と wsize を使用すると、待機時間とスループットの両方において、待機時間が長くなり、スループットが低下するおそれがあります。
たとえば、「SUSE Linux Enterprise Server 上の Azure NetApp Files を使用して、スタンバイ ノードを備えた Azure VM 上の SAP HANA スケールアウト システムをデプロイする」では、次のように 256 KiB の rsize と wsize の最大値が示されています。
sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002 nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
10.23.1.4:/HN1-shared/shared /hana/shared nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys 0 0
たとえば、SAS Viya では 256 KiB の読み取りサイズと書き込みサイズが推奨され、SAS GRID では、NFS マウントの先読みを増やして読み取りパフォーマンスを向上させる一方で、r/wsizeサイズが 64 KiB に制限されます。 詳細については、Azure NetApp Files の NFS 先読みのベスト プラクティスに関するページを参照してください。
rsize と wsize の使用には以下の考慮事項が適用されます。
- ランダム I/O の操作サイズは、多くの場合、
rsizeとwsizeのマウント オプションで指定される値よりも小さくなります。 そのため、これらは制約ではありません。 - ファイルシステム キャッシュを使用する場合、ファイル サイズが
rsizeおよびwsizeよりも小さい場合を除き、rsizeとwsizeのマウント オプションによって指定されるサイズで順次 I/O が発生します。 - ファイルシステム キャッシュをバイパスする操作は、
rsizeおよびwsizeマウント オプションによって引き続き制約されますが、rsizeまたはwsizeで指定された最大値ほど大きくはありません。directioオプションが指定されたワークロード ジェネレーターを使用する場合、この考慮事項は重要です。
''Azure NetApp Files を使用する際のベスト プラクティスとして、全体的なスループットと待機時間を最適にするために、rsize と wsize を 262,144 バイト以下に指定します。''
close-to-open整合性とキャッシュ属性タイマー
NFS では緩やかな整合性モデルを使用します。 アプリケーションで使用するたびに共有ストレージにアクセスしてデータをフェッチする必要がないため、整合性の要件は厳密ではありません。毎回取得しなければならないとすると、アプリケーションのパフォーマンスに甚大な影響を与えることになるためです。 このプロセスを管理するメカニズムには、キャッシュ属性タイマーとクローズツーオープンの整合性の 2 つがあります。
クライアントにデータの完全な所有権がある場合、つまり、複数のノード間やシステム間で共有されていない場合は、整合性が保証されます。 この場合、クローズツーオープン (cto) 整合性をオフにし (マウント オプションとして nocto)、属性キャッシュ管理のタイムアウトを長くする (マウント オプションとして actimeo=600 を指定すると、タイマーが 10m に変わります。これに対して、既定値は acregmin=3,acregmax=30,acdirmin=30,acdirmax=60) ことで、ストレージへの getattr アクセス操作を減らし、アプリケーションを高速化できます。 一部のテストでは、nocto で getattr アクセス呼び出しの約 65 から 70% を減らし、actimeo を調整することで、これらの呼び出しをさらに 20 から 25% 減らします。
属性キャッシュ タイマーのしくみ
acregmin、acregmax、acdirmin、および acdirmax 属性でキャッシュの整合性を制御します。 最初の 2 つの属性では、ファイルの属性が信頼される期間を制御します。 後の 2 つの属性では、ディレクトリ ファイル自体の属性 (ディレクトリ サイズ、ディレクトリの所有権、ディレクトリのアクセス許可) が信頼される期間を制御します。
min および max 属性では、ディレクトリの属性、ファイルの属性、ファイルのキャッシュ コンテンツがそれぞれ信頼できると見なされる最小および最大期間を定義します。
min と max との間では、キャッシュされたエントリが信頼される期間を定義するアルゴリズムが使用されます。
たとえば、acregmin と acregmax の既定値がそれぞれ 3 秒と 30 秒であるとします。 たとえば、ディレクトリ内のファイルに対して属性が繰り返し評価されます。 3 秒が経過すると、鮮度について、NFS サービスに対してクエリが実行されます。 属性が有効と見なされると、クライアントでは信頼済み時間が 6 秒、12 秒、24 秒と倍になり、その後、最大値が 30 に設定されているため、30 秒になります。 この時点から、キャッシュされた属性が古いと見なされるまで (その時点でサイクルがやり直される)、信頼度は acregmax で指定された値である 30 秒として定義されます。
クライアントでデータが読み取り専用として使用され、データ更新が別のパスを介して管理されている場合など、クライアントに完全な所有権がない場合でも、同様のマウント オプション セットのベネフィットが得られる場合があります。 EDA、Web ホスティング、ムービー レンダリングなどの、クライアントのグリッドを使用し、比較的静的なデータ セット (EDA ツールまたはライブラリ、Web コンテンツ、テクスチャ データ) があるアプリケーションの場合、一般的な動作では、データ セットがクライアント上で主にキャッシュされます。 読み取りは少なく、書き込みはありません。 ストレージに戻される getattr /アクセス呼び出しは多数あります。 これらのデータ セットは通常、別のクライアントがファイル システムをマウントし、コンテンツの更新を定期的にプッシュすることで更新されます。
このような場合、新しいコンテンツの反映に遅延が発生することが知られており、アプリケーションは古い可能性のあるデータを使用して引き続き動作します。 このような場合は、nocto および actimeo を使用して、対象外の日付を管理できる期間を制御できます。 たとえば、EDA ツールおよびライブラリでは、actimeo=600 が適しています。このデータは通常は頻繁に更新されないためです。 顧客がサイトを編集している際にデータの更新をタイムリーに確認する必要がある小規模な Web ホスティングでは、actimeo=10 を許容できる場合があります。 複数のファイル システムにプッシュされたコンテンツがある大規模な Web サイトでは、actimeo=60が許容される場合があります。
これらのマウント オプションを使用すると、このような場合のストレージへの負荷が大幅に削減されます (たとえば、最近の EDA エクスペリエンスでは、ツール ボリュームへの IOPS が >150 K から約 6 K へ削減されています)。アプリケーションは、メモリ内のデータを信頼できるため、非常に高速に実行できます。 （メモリ アクセス時間はナノ秒で、これに対して、高速ネットワークでの getattr へのアクセスでは数百マイクロ秒となります。）
クローズからオープンへの整合性
クローズツーオープンの整合性 (cto マウント オプション) を使用すれば、キャッシュの状態に関わらず、ファイルを開いたときに常に最新のデータがアプリケーションに提供されるようになります。
- ディレクトリがクロールされると (たとえば、
ls、ls -l)、特定の RPC (リモート プロシージャ コール) セットが発行されます。 NFS サーバーでは、そのファイル システムのビューを提示します。 指定された NFS エクスポートにアクセスするすべての NFS クライアントでctoが使用されている限り、すべてのクライアントにファイルとディレクトリの同じリストが表示されます。 ディレクトリ内のファイルの属性の鮮度は、属性キャッシュ タイマーによって制御されます。 つまり、ctoが使用されている限り、ファイルは作成されてストレージに配置されるとすぐに、リモート クライアントに表示されます。 - ファイルが開かれると、そのファイルのコンテンツは NFS サーバーの観点から最新であることが保証されます。
マシン 2 でファイルを開いたときにマシン 1 からのコンテンツのフラッシュが終了していない競合状態が発生した場合、マシン 2 では、ファイルを開いた時点でサーバー上に存在するデータのみを受信します。 この場合、マシン 2 では、
acregタイマーに達するまでファイルからさらにデータを取得しません。また、マシン 2 では、サーバーに再度問い合わせてキャッシュの整合性を確認します。 このシナリオは、ファイルがマシン 1 からまだ書き込まれている場合に、マシン 2 から tail-fを使用して確認できます。
クローズドからオープンへの一貫性がありません
クローズツーオープンの整合性 (nocto) が使用されていない場合、クライアントでは、キャッシュ属性タイマーの期限を超えるまで、ファイルおよびディレクトリの現在のビューの鮮度を信頼します。
ディレクトリがクロールされると (たとえば、
ls、ls -l)、特定の RPC (リモート プロシージャ コール) セットが発行されます。 クライアントでは、acdirキャッシュ タイマーの値を超えた場合にのみ、ファイルの現在のリストに対してサーバーへの呼び出しを発行します。 この場合、最近作成されたファイルとディレクトリは表示されません。 最近削除されたファイルとディレクトリが実際に表示されます。ファイルが開かれると、そのファイルがまだキャッシュ内にある限り、NFS サーバーとの整合性が検証されることなく、キャッシュされたコンテンツ (存在する場合) が返されます。