本發(fā)明涉及it管理技術領域，具體涉及一種基于cmdb的自助資源分配調度的方法。

背景技術：

隨著目前諸多大型企業(yè)越來越重視互聯(lián)網(wǎng)技術，所建立的數(shù)據(jù)中心也不單單在某個城市，可能在多個城市、甚至多個國家擁有多個分布式數(shù)據(jù)中心；而每個數(shù)據(jù)中心可能還包括數(shù)以萬計的物理資源和虛擬資源(泛指虛擬機，指通過軟件模擬的具有完整硬件系統(tǒng)功能的、運行在一個完全隔離環(huán)境中的完整計算機系統(tǒng))，尤其是每臺物理服務器都承載大量重要的虛擬機等應用。針對這種日趨復雜的情況，需要通過cmdb系統(tǒng)針對“閑置資源”和“業(yè)務應用”進行分配及關聯(lián)。

cmdb(configurationmanagementdatabase，配置管理數(shù)據(jù)庫)通過識別、控制、維護，檢查企業(yè)的it資源，從而高效控制與管理不斷變化的it基礎架構與it服務，并為其它流程，例如事故管理、問題管理、變更管理、發(fā)布管理等流程提供準確的配置信息。

作為it管理的核心，近年來cmdb逐漸成為系統(tǒng)管理項目實施的熱點。cmdb系統(tǒng)中至少包含這幾種關鍵的功能：整合、調和、同步、映射和可視化，其中“同步”是指確保cmdb中的信息能夠反映聯(lián)合數(shù)據(jù)源的更新情況，在聯(lián)合數(shù)據(jù)源更新頻率的基礎上確定cmdb更新日程，按照經(jīng)過批準的變更來更新cmdb，找出未被批準的變更。這當中有一個重要的特性“資源”，資源在這里多指ip資源，也可以是存儲資源、網(wǎng)絡資源、機房資源等等，而資源必須要和應用關聯(lián)起來，那么這當中就會涉及到“資源分配申請”的功能模塊。

在運用cmdb系統(tǒng)進行資源分配時，通常為了節(jié)省成本及資源，會在每臺物理機(即宿主機，虛擬機的物理基礎，虛擬機存在于宿主機中，與宿主機共享使用硬件。宿主機的運行是虛擬機運行的前提與基礎。)中承載多個虛擬機，每個虛擬機可以看作獨立的服務器進行使用，然而為了避免發(fā)生單點故障(這里的“單點”是指通過cmdb系統(tǒng)在進行自動申請資源時，所申請的某個或多個虛擬機服務器資源，正巧都落在同一個宿主機中，容易發(fā)生單點故障)，會在多個宿主機及其包含的虛擬機中組建成龐大的計算機集群一來加強計算能力，二來可以防止單點故障發(fā)生，然后通過cmdb系統(tǒng)的資源申請功能來讓企業(yè)開發(fā)人員自助根據(jù)不同的業(yè)務應用來申請資源數(shù)量。

cmdb系統(tǒng)的資源分配功能，通常都是以網(wǎng)頁并且以b/s結構的方式表現(xiàn)，使用人員通過瀏覽器所呈現(xiàn)的頁面進行自助申請操作，結合以上描述，目前主要有以下實施方式：

現(xiàn)有技術方案一：

如圖1所示，包括以下步驟：

步驟a1，為每個業(yè)務應用開發(fā)創(chuàng)建一個cmdb系統(tǒng)，然后將事先已經(jīng)預定好的應用和所涉及到的所有服務器(集群)資源信息都收集并導入進各個cmdb系統(tǒng)的數(shù)據(jù)庫中，確保每個應用下的cmdb系統(tǒng)中資源信息互相隔離。

服務器集群是將很多服務器集中起來一起進行同一種服務，在客戶端看來就像是只有一個服務器。集群可以利用多個計算機進行并行計算從而獲得很高的計算速度，也可以用多個計算機做備份。

步驟a2，開發(fā)人員通過對應的業(yè)務應用中的cmdb系統(tǒng)，進入資源申請的頁面，然后填寫包括“應用名”、“資源申請數(shù)量”、“責任人”等信息自助提交申請操作。

