基于樹莓派的高校中心機房綜合環境監測系統的研究與設計

劉 磊，江永旭，劉慶俞

數據中心是高校信息化建設的核心基礎設施，其對所處機房環境的安全性與穩定性要求極高［1-2］，而機房環境監測系統作為一種基于傳感器實現對機房環境狀態的實時監測方案，在保障機房的安全運行方面發揮著重要作用.

近些年，各類成熟的企業級機房環境監測方案被紛紛推出，這些方案多采用分層框架構建，終端部分由數據接入設備和環境傳感器組成，并通過網絡將數據傳輸給系統總業務服務器處理［3-4］.例如，深圳鯤鵬公司推出的智能化機房動力環境監控報警系統［5］，能夠提供包含自然環境、動力、安保、網絡、報警等在內的多方位安全防范服務.南寧邁世公司的一體化智能監控系統OM-ZKM［6］，通過配置特定的外圍傳感器，能夠提供高可靠性、高度適用性的環境監測解決方案，此外，系統提供的智能化預警功能，能夠實現對故障的快速反應能力及實時預警評估.這些企業級機房環境監測方案，能夠為用戶提供穩定、高效且專業的機房運維保障，但也存在部署復雜、功能使用率低和成本高昂等問題，不適合中小型用戶使用.

為了滿足中小型用戶對機房實時環境監測及實時告警兩大核心功能的業務需求，本文在系統的軟/硬件架構設計實現方面均采用輕量化方案構建.其中，硬件架構采用樹莓派［7］（Raspberry pi）及以通用輸入/輸出接口［8］（General Purpose Input Output，GPIO）通信的環境傳感器作為系統的硬件載體，構建一種由數據匯總處理單元、數據接入單元及傳感器組成的三層系統架構，能夠較好地實現對機房多種環境數據的實時在線監測及處理.同時，樹莓派良好的軟/硬件性能，可以滿足用戶對數據可視化及實時報警等業務的功能需求.此外，這種硬件構建方案能夠極大地降低系統成本，且通過設計數據接入單元的輕量化傳感器介入管理流程，能夠實現系統對環境監測范圍的靈活擴展.而在軟件架構設計實現方面，本文設計的原型系統以Python 腳本語言實現，Python 在GPIO 數據處理、Web 應用框架及信息通信框架等方面均具有豐富的第三方開發庫支持，能夠為系統的實現提供輕量化的構建選擇.同時，系統部署方式采用虛擬化容器技術Docker［9-10］進行封裝，具有易實現、易部署及跨平臺等特點.

1 方案總體設計

1.1 術語定義

①DCN（Data Collection Node）：數據采集節點.

②DTN（Data Total Node）：數據匯總節點.

③Sensor_table：DCN 傳感器端口配置列表.

④Sersor_data：DCN 環境數據匯總信息.

⑤Node_table：DCN 信息列表.

⑥Data_table：環境數據匯總信息列表.

1.2 方案架構設計

如圖1 所示，系統以樹莓派和傳感器構建三層結構的硬件框架，其中，數據匯總節點和數據采集節點均由樹莓派承擔.框架的最下層終端部分由傳感器組成，傳感器與DCN 間通過GPIO 接口相連；DCN 主要負責匯總傳感器采集的環境數據并封裝后傳輸給DTN；DTN主要負責匯總并分析各DCN 傳輸來的數據，同時承擔系統的安全告警及數據發布等相關業務功能.

圖1 系統框架圖

針對上述系統框架，本文設計的業務功能模塊包括：數據采集模塊，數據匯總模塊、系統告警模塊、數據可視化模塊及Web 發布模塊.系統的業務處理流程主要集中于數據采集模塊和數據匯總模塊.

1.3 數據采集模塊

數據采集模塊是DCN 的核心功能模塊，主要實現匯總DCN 接入的傳感器采集數據及向DTN 傳輸數據的功能.DCN 由一個樹莓派和多個環境傳感器組成，樹莓派和傳感器間通過GPIO 接口進行數據傳輸.GPIO 是一種通用輸入/輸出接口，具有低功耗、小封裝和低成本等優點，通過配置可設定端口為輸入模式或輸出模式.如圖2 所示，左側部分為樹莓派實物圖，右側部分為樹莓派自帶的一組GPIO 接口，最多同時支持14 個GPIO 數據的輸入/輸出.

圖2 樹莓派GPIO 接口圖

