91精品人妻互换日韩精品久久影视|又粗又大的网站激情文学制服91|亚州A∨无码片中文字慕鲁丝片区|jizz中国无码91麻豆精品福利|午夜成人AA婷婷五月天精品|素人AV在线国产高清不卡片|尤物精品视频影院91日韩|亚洲精品18国产精品闷骚

 賈寶軍，徐雷，郭玉華，熊微，李素粉

 （中國(guó)聯(lián)合網(wǎng)絡(luò)通信有限公司研究院，北京100032）

摘要：提出了一種能夠支撐多數(shù)據(jù)中心和多私有云環(huán)境的監(jiān)控系統(tǒng)解決方案。通過(guò)采用分布式框架，重新封裝Zahbix API和OpenStack API，實(shí)現(xiàn)了壓力分擔(dān)、易于擴(kuò)展的統(tǒng)一監(jiān)控系統(tǒng)。該方案對(duì)于研究類(lèi)似的分布式集群調(diào)度系統(tǒng)具有重要意義。

關(guān)鍵詞：統(tǒng)一監(jiān)控系統(tǒng)；虛擬化；資源池

中圖分類(lèi)號(hào)：TP393  doi: 10.11959/j.issn.1000-0801.2016095

1  引言

 IT系統(tǒng)的監(jiān)控技術(shù)從信息化伊始就一直存在和發(fā)展著。小到單獨(dú)的IT系統(tǒng)，大到成百上千臺(tái)的服務(wù)器和網(wǎng)絡(luò)設(shè)備，都有或大或小的監(jiān)控系統(tǒng)。開(kāi)源社區(qū)也形成了如Ganglia、Nagios、Splunk的監(jiān)控軟件，被不少公司的信息化部門(mén)采用。近年來(lái)，隨著云計(jì)算、大數(shù)據(jù)和互聯(lián)網(wǎng)的快速發(fā)展，IT基礎(chǔ)設(shè)施發(fā)生了根本轉(zhuǎn)變，監(jiān)控需求從一些獨(dú)立的系統(tǒng)要求轉(zhuǎn)變?yōu)檎�體平臺(tái)化的系統(tǒng)要求。服務(wù)器不再是孤立的計(jì)算單元，而是通過(guò)云計(jì)算、大數(shù)據(jù)等平臺(tái)將計(jì)算、存儲(chǔ)資源統(tǒng)一起來(lái)，跨越數(shù)據(jù)中心范圍形成規(guī)模更大、統(tǒng)一管理的資源池，因此需要能夠監(jiān)控大規(guī)模、跨地域的虛擬資源的監(jiān)控系統(tǒng)。

2統(tǒng)一監(jiān)控的需求