步驟a3，后端服務器接收到前端發(fā)來的提交申請的數(shù)據(jù)，會在數(shù)據(jù)庫中表的′status′和′host_ip′字段來組合查詢該業(yè)務應用是否有可用閑置資源，若有，即會變更和記錄相應的數(shù)據(jù)信息并把結果返回給前端頁面；若沒有，則會向前端頁面拋出錯誤。圖2是各個數(shù)據(jù)庫關于資源表的相關e-r圖(entityrelationshipdiagram，實體-聯(lián)系圖)，經(jīng)圖里顯示′host_ip′唯一性約束字段可說明其服務器資源僅有宿主機(即物理機)。

步驟a4，開發(fā)人員或系統(tǒng)管理員可以看到提交申請結果和相關日志。

現(xiàn)有技術方案二：

如圖3所示，現(xiàn)有技術方案二不同于現(xiàn)有技術方案一為每個應用都開發(fā)一套獨立的cmdb系統(tǒng)，現(xiàn)有技術方案二主要通過一個cmdb系統(tǒng)對多個業(yè)務應用進行統(tǒng)一資源申請，而數(shù)據(jù)庫存儲的是所有業(yè)務應用所涉及到的所有服務器(集群)資源信息，通過圖4的e-r圖可知，如字段′host_ip′和唯一性約束字段′private_ip′，代表可能有多條數(shù)據(jù)擁有相同′host_ip′和不同的′private_ip′，說明技術方案二所申請的資源不僅包括宿主機(即物理機)，并且部分宿主機中還包括大量虛擬機。接下來的步驟基本和技術方案一所提到的步驟a1、a2、a3一樣，開發(fā)人員通過申請自助頁面填入相關信息后，系統(tǒng)后臺向數(shù)據(jù)庫表的′status′和′host_ip′字段來組合查詢可用資源，并進行相應的變更和返回結果。

綜上所述，現(xiàn)有技術方案一主要通過為每個應用都開發(fā)一套獨立的cmdb系統(tǒng)，并單獨存儲該應用所對應的資源信息，且這些資源都只是物理服務器，沒有虛擬機，因此該方案主要從不同應用之間的數(shù)據(jù)隔離來確保資源申請的準確性，但由于當前企業(yè)互聯(lián)網(wǎng)業(yè)務大量普及，僅僅通過一臺物理服務器運行一個應用既浪費服務器性能，又耗費巨大，已不符合現(xiàn)代企業(yè)互聯(lián)網(wǎng)建設的初衷；再者，日后若在物理機中引入虛擬機技術，該方案將無法滿足需求，另外，隨著企業(yè)的發(fā)展越來越大，而業(yè)務應用也會越來越多，而cmdb系統(tǒng)也會變的更復雜龐大，若為每個應用都單獨開發(fā)一套cmdb系統(tǒng)和數(shù)據(jù)庫顯然大大增加了人力維護的成本，因此該資源申請方案的使用場景非常有限，只適合于擁有服務器資源極少的企業(yè)選用。

現(xiàn)有技術方案二相當于針對現(xiàn)有技術方案一的改進，通過開發(fā)創(chuàng)建一個cmdb系統(tǒng)來統(tǒng)一對各個業(yè)務應用進行資源申請，而所有的資源服務器信息都會在一個數(shù)據(jù)庫中進行查詢相關可用資源信息，并為使用人員在申請多臺資源時隨機分配資源數(shù)量，盡管這一技術方案大大彌補了技術方案一所涉及的問題，但由于現(xiàn)在諸多企業(yè)的服務器資源以虛擬機的形式安放在多臺物理機中，這樣就會帶來另一種問題，如果開發(fā)人員在申請2臺及2臺以上的服務器資源時，后臺無論是通過數(shù)據(jù)庫表中的字段′status′和′private_ip′還是字段′status′和′host_ip′進行組合查詢并隨機分配資源時，都會面臨分配的資源都落在同一臺宿主機中，而且閑置資源的范圍越小，被分配到同一臺宿主機的概率就越大，如圖5所示；盡管所有的服務器資源(物理機和虛擬機)都已集群化來增強性能及其可靠性，但某個應用的服務器資源都分配在同一個物理機中，集群技術不僅無效，也會存在單點故障；而且即使隨機分配發(fā)生該概率問題比較小的話，那么也很有可能出現(xiàn)如圖6，當某一應用的訪問量突然增大時，由于各個被分配的宿主機中的虛擬資源不均衡，會導致某臺宿主機的負載極高，而另一些宿主機負載極低，大大浪費了服務器資源，并且隨著申請的資源越多，風險就會越大，由此，一旦發(fā)生這種情況，勢必需要管理人員或開發(fā)人員人為干預和修改，極為不便。

