App-V 容量规划
适用于：Windows Server 2016
以下建议可用作基线，以帮助确定适合组织的 App-V 基础结构的容量规划信息。
重要
仅将本部分中的信息用作规划 App-V 部署的一般指南。 系统容量要求将取决于硬件和应用程序环境的特定详细信息。 此外，本文档中显示的性能数字是示例，结果可能会有所不同。
确定项目范围
在设计 App-V 基础结构之前，确定哪些应用程序将几乎可用，并确定目标用户及其位置。 此信息将确定项目应实现的 App-V 基础结构类型。 应根据组织的特定需求，根据项目范围做出决策。
| 任务 | 更多信息 |
|---|---|
| 确定应用程序范围 | 可以以不同的方式设置 App-V 基础结构，具体取决于要虚拟化的应用程序。 设置中的此自定义意味着你的第一个任务是定义要虚拟化的应用程序。 |
| 确定位置范围 | “位置范围”是指你计划在其中运行虚拟化应用程序的物理位置 (例如，企业范围或特定地理位置) 。 它还可以引用将运行虚拟应用程序 (的用户群体，例如单个部门) 。 应获取网络映射，其中包括连接路径、每个位置的可用带宽、使用虚拟化应用程序的用户数和 WAN 链接速度。 |
确定需要哪个 App-V 基础结构
还可以使用电子软件分发 (ESD) 解决方案（如 Microsoft Systems Center Configuration Manager）管理 App-V 环境。 有关详细信息，请参阅 如何使用电子软件分发部署 App-V 包。
独立模型 - 独立模型允许虚拟应用程序Windows安装程序启用，无需流式处理即可进行分发。 独立模式下的 App-V 只需要序列器和客户端;不需要额外的组件。 应用程序已准备好使用称为序列化的进程进行虚拟化。 有关详细信息，请参阅 规划 App-V Sequencer 和客户端部署。 对于以下方案，建议使用独立模型：
- 当有无法连接到 App-V 基础结构的断开连接的远程用户时。
- 运行软件管理系统时，例如 System Center 2012 Configuration Manager。
- 当网络带宽限制抑制电子软件分发时。
完整基础结构模型 - 完整基础结构模型提供软件分发、管理和报告功能;它还包括跨网络的应用程序流式传输。 App-V 完整基础结构模型由一个或多个 App-V 管理服务器组成，可用于将应用程序发布到所有客户端。 发布会将虚拟应用程序图标和快捷方式放置在目标计算机上。 它还可以将应用程序流式传输到本地用户。 有关如何安装管理服务器的详细信息，请参阅 规划 App-V Server 部署。 对于以下方案，建议使用完整的基础结构模型：
- 如果要使用管理服务器将应用程序发布到目标计算机。
- 用于快速预配面向计算机的应用程序。
- 想要使用 App-V 报告时。
重要
App-V 完整基础结构模型需要Microsoft SQL Server来存储配置数据。 有关详细信息，请参阅 App-V 支持的配置。
端到端服务器大小调整指南
以下部分介绍端到端 App-V 大小调整和规划。 有关更具体的信息，请参阅后续部分。
备注
客户端上的往返响应时间是运行 App-V 客户端的计算机从发布服务器接收成功通知所花的时间。 发布服务器上的往返响应时间是运行发布服务器的计算机从管理服务器接收成功包元数据更新所花的时间。
- 20，000 个客户端可以面向单个发布服务器，以在可接受的往返时间 (<3 秒) 获取包刷新。
- 单个管理服务器最多可以支持 50 台发布服务器，以便在可接受的往返时间 (<5 秒) 中刷新包元数据。
App-V 管理服务器容量规划建议
App-V 发布服务器需要管理服务器来处理包刷新请求和包刷新响应。 然后，管理服务器将信息发送到管理数据库以检索信息。 有关 App-V 管理服务器支持的配置的详细信息，请参阅 App-V 支持的配置。
备注
App-V 发布服务器上的默认刷新时间为 10 分钟。
当多个同时发布服务器联系单个管理服务器进行包元数据刷新时，以下三个因素将影响发布服务器的往返响应时间：
- 同时发出请求的发布服务器数。
- 在管理服务器上配置的连接组数。
- 在管理服务器上配置的访问组数。
下表更详细地描述了影响往返时间的每个因素。
备注
往返响应时间是运行 App-V 发布服务器的计算机从管理服务器接收成功包元数据更新所花的时间。
| 影响往返响应时间的因素 | 描述 |
|---|---|
| 同时请求包元数据刷新的发布服务器数。 | 单个管理服务器最多可以响应 320 个同时请求发布元数据的发布服务器。 例如，在 30 台发布服务器同时请求发布元数据的情况下，往返响应时间大约为 40 秒，而对于不到 50 台服务器，则不到 5 秒。 从 50 台发布服务器到 320 台发布服务器，响应团队将线性增加 (大约 2×) 。 |
| 在管理服务器上配置的连接组数。 | 对于最多 100 个连接组，发布服务器上的往返响应时间没有显著变化。 对于 100-400 个连接组，往返响应时间略有增加。 |
| 在管理服务器上配置的访问组数。 | 对于多达 40 个访问组，发布服务器上的往返响应时间增加了大约 3 (×) 增加。 |
下表显示上述每个因素的示例值。 在每个变体中，从 App-V 管理服务器刷新 120 个包。
| 方案 | 变体 | 连接组数 | 访问组数 | 发布服务器的数量 | 网络连接类型 | 往返响应时间 (秒) | 管理服务器 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 个。
通过地理分布式部署，管理服务器和发布服务器使用它们之间的慢速链接网络，发布服务器上的往返响应时间在可接受的时间限制 (<5 秒) ，甚至对于单个管理服务器上的 100 个同时请求也是如此。
| 方案 | 变体 | 连接组数 | 访问组数 | 发布服务器的数量 | 网络连接类型 | 往返响应时间 (秒) | %) 中的管理服务器 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 |
WLAN | 11 20 |
15 17 |
无论是通过慢速链接网络还是高速网络连接管理服务器和发布服务器，管理服务器都可以在 30 分钟内处理大约 15，000 个包刷新请求。
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 秒。 往返响应时间会根据客户端数目线性增加。 |
| 报告服务器处理的每秒请求数。 | 单个报表服务器和单个数据库每秒最多可处理 139 个请求。 平均值为 121 个请求/秒。 在向同一Microsoft SQL Server数据库报告的两个报表服务器的帮助下，平均请求数/秒（如单个报表服务器）约为 127，最大请求数为 278 个/秒。 单个报表服务器可以处理 500 个并发/活动连接。 单个报表服务器最多可以处理 1，500 个并发连接。 |
| 报告数据库。 | 运行Microsoft SQL Server的计算机上的锁争用是请求/秒的限制因素。 吞吐量和响应时间与数据库大小无关。 |
计算随机延迟
随机延迟指定要将数据发送到报表服务器的最大延迟 (分钟) 。 启动计划任务时，客户端会在 0 和 ReportingRandomDelay 之间生成随机延迟，并在发送数据之前等待指定的持续时间。
随机延迟 = 每秒 4 ×个客户端/平均请求数。
示例：每秒 120 个请求的 500 个客户端的随机延迟为 4 × 500/120 = 大约 17 分钟。
App-V 发布服务器容量规划建议
运行 App-V 客户端的计算机连接到 App-V 发布服务器，以发送发布刷新请求并接收响应。 往返响应时间在运行 App-V 客户端的计算机上进行测量，而处理器时间在发布服务器上进行测量。 有关 App-V 发布服务器支持的配置的详细信息，请参阅 App-V 支持的配置。
重要
以下列表显示设置 App-V 发布服务器时要考虑的主要因素：
- 同时连接到单个发布服务器的客户端数。
- 每次刷新中的包数。
- 客户端和 App-V 发布服务器之间的环境中可用网络带宽。
| 方案 | 摘要 |
|---|---|
| 多个 App-V 客户端同时连接到单个发布服务器。 | 运行双核处理器的发布服务器最多可以响应 5000 个同时请求刷新的客户端。 对于 5，000-10，000 个客户端，发布服务器需要最小四核。 对于 10，000-20，000 个客户端，发布服务器应具有双四核，以便更高效的响应时间。 具有四核的发布服务器最多可在三秒内刷新 10，000 个包。 (支持 10，000 个同时使用的客户端。) |
| 每次刷新中的包数。 | 越来越多的包将增加大约 40% 的响应时间 (多达 1，000 个包) 。 |
| App-V 客户端与发布服务器之间的网络。 | 在慢速网络 (1.5-Mbps 带宽) 中，响应时间增加了 97%，而 LAN (多达 1，000 名用户) 。 |
备注
发布服务器 CPU 在大多数情况下必须处理同时请求 (>90%) 的时间间隔内始终很高。 发布服务器可以在一秒内处理大约 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 流式处理服务器时要考虑的主要因素：
- 同时从单个流式处理服务器流式处理应用程序包的客户端数。
- 要流式传输的包的大小。
- 客户端和流式处理服务器之间环境中的可用网络带宽。
| 方案 | 摘要 |
|---|---|
| 多个 App-V 客户端同时从单个流式处理服务器流式传输应用程序。 | 如果同时从同一服务器流式传输的客户端数增加，则与包下载/流时间存在线性关系。 |
| 正在流式传输的包的大小。 | 包大小仅对大小约为 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 个客户端从服务器流式传输时，平均用户可以在不到 2 分钟内流式传输 100 MB 的包。 但是，大小为 1 GB 的包可能需要长达 30 分钟的时间。 在大多数实际环境中，流式处理需求不是统一分布的，你需要了解环境中存在的大致峰值流式处理要求，以便正确调整所需流式处理服务器的大小。
如果预先缓存应用程序，可以增加流式处理服务器可以支持的客户端数，并减少峰值流式处理要求。 还可以使用按需流式处理交付和流优化包来增加流式处理服务器可以支持的客户端数。
组合 App-V 服务器角色
打折扣缩放和容错要求时，具有 Active Directory 连接的位置需要运行的最小服务器数为 1。 此服务器将托管管理服务器、管理服务器服务和Microsoft SQL Server角色。 此覆盖范围意味着你可以在喜欢的任何组合中排列服务器角色，因为它们不会相互冲突。
尽管需要缩放，但容错实现需要运行的最小服务器数是四个。 管理服务器和Microsoft SQL Server角色支持在容错配置中放置。 管理服务器服务可以与任何角色结合使用，但仍是一个故障点。
尽管可以使用许多容错策略和技术，但并非所有策略都适用于给定服务。 此外，如果将 App-V 角色组合在一起，则导致的不兼容性可能导致某些容错选项停止工作。