田 園，王 鋒，李 建，王 政，趙永恒

(1. 中國(guó)科學(xué)院光學(xué)天文重點(diǎn)實(shí)驗(yàn)室，國(guó)家天文臺(tái)，北京 100101; 2. 廣州大學(xué)，廣東 廣州 510006; 3. 中國(guó)科學(xué)院大學(xué)，北京 100049)

大天區(qū)面積多目標(biāo)光纖光譜天文望遠(yuǎn)鏡(Large Sky Area Multi-Object Fiber Spectroscopy Telescope, LAMOST)也叫郭守敬望遠(yuǎn)鏡，是一臺(tái)自主研發(fā)的主動(dòng)反射施密特裝置，兼顧大口徑與大視場(chǎng)，運(yùn)用并行控制技術(shù)使之可以同時(shí)跟蹤多達(dá)4 000個(gè)觀測(cè)目標(biāo)，是天文學(xué)界光譜獲取率最高的望遠(yuǎn)鏡[1]。郭守敬望遠(yuǎn)鏡于2008年10月正式落成，到目前為止，已觀測(cè)、生產(chǎn)和發(fā)布天文光譜超過(guò)900萬(wàn)條①http://dr5.lamost.org/。

郭守敬望遠(yuǎn)鏡設(shè)計(jì)新穎，結(jié)構(gòu)復(fù)雜，由觀測(cè)控制系統(tǒng)、主動(dòng)光學(xué)系統(tǒng)、巡天戰(zhàn)略系統(tǒng)、數(shù)據(jù)處理系統(tǒng)等8個(gè)子系統(tǒng)構(gòu)成。作為現(xiàn)代大型天文設(shè)備，每個(gè)子系統(tǒng)都離不開(kāi)計(jì)算機(jī)的控制。觀測(cè)期間，多達(dá)上百臺(tái)的計(jì)算機(jī)組成了一個(gè)龐大的計(jì)算機(jī)集群[2]。集群中的各計(jì)算機(jī)節(jié)點(diǎn)(尤其是關(guān)鍵節(jié)點(diǎn))的性能、效率和穩(wěn)定性等因素直接影響整個(gè)望遠(yuǎn)鏡的運(yùn)行效率。對(duì)集群中各節(jié)點(diǎn)計(jì)算機(jī)資源的監(jiān)視、預(yù)警和管理是一項(xiàng)繁重、困難但又必不可少的工作。

本文正是在這樣的背景下開(kāi)展相應(yīng)的研究工作，在深入分析工程環(huán)境和需求的基礎(chǔ)上，利用Python異步協(xié)程技術(shù)，設(shè)計(jì)和開(kāi)發(fā)了一套大型望遠(yuǎn)鏡計(jì)算機(jī)集群的硬件資源信息監(jiān)控系統(tǒng)，并部署于郭守敬望遠(yuǎn)鏡的工作環(huán)境。

1 需求分析與工具選擇

郭守敬望遠(yuǎn)鏡使用的計(jì)算機(jī)不僅數(shù)量眾多，而且計(jì)算機(jī)之間的軟硬件差異也十分明顯。在設(shè)備類(lèi)型方面，既有性能優(yōu)越的大型刀片服務(wù)器、工作站，又有適應(yīng)各種惡劣環(huán)境的工控機(jī)以及適合工作人員操作的臺(tái)式機(jī)。在分布位置方面，數(shù)據(jù)服務(wù)式計(jì)算機(jī)(如數(shù)據(jù)存儲(chǔ)服務(wù)器、數(shù)據(jù)傳輸設(shè)備等)安置于專(zhuān)業(yè)機(jī)房中，人機(jī)交互式臺(tái)式機(jī)安置于觀測(cè)控制室，硬件驅(qū)動(dòng)式計(jì)算機(jī)(如相機(jī)控制集群、機(jī)架焦面控制機(jī)等)安置于望遠(yuǎn)鏡主體建筑內(nèi)，輔助服務(wù)式計(jì)算機(jī)(如氣象站部分室外機(jī)等)則放置在室外。從操作系統(tǒng)分類(lèi)來(lái)講，目前集群中各節(jié)點(diǎn)計(jì)算機(jī)采用的操作系統(tǒng)包括了Windows系列、Linux(RedHat或Ubuntu)以及Apple MacOS等。