如圖3 所示，本文針對機房的環境監測主要涉及溫濕度、火災、水浸及電源等方面，采用的傳感器包括溫濕度傳感器（DHT11）、煙霧傳感器（MQ-2）、水滴傳感器（MH-RD）、紅外傳感器（HC-SR501）和霍爾電流傳感器（QBC-ECS5）.其中，溫濕度傳感器（DHT11）是一種一體式環境傳感器，能夠同時監測環境的溫度和濕度.上述所列傳感器均支持GPIO 接口數據傳輸，一些傳感器僅支持模擬信號，可通過數模轉換器轉換為數字信號.一臺樹莓派理論上可同時最多支持14 個GPIO的數據接入，但考慮數據傳輸及處理效率和實際安裝等影響因素，本方案設定一臺樹莓派配置傳感器數量上限為6 個，同類型傳感器數量上限為3 個，均可配置連接上述5 類傳感器.DCN 通過維護Sensor_table{Id，Type，Port}來管理傳感器的端口接入配置信息.其中，Id 為傳感器編號，具有唯一性；Type 為傳感器類型編號；Port 為傳感器對應樹莓派的GPIO 端口號.DCN 會對采集到的環境數據進行封裝，生成一 條Sersor_data{Id，Ip，Time，Temperature_list，Humidity_list，Smoke_list，Water_list，Infrared_list，Electric_list}.其中，Id 為DCN 的編號，具有唯一性；Ip 為DNC 的網絡地址；Time 為數據采集時間；Temperature_list、Humidity_list、Smoke_list、Water_list、Infrared_list 及Electric_list 分 別 為 各類傳感器的采集數據列表，每個列表包含3 個同類數據，分別對應DNC 接入的同類型傳感器的采集數據，無傳感器接入時對應列表數據項設置為空值（Null）.

圖3 傳感器實物圖

DCN 數據采集流程如下：

Step1.DCN 初始化系統，設定數據采集周期T；

Step2.DCN 根 據Sensor_table 中的Type 分 別對GPIO 端口進行端口的輸入/輸出模式配置；

Step3.DCN 在一個T內，以順序方式讀取接入傳感器的采集數據.具體根據Sensor_table 中 的Type 調 用Get_Signal（Type，Port）函 數進行讀取；

Step4.DCN 匯總所有傳感器數據，生成Sensor_data.

基于Python 編程語言的GPIO 類庫一般采用Rpi.GPIO，能夠滿足多種傳感器接入，通過簡單配置端口模式及添加事件響應函數即可完成對傳感器的參數配置，從而實現對數據的讀寫.此外，Adafruit 等類庫也能夠對GPIO提供支持，但支持接入的傳感器種類較少.

DCN 讀取傳感器數據分為輪詢式（Polling）和中斷式（Interrupt）兩種.其中，輪詢式是DCN以固定采集周期T通過主動形式順序讀取傳感器數據；中斷式則是傳感器根據各自數據采集周期t采集數據后，以終端請求形式向DCN 傳輸數據.由于每個傳感器的t不同，若DCN 采用輪詢式，則可能會在一個T內錯過某個傳感器的數據采集行為，因此本文采用中斷式方式.同時，為了避免DCN 對傳感器GPIO 引腳電平狀態變化的監測，可通過Rpi.GPIO 庫中的wait_for_edge（）和event_detected（）兩個函數進行配置.其中，wait_for_edge（）函數會中斷主程序的執行，直到檢測到狀態變化為止.event_detected（）函數則會啟用一個子線程，通過在子線程中啟用一個主循環監聽傳感器狀態變化并設置回調函數實現立即響應.

1.4 數據匯總模塊

數據匯總模塊是DTN 的核心功能模塊，主要負責管理DCN，并匯總從DCN 獲取的環境數據.DTN 采用SQLite 作為數據庫，SQLite是一種輕量化關系型數據庫，也是一種內存式數據庫，具有高可靠性、低配置性、去服務器化及跨平臺等特點，其對硬件較低的配置要求使得采用樹莓派承擔DTN 的各項業務成為可能.DTN 主要維護的數據表包括Node_table 和數據信息表Data_table.其中，Node_table{Id，Ip，Time，Location}負責保存DTN 當前接入的DCN 信 息，Id 為DCN 的 編 號，Ip 為DCN 的網絡地址，Time 為DCN 的接入時間，Location為DCN 的位置標識.Data_table 與DCN 中的Sersor_data 結構相同，用于存儲從各DCN 采集到的環境數據.

由于每個DCN 接入的傳感器種類及個數不相同，且各類傳感器的數據采集周期t不一致，使得各DCN 的采集周期T也不相同.對此，本文設計了兩種數據匯總算法滿足DTN的數據匯總需求，分別為主動輪詢算法和被動插入算法.兩者的區別在于：主動輪詢算法以DTN 為總調度節點，通過DTN 主動向各DCN發送調度指令協調數據的匯總流程；被動插入算法則是以各DCN 為獨立數據匯總單元，彼此間無聯系，系統沒有統一的調度節點，DCN 以各自的T為周期采集到數據后直接插入到DTN 的數據庫中.由于被動插入算法中，對DCN 采用自主式管理，數據匯總流程較為簡單，本文僅對主動輪詢算法展開介紹，具體如下：

