从数据中心学到的经验：托管可用性

原文发布于 2012 年 9 月 22 日（星期六）

监控是成功部署 Exchange 的一个主要因素。在以前的版本中，我们斥巨资开发了一个关联引擎，并与 System Center Operations Manager (SCOM) 产品组密切合作，为 Exchange 环境提供全面的警报解决方案。

传统上，监控涉及收集数据和根据收集的数据执行操作（如有必要）。例如，在 SCOM 环境中，使用了不同的机制来通过 Exchange 管理包收集数据：

Exchange Server 2013 监控目标

我们开始开发 Exchange 2013 时，重点是提高所有 Exchange 部署的端到端监控（从最小的本地部署到世界上最大的部署 Office 365）。我们记住了三个主要目标：

1. 将我们的知识和 Office 365 服务体验带给本地客户最近 6 年中，Exchange 产品组一直运营 Exchange Online。我们使用的运营模式称为开发人员运营模式 (DevOps)。在这种模式中，如果开发人员的功能在服务中无法正常运行或当客户报告呈报的未知问题时，问题会直接呈报给该功能的开发人员。无论问题的原因是什么，直接呈报给开发人员会通过解决软件缺陷来为软件的开发提供可追溯性。

   因此，使用此模式后，我们了解了许多内容。例如，在 Exchange 2010 管理包中，有将近 1100 个警报。但经过多年的实践，我们发现，其中只有约 150 个警报在 Office 365 中有用（因此，我们禁用了其他警报）。此外，我们发现，当开发人员收到呈报后，由于他们不希望继续被打扰，或被叫来重复解决同一问题，因此有可能更加对其负责，并努力解决该问题（通过代码修复、通过新的恢复工作流、通过微调警报等）。在 DevOps 模式中，我们有一个流程，即呼叫人员会每周召开一次交接会议，回顾上周的事件；因此开发了内部恢复工作流，如重置 IIS 应用程序池等。在 Exchange 2013 之前，我们具有处理这些恢复工作流的自己的内部引擎。此知识从未用于本地产品。在 Exchange 2013 中，我们对恢复工作流引擎进行了组件化，以便与我们的本地客户共享这些知识。

2. 基于最终用户的体验进行监控我们还了解到，我们用于监控的许多方法其实并不能真正帮助我们运营该环境。因此，我们将转向客户关注的方面，观察我们在监控方面还有哪些差距。

   在过去的版本中，每个组件团队会通过阐明其系统中的所有不同组件来开发一个运行状况模型。例如，传输由 SMTP-IN、SMTP-OUT、传输代理、分类程序、路由引擎、存储驱动程序等组成。然后组件团队会构建有关其中每个组件的警报。这样在管理包中，便会有让您知道存储驱动程序失败的警报。但缺少这样的事实：警报不会告知您端到端用户体验，或者在该体验中哪些方面可能被破坏。所以在 Exchange 2013 中，我们将尝试倒转该模型。我们不会去除系统级别监控，因为那很重要。但真正重要的是，如果您需要管理服务，您的用户会看到哪些内容？所以我们翻转了模型，努力尝试监控用户体验。

3. 通过面向恢复的计算保护用户的体验 对于以前版本的 Exchange，监控的重点在于系统和组件，而不是如何自动恢复和还原最终用户体验。

监控 Exchange Server 2013 - 托管可用性

托管可用性是与 Exchange 的高可用性解决方案集成的监控和恢复基础架构。在发生问题时，托管可用性可检测这些问题，并在发现问题后，从问题中恢复。

托管可用性以用户为重点。我们需要衡量三个主要方面 – 可用性、体验（对于多数客户端协议，它按延迟来衡量）和是否发生错误。为了解这三个方面，让我们观看一个示例：一个使用 Outlook Web App (OWA) 的用户。

可用性方面仅仅是用户是否可访问 OWA 基于表单的身份验证网页。如果用户无法访问，则体验被破坏，并且会生成一个技术支持呈报。就体验而言，如果他们可以登录 OWA，会是什么体验 – 界面是否加载，他们是否可访问其邮件？最后一个方面是延迟 – 用户能够登录并访问界面，但邮件在浏览器中的呈现速度如何？这些方面组成了最终用户体验。

以前版本和 Exchange 2013 的一个主要区别是，在 Exchange 2013 中，我们的监控解决方案不会尝试提供根源（这并不意味着数据不会记录在日志中，或者不会生成转储，或无法发现根源）。您应该知道，在过去的版本中，我们从未有效地显示根源 - 有时我们是正确的，但往往是错误的。

托管可用性的组件