面對(duì)類(lèi)型眾多、位置復(fù)雜、操作系統(tǒng)異構(gòu)的大型望遠(yuǎn)鏡控制計(jì)算機(jī)集群，節(jié)點(diǎn)計(jì)算機(jī)的硬件資源信息監(jiān)視和管理工作完全由人工逐節(jié)點(diǎn)實(shí)現(xiàn)，不但工作效率低下，而且極容易出現(xiàn)錯(cuò)判漏判等情況，從而影響望遠(yuǎn)鏡的使用。

顯而易見(jiàn)，對(duì)于現(xiàn)代大型望遠(yuǎn)鏡，構(gòu)建一套硬件資源監(jiān)控系統(tǒng)完成對(duì)集群中各節(jié)點(diǎn)計(jì)算機(jī)的資源與狀況的采集、存儲(chǔ)、監(jiān)控和分析處理是非常重要的。

在工程領(lǐng)域，開(kāi)源的計(jì)算機(jī)集群資源監(jiān)控軟件主要有Cacti，Nagios，Zabbix等[3-5]，均在各種應(yīng)用領(lǐng)域起到了重要作用。但是，Cacti更傾向于單一的網(wǎng)絡(luò)資源監(jiān)視功能而不能全面地監(jiān)視各節(jié)點(diǎn)的狀態(tài)。Nagios和Zabbix均可以全面監(jiān)視各節(jié)點(diǎn)的資源狀態(tài)并且提供報(bào)警機(jī)制和插件模板等技術(shù)。但是由于是通用性資源監(jiān)視系統(tǒng)，兩者配置比較繁瑣，再開(kāi)發(fā)難度較大，難于整合到郭守敬望遠(yuǎn)鏡現(xiàn)有的觀測(cè)控制系統(tǒng)中。因此，基于工程需求，需要開(kāi)發(fā)一套適合郭守敬望遠(yuǎn)鏡的計(jì)算機(jī)集群資源監(jiān)視系統(tǒng)。

為了保證良好的可用性和穩(wěn)定性，硬件資源監(jiān)控系統(tǒng)應(yīng)采用分層方式設(shè)計(jì)和開(kāi)發(fā)。綜合考慮在實(shí)際工程環(huán)境中的諸多因素，系統(tǒng)應(yīng)分為信息采集與傳輸層、信息接收與處理層以及信息展示與應(yīng)用層。信息采集和傳輸層充分考慮節(jié)點(diǎn)之間的巨大差異，以及傳輸實(shí)現(xiàn)方式的統(tǒng)一性。信息接收和處理層具備較好的接收能力和穩(wěn)定的處理能力，并為上層應(yīng)用提供解耦的接口。信息展示和應(yīng)用層的功能應(yīng)該模塊化，從而達(dá)到人機(jī)交互的靈活性和友好性。整套系統(tǒng)還應(yīng)考慮運(yùn)行效率，不應(yīng)給各節(jié)點(diǎn)以及整個(gè)網(wǎng)絡(luò)帶來(lái)較大的負(fù)載。

另外，為了更好地服務(wù)于望遠(yuǎn)鏡的運(yùn)行，還應(yīng)考慮將軟件融入望遠(yuǎn)鏡的軟件體系中。目前望遠(yuǎn)鏡正在嘗試采用遠(yuǎn)程望遠(yuǎn)鏡系統(tǒng)第2版(Remote Telescope System 2nd version, RTS2)*http: / /rts2．org升級(jí)原有的觀測(cè)控制系統(tǒng)[7-8]。因此，資源監(jiān)控系統(tǒng)需要預(yù)留接口以供RTS2框架使用。

基于以上工程需求分析，結(jié)合望遠(yuǎn)鏡的實(shí)際工作環(huán)境，采用 “客戶(hù)端-服務(wù)器-應(yīng)用” 的架構(gòu)實(shí)現(xiàn)資源監(jiān)控系統(tǒng)。在編程語(yǔ)言方面，選擇通用性較強(qiáng)、跨平臺(tái)能力出眾的Python作為主題語(yǔ)言，并利用Python的標(biāo)準(zhǔn)庫(kù)(模塊)以及實(shí)現(xiàn)各種功能的第三方庫(kù)。

