配置 Service Management Automation 实现最佳性能

您是否曾想过，如何配置 Service Management Automation (SMA) 才能确保充分利用自身掌握的各种资源并实现最佳性能？本文将会探讨我们对 SMA 开展的压力和性能测试，阐释这项测试衍生了怎样的系统配置建议。为使这些建议适合您的自定义使用场景，您应该了解我们在测试过程中使用的基准，并充分考虑您自身使用场景的不同之处。同样重要的是，要注意每种组件消耗的资源，哪些组件可以随 SMA 使用量的增加而扩展并实现负载平衡。

首先，业务流程团队究竟如何定义压力和性能测试？我们运用压力测试确定 SMA 系统可以处理的吞吐量，并确保系统在可承受负载下正常运转。至于性能测试，我们将根据处理作业所需的时间来测试系统响应能力，同时还会测试 UI 元素的响应能力。我们的团队已经针对这两种类型的测试创建了用户行为基准模型，其中用户行为通过 Runbook 特征、作业吞吐量和系统资产进行定义。在阅读本文的过程中，请仔细思考您的使用场景的不同之处，以及这些差别可能会对 SMA 的性能造成怎样的影响。您可以将本文作为例子，了解如何自行开展性能分析，从而确保针对您的使用模式设计最佳配置。

SMA 性能和压力分析

我们将稍后在本文中给出相关建议，因为 SMA 硬件是压力和性能测试的直接结果。为了测试系统，需要对预期条件进行一定的分析。通过将这些条件设置为目标，我们就能对做出配置和源代码更改时产生的效果进行比较。

SMA 使用测试建模

在性能测试中，吞吐量大约为 22 个作业/分钟或者 1,320 个作业/小时，旨在模拟一小时高使用率情形。在压力测试中，系统每小时运行 15,000 个作业，从而验证系统在可承受负载下是否稳定。Runbook 作业已被划分为四个不同的类别：小型作业、中型作业、大型作业和长时间运行的作业。不同作业的 Runbook 特征差别在于总的运行时间、是否包含远程调用以及流写入变体。虽然我们无法指定您的 Runbook 的理想总运行时间，但您可以留意其完成任何特定的 Runbook 通常所需的时间长度。如果发现您的作业占用的时间超过通常完成作业所需的时间，应该考虑增加一个 Runbook Worker 以提升性能。本文档对 Runbook Worker 部署管理进行了介绍，您可以借此了解如何向当前部署项目添加 Runbook Worker。

Runbook 作业类别

类别类型	占作业总数的比例	运行时间	远程调用次数	流写入次数
小型作业	20	3 秒	1	4
中型作业	40	15 秒	2	30
大型作业	20	3 分钟	3	100
长时间运行的作业	20	20 分钟	20	1

除作业提交外，测试通信模式还包括通过 Web 服务发出的其他调用。我们通过纳入由编辑 Runbook、更新模块及查看门户页面发出的调用来模拟其他有关通信。

通过确定其他非作业工件数量保持一致的系统状态，并在运行测试的整个过程中保持数量始终不变。这些项目包括：

非作业工件	数量
Runbook	100
计划	50
导入的模块（系统模块除外）	10（最大模块为 30MB）
活动	2248
变量	500
凭据、连接和证书	75

现在，思考一下如何对您的使用模式进行比较。通常同时运行多少个 Runbook？这些 Runbook 的情况如何？另外，您的 Runbook 会输出多少数据？最佳做法是避免从您的 Runbook 写入不必要的输出，应仅出于测试和调试目的使用日志记录，因为将全部此类数据写入数据库费用十分昂贵。同时，还应留意写入工作流的检查点数量。检查点意义非凡，不仅有助于保护 Runbook 防止意外损坏，而且无需重复操作即可重新启动这些 Runbook。但是，每个检查点都需要一定的时间将作业状态保存到数据库中，因此应该谨慎留意纳入检查点的位置。这些检查点将被预留，仅在运行作业期间使用。对于各项 Runbook 作业而言，仅会将最新的检查点存储到数据库中，作业完成后即刻删除对应的检查点。

