故障管理系统架构优化的新方法

故障管理系统架构优化的新方法

柴华

中国移动通信集团天津有限公司 天津市 300303

摘要 某省移动故障管理系统承载着数百万级别的网元监控任务，需要对各类业务系统、网元进行全面监控，准确定位故障点，实时进行处理。目前的架构已经无法兼顾告警业务容量和质量，业务恢复耗时较长、影响范围大、用户感知差，无法满足运维监控人员对网元进行实时监控的需求。随着SDN/NFV网络的发展，以及集中化运维管理模式的推进，对网管管理支撑系统的要求也发生了比较大的变化，弹性伸缩、故障快速切换、能力开放等等都成为下一代OSS的基础能力要求。

关键词 故障管理系统 架构优化

1现状

1. 1. 故障管理系统简介

故障管理系统旨在实现全专业的、标准化的、实时的设备告警监控、关键指标监控、业务质量监控，实现面向网络、面向业务、面向客户的专业内、跨专业、端到端的关联监控，实现网络信息实时综合监控，支撑网络监控人员和故障处理人员快速发现、及时响应故障、准确定位网络故障，缩短业务中断时长，实现重要客户、重要业务的重点保障。系统主要支撑“发现故障、分析故障、解决故障”的各项故障管理工作，以及网络信息实时综合展现。主要面向网络监控人员、故障处理人员，实现告警监控、性能监控、拓扑监控、集客业务监控等功能。

1. 2. 目前面临的问题

（1）告警风暴频发，故障管理系统业务不堪重负，系统响应缓慢

面对告警风暴频发，告警风暴来临时告警消息堆积拥塞，导致故障管理系统处理效率低，严重时致使故障管理系统瘫痪，业务中断，恢复正常业务耗费时间较长，影响对网元告警信息的实时监控能力，不能满足监控要求。

（2）功能升级对故障系统业务的影响问题

故障管理系统在如何面向业务端到端，实现精细化运营，快速实现系统功能更新升级方面面临着挑战。

（3）系统没有系统级的高可用方案，容灾能力不足

故障管理系统除数据库及消息平台外，没有应用级容灾能力，即当应用程序异常或应用程序所在主机故障时，只能通过人工修复的方式进行故障修复，故障修复时间较长，无法达到通信网实时监控的要求。

（4）系统扩展能力差

传统的IT系统架构按照纵向垂直形式演进，导致业务、功能、数据耦合度较高，无法横向扩展及服务能力的延伸。引入云计算架构设计理念，一是通过对应用程序的改造，使系统支持横向扩展，可以使用多台中低配置服务器进行分布式计算；二是可以将所有的数据、应用、账号等IT资源均由平台管理员全面保护、管理，同时对服务和应用进行性能方面的监控。

1. 3. 故障管理系统云化主要工作内容

按照国际通用研究标准，“云计算”服务模型标准为：基础设施即服务（IaaS）、平台即服务(PaaS)、软件即服务(SaaS)。以上三种模型的友好特性是企业用户可以根据自身需求定制化使用云计算能力，按需付费，企业用户可以有针对性的进行平台资源的整合，通过资源的集约整合、兼容性强易于后期平台扩展。

针对已部署成熟的企业级信息化平台的企业来说，为了在充分利用已有资源的基础上降本增效，将已有应用系统进行云化，实现系统降低运维成本、提升系统容错性和系统功能高可扩展。

1. 4. 改造目标

一、应用层对一定范围内的硬件故障免疫

1. 系统的运行不受池内基础设施故障的影响，用户不感知底层资源的故障。

2. 基础设施故障后只需事后通知维护人员简单推车换硬件，整个过程不停业务。

二、业务量增长自适应

1. 在遇到大面积故障、自然灾害等告警风暴或DPI突然增长等场景时，能秒级自动调度闲置资源，提升处理能力。

2. 在网络规模、业务数据量增长时，不用调整架构，能通过简单快速扩容来提升处理能力。

三、硬件能快速部署释放

1. 当资源池规划分配出新的基础设施后，系统通过简单配置快速完成应用部署并提供业务处理能力。

2. 当系统整体有富余资源情况下，通过简单配置就能释放资源。

四、具备向下一代OSS演进的基础

1. 通过云化改造，应用去状态化，向微服务架构演进打基础。

2. 具备微服务架构的平台能力，为实现应用解耦，支撑应用百花齐放做准备。

3. 支撑向下一代OSS平滑演进。

2.云化技术方案

2. 1. 系统功能架构

故障系统云化改造后的功能架构图：

2.2实施过程遇到的问题及解决办法

问题一:业务风暴来临时，云资源不能满足业务增长要求

解决办法：通过PASS层与IAAS层的资源调度接口，实现对虚拟机的资源的申请和释放。

• 当告警风暴到来的时，故障系统云管理平台告警核心处理程序进行动态扩展，此时核心处理程序会向云资源池申请资源，当云资源池的资源不够时，云管理平台根据虚拟机模板向IAAS层申请虚拟机资源，将扩展的告警核心处理程序运行在新的虚拟机上。

• 当告警风暴结束后，风暴结束后故障系统云管理平台告警核心处理程序进行动态收缩，当云资源池的资源冗余值高于阈值，云管理平台根据虚拟机模板向IAAS层申请虚拟机资源释放，使云管理平台资源能够充分利用。

问题二:并网期间数据和功能一致性验证

• 数据一致性：通过每日对上百万条告警进行字段粒度的一致性对比，将两个系统的数据一致性由60%上升至100%。

• 业务规则验证：对预处理、派单、关联等600余条业务规则进行迁移并充分验证，进行两系统规则处理结果对比，一致性达到100%。

• 对云化系统进行配置优化：通过对某省现网告警数量及分布情况的分析，对系统中的消息集群实例数、缓存大小、容灾参数进行优化调整，使系统充分适应某省现网情况。

• 客户端功能测试：以现网为标准，对云化系统客户端进行全功能遍历验证，直至完全一致。

三 总结

在故障管理系统云架构设计与实现这个项目中，主要完成了以下工作：

实现了可扩展的架构：通过云化改造，实现了软件及硬件整体兼容和横向可扩展能力，实现系统资源的统一灵活调度和编排，支持纵向和横向灵活扩展，大大提升提升资源使用效率和可靠性，为功能层面的云部署提供有效的支撑能力，从系统能力角度看，为下一代网管演进及微服务化奠定了基础。

实现完全弹性伸缩：实现进程级的完全弹性伸缩，系统忙时向云管平台发起请求快速请求资源，闲时自动释放资源，达到资源利用率提升，快速应对业务增长的目标。

消息级别的高可用：利用Kafka消息集群、Redis缓存集群、流处理框架，实现告警、性能消息At least once消息级高可用，系统的故障恢复、业务数据质量取得了本质上的提升，达到了业务高可用的目标。

故障能自愈：能主动发现主机物理故障、磁盘空间满、网络中断、进程异常停止等问题，并能够主动的进行资源申请、资源加载、应用程序的迁移和恢复。

参考文献：

[1]移动通信系统的网络优化技术的研究与实践_姚羽

[2]移动通信系统的网络优化技术介绍_吴蒙

3