Azure Files と Azure File Sync のスケーラビリティとパフォーマンスのターゲット
Azure Files では、サーバー メッセージ ブロック (SMB) およびネットワーク ファイル システム (NFS) ファイル システム プロトコルを介してアクセスできる、フル マネージドのファイル共有がクラウドで提供されます。 この記事では、Azure Files と Azure File Sync のスケーラビリティとパフォーマンスのターゲットについて説明します。
ここで示すターゲットは、デプロイにある他の変数の影響を受ける可能性があります。 たとえば、ファイルの I/O のパフォーマンスは、SMB クライアントの動作と使用可能なネットワーク帯域幅の影響を受け得る場合があります。 Azure Files のスケーラビリティとパフォーマンスが要件を満たしているかどうかを判断するには、実際の使用パターンでテストすることをお勧めします。
適用対象
| 管理モデル | 課金モデル | メディア レベル | 冗長性 | SMB | NFS |
|---|---|---|---|---|---|
| Microsoft.Storage | プロビジョニング済み v2 | HDD (標準) | ローカル (LRS) |  |
 |
| Microsoft.Storage | プロビジョニング済み v2 | HDD (標準) | ゾーン (ZRS) | |
|
| Microsoft.Storage | プロビジョニング済み v2 | HDD (標準) | geo (GRS) | |
|
| Microsoft.Storage | プロビジョニング済み v2 | HDD (標準) | geo ゾーン (GZRS) | |
|
| Microsoft.Storage | プロビジョニング済み v1 | SSD (プレミアム) | ローカル (LRS) | |
|
| Microsoft.Storage | プロビジョニング済み v1 | SSD (プレミアム) | ゾーン (ZRS) | |
|
| Microsoft.Storage | 従量課金制 | HDD (標準) | ローカル (LRS) | |
|
| Microsoft.Storage | 従量課金制 | HDD (標準) | ゾーン (ZRS) | |
|
| Microsoft.Storage | 従量課金制 | HDD (標準) | geo (GRS) | |
|
| Microsoft.Storage | 従量課金制 | HDD (標準) | geo ゾーン (GZRS) | |
|
Azure Files のスケール ターゲット
Azure ファイル共有は、ストレージの共有プールを表す最上位オブジェクトである "ストレージ アカウント" にデプロイされます。 このストレージのプールは、複数のファイル共有をデプロイするのに使用できます。 そのため、ストレージ アカウント、Azure ファイル共有、個々のファイルという 3 つのカテゴリについて考慮する必要があります。
ストレージ アカウントのスケール ターゲット
ストレージ アカウントのスケール ターゲットは、ストレージ アカウント レベルで適用されます。 Azure Files には、次のように主に 2 種類のストレージ アカウントがあります。
FileStorage ストレージ アカウント: FileStorage ストレージ アカウントを使用すると、プロビジョニングされた課金モデルで Azure ファイル共有をデプロイできます。 FileStorage アカウントは、Azure ファイル共有を格納するためにのみ使用できます。FileStorage アカウントでその他のストレージ リソース (BLOB コンテナー、キュー、テーブルなど) をデプロイすることはできません。
汎用バージョン 2 (GPv2) ストレージ アカウント: GPv2 ストレージ アカウントを使用すると、HDD ベースのハードウェアに従量課金制のファイル共有をデプロイできます。 GPv2 ストレージ アカウントでは、Azure ファイル共有を格納するだけでなく、BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースを格納することもできます。
| Attribute | SSD プロビジョニング済み v1 | HDD プロビジョニング済み v2 | HDD 従量課金制 |
|---|---|---|---|
| ストレージ アカウントの種類 | FileStorage | FileStorage | StorageV2 |
| SKU |
|
|
|
| サブスクリプションあたり/リージョンあたりのストレージ アカウント数 | 250 | 250 | 250 |
| 最大ストレージ容量 | 100 TiB | 4 PiB | 5 PiB |
| 最大ファイル共有数 | 1024 (50 以下を使用することをお勧めします) | 50 | 無制限 (50 以下を使用することをお勧めします) |
| 最大 IOPS | 102,400 IOPS | 50,000 IOPS | 20,000 IOPS |
| 最大スループット | 10,340 MiB / 秒 | 5,120 MiB/秒 |
|
| 仮想ネットワーク規則の最大数 | 200 | 200 | 200 |
| IP アドレス規則の最大数 | 200 | 200 | 200 |
| 管理読み取り操作 | 5 分あたり 800 | 5 分あたり 800 | 5 分あたり 800 |
| 管理書き込み操作 | 1 秒あたり 10 または 1 時間あたり 1,200 | 1 秒あたり 10 または 1 時間あたり 1,200 | 1 秒あたり 10 または 1 時間あたり 1,200 |
| 管理一覧表示操作 | 5 分あたり 100 | 5 分あたり 100 | 5 分あたり 100 |
HDD 従量課金制の増加した最大スループットが選択されたリージョン
次のリージョンでは、HDD 従量課金制ストレージ アカウント (StorageV2) の最大スループットが増加しています。
- 東アジア
- 東南アジア
- オーストラリア東部
- ブラジル南部
- カナダ中部
- 中国東部 2
- China North 3
- 北ヨーロッパ
- 西ヨーロッパ
- フランス中部
- ドイツ中西部
- インド中部
- 東日本
- JIO インド西部
- 韓国中部
- ノルウェー東部
- 南アフリカ北部
- スウェーデン中部
- アラブ首長国連邦北部
- 英国南部
- 米国中部
- 米国東部
- 米国東部 2
- US Gov バージニア州
- US Gov アリゾナ
- 米国中北部
- 米国中南部
- 米国西部
- 米国西部 2
- 米国西部 3
Azure ファイル共有のスケール ターゲット
Azure ファイル共有のスケール ターゲットは、ファイル共有レベルで適用されます。
| Attribute | SSD プロビジョニング済み v1 | HDD プロビジョニング済み v2 | HDD 従量課金制 |
|---|---|---|---|
| ストレージ プロビジョニング ユニット | 1 GiB | 1 GiB | 該当なし |
| IOPS プロビジョニング ユニット | 該当なし | 1 IO/秒 | 該当なし |
| スループット プロビジョニング ユニット | 該当なし | 1 MiB/秒 | 該当なし |
| 最小ストレージ サイズ | 100 GiB (プロビジョニング済み) | 32 GiB (プロビジョニング済み) | 0 バイト |
| 最大ストレージ サイズ | 100 TiB | 256 TiB | 100 TiB |
| ファイルの最大数 | 無制限 | 無制限 | 無制限 |
| 最大 IOPS | 102,400 IOPS (プロビジョニングに依存) | 50,000 IOPS (プロビジョニングに依存) | 20,000 IOPS |
| 最大スループット | 10,340 MiB / 秒 (プロビジョニングに依存) | 5,120 IOPS (プロビジョニングに依存) | ストレージ アカウントの上限まで |
| 共有スナップショットの最大数 | 200 スナップショット | 200 スナップショット | 200 スナップショット |
| ファイル名の最大長3 (すべてのディレクトリ、ファイル名、円記号を含む完全なパス名) | 2,048 文字 | 2,048 文字 | 2,048 文字 |
| 個々のパス名要素の最大長2 (\A\B\C\D というパスにおいて、各文字は個々の要素であるディレクトリまたはファイルを表します) | 255 文字 | 255 文字 | 255 文字 |
| ハード リンクの制限 (NFS のみ) | 178 | 該当なし | 該当なし |
| SMB マルチチャネルの最大チャネル数 | 4 | 該当なし | 該当なし |
| ファイル共有あたりの保存されるアクセス ポリシーの最大数 | 5 | 5 | 5 |
3 Azure Files では、ディレクトリとファイルの名前に対して特定の名前付けルールが適用されます。
ファイルのスケール ターゲット
ファイルのスケール ターゲットは、Azure ファイル共有に格納されている個々のファイルに適用されます。
| Attribute | SSD プロビジョニング済み v1 | HDD プロビジョニング済み v2 | HDD 従量課金制 |
|---|---|---|---|
| ファイルの最大サイズ | 4 TiB | 4 TiB | 4 TiB |
| ファイルあたりの最大データ IOPS | 8,000 IOPS | 1,000 IOPS | 1,000 IOPS |
| ファイルあたりの最大スループット | 1,024 MiB / 秒 | 60 MiB/秒 | 60 MiB/秒 |
| ルート ディレクトリの同時ハンドルの最大数 | 10,000 ハンドル | 10,000 ハンドル | 10,000 ハンドル |
| ファイルおよびディレクトリあたりの同時ハンドルの最大数 | 2,000 ハンドル | 2,000 ハンドル | 2,000 ハンドル |
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 の同期グループ | はい |
| ストレージ同期サービスごとの登録サーバー数 | 100 サーバー | はい |
| ストレージ同期サービスごとのプライベート エンドポイント | 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 のスケール ターゲットによって制限されます。