次の方法で共有

SMB Azure ファイル共有のパフォーマンスを向上させる

適用対象: ✔️ SMB Azure ファイル共有

この記事では、SMB マルチチャネルやメタデータ キャッシュの使用など、SSD (Premium) SMB Azure ファイル共有のパフォーマンスを向上させる方法について説明します。

パフォーマンスの最適化

次のヒントを参考にして、パフォーマンスを最適化することができます。

  • ネットワーク待機時間を短縮するために、ストレージ アカウントとクライアントが同じ Azure リージョンにあることを確認します。
  • マルチスレッド アプリケーションを使用し、複数のファイルに負荷を分散します。
  • SMB マルチチャネルのパフォーマンス上の利点は、負荷を分散するファイルの数に伴って増加します。
  • SSD 共有のパフォーマンスは、IOPS とスループット、単一ファイルの制限など、プロビジョニングされた共有サイズによって制限されます。 詳細については、 プロビジョニング v1 モデルの理解を参照してください。
  • 1 つの仮想マシン (VM) クライアントの最大パフォーマンスは、引き続き VM の制限にバインドされます。 たとえば、 Standard_D32s_v3 は最大帯域幅約 1.86 GiB/秒をサポートします。VM からのエグレス (ストレージへの書き込み) は従量制課金されますが、イングレス (ストレージからの読み取り) は行われません。 ファイル共有のパフォーマンスは、コンピューターのネットワーク制限、CPU、使用可能な内部ストレージのネットワーク帯域幅、IO サイズ、並列処理、およびその他の要因の影響を受けます。
  • 通常、最初のテストはウォームアップです。 結果を破棄し、テストを繰り返します。
  • 単一のクライアントによってパフォーマンスが制限され、ワークロードがプロビジョニングされた共有制限を下回っている場合は、複数のクライアントに負荷を分散することで、より高いパフォーマンスを実現できます。

IOPS、スループット、I/O サイズの関係

スループット = IO サイズ * IOPS

I/O サイズが大きいほどスループットが向上し、待機時間が長くなり、結果としてネット IOPS の数が少なくなります。 I/O サイズを小さくすると、IOPS が高くなりますが、ネット スループットと待機時間が低下します。 詳細については、「Azure Files のパフォーマンスについて」を参照してください。

SMB マルチチャネル

SMB マルチチャネルを使用すると、SMB クライアントは SMB ファイル共有への複数のネットワーク接続を確立でき、スループットと回復性が向上します。 Azure Files では、Windows と Linux の両方の SMB クライアントの SSD ファイル共有で SMB マルチチャネルがサポートされています。 サポートされている Linux OS のバージョンと詳細な構成については、「Linux SMB マルチチャネル」セクションを参照してください。

Linux SMB マルチチャネルのサポート

Azure Files では、次のディストリビューションでネイティブ Linux SMB クライアントを使用する SMB マルチチャネルがサポートされています。

  • Ubuntu 24.04 AKS: 6.8.0-1042
  • Ubuntu 24.04 VM: 6.14.0-1017
  • Ubuntu 22.04 VM: 6.8.0-1044
  • AzLinux 3.0 (VM と AKS): 6.6.106.1
  • RHEL 9.7: 5.14.0-611.5.1.el9_7
  • RHEL 10.1: 6.12.0-124.8.1.el10_1

これらのクライアントは、マルチチャネルをサポートする適切なカーネル スタックおよび CIFS ユーティリティを実行している必要があります。 Linux での SMB マルチチャネルのサポートにより、同じファイル共有エンドポイントへの複数の並列 TCP 接続を確立することで、Windows と同様のパフォーマンス スケーリングが可能になります。

[前提条件]

Linux で SMB マルチチャネルを使用するための前提条件を次に示します。

  • SMB マルチチャネルのサポートが有効になっているカーネル (通常は 6.8 以上、 max_channels = 4 マウント フラグを使用)
  • SMB 3.1.1
  • クライアントと Azure Files エンドポイントの間でポート 445/TCP を開く
  • クライアント側の受信側スケーリング (RSS) がマルチキュー サポートに対して有効になっていることを確認する

mount コマンドの例

Linux で SMB マルチチャネルを使用するための mount コマンドの例を次に示します。

mount -t cifs //<storageaccount>.file.core.windows.net/<share> /mnt/azfiles \
   -o vers=3.1.1,username=<account>,password=<key>,dir_mode=0777,file_mode=0777, \
   multiuser,serverino,actimeo=30,max_channels=4

