App-V 5.0 容量规划

应用到: Application Virtualization 5.0, Application Virtualization 5.0 SP1, Application Virtualization 5.0 SP2, Application Virtualization 5.0 SP3

以下建议可用作帮助你确定适合你组织的 App-V 5.0 基础结构的容量规划信息的基线。

重要

仅使用本节的信息作为规划 App-V 5.0 部署的一般指南。你的系统容量要求将取决于你硬件和应用程序环境的具体详细信息。此外,本文档中显示的性能值只是示例数据,你的结果可能会有所不同。

确定项目范围

在设计 App-V 5.0 基础结构之前,你必须确定项目的范围。该范围包括确定实际可用的应用程序有哪些以及确定目标用户及其位置。此信息将有助于确定应实施哪种 App-V 5.0 基础结构。有关项目范围的决策必须基于你组织的具体需求。

任务 更多信息

确定应用程序范围

根据要虚拟化的应用程序,可以采用不同的方法部署 App-V 5.0 基础结构。首要任务是确定你希望虚拟化的应用程序类型。

确定位置范围

位置范围是指你打算运行虚拟化应用程序的物理位置(例如,企业范围内或特定地理位置)。还可以指将运行虚拟应用程序的用户群(例如,单个部门)。你应获取包括每个位置的连接路径和可用带宽、使用虚拟化应用程序的用户数以及 WAN 链接速度的网络地图。

确定需要的 App-V 5.0 基础结构

重要

以下两种模式都要求在你打算运行虚拟应用程序的计算机上安装 App-V 5.0 客户端。

你还可以使用电子软件分发 (ESD) 解决方案(如 Microsoft Systems Center Configuration Manager)来管理你的 App-V 5.0 环境。有关详细信息,请参阅通过使用电子软件分发 (ESD) 部署 App-V 5.0 包

  • “独立模式”- 独立模式允许虚拟应用程序在分发时启用 Windows Installer 且无流式处理。独立模式中的 App-V 5.0 包含排序器和客户端;无需其他组件。使用名为序列化的过程准备应用程序进行虚拟化。有关详细信息,请参阅 规划 App-V 5.0 Sequencer 和客户端部署。对于以下情景,推荐使用独立模式:

    • 远程用户断开连接无法连接到 App-V 5.0 基础结构时。

    • 运行软件管理系统(如 Configuration Manager 2012)时。

    • 网络带宽限制阻止电子软件分发时。

  • “完整基础结构模式”- 完整基础结构模式提供软件分发、管理和报告功能;而且还包括应用程序的跨网络流处理。App-V 5.0 完整基础结构模式由一个或多个 App-V 5.0 管理服务器组成。管理服务器可用于向所有客户端发布应用程序。发布过程可以将虚拟应用程序图标和快捷方式放置于目标计算机上。还可以将应用程序流处理到本地用户。有关安装管理服务器的更多信息,请参阅规划 App-V 5.0 服务器部署。对于以下情景,推荐使用完整基础结构模式:

    重要

    App-V 5.0 完整基础结构模式要求使用 Microsoft SQL Server 来存储配置数据。有关详细信息,请参阅App-V 5.0 支持的配置

    • 想要使用管理服务器来将应用程序发布到目标计算机时。

    • 想要将应用程序快速配置到目标计算机时。

    • 想要使用 App-V 5.0 报告时。

端对端服务器选型指南

下一节介绍关于端对端 App-V 5.0 选型和规划的信息。有关更多具体信息,请参考后续章节。

note备注
客户端上的往返响应时间是运行 App-V 5.0 客户端的计算机收到来自发布服务器的成功通知所花费的时间。发布服务器上的往返响应时间是运行发布服务器的计算机收到来自管理服务器的包元数据更新成功消息所花费的时间。

  • 20,000 个客户端可同时以单个发布服务器为目标,在可接受的往返时间内获取包刷新。(< 3 秒)

  • 单个管理服务器最多可支持 50 个发布服务器在可接受的往返时间内获取包元数据刷新。(< 5 秒)

App-V 5.0 管理服务器容量规划建议

App-V 5.0 发布服务器要求管理服务器提出包刷新请求并响应包刷新。然后,管理服务器会将信息发送至管理数据库进行信息检索。有关 App-V 5.0 管理服务器支持的配置的更多信息,请参阅 App-V 5.0 支持的配置