經(jīng)過(guò)充分調(diào)研和認(rèn)真篩選，文中主要涉及以下Python庫(kù)(模塊)的使用：

psutil模塊：能夠輕松實(shí)現(xiàn)獲取系統(tǒng)運(yùn)行的進(jìn)程和系統(tǒng)利用率(包括中央處理器、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)等)信息，主要應(yīng)用于系統(tǒng)監(jiān)控、分析和管理領(lǐng)域。

Python標(biāo)準(zhǔn)庫(kù)的asyncio模塊：支持異步協(xié)程。傳統(tǒng)服務(wù)器端的設(shè)計(jì)大多采用單進(jìn)程多路IO復(fù)用、多進(jìn)程(池)、多線程(池)等技術(shù)，這些技術(shù)對(duì)提升服務(wù)器端的響應(yīng)效率起到了積極的作用，但以上技術(shù)也有各自的限制和缺陷。例如：多路IO復(fù)用技術(shù)在編寫(xiě)大型服務(wù)器處理程序時(shí)過(guò)于復(fù)雜，不易維護(hù)；多進(jìn)程技術(shù)需要占用大量系統(tǒng)資源(占用內(nèi)存、進(jìn)程間上下文切換消耗等)，并且進(jìn)程間通信實(shí)現(xiàn)過(guò)程較復(fù)雜；多線程技術(shù)相對(duì)于多進(jìn)程技術(shù)消耗的系統(tǒng)資源較少，但是線程間同步、競(jìng)爭(zhēng)、死鎖等問(wèn)題給服務(wù)器設(shè)計(jì)帶來(lái)很大麻煩。協(xié)程是一種程序開(kāi)發(fā)人員可控的用戶(hù)態(tài)上下文切換技術(shù)，相比進(jìn)程、線程，協(xié)程更加輕量級(jí)且調(diào)度更加靈活，因此非常適合小數(shù)據(jù)量、邏輯簡(jiǎn)單、高并發(fā)的網(wǎng)絡(luò)通信環(huán)境。在Python中，協(xié)程屬于較新引入的概念。Python從3.4開(kāi)始支持協(xié)程，3.5引入?yún)f(xié)程關(guān)鍵字(async/await)和語(yǔ)法，同時(shí)提供了asyncio標(biāo)準(zhǔn)庫(kù)[注]https://docs.python.org/3/library/asyncio.html。

curio庫(kù)：對(duì)asyncio模塊的封裝庫(kù)，它進(jìn)一步隱藏了事件循環(huán)和復(fù)雜回調(diào)機(jī)制，還提供了Queue(用于協(xié)程間通信)、SingalQueue(用于系統(tǒng)信號(hào)處理)、run_in_process(用于子進(jìn)程調(diào)度)、run_in_thread(用于子線程調(diào)度)等開(kāi)發(fā)工具，從而使編寫(xiě)異步協(xié)程程序更加簡(jiǎn)潔安全。

PyZMQ庫(kù)：Python版的ZMQ通信庫(kù)。ZMQ基于標(biāo)準(zhǔn)socket，進(jìn)一步開(kāi)發(fā)了上層協(xié)議，提供了斷續(xù)重傳、負(fù)載均衡、發(fā)布/訂閱等高級(jí)接口，適合大型軟件組件間通信的解耦，使之更加穩(wěn)定。

aiomysql模塊：Python的異步MySQL數(shù)據(jù)庫(kù)接口模塊。它允許Python應(yīng)用程序與MySQL數(shù)據(jù)庫(kù)之間的異步數(shù)據(jù)交互，同時(shí)還提供了可配置的線程池，以提高數(shù)據(jù)庫(kù)的操作性能。

2 設(shè)計(jì)與實(shí)現(xiàn)

2.1 總體設(shè)計(jì)

