更高難度：云時代下的CMDB

huxh1101 2016-04-11

展開全文

本文根據(jù)〖高效運維社區(qū)講壇〗線上活動的分享整理而成。
歡迎關(guān)注“高效運維(微信ID：greatops)”公眾號，以搶先賞閱干貨滿滿的各種原創(chuàng)文章。

嘉賓介紹

前言

最近在社區(qū)多次看到CMDB的分享，大多是在探討CMDB如何建設(shè)（How）的問題，雖然如何建設(shè)的問題非常重要，但在當今人人談云的云化時代下，究竟該建立一個什么樣（What）的CMDB更為重要。

首先要說明的是，今天在這里的分享都建立在傳統(tǒng)企業(yè)存量環(huán)境中，暫時不考慮互聯(lián)網(wǎng)企業(yè)。這種假設(shè)的考慮主要基于兩個方面：

本人相對于傳統(tǒng)行業(yè)更為熟悉
傳統(tǒng)企業(yè)的運維理念和組織架構(gòu)設(shè)定和互聯(lián)網(wǎng)不同，進而導(dǎo)致了運維工具架構(gòu)、選擇、以及IT標準化策略等方面的不同

CMDB發(fā)展史

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

2004年

我從04年開始參與國內(nèi)某銀行的CMDB建設(shè)，這時CMDB的典型場景是資產(chǎn)信息的電子化。配置信息的采集主要采用Excel導(dǎo)入的方式，CMDB模型需要提前預(yù)設(shè)，不具備動態(tài)擴展能力，暫且稱之為CMDB1.0。

2006年

到了06年，我在某銀行主導(dǎo)實施了國內(nèi)第一個基于BMC Atrium CMDB架構(gòu)的CMDB項目，這時的CMDB開始側(cè)重于與其他ITSM (IT Service Management，IT服務(wù)管理 )流程的協(xié)同以及故障、變更影響分析等診斷場景。

但由于配置數(shù)據(jù)的初始化工作仍然需要手工Excel導(dǎo)入，同時配置信息的更新也不及時（無法在一個變更窗口內(nèi)更新完成），導(dǎo)致上層場景沒有發(fā)揮作用。這個階段我們稱之為CMDB2.0。

2007年

從07年開始，配置自動化發(fā)現(xiàn)工具的引入，幫助企業(yè)極大簡化了配置數(shù)據(jù)初始化工作。

2008年

緊接著，08年左右業(yè)界提出變更閉環(huán)的概念，即在變更結(jié)束后重新進行配置自動發(fā)現(xiàn)并更新配置信息。相比CMDB2.0階段，配置信息更新實時性有一定程度提高。

2012年

12年一些銀行開始嘗試通過配置自動發(fā)現(xiàn)工具實現(xiàn)配置比對場景，尤其是災(zāi)備與生產(chǎn)環(huán)境配置比對，以及集群環(huán)境內(nèi)任意兩節(jié)點間的配置比對。

近幾年

應(yīng)該說，配置自動發(fā)現(xiàn)工具一定程度上降低了配置數(shù)據(jù)初始化和維護的難度，但限于配置自動發(fā)現(xiàn)工具的技術(shù)局限，發(fā)現(xiàn)時間往往較長，發(fā)現(xiàn)的信息也存在一定盲區(qū)，同時還需使用root等管理員賬號，這些約束一定程度上影響了自動發(fā)現(xiàn)工具的實際使用效果。這個階段我們稱之為CMDB3.0。

云化CMDB時代

隨著云計算在10年國內(nèi)的興起，大約在12年后逐步在大型企業(yè)內(nèi)部落地。落地過程中，我們發(fā)現(xiàn)云化資源的管理是一件比CMDB管理更為棘手的事情。

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

從CMDB在國內(nèi)發(fā)展的歷程看，隨著客戶對于CMDB認知不斷深化，CMDB的場景已經(jīng)從傳統(tǒng)的資產(chǎn)臺賬管理逐步演化到流程協(xié)同管理、影響分析、配置比對、云化資源管理等方面，但在CMDB的技術(shù)架構(gòu)上，無論是開源產(chǎn)品還是商業(yè)化產(chǎn)品都沒有一個明顯的改進，發(fā)展比較緩慢。這在一定程度上也影響了CMDB場景的拓展。

