电信级Inventory系统的NoSQL实现(未完成)

之前一直是从事通信行业OSS系统的设计和实现。
电信OSS领域有两个至关重要的系统Inventory, Service Desk,这两个系统可以看成是整个OSS业务中的两个数据泵,是整个OSS Solution集成的枢纽。
Service Desk是作为人机交互的request数据(来自business或者trouble)的流转枢纽。
而Inventory则作用更偏向于solution-solution集成的枢纽。
不同厂商的Solution或者同一厂商的不同业务域软件,都会在这两个软件节点上做集成。
在各种OSS架构图中可以很容易发现,这两个系统通常都会位于整个星形结构的中心部位。
因此可以说,这两个系统的设计实现水平和实施水平,会直接最大程度影响整个OSS的实施质量和管理难度,这两个系统也是最容易为公司整个OSS产品线打下大单的核心系统,掌握了这两个系统,就掌握了整个OSS集成的主动权
不管是基于ITIL还是eTom模型划分,这两个系统都会贯穿整个分层模型中的没个部分都要和其中至少1个打交道

电信Inventory系统由于涉及不同业务领域,各个领域需求与模型差异又很大。比如传输和无线,这两个领域规范模型和业务关注点就大相径庭。但抽象来说,各种Inventory系统最后都会集中在几个方面上:

1.层级关系

2.物理关系,主要指网元与网元间的连接拓扑关系,这里还不涉及真实的物理位置

3.Service到resource的承载关系

3.地理关系甚至包括更细化的物理位置信息

其中获得层级关系相对是最容易实现,如果设备提供了标准化的北向接口,则很容易通过这些接口从EMS获取这些数据,再通过ID层次建立各个领域的设备层级关系。如果没有北向接口,则可能要通过文件ftp或者数据库同步的方式从要管理的设备中抽取设备信息和层次结构。通常情况取得层次结构的设备id已经足以构建出网元设备的从属结构。

物理关系相对就复杂很多,不同的业务solution对这个物理关系理解的深度和广度差异会很大。

以无线资源网管为例,它关心的物理关系大多只是网元到网元层次的物理连接,除了在无线和核心交接处的网元连接会呈现小规模网状连接,其他多数情况是星形(也可以说是树形)连接层次。

在传输网中物理关系则会涉及高阶低阶的复用承载关系,自愈环是否闭合这些更复杂的网状拓扑信息,这种网络是多层次的大规模网状结构。

传输网的invenroty采集和拓扑分析往往是电信网invenroty系统比较核心的也比较复杂的部分,它的难点在于整合集成不同厂商北向接口和复杂的拓扑关系计算上。

猜你喜欢

转载自ppgunjack.iteye.com/blog/1171719
今日推荐