郭守敬望遠(yuǎn)鏡資源監(jiān)控軟件系統(tǒng)總體分為3層：信息采集器(客戶(hù)端)、中央信息處理服務(wù)器以及上層應(yīng)用模塊，如圖1。

圖1 郭守敬望遠(yuǎn)鏡資源監(jiān)控系統(tǒng)總體框架
Fig.1 The framework of Monitoring System for LAMOST resource

部署在郭守敬望遠(yuǎn)鏡計(jì)算機(jī)集群各節(jié)點(diǎn)計(jì)算機(jī)上的信息采集器(客戶(hù)端)根據(jù)默認(rèn)設(shè)置和配置文件確定信息采集間隔時(shí)間以及本節(jié)點(diǎn)需要采集的具體信息內(nèi)容后，周期性地采集本節(jié)點(diǎn)硬件資源信息并發(fā)送給中央信息處理服務(wù)器。

中央信息處理服務(wù)器接收眾多客戶(hù)端發(fā)來(lái)的信息，進(jìn)行信息處理(如數(shù)據(jù)驗(yàn)證、數(shù)據(jù)分析、數(shù)據(jù)存儲(chǔ)等)，并通過(guò)自身的服務(wù)接口向上層應(yīng)用模塊提供數(shù)據(jù)服務(wù)。

上層應(yīng)用模塊可以有多個(gè)，分別實(shí)現(xiàn)不同的功能(如圖形界面人機(jī)交互、網(wǎng)頁(yè)顯示、接入觀測(cè)控制系統(tǒng)、數(shù)據(jù)詳細(xì)分析統(tǒng)計(jì)等)。它們均通過(guò)中央信息服務(wù)器的數(shù)據(jù)提供接口獲取數(shù)據(jù)，然后這些數(shù)據(jù)完成自己的工作。

應(yīng)用模塊和中央信息處理服務(wù)器相互獨(dú)立，不規(guī)定啟動(dòng)先后順序，也不需要在同一臺(tái)電腦上運(yùn)行，最大程度地實(shí)現(xiàn)系統(tǒng)解耦，從而提高系統(tǒng)的穩(wěn)定性和可用性。

2.2 客戶(hù)端

客戶(hù)端主要責(zé)任是周期性采集節(jié)點(diǎn)系統(tǒng)的資源信息，將信息發(fā)送給服務(wù)器。

考慮代碼的簡(jiǎn)潔性和易維護(hù)性，選取Python的psutil包進(jìn)行信息采集。絕大多數(shù)節(jié)點(diǎn)計(jì)算機(jī)的操作系統(tǒng)自帶Python解釋器以及相應(yīng)包。對(duì)于未安裝psutil包的節(jié)點(diǎn)采用pip安裝或源碼安裝也十分簡(jiǎn)易。極個(gè)別節(jié)點(diǎn)無(wú)法安裝Python，則采用C語(yǔ)言調(diào)用原生系統(tǒng)庫(kù)接口獲取信息。以下代碼為客戶(hù)端采用psutil包獲取系統(tǒng)資源的部分代碼。

import psutil as ps… …cpu=ps.cpu_percent(interval=60)#獲取CPU使用率,周期60秒mem=ps.virtual_memory()#獲取內(nèi)存使用率disk=ps.disk_usage(‘/’)#獲取掛載點(diǎn)‘/’所對(duì)應(yīng)磁盤(pán)分區(qū)使用情況nic_in=ps.net_io_counters().bytes_recv#獲取網(wǎng)卡接收字節(jié)數(shù)nic_out=ps.net_io_counters().bytes_sent#獲取網(wǎng)卡發(fā)送字節(jié)數(shù)… …#獲取進(jìn)程列表

為保證信息傳輸?shù)耐ㄓ眯圆⒈M量避免在各節(jié)點(diǎn)計(jì)算機(jī)上安裝額外軟件庫(kù)或包，客戶(hù)端信息發(fā)送采用標(biāo)準(zhǔn)的TCP通信協(xié)議，通信功能采用Python實(shí)現(xiàn)：設(shè)置錯(cuò)誤容忍閾值，將采集信息和發(fā)送信息功能包裹在循環(huán)體中。出現(xiàn)通信故障時(shí)捕獲異常錯(cuò)誤計(jì)數(shù)器自增1，若錯(cuò)誤計(jì)數(shù)器未到閾值則休眠指定時(shí)間后重新循環(huán)，若已到達(dá)閾值則結(jié)束程序釋放系統(tǒng)資源。

