Lync Server 2013 中的容量和可用性管理
上次修改的主题： 2014-08-18
容量管理和可用性管理的目的是衡量和控制系统性能。 建议实施容量管理和可用性管理过程，以便可以衡量和控制系统性能。 你必须知道系统是否可用，以及它是否可以通过设置基线和监视系统来查找趋势来处理当前和预计的需求。
容量管理
容量管理涉及规划、调整和控制服务容量，以帮助确保超出 SLA 中指定的最低性能级别。 良好的容量管理有助于确保可以以合理的成本提供 IT 服务，并且仍能满足 SLA 中与客户端一起定义的性能级别。 这些条件可以包括以下内容：
系统响应时间 这是系统执行典型操作所需的测量时间。 示例包括音频/视频服务器角色处理音频/视频流量所需的时间、客户端创建和加入会议所需的时间，或在所有观察程序客户端中更新状态所需的时间。
存储容量 这是存储系统的容量，无论是内容数据库、备份设备还是本地驱动器。 示例包括每个站点要提供的最大存储空间量，以及在覆盖备份之前应存储备份的时间。
调整容量通常是确保有足够的物理资源可用的情况，例如磁盘空间和网络带宽。 下表列出了与容量相关问题的典型解决方法。
与容量相关问题的典型解决方法
| 问题 | 可能的解决方法 |
|---|---|
音频/视频性能不佳的远程用户 |
检查 WAN 链接是否提供适当的带宽，以及是否启用并正确配置了 QoS。 检查 QoE 数据。 |
Lync 环境的总体响应速度很慢。 |
运行测试以检查现有前端服务器是否可以处理负载。 如果需要，请引入新的前端服务器。检查 SQL 数据库响应时间并修复延迟的原因 (例如，改进磁盘 I/O) 。 |
Lync Server 网络指南更详细地介绍了故障排除。
容量受系统配置的影响，并依赖于物理资源，例如网络带宽。 例如，如果 Lync 环境配置为每晚执行完整备份，则必须小心帮助确保将最终用户体验到的交互式性能的影响降到最低。
容量管理是将系统容量保留在可接受级别并解决以下问题的过程：
响应需求变化 必须调整容量要求，以考虑系统或组织中的更改。 例如，如果你的环境决定实现企业语音，中介服务器和公共交换电话网络 (PSTN) 网关的数量和位置将非常重要。 如果要 (SIP) 中继或直接 SIP 执行会话启动协议，则整体设计将发生重大更改，以提供最佳企业语音性能。
预测未来要求 随着时间推移，某些容量要求会发生可预测的变化。 通过跟踪趋势，可以提前计划升级。 例如，必须监视各种 Lync 站点之间的可用带宽才能创建基线。 此基线允许你预测何时必须向这些链接添加更多带宽，因为这些远程站点中的用户计数随时间的增加而增加。
可用性管理
可用性管理是确保任何 IT 服务一致且成本高效地提供客户所需的一致可靠服务级别的过程。 可用性管理涉及最大程度地减少服务损失，并确保在服务丢失时采取适当措施。 在 Lync 环境中，你可能担心企业语音服务是否可用、用户是否可以加入计划的会议等。 SLA 定义了可接受的中断频率和长度，并允许在系统不可用于计划内维护的特定时间段内。
如果必须向管理层提供有关系统可用性的报告，或者如果你有与缺少可用性目标相关的财务或其他处罚，则必须记录可用性数据。 即使你没有这样的正式要求，也最好至少知道系统在某个时间段内发生故障的频率。 例如，过去 12 个月的系统可用性，以及每次故障恢复所用的时间。 此信息将帮助你衡量和提高团队应对系统故障的有效性。 如果存在争议，它还可以提供有用的信息。
与可用性相关的度量值如下所示：
可用 性 这通常表示为可以访问系统或服务的时间与关闭时间相比。 它通常以百分比表示。 (你可能会看到对“三个九”或“五个九”的引用。这些是指 99.9% 或 99.999% 的可用性。)
可靠性 这是系统故障之间时间的度量值，有时表示为故障 (MTBF) 之间的平均 (或平均) 时间。
修复时间 这是在发生故障后恢复服务所花的时间，通常表示为平均 (意味着修复 (MTTR) 的平均) 时间。
可用性、可靠性和修复时间如下所示：
可用性 = (MTBF - MTTR) /MTBF 例如，如果服务器在 6 个月内失败两次，且平均 20 分钟不可用，则 MTBF 为 3 个月或 90 天，MTTR 为 20 分钟。 因此，可用性 = (90 天 – 20 分钟) /90 天 = 99.985%。
可用性管理是确保最大化可用性并保留在 SLA 中定义的参数中的过程。 可用性管理包括以下过程：
监测 检查服务不可用的时间和时间。
报告 应定期向管理层、用户和运营团队提供可用性数据。 这些报告应突出显示趋势，并确定表现良好的领域和需要注意的领域。 报表应汇总与 SLA 中设置的目标的符合性。
改进 如果可用性不符合 SLA 中定义的目标或趋势是降低可用性，则可用性管理过程应计划补救步骤。 这应包括与其他负责的团队合作，突出中断的原因，并计划补救措施以防止再次发生中断。
容量和可用性度量是重复性任务，非常适合自动化工具和脚本，例如 Microsoft System Center Operations Manager (以前的 Microsoft Operations Manager) ，本文档稍后将对此进行讨论。