Azure Files と Azure File Sync のスケーラビリティとパフォーマンスのターゲット

Azure Files では、サーバー メッセージ ブロック (SMB) およびネットワーク ファイル システム (NFS) ファイル システム プロトコルを介してアクセスできる、フル マネージドのファイル共有がクラウドで提供されます。 この記事では、Azure ストレージ アカウント、Azure Files、Azure File Sync のスケーラビリティとパフォーマンスのターゲットについて説明します。

ここで示すターゲットは、デプロイにある他の変数の影響を受ける可能性があります。 たとえば、ファイルの I/O のパフォーマンスは、SMB クライアントの動作と使用可能なネットワーク帯域幅の影響を受け得る場合があります。 Azure Files のスケーラビリティとパフォーマンスが要件を満たしているかどうかを判断するには、実際の使用パターンでテストすることをお勧めします。

適用対象

ファイル共有の種類	SMB	NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

Azure Files のスケール ターゲット

Azure ファイル共有は、ストレージの共有プールを表す最上位オブジェクトである "ストレージ アカウント" にデプロイされます。 このストレージのプールは、複数のファイル共有をデプロイするのに使用できます。 そのため、ストレージ アカウント、Azure ファイル共有、個々のファイルという 3 つのカテゴリについて考慮する必要があります。

ストレージ アカウントのスケール ターゲット

ストレージ アカウントのスケール ターゲットは、ストレージ アカウント レベルで適用されます。 Azure Files には、次のように主に 2 種類のストレージ アカウントがあります。

• General Purpose バージョン 2 (GPv2) ストレージ アカウント:GPv2 ストレージ アカウントを使うと、Standard のハード ディスク ベース (HDD ベース) のハードウェアに、Azure ファイル共有をデプロイできます。 GPv2 ストレージ アカウントでは、Azure ファイル共有を格納するだけでなく、BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースを格納することもできます。 ファイル共有は、トランザクション最適化 (既定)、ホット、またはクール層にデプロイできます。

• FileStorage ストレージ アカウント:FileStorage ストレージ アカウントを使うと、Premium のソリッドステート ディスク ベース (SSD ベース) のハードウェアに、Azure ファイル共有をデプロイできます。 FileStorage アカウントは、Azure ファイル共有を格納するためにのみ使用できます。FileStorage アカウントでその他のストレージ リソース (BLOB コンテナー、キュー、テーブルなど) をデプロイすることはできません。

¹ クォータの引き上げにより、リージョンごとに標準エンドポイントを使用して最大 500 個のストレージ アカウントを作成できます。 詳細については、「Azure Storage アカウントのクォータを増やす」を参照してください。 ² 汎用バージョン 2 ストレージ アカウントは、要求によるより高い容量制限とより高いイングレス制限をサポートします。 アカウント制限の引き上げを希望する場合は、Azure サポートにお問い合わせください。

Azure ファイル共有のスケール ターゲット

Azure ファイル共有のスケール ターゲットは、ファイル共有レベルで適用されます。

¹ Standard ファイル共有で使用可能な 3 つの階層 (トランザクションの最適化、ホット、クール) すべてに Standard ファイル共有の制限が適用されます。

² Azure Files では、ディレクトリとファイルの名前に対して特定の名前付けルールが適用されます。

ファイルのスケール ターゲット

ファイルのスケール ターゲットは、Azure ファイル共有に格納されている個々のファイルに適用されます。

^{1 読み取りと書き込みの I/O に適用 (一般的に I/O サイズは 64 KiB 以下)。 読み取りと書き込み以外のメタデータ操作の場合、それより低くなることがあります。 これらはソフト制限であり、スロットリングはこれらの制限を超えて発生する可能性があります。}

^{2 コンピューターのネットワーク制限、利用できる帯域幅、I/O サイズ、キューの深さ、その他の要因に左右されます。 詳しくは、「SMB マルチチャネルのパフォーマンス」を参照してください。}