配置

我们采用不同的组件组合运行性能测试，以便在硬件与性能之间做出权衡。这些配置测试均使用相同的 SQL Server 和计算机资源，从而提供基准进行比较。同时，我们还运行了其他测试，这些测试要么只测试性能要么只测试压力，并且不会进行配置比较。在后面的这些测试中，SQL Server 采用传统设置。在配置测试中，我们改变 Web 服务和 Runbook Worker 安装数量，以便确定上述使用模式的最佳设置。我们在装有 Web 服务和 Runbook Worker 的主机上使用固定磁盘。

我们对每台计算机均应用以下设置：

	核心	内存 (GB)	存储
SQL Server	16	16	SAN 存储
Web 服务	2	4
Runbook Worker	2	4

我们将各组件设置为不同的数量并使用它们运行性能测试，比较每项测试的最大可能吞吐量比例，以便确定最佳组合。最大可能吞吐量比例的计算方法如下：每分钟完成的作业数/每分钟完成的预期作业数。每分钟完成的预期作业数由 Runbook 中定义的运行时间决定。例如，小型作业应在 3 秒内完成，中型作业则在 15 秒内完成。

架构概述

由于大家已经了解这些测试中的使用模型，下面我们来看一下 SMA 的架构，以及测试结果会对建议产生怎样的影响。另外，我还会重点说明一些关键度量标准，从而帮助确定系统运行状况以及各组件的表现，并提供我们的配置建议。综合上述测试与这些建议，将有助于您做出一些资源分配决策，确定应该为 SMA 分配的资源。

  

Runbook Worker、Web 服务和 SQL 数据库是可供修改以处理繁重负载的三大组件。门户用户体验和 PowerShell 也是 SMA 的组件，尽管在本实验中无法对它们做出修改来提高性能。

Web 服务： Web 服务用于管理与外部客户端（如 Windows Azure 包）之间的通信，同时还负责处理身份验证和授权。除非大量用户同时访问 SMA，否则不会造成很大的 Web 服务压力。为实现高可用性，我们建议在多个主机上安装这项 Web 服务并在主机间部署一个负载平衡器。

Runbook Worker：Runbook Worker 用于在 SMA 中执行 Runbook 作业。当将某个作业加入数据库队列后，其中一个 Runbook Worker 将会检索该作业、编译并运行工作流，并将作业信息保存到数据库中。各 Runbook Worker 获取作业并独立于其他 Runbook Worker 单独运行作业，因此您可以通过额外添加 Runbook Worker 轻松地进行扩展。您可以监控每个 Runbook Worker 的 CPU、内存和 IO 消耗量，了解负载会对您的计算机造成怎样的影响。必须至少在三台计算机上安装 Runbook Worker，才能满足我们建议的性能目标。当每分钟提交 22 个作业时，将计算机数量从两台增加到三台，可将最大作业吞吐量比例从 68% 提升到 94%。

SQL 数据库： 该数据库用于存储有关 Runbook、资产和作业的各类信息。与该数据库进行通信是目前面临的主要性能瓶颈之一，因此您希望确保应用正确的使用设置。在考虑该数据库时，资源消耗至关重要，因为性能可能会随写入负载和表格大小的不同而有所差异。如果经历使用高峰期并发现该数据库占用大量磁盘空间，可能会考虑从该数据库中清除一些作业数据。您可以在此处阅读更多内容，了解如何清除该数据库。

门户： SMA 是 Windows Azure 包中的一项服务，服务管理门户提供客户端界面，用于全面进行 Runbook 创作、作业监控和资产管理。该门户的性能在很大程度上取决于数据库以及通过 Web 服务检索信息的速度。如果门户性能（尤其是自动化仪表板）看起来似乎较慢，则应该查看数据库中存储的作业量。您可以修改清除配置设置或使用 Set-SmaAdminConfiguration 来更改用于生成自动化仪表板的时间片段 (ChartTimeSliceSampleSize)。