note备注
App-V 5.0 发布服务器上的默认刷新时间为 10 分钟。

当多个同步发布服务器联系单个管理服务器获取包元数据刷新时,以下三个因素将影响发布服务器上的往返响应时间:

  1. 同时提出请求的发布服务器数量。

  2. 管理服务器上配置的连接组数量。

  3. 管理服务器上配置的访问组数量。

下表显示有关影响往返时间的各个因素的更多信息。

note备注
往返响应时间是运行 App-V 5.0 发布服务器的计算机收到来自管理服务器的包元数据更新成功消息所花费的时间。

影响往返响应时间的因素 更多信息

同时请求包元数据刷新的发布服务器数量。

  • 单个管理服务器最多可响应 320 个同时请求发布元数据的发布服务器。

  • 320 个发布服务器的往返响应时间约为 40 秒。

  • 如果同时请求元数据的发布服务器 < 50 个,则往返响应时间将 < 5 秒钟。

  • 从 50 到 320 个发布服务器,响应时间呈线性增加(近 2 倍)。

管理服务器上配置的连接组数量。

  • 对于 100 个以下连接组,发布服务器上的往返响应时间没有明显变化。

  • 对于 100 到 400 个连接组,往返响应时间会有轻微的线性增加。

管理服务器上配置的访问组数量。

  • 对于 40 个以下访问组,发布服务器上的往返响应时间呈线性增加(近 3 倍)。

下表显示之前每个因素的样本值。在每一次变动中,App-V 5.0 管理服务器都刷新 120 个包。

情景 变动 连接组数量 访问组数量 发布服务器数量 发布服务器/管理服务器的网络连接类型 发布服务器上的往返响应时间(以秒为单位) 管理服务上的 CPU 利用率

同时联系管理服务器以发布元数据的发布服务器。

发布服务器数量

  • 0

  • 0

  • 0

  • 0

  • 0

  • 0

  • 1

  • 1

  • 1

  • 1

  • 1

  • 1

  • 50

  • 100

  • 200

  • 300

  • 315

  • 320

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • 5

  • 10

  • 19

  • 32

  • 30

  • 37

  • 17

  • 17

  • 17

  • 15

  • 17

  • 15

发布元数据包含连接组

连接组数量

  • 10

  • 50

  • 100

  • 150

  • 300

  • 400

  • 1

  • 1

  • 1

  • 1

  • 1

  • 1

  • 100

  • 100

  • 100

  • 100

  • 100

  • 100

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • 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

  • LAN

  • LAN

  • 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 Cable DSL

  • 1.5 Mbps Cable DSL

  • 4

  • 5

  • 1

  • 2

发布服务器与管理服务器之间的网络连接

LAN/WIFI 网络

  • 0

  • 0

  • 1

  • 1

  • 100

  • 200

  • Wifi

  • Wifi

  • 11

  • 20

  • 15

  • 17

无论管理服务器与发布服务器是通过慢速链接网络连接的还是通过高速网络连接的,管理服务器在 30 分钟内都可以处理约 15,000 个包刷新请求。

App-V 5.0 报告服务器容量规划建议

App-V 5.0 客户端向报告服务器发送报告数据。随后,报告服务器将该信息记录到 Microsoft SQL Server 数据库,并向运行 App-V 5.0 客户端的计算机返回成功通知。有关 App-V 5.0 报告服务器支持的配置的更多信息,请参阅 App-V 5.0 支持的配置

note备注
往返响应时间是运行 App-V 5.0 客户端的计算机向报告服务器发送报告信息并收到来自报告服务器的成功通知所花费的时间。

情景 摘要

多个 App-V 5.0 客户端同时向报告服务器发送报告数据。

  • 对于 500 个客户端,报告服务器的往返响应时间为 2.6 秒。

  • 对于 1000 个客户端,报告服务器的往返响应时间为 5.65 秒。

  • 往返响应时间根据客户端数量呈线性增加。

报告服务器每秒处理的请求数。

  • 单个报告服务器和单个数据库每秒可处理最多 139 个请求。平均为每秒 121 个请求。

  • 使用两个报告服务器向同一个 Microsoft SQL Server 数据库报告时,每秒平均请求数与单个报告服务器相似,约 127 个,每秒最多 278 个请求。

  • 单个报告服务器可处理 500 个并发/活动连接。

  • 单个报告服务器最多可处理 1500 个并发连接。

