分析决策中心全局负载均衡机制设计与实现

葛以踊,郭海龙,高鑫,吴海伟,陈鹏

(1. 南瑞集团有限公司智能电网保护和运行控制国家重点实验室,江苏 南京 211106；2. 南瑞集团(国网电力科学研究院)有限公司,江苏 南京 211106；3. 国电南瑞 科技股份有限公司,江苏 南京 211106；4. 国家电网有限公司西北分部,陕西 西安 710048；5. 国网江苏省电力有限公司,江苏 南京 210024)

0 引言

新一代电网调度控制系统采用“物理分布、逻辑统一”的体系架构[1],监控系统本地建设,分析决策中心业务集中建设[2],通过采用所辖电网实时就地监控与全局分析决策相结合的策略[3],进一步提升电网调度控制系统的支撑能力。分析决策中心集中建设能够综合全局信息,为各区域提供控制目标,实现集中式控制决策[3]。为了保障系统的稳定可靠运行,分析决策中心进行异地多点建设,引入业务多活机制,实现多个中心的故障冗余及各分析决策中心地位均等,同时对外提供服务,并确保单个分析决策中心故障时其他中心对核心业务或全部业务的快速接管[4]。

分析决策业务多活机制实现了全局负载均衡、中心容错、阶段结果数据同步、断点续算和业务单元化等功能[4],其中全局负载均衡机制用于实现多中心间业务分流与容错。

新一代电网调度控制系统中,分析决策中心的业务在运行时,通过场景、场景实例、子场景、子场景实例四元组信息进行管理[5],每个业务都运行在特定的场景四元组之下,包含了一组运行中的进程,这些进程向外界提供一系列的功能服务。人机云终端作为客户端,部署在各监控系统,提供了位置无关的人机交互功能[6],支持本地、异地无差别访问,可以连接到指定的分析决策中心进行服务调用,来展示分析决策业务的计算状态、统计数据、计算结果等信息。

传统的多中心间一般通过全局负载均衡(global server load balance,GSLB)设备来实现负载分流[7],在系统内构建域名解析系统(domain name server,DNS),GLSB设备根据策略将域名解析到某个中心[8—9]。新一代电网调度控制系统业务没有统一的域名管理信息,并且部分调控系统业务的应用业务(如实时发电计划)在多中心不是对等部署[10],只在一个选定的分析决策中心(业务主中心)进行计算,因此基于DNS的分流方式不能满足特定的功能需求。另外,由于DNS缓存周期长等原因,传统基于DNS的全局负载分流[11]在一个中心故障时,切换到新中心通常需要花费较长时间,不能满足分析决策业务快速切换的需求。

文中介绍的负载均衡功能能够综合场景信息、服务信息及位置信息,将客户端请求根据负载均衡策略分流到运行指定应用业务中心,并能快速检测中心故障,完成故障中心访问业务的切换,满足新一代调控系统客户端数据展示、操作控制的需求,有效支撑了分析决策中心业务的异地多活。

1 负载均衡技术框架

电网调度控制系统业务多活环境下,基于场景与服务状态的负载分流实现方法,将客户端请求分流到满足负载分流策略的运行指定应用业务的分析决策中心,实现人机终端的数据展示、操作控制与业务场景工作中心服务相关联。负载分流功能既支持所有中心都提供服务的应用,也支持只在部分中心提供服务的应用。针对不同的应用场景,负载分流功能会根据场景与服务分布情况进行分流。

1.1 全局负载均衡功能模块

调度控制系统包含建设在异地的多个分析决策中心,应用业务运行于多个中心。从整体上看,各中心的所有应用业务对外提供服务,对于某些特定的应用业务,存在一个工作的主中心。

负载分流功能主要由中心健康状态检查模块、场景信息同步与选举模块、服务信息全局同步模块、中心分流定位模块及客户端接口模块共5个部分来实现。在每个分析决策中心的对外关口服务器上,运行前4个模块的服务程序,用于检测中心状态、同步场景及服务信息,同时为客户端提供查询服务。

分析决策中心负载均衡技术按照一定的策略,将来自客户层的访问请求均衡到不同的分析决策中心,实现各中心在正常状态下都能分担业务处理,达到“活起来”的目标[4]。负载均衡采用全局与本地相结合的两级分层设计,能够根据均衡策略以及业务场景[12—14]、服务的实时运行状态与资源使用情况,将客户端请求分流到特定的中心,如图1所示。

图1 两级负载均衡示意Fig.1 Schematic diagram of two-stage load balancing