Step1.DTN 初始化系統，設定數據匯總周期T′；

Step2.DTN 以T′為周期，根據Node_table 順序向各接入DCN 發送數據采集指令；

Step3.DCN 接收到指定后，以各自的T采集數據并生成一條Sensor_data，將其回傳給DTN；

Step4.DTN 匯總所有DCN 的回傳數據，統一整理后插入Data_table.

由于DCN 對于接入傳感器均采用中斷式數據采集方法，為了確保在一個T′內完成對所有DCN 的數據匯總，需要將DTN 的匯總周期設置大于各DCN 的數據采集周期T，即T′>T{T1，T2，…，Tn}，本文在實際測試結果基礎上，建議將T′設置為5 s.由上可知，主動輪詢算法需要通過DTN 統一協調各DCN 順序執行數據采集，這勢必會增加算法的流程復雜度和額外的數據通信流量.例如，需要增加Socket 通信模塊傳輸DTN 指令信息和DCN 狀態信息.而被動插入算法則是DCN 直連DTN上的系統數據庫，并將采集到的數據直接插入數據庫中，這種獨立匯總模式極大地簡化了算法流程，但也存在導致數據庫中匯總的采集數據在時間上無序，不利于DTN 對數據的統一管理和分析的問題.兩種算法各有優缺點，由于本系統還包括告警及數據分析等功能，對于數據的匯總質量要求較高，因此本文采用主動輪詢算法.

為了提升系統的高擴展性和靈活性，DTN對DCN 采用動態管理機制，通過DTN 定期監測DCN 連通性的方式，實現系統對DCN 的無感知擴展.具體做法為：新增DCN 時，在完成網絡環境配置后，由DCN 主動向Node_table 中添加一條數據，DTN 在每次采集數據前根據Node_table 檢測各DCN 的連通性，若網絡不可達，則在Node_table 中直接刪除對應條目.而移除DCN 時，可直接將DCN 斷開網絡，DTN 無需調整任何配置.

1.5 其他功能模塊

系統告警模塊.系統設計的告警模塊用以實現對異常環境狀態的告警.參考《計算機場地技術條件》國家標準GB2887-89 及《中華人民共和國通信行業標準》YD/T1821-2008 等文件中對中心機房環境條件具體要求，系統對機房溫度、濕度等數值參數及煙感、水滴、電流等狀態參數設定了合理的閥值，一旦系統監測到環境狀態超過預定閥值就會觸發告警機制.本文消息告警方式包括消息盒子、短信和郵件三種，其中，消息盒子方式是在系統的Web 開發框架中設計實現的；短信方式采用騰訊云短信接口實現，對應的Python 第三方功能庫為qcloudsms；郵件方式則采用基于Flask 框架的異步郵件發送機制實現，對應的Python 第三方功能庫為flask_mail.

數據可視化模塊.系統在Web 前端采用數據可視化技術對數據進行展示，展示內容包括環境數據及CTN 硬件狀態信息：CPU 占用率、內存占用率及硬盤占用率.其中，獲取CTN 硬件狀態信息采用Python 第三方功能庫psutil.在Web 前端數據可視化方面，可通過d3、highlight、echarts 等基于Javascript 的圖表庫實現.其中，百度開源輕量級圖表庫echarts 以其可以在PC 和移動設備上流暢運行、兼容當前絕大部分瀏覽器（IE8/9/10/11，Chrome，Firefox，Safari 等），以及底層依賴輕量級的Canvas 類庫zrender 等優點，能夠提供直觀、生動、可交互、可高度個性化定制的數據可視化圖表.因此，本文采用echarts 實現對環境數據的可視化展示.

Web 發布模塊.基于Python 的Web 開發框架以django 和flask 為代表.其中，django 是一套完整的Web 框架，在模板設計、網站管理、安全性及處理重負載方面表現突出，適用于需要大量功能的大型項目.而flask 則是一種輕量級Web 框架，核心簡化且配置簡單靈活，能夠通過豐富的功能庫和插件快速的實現功能擴展，適用于功能相對單一但業務需求多變的應用場景.由于本文設計的環境監測系統業務相對簡單、用戶并發量小，并且采用樹莓派作為Web 發布的硬件載體，硬件性能受限等原因，因此，采用flask 作為Web 開發框架.

2 系統實現與性能分析

