网管开发的一点感悟

10 views
Skip to first unread message

sky

unread,
May 18, 2009, 5:54:25 AM5/18/09
to EMS网管开发


分布式组件技术,曾经是本世纪初一个比较热门的话题。主流的就是corba,com/dcom这集中组件。com/dcom因为本身只能在微软的
平台上使用,注定了它是一个不能流行的系统。而corba则因为各大主流厂商的纷纷加入而一是声势浩大。那么我的回忆就从corba开始吧。
首先我们要从EMS的作用开始说起,五大功能里面计费除去,其他的分别是配置,性能,告警,日志管理。基本这四个是主要的功能,其中又以配置为最复
杂难做的功能。请注意这里的难并不是指那种技术层次上的难,而是兼容层次上的难,同时还有很多附加的难以取舍的原则。下面一一说明后,再来讲讲为什么
CORBA曾经是一种理想的解决方案,而最后却又彻底的消失的过程。

1.总论
网管开发的难,难在什么地方。首先是对稳定性的要求,一个大型的网管首先就是对于一年之中关闭的时间有着严格的要求,除了一般意义上的
7*24,对于数据的热备份,容错,灾难恢复都有着严格的要求。因为网管的实时性的要求,这类后台程序基本都是采取的C/C++开发的,常常一个进程中
有着几十数百的线程的任务在运行。C/C++的一个特点就是直接操作内存,这个对于程序的稳定性是一个极大的挑战。因为大量的网络数据被采集来后,需要
进行处理,或者被分析后记录入内存,或者被写入数据库,或者通过网管界面进行查询。网管的长期运行的特性,哪怕是一个最小的内存泄露,又或者是某一个操
作写的不够精细科学(比如改操作需要进行频繁的小块内存分配释放),长期运行后都会造成不可测的后果,最后往往就是程序莫明的异常崩溃。这类问题中尤其
是不科学的内存使用的问题最难以返防,理论上,我们的内存使用都是通过OS来获得,用完后归OS收回,但是这个假定的前提是OS能非常理想的管理内存,
尔在120天,或者365天,每天数百万次级别的操作下,这个假设往往会把我们带到一个无法预测的环境。比如频繁的小块内存分配,释放,长此以往很可能
导致系统没有大块的连续内存可以分配。这个时候,往往程序就会出现一个莫明的CRASH,而从代码上分析,或者即使能通过调试器抓住现场也不能通过代码
来解释的。这里是一个简单的例子,以说明网管开发的稳定性的难度。

网管的第二个难点就是实时性的要求,网员管理系统是一个实时系统。对于NE的告警上报有着严格的时间要求,当一个EMS管理成百上千个NE的时
候,这不是一件容易的事情。先不论一个合格的网管需要带不同厂商的NE。即使是EMS管理本公司的NE一旦上了规模,如和能在最短的时间里面把告警采集
上了也是一件很困难的事情。困难的意思当然不是说在一个理想的平稳的情况下,困难的情况是当NE发生了告警震荡,或者某个NE出现了故障大规模的上报告
警的时候,如何能及时而且一条不丢的把告警采集起来。再比如如果要求管理以太网的性能(30秒),如果该设备数据很大的情况下,如何采集。(关于如何采
集的方法这里不谈,只谈总的难点)

网管的第三个难点就是大数据处理的要求,大量的数据被采集上来。如何能够把真正用户关心有用的数据能快速的查询出来,这是一件不容易的事情。比
如告警性能日子数据,往往真正关注的数据是被淹没在一片不被关注的数据中的。而且数据量大到一定的规模的时候,系统的查询速度是呈现线性下降的。TB级
别的数据库中,如何优化查询,使得数据查询速度能够不随着NE数目,和数据量的增长和运行时间的越来越长而保持一个常数反应速度,这也是一个需要认真研
究的课题。

网管的第四个难点就是配置管理,这个难点往往是随着工程而定的。具体的情况是NE的管理往往是随着需求在不断变化的,不同的NE都有着类似的业
务,而类似的业务只是“类似”,到了具体的配置上就有着不一样的细节。随着NE的升级,EMS需要处理无数这样的小细节。如何能跳出这些细节用统一的模
型来管理,或者通过一个抽象层来实现设备的归一化。理想和现实常常有着不可调和的矛盾。

