IDC网络资源集中监控方案研究

1 IDC集中监控研究背景

近年来数据中心业务发展迅猛，IDC机楼投产速度也越来越快，一个IDC机楼的投产周期已从几年缩短至半年。同时，为了加快机架资源的储备，抢占市场份额，电信运营商越来越青睐与第三方发展合作共建模式，由第三方负责数据中心基础设施的建设，运营商负责提供网络出口和传输配套。

传统数据中心通常使用DCIM等系统对基础设施进行集中监控管理，往往只部署在一栋机楼或园区之内。运营商更关注于对网络出口和资源的管控，随着运营商管理的数据中心日益增多，需考虑一套对多个数据中心进行网络和资源集中化管理的整体解决方案。

电信运营商传统的网管建设周期较长，难以满足IDC共建机房的紧急需求，为支撑客户业务快速上线，IDC机房的网络监控靠数据中心运维部门自己搭建部署来实现，一般采用开源软件进行部署，结合业务部门的需求进行二次开发来实现。

为此，结合笔者自身工作实践，对IDC机房的网络资源集中监控方案进行了研究与探索。

2 研究主要内容

运营商对数据中心的网络集中监控主要考虑以下方面。

（1）选取集中监控中心。影响集中监控中心选择的因素有IDC机楼的业务规模、其所处的地理位置、各IDC机楼间相互的距离以及机楼附近的传输资源等。一般选择业务规模较大、地理位置较好的数据中心作为集中监控中心，各机楼的网络设备的网管信息采集通过传输中继传送到集中监控中心进行统一管理，一般通过公网可以实现数据的采集传送，对于安全性要求较高的组网，可通过网管网络来传输数据。

（2）部署一套集中监控系统。监控软件可使用Host Monitor、PRTG、CactiEZ等业界流行的监控软件进行部署。在建设初期，硬件使用一般的x86服务器进行配置即可，但随着运营商需要集中管理的机楼数量的增多，以及网络设备数量的增加，需要关注监控服务器的运行性能，及时对服务器进行升级与扩容。

（3）设置基于用户和业务的监控。数据中心机房内组网由多台接入交换机，汇聚交换机或出口路由器组成，网络设备端口较多，一般需要按用户进行端口捆绑，除一般端口告警监控之外，还应设置基于用户维度的业务质量监控；另外，根据不同用户级别设置不同告警分级，对于重要出口链路应有告警推送，及时知会运维主管进行故障处理督办。

3 具体实现方案

本课题在广州公司数据中心机房开展了集中监控部署研究，具体方案介绍如下。

3.1 IDC监控中心选址

由于广州公司数据中心大多集中在黄埔区科学城一带，因此选取其中一栋标准机楼作为集中监控中心，在该机楼部署集中监控平台，其余机楼的网络设备数据采集通过传输链路传送到该机房监控平台。如图1所示。

图1 集中监控物理架构

3.2 集中监控系统部署

监控平台采用zabbix软件进行搭建。zabbix是目前业内最流行的分布式图形化开源监控系统解决方案，它具有健全灵活的监控数据采集、存储、告警规则配置以及图形化展示界面。通过SNMP、ping，端口监视等方法配置zabbix server服务器可以对各种远端网络设备进行数据采集和监视。

Zabbix有3种架构：直接连接架构（server-client）、Node架构（master-node-client）和proxy架构（serverproxy-client）。本方案根据本地数据中心实际生产环境、网络结构、监控规模等因素，采用了直接连接架构与proxy架构相结合的方式，这2种架构的区别在于：①直接连接架构：该架构是zabbix最简单的架构，监控服务器和被监控设备之间不经过任何代理，直接在zabbix server（监控服务器）和被监控设备之间进行数据交互，适用于网络比较简单，设备较少的监控环境。②Proxy架构：proxy是server、client之间沟通的一个桥梁，proxy本身没有前端，而且其本身不存放数据，只是将被监控设备发来的数据暂时存放，而后再提交给服务器端。该架构一般适用于跨机房、跨网络的中型网络架构的监控。

本方案对于设备数量较少的数据中心采用直连架构进行部署，另外在业务量大、设备数量较多的数据中心采用proxy架构。proxy架构下需各部署1台proxy服务器，用于该机楼内网络设备的信息数据采集。