^{3 Azure Files では、ルート ディレクトリで 10,000 個のオープン ハンドルが、共有内のファイルとディレクトリごとに 2,000 個のオープン ハンドルがサポートされます。 共有ごとにサポートされるアクティブ ユーザーの数は、共有にアクセスしているアプリケーションによって異なります。 アプリケーションがルート ディレクトリでハンドルを開いていない場合、Azure Files は共有あたり 10,000 人を超えるアクティブ ユーザーをサポートできます。 ただし、大規模な仮想デスクトップ ワークロード用のディスク イメージを保存するために Azure Files を使用している場合は、ルート ディレクトリまたはファイル/ディレクトリごとのハンドルが不足する可能性があります。 この場合、複数の Azure ファイル共有の使用が必要となることがあります。 詳しくは、「Azure Virtual Desktop 用の Azure Files のサイズ設定ガイダンス」をご覧ください。}

Azure Virtual Desktop 用の Azure Files のサイズ設定ガイダンス

Azure Files の一般的なユース ケースは、FSLogix またはアプリ アタッチを使用して、Azure Virtual Desktop 用のユーザー プロファイル コンテナーとディスク イメージを保存することです。 大規模な Azure Virtual Desktop デプロイでは、1 つの Azure ファイル共有を使用している場合、ルート ディレクトリ用の、またはファイル/ディレクトリごとのハンドルが不足する可能性があります。 このセクションでは、さまざまな種類のディスク イメージによってハンドルがどのように使用されるかについて説明し、使用しているテクノロジに応じたサイズ設定のガイダンスを提供します。

FSLogix

Azure Virtual Desktop で FSLogix を使用している場合、ユーザー プロファイル コンテナーは、仮想ハード ディスク (VHD) または Hyper-V 仮想ハード ディスク (VHDX) のファイルであり、システム コンテキストではなくユーザー コンテキストでマウントされます。 各ユーザーは、ファイル共有に対する単一のルート ディレクトリ ハンドルを開きます。 ファイル共有 (\\storageaccount.file.core.windows.net\sharename)、プロファイル ディレクトリ (%sid%_%username%)、およびプロファイル コンテナー (profile_%username.vhd(x)) があると仮定した場合、Azure Files では最大 10,000 人のユーザーをサポートできます。

ルート ディレクトリの同時ハンドル数が 10,000 の制限に達している場合、またはユーザーのパフォーマンスが低下している場合は、追加の Azure ファイル共有を使用して、共有間にコンテナーを配布してみてください。

たとえば、同時ユーザー数が 2,400 の場合、ルート ディレクトリに 2,400 個のハンドル (ユーザーごとに 1 つ) が必要です。これは、開いているハンドルの上限である 10,000 個を下回ります。 FSLogix ユーザーの場合、ファイルとディレクトリの開いているハンドルが 2,000 個の制限に達する可能性はきわめて低くなります。 ユーザーごとに 1 つの FSLogix プロファイル コンテナーがある場合、プロファイル ディレクトリ用とプロファイル コンテナー ファイル用にそれぞれ 1 つずつ、2 つのファイル/ディレクトリ ハンドルのみ使用します。 ユーザーがそれぞれ 2 つのコンテナー (プロファイルと ODFC) を持っている場合は、ODFC ファイル用に追加のハンドルが 1 つ必要になります。

CimFS によるアプリ アタッチ

MSIX アプリ アタッチまたはアプリアタッチ を使用してアプリケーションを動的にアタッチする場合、ディスク イメージとして複合イメージ ファイル システム (Composite Image File System: CimFS) または VHD/VHDX ファイルを使用できます。 どちらの場合も、スケール制限はユーザーごとではなく、イメージをマウントする VM ごとです。 スケール制限を計算する際、ユーザー数は関係ありません。 VM を起動すると、ユーザー数が 0 の場合でも、ディスク イメージはマウントされます。