网管的第五个难点就是第三方的管理。网管的开发的最终目的就是把不同供应商所提供的设备都通过同一个平台管理起来,这个才是最终目的。如果网管
只是能够把某一个公司的设备管理的很好,而其他的设备不能够很好的管理起来。或者管理管理效率要比本公司的设备管理效率低很多,那么这个网管也不是一个
合格的网管。第三方的难难在哪里?难在如何搭建一个平台,难在设计这个项目的人是否能够在一开始就很鉴定的拒绝在自己的NE中为自己的网管做一些特定的
优化设计。这个尺度是很难把握的。通用通常是拒绝效率的,尤其是执行效率,而网管是一个追求效率的地方。就算建立了一个平台,提供一个方便的开发接口支
持其他设备的开发也是需要仔细考虑的。

sky

unread,
May 18, 2009, 5:58:43 AM5/18/09
to EMS网管开发
分布式组件技术,曾经是本世纪初一个比较热门的话题。主流的就是corba,com/dcom这集中组件。com/dcom因为本身只能在微软的
平台上使用,注定了它是一个不能流行的系统。而corba则因为各大主流厂商的纷纷加入而一是声势浩大。那么我的回忆就从corba开始吧。首先我们要
从EMS的作用开始说起,五大功能里面计费除去,其他的分别是配置,性能,告警,日志管理。基本这四个是主要的功能,其中又以配置为最复杂难做的功能。
请注意这里的难并不是指那种技术层次上的难,而是兼容层次上的难,同时还有很多附加的难以取舍的原则。下面一一说明后,再来讲讲为什么CORBA曾经是
一种理想的解决方案,而最后却又彻底的消失的过程(现在在EMS->NES的北向接口还存在,但是这个显然不是CORBA的本意了)。

整理的一下,这个属于绪论部分,后面计划慢慢写。

sky

unread,
Jul 14, 2009, 5:49:10 AM7/14/09
to EMS网管开发
总结总结,继续写。

techabc

unread,
Jul 14, 2009, 9:57:35 PM7/14/09
to EMS网管开发
总结的很好,全是干货啊~
可否分享一个提纲先?

Hailong Shu

unread,
Jul 14, 2009, 10:05:24 PM7/14/09
to ems...@googlegroups.com
以前准备好好写一下的,不过写了个绪论(就是贴出的)这部分就没有继续了。主要是感觉写了也是给自己看而已。
打算是后面就前面提出的几个问题来详细写写。
除了前面提出的5个问题,还有一部分就是CORBA为啥最后只能存在于对上的NMS了。
 
其实配置部分,对于国内厂商来说作用不大,都是自己管自己的设备。不管第三方,夹了很多私有协议,或者是把私有协议用SNMP包装一下。我说的这部分配置是针对提供网管开发框架的软件服务商而言。


钱不够

unread,
Jul 19, 2009, 5:15:46 AM7/19/09
to ems...@googlegroups.com
不错


2009/7/15 Hailong Shu <shuha...@gmail.com>

techabc

unread,
Aug 12, 2016, 5:02:42 AM8/12/16
to ems...@googlegroups.com
sky兄,是否还记得这里?
大家,是否还记得这里?
大家,安好?

不错
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "EMS
网管开发" group.
To post to this group, send email to ems...@googlegroups.com
To unsubscribe from this group, send email to ems-nms+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/ems-nms?hl=en
-~----------~----~----~----~------~----~------~--~---


Hailong Shu

unread,
Aug 12, 2016, 5:37:49 AM8/12/16
to ems...@googlegroups.com
我已经离开电信行业不做EMS了。好多年了,大家最近在做什么?

--
您收到此邮件是因为您订阅了Google网上论坛上的“EMS网管开发”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到ems-nms+unsubscribe@googlegroups.com
要发帖到此群组,请发送电子邮件至ems-nms@googlegroups.com
访问此群组:https://groups.google.com/group/ems-nms
要查看更多选项,请访问https://groups.google.com/d/optout

Reply all
Reply to author
Forward
0 new messages