更高難度：雲時代下的CMDB

前言

最近在社區屢次看到CMDB的分享，大可能是在探討CMDB如何建設（How）的問題，雖然如何建設的問題很是重要，但在當今人人談雲的雲化時代下，究竟該創建一個什麼樣（What）的CMDB更爲重要。

首先要說明的是，今天在這裏的分享都創建在傳統企業存量環境中，暫時不考慮互聯網企業。這種假設的考慮主要基於兩個方面：

1. 本人相對於傳統行業更爲熟悉

2. 傳統企業的運維理念和組織架構設定和互聯網不一樣，進而致使了運維工具架構、選擇、以及IT標準化策略等方面的不一樣

CMDB發展史

我先簡要回顧一下十幾年來CMDB的建設歷程。

2004年

我從04年開始參與國內某銀行的CMDB建設，這時CMDB的典型場景是資產信息的電子化。配置信息的採集主要採用Excel導入的方式，CMDB模型須要提早預設，不具有動態擴展能力，暫且稱之爲CMDB1.0。

2006年

到了06年，我在某銀行主導實施了國內第一個基於BMC Atrium CMDB架構的CMDB項目，這時的CMDB開始側重於與其餘ITSM (IT Service Management，IT服務管理 )流程的協同以及故障、變動影響分析等診斷場景。

但因爲配置數據的初始化工做仍然須要手工Excel導入，同時配置信息的更新也不及時（沒法在一個變動窗口內更新完成），致使上層場景沒有發揮做用。這個階段咱們稱之爲CMDB2.0。

2007年

從07年開始，配置自動化發現工具的引入，幫助企業極大簡化了配置數據初始化工做。

2008年

緊接着，08年左右業界提出變動閉環的概念，即在變動結束後從新進行配置自動發現並更新配置信息。相比CMDB2.0階段，配置信息更新實時性有必定程度提升。

2012年

12年一些銀行開始嘗試經過配置自動發現工具實現配置比對場景，尤爲是災備與生產環境配置比對，以及集羣環境內任意兩節點間的配置比對。

近幾年

應 該說，配置自動發現工具必定程度上下降了配置數據初始化和維護的難度，但限於配置自動發現工具的技術侷限，發現時間每每較長，發現的信息也存在必定盲區， 同時還需使用root等管理員帳號，這些約束必定程度上影響了自動發現工具的實際使用效果。這個階段咱們稱之爲CMDB3.0。

雲化CMDB時代

隨着雲計算在10年國內的興起，大約在12年後逐步在大型企業內部落地。落地過程當中，咱們發現雲化資源的管理是一件比CMDB管理更爲棘手的事情。

爲此咱們幫助國內一些銀行實施了雲化資源管理平臺，除了管理以往CMDB中常見的物理配置外，進一步豐富了LPAR、端口、HBA卡、LV、VG等邏輯配置。這個階段我暫且稱之爲雲化CMDB1.0。

從CMDB在國內發展的歷程看，隨着客戶對於CMDB認知不斷深化，CMDB的場景已經從傳統的資產臺帳管理逐步演化到流程協同管理、影響分析、配置比對、雲化資源管理等方面，但在CMDB的技術架構上，不管是開源產品仍是商業化產品都沒有一個明顯的改進，發展比較緩慢。這在必定程度上也影響了CMDB場景的拓展。

爲了便於你們有更爲直觀的認識，我整理了下表羅列了不一樣階段CMDB的特色

須要說明的是，雲化CMDB2.0是我現階段設定的一個目標，將來也但願經過開源的方式實現的一個項目。

CMDB建設常見問題

回顧十幾年的CMDB建設，你們廣泛的反映是CMDB建設很困難，下面我有必要分析一下當前CMDB建設遇到的一些常見問題。

1. 缺少合理化、總體化的規劃

需求不清晰，定義了不合理的配置廣度和深度。