2.3 服務(wù)器

中央信息處理服務(wù)器是整套系統(tǒng)的樞紐，主要任務(wù)有兩個(gè)：(1)接收大量客戶(hù)端周期性發(fā)來(lái)的資源信息；(2)對(duì)信息進(jìn)行處理后存入MySQL數(shù)據(jù)庫(kù)。因此，對(duì)其運(yùn)行效率和穩(wěn)定性要求很高。為了使設(shè)計(jì)思路清晰、實(shí)現(xiàn)代碼簡(jiǎn)潔，實(shí)際方案采用了兩個(gè)子進(jìn)程，分別為異步消息接收器子進(jìn)程和MySQL異步處理器子進(jìn)程。中央信息處理服務(wù)器內(nèi)部結(jié)構(gòu)如圖2。

圖2 中央信息處理服務(wù)器內(nèi)部結(jié)構(gòu)
Fig.2 The internal structure of the central message handle server

異步消息接收器子進(jìn)程內(nèi)部包含TCP-Server協(xié)程和ZMQ.PUB協(xié)程。TCP-Server協(xié)程負(fù)責(zé)處理節(jié)點(diǎn)采集器(客戶(hù)端)的TCP連接申請(qǐng)以及并發(fā)地接收多客戶(hù)端發(fā)來(lái)的消息。ZMQ.PUB協(xié)程負(fù)責(zé)將接收的消息發(fā)布到消息總線上，以供上層應(yīng)用模塊使用。兩者之間采用curio庫(kù)的Queue實(shí)現(xiàn)單線程內(nèi)不同協(xié)程之間的異步通信，整個(gè)子進(jìn)程由curio庫(kù)事件循環(huán)驅(qū)動(dòng)。

MySQL異步處理器子進(jìn)程內(nèi)部包含ZMQ.SUB協(xié)程和aiomysql協(xié)程。ZMQ.SUB協(xié)程負(fù)責(zé)向消息總線訂閱并獲取消息。aiomysql協(xié)程負(fù)責(zé)將消息異步地存儲(chǔ)到MySQL數(shù)據(jù)庫(kù)。由于aiomysql模塊必須采用標(biāo)準(zhǔn)的Python.asyncio事件循環(huán)驅(qū)動(dòng)(curio庫(kù)目前尚未直接提供aiomysql模塊接口)，而Python.asyncio事件循環(huán)本身必須獨(dú)占一個(gè)線程，因此程序在實(shí)現(xiàn)過(guò)程中需要為aiomysql協(xié)程創(chuàng)立獨(dú)立的子線程。兩者之間采用curio庫(kù)的Universal Queue實(shí)現(xiàn)異步通信。與異步消息接收器中使用的Queue不同，curio庫(kù)提供的Universal Queue可以解決分屬于多個(gè)線程的不同協(xié)程之間的異步通信問(wèn)題。整個(gè)子進(jìn)程由curio庫(kù)事件循環(huán)驅(qū)動(dòng)。

此外，中央信息處理服務(wù)器采用ZMQ的發(fā)布/訂閱機(jī)制組建消息總線，實(shí)現(xiàn)對(duì)上層應(yīng)用模塊提供數(shù)據(jù)的功能。ZMQ.PUB端口用于發(fā)布消息，可以有任意數(shù)量的ZMQ.SUB端口用于訂閱和接收消息。ZMQ.PUB和ZMQ.SUB無(wú)需在同一計(jì)算機(jī)上部署，且運(yùn)行互不干擾。由于ZMQ以上優(yōu)點(diǎn)，極大地簡(jiǎn)化了服務(wù)接口層的開(kāi)發(fā)難度，實(shí)現(xiàn)了中央信息處理服務(wù)器與各應(yīng)用模塊之間的完全解耦。