报告数据库。

  • 运行 Microsoft SQL Server 的计算机上的锁争用是每秒请求数的限制因素。

  • 吞吐量和响应时间取决于数据库大小。

“计算随机延迟”:

随机延迟是指将数据发送到报告服务器的最长延迟(以分钟为单位)。计划任务启动时,客户端将生成一个介于“0”与“ReportingRandomDelay”之间的随机延迟时间,并将在规定的持续时间之后发送数据。

随机延迟 = 4 * 客户端数/每秒平均请求数。

示例:如果有 500 个客户端且每秒为 120 个请求,则随机延迟为 4 * 500/120,约等于 17 分钟。

App-V 5.0 发布服务器容量规划建议

将运行 App-V 5.0 客户端的计算机连接到 App-V 5.0 发布服务器以发送发布刷新请求并接收响应。在运行 App-V 5.0 客户端的计算机上测量往返响应时间。在发布服务器上测量处理时间。有关 App-V 5.0 发布服务器支持的配置的更多信息,请参阅 App-V 5.0 支持的配置

重要

下面的列表显示设置 App-V 5.0 发布服务器时需要考虑的主要因素。

  • 同时连接到单个发布服务器的客户端数量。

  • 每次刷新的包数量。

  • 你环境中客户端与 App-V 5.0 发布服务器之间可用的网络带宽。

情景 摘要

同时连接到单个发布服务器的多个 App-V 5.0 客户端。

  • 运行双核处理器的发布服务器可响应至少 5000 个同时请求刷新的客户端。

  • 对于 5000 到 10000 个客户端,发布服务器最低配置要求为四核。

  • 对于 10000 到 20000 个客户端,发布服务器应配备八核,以便获得更有效的响应时间。

  • 配备四核的发布服务器在 3 分钟内可刷新最多 10000 个包。(支持 10000 个同步客户端)

每次刷新的包数量。

  • 增加包的数据将会增加约 40% 的响应时间(最多 1000 个包)。

App-V 5.0 客户端与发布服务器之间的网络。

  • 在慢速网络中(1.5 Mbps 带宽),响应时间比 LAN 增加 97%(最多 1000 个用户)。

note备注
发布服务器的 CPU 使用率在其必须处理同步请求的时间间隔内通常较高(大多数情况下 > 90%)。发布服务器在 1 秒内可处理约 1500 个客户端请求。

情景 变动 App-V 5.0 客户端数量 包数量 发布服务器上的处理器配置 发布服务器/App-V 5.0 客户端的网络连接类型 App-V 5.0 客户端上的往返响应时间(以秒为单位) 发布服务器上的 CPU 利用率(以百分比为单位)

App-V 5.0 客户端发送发布刷新请求并接收响应,每个请求包含 120 个包

客户端数量

  • 100

  • 1000

  • 5000

  • 10000

  • 120

  • 120

  • 120

  • 120

  • 双核

  • 双核

  • 四核

  • 四核

  • LAN

  • LAN

  • LAN

  • LAN

  • 1

  • 2

  • 2

  • 3

  • 100

  • 99

  • 89

  • 77

每次刷新的多个包

包数量

  • 1000

  • 1000

  • 500

  • 1000

  • 四核

  • 四核

  • LAN

  • LAN

  • 2

  • 3

  • 92

  • 91

客户端与发布服务器之间的网络

1.5 Mbps 慢速链接网络

  • 100

  • 500

  • 1000

  • 120

  • 120

  • 120

  • 四核

  • 四核

  • 四核

  • 1.5 Mbps 洲际网

  • 3

  • 10(包含 0.2% 失效率)

  • 17(包含 1% 失效率)

App-V 5.0 流式处理容量规划建议

运行 App-V 5.0 客户端的计算机可以通过流式处理服务器对虚拟应用程序包进行流处理。在运行 App-V 5.0 客户端的计算机上测量往返响应时间,即对整个包进行流处理所花费的时间。

重要

下面的列表标出设置 App-V 5.0 流式处理服务器时需要考虑的主要因素。

  • 同时通过单个流式处理服务器流对应用程序包进行流处理的客户端数量。

  • 要进行流处理的包大小。

  • 你环境中客户端与流式处理服务器之间可用的网络带宽。