メリット

SMB マルチチャネルを使用すると、クライアントから、複数のネットワーク接続を使用して、パフォーマンスを向上させることができ、所有コストも削減します。 複数の NIC の帯域幅を集約し、Receive Side Scaling (RSS) サポートを利用して NIC の I/O 負荷を複数の CPU に分散できるようにすることで、パフォーマンス向上を達成します。

  • スループットの向上: 複数接続により、複数のパスでデータを並列で転送できるため、ファイルのサイズが大きく、I/O のサイズが大きいファイルを使用し、単一の VM または小さな VM セットからの高スループットを必要とするワークロードに大きなメリットがあります。 これらのワークロードには、コンテンツ作成やコード変換のためのメディアやエンターテインメント、ゲノミクス、金融サービスのリスク分析などがあります。
  • 高 IOPS:NIC RSS 機能を使用すると、複数の CPU で複数の接続がある場合に効果的な負荷分散を行うことができます。 これは、より高い IOPS スケールと VM CPU の有効活用に役立ちます。 これは、データベース アプリケーションなど、I/O のサイズが小さいワークロードに便利です。
  • ネットワーク フォールト トレランス: 複数接続により、クライアントが単一の接続に依存しなくなるため、中断のリスクが軽減されます。
  • 自動構成: クライアントとストレージ アカウントで SMB マルチチャネルを有効にすると、既存の接続を動的に検出できるようになり、必要に応じて追加の接続パスを作成できます。
  • コストの最適化: ワークロードは、SSD ファイル共有に接続しながら、単一の VM または少数の VM からより高いスケールを実現できます。 これにより、ワークロードを実行および管理するために必要な VM の数が減り、総保有コストを削減できます。
  • Linux クライアントのパフォーマンススケーリング: Linux SMB クライアントは、Windows と同様に、マルチチャネルを利用してスループットと IOPS を向上できるようになりました。
  • クロスプラットフォームの一貫性: 最適なパフォーマンスを実現する Windows クライアントと Linux クライアントの両方でハイブリッド環境を実現します。
  • 回復性: 複数のチャネルによって、異種ネットワークに対するフォールト トレランスが向上します。

SMB マルチチャネルの詳細については、 Windows のドキュメントを参照してください。

この機能により、マルチスレッド アプリケーションのパフォーマンスが向上するメリットが得られますが、通常シングルスレッド アプリケーションには役立ちません。 詳細については、「パフォーマンスの比較」セクションを参照してください。

制限事項

Azure ファイル共有の SMB マルチチャネルには、現在、次の制限があります。

  • SSD ファイル共有でのみ使用できます。 HDD Azure ファイル共有では使用できません。
  • SMB 3.1.1 を使用しているクライアントでのみサポートされます。 SMB クライアント オペレーティング システムに推奨レベルの修正プログラムが適用されていることを確認します。
  • チャネルの最大数は 4 です。 詳細については、 こちらを参照してください。

Windows の構成

SMB マルチチャネルは、機能がクライアント側 (お使いのクライアント) とサービス側 (お使いの Azure ストレージ アカウント) の両方で有効になっている場合にのみ機能します。

Windows クライアントでは、SMB マルチチャネルが既定で有効になっています。 次の PowerShell コマンドを実行して、構成を確認できます。

Get-SmbClientConfiguration | Select-Object -Property EnableMultichannel

Azure ストレージ アカウントで SMB マルチチャネルが有効になっていない場合は、SMB マルチチャネルの状態に関するページを参照してください。

SMB マルチチャネルを無効にする

ほとんどのシナリオ (特にマルチスレッド ワークロード) では、クライアントは SMB マルチチャネルを使用してパフォーマンスが向上します。 しかしながら、シングルスレッドのワークロードやテスト目的など、特定のシナリオでは、SMB マルチチャネルを無効にした方がよい場合があります。 詳細については、「パフォーマンスの比較」と SMB マルチチャネルの状態に関するページを参照してください。

