贾宝军，徐雷，郭玉华，熊微，李素粉
（中国联合网络通信有限公司研究院，北京100032）
摘要：提出了一种能够支撑多数据中心和多私有云环境的监控系统解决方案。通过采用分布式框架，重新封装Zahbix API和OpenStack API，实现了压力分担、易于扩展的统一监控系统。该方案对于研究类似的分布式集群调度系统具有重要意义。
关键词：统一监控系统；虚拟化；资源池
中图分类号：TP393 doi: 10.11959/j.issn.1000-0801.2016095
1 引言
IT系统的监控技术从信息化伊始就一直存在和发展着。小到单独的IT系统，大到成百上千台的服务器和网络设备，都有或大或小的监控系统。开源社区也形成了如Ganglia、Nagios、Splunk的监控软件，被不少公司的信息化部门采用。近年来，随着云计算、大数据和互联网的快速发展，IT基础设施发生了根本转变，监控需求从一些独立的系统要求转变为整体平台化的系统要求。服务器不再是孤立的计算单元，而是通过云计算、大数据等平台将计算、存储资源统一起来，跨越数据中心范围形成规模更大、统一管理的资源池，因此需要能够监控大规模、跨地域的虚拟资源的监控系统。
2统一监控的需求
2.1 云平台的统一监控要求
私有云平台除了采用商业的VMware和hypervisor作为虚拟化平台外，还可以采用OpenStack等开源技术。本文提出的云平台基于OpenStack底层技术进行搭建。为构建一套完整的统一监控系统，需要实现覆盖全部物理机和虚拟机的监控功能，以实现高效管理大规模软硬件资源、动态合理分配系统资源的目标。
(1)物理机监控，通过在物理机上安装一个守护进程，定时收集每个节点的状态信息，最后汇总到监控系统中，进行存储、归纳、分析、展示。智能平台管理接口(IPMI)获取监控数据。
(2)虚拟机监控，通过底层的Hypervisor进程和虚拟化管理平台收集相关的监控项信息，发送给监控系统，存储、归纳、分析、展示每台虚拟机的监控信息。
(3)监控系统可以同时展示物理机和虚拟机的监控视图。
(4)对于多个OpenStack平台的环境，需要同时监听多个Ceilometer来源以获取不同虚拟化平台下虚拟机的监控数据，汇总上报到监控系统中。
2.2跨地域的资源统一监控
随着IT资源的虚拟化，数据中心间的区隔也变得日益模糊。用户不再关心自己的硬件到底部署在什么地方，只关心软件系统的服务能力是否满足业务需求，这样就要求底层资源池能提供一定的QoS保障，或者具有资源使用的调优能力。要实现该要求，必须有纵观全局的监控能力，依据监控指标制定资源使用策略，实现资源的自动或智能调配，保障软件系统的能力要求。
因历史原因遗留下来的一些规模较小的数据中心，也需要纳入统一资源池的环境中。当下互联网的系统需求往 往会急剧膨胀，有限的IT资源很难满足互联网快速发展的需求，这样势必要将以往孤立的小规模数据中心打通．提供统一的服务能力。
3 Zabbix监控软件
Zabbix是开源社区监控软件的后起之秀，集成了SNMP、agent、IPMI等多种数据采集方式，方便在不同环境中使用，完善了监控和图形化显示功能。
Zabbix软件具备一定的分布式系统管理能力，可以监控小型和大型的分布式环境，并将所有历史数据、趋势和配置信息存储在数据库中。Zabbix所有的逻辑运算都在服务器端执行，对监控对象的性能影响很小。
Zabbix代理(proxy)支持分布式能力，可以代表Zabbix服务器收集性能和可用数据，承担采集数据的任务并减轻Zabbix服务器的负载。同时，使用Zabbix代理是实施统一和分布式监控最简单的方式，因为所有的客户端和代理 向同一个Zabbix服务器报告数据，并且所有数据集中保存在服务器数据库中。Zabbix代理可在监控远程区域、拥有不可靠链接的区域时使用。当监控数以千计的设备时．Zabbix代理可分担Zabbix服务器的负载。Zabbix分布式构如图1所示。
采用Zabbix作为监控系统可以支持分布式集中管理，用于分布式环境监控，但也存在明显缺点。首先，Zabbix方案需要在被监控的主机上安装agent，这样会侵害用户的隐私，而且agent也存在被用户卸载的情况；其次，所有数据都集中保存在数据库中，Zabbix监控系统产生的数据量很大，数据库会成为系统发展的瓶颈；最后，Zabbix代理的方案受限于代理性能，当代理服务的监控机器数量较多时，很难满足资源的监控要求。综上所述．Zabbix不是一个能够满足云平台和多数据中心统一监控的软件方案。
4分布式架构的引入
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案以及SOA服务治理方案。其核心部分如下所述。
(1)远程通信
提供对多种基于长连接的NIO框架的抽象封装，包括多种线程模型、序列化以及“请求一响应”模式的信息交换方式，像调用本地方法一样调用远程方法。 (2)集群容错
提供基于接口方法的透明远程过程的调用，包括多协议支持、软负载均衡、失败容错、地址路由、动态配置等集群支持。
(3)自动发现
基于注册中心目录服务，使服务消费方能动态查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo架构示意如图2所示。
系统包括5种不同的角色：服务提供者、服务消费者、服务注册中心、服务监控中心和服务运行容器。服务提供者是暴露服务的服务提供方：服务消费者是调用远程分布式服务的服务使用方：服务注册中心是系统的基础和核心，是服务提供者和服务消费者沟通的桥梁；服务监控中心负责统计各服务调用次数、调用时间以及服务提供者的
服务运行上报信息等：服务运行容器启动、加载、运行服务提供者。具体角色功能如下所述。
(1)服务注册中心提供集中的服务注册、服务订阅、服务信息通知及服务监控功能，并提供代理模式的服务调用能力。
(2)服务提供者负责提供具体的服务，并在服务启动后向集群服务管理系统进行服务注册，并定期将服务运行统计信息（如服务性能数据、服务使用情况等）上报给监控中心。
(3)服务消费者需要在服务启动后，主动向集群服务管理系统订阅所需的服务。当消费者订购的服务信息发生变化时，向订阅的消费者发送异步消息通知。
(4)服务提供者及服务消费者采用长连接方式与集群服务管理系统进行通信。
(5)监控中心统计服务消费者和服务提供者的性能指标等，并向服务注册中心汇报服务提供者的服务运行上报情况。
(6)服务运行容器提供Web服务容器功能，负责启动、加载、运行服务提供者。
5统一监控系统的实现
采用Zabbix作为监控能力的提供层，监控系统重新定制portal以满足跨数据中心的监控以及统一的物理资源和虚拟资源的监控。
采用Dubbo框架对Zabbix API和OpenStack API进行重新封装，如图3所示，实现分布式监控系统。这样监控门户对数据的访问变成由Dubbo引导的访问。Zabbix服务通过API方式由Dubbo服务提供者提供，用户请求作为Dubbo下的服务消费者向服务器提供者发送请求信息。
当监控多个数据中心时，在每个数据中心部署一套或多套Zabbix软件系统，Dubbo服务提供者调用Zabbix系统API实现监控能力，Dubbo服务消费者负责处理用户请求，通过调用Dubbo服务提供者响应请求，Dubbo服务消费者和服务提供者都需要首先在服务注册中心完成注册。当用户通过portal访问某一机器的监控信息时，需要根据区域标识符来决定由哪个Zabbix服务器提供监控源，从而引导用户请求到对应的Zabbix服务器。
对于数据中心有一个或多个云平台的情况，首先对OpenStack云平台的监控服务设置单独的Dubbo服务提供者和服务消费者，将Ceilometer API封装为实现Dubbo服务提供者，用户请求通过Dubbo的服务消费者模式执行。每增加一个OpenStack云平台，新增相应的Dubbo服务消费者和服务提供者，从而实现对多个云平台资源池的监控。分布式监控系统架构如图3所示。
图3描绘了两个数据中心的场景，每个数据中心部署有一套OpenStack云平台，虚拟机的监控数据由OpenStackCeilometer组件进行采集和存储。在每个数据中心部署一套Zabbix监控系统，通过Zabbix agent采集服务器的运行状态。来自portal的用户请求通过Dubbo层转发到相应的Zabbix服务器和云平台，以获取相应的数据。
数据中心之间可通过公网或者VPN进行连接，网络应提供足够的带宽和质量保障。系统对监控数据的处理主要在本数据中心完成，监控数据的采集分别由各自数据中心的Zabbix服务器和云平台完成，Dubbo的服务消费者和服务提供者负责将处理好的数据返回给portal。数据中心间仅传送必要的数据和Dubbo控制的数据，大部分数据流量限制在本地数据中心。
图4是其中服务器th内的监控情况。
6 结束语
本文提出了一种能够支撑多数据中心IT资源统一监控的系统，同时实现了云平台环境下物理与虚拟资源的统一监控。本文将监控系统搭建在Dubbo架构上，很好地解决了原来集中系统的性能问题和管理分布式环境问题。该系统已上线运行，从结果上看符合设计目标。该方案对于研究类似的分布式集群调度系统具有重要的意义。
下一篇:返回列表
