Azure Files のスケーラビリティおよびパフォーマンスのターゲット
Azure Files はクラウドで、SMB および NFS ファイル システム プロトコルを介してアクセスできる、フル マネージドのファイル共有を提供します。 この記事では、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 コンテナー、キュー、テーブルなど) をデプロイすることはできません。
| 属性 | GPv2 ストレージ アカウント (Standard) | FileStorage ストレージ アカウント (Premium) |
|---|---|---|
| サブスクリプションあたり/リージョンあたりのストレージ アカウント数 | 2501 | 2501 |
| ストレージ アカウントの最大容量 | 5 PiB2 | 100 TiB (プロビジョニング済み) |
| 最大ファイル共有数 | 無制限 | 無制限、すべての共有の合計プロビジョニング済みサイズは、ストレージ アカウントの最大容量よりも少なくする必要があります |
| 最大同時要求レート | 20,000 IOPS2 | 102,400 IOPS |
LRS/GRS のスループット (イングレス + エグレス)
|
|
10,340 MiB/秒 |
ZRS のスループット (イングレス + エグレス)
|
|
10,340 MiB/秒 |
| 前の行に記載されていない、冗長性/リージョンの組み合わせのスループット (イングレス + エグレス) |
|
10,340 MiB/秒 |
| 仮想ネットワーク規則の最大数 | 200 | 200 |
| IP アドレス規則の最大数 | 200 | 200 |
| 管理読み取り操作 | 5 分あたり 800 | 5 分あたり 800 |
| 管理書き込み操作 | 1 秒あたり 10 または 1 時間あたり 1,200 | 1 秒あたり 10 または 1 時間あたり 1,200 |
| 管理一覧表示操作 | 5 分あたり 100 | 5 分あたり 100 |
1 クォータの引き上げにより、リージョンごとに標準エンドポイントを使用して最大 500 個のストレージ アカウントを作成できます。 詳細については、「Azure Storage アカウントのクォータを増やす」を参照してください。 2 汎用バージョン 2 ストレージ アカウントは、要求によるより高い容量制限とより高いイングレス制限をサポートします。 アカウント制限の引き上げを希望する場合は、Azure サポートにお問い合わせください。
Azure ファイル共有のスケール ターゲット
Azure ファイル共有のスケール ターゲットは、ファイル共有レベルで適用されます。
| 属性 | Standard ファイル共有1 | Premium ファイル共有 |
|---|---|---|
| ファイル共有の最小サイズ | 最小なし | 100 GiB (プロビジョニング済み) |
| プロビジョニング済みサイズの増加/減少単位 | N/A | 1 GiB |
| ファイル共有の最大サイズ |
|
100 TiB |
| ファイル共有内の最大ファイル数 | 制限なし | 制限なし |
| 最大要求レート (最大 IOPS) |
|
|
| 1 つのファイル共有のスループット (イングレス + エグレス) (MiB/秒) |
|
100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |
| 共有スナップショットの最大数 | 200 スナップショット | 200 スナップショット |
| オブジェクト名の最大長3 (すべてのディレクトリ、ファイル名、バックスラッシュ文字を含む完全なパス名) | 2,048 文字 | 2,048 文字 |
| 個々のパス名コンポーネントの最大長3 (パス \A\B\C\D では、各文字は個々のコンポーネントであるディレクトリまたはファイルを表します) | 255 文字 | 255 文字 |
| ハード リンクの制限 (NFS のみ) | N/A | 178 |
| SMB マルチチャネルの最大チャネル数 | 該当なし | 4 |
| ファイル共有あたりの保存されるアクセス ポリシーの最大数 | 5 | 5 |
1 Standard ファイル共有で使用可能な 3 つの階層 (トランザクションの最適化、ホット、クール) すべてに Standard ファイル共有の制限が適用されます。
2 標準ファイル共有の既定値は 5 TiB です。100 TiB サイズでファイル共有を作成する方法と、既存の標準ファイル共有を最大 100 TiB まで増やす方法の詳細については、「Azure ファイル共有を作成する」を参照してください。 大規模なターゲットを利用するには、クォータを 5 TiB より大きくなるように変更する必要があります。
3 Azure Files では、ディレクトリとファイルの名前に対して特定の名前付けルールが適用されます。
ファイルのスケール ターゲット
ファイルのスケール ターゲットは、Azure ファイル共有に格納されている個々のファイルに適用されます。
| 属性 | Standard ファイル共有内のファイル | Premium ファイル共有内のファイル |
|---|---|---|
| ファイルの最大サイズ | 4 TiB | 4 TiB |
| 最大同時要求レート | 1,000 IOPS | 最大 8,0001 |
| ファイルの最大イングレス | 60 MiB/秒 | 200 MiB/秒 (SMB マルチチャネルで最大 1 GiB/秒)2 |
| ファイルの最大エグレス | 60 MiB/秒 | 300 MiB/秒 (SMB マルチチャネルで最大 1 GiB/秒)2 |
| ルート ディレクトリの同時ハンドルの最大数3 | 10,000 ハンドル | 10,000 ハンドル |
| ファイルおよびディレクトリあたりの同時ハンドルの最大数3 | 2,000 ハンドル | 2,000 ハンドル |
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 ファイル共有を使用して、共有間にコンテナーを配布してみてください。
警告
Azure Files では、1 つのファイル共有から最大 10,000 人の同時ユーザーをサポートできますが、作成したファイル共有のサイズと種類に対してワークロードを適切にテストすることが重要です。 要件は、ユーザー、プロファイル サイズ、ワークロードによって異なる場合があります。
たとえば、同時ユーザー数が 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 がテストした境界を表しているか、ハードであるか、適用された最大値を示しているかを表します。
| リソース | 移行先 | ハード制限 |
|---|---|---|
| リージョンあたりのストレージ同期サービス数 | 100 のストレージ同期サービス | はい |
| サブスクリプションごとのストレージ同期サービス数 | 15 のストレージ同期サービス | はい |
| ストレージ同期サービスごとの同期グループ数 | 200 の同期グループ | はい |
| ストレージ同期サービスごとの登録サーバー数 | 99 サーバー | はい |
| ストレージ同期サービスごとのプライベート エンドポイント | 100 のプライベート エンドポイント | はい |
| 同期グループあたりのクラウド エンドポイント数 | 1 クラウド エンドポイント | はい |
| 同期グループあたりのサーバー エンドポイント数 | 100 個のサーバー エンドポイント | はい |
| サーバーあたりのサーバー エンドポイント数 | 30 個のサーバー エンドポイント | はい |
| 同期グループあたりのファイル システム オブジェクト数 (ディレクトリとファイル) | 1 億オブジェクト | いいえ |
| ディレクトリ内のファイル システム オブジェクト (ディレクトリとファイル) の最大数 (再帰的ではない) | 500 万オブジェクト | はい |
| オブジェクト (ディレクトリとファイル) のセキュリティ記述子の最大サイズ | 64 KiB | はい |
| ファイル サイズ | 100 GiB | いいえ |
| 階層化するファイルの最小ファイル サイズ | ファイル システムのクラスター サイズ (ダブルファイル システムクラスターのサイズ) に基づきます。 たとえば、ファイル システム クラスターのサイズが 4 KiB の場合、ファイルの最小サイズは 8 KiB になります。 | はい |
注意
Azure File Sync エンドポイントは、Azure ファイル共有のサイズにスケールアップできます。 Azure ファイル共有のサイズの上限に達した場合、同期は操作できません。
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 回限りのプロビジョニング: 最初のプロビジョニングのパフォーマンスを最適化する場合、最適なデプロイの詳細については、「Azure File Sync でのオンボード」を参照してください。
- 継続的な同期:Azure ファイル共有に初期データがシードされた後、Azure File Sync は複数のエンドポイントの同期を維持します。
Note
同じ同期グループ内の多数のサーバー エンドポイントを同時に同期すると、エンドポイント間でクラウド サービス リソースの競合が発生します。 結果として、アップロードのパフォーマンスが影響を受けます。 極端な場合、一部の同期セッションはリソースにアクセスできず、失敗します。 ただし、これらの同期セッションはまもなく再開され、輻輳が減少すると最終的に成功します。
内部テストの結果
各ステージ (最初の 1 回限りのプロビジョニングと進行中の同期) でのデプロイの計画に役立つように、次の構成のシステムで行われた内部テスト中に観測された結果を次に示します。
| システム構成 | 詳細 |
|---|---|
| CPU | 64 仮想コアと 64 MiB の L3 キャッシュ |
| メモリ | 128 GiB |
| ディスク | SAS ディスクと RAID 10 およびバッテリ バックアップ付きキャッシュ |
| ネットワーク | 1 Gbps ネットワーク |
| ワークロード | 汎用ファイル サーバー |
1 回限りの初期プロビジョニング
| 1 回限りの初期プロビジョニング | 詳細 |
|---|---|
| オブジェクトの数 | 2,500 万オブジェクト |
| データセットのサイズ | 約 4.7 TiB |
| 平均ファイル サイズ | 約 200 KiB (最大ファイル:100 GiB) |
| 最初のクラウド変更の列挙 | 80 オブジェクト/秒 |
| アップロードのスループット | 同期グループごとに 20 オブジェクト/秒 |
| 名前空間ダウンロードのスループット | 400 オブジェクト/秒 |
最初のクラウド変更の列挙: 新しい同期グループが作成されると、最初のクラウド変更の列挙が、実行される最初のステップになります。 このプロセスでは、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 エージェントはクラウド エンドポイントからファイルのコンテンツをダウンロードしません。 最初に完全な名前空間を同期した後、バックグラウンドでの呼び戻しをトリガーして、ファイル全体をダウンロードするか、またはクラウドの階層化が有効になっている場合は、サーバー エンドポイントに設定されているクラウド階層化ポリシーまでダウンロードします。
継続的な同期
| 継続的な同期 | 詳細 |
|---|---|
| 同期されるオブジェクトの数 | 125,000 オブジェクト (約 1 % のチャーン) |
| データセットのサイズ | 50 GiB |
| 平均ファイル サイズ | ～ 500 KiB |
| アップロードのスループット | 同期グループごとに 20 オブジェクト/秒 |
| 完全なダウンロードのスループット* | 60 オブジェクト/秒 |
* クラウドを使った階層化が有効になっている場合、ファイル データの一部のみがダウンロードされるため、パフォーマンスが向上する可能性があります。 Azure File Sync は、いずれかのエンドポイントで変更されたときにのみ、キャッシュされたファイルのデータをダウンロードします。 階層化されたファイルや新しく作成されたファイルについて、エージェントはファイル データをダウンロードせず、代わりにすべてのサーバー エンドポイントに対して名前空間の同期を行うのみです。 エージェントは、ユーザーがアクセスした階層化されたファイルの部分的なダウンロードもサポートします。
Note
これらの数値は、現実に発生するパフォーマンスを示すものではありません。 実際のパフォーマンスは、このセクションの最初で説明したような複数の要因によって変わります。
デプロイに対する一般的なガイドとして、いくつかの点に留意してください。
- オブジェクトのスループットは、サーバー上の同期グループの数にほぼ比例して増減します。 サーバー上の複数の同期グループにデータを分割するとスループットが向上しますが、サーバーとネットワークによっても制限されます。
- オブジェクトのスループットは、1 秒あたりの MiB のスループットに反比例します。 小さいファイルの場合、1 秒間に処理されるオブジェクト数に関するスループットは高くなりますが、1 秒間の MiB のスループットは低下します。 逆に、大きいファイルでは、1 秒間に処理されるオブジェクトの数は減りますが、1 秒間の MiB のスループットは高くなります。 MiB/秒のスループットは、Azure Files のスケール ターゲットによって制限されます。