消息计费在线接入平台负载均衡项目的解决方案研究

2021-10-15方军丘华

电脑与电信 2021年7期

方军丘华

（中国联合网络通信有限公司广东省分公司，广东广州 510000）

1 引言

由于总部消息计费总体技术架构分为总部和省分两级，均为统一版本，总部部分在总部统一部署，省分部分在各分省部署。其中消息会话管理子系统主要涉及总部、省分部署。省分部署的消息控制节点为多套独立的节点，需要前端增加负载均衡的能力。实现计费消息负载均衡，能根据业务要求进行业务级的路由，实时进行在线和离线的切换，同时做到消息级的负载均衡，支撑后端服务分布式集群部署。

2 实施目标

（1）新增会话级负载均衡网元CCR消息到省分消息计费消息控制节点主机；

（2）省分部署的消息控制节点集群单节点故障时，故障节点会话记录快速均衡到集群；

（3）支持动态添加省分消息计费的消息控制节点；

（4）实现本省在线接入链接消息计费系统，产生负载均衡路由调整/变化时保证DCC消息不丢失。

3 技术方案

3.1 实现负载均衡

核心思想：根据处理的业务量进行负载均衡，业务量以计费请求消息数与计费应答消息数之差作为衡量(优先实现这种策略)。启用计数器登记计费请求消息数与计费应答消息数之差，每发送一个计费请求，计数器递增一；反之每收到一个计费应答，计数器递减一。业务流程如图1所示。

图1 业务流程图

算法实现：负载均衡模块对每个计费请求消息进行负载均衡选择消息计费节点的时候，先判断是否能直接路由，如相同会话相同号码发往同一个节点，不能对所有消息计费节点的计数器排序选择最小的发送。特别地，如果有新节点添加进来，这个算法也不需要重置计数器；采用计费请求消息数与计费应答消息数之差作为计数器的值，可能由于业务量少或者某个主机处理能力比较快而相对比较集中地把计费请求发送到一个主机节点上，为了避免这种情况，在负载均衡模块实现的时候，当存在多个计数器都是最小值的时候，通过随机函数计算选择某个节点。

负载均衡设备可以实现客户端连接级和请求会话级的负载均衡，同时可以开启DCC的会话保持功能，并根据实际生产情况，调试负载均衡的算法：

（1）轮询；

（2）加权轮询；

（3）响应时长加权。

在Diameter协议的负载均衡会根据负载均衡的计算方法，将省分接入节点分发到消息计费服务器上。负载均衡流程图如图2所示。

图2 负载均衡流程图

（1）Diameter握手进程，CER请求到负载均衡设备,负载均衡设备根据轮询的算法消息计费Server 1，同时在CER/CEA中，在server的HOST ID可透传给client，负载均衡设备也可以替换。

（2）第二个Diameter CCR请求发送到负载均衡设备，负载均衡设备解析Session-id=y，是一个新的请求，那么负载均衡设备会根据轮询的算法，把请求送到Proxy Server 2。在这里负载均衡设备是把Diameter协议中的AVP作为Session-id的值作为与后台服务器会话的标准。

（3）假设负载均衡设备收到第三个CCR请求，解析其Session-id=x,也是一个新的请求，那么根据负载均衡的算法，发到消息计费Server 1。

（4）收到第四个CCR请求，解析其AVPSession-id=y，那么根据AVP会话保持原则，负载到消息计费Server 2。

（5）收到第五个CCR请求，解析其AVPSession-id=x，那么根据AVP会话保持原则，负载到消息计费Server 1。

（6）收到第六个CCR请求，解析其AVPSession-id=y，那么根据AVP会话保持原则，负载到消息计费Server 2。

（7）由于Diameter协议是异步协议，所以来自Server的响应也是异步的。

（8）负载均衡设备不会透传DWR/DWA，而由负载均衡设备分别回应。

（9）当网元发出DPR，负载均衡设备把请求广播到所有消息计费Server服务器，如果只是消息计费Server端发起DPR请求，那么负载均衡设备只是响应这个Server服务器，不会影响其他的网元请求以及Server服务器。

3.2 实现系统自动应急响应

业务流程如图3所示。

图3 系统自动应急流程图

（1）负载均衡模块通过定期Health Check Request心跳健康检查侦测后台消息计费服务器是否正常；

（2）网元请求端正常发送DCC请求，负载均衡模块按照轮询的负载均衡方式分发到消息计费Server 1节点上处理；

（3）此时消息计费Server 1服务器节点失效；

（4）负载均衡设备定期Health Check心跳健康检查侦测消息计费Server 1节点失效，将该信息反馈给云化管理平台；

