本發(fā)明涉及計算機領域，尤其涉及一種面向超融合一體機的資源監(jiān)控系統(tǒng)。

背景技術：

超融合是云計算的一個新分支，主要關注于虛擬計算、分布式存儲與虛擬網(wǎng)絡的融合，定位于實現(xiàn)私有云平臺。目前超融合集群以最少3個物理節(jié)點組成，每個節(jié)點都處于對等的地位，集群擴展以節(jié)點線性擴展的方式擴展。但目前在實際生產(chǎn)環(huán)境中，超融合平臺由眾多物理機以及運行在物理機上的超融合相關服務組成，當平臺規(guī)模變大時，集群的物理服務器會很多，上面運行著成千上萬的租戶的虛擬機實例，單純依靠系統(tǒng)管理員的經(jīng)驗和運維人員來進行監(jiān)控和維護是不現(xiàn)實也不合理的。

傳統(tǒng)的資源監(jiān)控方案中，如Ganglia，一般采用侵入式的數(shù)據(jù)采集方式，這種監(jiān)控方式會影響到虛擬機的用戶體驗，而且對于惡意用戶惡意關閉監(jiān)控程序等現(xiàn)象沒有很好的解決辦法，同時也會增加系統(tǒng)的復雜程度。因此需要一個簡單高效的系統(tǒng)將整個集群的物理資源和虛擬資源等同時監(jiān)控起來，監(jiān)控系統(tǒng)不會隨著監(jiān)控數(shù)據(jù)的增加被壓垮，同時降低虛擬機監(jiān)控的侵入性。

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

有鑒于現(xiàn)有技術的上述缺陷，本發(fā)明所要解決的技術問題是提供一種面向超融合一體機的資源監(jiān)控系統(tǒng)，本系統(tǒng)通過Libvirt接口等方式，減少監(jiān)控系統(tǒng)的侵入性，同時使用基于ZooKeeper的分布式架構，來保證整個監(jiān)控集群的高可用性。

為實現(xiàn)上述目的，本發(fā)明提供了一種面向超融合一體機的資源監(jiān)控系統(tǒng)，包括若干個HcpMonitor監(jiān)控組件，所述HcpMonitor監(jiān)控組件包括MonitorServer模塊和MonitorClient模塊；

若干個所述HcpMonitor監(jiān)控組件依據(jù)ZooKeeper客戶端框架選擇其中一個MonitorServer模塊為主控節(jié)點，其他MonitorServer模塊作為隨從節(jié)點處于待命狀態(tài)，所述MonitorClient模塊從ZooKeeper組件中采集數(shù)據(jù)，將采集到的數(shù)據(jù)傳送到AMQP Message Middle文件中，其中作為主控節(jié)點的MonitorServer模塊從AMQP Message Middle文件中讀取到數(shù)據(jù)后，進行數(shù)據(jù)分析處理，通過ZooKeeper集群進行分布式管理。

較佳的，所述MonitorServer模塊工作流程包括如下步驟：

S1：服務器初始化；

S2：判斷是否成為主控節(jié)點，如果否，則執(zhí)行步驟S3，否則，則執(zhí)行步驟S4；

S3：放棄等待，放棄CPU占用并且等待，并定時執(zhí)行步驟S2。

S4：集群管理，管理HcpMonitor監(jiān)控組件集群的主循環(huán)，包括設置監(jiān)聽器，處理數(shù)據(jù)等工作，執(zhí)行完畢后，繼續(xù)執(zhí)行步驟S2。

較佳的，所述MonitorClient模塊中包括數(shù)據(jù)收集器和主循環(huán)器；

所述數(shù)據(jù)收集器主要使用Linux常見的系統(tǒng)工具以及Python腳本調(diào)用Libvirt的方式來獲取物理機和虛擬機對應的監(jiān)控信息；

所述主循環(huán)器的流程如下：

A1：獲取物理機狀態(tài)；

A2：獲取物理機數(shù)據(jù)；

A3：獲取監(jiān)控數(shù)據(jù)；

A4：數(shù)據(jù)適配器處理；

A5：判斷是否結束，是則結束程序，否則執(zhí)行步驟A1。

較佳的，所述步驟S1中服務器初始化流程如下：

S1-1：初始化ZooKeeper路徑，對ZooKeeper中所有使用到的路徑根據(jù)應有的狀態(tài)進行初始化，如果不存在的則進行創(chuàng)建；

S1-2：初始化清理線程，啟動一根線程定時清理集群中所有長期未處理的請求和未響應的事件，防止集群資源的浪費；

S1-3：初始化配置線程，啟動集群配置的更新線程，該線程的主要工作是定時同步所修改的集群配置，讓集群配置可以更新同步到每臺物理機上。

較佳的，所述步驟S4中集群管理的流程如下：

S4-1：設置監(jiān)聽器，初始化所有的監(jiān)聽事件，包括/hosts、/hosts-ephemeral以及/monitor等，并且根據(jù)所觸發(fā)的節(jié)點事件來生成集群的事件，包括物理節(jié)點上線、物理節(jié)點掉線、虛擬機上線、虛擬機掉線等等；

S4-2：清理舊數(shù)據(jù)，新選出來的主控節(jié)點會對舊主控節(jié)點產(chǎn)生的集群數(shù)據(jù)進行清理，防止有數(shù)據(jù)不一致的情況發(fā)生；