2.1  云平臺(tái)的統(tǒng)一監(jiān)控要求

 私有云平臺(tái)除了采用商業(yè)的VMware和hypervisor作為虛擬化平臺(tái)外，還可以采用OpenStack等開(kāi)源技術(shù)。本文提出的云平臺(tái)基于OpenStack底層技術(shù)進(jìn)行搭建。為構(gòu)建一套完整的統(tǒng)一監(jiān)控系統(tǒng)，需要實(shí)現(xiàn)覆蓋全部物理機(jī)和虛擬機(jī)的監(jiān)控功能，以實(shí)現(xiàn)高效管理大規(guī)模軟硬件資源、動(dòng)態(tài)合理分配系統(tǒng)資源的目標(biāo)。  

  (1)物理機(jī)監(jiān)控，通過(guò)在物理機(jī)上安裝一個(gè)守護(hù)進(jìn)程，定時(shí)收集每個(gè)節(jié)點(diǎn)的狀態(tài)信息，最后匯總到監(jiān)控系統(tǒng)中，進(jìn)行存儲(chǔ)、歸納、分析、展示。智能平臺(tái)管理接口(IPMI)獲取監(jiān)控?cái)?shù)據(jù)。

 (2)虛擬機(jī)監(jiān)控，通過(guò)底層的Hypervisor進(jìn)程和虛擬化管理平臺(tái)收集相關(guān)的監(jiān)控項(xiàng)信息，發(fā)送給監(jiān)控系統(tǒng)，存儲(chǔ)、歸納、分析、展示每臺(tái)虛擬機(jī)的監(jiān)控信息。

 (3)監(jiān)控系統(tǒng)可以同時(shí)展示物理機(jī)和虛擬機(jī)的監(jiān)控視圖。

 (4)對(duì)于多個(gè)OpenStack平臺(tái)的環(huán)境，需要同時(shí)監(jiān)聽(tīng)多個(gè)Ceilometer來(lái)源以獲取不同虛擬化平臺(tái)下虛擬機(jī)的監(jiān)控?cái)?shù)據(jù)，匯總上報(bào)到監(jiān)控系統(tǒng)中。

  2.2跨地域的資源統(tǒng)一監(jiān)控

 隨著IT資源的虛擬化，數(shù)據(jù)中心間的區(qū)隔也變得日益模糊。用戶不再關(guān)心自己的硬件到底部署在什么地方，只關(guān)心軟件系統(tǒng)的服務(wù)能力是否滿足業(yè)務(wù)需求，這樣就要求底層資源池能提供一定的QoS保障，或者具有資源使用的調(diào)優(yōu)能力。要實(shí)現(xiàn)該要求，必須有縱觀全局的監(jiān)控能力，依據(jù)監(jiān)控指標(biāo)制定資源使用策略，實(shí)現(xiàn)資源的自動(dòng)或智能調(diào)配，保障軟件系統(tǒng)的能力要求。

 因歷史原因遺留下來(lái)的一些規(guī)模較小的數(shù)據(jù)中心，也需要納入統(tǒng)一資源池的環(huán)境中。當(dāng)下互聯(lián)網(wǎng)的系統(tǒng)需求往 往會(huì)急劇膨脹，有限的IT資源很難滿足互聯(lián)網(wǎng)快速發(fā)展的需求，這樣勢(shì)必要將以往孤立的小規(guī)模數(shù)據(jù)中心打通．提供統(tǒng)一的服務(wù)能力。

  3 Zabbix監(jiān)控軟件

 Zabbix是開(kāi)源社區(qū)監(jiān)控軟件的后起之秀，集成了SNMP、agent、IPMI等多種數(shù)據(jù)采集方式，方便在不同環(huán)境中使用，完善了監(jiān)控和圖形化顯示功能。

 Zabbix軟件具備一定的分布式系統(tǒng)管理能力，可以監(jiān)控小型和大型的分布式環(huán)境，并將所有歷史數(shù)據(jù)、趨勢(shì)和配置信息存儲(chǔ)在數(shù)據(jù)庫(kù)中。Zabbix所有的邏輯運(yùn)算都在服務(wù)器端執(zhí)行，對(duì)監(jiān)控對(duì)象的性能影響很小。

 Zabbix代理(proxy)支持分布式能力，可以代表Zabbix服務(wù)器收集性能和可用數(shù)據(jù)，承擔(dān)采集數(shù)據(jù)的任務(wù)并減輕Zabbix服務(wù)器的負(fù)載。同時(shí)，使用Zabbix代理是實(shí)施統(tǒng)一和分布式監(jiān)控最簡(jiǎn)單的方式，因?yàn)樗�有的客戶端和代�?nbsp;向同一個(gè)Zabbix服務(wù)器報(bào)告數(shù)據(jù)，并且所有數(shù)據(jù)集中保存在服務(wù)器數(shù)據(jù)庫(kù)中。Zabbix代理可在監(jiān)控遠(yuǎn)程區(qū)域、擁有不可靠鏈接的區(qū)域時(shí)使用。當(dāng)監(jiān)控?cái)?shù)以千計(jì)的設(shè)備時(shí)．Zabbix代理可分擔(dān)Zabbix服務(wù)器的負(fù)載。Zabbix分布式構(gòu)如圖1所示。

 采用Zabbix作為監(jiān)控系統(tǒng)可以支持分布式集中管理，用于分布式環(huán)境監(jiān)控，但也存在明顯缺點(diǎn)。首先，Zabbix方案需要在被監(jiān)控的主機(jī)上安裝agent，這樣會(huì)侵害用戶的隱私，而且agent也存在被用戶卸載的情況；其次，所有數(shù)據(jù)都集中保存在數(shù)據(jù)庫(kù)中，Zabbix監(jiān)控系統(tǒng)產(chǎn)生的數(shù)據(jù)量很大，數(shù)據(jù)庫(kù)會(huì)成為系統(tǒng)發(fā)展的瓶頸；最后，Zabbix代理的方案受限于代理性能，當(dāng)代理服務(wù)的監(jiān)控機(jī)器數(shù)量較多時(shí)，很難滿足資源的監(jiān)控要求。綜上所述．Zabbix不是一個(gè)能夠滿足云平臺(tái)和多數(shù)據(jù)中心統(tǒng)一監(jiān)控的軟件方案。