中央信息處理服務(wù)器內(nèi)部組件時(shí)序如圖3。由于組件均為協(xié)程，組件間均采用異步方式通信，協(xié)程邏輯執(zhí)行與上下文切換由用戶(hù)精確控制，因此在不占用更多操作系統(tǒng)資源的前提下，極大地提高了服務(wù)器的并行處理能力和數(shù)據(jù)的吞吐量。

圖3 中央信息處理服務(wù)器內(nèi)部時(shí)序圖
Fig.3 The internal sequence diagram of the central message handle server

實(shí)際運(yùn)行中，中央信息處理服務(wù)器采用Linux后臺(tái)守護(hù)進(jìn)程方式運(yùn)行，并設(shè)置為開(kāi)機(jī)自啟動(dòng)，從而保證了程序運(yùn)行更加穩(wěn)定和高效。

2.4 應(yīng)用模塊

應(yīng)用模塊主要負(fù)責(zé)數(shù)據(jù)的應(yīng)用與展示。資源監(jiān)控系統(tǒng)允許運(yùn)行多個(gè)相互獨(dú)立的應(yīng)用模塊完成不同的功能。由于ZMQ消息總線的應(yīng)用，使中央信息處理服務(wù)器與應(yīng)用模塊之間徹底解耦，因此，極大地降低了各種應(yīng)用模塊的開(kāi)發(fā)難度。

根據(jù)工程需求，目前資源監(jiān)控系統(tǒng)提供3種應(yīng)用模塊：基于PyQt的圖形界面模塊、基于RTS2系統(tǒng)的傳感器設(shè)備(Rts2-sensord)模塊和基于Django的網(wǎng)站服務(wù)模塊。

圖4為本機(jī)圖形界面模塊運(yùn)行截圖。圖形界面實(shí)時(shí)顯示各節(jié)點(diǎn)計(jì)算機(jī)的資源信息并以顏色進(jìn)度條的方式為運(yùn)維工程師提供資源占用情況。圖4中，01號(hào)和02號(hào)CCD計(jì)算機(jī)的硬盤(pán)占用率超過(guò)80%，因此，圖形界面相應(yīng)節(jié)點(diǎn)子界面的硬盤(pán)進(jìn)度條變成紅色，以提醒觀測(cè)者注意，從而達(dá)到預(yù)警的效果。

圖4 圖形界面模塊截圖
Fig.4 The screenshot of GUI module

資源監(jiān)控系統(tǒng)為RTS2框架預(yù)留了傳感器模塊RTS2-Sensord。將其接入RTS2系統(tǒng)后，RTS2系統(tǒng)便可以收到資源預(yù)警信息。圖5是RTS2系統(tǒng)監(jiān)視器收到預(yù)警信息的截圖。

圖5 RTS2系統(tǒng)監(jiān)視器截圖
Fig.5 The screenshot of RTS2 monitor

架設(shè)于郭守敬望遠(yuǎn)鏡內(nèi)網(wǎng)中的網(wǎng)站模塊提供網(wǎng)頁(yè)瀏覽查詢(xún)服務(wù)，允許觀測(cè)者和運(yùn)維工程師在內(nèi)網(wǎng)中的計(jì)算機(jī)上通過(guò)瀏覽器查詢(xún)各節(jié)點(diǎn)資源的信息數(shù)據(jù)。圖6為01號(hào)CCD計(jì)算機(jī)的資源信息頁(yè)面。其中上半部分以曲線圖的方式顯示了該節(jié)點(diǎn)計(jì)算機(jī)各種資源信息的歷史記錄和趨勢(shì)，并以可設(shè)置虛線的形式提供預(yù)警功能。下半部分為該節(jié)點(diǎn)的信息列表，表中分別顯示了信息采集時(shí)間(timestamp)、中央處理器使用率、內(nèi)存占用率(memory_percent)、硬盤(pán)使用率(disk_percent)、網(wǎng)絡(luò)下行速度(nic_in)、網(wǎng)絡(luò)上行速度(nic_out)等信息。

圖6 網(wǎng)頁(yè)服務(wù)
Fig.6 Web Service

3 討 論

3.1 系統(tǒng)自身開(kāi)銷(xiāo)與網(wǎng)絡(luò)負(fù)載

