基于Python協(xié)程技術(shù)的LAMOST控制節(jié)點分布狀態(tài)采集與監(jiān)視系統(tǒng)*

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

(1. 中國科學院光學天文重點實驗室，國家天文臺，北京 100101; 2. 廣州大學，廣東 廣州 510006; 3. 中國科學院大學，北京 100049)

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

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

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

1 需求分析與工具選擇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 總體設(shè)計

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

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

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

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

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

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

2.2 客戶端

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

考慮代碼的簡潔性和易維護性，選取Python的psutil包進行信息采集。絕大多數(shù)節(jié)點計算機的操作系統(tǒng)自帶Python解釋器以及相應(yīng)包。對于未安裝psutil包的節(jié)點采用pip安裝或源碼安裝也十分簡易。極個別節(jié)點無法安裝Python，則采用C語言調(diào)用原生系統(tǒng)庫接口獲取信息。以下代碼為客戶端采用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(‘/’)#獲取掛載點‘/’所對應(yīng)磁盤分區(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ù)… …#獲取進程列表

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

2.3 服務(wù)器

中央信息處理服務(wù)器是整套系統(tǒng)的樞紐，主要任務(wù)有兩個：(1)接收大量客戶端周期性發(fā)來的資源信息；(2)對信息進行處理后存入MySQL數(shù)據(jù)庫。因此，對其運行效率和穩(wěn)定性要求很高。為了使設(shè)計思路清晰、實現(xiàn)代碼簡潔，實際方案采用了兩個子進程，分別為異步消息接收器子進程和MySQL異步處理器子進程。中央信息處理服務(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

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

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

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

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

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

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

2.4 應(yīng)用模塊

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

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

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

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

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

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

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

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

3 討 論

3.1 系統(tǒng)自身開銷與網(wǎng)絡(luò)負載

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)束語

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