数据库大小调整和性能

数据库大小调整是了解 System Center - Orchestrator 性能的关键。 Runbook 服务器、Management 服务器和 Web 组件全部依靠 Orchestrator 数据库来执行其操作。 业务流程协调程序部署的问题可能源于对数据库中数据类型的不完全了解以及如何管理它们。

因为 Runbook Designer(通过 Management 服务器)与 Orchestrator 数据库通信,所以数据库性能不良将妨碍该通信。

Orchestrator 操作员体验基于两个组件: 业务流程控制台 和 Web 服务。 “Orchestration 控制台” 是依靠 Web 服务连接到 Orchestrator 数据库的基于 Silverlight 的应用程序。 Web 服务是连接到数据库的 IIS 应用程序。 因此,Web 服务和 业务流程控制台 都依赖于 Orchestrator 数据库的性能。

此外,虽然“Orchestration 控制台” 与 Web 服务相关,但它也具有起用户界面作用所特有的逻辑,及其自己的性能特征。

配置数据和日志数据

在高级别上,Orchestrator 数据库包含两种类型的数据:

配置数据

Orchestrator 基础结构包含配置数据。 此数据在数据库增长的上下文中并不担心,因为此类数据的存储要求很小。

日志数据

Orchestrator 会创建不同类型的日志数据,所有这些数据都可以在 Runbook 设计器查看和管理。 此数据的存储要求可能因大小而异,并且可能很大。

下表列出了可存储在 Orchestrator 数据库中的日志数据的类型。 Orchestrator 还会将数据存储在单独的日志文件(数据库外部)中,以便进行审核跟踪和跟踪。 有关日志数据的所有类型的详细信息,请参阅 Orchestrator Logs

日志数据的类型 Runbook Designer 中的位置 是否通过日志清除来管理?
Runbook 日志 “日志” 和“日志历史记录” History 选项卡
活动(平台)事件 “事件” 选项卡
审核历史记录 “审核历史记录” 选项卡

平台代码和域代码

Orchestrator Runbook 活动包含两种不同的代码类型:

  • 平台代码

    这是大多数活动共享的常见代码,用于运行 Orchestrator 活动执行的常见任务。 平台代码生成常用已发布数据。

  • 域代码

    针对每个活动(通常不与 Orchestrator 平台本身关联的)运行特定于操作的各种任务。 平台代码和域代码之间可能存在很大的差异。

针对给定活动生成的日志记录数据可能包含具有单个或多个值的数据元素。 每个活动都会产生单值数据的单个记录。 域代码可以产生多值数据的多个记录,因此负责确定活动对其从以前活动中接收的常用已发布数据所执行的操作。

实质上,Orchestrator Runbook 旨在域代码的离散元素之间传递数据。 此外,域代码可以根据需要生成特定于活动的已发布数据。

所有 Runbook 都具有核心相似性,因为它们运行包含域代码和平台代码的活动、它们循环执行工作流并且它们会进行分支。 分支是当 Runbook 调用其他 Runbook 以执行特定任务。 首次调用 Runbook 时,它由单个线程组成。 当此线程遇到其链接需要分支的 Runbook 活动时,系统会为每个分支额外创建一个线程。 每个线程都会将创建分支的活动中的常用已发布数据作为输入。 此数据将回过来与 Runbook 中以前的活动关联,以更新活动所订阅的常用已发布数据。

域代码对数据库性能的影响可能会超过分支所生成的多线程处理所造成的影响。 这是因为域代码可能会生成大量特定于活动的已发布数据。

日志记录选项

利用 Runbook 的“属性” 上的“日志记录” 选项卡,你可以根据需要存储日志记录条目。 术语“默认日志记录” 是指不选择两个已发布数据选项中的任何一项,这意味着为每个活动生成了 524 个字节。 日志记录选项供两类常用已发布数据使用:

  • 常见已发布数据

    所有活动所共有的数据项目集。 有关列表,请参阅 Runbook 日志选项

    此日志记录选项为每个活动生成了 6082 个字节。

  • 特定于活动的已发布数据

    特定于域代码根据需要创建的活动的数据集。

    此日志记录选项生成 6082 个字节,以及特定活动所记录的字节。

    提示

    选择此选项主要用于调试目的。 取消选中复选框以限制日志记录增长。

设置日志记录选项可能会显著影响性能,并增大数据库增长。 请考虑运行两次相同 Runbook 活动的情况,第一次具有默认级别的数据日志记录(未选择已发布数据选项),然后进行设置并选择常用已发布数据。 完成域代码所需的时间量应该相同。 但是,平台代码的所需运行时间将较长,因为它必须支持的常用已发布数据日志记录是仅支持默认日志记录时的 12 倍。

