PMS业务、特性和系统架构

我完成的工作概要
背景：以前PMS只管理接入和核心网的性能采集，U2000网管要求有统一的跨域性能管理系统，因此进行重构和融合。同时，管理容量的提升和竞争分析也要求有更大的管理容量。
任务：
1、对原有的PMS系统进行重构；
2、继承数通和传送原有的所有需求，新增支持PTN和VRP 8设备；
3、梳理原来比较混乱的接口，设计统一接口；
4、提出了只报告警、不存数据的TCA任务模式，适应大规模数据采集；
5、迁移到Linux + Oracle架构；
6、针对北向场景，设计了非数据库运行模式；
7、针对市场需求，进行管理容量提升的专项研究

PMS主要特性
1、数十种设备类型的性能采集
2、多种性能数据浏览方式：表格、折线图、柱状图
3、提供多种形式的北向接口
4、提供性能数据对比显示功能
5、提供性能门限告警及浏览功能
6、数据转储（按时间、按空间）
7、报表功能
8、数据聚合功能
9、双门限告警，告警抑制

PMS管理容量
独立网管+数据库模式：最大的50万/15分钟（1GB/天，保存30天）
北向接口+文本模式：最大500万/15分钟（10GB/天）

PMS系统架构

PMS EXE和采集器之间的架构说明

支持分布式采集

支持数据库和文本两种存储方式

多进程架构，不同的设备接口类型通过独立的采集器完成采集：SNMP采集器、FTP采集器、传输设备性能采集器。通过中心的性能管理进程进行集中存储。由于设备子类型繁多，每个采集器都需要进行复杂的适配。

平台+插件式的架构模式：平台部门开发平台和采集器，下游产品开发数据库脚本。

SNMP和FTP采集器采用DLL实现。由于PTN和传送设备的管理接口是私有的，因此由网元管理器自己实现采集。PMS和网元管理器之间采用消息结构进行进程间通讯。

EXE和DLL之间的接口主要包括：
1、运行时接口：同步采集对象元数据；
2、运行时接口：设置采集周期，起始、结束时间，Schedule；
3、静态编译接口：数据入库、写文件的函数接口；
4、静态编译接口：获取性能指标元数据；

PMS EXE和其他子系统之间的架构说明

PMS在TOPO注册消息，从TOPO子系统获取实体信息。实体信息发生变化时，通知PMS。另外，PMS也会和TOPO定期校验数据一致性并进行同步。

PMS模拟产生或收集的TCA告警通过消息接口上报给IMAP故障进程。

PMS接收来自北向子系统的性能数据上报请求，并通过XML/CORBA/TXT/TL1方式上报给OSS。

和设备的接口

路由器：SNMP/FTP/SFTP
接入设备：SNMP/FTP/SFTP
传送/城域以太：二进制私有协议/TL1

性能阈值告警的概念

接入、数通设备的性能阈值告警由网管计算后模拟产生，支持双门限。VRP8和PTN设备的性能阈值告警由设备自己产生。

PMS的概念模型

实体
指标
阈值（触发上下限、消除上下限）
指标组
性能采集任务（只产生阈值告警的任务、只储存数据的任务，或二者兼而有之）



设备侧组网拓扑
传送/PTN：网关网元+非网关网元，IP组网、ECC组网，链式组网。
接入：OLT + ONU组网，大量的小设备/单板
路由器：多种组网方式

PMS团队开发模式

对于接入和数通、VRP 8，由CMF完成采集模块的开发，由各TDT完成数据库脚本的注册。由于PTN和传送设备的设备管理接口是私有二进制的，且网管只能同时和网元建立一个连接，因此由网元管理器完成采集。
DataAdmin是一个独立的进程，用以管理数据库模式下的数据生命周期。相关策略有：按剩余空间删除；按指标组删除过期数据；数据转储。按时间删除数据的思路是"每天删除7天前的过期数据"

PMS系统共设计的复杂性

大数据容量
设备类型繁多、接口差异大，3大产品系列分属3个独立的产品线开发，实现千差万别，协调工作量大。
由于设备业务特性差异大，而且原来都已经有性能管理系统，融合难度大，需要仔细权衡、设计技术方案。
沟通的成本高，需要和很多个部门协调，实现一个技术方案的沟通工作量大。