本地负载均衡采用通用的服务器负载均衡 (ser-er load balance,SLB)做法。文中主要研究GSLB。

新一代电网调度控制系统中的业务以服务和场景的形式广域部署在多个分析决策中心,为不同系统的业务访问者提供服务。新一代电网调度控制系统提出的基于服务与场景的业务区分形式能够更加多元化、精细化地对外提供业务,因此要求业务访问时需要以基于服务与场景查询的实现方式来定位业务。

GSLB服务以集群的方式广域部署在多个分析决策中心,用于实现多个分析决策中心之间的负载分流,使业务请求可以定位到不同分析决策中心的本地负载均衡集群节点。GSLB服务的进程运行在各中心的对外关口节点上,GSLB服务之间完全独立、对等,单个中心的GSLB服务故障不影响系统运行,客户端可以配置任意中心的GSLB服务进行服务的查询与定位。GSLB可以使用的策略包括随机分配、就近分配、应用层状态分配[7,12](定位到延迟小、负载轻、性能好并且关联业务场景在线运行的中心)等。GSLB获取中心容错状态(详见2.2节)检测结果,一旦发现某个分析决策中心异常,自动暂停分发请求到该中心,当检测到中心恢复正常后,自动将新的请求分发到该中心。

GSLB框架包括中心状态健康检查、全局服务管理、全局场景信息同步与选举、中心分流定位服务及客户端接口等功能。

1.2 GSLB架构

中心状态健康检查模块部署于各中心的关口节点上,通过在各中心间发送心跳报文的方式检测中心运行状态；全局服务管理模块收集本中心的服务信息,并将服务信息在不同中心间进行同步；场景信息同步与选举模块收集本中心场景信息并将其同步到其他中心,同时为每一个场景在所有中心中选举唯一中心作为该场景的主中心；客户端接口向人机云终端提供场景或服务的查询接口,供其调用以查询运行对应场景或服务的中心信息；中心定位分流服务接收到客户端的查询请求后,根据请求内容查询在中心间相互同步的场景或服务信息,并根据对应的负载均衡为人机云终端分配符合客户端需求的中心,将中心信息返回给客户端,供客户端后续调用相关服务或者场景,如图2所示。

图2 负载分流功能模块Fig.2 Diagram of load shunt function models

1.3 负载均衡策略

负载均衡策略是中心分流定位模块在响应客户端负载分流查询请求时选择相应中心的依据,文中实现的负载分流策略包括随机分配、就近分配及应用层状态分配。

随机分配策略是指在收到查询请求后,在运行指定业务场景的中心中随机选择一个中心,作为响应该客户端应用请求的中心。

就近分配策略根据请求来源的IP地址信息,选择与其位置相近且运行了所要查询业务场景的中心作为响应该客户端应用请求的中心。如果就近中心中没有所要查询的业务场景,则在其他运行该运行场景的中心中随机选取一个作为响应该客户端应用请求的中心。

应用层状态分配策略选取延迟小、负载轻、性能好并且关联业务场景在线运行的中心作为响应该客户端应用请求的中心。

2 负载均衡功能实现

负载均衡功能包括中心状态检查、场景信息同步与选举、全局服务管理、中心分流定位服务以及提供给应用程序调用的客户端接口。

中心状态检查模块负载检查各分析决策中心内部状态及中心间的状态；场景信息同步与选举完成中心内场景信息获取及场景信息在中心间同步,同时在各中心中为各场景选举主中心；全局服务管理模块负责各中心内部服务信息的收集和服务信息在中心间的同步；中心分流定位服务接收客户端的查询请求,并根据负载均衡策略将客户端的请求定位到不同中心；客户端接口供应用程序调用,以查询自己所需的场景或服务所在中心。

2.1 中心状态健康检查

中心状态健康检查模块包括中心间心跳发送接收机制以及中心内部关键功能检查机制。中心内部检查关键通信设备的可达性与关键服务的可用性,如果内部关键功能异常,则认为当前中心故障,并通过心跳告知其他中心。另外如果收不到某个中心的心跳报文,则也认为该中心故障。中心状态提供给中心分流定位模块,作为分流时的参考。

中心内功能检查检测中心内关口节点与中心内关键节点网络状态以及中心内关键业务的运行来确定本中心的工作状态,并将中心状态以心跳报文的方式发送到其他中心。