為了便于大家有更為直觀的認識，我整理了下表羅列了不同階段CMDB的特點

需要說明的是，云化CMDB2.0是我現(xiàn)階段設(shè)定的一個目標，未來也希望通過開源的方式實現(xiàn)的一個項目。

CMDB建設(shè)常見問題

回顧十幾年的CMDB建設(shè)，大家普遍的反映是CMDB建設(shè)很困難，下面我有必要分析一下當前CMDB建設(shè)遇到的一些常見問題。

1. 缺乏合理化、整體化的規(guī)劃

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

在大而全? 還是小而深? 方面猶豫不決：
這種決策機制在項目初期往往耗費了大量時間，但隨著新技術(shù)的不斷涌現(xiàn)，這種方式已經(jīng)無法適應(yīng)越來越敏捷的IT環(huán)境，我們發(fā)現(xiàn)一種相對靜態(tài)的CMDB模型已經(jīng)不能滿足納管新IT組件的要求。
如何解決？
用一種更為靈活的CMDB模型擴展機制。
采用了不正確的管控策略：
按照經(jīng)典ITIL的管控和項目實施機制，配置管理規(guī)劃，尤其是CMDB模型的規(guī)劃往往由項目組承擔，一旦規(guī)劃完成后整個模型也就變得很難再進行擴展，應(yīng)該說這里采用的是一種集中管控的策略。
但在實際IT運維工作中，我們發(fā)現(xiàn)對于CMDB使用最多的是各個二線團隊，不同團隊之間對于CMDB 深度和廣度的要求，以及管控方式都有較大差別。
如何解決？
基于集中分布式的理念建立CMDB管控體系

2. 配置管理人員職責(zé)定義不清晰

配置經(jīng)理、配置管理員、配置Owner之間職責(zé)不清晰：
按照ITIL或ISO20000中對于這三類角色的定義往往過于寬泛，沒有進一步考慮實際運維人員的運維場景，以及使用的運維工具，導(dǎo)致職責(zé)定義和實際做事方式脫節(jié)。
如何解決？
結(jié)合運維場景、運維工具、流程角色職責(zé)，對于各角色的職責(zé)進行重定義。
角色職責(zé)和崗位的對應(yīng)不明晰：
在沒有ITIL以前，在企業(yè)IT部門或數(shù)據(jù)中心往往找到不到一個現(xiàn)成崗位對于IT配置信息進行集中管理，而是每個人各管一攤。
實施ITIL后，究竟由哪個部門的哪個崗位承擔配置經(jīng)理這一職責(zé)往往是最讓人傷腦筋的，最后往往是趕鴨子上架。這種角色定義方式最終導(dǎo)致體系無法運轉(zhuǎn)。
如何解決？
基于集中分布式的理念設(shè)定角色和崗位的對應(yīng)關(guān)系

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

這其實是CMDB在企業(yè)落地所面臨的最大挑戰(zhàn)，無法充分調(diào)動運維人員的積極性，主要體現(xiàn)在：

