App-V の容量計画
適用先: Windows Server 2016
次の推奨事項をベースラインとして使用して、organizationの App-V インフラストラクチャに適した容量計画情報を決定するのに役立ちます。
重要
このセクションの情報は、App-V デプロイを計画するための一般的なガイドとしてのみ使用してください。 システム容量の要件は、ハードウェアとアプリケーション環境の特定の詳細によって異なります。 さらに、このドキュメントに表示されるパフォーマンス番号は例であり、結果が異なる場合があります。
プロジェクトのスコープを決定する
App-V インフラストラクチャを設計する前に、仮想的に使用できるアプリケーションを決定し、ターゲット ユーザーとその場所も特定します。 この情報により、プロジェクトで実装する App-V インフラストラクチャの種類が決まります。 プロジェクトのスコープに関する決定は、organizationの特定のニーズに基づいて行う必要があります。
| タスク | 詳細情報 |
|---|---|
| アプリケーション スコープを決定する | App-V インフラストラクチャは、仮想化するアプリケーションに応じてさまざまな方法で設定できます。 セットアップでのこのカスタマイズは、仮想化するアプリケーションを定義することが最初のタスクであることを意味します。 |
| 場所のスコープを決定する | "場所のスコープ" は、仮想化されたアプリケーションを実行する予定の物理的な場所を指します (たとえば、エンタープライズ全体または特定の地理的な場所)。 また、仮想アプリケーションを実行するユーザーの作成 (1 つの部署など) を参照することもできます。 接続パス、各場所で使用可能な帯域幅、仮想化されたアプリケーションを使用するユーザーの数、WAN リンク速度を含むネットワーク マップを取得する必要があります。 |
必要な App-V インフラストラクチャを決定する
また、Microsoft Systems Center Configuration Manager などの電子ソフトウェア配布 (ESD) ソリューションを使用して、App-V 環境を管理することもできます。 詳細については、「 電子ソフトウェア配布を使用して App-V パッケージをデプロイする方法」を参照してください。
スタンドアロン モデル - スタンドアロン モデルを使用すると、仮想アプリケーションをストリーミングなしで配布するために Windows インストーラーが有効になります。 スタンドアロン モードの App-V には、シーケンサーとクライアントのみが必要です。余分なコンポーネントは必要ありません。 アプリケーションは、シーケンス処理と呼ばれるプロセスを使用して仮想化のために準備されます。 詳細については、「 App-V シーケンサーとクライアントのデプロイの計画」を参照してください。 スタンドアロン モデルは、次のシナリオに推奨されます。
- App-V インフラストラクチャに接続できない切断されたリモート ユーザーが存在する場合。
- Configuration Managerなどのソフトウェア管理システムを実行している場合。
- ネットワーク帯域幅の制限が電子ソフトウェアの配布を妨げる場合。
完全なインフラストラクチャ モデル - 完全なインフラストラクチャ モデルは、ソフトウェアの配布、管理、およびレポート機能を提供します。また、ネットワーク経由でのアプリケーションのストリーミングも含まれます。 App-V の完全なインフラストラクチャ モデルは、すべてのクライアントにアプリケーションを発行するために使用できる 1 つ以上の App-V 管理サーバーで構成されます。 発行すると、仮想アプリケーションのアイコンとショートカットがターゲット コンピューターに配置されます。 また、ローカル ユーザーにアプリケーションをストリーミングすることもできます。 管理サーバーをインストールする方法の詳細については、「 App-V サーバーのデプロイの計画」を参照してください。 次のシナリオでは、完全なインフラストラクチャ モデルをお勧めします。
- 管理サーバーを使用して、ターゲット コンピューターにアプリケーションを発行する場合。
- ターゲット コンピューターへのアプリケーションの迅速なプロビジョニング。
- App-V レポートを使用する場合。
重要
App-V の完全なインフラストラクチャ モデルでは、構成データを格納するために Microsoft SQL Serverが必要です。 詳細については、「 App-V でサポートされる構成」を参照してください。
エンド ツー エンド サーバーのサイズ設定に関するガイダンス
次のセクションでは、エンドツーエンドの App-V のサイズ設定と計画について説明します。 詳細については、以降のセクションを参照してください。
注
クライアントでのラウンド トリップ応答時間は、App-V クライアントを実行しているコンピューターが発行サーバーから正常な通知を受け取るためにかかった時間です。 発行サーバーでのラウンド トリップ応答時間は、発行サーバーを実行しているコンピューターが管理サーバーからパッケージ メタデータの更新を正常に受け取るためにかかった時間です。
- 20,000 クライアントは、1 つの発行サーバーをターゲットにして、許容されるラウンド トリップ時間 (<3 秒) でパッケージの更新を取得できます。
- 1 つの管理サーバーで、許容されるラウンド トリップ時間 (<5 秒) でパッケージ メタデータの更新に最大 50 台の発行サーバーをサポートできます。
App-V 管理サーバーの容量計画に関する推奨事項
App-V 発行サーバーでは、パッケージ更新要求とパッケージ更新応答の管理サーバーが必要です。 次に、管理サーバーは情報を管理データベースに送信して情報を取得します。 App-V 管理サーバーでサポートされる構成の詳細については、「 App-V でサポートされる構成」を参照してください。
注
App-V 発行サーバーの既定の更新時間は 10 分です。
複数の同時発行サーバーが 1 つの管理サーバーに接続してパッケージ メタデータの更新を行う場合、次の 3 つの要因が発行サーバーのラウンドトリップ応答時間に影響します。
- 同時要求を行う発行サーバーの数。
- 管理サーバーで構成された接続グループの数。
- 管理サーバーで構成されたアクセス グループの数。
次の表では、ラウンド トリップ時間に影響を与える各要因について詳しく説明します。
注
ラウンド トリップ応答時間は、App-V 発行サーバーを実行しているコンピューターが管理サーバーから正常なパッケージ メタデータの更新を受け取るためにかかった時間です。
| ラウンドトリップ応答時間に影響を与える要因 | 説明 |
|---|---|
| パッケージ メタデータの更新を同時に要求する発行サーバーの数。 | 1 つの管理サーバーが、発行メタデータを同時に要求する最大 320 の発行サーバーに応答できます。 たとえば、30 台の発行サーバーが同時に発行メタデータを要求している場合、ラウンドトリップ応答時間は約 40 秒ですが、50 台未満のサーバーでは 5 秒未満です。 50 から 320 の発行サーバーに対して、応答チームは線形に増加します (約 2×)。 |
| 管理サーバーで構成された接続グループの数。 | 最大 100 の接続グループの場合、発行サーバーでのラウンドトリップ応答時間に大きな変更はありません。 100 から 400 の接続グループの場合、ラウンドトリップ応答時間が若干線形に増加します。 |
| 管理サーバーで構成されたアクセス グループの数。 | 最大 40 のアクセス グループでは、発行サーバーでのラウンドトリップ応答時間が線形 (約 3×) 増加します。 |
次の表に、前の各要因のサンプル値を示します。 各バリエーションでは、120 個のパッケージが App-V 管理サーバーから更新されます。
| シナリオ | バリエーション | 接続グループの数 | アクセス グループの数 | 発行サーバーの数 | ネットワーク接続の種類 | ラウンドトリップ応答時間 (秒) | 管理サーバーの CPU 使用率 |
|---|---|---|---|---|---|---|---|
| 発行サーバーは、メタデータを同時に発行するために管理サーバーに接続します | 発行サーバーの数。 | 0 0 0 0 0 0 |
1 1 1 1 1 1 |
50 100 200 300 315 320 |
LAN | 5 10 19 32 30 37 |
17 17 17 15 17 15 |
| メタデータの公開には、接続グループが含まれています | 接続グループの数 | 10 20 100 150 300 400 |
1 1 1 1 1 1 |
100 100 100 100 100 100 |
LAN | 10 11 11 16 22 25 |
17 19 22 19 20 20 |
| メタデータの公開には、アクセス グループが含まれています | アクセス グループの数 | 0 0 0 0 |
1 10 20 40 |
100 100 100 100 |
LAN | 10 43 153 535 |
17 26 24 24 |
管理サーバーを実行しているコンピューターの CPU 使用率は、それをターゲットとする発行サーバーの数に関係なく、約 25% です。 Microsoft SQL Server データベース トランザクション/秒、バッチ要求/秒、およびユーザー接続は、発行サーバーの数に関係なく同じです。 たとえば、トランザクション/秒は約 30、バッチ要求は約 200、ユーザーは約 6 つ接続します。
管理サーバーと発行サーバーが間の低速リンク ネットワークを利用する地理的に分散されたデプロイを通じて、発行サーバーのラウンドトリップ応答時間は、1 つの管理サーバーで同時に 100 回の要求でも許容される時間制限 (<5 秒) 以内です。
| シナリオ | バリエーション | 接続グループの数 | アクセス グループの数 | 発行サーバーの数 | ネットワーク接続の種類 | ラウンドトリップ応答時間 (秒) | 管理サーバーの CPU 使用率 (%) |
|---|---|---|---|---|---|---|---|
| 発行サーバーと管理サーバー間のネットワーク接続 | 1.5 Mbps 低速リンク ネットワーク | 0 0 |
1 1 |
50 100 |
1.5 Mbps ケーブル DSL | 4 5 |
1 2 |
| 発行サーバーと管理サーバー間のネットワーク接続 | LAN/WiFi ネットワーク | 0 0 |
1 1 |
100 200 |
Wi-Fi | 11 20 |
15 17 |
管理サーバーと発行サーバーが低速リンク ネットワークまたは高速ネットワークを介して接続されている場合でも、管理サーバーは約 15,000 個のパッケージ更新要求を 30 分で処理できます。
App-V Reporting Server の容量計画に関する推奨事項
App-V クライアントはレポート データをレポート サーバーに送信します。 レポート サーバーは、Microsoft SQL Server データベース内の情報を記録し、正常な通知を App-V クライアントを実行しているコンピューターに返します。 App-V Reporting Server でサポートされている構成の詳細については、「 App-V でサポートされる構成」を参照してください。
注
ラウンドトリップ応答時間は、App-V クライアントを実行しているコンピューターがレポート情報をレポート サーバーに送信し、レポート サーバーから正常な通知を受け取るためにかかった時間です。
| シナリオ | 要約 |
|---|---|
| 複数の App-V クライアントがレポート情報をレポート サーバーに同時に送信します。 | レポート サーバーからのラウンドトリップ応答時間は、500 クライアントで 2.6 秒です。 レポート サーバーからのラウンドトリップ応答時間は、1000 クライアントの場合は 5.65 秒です。 ラウンドトリップ応答時間は、クライアントの数に応じて直線的に増加します。 |
| レポート サーバーによって処理される 1 秒あたりの要求数。 | 1 つのレポート サーバーと 1 つのデータベースで、1 秒あたり最大 139 件の要求を処理できます。 平均は 121 要求/秒です。 同じ Microsoft SQL Server データベースにレポートする 2 つのレポート サーバーの助けを借りて、1 つのレポート サーバーと同様に、1 秒あたりの平均要求数は約 127 で、最大 278 要求/秒です。 1 つのレポート サーバーで 500 個のコンカレント/アクティブ接続を処理できます。 1 つのレポート サーバーで最大 1,500 個の同時接続を処理できます。 |
| レポート データベース。 | Microsoft SQL Server を実行しているコンピューターでのロックの競合は、要求/秒の制限要因です。 スループットと応答時間は、データベース サイズに依存しません。 |
ランダム遅延の計算
ランダム遅延は、レポート サーバーに送信されるデータの最大遅延 (分単位) を指定します。 スケジュールされたタスクが開始されると、クライアントは 0 から ReportingRandomDelay までのランダムな遅延を生成し、指定された期間待機してからデータを送信します。
ランダム遅延 = 4 ×クライアント数/1 秒あたりの平均要求数。
例: 1 秒あたり 120 要求がある 500 クライアントのランダム遅延は 、4 × 500/120 = 約 17 分です。
App-V 公開サーバーの容量計画に関する推奨事項
App-V クライアントを実行しているコンピューターは、App-V 発行サーバーに接続して、発行更新要求を送信し、応答を受け取ります。 ラウンド トリップ応答時間は、App-V クライアントを実行しているコンピューターで測定され、プロセッサ時間は発行サーバーで測定されます。 App-V Publishing Server でサポートされている構成の詳細については、「 App-V でサポートされる構成」を参照してください。
重要
次の一覧には、App-V 発行サーバーを設定するときに考慮すべきメイン要素が表示されます。
- 1 つの発行サーバーに同時に接続するクライアントの数。
- 各更新のパッケージの数。
- クライアントと App-V 発行サーバーの間の環境内で使用可能なネットワーク帯域幅。
| シナリオ | 要約 |
|---|---|
| 複数の App-V クライアントが 1 つの発行サーバーに同時に接続します。 | デュアル コア プロセッサを実行している発行サーバーは、更新を同時に要求する最大 5,000 個のクライアントに応答できます。 5,000 ~ 10,000 クライアントの場合、発行サーバーには最小クワッド コアが必要です。 10,000 から 20,000 のクライアントの場合、発行サーバーには、より効率的な応答時間のためにデュアル クワッド コアが必要です。 クワッド コアを備えた発行サーバーは、3 秒以内に最大 10,000 個のパッケージを更新できます。 (10,000 個の同時クライアントをサポートしています)。 |
| 各更新のパッケージの数。 | パッケージの数を増やすと、応答時間が約 40% 増加します (最大 1,000 パッケージ)。 |
| App-V クライアントと発行サーバー間のネットワーク。 | 低速ネットワーク (1.5 Mbps 帯域幅) では、LAN (最大 1,000 ユーザー) と比較して応答時間が 97% 増加します。 |
注
発行サーバーの CPU 使用率は、同時要求を処理する必要がある時間間隔の間に常に高くなります (>ほとんどの場合、90%)。 発行サーバーは、1 秒で約 1,500 のクライアント要求を処理できます。
| シナリオ | バリエーション | App-V クライアントの数 | パッケージの数 | 発行サーバーでのプロセッサ構成 | ネットワーク接続の種類 | App-V クライアントのラウンド トリップ時間 (秒単位) | サーバーの CPU 使用率の発行 (%) |
|---|---|---|---|---|---|---|---|
| App-V クライアントは、発行更新要求を送信し、120 個のパッケージを含む各要求の応答を受け取ります | クライアントの数 | 100 1,000 5,000 10,000 |
120 120 120 120 |
デュアルコア デュアルコア クアッドコア クアッドコア |
LAN | 1 2 2 3 |
100 99 89 77 |
| 更新ごとに複数のパッケージ。 | パッケージの数 | 1,000 1,000 |
500 1,000 |
クアッドコア | LAN | 2 3 |
92 91 |
| クライアントと発行サーバーの間のネットワーク。 | 1.5 Mbps 低速リンク ネットワーク | 100 500 1,000 |
120 120 120 |
クアッドコア | 1.5 Mbps のコンチネンタル内ネットワーク | 3 10 (0.2% エラー率) 7 (1% 失敗率) |
App-V ストリーミング容量計画に関する推奨事項
App-V クライアントを実行しているコンピューターは、ストリーミング サーバーから仮想アプリケーション パッケージをストリーミングします。 ラウンド トリップ応答時間は、App-V クライアントを実行しているコンピューターで測定され、パッケージ全体をストリーミングするためにかかった時間です。
重要
次の一覧は、App-V ストリーミング サーバーを設定するときに考慮すべきメイン要因を示しています。
- 1 つのストリーミング サーバーからアプリケーション パッケージを同時にストリーミングするクライアントの数。
- ストリーミングされるパッケージのサイズ。
- クライアントとストリーミング サーバーの間の環境内で使用可能なネットワーク帯域幅。
| シナリオ | 要約 |
|---|---|
| 複数の App-V クライアントが、1 つのストリーミング サーバーから同時にアプリケーションをストリーミングします。 | 同じサーバーから同時にストリーミングするクライアントの数が増えると、パッケージのダウンロード/ストリーミング時間と線形関係があります。 |
| ストリーミングされるパッケージのサイズ。 | パッケージサイズは、サイズが約 1 GB の大きいパッケージの場合にのみ、ストリーミング/ダウンロード時間に大きな影響を与えます。 3 MB から 100 MB までのパッケージ サイズの場合、ストリーミング時間の範囲は 20 秒から 100 秒で、同時クライアントは 100 です。 |
| App-V クライアントとストリーミング サーバー間のネットワーク。 | 低速ネットワーク (1.5 Mbps 帯域幅) では、LAN (最大 100 ユーザー) と比較して応答時間が 70 ~ 80% 増加します。 |
次の表に、前の一覧の各要素のサンプル値を示します。
| シナリオ | バリエーション | App-V クライアントの数 | 各パッケージのサイズ | ネットワーク接続の種類 | App-V クライアントでのラウンド トリップ時間 (秒単位) |
|---|---|---|---|---|---|
| ストリーミング サーバーから仮想アプリケーション パッケージをストリーミングする複数の App-V クライアント。 | クライアントの数。 | 100 200 1,000 100 200 1,000 |
3.5 MB 3.5 MB 3.5 MB 5 MB 5 MB 5 MB |
LAN | 29 39 391 35 68 461 |
| ストリーミングされる各パッケージのサイズ。 | 各パッケージのサイズ。 | 100 200 100 200 |
21 MB 21 MB 109 MB 109 MB |
LAN | 33 83 100 160 |
| クライアントと App-V ストリーミング サーバー間のネットワーク接続。 | 1.5 Mbps 低速リンク ネットワーク。 | 100 100 |
3.5 MB 5 MB |
1.5 Mbps のコンチネンタル内ネットワーク | 102 121 |
各 App-V ストリーミング サーバーは、仮想化されたアプリケーションを同時にストリーミングする少なくとも 200 のクライアントを処理できる必要があります。
注
ストリーミングに要する実際の時間は、主に、同時にストリーミングするクライアントの数、パッケージの数、パッケージ サイズ、サーバーのネットワーク アクティビティ、およびネットワーク条件によって決まります。
たとえば、100 台の同時クライアントがサーバーからストリーミングされている場合、平均的なユーザーは 100 MB のパッケージを 2 分以内にストリーミングできます。 ただし、サイズ 1 GB のパッケージには最大 30 分かかる場合があります。 ほとんどの実際の環境では、ストリーミング需要が一様に分散されていないため、必要なストリーミング サーバーの数を適切にサイズ設定するには、環境内に存在するおおよそのピーク ストリーミング要件を理解する必要があります。
ストリーミング サーバーでサポートできるクライアントの数を増やし、アプリケーションを事前にキャッシュすると、ストリーミングのピーク要件を減らすことができます。 また、オンデマンド ストリーミング配信とストリーム最適化パッケージを使用して、ストリーミング サーバーがサポートできるクライアントの数を増やすこともできます。
App-V サーバーロールの組み合わせ
スケーリングとフォールト トレランスの要件を割引する場合、Active Directory 接続を持つ場所が機能するために必要なサーバーの最小数は 1 です。 このサーバーは、管理サーバー、管理サーバー サービス、および Microsoft SQL Server ロールをホストします。 このカバレッジは、互いに競合しないため、任意の組み合わせでサーバー ロールを配置できることを意味します。
スケーリング要件にかかわらず、フォールト トレラントな実装で機能する必要があるサーバーの最小数は 4 です。 管理サーバーと Microsoft SQL Server ロールは、フォールト トレラントな構成での配置をサポートします。 管理サーバー サービスは、任意のロールと組み合わせることができますが、単一障害点のままです。
使用できるフォールト トレランス戦略とテクノロジは多数ありますが、すべてが特定のサービスに適用されるわけではありません。 さらに、App-V ロールが組み合わされると、その結果、非互換性によって特定のフォールト トレランス オプションが機能しなくなる可能性があります。