4分布式架構(gòu)的引入

 Dubbo是一個(gè)分布式服務(wù)框架，致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案以及SOA服務(wù)治理方案。其核心部分如下所述。

 (1)遠(yuǎn)程通信

 提供對(duì)多種基于長(zhǎng)連接的NIO框架的抽象封裝，包括多種線程模型、序列化以及“請(qǐng)求一響應(yīng)”模式的信息交換方式，像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法。 (2)集群容錯(cuò)

 提供基于接口方法的透明遠(yuǎn)程過(guò)程的調(diào)用，包括多協(xié)議支持、軟負(fù)載均衡、失敗容錯(cuò)、地址路由、動(dòng)態(tài)配置等集群支持。

 (3)自動(dòng)發(fā)現(xiàn)

 基于注冊(cè)中心目錄服務(wù)，使服務(wù)消費(fèi)方能動(dòng)態(tài)查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。

Dubbo架構(gòu)示意如圖2所示。

 系統(tǒng)包括5種不同的角色：服務(wù)提供者、服務(wù)消費(fèi)者、服務(wù)注冊(cè)中心、服務(wù)監(jiān)控中心和服務(wù)運(yùn)行容器。服務(wù)提供者是暴露服務(wù)的服務(wù)提供方：服務(wù)消費(fèi)者是調(diào)用遠(yuǎn)程分布式服務(wù)的服務(wù)使用方：服務(wù)注冊(cè)中心是系統(tǒng)的基礎(chǔ)和核心，是服務(wù)提供者和服務(wù)消費(fèi)者溝通的橋梁；服務(wù)監(jiān)控中心負(fù)責(zé)統(tǒng)計(jì)各服務(wù)調(diào)用次數(shù)、調(diào)用時(shí)間以及服務(wù)提供者的

服務(wù)運(yùn)行上報(bào)信息等：服務(wù)運(yùn)行容器啟動(dòng)、加載、運(yùn)行服務(wù)提供者。具體角色功能如下所述。

 (1)服務(wù)注冊(cè)中心提供集中的服務(wù)注冊(cè)、服務(wù)訂閱、服務(wù)信息通知及服務(wù)監(jiān)控功能，并提供代理模式的服務(wù)調(diào)用能力。

 (2)服務(wù)提供者負(fù)責(zé)提供具體的服務(wù)，并在服務(wù)啟動(dòng)后向集群服務(wù)管理系統(tǒng)進(jìn)行服務(wù)注冊(cè)，并定期將服務(wù)運(yùn)行統(tǒng)計(jì)信息（如服務(wù)性能數(shù)據(jù)、服務(wù)使用情況等）上報(bào)給監(jiān)控中心。

 (3)服務(wù)消費(fèi)者需要在服務(wù)啟動(dòng)后，主動(dòng)向集群服務(wù)管理系統(tǒng)訂閱所需的服務(wù)。當(dāng)消費(fèi)者訂購(gòu)的服務(wù)信息發(fā)生變化時(shí)，向訂閱的消費(fèi)者發(fā)送異步消息通知。

 (4)服務(wù)提供者及服務(wù)消費(fèi)者采用長(zhǎng)連接方式與集群服務(wù)管理系統(tǒng)進(jìn)行通信。

 (5)監(jiān)控中心統(tǒng)計(jì)服務(wù)消費(fèi)者和服務(wù)提供者的性能指標(biāo)等，并向服務(wù)注冊(cè)中心匯報(bào)服務(wù)提供者的服務(wù)運(yùn)行上報(bào)情況。

 (6)服務(wù)運(yùn)行容器提供Web服務(wù)容器功能，負(fù)責(zé)啟動(dòng)、加載、運(yùn)行服務(wù)提供者。

