一種基于CMDB平臺的運維管理系統的研究

曾曉松

（中國東方航空股份有限公司，上海 200000）

0 引言

伴隨著信息化互聯網技術的飛速發展，企業為了保證業務規模和數字化發展就需要不斷的采購和擴充機器設備來滿足企業的業務發展需要，但是目前絕大多數企業都只關心信息設備的采購、安裝和使用，對于非常重要的信息設備基礎設施建設和管理方面的投入嚴重不足。后期隨著機器設備數量的不斷壯大，極其容易造成運維人員維護時間和成本加大，不利于運維工作的開展。同時由于前期重視程度不夠，容易造成企業運維手段單一，不具備智能化和自動化管理運維能力，運維還是靠傳統的人工維護，這樣就會造成人力投入成本過高。另外排查和解決問題能力如果非常依賴技術人員的個人能力，那個不利于企業快速的排查和解決問題，這些問題在傳統的大型國有企業和央企等企業問題非常嚴重。針對此問題，如何綜合利用企業目前的技術架構和有限的資金來搭建一套合理并且有效的 CMDB（Configuration Management Database，配置管理數據庫）平臺，來智能化的提升信息設備的綜合服務管理能力，保障企業信息設備的運營質量和提升運維管理能力就顯得尤其重要。CMDB平臺不僅負責集中存儲企業中所有的信息設備，而且能夠智能化的集中管理這些設備的配置信息，自動化的處理設備的運行情況，為使用平臺提供服務支持能力、支撐著企業業務流程的運轉、發揮出配置信息的價值，保證系統平穩的運行。

1 CMDB平臺總體架構

國內有些企業前期搭建企業系統的時候采用直接照搬國外的解決方案，但是發現效果并不是很好，根本原因在于沒有結合企業的現狀進行分析和應用。尤其是典型的傳統企業，組織規模龐大，但是整體技術化能力一般，所以運營能力一定會跟不上。因此需要針對不同的企業類型，根據其專有的背景搭建一套特有的解決方案。這套系統需要以企業的業務為導向，對企業資產、配置等各種IT資源嚴加把控，能夠對接變更發布流程，把控系統總體風險。另外伴隨著版本的不斷迭代，需要不斷對系統進行全面的升級更近，保證系統總體能力輸出。本文中搭建的系統是以傳統央企為背景進行平臺構建，由于央企系統龐大，對于數據實時變化要求高，不僅需要提供準確的數據并且還需要盡量的滿足速度要求。為了滿足以上所有需求搭建了一款具備業務建模能力和建立以消費場景結合自動化流程為觸發點的CMDB采集系統。系統總體架構圖如圖1所示，系統總體層級采用四層架構模式進行設計，底層外圍接口層、基礎架構層、服務平臺層和門戶應用層。底層外圍接口層主要是負責和監控系統、短信平臺、LDAP/AD和第三方系統等進行數據業務對接?；A架構層主要是由配置管理數據庫、基礎配置信息和與底層進行通信的接口適配器組成，其中 CMDB主要側重于信息的管理包括信息的采集、清洗、整合、記錄、維護、檢驗、更新等。服務平臺主要是處理事件管理、問題管理、知識管理、變更管理、發布管理和資產管理等管理模塊，通過服務請求管理模塊集中和上層進行通信操作。門戶應用層主要就是上層的應用層，主要包括服務目錄、自助服務、公告信息和KPI展現等應用。

圖1 系統總體架構圖Fig.1 System overall design framework

2 CMDB平臺核心技術

本項目基于CMDB平臺的運維管理系統主要負責對配置信息進行集中管理，便于系統運維操作能實現智能化的管理操作，方便系統進行集中管理和維護，在利用CMDB平臺的同時，主要通過 CI建模設計和自動化采集模塊設計來實現信 息采集功能，提高系統管理的智能化水平。

2.1 CI建模設計

CMDB平臺的運維管理系統中的 CI建模設計是重中之重的關鍵部分。CMDB平臺中的 CI建模又稱之為配置項建模，在CI里面存放了所有CMDB平臺信息的分類，同時將 CMDB中各個CI的邏輯關系，包括上下級、包含、屬于、依賴等都重要關系都納入其中。存儲對象信息主要包括如下的屬性：CI屬性來源、IT資產維護需要、IT服務需要、配置項需要和配置項信息本身。表還需要額外的內容要求，例如各種硬件兼容度存放要求、CI變更記錄要求、CI唯一ID要求和CI多狀態要求。具體存儲對象CI表結構如圖2所示。