資源監(jiān)控系統(tǒng)軟件運(yùn)行自身也需要消耗部分系統(tǒng)資源，因此在軟件設(shè)計(jì)和開(kāi)發(fā)過(guò)程中，在保證可用性的前提下應(yīng)建立簡(jiǎn)化和優(yōu)化的代碼。將資源監(jiān)控系統(tǒng)部署在實(shí)際工程環(huán)境中，實(shí)際運(yùn)行測(cè)試結(jié)果如下：

節(jié)點(diǎn)消息采集器(客戶(hù)端)資源消耗：CPU占用不超過(guò)0.2%，內(nèi)存不超過(guò)4 KB。

中央信息處理服務(wù)器資源消耗：CPU不超過(guò)0.5%，內(nèi)存不超過(guò)40 MB。

可見(jiàn)，本系統(tǒng)不會(huì)對(duì)節(jié)點(diǎn)計(jì)算機(jī)和中央信息服務(wù)器產(chǎn)生過(guò)大的資源消耗。

而網(wǎng)絡(luò)傳輸方面，目前單節(jié)點(diǎn)信息采集器產(chǎn)生的信息以字符串形式傳輸，單條信息不超過(guò)128個(gè)字節(jié)，信息采集周期默認(rèn)值為10 s。因此，100個(gè)節(jié)點(diǎn)采集器每秒產(chǎn)生的信息大小不超過(guò)1 280字節(jié)，即整個(gè)系統(tǒng)對(duì)內(nèi)網(wǎng)的帶寬占用不超過(guò)1.25 KBps。未來(lái)，如果由于單節(jié)點(diǎn)信息量增多或系統(tǒng)總節(jié)點(diǎn)數(shù)增加導(dǎo)致網(wǎng)絡(luò)帶寬占用過(guò)多，可以考慮放棄字符串采用二進(jìn)制數(shù)據(jù)傳輸。

因此，郭守敬望遠(yuǎn)鏡資源監(jiān)控系統(tǒng)無(wú)論是在自身資源消耗還是網(wǎng)絡(luò)負(fù)載方面，都符合當(dāng)前的工程需求。

3.2 網(wǎng)絡(luò)通信架構(gòu)：集中式與分布式的選擇

目前，網(wǎng)絡(luò)通信主流架構(gòu)主要分為集中式設(shè)計(jì)和分布式設(shè)計(jì)兩大類(lèi)。集中式設(shè)計(jì)需要有強(qiáng)大健壯的中央服務(wù)器作為整個(gè)通信系統(tǒng)的樞紐，優(yōu)點(diǎn)是技術(shù)成熟，且便于管理和維護(hù)，缺點(diǎn)是依賴(lài)于中央服務(wù)器的穩(wěn)定性和處理能力。而分布式則是信息或功能分散在不同的計(jì)算機(jī)上，節(jié)點(diǎn)間協(xié)作共同完成任務(wù)，因此對(duì)每臺(tái)計(jì)算機(jī)的性能要求不高，優(yōu)點(diǎn)是可以極大地降低服務(wù)器的成本，缺點(diǎn)是程序設(shè)計(jì)更復(fù)雜，協(xié)作通信量增加。

具體到本項(xiàng)目，雖然涉及到集群中的計(jì)算機(jī)數(shù)量眾多，但通信量和數(shù)據(jù)處理量均很小，因此選擇集中式設(shè)計(jì)，即 “客戶(hù)端-服務(wù)器-應(yīng)用” 模式作為整體架構(gòu)更為合理，從而避免了分布式中的數(shù)據(jù)同步等問(wèn)題，降低開(kāi)發(fā)和維護(hù)難度。

3.3 客戶(hù)端與服務(wù)器之間通信協(xié)議的選擇