托管可用性内置在 Exchange 2013 的两个服务器角色中。它包括三个主要异步组件。第一个组件是探测引擎。探测引擎的责任是对服务器进行测量。这便引出第二个组件，即监控。监控包含对我们认为正常的内容进行编码的业务逻辑。您可将其视为模式识别引擎；它会在我们具有的不同测量方法中查找不同的模式，然后可决定是否将某项视为正常。最后，还有响应方引擎，我已在下图中将其标记为“恢复”。某项不正常时，它的首个操作是尝试恢复该组件。托管可用性可提供多阶段恢复操作 – 可能先尝试重新启动应用程序池，然后可能尝试重新启动服务，然后可能尝试重新启动服务器，最后可能尝试使服务器脱机，以便其不再接受通信。如果这些尝试失败，托管可用性会通过事件日志通知将该问题呈报给人员。

您可能还注意到我们分散了一些项目。过去，我们每台服务器上都有 SCOM 代理，并且我们会使所有测量流向中央 SCOM 服务器。SCOM 服务器必须评估所有测量，以确定某项是否正常。在高级环境中，会经常运用复杂关联。我们注意到，警报会需要更长时间才能触发等。将所有项推送到一个中央位置未能扩展。所以我们改让每个单独的服务器充当一个岛 – 每台服务器执行自己的探测，自我监控，并采取措施自我恢复，以及在必要时进行呈报。

图 1： 托管可用性的组件

探测

探测基础架构由三个不同的框架组成：

1. 探测是由每个组件团队构建的综合事务。它们与过去版本中的测试 cmdlet 类似。探测可通过执行综合的端到端用户事务来测量服务的认知。
2. 检查是一种被动监控机制，可测量实际的客户流量。
3. 通知框架允许我们立即采取措施，而不是等待探测执行。这样在我们检测到故障时，可立即采取措施。通知框架基于通知。例如，当证书到期时，会触发通知事件，向操作人员发出需要续订证书的警报。

监控

探测收集的数据会送入监控。探测和监控之间不一定有一对一的关联；许多探测可将数据送入一个监控。监控会查看探测的结果，并形成结论。结论是二元的 - 监控正常或不正常。

如上所述，Exchange 2013 监控以最终用户体验为重点。为此，我们必须在环境中的不同层进行监控：

图 2：在不同层进行监控以检查用户体验

您可以从上面的图中看到，我们有四项不同的检查。第一项检查是邮箱自我测试；此探测会验证本地协议或接口是否可访问数据库。第二项检查称为协议自我测试，它会验证邮箱服务器上的本地协议是否正常。第三项检查是代理自我测试，它在客户端访问服务器上执行，验证协议的代理功能是否正常。第四项也是最后一项检查是完整检查，它验证端到端体验（协议代理到存储功能）。每项检查以不同的间隔执行检测。

我们在不同的层监控，以处理相关项。由于 Exchange 2013 中不存在关联引擎，因此我们尝试使用与不同的探测相对应的唯一错误代码和不包括接触相关项的探测区分相关项。例如，如果您看到邮箱自我测试和协议自我测试探测同时失败，这说明了什么问题？是存储出问题了吗？不一定；它真正说明的是邮箱服务器上的本地协议实例不正常。如果您看到正常的协议自我测试，但邮箱自我测试出现故障，那说明了什么问题？该情形说明，“存储”层中出现问题，实际可能是存储或数据库脱机。

从监控角度看，这意味着我们现在可对发出哪种警报具有更精细的控制。例如，在评估 OWA 的运行状况时，如果我们的邮箱自我测试出现故障，而协议自我测试正常，则我们更可能会延迟触发警报；但是，如果邮箱自我测试和协议自我测试监控均未正常运行，则会触发警报。

响应方

响应方根据监控生成的警报执行响应。除非监控运行不正常，否则响应方决不会执行。

有几种类型的响应方：

• 重新启动响应方终止和重新启动服务
• 重置 AppPool 响应方循环 IIS 应用程序池
• 故障转移响应方使 Exchange 2013 邮箱服务器停止运行
• 错误检查响应方启动服务器的错误检查
• 脱机响应方使计算机上的协议停止运行
• 呈报响应方呈报问题
• 专门组件响应方

脱机响应方用于停止客户端访问服务器上使用的协议。此响应方被设计为不依赖于负载平衡器。调用此响应方时，协议不会确认负载平衡器运行状况检查，因此让负载平衡器从负载平衡池中去除服务器或协议。同样，当相应的监控再次正常运行时（假定没有其他关联的监控处于不正常的状态），便会自动启动相应的脱机响应方 – 联机响应方只允许协议响应负载平衡器运行状况检查，从而使负载平衡器能够将服务器或协议添加回负载平衡器池。脱机响应方可通过 Set-ServerComponentState cmdlet 来手动调用。这使管理员能够手动将客户端访问服务器置于维护模式中。

