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、8、16 と追加して確立されたことが示されています。 各テストでは 4 個の CPU コアが SMB に完全に利用されました。これは、perfmon の Per Processor Network Activity Cycles の統計によって確認されています (この記事には記載されていません)。
Azure 仮想マシンは、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 では、仮想マシンの種類とサイズごとにネットワーク速度が制限されます。 速度制限は、送信トラフィックに対してのみ適用されます。 仮想マシンに存在する 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 IO (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% |
高速ネットワーク
パフォーマンスを最大化するために、可能であれば、仮想マシンで高速ネットワークを構成することをお勧めします。 以下の点に注意してください。
- Azure portal では、この機能をサポートする仮想マシンに対し、既定で高速ネットワークが有効になります。 ただし、Ansible やそれと似た構成ツールなどの他のデプロイ方法では、有効にならない場合があります。 高速ネットワークを有効にしないと、マシンのパフォーマンスが低下する可能性があります。
- インスタンスの種類またはサイズがサポートされていないために仮想マシンのネットワーク インターフェイスで高速ネットワークが有効になっていない場合、インスタンスの種類を大きくしても無効のままです。 そのような場合は、手動で介入する必要があります。
- 専用の Azure NetApp Files のサブネット内の NIC に高速ネットワークを設定する必要はありません。 高速ネットワークは、Azure 仮想マシンだけに適用される機能です。 Azure NetApp Files NIC が設計により最適化されています。
RSS
Azure NetApp Files では、受信側のスケーリング (RSS) がサポートされています。
SMB マルチチャネルを有効にすると、SMB3 クライアントでは、単一 RSS 対応のネットワーク インターフェイス カード (NIC) を介して、Azure NetApp Files SMB サーバーへの複数の TCP 接続が確立されます。
お使いの Azure 仮想マシンの NIC で RSS がサポートされているかどうかを確認するには、次のようにコマンド Get-SmbClientNetworkInterface を実行し、フィールド RSS Capable を確認します。
SMB クライアント上の複数の NIC
SMB 用のクライアントで複数の NIC を構成しないでください。 SMB クライアントは、SMB サーバーから返される NIC の数に合わせます。 各ストレージ ボリュームには、1 つのストレージ エンドポイントからしかアクセスできません。 つまり、特定の SMB 関係に対して使用される NIC は 1 つだけです。
次の Get-SmbClientNetworkInterace の出力でわかるように、この仮想マシンには 2 つのネットワーク インターフェイス 15 と 12 があります。 次のコマンド Get-SmbMultichannelConnection の下に示されているように、RSS 対応の NIC は 2 つありますが、SMB 共有との接続にはインターフェイス 12 のみが使用され、インターフェイス 15 は使用されていません。
次のステップ
- SMB に関する FAQ
- Azure NetApp Files で SMB ファイル共有を使用する方法については、「Azure NetApp Files: SMB ワークロード用のマネージド エンタープライズ ファイル共有」を参照してください。