S4-3：判斷是否結束程序，如果是則結束成程序，否則繼續(xù)執(zhí)行下一步；

S4-4：收集數(shù)據(jù)；

S4-5：數(shù)據(jù)處理；

S4-6：返回步驟S4-3繼續(xù)執(zhí)行。

本發(fā)明的有益效果是：本發(fā)明提出了一種面向超融合一體機的資源監(jiān)控系統(tǒng)，此監(jiān)控系統(tǒng)基于超融合基礎架構下，系統(tǒng)簡單高效的，減少監(jiān)控系統(tǒng)的侵入性，可用性高，最大限度的共享超融合基礎架構已有的資源，數(shù)據(jù)采集、處理高效。

附圖說明

圖1是本發(fā)明總體結構圖；

圖2是本發(fā)明MonitorServer模塊工作流程圖；

圖3是本發(fā)明主循環(huán)器的工作流程圖；

圖4是本發(fā)明服務器初始化工作流程圖；

圖5是本發(fā)明集群管理的工作流程圖；

具體實施方式

下面結合附圖和實施例對本發(fā)明作進一步說明：

如圖1所示，本實施例包括若干個HcpMonitor監(jiān)控組件，所述HcpMonitor監(jiān)控組件包括MonitorServer模塊和MonitorClient模塊；若干個所述HcpMonitor監(jiān)控組件依據(jù)ZooKeeper客戶端框架選擇其中一個MonitorServer模塊為主控節(jié)點，其他MonitorServer模塊作為隨從節(jié)點處于待命狀態(tài)，所述MonitorClient模塊從ZooKeeper組件中采集數(shù)據(jù)，將采集到的數(shù)據(jù)傳送到AMQP Message Middle文件中，其中作為主控節(jié)點的MonitorServer模塊從AMQP Message Middle文件中讀取到數(shù)據(jù)后，進行數(shù)據(jù)分析處理，并將數(shù)據(jù)傳輸給ZooKeeper集群和MariaDB Cluster數(shù)據(jù)庫集群，通過ZooKeeper集群進行分布式管理。

如圖2所示，所述MonitorServer模塊工作流程包括如下步驟：

S1：服務器初始化；

S2：判斷是否成為主控節(jié)點，如果否，則執(zhí)行步驟S3，否則執(zhí)行步驟S4；

S3：放棄等待，放棄CPU占用并且等待，并每隔一段時間定時執(zhí)行步驟S2，本實施例每隔5s或者10s定時執(zhí)行步驟S2。

S4：集群管理，管理HcpMonitor監(jiān)控組件集群的主循環(huán)，包括設置監(jiān)聽器，處理數(shù)據(jù)等工作，執(zhí)行完畢后，繼續(xù)執(zhí)行步驟S2。

如圖3所示，所述MonitorClient模塊中包括數(shù)據(jù)收集器和主循環(huán)器；

所述數(shù)據(jù)收集器主要使用Linux常見的系統(tǒng)工具以及Python腳本調(diào)用Libvirt的方式來獲取物理機和虛擬機對應的監(jiān)控信息；

所述主循環(huán)器的流程如下：

A1：獲取物理機狀態(tài)；

A2：獲取物理機數(shù)據(jù)；

A3：獲取監(jiān)控數(shù)據(jù)；

A4：數(shù)據(jù)適配器處理；

A5：判斷是否結束，是則結束程序，否則執(zhí)行步驟A1。

如圖4所示，所述步驟S1中服務器初始化流程如下：

S1-1：初始化ZooKeeper路徑，對ZooKeeper中所有使用到的路徑根據(jù)應有的狀態(tài)進行初始化，如果不存在的則進行創(chuàng)建；

S1-2：初始化清理線程，啟動一根線程定時清理集群中所有長期未處理的請求和未響應的事件，防止集群資源的浪費；

S1-3：初始化配置線程，啟動集群配置的更新線程，該線程的主要工作是定時同步所修改的集群配置，讓集群配置可以更新同步到每臺物理機上。

如圖5所示所述步驟S4中集群管理的流程如下：

S4-1：設置監(jiān)聽器，初始化所有的監(jiān)聽事件，包括/hosts、/hosts-ephemeral以及/monitor等，并且根據(jù)所觸發(fā)的節(jié)點事件來生成集群的事件，包括物理節(jié)點上線、物理節(jié)點掉線、虛擬機上線、虛擬機掉線等等；

S4-2：清理舊數(shù)據(jù)，新選出來的主控節(jié)點會對舊主控節(jié)點產(chǎn)生的集群數(shù)據(jù)進行清理，防止有數(shù)據(jù)不一致的情況發(fā)生；

S4-3：判斷是否結束程序，如果是則結束成程序，否則繼續(xù)執(zhí)行下一步；

S4-4：收集數(shù)據(jù)；

S4-5：數(shù)據(jù)處理；

S4-6：返回步驟S4-3繼續(xù)執(zhí)行。

以上詳細描述了本發(fā)明的較佳具體實施例。應當理解，本領域的普通技術人員無需創(chuàng)造性勞動就可以根據(jù)本發(fā)明的構思作出諸多修改和變化。因此，凡本技術領域中技術人員依本發(fā)明的構思在現(xiàn)有技術的基礎上通過邏輯分析、推理或者有限的實驗可以得到的技術方案，皆應在由權利要求書所確定的保護范圍內(nèi)。