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 基础结构的断开连接的远程用户时。
- 运行软件管理系统（例如Configuration Manager）时。
- 当网络带宽限制阻止电子软件分发时。
完整基础结构模型 - 完整的基础结构模型提供软件分发、管理和报告功能;它还包括跨网络的应用程序流式传输。 App-V 完整基础结构模型由一个或多个 App-V 管理服务器组成，这些服务器可用于将应用程序发布到所有客户端。 发布会将虚拟应用程序图标和快捷方式置于目标计算机上。 它还可以将应用程序流式传输到本地用户。 有关如何安装管理服务器的详细信息，请参阅 规划 App-V 服务器部署。 对于以下方案，建议使用完整的基础结构模型：
- 想要使用管理服务器将应用程序发布到目标计算机时。
- 用于将应用程序快速预配到目标计算机。
- 想要使用 App-V 报告时。
重要提示
App-V 完整基础结构模型需要 Microsoft SQL Server 来存储配置数据。 有关详细信息，请参阅 App-V 支持的配置。
端到端服务器大小调整指南
以下部分介绍端到端 App-V 大小调整和规划。 有关更具体的信息，请参阅后续部分。
注意
客户端上的往返响应时间是运行 App-V 客户端的计算机从发布服务器接收成功通知所花费的时间。 发布服务器上的往返响应时间是运行发布服务器的计算机从管理服务器成功接收包元数据更新所花费的时间。
- 20,000 个客户端可以面向单个发布服务器，以在可接受的往返时间 (3 秒) <获取包刷新。
- 在可接受的往返时间 (5 秒) <，单个管理服务器最多可以支持 50 个发布服务器进行包元数据刷新。
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 发布服务器时要考虑的main因素：
- 同时连接到单个发布服务器的客户端数。
- 每次刷新中的包数。
- 环境中客户端与 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 带宽的慢速网络) 中，与 LAN (最多 1,000 个用户) 相比，响应时间增加了 97%。 |
注意
发布服务器 CPU 使用率在时间间隔内始终很高，在大多数情况下，它必须处理同时请求 (>90%) 。 发布服务器可以在一秒内处理大约 1,500 个客户端请求。
| 方案 | 变体 | App-V 客户端数 | 包数 | 发布服务器上的处理器配置 | 网络连接类型 | App-V 客户端往返时间 (秒) | 发布服务器 CPU 使用率 (（以 %) 为单位） |
|---|---|---|---|---|---|---|---|
| App-V 客户端发送发布刷新请求并接收响应，每个请求包含 120 个包 | 客户端数 | 100 1,000 5,000 10,000 |
120 120 120 120 |
双核 双核 Quad Core Quad Core |
LAN | 1 2 2 3 |
100 99 89 77 |
| 每次刷新时有多个包。 | 包数 | 1,000 1,000 |
500 1,000 |
Quad Core | LAN | 2 3 |
92 91 |
| 客户端和发布服务器之间的网络。 | 1.5 Mbps 慢链接网络 | 100 500 1,000 |
120 120 120 |
Quad Core | 1.5 Mbps 大陆内部网络 | 3 10 (0.2% 故障率) 7 (1% 的故障率) |
App-V 流式处理容量规划建议
运行 App-V 客户端的计算机从流式处理服务器流式传输虚拟应用程序包。 往返响应时间是在运行 App-V 客户端的计算机上测量的，是流式传输整个包所花费的时间。
重要提示
以下列表标识了设置 App-V 流式处理服务器时要考虑的main因素：
- 同时从单个流式处理服务器流式处理应用程序包的客户端数。
- 正在流式传输的包的大小。
- 客户端和流式处理服务器之间的环境中可用的网络带宽。
| 方案 | 摘要 |
|---|---|
| 多个 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 角色。 此覆盖范围意味着可以按所需的任意组合排列服务器角色，因为它们不会相互冲突。
尽管有缩放要求，但容错实现需要正常运行的最小服务器数为 4。 管理服务器和 Microsoft SQL Server 角色支持在容错配置中放置。 管理服务器服务可以与任何角色结合使用，但仍然是单一故障点。
尽管可以使用许多容错策略和技术，但并非所有策略和技术都适用于给定的服务。 此外，如果组合了 App-V 角色，则由此产生的不兼容可能会导致某些容错选项停止工作。