• 在大而全? 仍是小而深? 方面猶豫不決：
  這種決策機制在項目初期每每耗費了大量時間，但隨着新技術的不斷涌現，這種方式已經沒法適應愈來愈敏捷的IT環境，咱們發現一種相對靜態的CMDB模型已經不能知足納管新IT組件的要求。

  如何解決？

  用一種更爲靈活的CMDB模型擴展機制。

• 採用了不正確的管控策略：
  按照經典ITIL的管控和項目實施機制，配置管理規劃，尤爲是CMDB模型的規劃每每由項目組承擔，一旦規劃完成後整個模型也就變得很難再進行擴展，應該說這裏採用的是一種集中管控的策略。

  但在實際IT運維工做中，咱們發現對於CMDB使用最多的是各個二線團隊，不一樣團隊之間對於CMDB 深度和廣度的要求，以及管控方式都有較大差異。

  如何解決？

  基於集中分佈式的理念創建CMDB管控體系

2. 配置管理人員職責定義不清晰

• 配置經理、配置管理員、配置Owner之間職責不清晰：

  按照ITIL或ISO20000中對於這三類角色的定義每每過於寬泛，沒有進一步考慮實際運維人員的運維場景，以及使用的運維工具，致使職責定義和實際作事方式脫節。

  如何解決？

  結合運維場景、運維工具、流程角色職責，對於各角色的職責進行重定義。

• 角色職責和崗位的對應不明晰：

  在沒有ITIL之前，在企業IT部門或數據中心每每找到不到一個現成崗位對於IT配置信息進行集中管理，而是每一個人各管一攤。

  實施ITIL後，究竟由哪一個部門的哪一個崗位承擔配置經理這一職責每每是最讓人傷腦筋的，最後每每是趕鴨子上架。這種角色定義方式最終致使體系沒法運轉。

  如何解決？

  基於集中分佈式的理念設定角色和崗位的對應關係

3. 配置管理成了IT運維的負擔

這實際上是CMDB在企業落地所面臨的最大挑戰，沒法充分調動運維人員的積極性，主要體如今：

• 初始數據收集工做量大：
  存量的配置數據每每基數很大，通常配置的量級在5000以上，考慮到雲化環境的海量運維場景，這個基數還會更大。

  隨着分佈式應用架構以及微服務架構的興起，將來一套新應用系統上線引入新的配置項數量也沒法簡單經過手工輸入的方式來完成。

  如何解決？

  藉助自動化手段進行數據採集

• 單一的自動化配置發現工具只是一種幻想：
  如前所說，約從2007年開始，業內引入了自動發現工具用以解決配置數據的初始化問題，但因爲這類工具每每由某個廠商提供，致使了配置發現的侷限性，企業每每也要付出較大成本。

  如何解決？

  創建適配多類自動化工具的CMDB架構，將企業現有的腳本、監控工具、自動化工具、雲平臺都轉化爲配置數據的提供方。

• 投產後因爲變動頻繁，數據沒法保證及時準確：
  以往企業通常採用變動操做驅動配置修改（人工修改、或自動化發現修改）的方式以確保配置數據的準確性，這種方式每每出現了配置信息的不一致。

  如何解決？

  創建基於配置基線驅動的IT環境變動（操做）架構，即創建經過配置修改事件觸發變動操做的事件響應模型。
  對於將來軟件定義環境，這種架構是一種必然選擇。

• 如何讓人人「樂於」參與：
  這裏的參與主要體如今二個方面：
  1）須要使用與本身相關的配置數據時，CMDB能夠當即提供；
  2）遇到CMDB沒法提供的數據時，IT部門可自行在必定標準和約束下擴展知足本部門運維CMDB模型，支撐部門級的運維場景。

  如何解決？

  創建小、快、靈的CMDB架構，支撐快速擴展、快速納管、快速交付數據。

4. 配置數據的價值沒法呈現

• 缺少清晰的場景定義，包括流程價值、監控價值、BSM價值、雲價值等：
  單一流程驅動CMDB的場景，沒法讓CMDB中的數據流動起來，隨着時間的推移CMDB中的數據就逐漸腐敗—不及時也不許確。

  同時，CMDB在技術上做爲一個「數據庫」，要讓其中的數據可以流動起來，必須明確與之匹配的運維場景。

  場景是用來描述與CMDB中某些配置項交互的一組活動，知足IT部門某一方面的運維管理目標，這一目標能夠被度量、跟蹤、改進、可視化，與此同時，CMDB的價值也隨之呈現。

  如何解決？

  創建基於場景驅動的CMDB解決方案集合;

