次の方法で共有

Azure NetApp Files のパフォーマンスに関するよくあるご質問

  • [アーティクル]

この記事では、Azure NetApp Files のパフォーマンスについてのよくあるご質問 (FAQ) に回答します。

Azure NetApp Files のパフォーマンスを最適化したり調整したりするには、どうすればよいですか?

パフォーマンス要件に従って、次の操作を実行できます。

  • 仮想マシン (VM) のサイズが適切であることを示します。
  • VM の高速ネットワークを有効にします。
  • 容量プールに使用したいサービス レベルとサイズを選択します。
  • 容量とパフォーマンスに使用したいクォータ サイズのボリュームを作成します。

専用の Azure NetApp Files のサブネット内のネットワーク インターフェイスカード (NIC) に高速ネットワークを設定する必要はありません。 高速ネットワークは、Azure VM だけに適用される機能です。 Azure NetApp Files NIC が設計により最適化されています。

Azure NetApp Files ボリュームのパフォーマンスを監視する方法

Azure NetApp Files ボリュームのパフォーマンスは、使用可能なメトリックを使用して監視できます。

Azure NetApp Files のスループットベースのサービス レベルを 1 秒あたりの入出力操作 (IOPS) に変換するにはどうすればよいですか?

次の数式を使用して、メガバイト/秒 (MBps) を IOPS に変換できます。

IOPS = (MBps Throughput / KB per IO) * 1024

ボリュームのサービス レベルを変更するにはどうすればよいですか?

既存のボリュームのサービス レベルを変更するには、目的のボリュームに必要なサービス レベルを使用中の別の容量プールに、目的のボリュームを移動します。 「ボリュームのサービス レベルを動的に変更する」を参照してください。

Azure NetApp Files のパフォーマンスを監視するには、どうすればよいですか?

Azure NetApp Files には、ボリュームのパフォーマンス メトリックが用意されています。 また、Azure Monitor を使用して Azure NetApp Files の使用状況のメトリックを監視することもできます。 Azure NetApp Files のパフォーマンス メトリックの一覧については、「Azure NetApp Files のメトリック」を参照してください。

IOPS が低い場合にワークロードの待機時間が長くなるのはなぜですか?

他の症状 (エラー、ネットワークの問題、アプリケーションが応答しないなど) がない場合、IOP ワークロードが低くくても通常は問題ありません。 通常、低 IOPS は 500 から 600 未満ですが、異なる場合もあります。

Azure NetApp Files は、要求が入ってくると、それに応答します。 要求が少ないワークロードは長いように見えるかもしれませんが、正常に応答しています。 低 IOPS ワークロード (たとえば、5 IOPS、32 KiB/秒) の場合:

  • RAM キャッシュ内にないため、必要なディスクへのアクセスが多くなる。
  • 大きいサンプル サイズがないため、統計的に無関係と見なされる。
  • 外れ値を平均化するのに十分なサンプルがない。

報告される待機時間は、待機時間の平均化スキューのために、数秒または数十秒の範囲に達することがあります。 IOPS が低いボリュームのワークロードを増やすと、待機時間のスキューが待機時間の数値の増加を示す原因であるかどうかを判断するのに役立ちます。

NFSv4.1 での Kerberos のパフォーマンスへの影響はどのようなものですか?

NFSv 4.1 のセキュリティ オプション、テスト済みのパフォーマンス ベクトル、予想されるパフォーマンスへの影響については、NFSv 4.1 ボリュームでの Kerberos のパフォーマンスへの影響に関するページを参照してください。

Kerberos で nconnect を使用する場合のパフォーマンスへの影響はどのようなものですか?

nconnect と sec=krb5* のマウント オプションを一緒に使用することはお勧めしません。 2 つのオプションを組み合わせて使用すると、パフォーマンスの低下が見られました。

Generic Security Standard Application Programming Interface (GSS-API) は、ピア アプリケーションに送信されるデータを保護する方法をアプリケーションに提供します。 このデータは、あるコンピューター上のクライアントから別のコンピューター上のサーバーに送信されたものである可能性があります。 

Linux で nconnect を使用する場合、GSS セキュリティ コンテキストは特定のサーバーへのすべての nconnect 接続間で共有されます。 TCP は信頼性の高いトランスポートであり、シーケンス番号のスライディング ウィンドウを使用して、GSS ストリーム内の順序が正しくないパケットを処理するために順不同のパケット配信をサポートします。 シーケンス ウィンドウにないパケットを受信すると、セキュリティ コンテキストが破棄され、新しいセキュリティ コンテキストがネゴシエートされます。 破棄されたコンテキストで送信されたメッセージはすべて無効になるため、メッセージの再送信が必要になります。 nconnect セットアップ内のパケット数が多いほど、ウィンドウ外パケットが頻繁に発生し、上記の動作がトリガーされます。 この動作では、特定の低下率を指定することはできません。

Azure NetApp Files では SMB ダイレクトはサポートされていますか?

いいえ。Azure NetApp Files では SMB ダイレクトはサポートされていません。

Azure では NIC チーミングはサポートされていますか?

NIC チーミングは Azure ではサポートされていません。 Azure 仮想マシンでは複数のネットワーク インターフェイスがサポートされていますが、それらは物理的な構成ではなく論理的な構成を表します。 そのため、フォールト トレランスは提供されません。 また、Azure 仮想マシンで利用できる帯域幅は、個々のネットワーク インターフェイスではなく、マシン自体に対して計算されます。

ジャンボ フレームはサポートされていますか?

Azure 仮想マシンでは、ジャンボ フレームはサポートされていません。

次のステップ