技術實現(xiàn)要素：

本發(fā)明通過一些算法及技術手段來增強隨機分配資源的可靠性，來避免申請多臺資源時所遇到的單點問題，從而解決了現(xiàn)有技術方案存在的技術問題。

本發(fā)明采用的技術方案是：

一種基于cmdb的自助資源分配調度的方法，其特征在于，步驟如下：

步驟s1，收集服務器資源信息并存入cmdb數(shù)據(jù)庫資源表中；

步驟s2，用戶在cmdb系統(tǒng)中填寫申請資源信息并提交；

步驟s3，客戶端接收到用戶填寫的申請資源信息后，向cmdb系統(tǒng)的服務器端發(fā)送請求，服務器端接收到申請資源信息后，構建一個雙向隊列，并同時把用戶的申請資源信息放入雙向隊列中；

步驟s4，從cmdb數(shù)據(jù)庫資源表中獲取所有服務器資源信息，并生成動態(tài)資源池；

步驟s5，計算分配調度申請資源信息；

步驟s6，進行申請資源信息驗證并實時輸出。

進一步地，所述服務器資源信息包括物理機和虛擬機。

進一步地，所述步驟s4具體包括以下步驟：

通過cmdb數(shù)據(jù)庫資源表中的字段把閑置待用的所有服務器資源信息抽取出來，得到一個僅包括id和物理機ip的無序數(shù)據(jù)集，所述id是cmdb數(shù)據(jù)庫中用作主鍵的唯一標識。

進一步地，對閑置待用的服務器資源信息進行按順序分配，包括以下步驟：

將無序數(shù)據(jù)集ip轉換成十進制，即為節(jié)點；

在內存中創(chuàng)建一個帶有索引的動態(tài)數(shù)組表；

將無序數(shù)據(jù)集里每個服務器資源信息構建成線性表；

在動態(tài)數(shù)組表中通過指針來引用每個無序數(shù)據(jù)集的線性表形成一種關聯(lián)。

進一步地，通過鍵來構建一個基于圖的有序鍵值對鄰接表，所述鍵為動態(tài)數(shù)據(jù)表中的節(jié)點。

進一步地，所述圖g＝(v，e)，其中v為頂點，e為圖中各個頂點的邊；

v＝{節(jié)點1，節(jié)點2，節(jié)點……節(jié)點n}，n為節(jié)點數(shù)量；

把經(jīng)過排序并去重的節(jié)點作為所有頂點的集合，并作為鄰接表的鍵；設n為每個節(jié)點的重復元素的個數(shù)，設：

e＝{(節(jié)點1n1，)，(節(jié)點2n2，)，(節(jié)點3n3，)……節(jié)點nnn}。

進一步地，把每個頂點作為鍵，把每個節(jié)點重復元素作為邊，并壓入一個棧；每個頂點對應棧元素個數(shù)，作為每個頂點的邊長。

進一步地，構建一組動態(tài)資源池，包括以下步驟：

窮舉每個頂點的同時，獲取所述頂點的邊，每一次的遍歷頂點的同時，依次把各個頂點所對應的棧彈出棧頂元素，并通過內存地址作為節(jié)點引入進一個空的單向鏈表中，所述單向鏈表為動態(tài)資源池。

進一步地，所述步驟s5具體包括以下步驟：

用戶申請的資源數(shù)量作為索引范圍進行分片訪問動態(tài)資源池，取出相應的結果作為申請資源信息。

進一步地，所述步驟s6中通過一個驗證器來驗證動態(tài)資源池中所獲取的結果中所有的節(jié)點元素是否全都重復，若是，標記錯誤結果；若否，則向cmdb數(shù)據(jù)庫進行相應變更，并實時將結果輸出給瀏覽器。

本發(fā)明有益效果如下：

1、通過cmdb系統(tǒng)進行資源分配后無需再次人為的干預。

2、解決了分配給業(yè)務應用的資源存在的單點隱患。

3、申請后的資源均勻分布在各個物理節(jié)點中，而不至于當該應用達到高峰訪問量時出現(xiàn)性能瓶頸。

附圖說明

圖1是現(xiàn)有技術方案一原理圖。