• 缺少有效、明確的配置數據集成策略：
  如前所述，CMDB是一個邏輯上的數據庫，其中的數據須要和企業現有IT環境中的多類數據源進行整合，一套行之有效的數據集成策略和ETL（數據抽取、轉換、轉載）工具也必不可少。

  如何解決？

  創建數據集成策略，引入ETL。

經過以上分析，咱們回顧了CMDB的歷史發展過程，以及建設過程當中遇到的挑戰。接下來咱們看看雲化環境下CMDB又將面臨什麼新問題。

雲化時代的特色以及帶來的挑戰

應該說動態變化是雲化環境下最大的挑戰，不管對於配置模型仍是配置數據的更新都提出了全新要求。咱們勢必不能再參考現有CMDB產品架構去定義或知足雲化CMDB的要求。

對於互聯網或互聯網業務而言，海量會是一個比較大的問題，這裏的關鍵可能不是海量存儲的問題，而是如何在海量配置信息中快速配置定位、查找和可視化。

對於傳統企業而言，異構永遠是首要解決的問題，針對這個特色，以往廠商提出過聯邦的技術，但一直沒有找到可行的落地方法。這裏我嘗試藉助相似於ETL的機制，實現多數據源的整合。

雲化CMDB應具有的典型特徵和範式

下面咱們進入今天討論的第三部分：雲化CMDB應具有的典型特徵和範式

在雲化時代，CMDB須要從原有的單一工具轉變爲一種企業IT服務能力，即CMDB As A Service（如下爲了便於敘述，使用雲化CMDB代替）。

雲化CMDB：是指 CMDB消費者能夠經過網絡隨時隨地獲取、維護、管理CMDB。

服務要素

如IaaS中服務要素是指IT基礎架構，在雲化中的服務要素包括三個層面：

1. 配置模型：用以描述CMDB的深度和廣度，在技術上體現爲一組配置標籤（如服務器、網絡、應用等，或生產環境、測試環境等）、與配置標籤相關聯的配置對象、以及用於描述配置對象的屬性集合。

   配置模型是用以描述配置項的元數據，其描述了某一配置項應該具有的屬性，以及該配置項與其餘配置項之間的邏輯關係，以及與配置項相關的一組操做。

2. 配置項：用以描述某一配置對象的具體實例。如對於Server這個配置對象，其具體的IT環境中可能表現爲IBM Server01，IBM Server02，IBM Server03等服務器實例。

3. 配置項的關聯操做：這個層面是對ITIL的補充。操做用來描述某個配置項在實際特定的IT環境中容許進行的一組行爲集合。

   舉例來講，對於IBM Server01配置項來講，可能有的操做包括啓動、中止；對於比較複雜的應用系統APP 01來講，可能有的操做就包括啓動、中止、重啓、配置等。

   若是說配置項屬性是對配置項的靜態描述，那麼配置項操做就是對配置項的動態描述，其描述了消費者能夠對當前配置項施加的動做。

上述服務要素並不能單獨存在，這就像數據庫管理系統中的數據同樣，在沒有被業務系統使用前，都只是一堆0和1組成的數據，必須放到某個特定的上下文中才具有其特定的含義。

這裏說的業務系統其實說的就是場景。配置場景描述CMDB與某個具體運維活動或業務活動之間的關係，在一個場景中可能同時觸發一組關聯操做。

在沒有JDBC或ODBC標準接口前，存放在數據庫管理系統中的數據只能經過特定的數據庫管理平臺才能進行增、刪、查、改操做，這種方式嚴重製約了數據庫中的數據對外提供服務和消費，給業務系統的開發帶來了極大的不便利性。

