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

  • [アーティクル]

この記事では、NFS Azure ファイル共有のパフォーマンスを向上させることができる方法について説明します。

適用対象

ファイル共有の種類 SMB NFS
Standard ファイル共有 (GPv2)、LRS/ZRS No, this article doesn't apply to standard SMB Azure file shares LRS/ZRS. NFS shares are only available in premium Azure file shares.
Standard ファイル共有 (GPv2)、GRS/GZRS No, this article doesn't apply to standard SMB Azure file shares GRS/GZRS. NFS is only available in premium Azure file shares.
Premium ファイル共有 (FileStorage)、LRS/ZRS No, this article doesn't apply to premium SMB Azure file shares. Yes, this article applies to premium NFS Azure file shares.

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

Linux の read_ahead_kb カーネル パラメーターは、シーケンシャル読み取り操作中に "先行読み取り" またはプリフェッチする必要があるデータの量を表します。 バージョン 5.4 より前の Linux カーネル バージョンを使うと、先行読み取り値は、マウントされたファイル システムの 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

Nconnect

Nconnect は、サービスとしてのプラットフォーム (PaaS) の回復性を維持しながら、クライアントと NFSv4.1 用の Azure Premium Files サービスの間でより多くの TCP 接続を使用できるようにすることで大規模にパフォーマンスを向上させる、クライアント側の Linux マウント オプションです。

nconnect の利点

nconnect を使用すると、より少ないクライアント マシンを使用して大規模にパフォーマンスを向上させ、総保有コスト (TCO) を削減できます。 Nconnect は、単一または複数のクライアントを使用して、1 つまたは複数の NIC で複数の TCP チャネルを使用することで、パフォーマンスを向上させます。 nconnect を使用しない場合、Premium Azure ファイル共有の最大プロビジョニング サイズによって提供される帯域幅スケール制限 (10 GiB/秒) を実現するには、約 20 台のクライアント マシンが必要です。 nconnect を使用すると、わずか 6 台から 7 台のクライアントを使用してこれらの制限を実現できます。 これはコンピューティング コストのほぼ 70% を削減すると同時に、IOPS とスループットの大幅な改善を大規模に提供します (表を参照)。

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

必須コンポーネント

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

nconnect のパフォーマンスへの影響

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

Screenshot showing average improvement in IOPS when using nconnect with NFS Azure file shares.

Screenshot showing average improvement in throughput when using nconnect with NFS Azure file shares.

nconnect に関する推奨事項

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

nconnect=4 を設定します

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

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

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

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

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

Nconnect のマウントごとの構成

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

シナリオ 1: (サポート対象) 複数のストレージ アカウントを持つプライベート エンドポイントに対する nconnect のマウントごとの構成

  • 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: (サポート対象外) パブリック エンドポイントを介した nconnect のマウントごとの構成

  • 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

Note

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

シナリオ 3: (サポート対象外) 1 つのストレージ アカウントで複数の共有を持つプライベート エンドポイントに対する nconnect のマウントごとの構成

  • 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

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

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

  • 1 つのクライアント: 1 つの NIC を使用する Azure 仮想マシン (DSv4 シリーズ)
  • OS: Linux (Ubuntu 20.40)
  • NFS ストレージ: Azure Files Premium ファイル共有 (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% 読み取り

I/O サイズ 64k - ランダム読み取り - キューの深さ 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 サイズ 1024k - 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 サイズ 4k - 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 サイズ 8k - 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 サイズ 64k - 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 サイズ 1024k - 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 が自分のワークロードに役立つかどうかを判断してください。 緑色で強調表示されているシナリオは推奨されますが、赤で強調表示されているものは推奨されません。 黄色で強調表示されているものは中間です。

Screenshot showing various read and write I O scenarios with corresponding latency to indicate when nconnect is advisable.

関連項目