移动功能的容量规划
上一次修改主题： 2011-12-05
确定实现移动功能所需的容量是一个迭代过程，此过程包括估计移动使用情况、测量当前容量、规划额外的容量和监视性能关键指标。下图说明了容量规划过程所包含的阶段以及每个阶段所涉及的因素。
移动功能容量规划工作流
.jpg "015701c0-77a2-4622-9c01-76576dea0140")
本节介绍了您在估计移动使用情况时需考虑的因素，并提供了有关确定需要部署的移动功能的规模的准则。
有关监视使用情况和性能指标的详细信息，请参阅：
有关监视服务器内存的详细信息，请参阅针对服务器内存容量限制进行监视。
有关监视移动使用情况的详细信息，请参阅监视 Mobility Service 的使用情况。
有关监视 IIS 跟踪日志文件的详细信息，请参阅监视 IIS 请求跟踪日志文件。
有关可用于监视移动的性能计数器的详细信息，请参阅移动性能计数器。
有关配置 Mobility Service 以实现高性能的详细信息，请参阅配置 Mobility Service 以实现高性能。
影响容量的因素
以下三个因素将影响针对运行 Microsoft Lync Server 2010 Mobility Service 的前端服务器的容量规划：
用户模型
移动设备特征
可用 RAM
用户模型
针对移动功能的容量规划度量和建议均以本节介绍的用户模型为基础。
每个用户的平均联系人数
| 联系人类别 | 每个用户的平均数目 |
|---|---|
所有联系人 |
80 |
企业联系人 |
64 |
联盟联系人 |
8 |
PIC 联系人 |
6 |
通讯组 |
2 |
最常使用的联系人 |
15 |
最近使用的联系人 |
10 |
每个用户的每日活动
| 每日活动 | 工作时间内的数目 | 工作时间外的数目 |
|---|---|---|
登录移动应用程序 |
10 |
2 |
电话呼叫（数目） |
10 |
2 |
电话呼叫（持续时间） |
每次呼叫 2 分钟 |
每次呼叫 2 分钟 |
会议 |
每周 1 次 |
0 |
每次会议的参与者 |
<10 |
0 |
状态通知更改 |
1 |
0 |
对联系人卡片的查看 |
6 |
1 |
对联系人列表的查看 |
9 |
1 |
对联系人列表的浏览 |
3 |
0 |
全局地址列表 (GAL) 搜索 |
5* |
- |
手动状态更新 |
0.5 |
0 |
每个联系人的状态更新总数 |
6 |
0 |
呼叫转接 |
0.5 |
0 |
即时消息 (IM) 会话（数目） |
3 |
1 |
IM 会话（持续时间） |
每次会话 6 分钟；每 30 秒一条消息 |
每次会话 6 分钟；每 30 秒一条消息 |
日历查找（与 Exchange Web 服务的连接） |
11 |
3 |
* GAL 搜索数 = 每天 1 次手动搜索 + 自动搜索次数（为传出即时消息和呼叫总数的一半）。即，1 + 2（即时消息）+ 2（呼叫数）=5。
移动设备特征
支持移动功能的移动设备可运行各种操作系统。操作系统在用户切换到其他应用程序时管理应用程序的方式将影响容量规划。为了进行容量规划，可将操作系统分为以下两类：
启用了后台 当用户在 Apple 和 Windows Phone 移动设备上切换到其他移动应用程序时，Lync 2010 移动应用程序将转到后台并丢失与 Lync Server 2010 的连接。该移动应用程序将由推送通知重新激活，或在用户手动将其移到前台时被激活。
始终连接 当用户在 Android 和 Nokia 移动设备上切换到其他移动应用程序时，只要用户保持登录状态，Lync 2010 移动应用程序就会保持与 Lync Server 2010 的连接。
Android 和 Nokia 移动设备会对服务器上产生更大的负载，因为它们将保留与服务器的连接，即使用户未主动使用移动应用程序也是如此。
可用内存
本节后面所述的规模准则将帮助您确定实现移动功能所需的内存量。若要确定服务器上可用的物理内存量，请使用 Memory 和 Available Mbytes 性能计数器。此性能计数器指示可用于运行进程的物理内存量 (MB)。如果可用于运行进程的内存量少于物理内存总量的百分之五 (5%)，则表示服务器的内存不足，这会导致增加分页。
规模准则
Mobility Service 会使用前端服务器上的额外内存、处理器资源和网络资源。在规划容量时，您需要了解移动负载对前端池产生的影响并决定是否需要额外的硬件来应对移动负载。请使用下表中的规模示例来帮助确定是否需要额外的硬件以及需要多少额外的硬件。
该表中的示例基于某些公式和假设。这些公式和假设使用以下定义：
AC 表示用户模型中始终连接的移动应用程序的数目。
BE 表示用户模型中针对后台启用的移动应用程序的数目。
公式和假设如下：
目标内存 (TM) (MB) = 164 + (AC * 534 + BE * 400) / 1024。
TM 是最小必需内存量。
在前面所述的用户模型中，与前端池的连接的数目为 AC * 2 + BE * .20。
当服务器上没有内存压力时，测量的内存量可能更高（最大值为每个终结点 1MB）。如果用户模型更加主动（例如，在有多个音频/视频 (A/V) 呼叫或联系人的情况下），则目标内存量会更高。
每秒创建的连接数小于或等于每千用户每秒 30 个连接。此数目依赖于硬件负载平衡器上的连接池设置和保持连接设置。
下表显示了用户模型中 50% 的始终连接用户的规模示例。
规模示例
| 用户数 | 内存 (MB) | 平均 CPU | 最大 CPU |
|---|---|---|---|
1,000 |
620.05 |
1% |
2.5% |
2,000 |
1076.11 |
6% |
8% |
3,000 |
1532.16 |
14% |
18% |
4,000 |
1988.22 |
14% |
18% |
5,000 |
2444.27 |
14% |
18% |
方案示例
下面的示例说明如何将规模准则应用于虚构的大型企业和一个包含两台服务器的前端池。
大型企业
Contoso 已在三个池（每个池包含四台前端服务器）中部署 75,000 个用户。Contoso 计划对 30,000 个用户启用 Mobility Service。
在规划阶段，Contoso 管理员将捕获以下数据：
每台前端服务器均具有 3 GB 的可用内存。
CPU 使用率低于 60%。
所有用户都拥有 iPhone 或 Windows Phone 移动设备。
Contoso 的用户模型与本节前面所述的容量规划用户模型类似。
每台服务器的最小必需内存为 164 + 2500 * 400 / 1024 = 1133 MB。当有可用内存时，可能会对移动应用程序分配更多内存，因为将根据需要释放内存（最多 2.7 GB）。在任一情况下，Contoso 都不需要升级前端服务器硬件。
.gif "note") 注意： |
|---|
| 移动 CPU 利用率的目标是达到 10% 的平均值。当 CPU 利用率接近 70% 的服务器限制时，Contoso 需要监视 CPU 处理器时间。 |
包含两台服务器的前端池
Contoso 已在包含两台服务器的前端池中部署 8,000 个用户。Contoso 计划对所有用户都启用 Mobility Service。
在规划阶段，Contoso 管理员将捕获以下数据：
每台前端服务器均具有 2.5 GB 的可用内存。
CPU 使用率低于 60%。
所有用户都拥有 Nokia 或 Android 移动设备。
Contoso 的用户模型与本节前面所述的容量规划用户模型类似。
每台服务器的最小必需内存为 164 + 4000 * 534 / 1024 = 2242 MB。理论上说，服务器可以支持该负载。但是，如果两台服务器之间发生故障转移，则服务器无法支持该负载。此外，移动 CPU 使用率将高于 10%，并且将达到服务器的 70% 的 CPU 限制。
在此方案中，建议向池中添加服务器。新的负载分配为每台前端服务器 2667（即 8000/3）个用户。额外的移动成本为 2667 * 534 / 1024 = 1390 MB。
添加一台服务器后，如果发生服务器故障转移，则池中的所有三台服务器都将额外接受 1,300 个用户，负载将增加 600 MB。通过新的负载分配，CPU 利用率也将保持在 70% 的服务器限制以下。