次の方法で共有

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

この記事では、ネットワーク ファイル システム (NFS) の Azure ファイル共有のパフォーマンスを向上させる方法について説明します。

適用対象

管理モデル 課金モデル メディア階層 冗長性 中小企業 ネットワークファイルシステム（NFS）
Microsoft.Storage プロビジョニング済み v2 HDD (標準) ローカル (LRS) いいえ いいえ
Microsoft.Storage プロビジョニング済み v2 HDD (標準) ゾーン (ZRS) いいえ いいえ
Microsoft.Storage プロビジョニング済み v2 HDD (標準) ジオ （GRS） いいえ いいえ
Microsoft.Storage プロビジョニング済み v2 HDD (標準) ジオゾーン (GZRS) いいえ いいえ
Microsoft.Storage プロビジョニング済み v1 SSD (プレミアム) ローカル (LRS) いいえ はい
Microsoft.Storage プロビジョニング済み v1 SSD (プレミアム) ゾーン (ZRS) いいえ はい
Microsoft.Storage 従量課金制 HDD (標準) ローカル (LRS) いいえ いいえ
Microsoft.Storage 従量課金制 HDD (標準) ゾーン (ZRS) いいえ いいえ
Microsoft.Storage 従量課金制 HDD (標準) ジオ （GRS） いいえ いいえ
Microsoft.Storage 従量課金制 HDD (標準) ジオゾーン (GZRS) いいえ いいえ

先行読み取りサイズを増やして読み取りスループットを向上させる

Linux の read_ahead_kb カーネル パラメーターは、シーケンシャル読み取り操作中に "先行読み取り" またはプリフェッチする必要があるデータの量を表します。 Linux カーネル バージョン 5.4 より前では、先行読み取り値が、マウントされたファイル システムの rsize の 15 倍 (読み取りバッファー サイズのクライアント側マウント オプション) に相当するように設定されます。 これにより、先行読み取り値が十分に高く設定され、ほとんどの場合にクライアントのシーケンシャル読み取りスループットが向上します。

ただし、Linux カーネル バージョン 5.4 以降の Linux NFS クライアントでは、既定の read_ahead_kb 値である 128 KiB を使います。 このような小さな値を使うと、大きなファイルでは読み取りスループットの量が減る場合があります。 より大きな先行読み取り値を含む Linux リリースから 128 KiB の既定値を含む Linux リリースにアップグレードするお客様は、シーケンシャル読み取りパフォーマンスの低下が発生する場合があります。

Linux カーネル 5.4 以降については、パフォーマンス向上のために、read_ahead_kb を常に 15 MiB に設定しておくことをお勧めします。

この値を変更するには、Linux カーネル デバイス マネージャーである udev にルールを追加して、先行読み取りサイズを設定します。 次の手順のようにします。

  1. テキスト エディターで、次のテキストを入力し、保存して、/etc/udev/rules.d/99-nfs.rules ファイルを作成します。

    SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

  2. コンソールで、udevadm コマンドをスーパーユーザーとして実行し、ルール ファイルとその他のデータベースを再読み込みして、udev ルールを適用します。 udev で新しいファイルが認識されるために必要なのは、このコマンドを 1 回実行することのみです。

    sudo udevadm control --reload

NFS nconnect

NFS nconnect は NFS ファイル共有のクライアント側マウント オプションであり、クライアントと NFS ファイル共有の間で複数の TCP 接続を使用できます。

メリット

nconnect を使用すると、少数のクライアント マシンを使用して大規模なパフォーマンスを向上させ、総保有コスト (TCO) を削減できます。 nconnect 機能は、1 つまたは複数の NIC で複数の TCP チャネルを使用し、単一または複数のクライアントを使用することでパフォーマンスを向上させます。 nconnect を使用しない場合、最大の SSD ファイル共有プロビジョニング サイズによって提供される帯域幅スケール制限 (10 GiB/秒) を実現するには、約 20 台のクライアント マシンが必要です。 nconnect を使用すると、6 ~ 7 個のクライアントのみを使用してこれらの制限を実現でき、コンピューティング コストを 70% 近く削減しながら、1 秒あたりの I/O 操作 (IOPS) とスループットを大幅に向上させることができます。 次のテーブルを参照してください。

メトリック (操作) I/O サイズ パフォーマンス改善
IOPS (書き込み) 64 KiB、1,024 KiB 3x
IOPS (読み取り) すべての I/O サイズ 2 - 4 倍
スループット (書き込み) 64 KiB、1,024 KiB 3x
スループット (読み取り) すべての I/O サイズ 2 - 4 倍

必須コンポーネント

  • 最新の Linux ディストリビューションでは、nconnect が完全にサポートされています。 古い Linux ディストリビューションの場合は、Linux カーネルのバージョンが 5.3 以降であることを確認してください。
  • マウントごとの構成は、プライベート エンドポイント経由でストレージ アカウントごとに 1 つのファイル共有が使用される場合にのみサポートされます。

パフォーマンスへの影響

Linux クライアント上の NFS Azure ファイル共有で nconnect マウント オプションを大規模に使用すると、次のパフォーマンスの結果が得られます。 これらの結果の達成方法の詳細については、「パフォーマンス テストの構成」を参照してください。

NFS Azure ファイル共有で nconnect を使用するときの IOPS の平均改善を示すスクリーンショット。

NFS Azure ファイル共有で nconnect を使用するときのスループットの平均改善を示すスクリーンショット。

推奨事項

nconnect から最適な結果を得るには、これらの推奨事項に従います。

nconnect=4 を設定します

