數據中心自動化是在沒有任何人工操作的情況下完成數據中心操作的常規過程的過程。它提高了運營效率，提高了數據準確性，并簡化了數據中心管理。

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 的高可用性功能，因此我們擁有了它以及一個額外的保護層。”