清除日志

Runbook 设计器日志清除功能指定的默认选项配置为为现用业务流程协调程序部署提供最佳用户体验。 更改这些值可以更改环境的性能特征,并应逐步实施和高水印,以便评估更改的效果。

有关日志的自动清除和手动清除的详细信息,请参阅 清除 Runbook 日志

创建性能基准

若要创建简单的 Runbook 来测试日志记录增长,可以使用标准活动 比较值 来创建 Orchestrator 环境的基准。

以下过程创建一个 Runbook,该 Runbook 运行 比较值 活动 10,000 次。 比较值 是一个简单的活动,其域代码最少。 可以在各种情况下调用此 Runbook,以描述给定 Orchestrator 运行时环境的整体性能。

创建可用于对 Orchestrator 环境进行基准测试的 Runbook

  1. 创建一个新的 Runbook。

  2. 从“标准活动”调色板中添加 Compare Values 活动。 双击活动以对其进行配置。

  3. 选择“ 常规 ”选项卡并配置此活动以比较字符串(默认值)。

  4. 选择“详细信息”选项卡,在“测试”框中输入值 STRING,然后选择为空

  5. 选择“完成以将更新保存到活动。

  6. 右键单击该活动,然后选择“循环”

  7. 选中“启用”复选框,然后输入第 0(零)表示尝试之间的延迟。

  8. 选择“退出”选项卡。

  9. 更改默认的退出条件。 选择“比较值”,选中“显示通用已发布数据”复选框,然后选择“循环:尝试次数”。 选择“确定保存此更改。

  10. 从更新的退出条件中选择 ,并输入数字 10000 (万)。 选择“确定保存此更改。

  11. 选择“完成以保存这些更新。

  12. 选择“签入以保存对 Orchestrator 数据库的更改。

此 Runbook 可以用于实验 Orchestrator 的不同配置。 例如,你可以创建基准 Runbook 以确定部署到不同数据中心的四个 Runbook 服务器的性能。

数据中心 日志记录配置 平台代码运行时间(毫秒) 每个活动的毫秒数 比例系数
位置 1 默认日志记录 819 82 1.0(参考)
位置 1 记录常用已发布数据 2012 201 2.5
位置 2 默认日志记录 1229 123 1.5
位置 2 记录常用已发布数据 3686 369 4.5
位置 3 默认日志记录 2457 426 3.0
位置 3 记录常用已发布数据 4422 442 5.4
位置 4 默认日志记录 1474 147 1.8
位置 4 记录常用已发布数据 2654 265 3.2

请注意,常用已发布数据的日志记录使平台性能大大降低。 位置 2 的常用已发布数据日志记录情况似乎最不理想。 表面上看,结论似乎清晰且没有偏题。

但是,应该注意到这些数字反映的是平台代码的开销,而不是域代码的开销。 域代码运行时可能更长。 例如,在创建 VM 时,Virtual Machine Manager 集成包中的“从模板创建 VM” 活动可能会运行若干分钟。 在前面的示例中展开,请考虑 Runbook 活动的平台代码成本,无论位置如何,该活动需要 1 分钟运行(1 分钟 = 60,000 毫秒)。

数据中心 日志记录配置 平台代码运行时间(毫秒) % 域代码 % 平台代码
位置 1 默认日志记录 819 98.6% 1.4%
位置 1 记录常用已发布数据 2012 96.7% 3.3%
位置 2 默认日志记录 1229 98.0% 2.0%
位置 2 记录常用已发布数据 3686 93.9% 6.1%
位置 3 默认日志记录 2457 95.9% 4.1%
位置 3 记录常用已发布数据 4422 92.6% 7.4%
位置 4 默认日志记录 1474 97.5% 2.5%
位置 4 记录常用已发布数据 2654 95.6% 4.4%

更清楚的图片开始从数据中显现出来。 在位置 2 处启用常用已发布数据日志记录的情况仍然表现最差。 但是,平台代码和日志记录仅占总运行时的 6%。 这是一个大数字,而最佳案例情况为 1.4%。 实质上,示例中花在域代码上的时间远远超过了运行平台代码所花费的时间。 为此,如果能够完全消除平台代码成本,则只会在 1.4% 到 7.4% 的范围内看到 Runbook 性能改进。

大多数实际方案将有所不同。 活动行为可能会发生变化,具体取决于为域代码所指示的操作。 例如, 从模板 活动克隆 VM 可能需要一分钟才能从服务器模板 A 克隆 VM,但需要 5 分钟才能从服务器模板 B 克隆 VM。此外,Runbook 服务器可能位于具有不同性能特征的不同网络上,这可能会影响域代码性能和 Orchestrator 数据日志记录性能。

确定数据库增长