（5）云化管理平台得知消息计费Server 1节点失效，准备启用消息计费Server 2节点；

（6）云化管理平台停止服务器消息计费Server 1节点，释放相关资源，并将此节点从消息计费动态云化资源池中移除；

（7）云化管理平台启用服务器消息计费Server 2节点，并完成业务可用性验证；

（8）同一个会话新接续DCC请求达到负载均衡设备，不会再分发到失效的消息计费Server 1节点，而是分发到Proxy动态云化资源池中有效的消息计费Server 2节点处理；新会话的DCC请求到达负载均衡设备，也分发到Proxy动态云化资源池有效的消息计费Server 2节点处理。

3.3 实现在线动态扩容

CMP要正确路由，首先要能识别每个链路是来自Proxy、FEP-CF、会话管理Session_Manager还是CMP管理客户端。这个和CMP在与它们建立连接时，是客户端还是服务端有关系。如果CMP是它们的客户端，链路的建立是CMP的主动行为，对于CMP识别这个链路是不存在问题的；但如果CMP是服务端，这个链路就要识别。根据系统目前的业务情况，CMP要支持：

（1）DCC协议：数据业务、语音业务、增值会话业务、WLAN业务

（2）SMPP+协议：短信业务

（3）SGIP协议：增值事件业务

支持同种协议时，相关流程如图4所示。

图4 在线动态扩容流程图

（1）网元请求端正常发送DCC请求，负载均衡设备按照轮询的负载均衡方式分发到消息计费Server 1节点上处理；

（2）负载均衡设备定期反馈Proxy负载信息至云化管理平台；

（3）云化管理平台检测Proxy负载是否超过设定阈值，如果超过阈值，则需要启动新Proxy资源节点；

（4）云化管理平台启动新资源节点消息计费Server 3；

（5）云化管理平台要求负载均衡设备验证并反馈新节点消息计费Server 3的可用性；

（6）云化管理平台根据反馈信息判断新节点是否可用；如果可用，通知负载均衡设备将新节点消息计费Server 3加入到Proxy云化资源池中；

（7）新会话请求按负载均衡方式分发到原有效消息计费Server 2节点处理；

（8）另一个新会话请求按负载均衡方式分发到新启用的消息计费Server 3节点处理。

3.4 在线版本升级过程实现

集群中的CF应用版本升级有几种方式：

（1）Proxy全业务切离线，再升级应用版本（手工方式）；

（2）CMP支持设置节点升级模式（后续说明这个模式），手工逐一停节点，再升级应用，启动应用（手工方式）；

（3）CMP自动升级方式。

进入节点升级模式时，CMP断开该节点的连接，会把该节点的会话记录设置为故障，需要同步到其它节点，CMP启动一个新的后台进程进行升级，当CMP完成升级，该节点以一个新节点添加的方式重新加入集群中。升级完成分单节点完成和整个集群完成。升级过程的状态，比如升级完成了几个节点，还有几个节点的信息，CMP需要提供信息显示。一个节点的应用在升级过程中大概需要耗时100ms，这跟不同的应用启动时间有关。总之，能提供新节点的添加命令，就能通过手工逐一升级每个节点的应用。

升级说明：

（1）升级模式修改为离线控制模式，因为消息计费系统的升级时会造成CCA返回错误码；

（2）保留升级模式的部分手工操作命令，并能配合Proxy进行离线容灾机制的切换。

在线升级流程如图5所示。

图5 在线版本升级流程图

（1）云化管理平台启动Proxy版本升级过程；

（2）云化管理平台卸载部分在线资源节点到空闲资源池中；

（3）云化管理平台向空闲资源池中可用的节点发送Proxy新版本升级指令；

（4）安装新版本Proxy应用；

（5）启用新版本Proxy应用；

（6）云化管理平台要求负载均衡设备激活并反馈新版本节点的可用性；

（7）云化管理平台要求负载均衡设备卸载旧版本Proxy节点；

（8）负载均衡设备发起并停止旧版本Proxy节点。

3.5 实现在线会话离线

系统由Proxy模块向网元提供服务端口，同时具备对网元计费请求进行“在线”“离线”方式的切换。Proxy以SOCK客户端的方式连接fep_ctrl模块，在SOCK链路异常、无法通信的情况下，就会进行离线切换，连接到offline_cf模块。实现从系统层面、业务层面、网络物理层面综合考虑，三者在满足特定的条件都要进行离线切换：

（1）当Proxy与fep_ctrl之间的链路不可达，把消息计费该节点业务全部切到离线；

（2）当消息计费系统处理业务出现故障时把当前会话切换到离线。