中心间心跳检查包括网络运行状态检测与业务运行状态检测2个方面,通过部署在各分析决策对外关口节点上的中心运行状态感知功能完成,如图3所示。对外关口节点上的网络运行状态检测通过向中心内关键通信设备发送控制报文协议(internet control message protocol,ICMP)请求,并接收ICMP响应来监测关口节点与中心内部其他节点的网络状态,同时将本中心的状态信息以心跳报文的形式发送到其他中心的关口节点以判断本中心与其他中心的网络状态。业务运行状态检测监视本中心各业务场景的运行状态、服务运行状态,及时发现场景、服务的异常情况并将以上信息在各中心间同步,以作为中心间业务切换的依据。

图3 中心运行状态感知Fig.3 Diagram of center running state awareness

GSLB通过中心运行状态感知功能,快速识别分析决策中心故障,并利用该信息来分流客户层访问请求。中心容错示意如图4所示,当各中心状态正常时,GSLB根据选定的负载均衡策略[7—8]将业务请求分配到对应中心,当分配的中心发生故障时,GSLB会将业务请求重新分配到其他状态正常的中心,以确保业务请求在至少有一个中心状态正常的情况下都可以得到响应。

图4 中心容错示意Fig.4 Schematic diagram of center fault tolerance

2.2 场景信息同步与选举

调控系统业务中有一些特定的应用业务不能在多中心对等部署,只在一个选定的分析决策中心(业务主中心)进行计算,并向外提供服务,此时客户端发出的计算控制指令只有送给业务主中心才能执行,人机展示只有连到业务主中心才能获取正确的数据信息。因此需要对分析决策中心间的场景信息进行同步,并在多个中心中选举出一个中心作为场景的主中心。

2.2.1 同步机制实现

为选举业务场景的主中心,需要将中心内的场景信息在多中心间进行同步,以确保每个中心都能获取到相同的场景信息,为场景主中心选举提供数据参考。

每个中心的关口节点上的场景信息同步与选举服务会收集本中心场景信息,将场景四元组信息与中心唯一ID组合为一个全局唯一的值,并将中心内这些唯一的值以心跳报文的形式在各中心间进行同步。

2.2.2 选举机制实现

场景信息同步与选举服务在中心间同步场景信息会将最早获取到场景信息的时间也同步到其他中心,场景信息同步与选举服务首先接收各中心的心跳报文,并从中获取到各中心的场景信息。当超过一定时间场景,信息不再发生变化时,选举服务再根据场景信息中的时间戳,在多个中心中选举出时间戳最早的场景所在中心作为该场景的主中心,如果所有场景信息获取的时间恰好一致,则选取场景信息中所属中心ID较小场景所在中心作为主中心。同时,如果场景主中心已经选举完成,之后又收到其他新接入中心的场景信息,并且场景信息获取到的时间比当前主中心上的场景信息的时间更早,也不再重新选举,以保证场景主中心的稳定性,如图5所示。

图5 场景信息同步与主场景选举示意Fig.5 Schematic diagram of synchronize of scenario and master center select

2.2.3 查询主场景实现

场景信息同步与选举模块对各中心的场景进行同步与管理。业务应用在分析决策中心运行时,通过场景、场景实例、子场景、子场景实例四元组信息进行管理,每个业务应用都运行在特定的四元组之下。业务应用下的进程向外界提供一系列的功能服务,等待客户程序(如:人机云终端)调用。各中心的四元组信息互相之间同步,形成全局的场景信息。

场景信息同步与选举模块实现中心间的场景选举与切换。场景选举与切换根据全局的场景四元组信息进行,如果某场景已有全局主场景,需要通过心跳进行维持；如果没有,则将中心优先级最高的那个场景选为主场景。应用根据选举结果,确定当前中心是不是工作主中心,是否需要进行计算与对外提供服务。

2.3 全局服务管理

服务信息全局同步模块进行多中心间服务信息同步。各中心内部的服务信息由服务管理功能实现,服务信息全局同步模块从各中心的服务管理模块获得服务信息,在各中心间交互,最终形成全局的分析决策中心服务信息,如图6所示。

图6 服务管理示意Fig.6 Schematic diagram of service management

根据系统的总体架构,全局服务信息同步功能实现了一、二级分析决策中心间、同级分析决策中心多活站点间、分析决策中心与模型数据中心间以及分析决策中心与监控系统间的服务信息的同步。在一、二级分析决策中心间相互同步少量的必要的服务信息；同级分析决策中心多活站点间相互同步各自中心内的服务信息；分析决策中心与模型数据中心间以及分析决策中心与监控系统间的同步方式相同,由模型数据中心或监控系统将自身服务信息同步到任意一个分析决策中心,分析决策中心只将必要的分析决策中心内的服务信息同步到模型数据中心或监控系统[15],模型数据中心或监控系统间不需要同步服务信息。不同中心间的全局服务信息同步采用可配置的方式完成。