圖2是現(xiàn)有技術方案一資源表e-r圖。

圖3是現(xiàn)有技術方案二原理圖。

圖4是現(xiàn)有技術方案二資源表e-r圖。

圖5是現(xiàn)有技術方案二資源分配調度實施方式一效果圖。

圖6是現(xiàn)有技術方案二資源分配調度實施方式二效果圖。

圖7是本發(fā)明資源分配調度效果圖。

圖8是本發(fā)明自主資源分配調度原理圖。

圖9是本發(fā)明雙向隊列構建示意圖。

圖10是本發(fā)明數(shù)據(jù)庫資源表的數(shù)據(jù)結構圖。

圖11是通過索引訪問元素成員信息示意圖。

圖12是鄰接圖。

圖13是動態(tài)資源池示意圖。

圖14是資源驗證與實時輸出示意圖。

具體實施方式

本發(fā)明的目的在于為開發(fā)人員在使用cmdb系統(tǒng)進行應用資源申請后，來避免某一應用下的服務器會面臨的單點故障隱患，并可均勻分布在各個物理節(jié)點中，提高高可用性，從而降低事后人為干預的問題。下文中，結合附圖和實施例對本發(fā)明作進一步闡述。

圖7是本發(fā)明最終效果圖，通過一些算法及技術手段來增強隨機分配資源的可靠性。

圖8是本發(fā)明基于cmdb的自助資源分配調度方法流程圖，包括以下步驟：

步驟s1，把所有的服務器資源信息(包括物理機和虛擬機)收集并存入cmdb數(shù)據(jù)庫的資源表中。

步驟s2，用戶在cmdb系統(tǒng)中的“自助申請資源”頁面里，填寫相應的申請資源信息，如“應用名”、“資源申請數(shù)量”、“責任人”等信息，并點擊“提交申請”按鈕。

步驟s3，客戶端接收到用戶填寫的申請資源信息后，向cmdb系統(tǒng)的服務器端發(fā)送請求，服務器端接收到數(shù)據(jù)后，此時會事先構建一個雙向隊列，并同時把每個申請人的申請資源信息放入雙向隊列里，并準備在雙向隊列中進行cmdb數(shù)據(jù)庫變更讀寫操作，從而解決競爭問題，如圖9所示。

步驟s4，從cmdb數(shù)據(jù)庫中獲取所有服務器資源信息，并生成動態(tài)資源池，具體步驟如下：

圖10為cmdb數(shù)據(jù)庫資源表的數(shù)據(jù)結構以及當中涉及的假設數(shù)據(jù)，其中字段“status”代表“待用”和“在用”的資源狀態(tài)、以及當字段“host_ip”有值代表“物理機”、當字段“host_ip”和“private_ip”都有值代表“虛擬機”、若多個虛擬機信息中擁有相同值的字段“host_ip”代表是這些虛擬機都隸屬于同一臺物理機中。如下表1所示。

表1本發(fā)明cmdb數(shù)據(jù)庫資源表

為了把“待用資源”均勻的分布在各個物理機中，以及盡可能的方便資源管理、服務器資源信息能夠被順序分配。因此首先通過cmdb數(shù)據(jù)庫資源表中的字段“status”、“private_ip”和“host_ip”把閑置待用的所有服務器資源信息抽取出來，得到一個僅包含“id”(這里的id是指cmdb數(shù)據(jù)庫中用作主鍵的唯一標識id)和“host_ip”(既物理機ip)的無序數(shù)據(jù)集，假設如下所示：

“(4，’10.1.1.1’)，(3，’10.1.1.3’)，(1，’10.1.1.1’)，(2，‘10.1.1.2’)......”

之所以出現(xiàn)重復的物理機ip，是由于存在多個虛擬機都在同一個物理機中。為了先滿足閑置資源能被順序的分配，先需要把無序數(shù)據(jù)集的ip轉換成十進制有利于排序做準備，在此為了方便描述，記為“節(jié)點”，然后在內存中創(chuàng)建一個帶有索引的動態(tài)數(shù)組(特指在聲明時沒有確定數(shù)組大小的數(shù)組。使用動態(tài)數(shù)組的優(yōu)點是可以根據(jù)用戶需要，有效利用存儲空間)表，再把無序數(shù)據(jù)集里每個服務器資源信息都構建成線性表(一種具有線性結構特點的計算機中常用數(shù)據(jù)結構，它是一個含有n≥0個節(jié)點的有限序列)，接著在動態(tài)數(shù)組表中通過指針來引用每個無序數(shù)據(jù)集的線性表形成一種關聯(lián)，這樣就可以通過索引來方便訪問每個元素的成員信息，如圖11所示。