Orchestrator 数据库的数据库管理员可以使用以下准则来确定数据库文件增长策略:

  • 一般情况下,数据库文件的大小不会随着 Runbook 的每个调用而增加。 当文件中包含的数据达到了数据库管理员所配置的某个高水印时,文件将会增长,此时通常会扩展文件。

  • 每次运行 Runbook 活动时,都应单独计数该活动,当循环功能可能导致单个活动多次运行时,应考虑该操作。

  • 若要确定每次调用 Runbook 所需的存储,请将 Runbook 中的活动数乘以根据所选日志记录级别添加到数据库的字节数。 其值如下所示:

    • 524 个字节

      默认日志记录配置。

    • 6082 个字节

      常用已发布数据日志记录级别。

    • 6082 个字节 + 活动记录的数据

      特定于活动的已发布数据日志记录级别。

  • 默认情况下,Orchestrator 将在凌晨 2:00 点清除每个 Runbook 最近 500 条日志之外的所有日志。 若要确定每次调用 Runbook 所需的存储空间,请将每次调用 Runbook 所需的存储空间乘以 500。 如果更改“日志清除”设置,请根据需要将每次调用乘以每天、每周或每月的调用估计数。

下表显示了日志记录级别配置的增长和性能估计值。

日志记录级别 DB 增长因子 性能因子 推荐用于生产
默认 1 1
常用已发布数据 11.6x 2.5x 按计划限制使用
特定于活动的已发布数据 大于 11.6x 大于 2.5x

示例

示例 1

下表介绍了 Orchestrator 部署的数据库大小调整注意事项。

Runbook 名称 活动数目 日志记录级别 每天的调用数
Runbook 1 50 默认 100
Runbook 2 25 默认 50
Runbook 3 12 常用已发布数据 24
Runbook 4 8 常用已发布数据 500

通过使用上述数据库大小,你可以估计 Runbook 的存储要求。

Runbook 名称 每个调用的字节数 以 MB 为单位的存储

默认日志清除(500 个调用)
每月的调用数 以 MB 为单位的存储

一个月

(非默认日志清除)
30 天后的数据库存储的 %
Runbook 1 26,200 12.5 3,000 74.5 9%
Runbook 2 13,100 6.2 1,500 18.7 %2
Runbook 3 72,984 34.8 720 50.1 6%
Runbook 4 48,656 23.2 15,000 696.0 83%
总数:76.7 MB 总计:839.3 MB

此示例清楚地证明了做出合理的数据日志记录决策的重要性。 Runbook 4 仅包含 8 个活动,但在通用已发布数据日志记录级别配置时,由于调用频率高,它消耗了数据库中的大部分存储。 根据这些结果,你可能更喜欢将 Runbook 4 的日志记录级别减少到默认日志记录配置。

示例 2

下表介绍了 Orchestrator 的另一个部署的数据库大小调整注意事项。

Runbook 名称 活动数目 日志记录级别 每天的调用数
Runbook 1 50 默认 100
Runbook 2 25 默认 50
Runbook 3 12 常用已发布数据 24
Runbook 4 8 默认 500

如果重新计算更新配置的存储数值,则会产生明显不同的结果。

Runbook 名称 每个调用的字节数 以 MB 为单位的存储

默认日志清除(500 个调用)
每月的调用数 以 MB 为单位的存储

一个月

(非默认日志清除)
30 天后的数据库存储的 %
Runbook 1 26,200 12.5 3,000 74.5 37%
Runbook 2 13,100 6.2 1,500 18.7 9%
Runbook 3 72,984 34.8 720 50.1 25%
Runbook 4 4,192 2.0 15,000 60.0 29%
总数:55.5 MB 总计:203.3 MB

虽然默认日志记录配置(每个 Runbook 500 个日志条目)几乎没有变化,但 30 天的存储要求发生了很大变化。 显然,应仔细考虑对 Runbook 4 使用通用已发布数据日志记录的存储成本,因为此更改导致数据库存储要求在 30 天内减少 76%。

总结

使用以下准则来管理数据库大小和性能:

  • 仅在需要时启用常用已发布数据的日志记录。

  • 请记住,活动的运行次数决定了记录的数据量。 运行多个活动的小型 Runbook 可能会导致数据日志记录多于大型 Runbook 的运行次数较少。

  • 不要在生产环境中启用特定于活动的已发布数据的日志记录,并且只应用于调试目的。

  • 加强理解 Runbook 运行域代码所花费的时间(与运行平台代码相比)。

  • 使用本文档中介绍的方法估计平台代码成本。 考虑在哪些方面提高 Runbook 性能时用作参考。

  • 通过对测量进行规范化比较以确定改进的机会。

另请参阅