引言

近年来, 随着云计算、虚拟化技术的发展和应用^[1], 云计算平台产品得到各行各业的广泛使用. 越来越多的应用领域, 构建了适宜于自身的应用支撑系统^[2,3]. 气象部门作为科技密集型部门, 对新技术有天然的应用需求, 同时, 信息技术在气象行业的深度应用, 能够解决业务中存在的突出问题. 从信息化角度, 地市级气象部门承担着气象数据的收集、存储、分析、共享, 公共气象服务产品的发布等职能, 特别是灾害性、极端天气来临前, 公共气象产品的短时、海量的数据请求, 气象灾害信息的及时发布, 对计算资源、支撑系统的可靠性、健壮性、并发处理能力提出较高要求, 譬如, 在灾害性天气来临时或天气预警发送时点, 苏州气象APP客户端有约5万用户的并发访问, 常常造成服务器崩溃, 传统的服务支撑模式已无法满足公共气象服务需求. 因此, 急需应用新技术, 结业应用需求, 运用工程思维构建面向气象领域的应用支撑系统.

目前, 面向地市级的气象应用支撑系统存在以下几方面问题急需解决: (1) 计算资源还处在单服务器单应用模式, 资源需要整合. (2) 应用支撑系统整体可靠性、可扩展性差. (3) 系统并发处理能力满足不了短时海量的数据访问. (4) 监控运维困难, 集约化的运维监控系统缺失. 因此, 针对气象应用中所面临的诸多问题, 构建一种集约整合、弹性可扩, 可靠性高, 且能够实现应 用端负载均衡的气象应用支撑系统非常必要. 这也是气象业务、公共气象服务得以有效开展的基础性工作.

在计算资源整合, 提高资源利用率和系统可靠性上, 虚拟化技术的发展, 使得计算资源的使用效率和资源的动态配置和扩展都有了很大提升^[4]. 目前, 包括KVM (Kernel-based Virtual Machine)^[5]、VMware^[6]、Xen等^[7]在内的基于裸金属架构的虚拟化产品在各领域私有云搭建上得到广泛应用. 张千等^[8]基于KVM虚拟化技术, 提出一种私有云平台实现方案, 并应用于石油勘探开发行业. 华连生等^[9]采用VMware虚拟化, 开展了气象业务省级资源池的设计与应用, 并推进了省市县气象业务的整合. 蒋建军等^[10]提出一种基于虚拟化技术的应用交付设备, 终端用户以虚拟桌面或虚拟应用方式运行部署在虚拟服务器上的应用程序, 实现了应用虚拟化. 李成功等^[11]针对空管信息系统建设中存在的资源利用率低、软件紧耦合、数据存储分散等问题, 提出一种混合云模式的新一代空管信息系统.

为解决虚拟机集群资源利用负载能够均衡分配的问题, 易星宇等^[12]通过迁移高负载主机上的虚拟机到低负载主机, 使得各主机处理器频率更均匀, 以达到节省能耗的目的. 何倩等^[13]提出基于软件定义网络的反饱和负载均衡方法, 通过周期性获取云主机负载和权值调整来保证云主机集群负载更加均衡. 刘胜楠等^[14]在Xen虚拟化环境中, 实时监视宿主机和虚拟机的负载状态, 通过虚拟机启动和关闭来提高Web服务集群的伸缩性和自动化能力.

本文面向气象领域的应用需求, 从信息系统支撑更加集约、高效、可靠、灵活的角度, 采用云计算、虚拟化技术, 负载均衡策略配置及与虚拟化的联动技术, 构建一种面向地市级气象领域的应用支撑系统, 并投入业务使用, 极大地提升了信息系统支撑能力, 在系统运维方面, 实现了自动化运维和监控.

1 系统总体设计

按照分层架构思想, 将系统分为4个层次, 各层之间各司其职, 分层解耦, 系统框架图如图1所示.

如图1所示, 将系统分为物理资源层、虚拟资源层、负载均衡与分发层, 应用层. 其中, 虚拟资源层、负载均衡与分发层是本次应用支撑系统设计的核心, 虚拟资源层基于KVM虚拟化技术实现计算、存储资源的整合、虚拟化和池化, 完成资源管理、业务负载监控及基于业务负载的动态资源调度等功能, 构建更为可靠、高效、弹性的基础计算资源支撑平台, 并实现集约化的运维监控. 负载均衡与分发层是面向不同类型的气象应用, 采用合适的负载均衡策略, 将负载均衡与虚拟资源的分配相结合, 完成联动资源扩展和回收, 实现面向气象应用的精准资源支撑, 同时, 增强气象业务系统的并发处理能力.

2 关键技术 2.1 虚拟化资源平台

针对苏州市气象部门数据中心存在的单应用单服务器的支撑现状, 采用服务器虚拟化技术进行资源整合是基础性工作. 因此, 本文基于X86刀片式服务器和部分利旧服务器搭建了虚拟化资源管理平台, 实现了资源的集约和统一管理, 完成日常气象计算资源的便捷式分配、管理及相关资源的监控, 进一步提高了系统运维水平. 资源集约的前提是搭建更为可靠的计算资源支撑系统, 本文分别采用虚拟化管理平台双机热备、虚拟机快照备份、关键气象业务系统整体备份等方式实现计算资源和气象业务的双重备份, 提高系统可靠性. 虚拟化资源平台系统结构图如图2所示.

