SMB Azure ファイル共有のパフォーマンスを向上させる
この記事では、SMB マルチチャネルやメタデータ キャッシュ (プレビュー) の使用など、Premium SMB Azure ファイル共有のパフォーマンスを向上させる方法について説明します。
適用対象
ファイル共有の種類 | SMB | NFS |
---|---|---|
Standard ファイル共有 (GPv2)、LRS/ZRS | ||
Standard ファイル共有 (GPv2)、GRS/GZRS | ||
Premium ファイル共有 (FileStorage)、LRS/ZRS |
パフォーマンスの最適化
次のヒントを参考にして、パフォーマンスを最適化することができます。
- ストレージ アカウントとクライアントを同じ Azure リージョンに共存させて、ネットワーク待ち時間を短縮します。
- マルチスレッド アプリケーションを使用し、複数のファイルに負荷を分散します。
- SMB マルチチャネルのパフォーマンス上の利点は、負荷を分散するファイルの数と共に増えます。
- Premium 共有のパフォーマンスは、プロビジョニングされた共有サイズ (IOPS、エグレス、イングレス) と単一ファイルの制限に縛られます。 詳細については、「Premium ファイル共有のプロビジョニングについて」を参照してください。
- 1 つの VM クライアントの最大パフォーマンスは VM の制限に引き続き縛られます。 たとえば Standard_D32s_v3 で最大帯域幅 16,000 MBps (または 2 GBps) をサポートでき、VM からのエグレス (ストレージへの書き込み) は測定され、イングレス (ストレージからの読み取り) は測定されません。 ファイル共有のパフォーマンスは、マシン ネットワーク制限、CPU、内部ストレージの使用可能なネットワーク帯域幅、IO サイズ、並列処理、その他の要因の影響を受けます。
- 通常、最初のテストはウォームアップです。 結果を破棄し、テストを繰り返します。
- パフォーマンスが 1 つのクライアントによって制限されていて、ワークロードがプロビジョニングされた共有制限をまだ下回っている場合は、複数のクライアントに負荷を分散することでパフォーマンスを向上させることができます。
IOPS、スループット、I/O サイズの関係
スループット = IO サイズ * IOPS
I/O サイズが大きくなるとスループットが向上して、待ち時間が多くなり、その結果、正味の IOPS 数が少なくなります。 I/O サイズが小さくなると IOPS が向上しますが、その結果、正味のスループットと待ち時間は少なくなります。 詳細については、「Azure Files のパフォーマンスについて」を参照してください。
SMB マルチチャネル
SMB マルチチャネルでは、SMB 3.x クライアントが SMB ファイル共有に複数のネットワーク接続を確立できます。 Azure Files では、プレミアム ファイル共有 (FileStorage ストレージ アカウントの種類のファイル共有) で SMB マルチチャネルがサポートされています。 サービス側では Azure Files において SMB マルチチャネルが既定で無効になっていますが、有効にしても追加のコストは発生しません。
2024 年 7 月以降、SMB マルチチャネルは、次のリージョンで新しく作成されたすべての Azure ストレージ アカウントに対して既定で有効になります。
- オーストラリア中部
- ブラジル南東部
- カナダ東部
- フランス南部
- 東アジア
- 東南アジア
- インド中部 (Jio)
- インド西部 (Jio)
- インド西部
- 東日本
- 西日本
- 韓国南部
- 北ヨーロッパ
- 西ヨーロッパ
- ノルウェー西部
- 英国南部
メリット
SMB マルチチャネルを使用すると、クライアントから、複数のネットワーク接続を使用して、パフォーマンスを向上させることができ、所有コストも削減します。 複数の NIC の帯域幅を集約し、Receive Side Scaling (RSS) サポートを利用して NIC の I/O 負荷を複数の CPU に分散できるようにすることで、パフォーマンス向上を達成します。
- スループットの向上: 複数接続により、複数のパスでデータを並列で転送できるため、ファイルのサイズが大きく、I/O のサイズが大きいファイルを使用し、単一の VM または小さな VM セットからの高スループットを必要とするワークロードに大きなメリットがあります。 これらのワークロードには、コンテンツ作成やコード変換のためのメディアやエンターテインメント、ゲノミクス、金融サービスのリスク分析などがあります。
- 高 IOPS:NIC RSS 機能を使用すると、複数の CPU で複数の接続がある場合に効果的な負荷分散を行うことができます。 これは、より高い IOPS スケールと VM CPU の有効活用に役立ちます。 これは、データベース アプリケーションなど、I/O のサイズが小さいワークロードに便利です。
- ネットワーク フォールト トレランス: 複数接続により、クライアントが単一の接続に依存しなくなるため、中断のリスクが軽減されます。
- 自動構成: クライアントとストレージ アカウントで SMB マルチチャネルを有効にすると、既存の接続を動的に検出できるようになり、必要に応じて追加の接続パスを作成できます。
- コストの最適化:ワークロードは、Premium 共有に接続しながら、単一の VM または小さな VM セットからスケールアップできます。 これにより、ワークロードを実行および管理するために必要な VM の数が減り、総保有コストを削減できます。
SMB マルチチャネルの詳細については、Windows のドキュメントを参照してください。
この機能により、マルチスレッド アプリケーションのパフォーマンスが向上するメリットが得られますが、通常シングルスレッド アプリケーションには役立ちません。 詳細については、「パフォーマンスの比較」セクションを参照してください。
制限事項
Azure ファイル共有の SMB マルチチャネルには、現在、次の制限があります。
- Premium Azure ファイル共有でのみ使用できます。 Standard Azure ファイル共有では使用できません。
- SMB 3.1.1 を使用している Windows クライアントでのみサポートされます。 SMB クライアント オペレーティング システムに推奨レベルの修正プログラムが適用されていることを確認します。
- Linux クライアントでは現在サポートされていないか、推奨されていません。
- チャネルの最大数は 4 です。詳細については、こちらを参照してください。
構成
SMB マルチチャネルは、機能がクライアント側 (お使いのクライアント) とサービス側 (お使いの Azure ストレージ アカウント) の両方で有効になっている場合にのみ機能します。
Windows クライアントでは、SMB マルチチャネルが既定で有効になっています。 次の PowerShell コマンドを実行して、構成を確認できます。
Get-SmbClientConfiguration | Select-Object -Property EnableMultichannel
Azure ストレージ アカウントで SMB マルチチャネルが有効になっていない場合は、SMB マルチチャネルの状態に関するページを参照してください。
SMB マルチチャネルを無効にする
ほとんどのシナリオ (特にマルチスレッドのワークロード) では、クライアントのパフォーマンスは SMB マルチチャネルにより向上するはずです。 しかしながら、シングルスレッドのワークロードやテスト目的など、特定のシナリオでは、SMB マルチチャネルを無効にした方がよい場合があります。 詳細については、「パフォーマンスの比較」と SMB マルチチャネルの状態に関するページを参照してください。
SMB マルチチャネルが正しく構成されていることを確認する
- 新しい Premium ファイル共有を作成するか、既存の Premium 共有を使用します。
- クライアントが SMB マルチチャネルをサポートしている (1 つまたは複数のネットワーク アダプターの Receive Side Scaling が有効になっている) ことを保証します。 詳細については、Windows のドキュメントを参照してください。
- クライアントにファイル共有をマウントします。
- アプリケーションで負荷を生成します。 robocopy /MT などのコピー ツールや Diskspd などのパフォーマンス ツールを使用してファイルの読み取り/書き込みを行うと、負荷を生じさせることができます。
- 管理者として PowerShell を開き、次のコマンドを使用します:
Get-SmbMultichannelConnection |fl
- MaxChannels および CurrentChannels プロパティを検索します。
パフォーマンスの比較
読み取り/書き込みのワークロード パターンには、シングルスレッドとマルチスレッドの 2 つのカテゴリがあります。 ほとんどのワークロードで複数のファイルが使用されますが、共有内の 1 つのファイルを使ってワークロードが動作する特殊なユース ケースがあります。 このセクションでは、それぞれのユース ケースとパフォーマンスへの影響について説明します。 一般に、ほとんどのワークロードはマルチスレッドであり、ワークロードが複数のファイルに分散されるため、SMB マルチチャネルを使用することでパフォーマンスの大幅な向上が見られるはずです。
- マルチスレッド、複数ファイル: ワークロード パターンによっては、複数のチャネルでの読み取りと書き込みの I/O のパフォーマンスが大幅に向上するはずです。 IOPS、スループット、待ち時間について、パフォーマンスが 2 から 4 倍向上します。 このカテゴリでは、最適なパフォーマンスを実現するために SMB マルチチャネルを有効にする必要があります。
- マルチスレッド、単一ファイル: このカテゴリのほとんどのユース ケースでは、特にワークロードの平均 I/O サイズが約 16k を超える場合、ワークロードは SMB マルチチャネルを有効にすることでメリットが得られます。 SMB マルチチャネルのメリットが得られるシナリオ例としては、大きな単一ファイルのバックアップや回復があります。 例外として SMB マルチチャネルを無効にした方がよいのは、I/O が小さくてワークロードが重い場合です。 この場合、10% ほどのわずかなパフォーマンス低下が見られることがあります。 ユース ケースに応じて、複数のファイルに負荷を分散させるか、機能を無効にすることを検討してください。 詳細については、「構成」セクションを参照してください。
- シングルスレッド、複数ファイルまたは単一ファイル: ほとんどのシングルスレッド ワークロードでは、並列処理がないため、パフォーマンス上の利点は最小限にとどまります。 SMB マルチチャネルが有効になっている場合、通常は 10% ほどのわずかなパフォーマンスの低下が見られます。 この場合は、SMB マルチチャネルを無効にすることをお勧めします。ただし、例外が 1 つあります。 シングルスレッドのワークロードで複数のファイルに負荷を分散でき、かつ大きめの平均 I/O サイズ (約 16k 超) で使用する場合は、SMB マルチチャネルによって多少のパフォーマンス上の利点が得られます。
パフォーマンス テストの構成
この記事のグラフで使用されている構成は、単一の標準 D32s v3 VM で、単一の RSS 対応 NIC を備え、チャネルは 4 つです。 負荷の生成には、diskspd.exe をマルチスレッドで使用しました。IO 深度は 10、様々な I/O サイズのランダムな I/O です。
サイズ | vCPU | メモリ:GiB | 一時ストレージ (SSD) GiB | 最大データ ディスク数 | キャッシュが有効な場合の一時ストレージの最大スループット: IOPS/MBps (キャッシュ サイズは GiB 単位) | キャッシュが無効な場合の最大ディスク スループット: IOPS/MBps | 最大 NIC 数 | 必要なネットワーク帯域幅 (Mbps) |
---|---|---|---|---|---|---|---|---|
Standard_D32s_v3 | 32 | 128 | 256 | 32 | 64000/512 (800) | 51200/768 | 8 | 16000 |
SMB マルチチャネルを使用した、マルチスレッド/複数ファイル
負荷は、IO サイズが異なる 10 個のファイルに対して生成されました。 スケールアップ テストの結果には、SMB マルチチャネルを有効にした IOPS とスループットのテスト結果の両方で大幅な改善が示されました。 それぞれの結果を以下の図に示します。
- 単一の NIC で、読み取りの場合は 2 から 3 倍のパフォーマンス向上、書き込みの場合は IOPS とスループットの両方で 3 から 4 倍の向上が見られました。
- NIC が 1 つ、チャネルが 4 つという制限があっても、SMB マルチチャネルにより、IOPS とスループットが VM の制限に達することができました。
- エグレス (またはストレージへの読み取り) は測定されないため、読み取りスループットが、VM の公開上限である 16,000 Mbps (2 GiB/s) を超えることができました。 テストは 2.7 GiB/s 超を達成しました。 イングレス (またはストレージへの書き込み) は引き続き VM の制限が適用されます。
- 複数のファイルに負荷を分散することにより、大幅な改善が可能になりました。
このテストで使用されるコマンドの例を次に示します。
diskspd.exe -W300 -C5 -r -w100 -b4k -t8 -o8 -Sh -d60 -L -c2G -Z1G z:\write0.dat z:\write1.dat z:\write2.dat z:\write3.dat z:\write4.dat z:\write5.dat z:\write6.dat z:\write7.dat z:\write8.dat z:\write9.dat
SMB マルチチャネルを使用したマルチスレッド、単一ファイルのワークロード
この負荷は、128 GiB の単一ファイルに対して生成されました。 SMB マルチチャネルを有効にすると、マルチスレッド、単一ファイルを使用したスケールアップ テストのほとんどの場合に改善が見られました。 それぞれの結果を以下の図に示します。
- 平均 I/O サイズが大きい (約 16k 超) の単一の NIC では、読み取りと書き込みの両方が大幅に改善しました。
- I/O サイズが小さい場合は、SMB マルチチャネルが有効になっていると、パフォーマンスに与える影響はわずかで 10% ほどでした。 これは、複数のファイルに負荷を分散するか、機能を無効にすることで軽減できます。
- パフォーマンスは、単一ファイルの制限に引き続き縛られます。
Premium SMB ファイル共有のためのメタデータ キャッシュ
メタデータ キャッシュは、SMB Azure Premium のファイル共有のための機能強化であり、メタデータの待機時間の短縮、使用可能な IOPS の増加、ネットワーク スループットの向上を目的としています。 このプレビュー機能は、次のメタデータ API を向上させ、Windows と Linux 両方のクライアントから使用できます。
- 作成
- [ファイル]
- 閉じる
- 削除
オンボードするには、パブリック プレビューにサインアップすると、追加の詳細をお知らせします。 現在、このプレビュー機能は、Premium SMB ファイル共有 (FileStorage ストレージ アカウントの種類でのファイル共有) でのみ使用できます。 この機能の使用に関連してコストが増えることはありません。
リージョン別の提供状況
現在、メタデータ キャッシュ (プレビュー) は、次の Azure リージョンでのみ使用できます。
- オーストラリア東部
- ブラジル南東部
- フランス南部
- ドイツ中西部
- スイス北部
- アラブ首長国連邦中部
- アラブ首長国連邦北部
- 米国中西部
メタデータ キャッシュによるパフォーマンスの向上
メタデータを含むほとんどのワークロードまたは使用パターンは、メタデータ キャッシュを使うことでメリットがあります。 ワークロードにメタデータが含まれるかどうかを判断するには、Azure Monitor を使用して、API ディメンション別にトランザクションを分割できます。
一般に、次のようなワークロードと使用パターンでメタデータが多くなります。
- Web サービスやアプリ サービス
- DevOps タスク
- インデックス作成ジョブやバッチ ジョブ
- ホーム ディレクトリや、多くの小さいファイル、ディレクトリ、またはハンドルと主に対話するその他のワークロードを含む仮想デスクトップ
次の図は、可能性のある結果を示したものです。
メタデータの待ち時間を短縮する
メタデータ キャッシュを使って、将来の検索のためにファイルとディレクトリのパスをキャッシュすると、メタデータの多い大規模なワークロードの場合、頻繁にアクセスされるファイルとディレクトリの待ち時間を 30% 以上短縮できます。
使用可能な IOPS を増やす
メタデータ キャッシュを使うと、メタデータの多い大規模なワークロードの場合、利用できる IOPS を 60% より多く増やすことができます。
ネットワーク スループットを増やす
メタデータ キャッシュを使うと、メタデータの多い大規模なワークロードの場合、ネットワーク スループットを 60% より多く増やすことができます。
次のステップ
- SMB マルチチャネルの状態を確認する
- SMB マルチチャネルに関する Windows ドキュメント を参照してください
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示