情景 摘要

同时通过单个流处理服务器流对应用程序进行流处理的多个 App-V 5.0 客户端。

  • 如果通过相同服务器同时进行流处理的客户端数量增加,则包下载/流处理时间将呈线性关系。

要进行流处理的包大小。

  • 包大小仅对大小约为 1 GB 的大包的流处理/下载时间影响显著。对于大小范围为 3 MB 到 100 MB 的包,流处理时间范围为 20 秒到 100 秒,具有 100 个同步客户端。

App-V 5.0 客户端与流式处理服务器之间的网络。

  • 在慢速网络中(1.5 Mbps 带宽),响应时间比 LAN 增加 70-80%(最多 100 个用户)。

下表显示之前列表中每个因素的样本值:

情景 变动 App-V 5.0 客户端数量 每个包的大小 流式处理服务器/App-V 5.0 客户端的网络连接类型 App-V 5.0 客户端上的往返响应时间(以秒为单位)

通过流式处理服务器对虚拟应用程序包进行流处理的多个 App-V 5.0 客户端。

客户端数量。

  • 100

  • 200

  • 1000



  • 100

  • 200

  • 1000

  • 3.5 MB

  • 3.5 MB

  • 3.5 MB



  • 5 MB

  • 5 MB

  • 5 MB

  • LAN

  • LAN

  • LAN



  • LAN

  • LAN

  • LAN

  • 29

  • 39

  • 391



  • 35

  • 68

  • 461

要进行流处理的每个包的大小。

每个包的大小。

  • 100

  • 200



  • 100

  • 200

  • 21 MB

  • 21 MB



  • 109

  • 109

  • LAN

  • LAN



  • LAN

  • LAN

  • 33

  • 83



  • 100

  • 160

客户端与 App-V 5.0 流式处理服务器之间的网络连接。

1.5 Mbps 慢速链接网络。

  • 100



  • 100

  • 3.5 MB



  • 5 MB

  • 1.5 Mbps 洲际网

  • 102



  • 121

每个 App-V 5.0 流式处理服务器应能处理至少 200 个同时对虚拟化应用程序进行流处理的客户端。

note备注
进行流处理将花费的实际时间主要由同时进行流处理的客户端数量、包数量、包大小、服务器的网络活动和网络条件决定。

例如,一般用户在 2 分钟可以对 100 MB 的包进行流处理,这段时间内有 100 个同步客户端通过该服务器进行流处理。但是,大小为 1 GB 的包会占用长达 30 分钟。在大多数现实世界环境中,流处理需求并不是均匀分布的,你需要了解你环境中存在的大致峰值流处理要求,以便正确确定所需流式处理服务器的数量。

如果预缓存你的应用程序,流式处理服务器可以支持的客户端数量将显著增加并且峰值流处理要求将减少。你还可以通过使用按需流式交付和流处理优化包来增加流式处理服务器可支持的客户端数量。

结合 App-V 5.0 服务器角色

降低缩放和容错要求后,与 Active Directory 连接的位置所需的最少服务器数量为 1 个。此服务器将托管管理服务、管理服务器服务和 Microsoft SQL Server 角色。因此,只要相互之间不冲突,就可以按所需任意组合安排服务器角色。

忽略缩放要求后,实施容错所需的最少服务器数量为 4 个。管理服务器和 Microsoft SQL Server 角色支持放置于容错配置中。管理服务器服务可与任何角色相结合,但仍然是单点故障。

尽管有很多容错策略和技术可用,但并不是所有策略和技术都适用于指定的服务。此外,如果结合 App-V 5.0 角色,由于不兼容,某些容错选项可能不再适用。

想对 App-V 提建议?

此处添加建议或参与投票。有关 App-V 的问题,请使用 App-V TechNet Forum(App-V TechNet 论坛)

另请参阅

概念

App-V 5.0 支持的配置
规划 App-V 5.0 的高可用性

其他资源

计划部署 App-V

-----
你可以在 TechNet Library(TechNet 库)中详细了解 MDOP、在 TechNet Wiki 上搜索疑难解答,或者在 FacebookTwitter 上了解我们的最新动态。
-----