CimFS でアプリ アタッチを使用している場合、ディスク イメージはディスク イメージ ファイルのハンドルのみを使用します。 ルート ディレクトリ、またはディスク イメージを含むディレクトリのハンドルは使用されません。 ただし、CimFS イメージは .cim ファイルと少なくとも 2 つの他のファイルの組み合わせであるため、ディスク イメージをマウントするすべての VM で、ディレクトリ内の 3 つのファイルに対してそれぞれ 1 つのハンドルが必要になります。 そのため、100 個の VM がある場合、300 個のファイル ハンドルが必要になります。

アプリあたりの VM の数が 2,000 を超えると、ファイル ハンドルが不足する可能性があります。 この場合、追加の Azure ファイル共有を使用します。

VHD/VHDX によるアプリ アタッチ

VHD/VHDX ファイルでアプリ アタッチを使用している場合、ファイルはユーザー コンテキストではなく、システム コンテキストでマウントされ、読み取り専用で共有されます。 VHDX ファイル上の複数のハンドルを接続システムで使用できます。 Azure Files のスケール制限内に収めるには、VM の数にアプリの数を乗じた値が 10,000 未満である必要があり、アプリあたりの VM 数は 2,000 を超えることはできません。 そのため、どちらか先に達した方が制約となります。

このシナリオでは、1 つの VHD/VHDX のマウント数が 2,000 になると、ファイル/ディレクトリごとの制限に達する可能性があります。 または、共有に複数の VHD/VHDX ファイルが含まれている場合は、最初にルート ディレクトリの制限に達する可能性があります。 たとえば、100 個の VM が 100 個の共有 VHDX ファイルをマウントすると、10,000 個のハンドルのルート ディレクトリ制限に達します。

別の例では、100 個の VM が 20 個のアプリにアクセスする場合、2,000 個のルート ディレクトリ ハンドル (100 x 20 = 2,000) が必要になります。これは、ルート ディレクトリ ハンドルの 10,000 個の制限内に十分収まっています。 また、VHD(X) イメージをマウントするすべての VM に対してファイル ハンドルとディレクトリ/フォルダー ハンドルも必要になります。そのため、この場合は 200 個のハンドル (100 個のファイル ハンドル + 100 個のディレクトリ ハンドル) が必要になります。これは、ファイル/ディレクトリあたりの 2,000 個のハンドル制限を余裕で下回っています。

ルート ディレクトリ用またはファイル/ディレクトリごとの同時ハンドルの最大数の制限に達している場合は、追加の Azure ファイル共有を使用してください。

Azure File Sync のスケール ターゲット

次の表では、どのターゲットがソフトであるか、Microsoft がテストした境界を表しているか、ハードであるか、適用された最大値を示しているかを表します。

Azure File Sync のパフォーマンス メトリック

Azure File Sync エージェントは Azure ファイル共有に接続している Windows Server マシン上で実行されているので、実質的な同期パフォーマンスはインフラストラクチャのいくつかの要因に依存します。この要因には Windows Server と基盤のディスクの構成、サーバーと Azure Storage との間のネットワーク帯域幅、ファイルのサイズ、データセット全体のサイズ、データセットでのアクティビティなどがあります。 Azure File Sync はファイル レベルで動作するため、Azure File Sync ベースのソリューションのパフォーマンス特性は、1 秒間に処理されたオブジェクト (ファイルとディレクトリ) の数によって測定される必要があります。

Azure File Sync の場合、2 つのステージで重要です。

1. 最初の 1 回限りのプロビジョニング: 最初のプロビジョニングのパフォーマンスを最適化する場合、最適なデプロイの詳細については、「Azure File Sync でのオンボード」を参照してください。
2. 継続的な同期:Azure ファイル共有に初期データがシードされた後、Azure File Sync は複数のエンドポイントの同期を維持します。

内部テストの結果

各ステージ (最初の 1 回限りのプロビジョニングと進行中の同期) でのデプロイの計画に役立つように、次の構成のシステムで行われた内部テスト中に観測された結果を次に示します。

1 回限りの初期プロビジョニング