圖2 存儲對象CI表結構Fig.2 Store object CI table structure

2.2 自動化采集模塊設計

自動化采集模塊是CMDB能夠實現自動化持續消費的基礎，也是近些年 CMDB逐漸成為 IT服務發展主力的主要原因。CMDB的自動化采集需要有無代理和有代理兩種發現形式，其中有代理即在服務器上部署代理程序，確保代理程序在后臺持續運行，也可以注冊為服務運行在服務器上。通過代理程序的不斷采集服務器的 OS版本信息、進程信息、用戶名、存儲、CPU、內存、硬盤、中間件、注冊安裝的軟件、網卡、MAC地址、IP地址、系統當前使用資源情況、日志、鄰居關系等等信息，發送給代理采集服務器或代理采集中繼服務器，通過服務器的比對、去重、校驗、數據清洗等運算，產生該臺機器的CI模型內容數據，并經過與現有數據的對比后通過變更流程的控制，自動寫入到CMDB數據庫中。無代理的采集內容較少于有代理模式，其主要用于輔助采集方面，由于有些服務器、網絡設備、安全設備無法安裝代理程序，或者不便安裝的原因，采用 SNMP（簡單網絡管理協議）發現目標設備的相關基礎信息，尤其是網絡層信息；對于Windows服務器采用 WMI協議，對于 Linux服務器采用SSH連接等方式通過授權賬號自動登錄相關系統自動采集到CI模型中需要的數據。

3 CMDB管理界面和系統實踐

CMDB平臺的運維管理系統信息管理頁面，主要可以實現信息的管理功能，信息管理不僅僅滿足于手動信息管理，另外還需要滿足自動信息管理，在滿足手動錄入信息支持的同時，也支持批量模板文件的導入。手動信息管理則需要用戶手動錄入多項數據內容，具體的手動信息管理功能界面圖如圖3所示。

圖3 手動信息管理功能界面Fig.3 Manual information management function interface

CMDB平臺的運維管理系統為了提高信息采集的效率和便于后期系統實現自動化的管理功能，系統需要滿足信息的自動采集功能，系統采集到具體的系統信息和硬件信息統一上送到數據庫中及時的進行數據備份和保存，管理頁面實現信息的顯示，運維人員通過頁面確認信息是否正確，便于后期信息維護，另外系統信息數據采集，還具有信息同步的功能，便于及時的共享系統的基本配置信息，同時將配置信息及時入庫進行存儲管理。自動采集功能界面圖如圖4所示。

圖4 自動采集功能界面Fig.4 Automatic acquisition function interface

運維人員和管理員度可以在前端現實的界面上實時的查詢信息采集的內容，包括系統的具體配置信息，機器的硬件信息等，另外系統在運行中的中間件信息和運行的進程信息也可以查詢，方便運維人員快速的定位問題，提高解決問題的效率。具體的采集信息查詢顯示的示意圖，如下圖5所示。

圖5 采集信息內容展示Fig.5 Collection of information content display

4 結論

經過充分的調查和對大量資料的研究，本文分析了 CMDB的基礎理論知識，也闡述了實施CMDB對企業帶來的好處，并且根據本企業的具體痛點針對性的設計了CMDB的總體設計框架，包括核心模塊的的實現。為了解決企業在CMDB方面面臨的種種困難，本文根據企業的實際情況，設計了一套CMDB框架，雖然CMDB平臺在企業的應用己經全面開展，但是還沒有達到非常成熟的地步。這是因為CMDB中包含大量的標準和流程，企業要全部實現有較大難度，需要自己摸索，尋找適合自己的實踐方法。同時在進行CMDB建設時，硬件設備、軟件系統和人員都處于磨合階段，一些IT部門的工作人員對CMDB的認識程度還不夠，需要不斷進行培訓和學習。通過本企業的CMDB實施案例和設計方案我們看到，IT服務和商業運作之間的關系越來越緊密。隨著實施 CMDB的時間越來越長，企業將逐漸認識到CMDB平臺管理的好處，也希望這一案例對于國內希望和愿意嘗試實施CMDB的企業有借鑒作用。