如图2, 在搭建共享存储基础上, 系统采用14把刀片式服务器, 安装虚拟化内核软件组成计算集群, 虚拟化软件采用基于KVM架构的H3C CAS3.0解决方案. 为了避免虚拟化管理平台主机故障, 导致的无法进行及时资源管理和维护的问题, 本文在管理主机的搭建上采用2台性能一般的利旧机架式服务器, 通过双机热备的形式提高管理平台的可靠性.

虚拟化平台管理主机双机热备功能是基于数据同步复制的方式实现, 主备服务器之间数据的同步是采用DRBD (Distributed Relicated Block Device)分布式存储复制方法来实现, 当主服务器数据发生变化时, 该数据变化会实时同步到备用服务器, 这样就保证了主备服务器之间的数据一致性. 当主服务器发生故障, 主备切换是基于开源的高可用资源管理器Pacemaker和集群框架Corosync来实现. Corosync监测主备服务器之间的心跳. 当检测到主服务器发生断电故障或网络故障时, Pacemaker会进行主备管理平台的切换, 备用服务器接管主服务器对外提供业务, 并成为主服务器.

2.2 动态资源扩展

动态资源扩展(dynamic resource extension)是通过业务负载监控和业务资源调度两个模块实现虚拟资源的动态扩展和回收. 业务负载监控模块实时监控虚拟机的CPU、内存、网络、磁盘和连接数等负载情况, 实现业务系统性能的自动化感知, 为资源扩展与回收提供依据, 而在实际的应用中, 通过划分不同的动态资源扩展服务器组来实现组内资源的监控和感知. 当业务负载达到一定条件后(如超出事先设定的阈值后), 业务负载监控模块向业务资源调度模块上报资源扩展时间, 由业务资源调度模块进行虚拟机的调度, 进行虚拟资源的扩展或回收. 同时, 结合负载均衡设备, 制定不同的负载均衡策略, 完成精确到不同业务系统的弹性、可伸缩的动态资源扩展.

本文的动态资源扩展是通过虚拟机模板快速部署或者源虚拟机克隆的方式扩展业务虚拟机. 因此, 虚拟机要通过DHCP来获取地址, 在实际应用中, 通过设置IP地址段来指定具体业务资源扩展的IP地址范围. 动态资源扩展与负载均衡技术的联动, 可解决气象应用领域突发、短时、高并发数据访问的问题.

2.3 负载均衡与虚拟化联动技术

服务器负载均衡技术研究将业务较均衡地分配到多台虚拟机上, 从而提高系统的整体性能. 同时, 在系统可扩展性、高可靠性方面都有较大的技术优势, 譬如, 在不降低业务质量的前提下, 可以很方便的增加虚拟机, 单个机器故障不会导致业务中断. 负载均衡及其与虚拟化的联动是动态资源扩展的关键技术. 针对不同的气象业务应用, 制定适宜的业务负载分发及联动扩展策略, 可以实现面向具体应用的联动资源扩展.

2.3.1 基于应用的负载均衡

通过划分面向具体业务的虚服务器, 并将虚服务器映射到实服务器组来实现基于应用的负载均衡, 系统框架如图3所示.

如图3所示, 将负载均衡框架系统分为以下几个模块:

(1) 虚服务器: 面向具体业务的虚拟载体, 只有匹配虚服务器的报文才需要负载均衡处理. 具体表现为一个虚拟IP和端口地址, 每一种虚服务对应一种应用.

(2) 实服务器组: 处理业务的实体, 一组功能相同的服务器组. 实服务器可被虚服务器和负载均衡动作引用, 本文通过动态资源扩展技术, 动态调整实服务器组.

(3) 负载均衡策略: 负载均衡分类和负载均衡动作关联起来构成负载均衡策略. 负载均衡策略可被虚服务器引用.

(4) 负载均衡分类: 将IP报文分类, 以便对不同类型的报文执行不同的负载均衡动作.

(5) 持续性组: 将具有一定相关性的会话分配给同一个实服务器处理, 保证会话的持续性.

(6) 参数模板: 定义对负载均衡IP报文进行处理的模板.

系统将需要负载均衡的业务对外公布一个虚拟IP或虚拟IP和端口地址, 通过虚拟化资源平台和动态资源扩展技术定义实服务器组集合, 并将虚服务器与实服务器组形成对应关系. 同时, 对不同的负载均衡IP报文定义不同的负载均衡策略, 当系统检测到相应的IP报文时, 会根据事先定义好的负载均衡分类, 采取对应的负载均衡动作, 启动实服务器组中服务器资源负载分配. 持续性组模块是将有一定相关性的会话(如有登录认证功能的应用)分配到同一个服务器进行处理, 保证应用的连续性.