同理，在CMDB As A Service理念中，咱們也須要經過把服務要素API化，將CMDB的服務能力真正暴露出去，以便於場景進行調用。

CMDB API與服務要素一一對應，包括三個層次：

1. 配置模型的增、刪、查、改（相似於DML）；

2. 配置數據的增、刪、查、改；配置項關係創建、移除（相似於DDL）；

3. 配置操做的增、刪、查、改；並創建配置操做與特定的IT運維自動化工具的關聯（包括腳本、專業自動化運維工具、雲平臺、監控平臺等等）；

注：其實Puppet、Chef在架構上已經採起了相似的理念，這裏咱們但願再往上抽象一個層次

經過上述要素的組合，我給出雲化CMDB的定義：

雲化CMDB=模型 + 操做 + 數據 + API + 場景

雲化CMDB的基本架構

下面咱們進入今天分享的最後一部份內容：雲化CMDB的基本架構。

整個雲化CMDB平臺自下而上分爲四個層次，分別是：

1. 系統管理層：該層爲系統的使用提供了最基本的支持，包括組織、人員、角色、權限的管理。支持定義各種角色和權限的管理，有完整的角色管理和權限管理功能，權限配置支持組嵌套。並經過與外部IT管理雲平臺集成實現用戶的統一認證功能

2. CMDB服務要素層：按照雲化CMDB的理念，服務要素包括模型、數據和操做，與之對應的分別是模型維護、配置項維護和操做維護功能。

3. API層：經過封裝底層CMDB服務要素層的功能要素，對外提供模型管理API、配置項管理API和操做API

4. 場景層：場景層採用了一種可擴展的方式進行設計，CMDB ETL和配置可視化是CMDB的兩個基本場景：

   場景一：其中CMDB ETL主要實現對於多外部配置數據源的數據抽取、轉化和處理，並將處理的結果經過API層的配置項API進行數據錄入，並記錄配置數據的變化，創建配置基線，並圍繞基線造成基線比對等功能；

   場景二：配置可視化主要針對配置數據提供一種展現（圖形、聲音、文字等）手段，包括配置拓撲展示（以圖形化方式展示配置項間的關聯關係）、配置項多維度查詢、配置報表以及預警功能。

   除了基本場景外，開發人員能夠經過API層的功能，並結合基本場景實現自定義場景，好比在本次項目中實現架構標準配置比對功能就是一種基於配置比對功能基礎上的新場景應用。

除了以上層次，平臺提供了CMDB管理門戶的GUI界面，便於系統管理員和配置管理相關用戶對於模型、配置項進行維護、查詢。

目前已經參考上述架構啓動開源雲化CMDB項目，並實現了模型動態擴展，模型/配置數據API、配置基線、配置比對、ETL和可視化場景，預計7月份開源第一個版本。

今天就分享這些內容，請你們多多指教！謝謝你們！還有一些具體細節，今天因爲時間的緣由就不展開了，歡迎具體探討。

精彩互動

Q1：雲平臺下運維與傳統運維的最大差別包括哪一個方面？從而致使運維平臺進入一個新的發展時期。

A：雲化環境下最大的挑戰是配置信息的動態變化，以往在配置手工更新每每須要幾個小時甚至幾天時間，等更新後其實CMDB中已是髒數據了。

Q2：海量配置對比的實現原理和準確性程度如何？

A：基本思路是將數據庫記錄級比對（傳統CMDB技術實現）轉變爲文本級比對。比對過程當中能夠識別新增、修改、刪除屬性、配置項等信息。

Q3：若是已經有一個偏資產管理流程數據的cmdb了，那麼想用這個雲化cmdb思路落地是否是隻能重構了？

A：是。

Q4：配置主動發現這個最重要。怎麼去區分邏輯屬性，物理屬性，動態屬性，靜態屬性，關聯配置項目，怎麼與資產關聯？

A：應該說配置主動發現採用的是一種輪詢查找機制，我但願在新的雲化CMDB中採用的思路是配置事件驅動的模式進行配置更新。

