基于树莓派的高校中心机房综合环境监测系统的研究与设计

刘 磊，江永旭，刘庆俞

数据中心是高校信息化建设的核心基础设施，其对所处机房环境的安全性与稳定性要求极高［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 对系统进行封装，能够实现系统一键化环境部署需求，具有易部署、易扩展的特点.综上所述，该方案具有一定的实际应用意义和推广价值.