Azure Files には、仮想デスクトップ ユーザー プロファイルとディスク イメージをクラウドに格納するのに最適な、フル マネージドのスケーラブルな SMB ファイル共有が用意されています。
VDI とは
仮想デスクトップ インフラストラクチャ (VDI) は、サーバー上のデスクトップ環境を一元化し、セキュリティで保護されたリモート アクセスを可能にし、デバイス間の管理を簡素化します。 Azure Virtual Desktop (AVD) は、Microsoft のクラウドベースの VDI ソリューションであり、Microsoft 365 と Microsoft Entra ID へのシームレスな統合を備えたスケーラブルなマルチセッション Windows 10 および 11 デスクトップを提供し、リモート作業やセキュリティで保護されたリソース アクセスに最適です。 その他の VDI オファリングには、Citrix/VMWare Horizon on Azure インフラストラクチャが含まれます。
Azure Files for VDI の理由
Azure Files は、ユーザー プロファイル ストレージ用の FSLogix とシームレスに統合するクラウド ファイル共有を提供し、動的アプリケーション配信用にディスク イメージを格納する App Attach を提供するため、VDI に最適です。 Azure Files を正しくデプロイすると、インフラストラクチャのオーバーヘッドを削減し、高可用性を提供し、エンタープライズ レベルのセキュリティをサポートし、仮想デスクトップ セッション全体でスムーズなユーザー エクスペリエンスを実現するために一貫したパフォーマンスを実現できます。
パフォーマンス、スケーリング、コスト
Azure Files には、プロビジョニング済みや従量課金制など、さまざまな課金モデルが用意されています。 「Azure Files の課金について」を参照してください。
Azure Files では、1 つのファイル共有から数千人の同時仮想デスクトップ ユーザーをサポートできますが、使用しているファイル共有のサイズと種類に対してワークロードを適切にテストすることが重要です。 要件は、ユーザー数とプロファイル サイズによって異なります。
ホーム ディレクトリを含む仮想デスクトップは、SSD ファイル共有での メタデータ キャッシュ の利点を活用できます。
認証と承認
ユーザーが自分のプロファイルまたはアプリケーションに安全にアクセスできるようにするには、ID ベースの認証を使用し、適切なアクセス許可と Azure RBAC ロールを割り当てる必要があります。
次の 3 つの ID ソースのいずれかを使用して、ユーザーを認証して Azure ファイル共有にアクセスできます。
オンプレミスの Active Directory Domain Services (AD DS): このオプションでは、仮想デスクトップ ユーザーがドメイン コントローラーへのネットワーク接続を妨げない状態にする必要があります。
Microsoft Entra Kerberos (ハイブリッド ID のみ): このオプションには既存の AD DS 展開が必要です。この展開は、Microsoft Entra ID がハイブリッド ID を認証できるように Microsoft Entra テナントに同期されます。 これは、ユーザーがドメイン コントローラーにアクセスできないネットワーク接続を持っている必要がないため、仮想デスクトップ ワークロードに適しています。 このオプションを使用すると、Microsoft Entra 参加済みまたは Microsoft Entra ハイブリッド参加済みセッション ホストからハイブリッド ユーザー ID によってアクセスできるプロファイルを格納できます。
Microsoft Entra Domain Services: AD DS がなく、クラウド専用 ID を認証する必要がある場合は、このオプションを選択します。
ストレージのアクセス許可を構成するには、「 FSLogix の SMB ストレージのアクセス許可を構成する」を参照してください。
高可用性と障害復旧
仮想デスクトップ ワークロードに Azure リージョン を選択する前に、そのリージョンのコンプライアンスとデータ所在地の要件に注意する必要があります。
必ず、Azure Virtual Desktop ホスト プールと同じ Azure リージョンとリソース グループにあるストレージ アカウントを使用してください。
リージョンの選択におけるもう 1 つの重要な考慮事項は、待機時間です。 通常は、Azure Virtual Desktop ホスト プールと同じ Azure リージョンとサブスクリプションに、ユーザー プロファイルを含め、必要なすべての仮想デスクトップ リソースを一元化することをお勧めします。 ユーザーから遠いリージョンにファイル共有をデプロイすると、待機時間が長くなり、パフォーマンスが低下する可能性があります。 また、リージョン間のデータ転送のコストを増やすこともできます。
Azure Files には、HDD (Standard) ファイル共有と SSD (Premium) ファイル共有の両方が用意されています。 SSD Azure ファイル共有では geo 冗長性が提供されない点に注意してください。 Azure Files で使用できるさまざまな冗長性オプションの詳細については、Azure Files の冗長性に関するページを参照してください。
Azure Virtual Desktop 用の Azure Files のサイズ設定ガイダンス
大規模な VDI 環境では、特にアプリケーションの起動とセッションのセットアップ中に、何万人ものユーザーが同じファイルに同時にアクセスする必要がある場合があります。 このような状況では、特に 1 つの Azure ファイル共有を使用している場合は、ハンドルが不足する可能性があります。 このセクションでは、さまざまな種類のディスク イメージがハンドルを使用する方法について説明し、使用しているテクノロジに基づいてサイズ設定のガイダンスを提供します。
Azure Files では、 FSLogix プロファイル ストレージ シナリオと FSLogix 以外の プロファイル ストレージ シナリオの両方がサポートされています。 このガイダンスでは、同時仮想デスクトップ ユーザーの数、ユーザーあたりの予想される IOPS、ストレージの種類 (HDD または SSD) に基づいて、推奨されるファイル共有構成を提供します。 一般に、FSLogix では、FSLogix 以外と比較して、より効率的なハンドルの使用が可能になります。
ヒント
Azure Files には現在、ファイルとディレクトリごとに 2,000 個の同時実行ハンドル制限があり、この記事ではその制限を念頭に置いて書かれています。 ただし、SSD ファイル共有の場合、これはソフト制限です。 この制限を超えてスケーリングする必要がある場合は、 メタデータ キャッシュを有効に して、 ファイル ハンドルの制限の引き上げ (プレビュー) に登録できます。
FSLogix プロファイル コンテナー
Azure Virtual Desktop で FSLogix を使用している場合、ユーザー プロファイル コンテナーは、仮想ハード ディスク (VHD) または Hyper-V 仮想ハード ディスク (VHDX) のファイルであり、システム コンテキストではなくユーザー コンテキストでマウントされます。 各ユーザーは 1 つのルート ディレクトリ ハンドルを開きます。これはファイル共有に対して行う必要があります。 ファイル共有 (\\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 ユーザーの場合、開いているファイル ハンドルとディレクトリ ハンドルの制限に達する可能性はほとんどありません。 ユーザーごとに 1 つの FSLogix プロファイル コンテナーがある場合、プロファイル ディレクトリ用とプロファイル コンテナー ファイル用にそれぞれ 1 つずつ、2 つのファイル/ディレクトリ ハンドルのみ使用します。 ユーザーがそれぞれ 2 つのコンテナー (プロファイルと ODFC) を持っている場合は、ODFC ファイルにもう 1 つのハンドルが必要です。
次の表に、これらの条件下での同時ユーザー数に基づく FSLogix プロファイル コンテナー に関する一般的な推奨事項を示します。
- 各ユーザーには 1 ~ 2 個のコンテナーがあります (プロファイル + オプションの Office コンテナー)
- ハンドル: ユーザーあたり最大 2 ~ 3 (ルート ディレクトリ、プロファイル、場合によっては ODFC コンテナー)
| 同時 FSLogix ユーザーの数 | 推奨されるファイル ストレージ | メモ |
|---|---|---|
| ユーザー数が 2,000 未満 | HDD 従量課金制またはプロビジョニング済み v2 ファイル共有 | 軽いワークロードまたは低コンカレンシーに対応 |
| 2,000 ~ 5,000 ユーザー | 1-2 メタデータ キャッシュを使用した SSD ファイル共有 | SSD によりログイン パフォーマンスが向上し、ハンドル数は 1 共有あたり 10,000 をはるかに下回ります |
| 5,000 ~ 10,000 ユーザー | 2 -4 SSD ファイル共有、均等に分散 | 株式は正しく分割される必要がある |
| 10,000 人を超えるユーザー | メタデータ キャッシュとファイル ハンドル制限の増加を含む複数の SSD ファイル共有 (プレビュー) | 増加したハンドル制限に登録し、大規模環境でのメタデータキャッシュを有効にする |
FSLogix 以外のプロファイル ストレージ
FSLogix を使用していない場合は、Windows で移動ユーザー プロファイルまたはフォルダー リダイレクトを使用している可能性があります。
注
FSLogix 以外のプロファイルは、ディレクトリまたはファイルごとのハンドルの上限である 2,000 個の同時実行ハンドルに達する可能性が高くなります。 この制限を超えてスケーリングする必要がある場合は、SSD ファイル共有を使用し、 メタデータ キャッシュを有効にして、 ファイル ハンドルの制限の引き上げ (プレビュー) に登録できます。
次の表は、これらの条件下での同時ユーザーの数に基づいて、 FSLogix 以外 のプロファイル ストレージに関する一般的な推奨事項を示しています。
- プロファイル データは、小さなファイル/フォルダーの数として格納されます
- ユーザーあたりのメタデータ IOPS の向上
- ハンドルの使用率が比較的高い (アクセスされる各ファイル/フォルダーがハンドルを使用する)
- プロファイル サイズ ~5 GiB
- ピーク IOPS: ログイン中は 50 IOPS/ユーザー、安定状態では 20 IOPS/ユーザー
| 同時ユーザーの数 | 推奨されるファイル ストレージ | メモ |
|---|---|---|
| ユーザー数が 400 未満 | HDD 従量課金制ファイル共有 | IOPS 要求を最小限に抑えたコンカレンシーの低いワークロードに適しています |
| 400 ~ 1,000 ユーザー | HDD プロビジョニング済み v2 ファイル共有または複数の HDD 従量課金制ファイル共有 | ログイン バーストのピーク時にチューニングが必要になる場合がある |
| 1,000 ~ 2,000 ユーザー | SSD または複数の HDD ファイル共有 | メタデータの待機時間が短縮されるため、SSD が推奨される |
| 2,000 人を超えるユーザー | メタデータ キャッシュとファイル ハンドル制限の増加を含む複数の SSD ファイル共有 (プレビュー) | ハンドルの制限を回避し、一貫したログイン パフォーマンスを実現するために重要です |
アプリ アタッチ
MSIX アプリ アタッチまたはアプリアタッチ を使用してアプリケーションを動的にアタッチする場合、ディスク イメージとして複合イメージ ファイル システム (Composite Image File System: CimFS) または VHD/VHDX ファイルを使用できます。 どちらの場合も、スケール制限はユーザーごとではなく、イメージをマウントする VM ごとです。 スケール制限を計算する際、ユーザー数は関係ありません。 VM を起動すると、ユーザー数が 0 の場合でも、ディスク イメージはマウントされます。
CimFS によるアプリ アタッチ
CimFS でアプリ アタッチを使用している場合、ディスク イメージはディスク イメージ ファイルのハンドルのみを使用します。 彼らはルートディレクトリやディスクイメージを含むディレクトリのハンドルを消費しません。 ただし、CimFS イメージは .cim ファイルと少なくとも 2 つの他のファイルの組み合わせであるため、ディスク イメージをマウントするすべての VM に対して、ディレクトリ内の 3 つのファイルに対してそれぞれ 1 つのハンドルが必要です。 そのため、100 個の VM がある場合は、300 個のファイル ハンドルが必要です。
アプリあたりの VM の数が 2,000 を超えると、ファイル ハンドルが不足する可能性があります。 この場合は、追加の Azure ファイル共有を使用するか、SSD ファイル共有のメタデータ キャッシュを有効にして、ファイル ハンドルの制限の引き上げ (プレビュー) を登録します。
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 個のハンドルのルート ディレクトリ制限に達します。
別の例では、20 個のアプリにアクセスする 100 個の VM には 2,000 個のルート ディレクトリ ハンドル (100 x 20 = 2,000) が必要です。これは、ルート ディレクトリ ハンドルの 10,000 個の制限の範囲内です。 また、VHD (X) イメージをマウントするすべての VM に対してファイル ハンドルとディレクトリ/フォルダー ハンドルも必要です。そのため、この場合は 200 個のハンドル (100 個のファイル ハンドル + 100 個のディレクトリ ハンドル) が必要です。これは、ファイル/ディレクトリあたり 2,000 ハンドルの制限を快適に下回ります。
ルート ディレクトリの最大同時ハンドルの制限に達している場合は、追加の Azure ファイル共有を使用します。
ファイル/ディレクトリあたりの最大同時ハンドル数の制限に達している場合は、追加の Azure ファイル共有を使用するか、 SSD ファイル共有のメタデータ キャッシュを有効に して 、ファイル ハンドルの制限の引き上げ (プレビュー) を登録します。