初始數(shù)據(jù)收集工作量大：
存量的配置數(shù)據(jù)往往基數(shù)很大，一般配置的量級在5000以上，考慮到云化環(huán)境的海量運維場景，這個基數(shù)還會更大。
隨著分布式應(yīng)用架構(gòu)以及微服務(wù)架構(gòu)的興起，未來一套新應(yīng)用系統(tǒng)上線引入新的配置項數(shù)量也無法簡單通過手工輸入的方式來完成。
如何解決？
借助自動化手段進行數(shù)據(jù)采集
單一的自動化配置發(fā)現(xiàn)工具只是一種幻想：
如前所說，約從2007年開始，業(yè)內(nèi)引入了自動發(fā)現(xiàn)工具用以解決配置數(shù)據(jù)的初始化問題，但由于這類工具往往由某個廠商提供，導(dǎo)致了配置發(fā)現(xiàn)的局限性，企業(yè)往往也要付出較大成本。
如何解決？
建立適配多類自動化工具的CMDB架構(gòu)，將企業(yè)現(xiàn)有的腳本、監(jiān)控工具、自動化工具、云平臺都轉(zhuǎn)化為配置數(shù)據(jù)的提供方。
投產(chǎn)后由于變更頻繁，數(shù)據(jù)無法保證及時準確：
以往企業(yè)一般采用變更操作驅(qū)動配置修改（人工修改、或自動化發(fā)現(xiàn)修改）的方式以確保配置數(shù)據(jù)的準確性，這種方式往往出現(xiàn)了配置信息的不一致。
如何解決？
建立基于配置基線驅(qū)動的IT環(huán)境變更（操作）架構(gòu)，即建立通過配置修改事件觸發(fā)變更操作的事件響應(yīng)模型。
對于未來軟件定義環(huán)境，這種架構(gòu)是一種必然選擇。
如何讓人人“樂于”參與：
這里的參與主要體現(xiàn)在二個方面：
1）需要使用與自己相關(guān)的配置數(shù)據(jù)時，CMDB可以立即提供；
2）遇到CMDB無法提供的數(shù)據(jù)時，IT部門可自行在一定標準和約束下擴展?jié)M足本部門運維CMDB模型，支撐部門級的運維場景。
如何解決？
建立小、快、靈的CMDB架構(gòu)，支撐快速擴展、快速納管、快速交付數(shù)據(jù)。

4. 配置數(shù)據(jù)的價值無法呈現(xiàn)

缺乏清晰的場景定義，包括流程價值、監(jiān)控價值、BSM價值、云價值等：
單一流程驅(qū)動CMDB的場景，無法讓CMDB中的數(shù)據(jù)流動起來，隨著時間的推移CMDB中的數(shù)據(jù)就逐漸腐敗—不及時也不準確。
同時，CMDB在技術(shù)上作為一個“數(shù)據(jù)庫”，要讓其中的數(shù)據(jù)能夠流動起來，必須明確與之匹配的運維場景。
場景是用來描述與CMDB中某些配置項交互的一組活動，滿足IT部門某一方面的運維管理目標，這一目標可以被度量、跟蹤、改進、可視化，與此同時，CMDB的價值也隨之呈現(xiàn)。
如何解決？
建立基于場景驅(qū)動的CMDB解決方案集合;
缺乏有效、明確的配置數(shù)據(jù)集成策略：
如前所述，CMDB是一個邏輯上的數(shù)據(jù)庫，其中的數(shù)據(jù)需要和企業(yè)現(xiàn)有IT環(huán)境中的多類數(shù)據(jù)源進行整合，一套行之有效的數(shù)據(jù)集成策略和ETL（數(shù)據(jù)抽取、轉(zhuǎn)換、轉(zhuǎn)載）工具也必不可少。
如何解決？
建立數(shù)據(jù)集成策略，引入ETL。

通過以上分析，我們回顧了CMDB的歷史發(fā)展過程，以及建設(shè)過程中遇到的挑戰(zhàn)。接下來我們看看云化環(huán)境下CMDB又將面臨什么新問題。

云化時代的特點以及帶來的挑戰(zhàn)

應(yīng)該說動態(tài)變化是云化環(huán)境下最大的挑戰(zhàn)，無論對于配置模型還是配置數(shù)據(jù)的更新都提出了全新要求。我們勢必不能再參考現(xiàn)有CMDB產(chǎn)品架構(gòu)去定義或滿足云化CMDB的要求。

對于互聯(lián)網(wǎng)或互聯(lián)網(wǎng)業(yè)務(wù)而言，海量會是一個比較大的問題，這里的關(guān)鍵可能不是海量存儲的問題，而是如何在海量配置信息中快速配置定位、查找和可視化。