SMB マルチチャネルが正しく構成されていることを確認する

  1. 新しい SSD ファイル共有を作成するか、既存の SSD ファイル共有を使用します。
  2. クライアントが SMB マルチチャネルをサポートしている (1 つまたは複数のネットワーク アダプターの Receive Side Scaling が有効になっている) ことを保証します。 詳細については、Windows のドキュメントを参照してください。
  3. クライアントにファイル共有をマウントします。
  4. アプリケーションで負荷を生成します。 robocopy /MT などのコピー ツールや Diskspd などのパフォーマンス ツールを使用してファイルの読み取り/書き込みを行うと、負荷を生じさせることができます。
  5. 管理者として PowerShell を開き、次のコマンドを使用します: Get-SmbMultichannelConnection |fl
  6. MaxChannels および CurrentChannels プロパティを検索します。

パフォーマンスの比較

読み取り/書き込みのワークロード パターンには、シングルスレッドとマルチスレッドの 2 つのカテゴリがあります。 ほとんどのワークロードで複数のファイルが使用されますが、共有内の 1 つのファイルを使ってワークロードが動作する特殊なユース ケースがあります。 このセクションでは、それぞれのユース ケースとパフォーマンスへの影響について説明します。 一般に、ほとんどのワークロードはマルチスレッドであり、ワークロードが複数のファイルに分散されるため、SMB マルチチャネルを使用することでパフォーマンスの大幅な向上が見られるはずです。

  • マルチスレッド、複数ファイル: ワークロード パターンによっては、複数のチャネルでの読み取りと書き込みの I/O のパフォーマンスが大幅に向上するはずです。 IOPS、スループット、待ち時間について、パフォーマンスが 2 から 4 倍向上します。 このカテゴリでは、最適なパフォーマンスを実現するために SMB マルチチャネルを有効にする必要があります。
  • マルチスレッド/単一ファイル: このカテゴリのほとんどのユース ケースでは、特にワークロードの平均 I/O サイズが最大 16,000 > の場合、ワークロードで SMB マルチチャネルを有効にするとメリットがあります。 SMB マルチチャネルのメリットが得られるシナリオ例としては、大きな単一ファイルのバックアップや回復があります。 例外として SMB マルチチャネルを無効にした方がよいのは、I/O が小さくてワークロードが重い場合です。 その場合、約 10%のわずかなパフォーマンス損失が発生する可能性があります。 ユース ケースに応じて、複数のファイルに負荷を分散させるか、機能を無効にすることを検討してください。
  • シングルスレッド、複数ファイルまたは単一ファイル: ほとんどのシングルスレッド ワークロードでは、並列処理がないため、パフォーマンス上の利点は最小限にとどまります。 通常、SMB マルチチャネルが有効になっている場合、10% のパフォーマンスが若干低下します。 この場合は、SMB マルチチャネルを無効にすることをお勧めします。ただし、例外が 1 つあります。 シングルスレッド ワークロードが複数のファイルに負荷を分散でき、平均で大きい I/O サイズ (16 KiB を超える) で使用する場合、SMB マルチチャネルのパフォーマンスにわずかな利点があるはずです。

パフォーマンス テストの構成

この記事のグラフで使用されている構成は、単一の標準 D32s v3 VM で、単一の RSS 対応 NIC を備え、チャネルは 4 つです。 負荷の生成には、diskspd.exe をマルチスレッドで使用しました。IO 深度は 10、様々な I/O サイズのランダムな I/O です。

SMB マルチチャネルを使用した、マルチスレッド/複数ファイル

負荷は、IO サイズが異なる 10 個のファイルに対して生成されました。 スケールアップ テストの結果には、SMB マルチチャネルを有効にした IOPS とスループットのテスト結果の両方で大幅な改善が示されました。 それぞれの結果を以下の図に示します。

パフォーマンスのダイアグラム。

スループットのパフォーマンスの図。

  • 単一の NIC で、読み取りの場合は 2 から 3 倍のパフォーマンス向上、書き込みの場合は IOPS とスループットの両方で 3 から 4 倍の向上が見られました。
  • NIC が 1 つ、チャネルが 4 つという制限があっても、SMB マルチチャネルにより、IOPS とスループットが VM の制限に達することができました。
  • エグレス (またはストレージへの読み取り) は従量制課金されないため、読み取りスループットは VM の公開されている約 1.86 GiB/秒の制限を超えることができました。テストは 2.7 GiB/秒を超える値を達成しました。イングレス (またはストレージへの書き込み) は、引き続き 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 マルチチャネルを有効にすると、マルチスレッド、単一ファイルを使用したスケールアップ テストのほとんどの場合に改善が見られました。 それぞれの結果を以下の図に示します。

IOPS パフォーマンスの図。