Azure Files では nconnect の最大設定 16 までの設定がサポートされていますが、nconnect=4 の最適な設定でマウント オプションを構成することをお勧めします。 現時点では、nconnect の Azure Files 実装では、4 つのチャネルを超える利益はありません。 実際、1 つのクライアントから 1 つの Azure ファイル共有に対してチャネルが 4 つを超えると、TCP ネットワークの飽和が原因でパフォーマンスに悪影響を及ぼす可能性があります。

仮想マシンのサイズを慎重に設定する

ワークロードの要件に応じて、 予想されるネットワーク帯域幅によって制限されないように、クライアント仮想マシン (VM) のサイズを正しく設定することが重要です。 予想されるネットワーク スループットを実現するために複数の NIC が必要になることはありません。 Azure Files で汎用 VM を使用するのが一般的ですが、ワークロードのニーズとリージョンの可用性に応じて、さまざまな種類の VM を使用できます。 詳しくは、Azure VM セレクターに関する記事をご覧ください。

キューの深さを 64 以下に保つ

キューの深さは、ストレージ リソースがサービスを提供できる未処理の I/O 要求の数です。 それ以上のパフォーマンス向上は見込まれないため、最適なキューの深さを 64 を超えて設定することはお勧めしません。 詳細については、「キューの深さ」を参照してください。

マウントごとの構成

ワークロードで、1 つのクライアントとは異なる nconnect 設定を持つ 1 つ以上のストレージ アカウントで複数の共有をマウントする必要がある場合、パブリック エンドポイント経由でマウントするときにそれらの設定が保持されることを保証することはできません。 マウントごとの構成は、シナリオ 1 で説明されているように、プライベート エンドポイント経由でストレージ アカウントごとに 1 つの Azure ファイル共有が使用されている場合にのみサポートされます。

シナリオ 1: 複数のストレージ アカウントを持つプライベート エンドポイント経由でのマウントごとの構成 (サポートされています)

  • StorageAccount.file.core.windows.net = 10.10.10.10
  • StorageAccount2.file.core.windows.net = 10.10.10.11
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
    • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

シナリオ 2: パブリック エンドポイント上でのマウント構成ごと (サポートされていません)

  • StorageAccount.file.core.windows.net = 52.239.238.8
  • StorageAccount2.file.core.windows.net = 52.239.238.7
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
    • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

注

ストレージ アカウントが別の IP アドレスに解決された場合でも、パブリック エンドポイントは静的アドレスではないので、そのアドレスが保持されることを保証できません。

シナリオ 3: 1 つのストレージ アカウントに複数の共有がある環境で、マウント構成ごとの設定をプライベート エンドポイントを通じて行う場合 (サポートされていません)

  • StorageAccount.file.core.windows.net = 10.10.10.10
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

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

この記事で概説されている結果を達成および測定するために、次のリソースとベンチマーク ツールを使用しました。

  • 単一クライアント: 単一 NIC を使用した Azure VM (DSv4-Series)
  • OS: Linux (Ubuntu 20.40)
  • NFS ストレージ: SSD ファイル共有 (30 TiB をプロビジョニング済み、nconnect=4 の設定)
[サイズ] vCPU [メモリ] 一時ストレージ (SSD) 最大データ ディスク数 最大 NIC 数 予想されるネットワーク帯域幅
Standard_D16_v4 16 64 GiB リモート ストレージのみ 32 8 12,500 Mbps

ベンチマーク ツールとテスト

ベンチマークとストレス/ハードウェア検証の両方に使用される、無償かつオープンソースのディスク I/O ツールである Flexible I/O Tester (FIO) を使用しました。 FIO をインストールするには、FIO README ファイルの「Binary Packages」セクションに従って、任意のプラットフォームにインストールします。

これらのテストはランダムな I/O アクセス パターンに焦点を当てていますが、シーケンシャル I/O を使用するときも同様の結果が得られます。

高い IOPS: 100% 読み取り

I/O サイズ 4k - ランダム読み取り - キューの深さ 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

I/O サイズ 8k - ランダム読み取り - キューの深さ 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

高スループット: 100% 読み取り

64 KiB I/O サイズ - ランダム読み取り - 64 キューの深さ

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

I/O サイズ 1,024 KiB - 100% ランダム読み取り - キューの深さ 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

高い IOPS: 100% 書き込み

I/O サイズ 4 KiB - 100% ランダム書き込み - キューの深さ 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

I/O サイズ 8 KiB - 100% ランダム書き込み - キューの深さ 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

高スループット: 100% 書き込み

I/O サイズ 64 KiB - 100% ランダム書き込み - キューの深さ 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

I/O サイズ 1024 KiB - 100% ランダム書き込み - キューの深さ 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

nconnect のパフォーマンスに関する考慮事項

nconnect マウント オプションを使用する場合は、次の特性を持つワークロードを厳密に評価する必要があります。

  • シングル スレッドであるか、低いキューの深さ (16 未満) を使用する、待機時間の影響を受けやすい書き込みワークロード
  • シングル スレッドであるか、小さい I/O サイズと組み合わせて低いキューの深さを使用する、待機時間の影響を受けやすい読み取りワークロード

すべてのワークロードで、高スケールの IOPS やスループット パフォーマンスが必要なわけではありません。 小規模なワークロードの場合、nconnect は意味をなさない可能性があります。 次の表を使って、nconnect が自分のワークロードに役立つかどうかを判断します。 緑色で強調表示されているシナリオは推奨されていますが、赤で強調表示されているシナリオは推奨されていません。 黄色で強調表示されているのは中立的なシナリオです。

nconnect が推奨される場合を示すために、さまざまな読み取りと書き込みの I/O シナリオと、対応する待機時間を示したスクリーンショット。

関連項目