對于傳統(tǒng)企業(yè)而言，異構(gòu)永遠是首要解決的問題，針對這個特點，以往廠商提出過聯(lián)邦的技術(shù)，但一直沒有找到可行的落地方法。這里我嘗試借助類似于ETL的機制，實現(xiàn)多數(shù)據(jù)源的整合。

云化CMDB應(yīng)具備的典型特征和范式

下面我們進入今天討論的第三部分：云化CMDB應(yīng)具備的典型特征和范式

在云化時代，CMDB需要從原有的單一工具轉(zhuǎn)變?yōu)橐环N企業(yè)IT服務(wù)能力，即CMDB As A Service（以下為了便于敘述，使用云化CMDB代替）。

云化CMDB：是指 CMDB消費者可以通過網(wǎng)絡(luò)隨時隨地獲取、維護、管理CMDB。

服務(wù)要素

如IaaS中服務(wù)要素是指IT基礎(chǔ)架構(gòu)，在云化中的服務(wù)要素包括三個層面：

配置模型：用以描述CMDB的深度和廣度，在技術(shù)上體現(xiàn)為一組配置標簽（如服務(wù)器、網(wǎng)絡(luò)、應(yīng)用等，或生產(chǎn)環(huán)境、測試環(huán)境等）、與配置標簽相關(guān)聯(lián)的配置對象、以及用于描述配置對象的屬性集合。
配置模型是用以描述配置項的元數(shù)據(jù)，其描述了某一配置項應(yīng)該具備的屬性，以及該配置項與其他配置項之間的邏輯關(guān)系，以及與配置項相關(guān)的一組操作。
配置項：用以描述某一配置對象的具體實例。如對于Server這個配置對象，其具體的IT環(huán)境中可能表現(xiàn)為IBM Server01，IBM Server02，IBM Server03等服務(wù)器實例。
配置項的關(guān)聯(lián)操作：這個層面是對ITIL的補充。操作用來描述某個配置項在實際特定的IT環(huán)境中允許進行的一組行為集合。
舉例來說，對于IBM Server01配置項來說，可能有的操作包括啟動、停止；對于比較復(fù)雜的應(yīng)用系統(tǒng)APP 01來說，可能有的操作就包括啟動、停止、重啟、配置等。
如果說配置項屬性是對配置項的靜態(tài)描述，那么配置項操作就是對配置項的動態(tài)描述，其描述了消費者可以對當前配置項施加的動作。

上述服務(wù)要素并不能單獨存在，這就像數(shù)據(jù)庫管理系統(tǒng)中的數(shù)據(jù)一樣，在沒有被業(yè)務(wù)系統(tǒng)使用前，都只是一堆0和1組成的數(shù)據(jù)，必須放到某個特定的上下文中才具備其特定的含義。

這里說的業(yè)務(wù)系統(tǒng)其實說的就是場景。配置場景描述CMDB與某個具體運維活動或業(yè)務(wù)活動之間的關(guān)系，在一個場景中可能同時觸發(fā)一組關(guān)聯(lián)操作。

在沒有JDBC或ODBC標準接口前，存放在數(shù)據(jù)庫管理系統(tǒng)中的數(shù)據(jù)只能通過特定的數(shù)據(jù)庫管理平臺才能進行增、刪、查、改操作，這種方式嚴重制約了數(shù)據(jù)庫中的數(shù)據(jù)對外提供服務(wù)和消費，給業(yè)務(wù)系統(tǒng)的開發(fā)帶來了極大的不便利性。

同理，在CMDB As A Service理念中，我們也需要通過把服務(wù)要素API化，將CMDB的服務(wù)能力真正暴露出去，以便于場景進行調(diào)用。

CMDB API與服務(wù)要素一一對應(yīng)，包括三個層次：

配置模型的增、刪、查、改（類似于DML）；
配置數(shù)據(jù)的增、刪、查、改；配置項關(guān)系建立、移除（類似于DDL）；
配置操作的增、刪、查、改；并建立配置操作與特定的IT運維自動化工具的關(guān)聯(lián)（包括腳本、專業(yè)自動化運維工具、云平臺、監(jiān)控平臺等等）；

