Azure NetApp Files の SMB のパフォーマンスのベスト プラクティス

この記事は、Azure NetApp Files の SMB のパフォーマンスとベスト プラクティスを理解するのに役立ちます。

SMB マルチチャネル

SMB マルチチャネルは、SMB 共有で既定で有効になっています。 既存の SMB ボリュームより前から存在していたすべての SMB 共有ではこの機能が有効になっています。また、新しく作成されたすべてのボリュームでも、作成時にこの機能が有効になっています。

SMB マルチチャネル機能を利用するには、機能が有効になる前に確立された SMB 接続をすべてリセットする必要があります。 リセットするには、SMB 共有を切断して再接続します。

Windows では、最適なパフォーマンスを実現するため、Windows 2012 以降で SMB マルチチャネルがサポートされています。 詳しくは、「SMB マルチチャネルを展開する」および SMB マルチチャネルの基礎に関する記事をご覧ください。

SMB マルチチャネルの利点

SMB マルチチャネル機能を使用すると、SMB3 クライアントでは、単一のネットワーク インターフェイス カード (NIC) または複数の NIC を介して接続のプールを確立し、それらを使用して 1 つの SMB セッションに要求を送信することができます。 これに対し、SMB1 と SMB2 では、設計上、クライアントは 1 つの接続を確立し、特定のセッションに対するすべての SMB トラフィックを、その接続を介して送信する必要があります。 この単一接続により、単一のクライアントから実現できるプロトコル全体のパフォーマンスが制限されます。

SMB マルチチャネルのパフォーマンス

次のテストとグラフは、単一インスタンス ワークロードにおける SMB マルチチャネルの能力を示したものです。

ランダム I/O

クライアントで SMB マルチチャネルを無効にし、FIO と 40 GiB のワーキング セットを使用して、純粋な 4 KiB の読み取りと書き込みのテストを実行しました。 SMB 共有は各テスト間でデタッチされており、RSS ネットワーク インターフェイス設定あたりの SMB クライアント接続数の増分は 1、4、8、16、set-SmbClientConfiguration -ConnectionCountPerRSSNetworkInterface <count> でした。 このテストでは、既定の設定 4 で、I/O 集中型のワークロードに十分であることが示されています。8 や 16 に増やしても影響はほとんどありませんでした。

コマンド netstat -na | findstr 445 により、1 から 4、4 から 8、8 から 16 の増分で追加接続が確立されたことが示されました。 各テストでは 4 個の CPU コアが SMB に完全に利用されました。これは、perfmon の Per Processor Network Activity Cycles の統計によって確認されています (この記事には記載されていません)。

Azure 仮想マシン (VM) は、SMB (または NFS) のストレージ I/O 制限には影響しません。 次のグラフに示すように、インスタンスの種類が D32ds の場合、キャッシュされたストレージ IOPS では 308,000、キャッシュされていないストレージ IOPS では 51,200 に速度が制限されます。 ただし、上のグラフでは、SMB の方が I/O がはるかに多いことが示されています。

シーケンシャル I/O

前述のランダム I/O のテストと同様のテストを、64 KiB のシーケンシャル I/O で実行しました。 ランダム I/O では RSS ネットワーク インターフェイスあたりのクライアント接続数を 4 より大きくしても大きな効果はありませんでしたが、シーケンシャル I/O には同じことは当てはまりません。 次のグラフが示すように、接続数を増やすたびに、それに対応して読み取りスループットも増加します。 書き込みスループットは、インスタンスの種類とサイズごとに Azure によって課せられるネットワーク帯域幅の制限により、フラットなままです。

Azure では、VM の種類とサイズごとにネットワーク速度が制限されます。 速度制限は、送信トラフィックに対してのみ適用されます。 VM に存在する NIC の数は、マシンで利用可能な合計帯域幅には影響しません。 たとえば、インスタンスの種類が D32ds の場合、16,000 Mbps (2,000 MiB/秒) のネットワーク制限が適用されます。 上のシーケンシャルのグラフで示されているように、この制限は送信トラフィック (書き込み) には影響しますが、マルチチャネルの読み取りには影響しません。

SMB 署名

SMB プロトコルでは、ファイルや印刷の共有や、Windows のリモート管理などの他のネットワーク操作に対する基盤が提供されます。 転送中の SMB パケットを変更する中間者攻撃を防ぐため、SMB プロトコルでは SMB パケットのデジタル署名がサポートされています。

SMB 署名は、Azure NetApp Files によってサポートされているすべての SMB プロトコル バージョンでサポートされています。

SMB 署名によるパフォーマンスへの影響

SMB 署名を使用すると、SMB のパフォーマンスに悪影響があります。 パフォーマンスが低下する可能性のある原因の 1 つは、以下の perfmon の出力に示すように、各パケットのデジタル署名によってクライアント側の CPU が余計に使用されることです。 この場合、コア 0 で SMB 署名を含む SMB の処理が行われています。 前のセクションのマルチチャネルではない場合のシーケンシャル読み取りスループットの数値と比較すると、SMB 署名により、全体的なスループットが 875 MiB/秒から約 250 MiB/秒に低下することがわかります。

1 TB のデータセットを使用する単一インスタンスのパフォーマンス

読み取り/書き込みを組み合わせたワークロードの詳細な分析情報を提供するために、次の 2 つのグラフで、1 TB のデータセットと SMB マルチチャネル 4 を使用した、50 TB の単一の Ultra サービスレベル クラウド ボリュームのパフォーマンスを示します。 最適な IODepth 16 が使用されました。ネットワーク帯域幅を最大限に使用するために、Flexible I/O (FIO) パラメーターが使用されました (numjobs=16)。