PowerShell Module ： SMA PowerShell 模块也作为 SMA 的客户端界面。如果倾向于在 PowerShell 中工作，您可以使用此模块（而非门户）有效管理您的自动化任务。

小结

虽然我们发现使用四台专用计算机（一台安装 Web 服务，另外三台安装 Runbook Worker）获得的效果最佳，但相较于使用三台计算机（安装一次 Web 服务和三个 Runbook Worker，即其中一台计算机同时安装 Runbook Worker 和 Web 服务），此设置无法实现太高的吞吐量比例优势。在测试使用的负载方面，此设置以外的任何其他硬件只会对处理的吞吐量造成很小的差别。因此，我们建议在三台计算机上组合安装 Web 服务和 Runbook Worker，并对传入流量应用负载平衡器。应在三个主机（而非一个主机）上安装 Web 服务，以便提高冗余性并确保实现高可用性。

配置和作业吞吐量比较

计算机总数	Web 服务数	Runbook Worker 数	Worker/Web 服务Service 是否在同一台计算机上	最大可能吞吐量比例
4	1	3	否	94.59%
2	1	2	是	66.50%
3	1	3	是	94.40%
3	1	2	否	68.25%

我们的测试表明，Runbook Worker 对处理的作业数量有很大的影响，但部署 Web 服务的计算机数量对系统性能的影响微乎其微。在同一台计算机上同时安装 Runbook Worker 和 Web 服务不会对性能造成重大影响，因此请随意在同一台计算机上安装这些组件。另外我们还发现，即便当 CPU 占用率较高时（大约 90%），Runbook Worker 仍然能够有效地处理业务，较高的 CPU 占用率并不暗示需要任何关注。当您创建其他 Runbook 并将其投入生产时，应当对各 Runbook Worker 上的可用资源以及完成 Runbook 所需的平均时间实施监控。SMA 管理包是一款非常实用的工具，可用于监控 Web 服务和 Runbook Worker 的运行状况。当 Runbook 的平均运行时间增加时，应当考虑额外添加 Runbook Worker。

在整个测试过程中，SQL 速度一直是最大瓶颈，在压力状态下尤其如此。注意存储作业的数目以及写入数据库的频率。我们还发现最好限制所有特定 Runbook Worker 上的并行作业总数，最好设置 SMA 配置文件 Orchestrator.Settings.config 的默认值。

该文件的值如下所示：

• MaxRunningJobs – 可以在沙盒中同时运行的作业数。
• TotalAllowedJobs – 沙盒在其生存期内可以处理的作业总数。达到此限制后，将不再向沙盒分配新作业，以便完成现有作业。而后，将丢弃该沙盒。
• MaxRunningJobsPerWorker – Runbook Worker 上的所有现有沙盒一次可以运行的并行作业数。
• MaxConcurrentSandboxes – Runbook Worker 上一次可以运行的沙盒数。当现有沙盒达到 TotalAllowedJobs      上设置的上限后，将创建新沙盒以处理现有模块版本或应对这种状况。

任何特定 Runbook Worker 上可以运行的并行作业的建议上限 (MaxRunningJobsPerWorker) 默认值为 120 个。您可以修改此数值，但除非确定您的工作负载包含大部分非资源密集型 Runbook（如监控那些占用资源较少但运行很长时间的作业），否则不建议增加这一数值。

希望本文提供的信息具有一定的启发性，帮助您了解如何配置 SMA 实现最佳性能，以及在确定硬件规格和主机数量时应当注意哪些方面。您的最佳环境可能与我们的规格有所差异，具体取决于您的负载情况。本文概括介绍了在做出配置决策时应当注意的核心概念，从而优化 SMA 性能。