调用呈报响应方时，它会生成 Exchange 2013 管理包可识别的 Windows 事件。它不是正常的 Exchange 事件。它不是说明 OWA 已破坏或我们已具有硬件 IO 的事件，而是说明运行状况集不正常或正常的 Exchange 事件。我们使用这样的单个实例事件来处理 SCOM 中的监控。与分散于整个产品中的事件不同，我们基于在呈报响应方中生成的事件来执行此操作。考虑它的另一方法是间接的级别。托管可用性决定我们何时翻转 SCOM 中的监控。托管可用性做出有关应何时进行呈报（换句话说，人为操作应何时参与）的决策。

还可限制响应方以确保不会破坏整个服务。限制因响应方而异：

• 有些响应方考虑 DAG 或负载平衡 CAS 池中的最小服务器数
• 有些响应方考虑执行之间的时间。
• 有些响应方考虑响应方已启动的次数。
• 有些可能使用以上任意组合。

发生限制时，可能会延迟或跳过响应方的操作，具体取决于响应方。

恢复序列

应了解监控定义执行的响应方的类型和响应方执行的日程表，这一点非常重要；我们将此称为监控的恢复序列。例如，假设 OWA 协议（协议自我测试）的探测数据将监控触发为运行不正常。此时会保存当前时间（我们将此时间称为 T）。监控会启动一个基于当前时间的恢复管道。监控可按恢复管道中的已命名时间间隔定义恢复操作。对于邮箱服务器上的 OWA 协议监控，恢复序列是：

1. 在 T=0 时，执行重置 IIS 应用程序池响应方。
2. 如果在 T=5 分钟时，监控尚未还原为正常状态，则会启动故障转移响应方，并从服务器移除数据库。
3. 如果在 T=8 分钟时，监控尚未还原为正常状态，则会启动错误检查响应方，并强制重新启动服务器。
4. 如果在 T=15 分钟时，监控仍尚未还原为正常状态，则会触发呈报响应方。

监控变为正常时，恢复序列管道将停止。注意，不必等待上一指定时间操作完成，便可开始下一指定时间操作。此外，监控可具有任意数目的指定时间间隔。

Systems Center Operations Manager (SCOM)

Systems Center Operations Manager (SCOM) 可用作查看与 Exchange 环境相关的运行状况信息的门户。SCOM 门户中的不正常状态由写入应用程序日志的事件通过呈报响应方触发。SCOM 仪表板经过优化，现在具有三个主要区域：

• 活动警报
• 组织运行状况
• 服务器运行状况

SCOM 2007 R2 和 SCOM 2012 将支持 Exchange Server 2013 SCOM 管理包。

替代

对于任何环境，默认值可能并不总是最佳条件，或者可能存在需要紧急操作的条件。托管可用性包括为整个环境或对单个服务器启用替代的能力。可为每个替代设置指定期限，或将其设置为应用于服务器的特定版本。凭借 *-ServerMonitoringOverride 和 *-GlobalMonitoringOverride cmdlet，管理员可设置、移除或查看替代。

运行状况确定

类似或绑定到特定组件的体系结构的监控组在一起形成运行状况集。运行状况集的运行状况始终由运行状况集中的监控的“最坏”评估确定 – 这意味着如果您的运行状况集中有 9 个监控，其中 1 个监控不正常，则会将该运行状况集视为不正常。您可使用 Get-MonitoringItemIdentity cmdlet 确定给定运行状况集中的监控（以及关联的探测和响应方）的集合。

为查看运行状况，可使用 Get-ServerHealth cmdlet 和 Get-HealthReport cmdlet。Get-ServerHealth 用于检索原始运行状况数据，而 Get-HealthReport 对原始运行状况数据进行操作，并提供运行状况的当前快照。这些 cmdlet 可在多个层运行：

• 它们可显示给定服务器的运行状况，按运行状况集进行分类。
• 它们可用于探索特定运行状况集，并查看每个监控的状态。
• 它们可用于总结给定服务器组（DAG 成员或 CAS 的负载平衡数组）的运行状况。

运行状况集可进一步分为功能单位（称为“运行状况组”）。共有四个“运行状况组”，它们用于在 SCOM 管理门户中进行报告：

1. 客户接触点 – 具有直接实时客户交互的组件（如 OWA）。
2. 服务组件 – 没有直接实时客户交互的组件（如 OAB 生成）。
3. 服务器组件 – 服务器的物理资源（如磁盘、内存）。
4. 相关项可用性 – 服务器调用相关项（如 Active Directory）的能力。

结束语

托管可用性可在每台服务器中执行各种运行状况评估。这些常规的定期测试可确定服务器上各个组件的可行性，从而在用户负载之前和之中确定服务器（或服务器组）的运行状况。检测到问题时，会采取多步骤纠正措施，使服务器回到正常状态；如果服务器未返回到正常状态，则托管可用性可向操作员发出需要注意的警报。

最终结果是托管可用性以用户体验为重点，并确保在发生问题时，尽量减少对体验的影响，甚至不影响体验。

这是一篇本地化的博客文章。请访问 Lessons from the Datacenter: Managed Availability 以查看原文