负载均衡与虚拟化的联动是通过在虚拟化资源平台定义面向具体业务的动态资源扩展组, 在对虚拟机资源监控自动化感知的基础上, 当应用达到预先设定资源扩展或回收条件时, 自动进行资源扩展或回收, 这对于负载均衡是透明的. 也就是通过虚服务器与实服务器组之间的映射, 根据实时业务负载情况, 动态调整实服务器组, 实现了负载均衡与虚拟化资源之间的联动.

2.3.2 负载均衡策略

采用合适的负载均衡策略是应用得以有效支撑的关键, 因此, 需要根据不同的应用场景选取合适的负载均衡算法.

2.3.2.1 源/目的IP地址哈希算法

源IP地址哈希算法是针对请求的源IP地址的负载均衡, 用源IP地址作为散列键(Hash Key)从分配的散列表中找出对应的服务器, 通过虚拟化计算资源监控模块自动化感知服务器健康状况和负载情况, 若该服务器是可用的且未超载, 则将请求分配到该服务器. 假设有一个服务器集合S={S0,S1,…, Sn}, HashTable[]表示一个Hash表, 初始值是将服务器集合顺序、循环地放置到HashTable中. 当有IP地址请求时, 通过Hash函数计算出Hash值, 然后, 在HashTable中, 找出对应的待分配服务器, 本文采用素数乘法Hash函数, 通过乘以素数使得Hash值达到较均匀的分布. 负载均衡与虚拟化的联动, 使得服务器集合S中的服务器是动态变化的, 相对于传统的静态调度算法, 更有益于保证应用的稳定性和可用性.

2.3.2.2 最少连接算法

客户端的每一次请求服务, 在服务器停留的时间可能有较大的差异, 随着调度时间的加长, 如果采用简单的轮询或随机算法, 每一台服务器上的连接进程可能会产生很大的不同, 并没有达到真正的负载均衡.

最少连接算法对需要进行负载均衡处理的每一台服务器都有一个数据记录, 记录当前该服务器正在处理的连接数量, 当有新的服务连接请求时, 把当前请求分配给连接数最少的服务器. 最少连接算法是一种动态的负载均衡算法, 使负载更加均衡.

2.3.3 持续性方法

从某种意义上讲, 负载均衡技术使得各服务器的负载更加均匀, 同时带来了会话分配具有一定的随机性的问题. 为了解决具有一定相关性的会话分配给同一个实服务器处理, 本文在实现负载均衡的同时, 采用持续性方法, 建立持续性表项, 以保持会话的持续性. 根据气象应用的类别, 分别根据源IP和端口信息、报文的Cookie和报文的某些特定内容进行持续性处理.

IP和端口信息持续性处理方法将同一个网段的地址访问流量统一分给同一台服务器处理, 适合于星型的网络布局, 对于同一分地的用户提供同样的服务. 报文的Cookie持续性处理方法较适宜于对同一用户的不同时间内的业务分发到同一台服务器. Cookie的作用是用来区分用户以及跟踪用户的访问特征, 以Cookie做为持续性可以提高用户的访问体验. 利用报文的某些特定内容(如HTTP报文的报文体)进行持续性处理, 如报文体中的UserName提取, 以用户名匹配持续性表项内容, 进行会话保持.

3 系统应用及运行效果

在搭建虚拟化资源平台和负载均衡技术的基础上, 在气象领域, 选取有条件的典型应用(如前后端服务分离、分层解耦等气象应用), 进行了系统应用, 并解决短时、突发的业务请求难题.

分别选取了气象APP、云视频系统、气象数据接口平台3个系统进行了系统应用. 应用分析如表1所示.

首先对3类应用进行虚IP服务调整, 改变原有的单服务器单应用模式, 利用虚拟化资源平台建立实服务器组, 创建各应用对应的资源克隆模板和动态资源扩展与回收策略. 对于气象APP、数据接口平台两个公共服务系统, 采用最少连接负载均衡算法. 而云视频系统是一个市县气象部门内部分析系统, 在IP地址段明确的前提下, 采用源IP地址Hash负载均衡算法, 因需要用户登录, 为保持应用持续性, 采用用户名进行持续性表项匹配, 以保证应用的持续连接. 实验证明, 3类气象应用, 在实际的业务化运行中在稳定性、并发处理能力、流畅度均较之前有了明显提升.

气象云视频系统应用效果如图4所示, 视频的分发和调度较为流畅.

4 结束语

本文面向地市级气象领域的应用需求, 针对目前存在的信息系统可靠性低、可扩展性差、应用端高并发处理能力弱等问题, 从信息系统集约、高效、可靠、灵活的角度, 采用云计算、虚拟化技术, 负载均衡策略配置及与虚拟化的联动技术, 搭建了虚拟化资源平台, 完成了计算资源整合, 在此基础上实现了动态资源的扩展与回收, 设计并实现了一种基于应用端的负载均衡方法, 并在实际的气象领域中进行了应用. 通过系统的测试和业务化使用, 对气象应用有一个较为适宜的信息化支撑, 整体上, 构建了资源弹性可扩, 应用端负载均衡的气象应用支撑系统, 极大地提升了信息系统支撑水平. 目前该系统运行稳定、高效.