注：其實Puppet、Chef在架構(gòu)上已經(jīng)采取了類似的理念，這里我們希望再往上抽象一個層次

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

云化CMDB=模型操作數(shù)據(jù) API 場景

云化CMDB的基本架構(gòu)

下面我們進入今天分享的最后一部分內(nèi)容：云化CMDB的基本架構(gòu)。

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

系統(tǒng)管理層：該層為系統(tǒng)的使用提供了最基本的支持，包括組織、人員、角色、權(quán)限的管理。支持定義各類角色和權(quán)限的管理，有完整的角色管理和權(quán)限管理功能，權(quán)限配置支持組嵌套。并通過與外部IT管理云平臺集成實現(xiàn)用戶的統(tǒng)一認證功能
CMDB服務(wù)要素層：按照云化CMDB的理念，服務(wù)要素包括模型、數(shù)據(jù)和操作，與之對應(yīng)的分別是模型維護、配置項維護和操作維護功能。
API層：通過封裝底層CMDB服務(wù)要素層的功能要素，對外提供模型管理API、配置項管理API和操作API
場景層：場景層采用了一種可擴展的方式進行設(shè)計，CMDB ETL和配置可視化是CMDB的兩個基本場景：
場景一：其中CMDB ETL主要實現(xiàn)對于多外部配置數(shù)據(jù)源的數(shù)據(jù)抽取、轉(zhuǎn)化和處理，并將處理的結(jié)果通過API層的配置項API進行數(shù)據(jù)錄入，并記錄配置數(shù)據(jù)的變化，建立配置基線，并圍繞基線形成基線比對等功能；
場景二：配置可視化主要針對配置數(shù)據(jù)提供一種展示（圖形、聲音、文字等）手段，包括配置拓撲展現(xiàn)（以圖形化方式展現(xiàn)配置項間的關(guān)聯(lián)關(guān)系）、配置項多維度查詢、配置報表以及預(yù)警功能。
除了基本場景外，開發(fā)人員可以通過API層的功能，并結(jié)合基本場景實現(xiàn)自定義場景，比如在本次項目中實現(xiàn)架構(gòu)標準配置比對功能就是一種基于配置比對功能基礎(chǔ)上的新場景應(yīng)用。

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

目前已經(jīng)參考上述架構(gòu)啟動開源云化CMDB項目，并實現(xiàn)了模型動態(tài)擴展，模型/配置數(shù)據(jù)API、配置基線、配置比對、ETL和可視化場景，預(yù)計7月份開源第一個版本。

今天就分享這些內(nèi)容，請大家多多指教！謝謝大家！還有一些具體細節(jié)，今天由于時間的原因就不展開了，歡迎具體探討。

精彩互動

Q1：云平臺下運維與傳統(tǒng)運維的最大差異包括哪個方面？從而導(dǎo)致運維平臺進入一個新的發(fā)展時期。

A：云化環(huán)境下最大的挑戰(zhàn)是配置信息的動態(tài)變化，以往在配置手工更新往往需要幾個小時甚至幾天時間，等更新后其實CMDB中已經(jīng)是臟數(shù)據(jù)了。

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

A：基本思路是將數(shù)據(jù)庫記錄級比對（傳統(tǒng)CMDB技術(shù)實現(xiàn)）轉(zhuǎn)變?yōu)槲谋炯壉葘?。比對過程中可以識別新增、修改、刪除屬性、配置項等信息。

Q3：如果已經(jīng)有一個偏資產(chǎn)管理流程數(shù)據(jù)的cmdb了，那么想用這個云化cmdb思路落地是不是只能重構(gòu)了？

A：是。

Q4：配置主動發(fā)現(xiàn)這個最重要。怎么去區(qū)分邏輯屬性，物理屬性，動態(tài)屬性，靜態(tài)屬性，關(guān)聯(lián)配置項目，怎么與資產(chǎn)關(guān)聯(lián)？