本文采用Docker 技術進行系統部署配置，以滿足系統對輕量化部署及高擴展性的需求.Docker 是一種虛擬容器技術，采用分層存數和鏡像技術，使得應用重復部分的復用操作更為容易，也極大的簡化了應用的維護更新，Docker 允許開發者將應用及運行依賴包打包到一個輕量級、可移植的容器中，并能夠發布到包括物理機、虛擬機、公有云、私有云、個人電腦、服務器等平臺，且能夠實現平臺間的無縫遷移.因此，通過Docker 技術不僅能夠滿足本文設計的環境監測系統對DCN 的靈活擴展需求，同時其較低的容器性能開銷對于樹莓派來說也是一種合適的系統部署選擇.

本文以Python 語言實現了基于樹莓派的機房環境監測原型系統.圖4 為系統數據實時監測及管理界面.

圖4 系統管理界面

其中，圖4（a）是系統的主頁，展示實時環境監測數據及DTN 的主要硬件狀態數據，每個環境監測數據子單元順序展示此類傳感器的所有數據，若超過告警值，則報警警示；圖4（b）是DCN 管理界面，可以對DCN 進行增、刪改、查操作；圖4（c）和圖4（d）是單個DCN 連接的所有傳感器采集的實時環境數據，本文中DCN 僅連接6 類傳感器，其中溫度和濕度以數值數據展示，煙霧、水滴、紅外、電流則以狀態值數據展示.

對于系統所需的大容量存儲，本方案采用樹莓派通過USB 3.0 接口掛載移動硬盤柜予以滿足.這種硬件配置方案所需成本大約在3 000 元左右，相較于一般配置的業務服務器數萬元的價格，對于普通用戶來說是一種廉價的選擇.

本方案中，主要業務流程均集中于DTN中，其運行狀態直接影響系統的各項性能指標.然而作為DTN 硬件載體的樹莓派，雖然能夠滿足系統在數據匯總、存儲及Web 發布等方面的業務需求，但作為一種卡片式微型電腦，其相對較低的硬件配置依然是制約系統高性能穩定運行的重要因素.此外，由于本方案采用主動輪詢方式進行數據匯總，伴隨DCN 數量增多，DTN 在CPU、內存及網絡帶寬等方面占用比均會發生變化.因此，本文主要圍繞上述內容對原型系統展開性能測試.

測試環境中的DTN 硬件配置為：采用最新版的樹莓派4B 版本，此版本具有64 位四核處理器、4G 內存、千兆以太網接口.DCN 與DTN 之間為100 Mb/s 網絡環境，采用的網絡流量測試工具為BWMeter，版本是8.4.1.

如圖5 所示，隨著DCN 數量的增多，DTN在CPU、內存及網絡帶寬方面的占比均會提高.其中，CPU 及內存占比變化相對較小，網絡帶寬占比變化相對較大.造成上述結果的主要原因是：一方面，系統的數據匯總、存儲及Web 發布等核心業務是CPU 及內存資源消耗的主要因素，通過本方案采用的各種輕量級開發技術能夠大大降低系統對硬件資源的需求，能夠使以樹莓派為硬件載體實現的輕量化環境監測方案在保證系統穩定、高效運行基礎上，極大降低系統的硬件成本.另一方面，由于本方案采用主動輪詢方式，DTN 通過指令及DCN 狀態信息統一協調數據匯總流程，這些數據會造成一定的網絡資源消耗，且伴隨DCN 數量的增多，網絡帶寬消耗將逐漸提升，也會增加DTN 的運行負載.因此，出于系統在安全、高效、低負載等方面因素的考慮，本文建議DCN 數量不大于10 個.

圖5 系統性能分析圖

3 結論

機房環境監測系統在高校中心機房建設中越來越重要.本文聚焦高校中小型機房的環境監測需求，圍繞環境實時監測和報警兩大核心業務，設計了一套基于樹莓派的“傳感器單元-數據采集節點-數據匯總節點”三層框架的輕量化實時環境監測方案.該方案的優點包括：①方案采用樹莓派和基于GPIO 接口的傳感器作為硬件載體，簡化了系統硬件部署結構，在滿足用戶對機房環境監測的基本需求基礎上，能夠極大地降低系統的硬件成本.②方案依托Python 豐富的第三方開發庫支持，設計實現了輕量化業務處理模塊，以極少的代碼解決了用戶的核心業務需求，系統具有易實現和跨平臺特點.③方案通過引入虛擬容器技術Docker 對系統進行封裝，能夠實現系統一鍵化環境部署需求，具有易部署、易擴展的特點.綜上所述，該方案具有一定的實際應用意義和推廣價值.