PMS管理容量提升方案

针对不同的组网模式、网管硬件配置，有不同的优化方案：

1、普通场景：数据库优化
批量插入、忽略重复数据
字段优化：缩短字段、裁剪无用字段
分区表、分表
分散日志文件和数据文件的物理存储
优化数据库表参数（PCTUSED/PCTFREE）
另外，也受益于Oracle的效率

2、北向场景：文本存储
采用非数据库模式满足容量需求
统一北向文件格式和设备文件格式差异

3、所有场景：通过FTP采集提升性能
单设备批量上传多周期数据
一个设备设置了相同采集周期的所有实体通过一个文件上报
内存FTP

将计算、告警触发比较下移到设备实现，由设备主动上报

5、特定场景的优化方案
对于PTN、路由器等拓扑形态复杂的场景，采用上层设备代理采集的方案

PMS管理的业务领域和设备类型

传送：OptiX OSN1500、OSN2500、OSN3500、OSN7500
城域以太交换机：S2300/S3300/S5300
接入：UA5000/MA5600(T)/MA5200(G)/MA5300/MD5500
路由器：NE20/NE40(E)/NE80E/NE5000

PMS采集的主要性能指标

传送设备：

误码率、误码秒、抖动、漂移、不可用秒
15分钟性能、24小时性能，当前性能，历史性能
不可用时间（UAT）

城域以太交换机/路由器：
基于报文：上行速率、下行速率（基于不同实体：端口、单板、设备、VPN，基于协议：TCP/UDP/ICMP/ARP/单播/广播/组播），基于不同单位：速率、包数、字节数。非法报文、丢弃报文、转发报文。
基于设备：网络设备在线可用性,CPU平均利用率,内存利用率,网络设备内存池占用容量,网络设备内存池可用容量,
IGMP, QOS队列, 链路聚合，VLAN
基于测试：
SLA: 测试延时、丢包、抖动，DHCP, DNS, ICMP Echo, FTP, HTTP, Jitter, UDP

接入设备：
OLT及ONU PON端口报文流量统计
OLT及ONU CPU及内存监控与告警
SNMP报文流量统计
以太网端口流量统计表

PMS业务、特性和系统架构相关推荐

大型网站系统架构演化之路（转）
前言一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思 ...
大型网站系统架构演化之路
前言一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思 ...
【转】大型网站系统架构演化之路
前言一个成熟的大型网站(如淘宝.天猫.腾讯等)的系统架构并不是一开始设计时就具备完整的高性能.高可用.高伸缩等特性的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术 ...
解读大型网站系统架构的演化
解读大型网站系统架构的演化大型网站的架构是根据业务需求不断完善的,根据不同的业务特征会做特定的设计和考虑,本文只是讲述一个常规大型网站会涉及的一些技术和手段. 作者:李平来源:LEE的博客前言一 ...
系统架构的演变 -----自罗文浩
转自:https://my.oschina.net/lwhmdj0823/blog/617713 版权声明:罗文浩所有摘要: 一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的 ...
大型电商网站系统架构演变过程
一个成熟的大型网站(如淘宝.天猫.腾讯等)的系统架构并不是一开始设计时就具备完整的高性能.高可用.高伸缩等特性的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构. ...
大型网站系统架构的演化
大型网站系统架构的演化来源:http://www.cnblogs.com/leefreeman/ 声明:作者授权转载. 前言一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的 ...
大型分布式电商系统架构是如何从0开始演进
大型分布式电商系统架构是如何从0开始演进的?本文是学习大型分布式网站架构的技术总结.对架构一个高性能.高可用.可伸缩及可扩展的分布式网站进行了概要性描述,并给出一个架构参考.文中一部分为读书笔记,一部 ...
大型网站系统架构的演化【转自飘扬的红领巾】
前言一个成熟的大型网站(如淘宝.京东等)的系统架构并不是开始设计就具备完整的高性能.高可用.安全等特性,它总是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式.技术架构.设计思 ...

PMS业务、特性和系统架构

PMS业务、特性和系统架构相关推荐

最新文章

热门文章