自动化数据中心运营的5种方法

数据中心自动化是在没有任何人工操作的情况下完成数据中心操作的常规过程的过程。它提高了运营效率，提高了数据准确性，并简化了数据中心管理。

Workday 是通过与数据中心基础设施管理 (DCIM) 软件集成来推动自动化的领先组织之一。Workday 成为 Sunbird 的客户已有五年多了，目前他们的系统上有 900 多名用户，并且还在不断增长。

在最近的Automation Workshop 网络研讨会中，Workday 的数据中心专家分享了他们的真实用例，并分享了他们如何使用 API 和集成来消除数据中心运营中的手动工作的见解。

“对于我们在全球数据中心拥有的数万个裸机资产，DCIM 确实是我们的真实来源，”高级软件工程师经理 Tim Putney 说。

Workday 的 DCIM API 架构的主要设计目标

当 Workday 设计他们的 DCIM API 模型时，他们考虑了三个关键目标：

自动的。Workday 希望能够以编程方式执行几乎所有可通过 DCIM GUI 完成的任务，以降低支持负担并为其他优先事项节省时间。

安全的。由于系统上有如此多的用户，Workday 团队知道他们需要细粒度的基于角色的访问控制，这种访问控制在访问服务和可以对数据执行的操作方面都遵循最小特权原则。

快速地。由于他们期望越来越多的客户端、请求和资产，Workday 需要强大的性能来支持他们的 API 驱动的全球环境以及极端的可扩展性。

Workday 的 DCIM API 架构

在活动期间，首席 DevOps 工程师 Tony Lincoln 展示了 Workday 的 DCIM API 架构示意图。

底层是 Sunbird 的 dcTrack DCIM Operations 设备。它有一个 GUI 和两种以编程方式访问底层数据的方法：本机 dcTrack API 和 ODBC 接口。顶层是 Workday 的 DCIM 套件，它本身包含多个层。

Workday的逻辑架构体现了他们的设计目标是自动化、安全、快速，同时也体现了一些实际的考虑。他们拥有具有不同需求和访问方法的各种用户。开发人员和工程师运行命令行界面 (CLI) 或 API，服务帐户是他们持续集成管道的一部分，而业务用户直接访问 GUI。

“我们的 API 用户在 Workday 习惯了一个通用的 API 平台，”Lincoln 说。“我们的一些查询——尤其是几年前——需要自定义 SQL 语句来优化性能。我们监控了以非常高的频率发生的查询，我们还有其他非常复杂的查询。正如你所看到的，我们提供多层访问。我们有一个 Python 库，它提供直接的客户端方法，抽象出 dcTrack 的两个访问点。”

这种架构使 Workday 能够通过在本机 dcTrack API 调用和通过 ODBC 的原始 SQL 之间进行选择来优化其 API 调用。他们可以挑选他们需要的性能。除此之外，他们还有一个REST API 。

“这是具有通用身份验证、授权和日志记录的通用 API，”Lincoln 说。“这是一个自主开发的 Workday 层，我们通过开发到该层来提高效率。”

API 之上是一个 CLI，它使用底层来提供一个简单的交互式工具。这被 Workday 的工程师大量使用，他们进行了单独的更改，其中一些工程师将其嵌入到更复杂的工作流中，这些工作流被捕获在Ansible剧本中。

“他们可以通过将 CLI 与 Ansible 混合搭配来扩大他们的 CLI，”Lincoln 说。

Workday 的自动化架构

高级 DevOps 工程师 Moshe Haber 解释了 Workday 如何在他们的自动化架构中使用Jenkins 。

“Jenkins 是一个非常强大的自动化工具，它使用各种插件与 Jira、Slack 和其他应用程序进行了大量集成。当然，我们有自己开发的 REST API，它允许我们进行身份验证、授权和收集一些指标。例如，各种自动化作业能够作为 Jenkins 作业运行，它们能够通过 Workday API 访问 dcTrack API。它们能够访问各种表、事件日志、审计日志、事务日志和其他表格，并生成详细的报告。使用这种架构可以提供很多功能。”

Workday 通过集成实现自动化的 5 个用例

1. 供应和编排。

在 Workday 部署 dcTrack 之前，他们有一个自己开发的工具，他们已经开始与其他系统集成。他们马上了解到，除非他们能够近乎实时地执行此操作，否则他们将遇到数据完整性问题，因为他们的资产工具可能会报告在机器配置完成之前不准确的值。这有可能造成运营、合规性和可信度方面的问题。为了克服这一挑战，Workday 开始讨论“生成之源”的概念，类似于众所周知的“真理之源”。

“我们意识到我们需要一种方法来跟踪两者，”林肯说。“我们的解决方案是利用dcTrack 本身具有的自定义字段功能。我们不是使用独立的数据库来捕获大量这些期望值，而是在 dcTrack 中捕获期望值和报告值的数据。然后，我们使用那些所需的值作为我们的配置和编排工具的集成点。”

Lincoln 随后解释了 Workday 的供应工作流程。

“dcTrack 在提供有关事物的现状和我们希望它们成为的样子的信息方面发挥着关键作用。我们使用 DCIM 查找来根据其属性确定哪些机架和主机已准备好构建。我们将有关“给定设备在其生命周期中移动时的状态。然后，服务团队可以依靠 DCIM 来显示哪些机架已准备好使用。”

“SNAP 是我们内部开发的 API 驱动的计算供应系统，”Lincoln 继续说道。“它与 dcTrack 和所有其他工具紧密集成，以构建、更新和管理我们的车队。有一个我们称之为‘DCIM to Chef ’的过程，它采用[自定义字段值]和其他与 Chef 相关的值，并动态更新节点数据在参考 Chef 服务器中。这允许具有适当访问权限的工程师近乎实时地更改给定计算节点的配置和功能。