単一ファイルのスループット パフォーマンスの図。

  • 平均 I/O サイズ (16 KiB を超える) が大きい 1 つの NIC では、読み取りと書き込みの両方が大幅に改善されました。
  • I/O サイズが小さい場合、SMB マルチチャネルを有効にした場合のパフォーマンスに対する影響は約 10% でした。 これは、複数のファイルに負荷を分散するか、機能を無効にすることで軽減できます。
  • パフォーマンスは、単一ファイルの制限に引き続き縛られます。

SSD ファイル共有のメタデータ キャッシュ

メタデータ キャッシュは、メタデータの待機時間を短縮し、メタデータスケールの制限を引き上げる SSD Azure ファイル共有の機能強化です。 この機能により、待機時間の整合性と使用可能な IOPS が向上し、ネットワーク スループットが向上します。

この機能により、次のメタデータ API のパフォーマンスが向上します。 Windows クライアントと Linux クライアントの両方で使用できます。

  • メタデータ スケール制限の引き上げ
  • 待機時間の一貫性、利用可能な IOPS の向上、ネットワーク スループットの向上

この機能により、次のメタデータ API が向上し、Windows クライアントと Linux クライアントの両方から使用できます。

  • 作成
  • 開く
  • 閉じる
  • 削除

現在、この機能は SSD ファイル共有でのみ使用できます。 この機能の使用に関連する追加コストはありません。 また、登録して SSD ファイル共有のファイル ハンドルの制限を増やすこともできます (プレビュー)。

メタデータ キャッシュ機能に登録する

使用を開始するには、Azure portal または Azure PowerShell を使用してこの機能に登録します。

  1. Azure portal にサインインします。
  2. [プレビュー機能] を検索して選択します。
  3. [種類] フィルターを選択し、[Microsoft.Storage] を選択します。
  4. Azure Premium Files メタデータ キャッシュを選択し、[登録] を選択します。

重要

  • プレビュー機能の一覧に記載されていますが、GA SLA が適用され、間もなくすべてのアカウントでこの設定が既定値になり、登録が不要になります。
  • AFEC登録後は、 azfilespreview@microsoft.com にお問い合わせください。

メタデータ キャッシュによるパフォーマンスの向上

メタデータを含むほとんどのワークロードまたは使用パターンは、メタデータ キャッシュを使うことでメリットがあります。 ワークロードにメタデータが含まれるかどうかを判断するには、Azure Monitor を使用して、API ディメンション別にトランザクションを分割できます。

一般に、次のようなワークロードと使用パターンでメタデータが多くなります。

  • Web サービスやアプリ サービス
  • DevOps タスク
  • インデックス作成ジョブやバッチ ジョブ
  • ホーム ディレクトリや、多くの小さいファイル、ディレクトリ、またはハンドルと主に対話するその他のワークロードを含む仮想デスクトップ

次の図は、可能性のある結果を示したものです。

メタデータの待ち時間を短縮する

メタデータ キャッシュを使って、将来の検索のためにファイルとディレクトリのパスをキャッシュすると、メタデータの多い大規模なワークロードの場合、頻繁にアクセスされるファイルとディレクトリの待ち時間を 30% 以上短縮できます。

メタデータ キャッシュがある場合とない場合の待機時間をミリ秒単位で示すグラフ。

使用可能な IOPS を増やす

メタデータ キャッシュを使うと、メタデータの多い大規模なワークロードの場合、利用できる IOPS を 60% より多く増やすことができます。

メタデータ キャッシュがある場合とない場合の使用可能な IOPS を示すグラフ。

ネットワーク スループットを増やす

メタデータ キャッシュを使うと、メタデータの多い大規模なワークロードの場合、ネットワーク スループットを 60% より多く増やすことができます。

メタデータ キャッシュがある場合とない場合のネットワーク スループットを示すグラフ。

ファイルハンドル上限値の引き上げに登録する (プレビュー)

SSD SMB ファイル共有のファイルとディレクトリごとの同時実行ハンドルの最大数を 2,000 から 10,000 に増やすには、Azure portal または Azure PowerShell を使用してプレビュー機能に登録します。 ご質問がある場合は、メール azfilespreview@microsoft.com。

  1. Azure portal にサインインします。
  2. [プレビュー機能] を検索して選択します。
  3. [種類] フィルターを選択し、[Microsoft.Storage] を選択します。
  4. [Azure Premium Files の最大オープン ハンドル数の増加] を選択し、[登録] を選択します。

次のステップ

  • Last updated on