最初のクラウド変更の列挙: 新しい同期グループが作成されると、最初のクラウド変更の列挙が、実行される最初のステップになります。 このプロセスでは、Azure ファイル共有内のすべての項目が列挙されます。 このプロセス中は、同期アクティビティはありません。 クラウド エンドポイントからサーバー エンドポイントにダウンロードされる項目はなく、サーバー エンドポイントからクラウド エンドポイントにアップロードされる項目もありません。 最初のクラウド変更の列挙が完了すると、同期アクティビティは再開されます。

パフォーマンスの速度は 80 オブジェクト/秒です。 クラウド共有内の項目数を決定し、次の数式を使用して日単位の時間を取得して、最初のクラウド変更の列挙が完了するまでにかかる時間を見積もることができます。

最初のクラウドの列挙にかかる時間 (日単位) = (クラウド エンドポイント内のオブジェクト数)/(80 * 60 * 60 * 24)

Windows Server から Azure ファイル共有への初回データ同期: データはすべて Windows Server 上にあるため、Azure File Sync デプロイの多くは空の Azure ファイル共有から始まります。 この場合、最初のクラウド変更の列挙は速く、大半の時間が Windows Server から Azure ファイル共有への変更の同期に費やされます。

同期によって Azure ファイル共有にデータがアップロードされますが、ローカルのファイル サーバーにはダウンタイムがなく、管理者はネットワークの制限を設定して、バックグラウンドのデータ アップロードに使用される帯域幅の量を制限できます。

初回同期は通常、同期グループあたり毎秒 20 ファイルという初回アップロード率に制限されます。 顧客は以下の数式で時間 (日数) を割り出し、すべてのデータを Azure にアップロードする時間を見積もりできます。

同期グループにファイルをアップロードするための時間 (日数) = (サーバー エンドポイントに含まれるオブジェクト数)/(20 * 60 * 60 * 24)

データを複数のサーバー エンドポイントと同期グループに分割すると、複数の同期グループに対してそれぞれ毎秒 20 項目の率で並列アップロードできるため、このデータ アップロードのスピードが上がります。 つまり、同期グループが 2 つであれば、毎秒 40 項目という率の組み合わせで実行されます。 完了までの合計時間は、同期するファイルが最も多い同期グループの見積もり時間になります。

名前空間のダウンロード スループット: 新しいサーバー エンドポイントが既存の同期グループに追加されるときに、Azure File Sync エージェントはクラウド エンドポイントからファイルのコンテンツをダウンロードしません。 最初に完全な名前空間を同期した後、バックグラウンドでの呼び戻しをトリガーして、ファイル全体をダウンロードするか、またはクラウドの階層化が有効になっている場合は、サーバー エンドポイントに設定されているクラウド階層化ポリシーまでダウンロードします。

継続的な同期

* クラウドを使った階層化が有効になっている場合、ファイル データの一部のみがダウンロードされるため、パフォーマンスが向上する可能性があります。 Azure File Sync は、いずれかのエンドポイントで変更されたときにのみ、キャッシュされたファイルのデータをダウンロードします。 階層化されたファイルや新しく作成されたファイルについて、エージェントはファイル データをダウンロードせず、代わりにすべてのサーバー エンドポイントに対して名前空間の同期を行うのみです。 エージェントは、ユーザーがアクセスした階層化されたファイルの部分的なダウンロードもサポートします。

デプロイに対する一般的なガイドとして、いくつかの点に留意してください。

• オブジェクトのスループットは、サーバー上の同期グループの数にほぼ比例して増減します。 サーバー上の複数の同期グループにデータを分割するとスループットが向上しますが、サーバーとネットワークによっても制限されます。
• オブジェクトのスループットは、1 秒あたりの MiB のスループットに反比例します。 小さいファイルの場合、1 秒間に処理されるオブジェクト数に関するスループットは高くなりますが、1 秒間の MiB のスループットは低下します。 逆に、大きいファイルでは、1 秒間に処理されるオブジェクトの数は減りますが、1 秒間の MiB のスループットは高くなります。 MiB/秒のスループットは、Azure Files のスケール ターゲットによって制限されます。

関連項目

• Azure Files のパフォーマンスについて
• Azure Files のデプロイの計画
• Azure File Sync のデプロイの計画