在采集到信息之后，客戶(hù)端需要通過(guò)網(wǎng)絡(luò)將信息發(fā)送給服務(wù)器。網(wǎng)絡(luò)信息傳輸?shù)膶?shí)現(xiàn)可以選擇，例如：UDP傳輸、TCP傳輸、ACE通信庫(kù)、ZMQ通信庫(kù)等。采用UDP通信可靠性相對(duì)較差，因此暫不考慮。而ACE通信庫(kù)是一套完善的C++通信庫(kù)，它完全采用面向?qū)ο笤O(shè)計(jì)，支持和采用多種設(shè)計(jì)模式。但是由于過(guò)于龐大復(fù)雜且開(kāi)發(fā)維護(hù)難度很高，因此并不適合本文提到的實(shí)際工程需求。采用ZMQ通信方式(見(jiàn)服務(wù)器內(nèi)部通信實(shí)現(xiàn)章節(jié))雖然使用方便靈活，但是需要在各個(gè)客戶(hù)端安裝ZMQ庫(kù)。如前文所述，各個(gè)節(jié)點(diǎn)硬件設(shè)備差異較大，操作系統(tǒng)種類(lèi)繁多，如果根據(jù)各節(jié)點(diǎn)軟硬件配置選擇相應(yīng)版本的ZMQ庫(kù)并進(jìn)行安裝，不但工作量巨大、可操作性很差，而且不利于今后設(shè)備更新和擴(kuò)展。而TCP傳輸作為最常見(jiàn)的底層通信協(xié)議，各種操作系統(tǒng)均自帶實(shí)現(xiàn)庫(kù)，無(wú)需再自行安裝配置。因此，客戶(hù)端與服務(wù)器之間的通信采用TCP通信協(xié)議。

3.4 系統(tǒng)的預(yù)警和分析處理功能擴(kuò)展

郭守敬望遠(yuǎn)鏡資源監(jiān)控系統(tǒng)已初步完成，部署于實(shí)際工程環(huán)境中能夠準(zhǔn)確有效地采集和存儲(chǔ)集群中各節(jié)點(diǎn)計(jì)算機(jī)資源的信息數(shù)據(jù)。但仍有以下兩方面的不足：

(1)在人機(jī)交互預(yù)警方面，如2.4節(jié)所述，目前通過(guò)本機(jī)圖形界面資源條顏色(綠、藍(lán)、紅)變化，以及網(wǎng)頁(yè)預(yù)警線的方式為工作人員提供最基本的提醒功能。未來(lái)可以借鑒Zabbix系統(tǒng)的實(shí)現(xiàn)思路，根據(jù)預(yù)警信息類(lèi)型或錯(cuò)誤等級(jí)為工作人員提供郵件推送、微信消息等功能，從而進(jìn)一步提高系統(tǒng)的友好性。

(2)已存儲(chǔ)的資源信息數(shù)據(jù)的后期分析、統(tǒng)計(jì)和處理功能目前尚未完成。主要原因在于該功能需要不斷積累大型望遠(yuǎn)鏡運(yùn)行維護(hù)經(jīng)驗(yàn)。

不過(guò)，由于服務(wù)器內(nèi)部采用了基于發(fā)布/訂閱機(jī)制的ZMQ消息總線技術(shù)，使預(yù)警組件和數(shù)據(jù)分析處理組件與整個(gè)軟件框架完全解耦，極大地降低了進(jìn)一步開(kāi)發(fā)的技術(shù)難度，因此，資源監(jiān)控系統(tǒng)會(huì)不斷完善，最終為望遠(yuǎn)鏡高效運(yùn)行提供有力的保障。

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

郭守敬望遠(yuǎn)鏡是由我國(guó)自主研發(fā)的目前世界上光譜獲取率最高的大型天文望遠(yuǎn)鏡，其內(nèi)部管理與控制計(jì)算機(jī)龐大、節(jié)點(diǎn)眾多、種類(lèi)繁雜，本系統(tǒng)的設(shè)計(jì)，實(shí)時(shí)采集、存儲(chǔ)和分析各節(jié)點(diǎn)計(jì)算機(jī)硬件資源信息，有效地提高望遠(yuǎn)鏡的運(yùn)行穩(wěn)定性和觀測(cè)效率。系統(tǒng)運(yùn)行表明，本系統(tǒng)的設(shè)計(jì)與研發(fā)是成功的，同時(shí)這樣的模式也為其他大型望遠(yuǎn)鏡的觀測(cè)控制與后期維護(hù)提供有價(jià)值的參考。