综合网管和资源管理系统的关系Word文档格式.docx
《综合网管和资源管理系统的关系Word文档格式.docx》由会员分享,可在线阅读,更多相关《综合网管和资源管理系统的关系Word文档格式.docx(9页珍藏版)》请在冰豆网上搜索。
光缆段、光缆附件信息(光纤接头盒、余长点)、ODF、光交接箱、光分纤设备等
传输网络资源:
DWDM/PDH/SDH设备物理资源、DWDM/PDH/SDH逻辑资源(如光波道、段、通道、槽道、电路等)
接入网络资源:
IDLC设备及逻辑资源、PON设备及逻辑资源、FWA设备及逻辑资源(基站设备、基站控制器、固定用户站设备)、xDSL设备及逻辑资源、以太网接入设备资源等。
数据网络资源:
ATM、IP、DDN、帧中继、分组交换等网络设备资源及逻辑资源
交换网络资源:
交换节点、固定电话网络交换机、局号资源、MDF横列、中继电路、信令链路等。
动力资源:
电源设备:
发电机、高压变配电、低压配电、变流设备(开关整流器、相控整流器)、直流配电、蓄电池组、UPS、逆变器等;
空调设备:
中央空调、专用空调(恒温恒湿空调)、分体空调等。
时钟资源:
BITS设备、时钟通道。
业务资源:
业务类型、业务实例。
客户资源:
客户类型、客户实例。
第2章综合网管对资源数据的需求
2.1综合网管系统和资源数据的关系
联想提供的综合网管产品是一个完整的OSS系统,除了包含了基本的故障管理和性能管理等网管功能外,同时提供和资源管理系统的紧密集成,支持网络资源的综合呈现,支持故障对业务和客户的影响分析,支持端到端的业务的管理,支持用户订单的处理,实现业务的快速开通等综合管理功能。
这些功能是通过对告警数据、性能数据,逻辑资源数据、物理资源数据、业务资源数据的综合分析和处理实现的,其中告警数据、性能数据和逻辑数据可以通过网管系统对智能网络设备的数据得到,但物理资源数据和业务资源数据不能直接从网络设备中得到,需要从企业的资源管理系统获取。
下表为综合管理功能对资源数据的依赖关系:
综合管理功能
网管系统
资源管理系统
备注
故障的定位
实时告警
基于拓扑的故障的相关性分析
实时告警,逻辑资源数据
物理资源数据
故障对业务和客户的影响
业务、客户数据
网络资源的综合呈现
逻辑资源数据
业务、客户、物理资源数据
业务开通
业务开通指令
业务资源的预占,规划和状态查询
端到端的业务管理
网络性能数据
业务资源
由此可见,综合网管系统的功能和资源数据是紧密相关的,是以资源数据的分析为基础的,北京电信的综合网管的建设必须将现有的资源管理系统中的与网管相关的数据通过专用的数据接口集成进来。
2.2综合网管需要的资源数据
综合网管需要的资源数据主要是指与网管的功能紧密相关的,从网络设备和网元管理系统无法自动提取的设备的相关描述信息、网络的物理连接关系数据以及和网络所承载的业务和用户等资源数据,具体包括以下内容:
●地理层次结构
●资源类型
●专业网
●设备功能
●设备技术
●复用层次
●电路类型
●资源的状态信息
●路由类型
●服务类型
●厂商
●站点
●位置
●客户信息
●设备类型
●设备
●缆线段
●缆线传导介质
●电路
●路由段
●端口
●通道
●服务
●服务资源
详细描述请见文档:
DataimporttoNetracInventorydatabase.doc
2.3资源数据的有效性对综合网管的影响
资源数据的有效性主要是指其完整性和正确性以及和实际网络配置状态的一致性,因为经过上面的分析可以看出:
许多综合管理功能是通过对的资源数据的分析做出的,所以资源数据的有效性将直接影响到综合网管的管理功能,例如:
无法完成基于网络物理结构的告警相关性分析,无法实现快速的业务开通等等。
第3章
互联接口技术建议
3.1综合网管系统与资源管理系统的互联点
综合网管系统与资源管理系统是两套完全独立建设的系统,但同属于电信运营支撑系统的范畴,两套系统在数据和业务上存在着互补性,综合网管系统要利用资源数据进行面向全网的综合分析,而分析结果则可以在资源管理系统里进行呈现,另一方面,综合网管系统还可以向资源管理系统提供动态的配置数据,使得资源管理系统能够动态且自动地呈现出网络的运营状态,因此,在两套系统之间很自然地就要实现数据和业务的互联互通。
为了实现两系统在数据和业务上的互联互通,需要在两系统间定义互联互通的协议,并通过相应的接口来实现。
从数据和业务两个层面来考虑,相应的定义“数据接口”和“功能接口”。
3.1.1数据接口
数据接口是最基本的互联互通协议,通过数据接口,两系统可以实现数据的共享和互访,避免了在两套系统内各自维护不一致数据所造成的额外投资和额外工作量,实现了数据的高利用率和一致性、完整性。
数据是电信运营支撑系统的基础,如果在电信运营支撑系统内出现数据在一致性和完整性上的缺陷,那么除了上面提到的额外投资和额外工作量外,电信运营支撑系统在功能上也不能够对业务实施强有力的支撑,例如,如果综合网管系统没有完整的资源数据,那么在网络故障的管理上,我们就很难判断出故障点,以及故障所造成的影响。
通过数据接口,我们在最基本的层面上实现了两系统的互联互通,为更进一步通过“功能接口”来实现两系统的互融提供了坚实的基础。
3.1.2功能接口
功能接口是面向业务的互联互通协议,通过功能接口,两系统可以实现应用功能的互访,从而实现业务的互通,例如,综合网管系统对故障进行分析,其分析结果可以通过调用资源管理系统的相应呈现功能,在资源管理系统里呈现出来,另一方面,资源管理系统也可以通过功能接口向综合网管系统主动地发起对网络的分析和管理请求。
通过功能接口,使得两系统能够相互配合实施业务支撑,比如,业务的受理与开通,无论单独的资源管理系统,还是单独的综合网管系统,都是无法独立完成,在进行业务受理与开通时,首先需要在资源管理系统里查询相关资源的状态并实施预占,然后再在综合网管系统里实施具体的配置与测试等操作,最后返回到资源管理系统里将预占的资源修订为实占,从而完成业务的开通,在这个流程中,如果没有功能接口的支持,我们只能在两个系统间进行切换操作,不仅不方便,还很容易出错。
而通过功能接口,我们就可以构造出一个统一的界面来实施业务,这里获得的好处,不仅是操作上的方便或高效,更重要的是我们能够对业务流程实施控制和管理。
3.2互联互通接口要考虑的问题
在定义互联互通接口时,要着重考虑如下几方面的问题:
3.2.1安全性
应该引入完善的认证与授权机制,以保证对数据和功能的访问是受控的,避免非法的操作,以及有意或无意的操作对系统所造成不良干扰,例如,没有限制的增删数据就会造成系统数据的混乱。
3.2.2隔离性
虽然综合网管系统与资源管理系统存在互补性,但由于这两个系统所处理的问题域并不相同,有着各自的私有数据和私有功能,因此互联互通接口要有很好的隔离措施,保证私有数据和私有功能的安全。
3.2.3灵活性
综合网管系统和资源管理系统作为两个独立建设的系统,其实施技术都不尽相同,存在着不同的技术理念,数据在定义、格式等方面都有较大的差异性,因此,互联互通接口要有足够的灵活性来解决这些差异性所造成的问题,例如,定义不同的数据转换规则,从而保证数据在两个系统间平滑的转移。
另外,综合网管系统与资源管理系统的互联互通并不是从一开始就明确所有的需求,这是一个随着认识的深入而逐步完善的过程。
因此,互联互通接口要有足够的能力来适配新需求的出现。
3.2.4扩展性
互联互通接口当前首要的是要解决综合网管系统和资源管理系统之间的关系,但互联互通接口也潜在地要解决与其它系统(计费、营帐等)的关系,因此,互联互通接口在技术上要有良好的扩展能力,例如,对J2EE、CORBA等技术的支持,以方便的扩展到其它技术领域和问题领域。
3.2.5数据一致性
通过互联互通接口,综合网管系统/资源管理系统都不再是单纯的面对存储在自身系统内的数据,也有操控对端数据的能力,因此,互联互通接口必须要承担起维持两系统间的数据一致性的责任。
3.2.6高效性
互联互通接口要保证适当的运行效率,根据需求提供实时或准实时的交互性能。
3.3互联互通接口的技术架构
基于上述对互联接口在安全、灵活、扩展等方面的考虑,互联接口适宜采用“桥接器(BridgeConnector)”技术来实现,其技术架构如下图所示:
技术架构图
桥接器独立于综合网管系统和资源管理系统,它既不属于综合网管系统,也不属于资源管理系统,而是介于两者之间的一个中间层。
通过桥接器,我们可以在综合网管系统和资源管理系统这两个异构系统间建立起稳定可靠的连接,实现数据共享和平滑互访,实现系统功能的相互调用,满足安全性、隔离性、灵活性、扩展性、数据一致性等多方面的要求。
3.3.1为什么要构建桥接器
当我们考虑到要在两个系统之间开放互联互通接口的时候,通常我们的第一个原始想法就是两个系统互相直接向对端开放接口,如下图所示:
直接开放接口
然而这种直接开放接口的技术具有很大的局限性:
首先,这是一种僵化的手段,资源管理系统暴露给综合网管系统的接口,依赖于综合网管系统对资源管理系统所提出的需求,也就是说接口与具体的需求是紧密绑定的,一旦需求发生变化,那么,接口也要跟着变化,否则就不可能实现访问。
最简单的情形,综合网管系统要求增加访问资源数据的属性字段,资源管理系统的接口就必须要进行改写,增加这些属性字段。
其次,这种接口技术只能实现数据层的互联,而不能(或者很困难)实现业务层功能的互联,因为两个系统是异构的,采用的是不同的技术和系统平台,因此两个系统要实现直接的功能互访相当困难,除非它们同时遵循相同的体系规范,如J2EE。
因此这种接口技术的典型实现方式就是开放数据库视图,或者通过平面数据文件进行导入导出。
第三,这种接口技术很难维持数据的一致性,由于两个系统内在的数据模型是异构的,资源管理系统能够开放的数据接口只能够做到依据其内在的数据模型而开放,因此,综合网管系统并不能够直接使用从接口中获取的数据,需要对其进行再加工,转换成综合网管系统内部的数据模型,这样同一个东西就被存储在了两个不同的地方,在没有额外的机制保证下,这种存储在两个系统中的数据极易发生不一致,只要资源管理系统对数据进行了变更,综合网管系统内的资源数据就处于不一致的状态,直至综合网管系统重新从资源管理系统中获取数据。
第四,扩展性差,由于这种直接接口是针对了某些具体的需求而设定的,因此,第三方应用就不可能使用这些接口,而必须在两系统间进行需求界定,然后开发开放相应接口。
因此,对于存在有很多个独立系统的情形,这种直接接口技术的可实现性就变得很低,很难想象开发和维护一大堆接口的工作量是多么巨大。
由于桥接器能够内建多种机制来保证安全性、隔离性、灵活性、扩展性、数据一致性等多方面的要求,因此桥接器是实现互联互通接口的比较好的技术手段。
桥接器就好像是多个独立应用系统间的交通枢纽,各应用系统之间不需要发生直接的联系,而是经过桥接器的调度。
3.3.2桥接器的技术实现
3.3.2.1基本原理
桥接器的基本技术原理如下图所示:
基本原理图
详述如下:
适配器(Adapter)
适配器是在应用系统与桥接器之间建立访问联系的构件,适配器实现如下(主要)功能:
⏹采取适当的技术(如Socket、RMI-IIOP、DBconnection等)实现应用系统与桥接器的可靠连接
⏹应用系统通过Adapter-Agent在桥接器中注册允许被访问的功能
⏹应用系统通过Adapter-Agent调用注册在桥接器中的功能
⏹桥接器通过Adapter-Agent识别应用系统的数据模型
⏹应用系统通过Adapter-Agent向桥接器上报数据
⏹桥接器通过Adapter-Agent向应用系统传送数据
其中,Agent是桥接器所规范由应用系统来实现,也就说应用系统必须遵循Agent规约并实现Agent,Agent规约规定了如下(主要)内容:
Ø
应用系统数据模型的元数据表达
应用系统被访功能的调用机制
应用系统与桥接器之间的消息格式
应用系统必须实现的接口方法
功能注册(FunctionRegistry)与功能调度(FunctionDispatcher)
功能的注册/调度机制实现了分布式的远程功能调用,当一个应用系统打算使用另一个应用系统的功能的时候,它只需要在桥接器中的功能注册表里找到该功能的入口,即可像在本系统内一样访问该功能。
数据类型映射(DataTypeMapping)与数据转换(DataTransformer)
由于两个应用系统的数据模型是不一样的,因此,要实现两系统间数据的平滑访问,就必须在两种数据模型间进行必要的数据转换。
桥接器可以获取应用系统的数据模型的元数据表达,然后在两个应用系统的数据模型间建立起数据类型的映射关系(由系统管理员配置),这样,当数据在两个系统间发生传送时,桥接器就会依据数据类型映射将数据自动转换到新的数据模型下,从而被识别。
3.3.2.2具体实现
J2EE是实现桥接器的理想技术,因为J2EE提供了很多标准的服务,能够对桥接器的实现提供全面的支持:
J2EE的认证与授权服务(JAAS)为桥接器的认证与授权功能提供了实现基础
J2EE的JNDI/RMI-IIOP为桥接器实现功能的注册与调度提供了实现基础
J2EE的消息服务(JMS)为实现数据的可靠传送提供了实现基础
J2EE的事务服务(JTS)为一致可靠的数据访问和功能访问提供了实现基础
J2EE的连接器架构(JCA)为桥接器平滑升级到EAI应用提供了实现基础
3.3.2.3关于大数据量的数据传递问题
在综合网管系统和资源管理系统之间进行数据互访,不可避免地会面临大数据传递的问题,桥接器是如何处理的呢?
在保持数据一致性的前提下,桥接器针对两种情形提供两种手段:
(1)快照(Snapshot)访问
对于快照型的数据访问,桥接器通过提供快速的数据拷贝服务(如:
FTPService)来实现高速高性能数据传递。
(2)联机访问
对于联机数据访问,桥接器向应用系统提供一个数据迭代器,应用系统每次从迭代器中取出一部分数据进行处理。
迭代器可以有效地解决数据的脏读(dirtyreads)、虚读(phantoms)等问题。