好比在IaaS中，咱們要申請一臺VM，在申請的過程當中已經收集了VM相關信息，以及安裝的數據庫、中間件實例等配置信息，從這個例子中咱們發現變動-配置更新是一體的，也就不須要配置自動發現工具。

固然在實際環境中，咱們要二者結合。配置自動發現工具也不侷限於特定的如ADDM、TADDM這類工具，能夠擴展到監控、腳本等工具。

Q5：cmdb etl如何解釋？我知道etl但和cmdb一塊兒徹底沒有概念，請解釋，謝謝！

A： CMDB從本質來講就是一個數據庫，咱們要解決的是如何容許多個外部數據源同時錄入配置數據，那麼數據源之間會出現衝突，這就須要一個合理的技術去解決。

ETL其實在數倉裏應用多年，咱們徹底能夠借鑑過來加以利用。這個方案在三個大行已經獲得了應用。當時咱們用的是Kettl。

Q6:怎麼區分模型仍是場景？

A：模型其實簡單說就是數據庫的表結構，場景其實就是使用數據庫的應用程序。

Q7:我以爲cmdb到後面就是個aws的json格式的api接口，異曲同工，不曉得老師怎麼看？

A：這個問題比較有意思，從接口的發展趨勢看，相似於RestFul的API目前已是事實標準，在雲化CMDB中全部API也將經過這種方式提供。

Q8：例如無論是阿里雲仍是aws，全部的運維活動都是圍繞資源自然集成，彷佛已經失去了傳統環境下配置驅動流程的意義了？

A：這個是個好問題。一個很是有意思的是不管是AWS、仍是Openstack都沒有集中存放配置的管理組件。

前不久，AWS發佈了AWSConfig，這個組件其實就是負責AWS上全部配置信息的集中管理，並已經和20多個軟件廠商實現了整合，同時咱們Netflix上也看到了相似的項目。

因此，答案已經比較明顯了，配置管理的這類需求還很廣泛。

Q9：在雲環境下，資源都是服務，運維服務和資源服務自然的聯動集成，我我的感受雲環境下cmdb的功能更可能是一個ci全景的可視查詢，還有其餘場景嗎？

A：可視查詢是從配置消費角度看到的一個典型場景，從配置提供的角度看，因爲雲化環境涉及了計算、網絡、存儲虛擬化，以及大量自動化運維工具，所以比較複雜的是配置數據提供場景。例如，如何在一個VM的交付過程當中，實時的更新配置信息。

Q10：cmdb在建設初期怎麼發揮價值？或者說，如何在運維工做中發揮更大做用，而不僅是一個電子臺賬？

A：

1. 創建場景驅動理念，確保配置數據有人去使用；

2. 經過技術手段提高配置數據的自動化率，確保CI項中的屬性絕大多數都能被某種自動化工具覆蓋。

Q11：請問下CMDB裏的數據準確性是怎麼保證的？

A：非雲化環境，通常經過過後審計的方式，識別有問題的配置項，而後進行手工修正。

雲化環境，因爲環境都是軟件定義的，基礎架構的變動和配置更新是同時發生的，理論上來講CMDB中的數據是雲化環境的快照。今天分享的內容主要側重在雲化環境。

Q12:邏輯關聯信息，能夠定義嗎？如何進行關聯關係的維護？

A：這個問題涉及模型定義問題。若是你有Puppet和Chef的經驗，咱們就能夠看到這種關係的定義。關係是一種特殊的CI屬性，在設計時，必須確保能夠經過自動化工具提供數據。


在實際項目中，咱們會造成上面的兩個表格。

Q13：如何將cmdb1.0和2.0合併在一塊兒實現？自動發現配置方面有沒有成型的解決方案？

A：上面只是處於表述的緣由，將CMDB分爲1.0和2.0，從實現角度看是能夠同時考慮的。自動發現配置方面常見的商業方案有BMC ADDM和IBM TADDM，開源的暫時沒有找到相似的解決方案，通常功能都比較散。

Q14:老師,你好.能講講大家Apache kylin主要拿來作什麼嗎？

A：可參考http://www.oschina.net/p/kylin-olap