本方案的直连架构和proxy架构共用一套服务器系统，在集中监控中心进行部署。服务器系统的软件架构为Linux+PHP+Web Service+Database，分别安装在4台机架式服务器上，其中1台提供zabbix server服务，1台提供web服务（安装Apache服务器软件），2台提供数据库服务（安装MySQL数据库软件）。Zabbix server服务器通过MySQL数据库进行数据存储和数据读取，通过网页的方式对zabbix采集的数据和告警阀值进行展示。数据库服务器设置2台是考虑了主备冗余备份，用于提高数据的可靠性，web服务器单独设置主要是考虑接入公网来提高系统的安全性。

由于广州IDC数据中心主要监控网络设备，所以该系统主要通过SNMP方式对设备数据进行采集。广州IDC数据中心不同机房采用了不同的SNMP团体名，该监控系统通过设置不同模板群组，来实现数据采集。

集中监控系统的部署架构如图2所示，规模较小的数据中心的设备采用直连架构进行配置，而规模较大的数据中心的设备采用了proxy架构。

图2 集中监控系统部署架构

通过zabbix proxy组件的方式做到分布式部署，proxy端进行信息数据采集，server端进行数据的分析和告警，可以提高信息数据采集效率，降低server端的压力。各服务均配置在Linux平台上运行。

3.3 监控基本功能设置

Zabbix可以通过多种方式进行告警呈现，或通过邮件、短信、微信等报警方式发送到指定人。由于邮件接收不及时甚至容易被忽视，而在大规模告警消息产生时，通过调用短信网关实现的短信告警方式对于消息接收者来说体验并不友好，越来越多运维人员开始使用zabbix的微信告警功能作为主要的告警方式，这样可以及时有效地把告警信息推送到接收人，方便告警的及时处理。

本方案的集中监控告警呈现分为平台告警和微信告警两种。

（1）平台告警，平台告警为网页访问，分为统一平台监控告警和分支机房监控告警。使用统一平台监控告警，所有IDC机房的警告以上的告警信息都在统一平台监控告警界面进行展示，而分支机房监控告警则是分支机房的告警信息在对应机房的账号平台上进行展示。分支机房的运维人员一般只关注查看本机房内的告警即可，集中监控中心的监控人员则可看到所有机房的告警，对于一些高等级告警须知会分支机房及时处理，做到对数据中心生产网监控的双备份，防止漏看和未及时处理故障告警。如图3所示。

图3 集中监控平台web界面

（2）微信告警。本方案启用了微信告警功能。微信告警通过微信企业号设置不同的分组，对不同的用户组发送不同的告警。机房现场运维团队分组能够接收对应机房的一般告警以上的告警信息，如端口中断等，而对于如出口线路中断、设备宕机等严重告警，除机房现场运维团队接收外，也需推送到运营商IDC运维主管进行督办处理。微信告警的分组设置如图4所示。本方案申请了一个有发送信息接口的微信公众号，编写脚本调用微信的API，脚本示例如图5所示。

图4 微信告警平台分组设置图

图5 微信告警平台脚本模板

微信告警效果呈现如图6所示。

图6 手机微信告警效果图

3.4 监控功能优化配置

3.4.1 告警分级

数据中心对不同客户的网络保障有着不同的SLA要求，尤其是重大客户对机房网络丢包、抖动等质量问题十分敏感，需要重点关注。为了提高机房故障发现及时率和故障处理效率，本方案对集中监控平台的告警做了分级设置。不同等级的故障，将会产生不同的告警。

Zabbix软件既提供了模板默认配置的的告警等级，又可根据实际需要进行人工调整。告警等级可分为信息、警告、一般严重、严重、灾难5个等级的告警。本方案根据广州数据中心运维工作的实际情况，对不同程度的设备故障，网络异常或业务质量劣化进行了相应的告警分级，5个等级的告警设置说明如表1所示。

表1 告警分级定义表

3.4.2 链路汇聚

数据中心的运营需要定期给运维管理部门提交运维报告，作为机房容量管控和网络规划的重要参考，也需要定期为业务部门提供基础数据，作为客户流量收费以及后续业务拓展的依据，因各数据中心出口链路和设备端口较多，若采用人工方式导出zabbix端口流量报表再逐个统计，会增加大量的工作，也难以确保数据的准确性。

