网管开发的一点感悟

    作者 bach_2008@hotmail.com

   本文所提及的观点都是个人理解，欢迎探讨。这里的部分属于总论，后面会慢慢写完。
   分布式组件技术，曾经是本世纪初一个比较热门的话题。主流的就是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中为自己的网管做一些特定的优化设计。这个尺度是很难把握的。通用通常是拒绝效率的，尤其是执行效率，而网管是一个追求效率的地方。就算建立了一个平台，提供一个方便的开发接口支持其他设备的开发也是需要仔细考虑的。