5統(tǒng)一監(jiān)控系統(tǒng)的實(shí)現(xiàn)

 采用Zabbix作為監(jiān)控能力的提供層，監(jiān)控系統(tǒng)重新定制portal以滿足跨數(shù)據(jù)中心的監(jiān)控以及統(tǒng)一的物理資源和虛擬資源的監(jiān)控。

 采用Dubbo框架對(duì)Zabbix API和OpenStack API進(jìn)行重新封裝，如圖3所示，實(shí)現(xiàn)分布式監(jiān)控系統(tǒng)。這樣監(jiān)控門(mén)戶對(duì)數(shù)據(jù)的訪問(wèn)變成由Dubbo引導(dǎo)的訪問(wèn)。Zabbix服務(wù)通過(guò)API方式由Dubbo服務(wù)提供者提供，用戶請(qǐng)求作為Dubbo下的服務(wù)消費(fèi)者向服務(wù)器提供者發(fā)送請(qǐng)求信息。

 當(dāng)監(jiān)控多個(gè)數(shù)據(jù)中心時(shí)，在每個(gè)數(shù)據(jù)中心部署一套或多套Zabbix軟件系統(tǒng)，Dubbo服務(wù)提供者調(diào)用Zabbix系統(tǒng)API實(shí)現(xiàn)監(jiān)控能力，Dubbo服務(wù)消費(fèi)者負(fù)責(zé)處理用戶請(qǐng)求，通過(guò)調(diào)用Dubbo服務(wù)提供者響應(yīng)請(qǐng)求，Dubbo服務(wù)消費(fèi)者和服務(wù)提供者都需要首先在服務(wù)注冊(cè)中心完成注冊(cè)。當(dāng)用戶通過(guò)portal訪問(wèn)某一機(jī)器的監(jiān)控信息時(shí)，需要根據(jù)區(qū)域標(biāo)識(shí)符來(lái)決定由哪個(gè)Zabbix服務(wù)器提供監(jiān)控源，從而引導(dǎo)用戶請(qǐng)求到對(duì)應(yīng)的Zabbix服務(wù)器。

 對(duì)于數(shù)據(jù)中心有一個(gè)或多個(gè)云平臺(tái)的情況，首先對(duì)OpenStack云平臺(tái)的監(jiān)控服務(wù)設(shè)置單獨(dú)的Dubbo服務(wù)提供者和服務(wù)消費(fèi)者，將Ceilometer API封裝為實(shí)現(xiàn)Dubbo服務(wù)提供者，用戶請(qǐng)求通過(guò)Dubbo的服務(wù)消費(fèi)者模式執(zhí)行。每增加一個(gè)OpenStack云平臺(tái)，新增相應(yīng)的Dubbo服務(wù)消費(fèi)者和服務(wù)提供者，從而實(shí)現(xiàn)對(duì)多個(gè)云平臺(tái)資源池的監(jiān)控。分布式監(jiān)控系統(tǒng)架構(gòu)如圖3所示。

 圖3描繪了兩個(gè)數(shù)據(jù)中心的場(chǎng)景，每個(gè)數(shù)據(jù)中心部署有一套OpenStack云平臺(tái)，虛擬機(jī)的監(jiān)控?cái)?shù)據(jù)由OpenStackCeilometer組件進(jìn)行采集和存儲(chǔ)。在每個(gè)數(shù)據(jù)中心部署一套Zabbix監(jiān)控系統(tǒng)，通過(guò)Zabbix agent采集服務(wù)器的運(yùn)行狀態(tài)。來(lái)自portal的用戶請(qǐng)求通過(guò)Dubbo層轉(zhuǎn)發(fā)到相應(yīng)的Zabbix服務(wù)器和云平臺(tái)，以獲取相應(yīng)的數(shù)據(jù)。

 數(shù)據(jù)中心之間可通過(guò)公網(wǎng)或者VPN進(jìn)行連接，網(wǎng)絡(luò)應(yīng)提供足夠的帶寬和質(zhì)量保障。系統(tǒng)對(duì)監(jiān)控?cái)?shù)據(jù)的處理主要在本數(shù)據(jù)中心完成，監(jiān)控?cái)?shù)據(jù)的采集分別由各自數(shù)據(jù)中心的Zabbix服務(wù)器和云平臺(tái)完成，Dubbo的服務(wù)消費(fèi)者和服務(wù)提供者負(fù)責(zé)將處理好的數(shù)據(jù)返回給portal。數(shù)據(jù)中心間僅傳送必要的數(shù)據(jù)和Dubbo控制的數(shù)據(jù)，大部分?jǐn)?shù)據(jù)流量限制在本地?cái)?shù)據(jù)中心。

 圖4是其中服務(wù)器th內(nèi)的監(jiān)控情況。

6  結(jié)束語(yǔ)

 本文提出了一種能夠支撐多數(shù)據(jù)中心IT資源統(tǒng)一監(jiān)控的系統(tǒng)，同時(shí)實(shí)現(xiàn)了云平臺(tái)環(huán)境下物理與虛擬資源的統(tǒng)一監(jiān)控。本文將監(jiān)控系統(tǒng)搭建在Dubbo架構(gòu)上，很好地解決了原來(lái)集中系統(tǒng)的性能問(wèn)題和管理分布式環(huán)境問(wèn)題。該系統(tǒng)已上線運(yùn)行，從結(jié)果上看符合設(shè)計(jì)目標(biāo)。該方案對(duì)于研究類(lèi)似的分布式集群調(diào)度系統(tǒng)具有重要的意義。