之后，通過動態(tài)數(shù)組中的節(jié)點(即十進制數(shù))作為“鍵”來構建一個基于圖(圖是一種抽象的數(shù)學結構，研究抽象對象之間的一類二元關系及其拓撲性質。數(shù)學領域里有一個稱為“圖論”的研究分支，專門研究這種拓撲結構。它也看作計算機中一種復雜的數(shù)據(jù)結構)的有序鍵值對鄰接表，由于節(jié)點可能存在重復值，而“鍵”本身是不可重復的，那么處理該問題的機制如下：

令圖g＝(v，e)，其中v為頂點，e為圖中各個頂點的邊，設：

v＝{節(jié)點1，節(jié)點2，節(jié)點3……節(jié)點n}，n為節(jié)點數(shù)量，

把經(jīng)過排序并去重的節(jié)點作為所有頂點的集合，并作為鄰接表的鍵；設n為每個節(jié)點的重復元素的個數(shù)，設：

e＝{(節(jié)點1n1，)，(節(jié)點2n2，)，(節(jié)點3n3，)……節(jié)點nnn}

通過觀察，由于圖g中各個頂點都沒有路徑相連，每個頂點的邊都各自獨立，于是就形成了一種“非連通圖”，圖12為表示所述非連通圖的有序鍵值對鄰接表。

把每個頂點v作為“鍵”，而把各個節(jié)點重復元素作為邊為e，并壓入一個棧；每個頂點對應的堆棧元素個數(shù)，作為每個頂點的邊長，即：

top-bottom+1，其中bottom≥1，如果棧當中top＝bottom＝0，說明棧是空的。

接著需要在此基礎之上構建一組動態(tài)資源池，首先每個頂點的邊都是由一個棧所構成，那么在窮舉每個頂點的同時，獲取所述頂點的邊，每一次的遍歷頂點的同時，依次把各個頂點所對應的棧彈出其棧頂元素，并通過內存地址作為節(jié)點引入進一個空的單向鏈表中，而所述單向鏈表即作為動態(tài)資源池，如圖13所示。

單向鏈表(單鏈表)是鏈表的一種，其特點是鏈表的鏈接方向是單向的，對鏈表的訪問要通過順序讀取從頭部開始；鏈表是使用指針進行構造的列表；又稱為節(jié)點列表，因為鏈表是由一個個節(jié)點組裝起來的。

步驟s5，計算分配調度申請資源信息，具體步驟如下：

由于在步驟s2時，系統(tǒng)已經(jīng)從用戶的輸入中獲取到需要申請的資源數(shù)量，而所述資源數(shù)量假設為x臺，把x臺作為索引范圍進行分片訪問單項鏈表(動態(tài)資源池)，取出相應的結果作為待申請的資源信息。

步驟s6，進行申請資源信息驗證并實時輸出。

盡管通過步驟s5已經(jīng)得到了結果，但還需考慮一種情況，假設最終的動態(tài)資源池中所獲取的結果里待用節(jié)點元素都為重復，那么說明動態(tài)資源池中的待用節(jié)點都在僅一臺物理機中，由于會存在單點隱患，因此還需要一個驗證器來驗證其結果中所有的節(jié)點元素是否全都重復，若是，標記錯誤結果；若否，則向cmdb數(shù)據(jù)庫進行相應變更，由步驟s3可知，整個cmdb數(shù)據(jù)庫資源分配的過程都在雙向隊列中進行，因此，在這里離開雙向隊列后，并實時把結果傳給瀏覽器。圖14為步驟s6的完整示例流程。

本發(fā)明雖然已以較佳實施例公開如上，但其并不是用來限定本發(fā)明，任何本領域技術人員在不脫離本發(fā)明的精神和范圍內，都可以利用上述揭示的方法和技術內容對本發(fā)明技術方案做出可能的變動和修改，因此，凡是未脫離本發(fā)明技術方案的內容，依據(jù)本發(fā)明的技術實質對以上實施例所作的任何簡單修改、等同變化及修飾，均屬于本發(fā)明技術方案的保護范圍。