A：應(yīng)該說配置主動發(fā)現(xiàn)采用的是一種輪詢查找機制，我希望在新的云化CMDB中采用的思路是配置事件驅(qū)動的模式進行配置更新。
比如在IaaS中，我們要申請一臺VM，在申請的過程中已經(jīng)收集了VM相關(guān)信息，以及安裝的數(shù)據(jù)庫、中間件實例等配置信息，從這個例子中我們發(fā)現(xiàn)變更-配置更新是一體的，也就不需要配置自動發(fā)現(xiàn)工具。
當然在實際環(huán)境中，我們要兩者結(jié)合。配置自動發(fā)現(xiàn)工具也不局限于特定的如ADDM、TADDM這類工具，可以擴展到監(jiān)控、腳本等工具。

Q5：cmdb etl如何解釋？我知道etl但和cmdb一起完全沒有概念，請解釋，謝謝！

A： CMDB從本質(zhì)來說就是一個數(shù)據(jù)庫，我們要解決的是如何允許多個外部數(shù)據(jù)源同時錄入配置數(shù)據(jù)，那么數(shù)據(jù)源之間會出現(xiàn)沖突，這就需要一個合理的技術(shù)去解決。
ETL其實在數(shù)倉里應(yīng)用多年，我們完全可以借鑒過來加以利用。這個方案在三個大行已經(jīng)得到了應(yīng)用。當時我們用的是Kettl。

Q6:怎么區(qū)分模型還是場景？

A：模型其實簡單說就是數(shù)據(jù)庫的表結(jié)構(gòu)，場景其實就是使用數(shù)據(jù)庫的應(yīng)用程序。

Q7:我覺得cmdb到后面就是個aws的json格式的api接口，殊途同歸，不曉得老師怎么看？

A：這個問題比較有意思，從接口的發(fā)展趨勢看，類似于RestFul的API目前已經(jīng)是事實標準，在云化CMDB中所有API也將通過這種方式提供。

Q8：例如不管是阿里云還是aws，所有的運維活動都是圍繞資源天然集成，似乎已經(jīng)失去了傳統(tǒng)環(huán)境下配置驅(qū)動流程的意義了？

A：這個是個好問題。一個非常有意思的是無論是AWS、還是Openstack都沒有集中存放配置的管理組件。
前不久，AWS發(fā)布了AWSConfig，這個組件其實就是負責(zé)AWS上所有配置信息的集中管理，并已經(jīng)和20多個軟件廠商實現(xiàn)了整合，同時我們Netflix上也看到了類似的項目。
所以，答案已經(jīng)比較明顯了，配置管理的這類需求還很普遍。

Q9：在云環(huán)境下，資源都是服務(wù)，運維服務(wù)和資源服務(wù)天然的聯(lián)動集成，我個人感覺云環(huán)境下cmdb的功能更多是一個ci全景的可視查詢，還有其他場景嗎？

A：可視查詢是從配置消費角度看到的一個典型場景，從配置提供的角度看，由于云化環(huán)境涉及了計算、網(wǎng)絡(luò)、存儲虛擬化，以及大量自動化運維工具，因此比較復(fù)雜的是配置數(shù)據(jù)提供場景。例如，如何在一個VM的交付過程中，實時的更新配置信息。

Q10：cmdb在建設(shè)初期怎么發(fā)揮價值？或者說，如何在運維工作中發(fā)揮更大作用，而不只是一個電子臺帳？

A：
建立場景驅(qū)動理念，確保配置數(shù)據(jù)有人去使用；
通過技術(shù)手段提升配置數(shù)據(jù)的自動化率，確保CI項中的屬性絕大多數(shù)都能被某種自動化工具覆蓋。

Q11：請問下CMDB里的數(shù)據(jù)準確性是怎么保證的？

A：非云化環(huán)境，一般通過事后審計的方式，識別有問題的配置項，然后進行手工修正。
云化環(huán)境，由于環(huán)境都是軟件定義的，基礎(chǔ)架構(gòu)的變更和配置更新是同時發(fā)生的，理論上來說CMDB中的數(shù)據(jù)是云化環(huán)境的快照。今天分享的內(nèi)容主要側(cè)重在云化環(huán)境。