次のグラフは、1 つの VM インスタンスと、10% 間隔での読み取り/書き込みの組み合わせを使用した、4k のランダム I/O の結果を示しています。

次のグラフは、シーケンシャル I/O の結果を示しています。

1 TB のデータセットを使用する 5 台の VM を使ってスケールアウトした場合のパフォーマンス

5 台の VM を使ったこれらのテストでは、単一の VM と同じテスト環境が使用され、各プロセスは独自のファイルに書き込みを行います。

次のグラフは、ランダム I/O の結果を示しています。

次のグラフは、シーケンシャル I/O の結果を示しています。

Hyper-V イーサネット アダプターを監視する方法

FIO を使ったテストで使用される戦略の 1 つは、numjobs=16 を設定することです。 これにより各ジョブが 16 個の特定のインスタンスに分岐され、Microsoft Hyper-V ネットワーク アダプターが最大化されます。

Windows パフォーマンス モニターで各アダプターのアクティビティを確認するには、[パフォーマンス モニター] > [カウンターの追加] > [ネットワーク インターフェイス] > [Microsoft Hyper-V ネットワーク アダプター] の順に選びます。

データ トラフィックがボリューム内で実行されたら、Windows パフォーマンス モニターでアダプターを監視できます。 これらの 16 個すべての仮想アダプターを使用しない場合は、ネットワーク帯域幅の容量が最大化されない可能性があります。

SMB 暗号化

このセクションは、SMB 暗号化 (SMB 3.0 および SMB 3.1.1) を理解するのに役立ちます。

SMB 暗号化は、SMB データをエンド ツー エンドで暗号化し、信頼できないネットワークで発生する傍受からデータを保護できます。 SMB 暗号化は、SMB 3.0 以上でサポートされています。

要求をストレージに送信するときに、クライアントは要求を暗号化します。この暗号化がストレージによって解除されます。 応答は、同様にサーバーによって暗号化され、クライアントによって暗号化が解除されます。

SMB 暗号化は、Windows 10、および Windows 2012 以降のバージョンでサポートされています。

SMB 暗号化と Azure NetApp Files

Azure NetApp Files では、SMB 暗号化は共有レベルで有効になっています。 SMB 3.0 では AES-CCM アルゴリズム、SMB 3.1.1 では AES-GCM アルゴリズムが採用されています。

SMB 暗号化は必須ではありません。 そのため、ユーザーが Azure NetApp Files 有効にするように要求すると、特定の共有に対してのみ有効になります。 Azure NetApp Files 共有がインターネットに公開されることはありません。 特定の VNet 内から、VPN または ExpressRoute 経由でのみアクセスできます。したがって、Azure NetApp Files 共有は本質的にセキュリティで保護されています。 SMB 暗号化を有効にするかどうかは、ユーザーが選択します。 この機能を有効にする前に、パフォーマンスの低下が予想されることを理解しておいてください。

クライアント ワークロードに対する SMB 暗号化の影響

SMB 暗号化は、クライアント (メッセージの暗号化と復号化のための CPU オーバーヘッド) とストレージ (スループットの低下) の両方に影響を与えますが、次の表は、ストレージに対する影響のみを示しています。 ワークロードを運用環境にデプロイする前に、自分のアプリケーションのパフォーマンスに対する暗号化の影響をテストする必要があります。

I/O プロファイル	影響
ワークロードの読み取りと書き込み	10% ～ 15%
メタデータ集中型	5%

高速ネットワーク

パフォーマンスを最大化するために、可能であれば、VM で高速ネットワークを構成することをお勧めします。 以下の点に注意してください。

• Azure portal では、この機能をサポートする VM に対し、既定で高速ネットワークが有効になります。 ただし、Ansible や同様の構成ツールなどの他のデプロイ方法では有効にできません。 高速ネットワークを有効にしないと、マシンのパフォーマンスが低下する可能性があります。
• インスタンスの種類またはサイズがサポートされていないために VM のネットワーク インターフェイスで高速ネットワークが有効になっていない場合、インスタンスの種類を大きくしても無効のままです。 そのような場合は、手動で介入する必要があります。
• 専用の Azure NetApp Files のサブネット内の NIC に高速ネットワークを設定する必要はありません。 高速ネットワークは、Azure VM だけに適用される機能です。 Azure NetApp Files NIC が設計により最適化されています。

Receive Side Scaling

Azure NetApp Files では、Receive Side Scaling (RSS) がサポートされています。

SMB マルチチャネルを有効にすると、SMB3 クライアントでは、単一 RSS 対応のネットワーク インターフェイス カード (NIC) を介して、Azure NetApp Files SMB サーバーへの複数の TCP 接続が確立されます。

お使いの Azure VM の NIC で RSS がサポートされているかどうかを確認するには、次のようにコマンド Get-SmbClientNetworkInterface を実行し、フィールド RSS Capable を確認します。

SMB クライアント上の複数の NIC

SMB 用のクライアントで複数の NIC を構成しないでください。 SMB クライアントは、SMB サーバーから返される NIC の数とは一致しません。 各ストレージ ボリュームには、1 つのストレージ エンドポイントからしかアクセスできません。つまり、特定の SMB 関係に対して使用される NIC は 1 つだけです。

以下の Get-SmbClientNetworkInterace の出力でわかるように、この VM には 2 つのネットワーク インターフェイス 15 と 12 があります。 次のコマンド Get-SmbMultichannelConnection の下に示されているように、RSS 対応の NIC は 2 つありますが、SMB 共有との接続にはインターフェイス 12 のみが使用され、インターフェイス 15 は使用されていません。

次のステップ

• SMB に関する FAQ