通过zabbix的整合监控项可以把数据中心跨设备的所需要的监控项整合到一起。整合型监控项是指对已经存储在数据库中的监控指标数值进行二次计算，从而形成新的监控指标，利用这个功能，可以很容易做到对一组或多组已有的监控项数值进行再次统计计算，如计算多组网络设备的端口流量使用总带宽等。

目前集中监控平台已对各数据中心的网络出口流量进行了整合，可通过图形直接了解每个数据中心的出口实时总流量情况。图7为旗锐数据中心两台出口路由器上的所有端口流量汇聚后的流量呈现图。

图7 数据中心出口流量汇总图

3.4.3 95计费

除了对网络和业务质量进行一体化集中监控外，业务部门对数据中心运维部门也提出更多需求，希望从运维部门获取一些业务相关的信息，包括业务运行情况、用户投诉及处理情况等，尤其是以客户为粒度的流量数据，是对客户进行计费参考的重要依据。运营商也需要掌握其在所有数据中心的客户业务的使用情况，以便统一计费，而目前数据中心还无法打造像运营商传统通信网那样的BOSS计费系统，因此利用集中监控系统进行95计费研究十分有必要。

目前业界IDC数据中心常用的带宽计费方式有共享带宽计费、独享带宽计费和95带宽计费。较为合理的计费方式是95计费。95计费是通过把一个结算时间里的流量（通常为一个月），按每5分钟取一个采样，然后把结算时间里的最高采样点的5%去掉，剩下的最高采样值作为95计费的计费值。如果是每月计费一次，每5分钟取一个流量采样，一个月按30天算一共有8 640个采样点，然后把数值最高的5%的点去掉，剩下的最高流量就是95计费的计费值了。即需要计费的点数是8 208个点，有432个点不用计费，就是异常高流量的时间为36个小时，即每月不超过36小时的异常大流量不影响本月的计费。

本方案配置的95计费使用了zabbix系统进行配置实现，在zabbix中有自动发现的单端口95计费和人工汇总的95计费两个模块。自动发现的单端口95计费，使用了zabbix的端口发现规则模板，通过新建监控项原型的方式把单端口的95计费直接通过模板部署，当有新的端口开启后将会直接匹配该规则模板，同时自动开启该端口的95计费；而人工汇总的95计费是通过运维人员在某个客户的带宽端口变化时，人工增加或删减可计算项中的条目来完成计费数据的汇总。自动发现的单端口95计费，其优点是无需人工操作即可自动完成95计费数据采集计算，缺点是由于系统对每个端口的计费规则都进行了监视，增加了系统的负荷，内存等资源利用率也会有所升高。人工汇总95计费优点只是方便数据的整体导出计算，缺点为人为的操作可能会存在可计算项更新不及时导致数据不准确。两者可以互相结合，综合考虑其优缺点来分批部署使用。Zabbix配置95计费流程如图8所示。端口自动配置的95计费样例如图9所示。

图8 zabbix配置95计费流程图

图9 端口自动发现95计费配置样例

4 方案实施效果

网络集中监控方案在广州数据中心部署以来，已成功预警出口链路类紧急故障十余次。同时通过对告警进行精确分级，网页监控与微信推送相结合的方式，提高了故障发现效率，能够先于客户投诉发现故障并及时处理，保障了客户的感知，大大提升了客户的满意度。

数据中心集中化监控方案打破了传统各IDC机楼各自监控的模式，为运营商提供了统一监控多个IDC机楼网络运行情况的有效手段，提升了管理效能。通过整合各机楼现场运维人员实现了监控人员的复用和统一管理，极大降低了运维成本。

本文探索了一套对数据中心网络资源进行集中监控管理的综合解决方案，既借鉴了运营商对于传统通信机楼集中监控的运维经验，又具有IT行业快速灵活部署的特点，是CT与IT应用相结合、运营商开展数字化转型的一次实践尝试。在广州、深圳、东莞等IDC机房众多的一类地市，目前正处于大力发展合作共建机房，加快IDC机房机柜资源储备的关键时期，推广自建监控系统的集中部署方案有利于缩短网络建设周期，加速资源投放，压缩运维成本。运营商也可利用其在网络管理方面的丰富经验，专注于数据中心网络出口的容量和质量管理，再根据实际需要在各分支机房与合建方独立开展基础设施管理，提高合建数据中心的运营管理效率。除此之外，对于运营商自建的数据中心来说，也可通过集中监控模式来加大对自有机房的管理力度，确保自身网络容量质量以及资源信息使用得到更好的管控。