2.4 中心分流定位服务

中心分流定位模块响应客户端负载分流查询请求,提供中心定位服务。通过综合中心状态信息、全局场景信息、全局服务信息,给出满足客户端需求的中心。默认情况下,根据负载均衡策略分配中心；当查询参数包含场景、场景实例、子场景、子场景实例时,除了满足指定的负载均衡策略外,还要选择有该场景四元组的中心；当指定要查询主场景中心时,则返回主场景中心。

中心分流定位模块根据客户端提供的参数查询,综合全局场景信息、全局服务信息、客户端位置信息获得特定的工作中心。客户端可以向任意一个中心的中心分流定位模块发送定位查询请求。

由于业务场景同时部署在多个分析决策中心,如果所有客户端请求都集中到某一中心,必然会造成该中心业务提供者负载过高,造成请求响应不及时甚至业务场景故障的情况,因此需要对客户端请求按照一定的负载均衡策略进行分流。

客户端在访问业务场景时,首先需要向任意一个分析决策中心的关口节点的中心分流定位服务查询所请求服务或业务场景的所属中心,关口节点上的中心分流定位服务根据各分析决策中心的状态及服务或业务场景负载均衡策略选取合适的分析决策中心,作为该客户端请求的业务场景的响应中心,并将包含该中心关口节点地址等内容的信息返回到客户端,客户端根据分流结果进行正常的服务或业务场景请求,如图7所示。

图7 客户端分流示意Fig.7 Schematic diagram of client distribute

2.5 客户端接口

客户端接口模块提供给人机终端等客户程序使用。新一代调控系统客户访问业务应用的服务时,需要首先调用负载分流提供的客户端接口(见表1),获取所要访问业务的中心信息,中心分流模块根据客户端请求信息及应用在中心间的分布情况为该客户端分配合适的中心,客户端获取到分配的中心后直接访问对应中心的相关服务。该分流方式需要客户程序主动调用查询接口。

表1 负载均衡接口Table 1 Application programming interface of load-balance

3 实验验证

文中搭建了实验验证环境,并完成相关关键技术实验验证。

3.1 环境部署

实验验证环境如图8所示,由3个分析决策中心、2个监控系统组成。其中,分析决策中心A与监控系统1位于南京,其他部分部署在北京。

图8 业务多活测试验证环境示意Fig.8 Schematic diagram of multi-active technologies verification environment

3.2 验证内容

在分析决策中心A、B、C上部署实时场景下场景实例与子场景实例均为1的数据库服务子场景,并部署运行于该场景下的模型修改服务,在3个不同的工作站上查询上述场景及服务对应的中心关口节点地址。模拟分析决策中心在故障、断网、正常情况下的中心关口节点地址返回情况以及在不同负载均衡策略下的返回情况。验证结果如下。

(1) 模拟中心故障后,查看中心状态信息,发现故障中心状态由正常变为故障,说明中心状态健康检查能够迅速识别出各中心的状态,并作为负载分流模块分流时的参考,确保负载分流模块只会将状态正常的中心的关口节点信息返回给客户端。

(2) 模拟当前人机云终端定位到的中心故障,之后重新定位人机服务关口节点,经过5 s左右,可由故障中心切换到状态正常的中心,说明GSLB服务在当前分流中心发生故障后能快速将人机云终端的访问请求分流新的中心。

(3) 为人机工作站配置所属中心信息并发起负载分流请求,全局负载分离会根据配置信息将根据工作站的请求分流到指定中心；将人机工作站所属中心配置删除后再发起负载分流请求时,负载分流模块会将客户端请求随机分配到任意状态正常的中心。证明全局负载分流模块可以根据不同的策略完成客户端请求的分流。

4 结语

文中在参考传统GSLB的基础上,结合电网调控系统分析决策中心业务的特点,提出了分析决策中心业务多活技术框架和相关关键技术。实验验证表明,该技术满足新一代电网调度控制系统“物理分布、逻辑统一”体系架构下分析决策中心的异地建设需求,实现了多个分析决策中心间负载均衡与故障冗余切换。后续将开展故障分析决策中心恢复正常后投运带来的相关技术问题研究,进一步完善分析决策中心业务多活技术方案。