Workday 的网络自动化团队还有一个集成，可以扫描他们的网络设备群，并向 DCIM 报告有关它们的相关信息。他们还在开发一种自动验证工具，该工具将在新安装的架顶式交换机上运行一系列测试，并在 DCIM 中填充一个字段，告诉 SNAP 相关机架已准备好进行配置。

“这……将使我们的供应过程从机柜安装、布线和供电的那一刻起实现零接触，”林肯说。“所有这一切都取决于了解您的资产状态、它们的去向、它们目前的样子以及它们的去向。利用自定义字段让我们构建一个框架来跟踪所有这些。”

2.VM数据管理。

Workday 有一个重要的虚拟机安装来运行他们的部分服务，他们想要跟踪有关构成这些集群的节点的数据。但是，由于 Workday 提供的服务类型，他们需要应用最严格的要求来保护客户的数据，他们发现一些现成的方法对他们不起作用。

他们的解决方案是翻转数据流动的方向。

“dcTrack 为您提供了多种方式来完成任务，而我们的堆栈对此进行了补充，”Lincoln 说。“我们使用我们的 API 客户端直接将数据推送到 dcTrack。满足内部要求。问题已解决。”

“在 DCIM 中跟踪虚拟机，”Haber 说。“我们的要求还包括过滤其中一些虚拟机，并在检测到后自动在 DCIM 中创建条目，不仅填充虚拟机数据，还填充与该组虚拟机相关的某些属性。”

Workday 通过 VMware 的电报应用程序在他们的各个数据中心实施虚拟机跟踪，该应用程序从关联的 VCenter 收集数据，将数据打包在 CSV 文件中，并将其推送到他们的中央 Jenkins。在那里，他们有一个自动化作业来处理 CSV 文件并在他们的 DCIM 中创建或更新信息。

“一切都是自动完成的，”哈伯说。

3.设备状态跟踪。

在另一个用例中，Workday 希望毫不费力地使他们的设备数据保持最新。

“随着所有这些自动化为我们的车队增加和改变提供动力，我们如何保持我们资产的当前状态是最新的？” 林肯说。“现在应该是一个共同的主题，我们将其自动化。”

Workday 的设备每小时运行几次 Chef，并缓存系统信息。当它发生变化时，他们将该信息传递给Splunk，以便直接检索到 dcTrack。

“服务器本身具有我们所说的 Splunk 转发功能，”Haber 说。“我们拥有的是一个预定的搜索，它从所有服务器收集所有数据并将其放入 CSV 文件并将其推送到我们的 Jenkins。在 Jenkins 上，我们有一个处理信息并填充或更新所有条目的工作在 DCIM 中是否有任何变化。”

4.零件管理。

Workday 使用 Sunbird 的部件管理功能为其数据中心运营团队扩展 dcTrack 的功能。

“我们很高兴能将 Sunbird 的零件管理模块添加到我们的环境中，但我们有点紧张，”Lincoln 说。“如果您正在跟踪数以万计的资产，突然间您需要跟踪每项资产的十个部分——这是一个相当保守的数量——您的环境就会变得更大。突然之间，将会有很多亟待解决的问题您的 DC 运营团队需要以下问题的答案：我们重新订购的东西是否正确？我们重新订购的东西数量是否正确？也许最重要的是，我们还能从此类信息中学到什么？”

Workday 的解决方案是报告零件使用情况并发出警报，以自动提供这三个问题及更多问题的答案。他们提供每个位置消耗的零件的每日报告，如果消耗的零件数量超过特定阈值则发出警报，如果特定零件消耗过多则发出警报，为过时零件创建折旧报告等等。他们从这些数据中收集的一些见解包括不同部件的可靠性以及不同供应商的响应速度。

5. 外部集成。

一旦组织的其他成员意识到 Workday 团队的努力和成果，他们就会面临新的挑战。

“这是你希望自己遇到的问题之一，”林肯说。“几年后，DCIM 在 Workday 成为一项成熟的服务，包含企业使用的大量信息。我们有一位业务分析师最近看到了我们所有的数据，并将 DCIM 称为我们组织资产数据的‘中心’。它是一个很棒的地方，但这确实意味着那里的每个人都想交流，而你无法帮助每个人，那么你如何做出这些选择呢？”

Workday 认为最好的解决方案是开放他们的 API 并将其与丰富的文档和示例一起分享给感兴趣的各方。然后，他们只需要让开。

他们实施了许多功能，使他们更愿意将这种自由交给他们的合作伙伴。他们有 API 驱动的入职和配置，这样人们就可以访问他们的公共 API 层、基于角色的精细访问控制，以及对客户每小时和每天可以发出的 API 请求数量的速率限制。他们还执行审计日志监控以检查特定字段更改和并发更改的数量。

“我们也有子生产环境，”林肯说。我们总是想确保我们在非生产环境中进行测试，但是拥有这些的额外好处是您也可以向您的客户开放这些环境，以便他们在测试激进的查询或类似的东西时这样，他们就不必在生产中第一次尝试了。”

“当然，我们永远不想使用它，但我们从一开始就知道我们想要一个强大的故障转移和灾难恢复程序，”林肯说。“我们有很多文档和内置系统，以确保如果我们在生产中确实遇到问题，我们可以从中恢复。我们有一种生成系统备份的常规方法。我们使用随附的方法“使用 dcTrack，然后我们有一种方法可以将其复制到单独的系统。最近，我们还部署了 dcTrack 的高可用性功能，因此我们拥有了它以及一个额外的保护层。”