




已阅读5页,还剩60页未读, 继续免费阅读
(信号与信息处理专业论文)交换路由器中本地监测代理模块的设计与实现.pdf.pdf 免费下载
版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
交换路由器中本地监测代理模块的设计与实现 诵妥 a 7 6 7 0 交换路由器是阿尔卡特公司开发的下一代网络核心系统。它包括两 个部分: 一 一个传输层,称为m g u ( 媒体网关单元1 ,负责i u c s 接口和t d m 交换 之间的用户平面的适配; - 一个集中控制层,称为b c u ( 承载控制单元) ,它基于n e c t a r 系统, 负责设备管理; 作为交换路由平台b c i j 软件架构的一部分,监测功能支持用户通过c o r b a 接口发起对指定监测对象的计数器数值收集请求,并且利用h t t p 协议支持观察 结果的可视化。 有三个模块参与了这个功能的实现:监测代理,本地监测代理和s n i p 接1 2 1 。 监测代理请求本地监测代理去冻结和收集对象实例的计数器数值。 通过s n m p 接口,本地监测代理收集m g u 计数器的数值。 本文将描述m g u 本地监测代理( b o b s ) 的设计过程。 关键词 监测代理数据采集实例化n e c t a rm g u l o c a lo b s e r v a t i o n a g e n t o f r o u t i n g & s w i t c h p l a t f o r m a b s t r a c t t h e7 6 7 0r s pi sa n e x t - g e n e r a t i o ns y s t e m f o rt h eh e a r to ft o m o r r o w s m u l t i s e r v i c en e t w o r k s t h e g e n e r a la r c h i t e c t u r ei sb a s e d o ht w ol e v e l s : 一a t r a n s p o r tl e v e l ,s u p p o r t e db yt h em g u ( m e d i ag a t e w a yu n i t ) ,i nc h a r g eo f p e r f o r m i n gt h e u s e rp l a n ea d a p t a t i o nb e t w e e nt h ei u c si n t e r f a c ea n dt h et d m s w i t c h 一ac e n t r a l i z e dc o n t r o ll e v e l s u p p o r t e db yt h e ”b c u ”( b e a r e rc o n t r o lu n i t ) , p e r f o r ma d d i t i o n a lf u n c t i o n ss u c ha se q u i p m e n tm a n a g e m e n t ,a sw e l la sa t ma n d s d h c o n f i g u r a t i o n a so n ep a r to fs w i t c h & r o u t i n gp l a t f o r ms o f t w a r ea r c h i t e c t u r e t h eo b s e r v a t i o n f u n c t i o na l l o w st h eo p e r a t o rt or e q u e s ts p e c i f i co b s e r v a t i o nc o u n t e r sc o l l e c t i o n ( v i a c o r b a i n t e r f a c e ) ,a n dv i s u a l i z et h er e s u l t s ( h t t pp r o t o c 0 1 ) t h r e e p a r t s h a v ec o n t r i b u t e dt ot h i s f u n c t i o n :o b s e r v a t i o n a g e n t ,l o c a l o b s e r v a t i o na g e n ta n ds n m pi n t e r f a c e t h eo b s e r v a t i o na g e n tr e q u e s t sl o c a lo b s e r v a t i o na g e m st of r e e z ea n dt o g e t c o u n t e r so f o n e c ti n s t a n c e so f l o c a lo b s e r v a t i o n a g e n t s v i as n m pi n t e r f a c e ,m g uc o u n t e r sa l eo n l yc o l l e c t e db yt h el o c a lo b so ft h e o a m & a t m p r o x y t h i sd o c u m e n ti n t e n d st o p r e s e n tt h e d e t a i l e d d e s i g n o ft h em g ul o c a l o b s e r v a t i o na g e n t 饵o b s ) o f a 7 6 7 0r s pm g r 3 0 o b s e r v a t i o na g e n t k e yw o r d s i n s t a n t i a t em g un e c t a r 4 第一章高速交换路由器的技术发展 随着全球i n t e m e t 用户数量和w e b 站点数量的急剧增长,带宽的需求也急 剧增长,每半年主要i s p 的i n t e m e t 骨干链路的带宽增长一倍。光通信技术的发 展也同新月异,传输带宽资源成倍增加,骨干链路速率己从0 c 1 2 提升到0 c 4 8 或o c l 9 2 。i n t e m e t 的迅速发展给传统电信网络带来了巨大的冲击,并向传统电 信网发出了挑战。 可以预见,在不久的将来,i p 网络中的路由器就像传统电信网中的核心元 素电话交换机,成为未来电信网络中的核心部件。一直以来,路由器的发展沿着 两条主线并行前进。一方面,随着软、硬件技术的不断发展,路由器从原来的传 统计算机技术,通过软件存储转发的单纯数据通信设备,发展到分布式硬件线速 转发无阻塞交换的电信级设备:另一方面,随着传输技术的日新月异,其互联采 用的传输方式从传统的串口、以太网接口,到i po v e ra t m 、i po v e rs d h 直到 目前最新i po v e rd w d m 通信能力不断迈向新的量级。未来电信网络中的路由 器已不再是简单完成包的转发功能,它有能力解决网络拥塞、时延和服务质量问 题以及与传统电信网络之间的无缝连接和业务综合。实际上,路由器的路由引擎 已由过去单纯软件实现转向由硬件a s i c 实现,进而成为有交换功能的高速交换 路由器。开发研制大容量、高速率的电信级、可管理、可运营的交换路由器已经 成为电信设备制造商竞争的新一轮焦点。 1 1 路由器发展过程 路由器是完成网络在i p 层互连的设备。i p 报文从源头主机发出,进入相 连路由器,路由器根据i p 报文的目的地址查找路由表,得到目的地所要经过的 下一跳路由器,完成必要处理后通过相应接口将报文发往该路由器,沿途各路由 器逐一进行这一过程,将报文送达最终目的地。路由可以通过管理人员手工配置, 或由网内各路由器通过动态路由协议相互学习得到。 传统路由器采用集中处理、软件转发的方式。一个c p u 和多个接口卡连在 个总线上,接口卡通过总线将报文上送c p u ,c p u 完成路由计算、查表转发及 用户配置处理等所有功能。通用的c p u 和高级语言编写的软件处理能力明显有 限,复杂路由计算和各种辅助功能耗费了大量的c p u 资源,连接多个板卡的数据 总线也很可能成为瓶颈,这一切都造成传统路由器的转发性能很难有大的提高。 另一方面,网络规模进一步增大,需要路由器支持更多数量端口,然而一般路由 器只支持1 0 个端口,即使大型路由器也只能支持5 0 个端口。所有这些,使路由 器成为网络的瓶颈,阻碍了i n t e r n e t 的进一步发展。 为了解决这些问题,人们起初看好a t m 技术。但a t m 技术实现和应用都比 较复杂,其关键的s a r 芯片需要完成适配多种业务和分割组装信元的工作,速率 很难做到很高而且价格昂贵;其与i p 层之间为叠加方式,使地址映射、网络管 理困难而不灵活;其信元头占了总信元的近十分之一,带来很大开销。上述弱点 都使a t m 难以很好地承担互联网骨干网组网的任务。 1 9 9 7 年以来出现了以c i s c o 的1 2 0 0 0 系列为代表的高速交换路由器,这使 i p 转发能力有了质的飞跃,进一步奠定了i p 网作为未来网络的统一平台的地位。 高速交换路由器提升性能的关键在于其分布交换式的体系结构。一方面,高速交 换路由器对报文转发采用分布式处理,可以插多个线路处理板,每个线路板独立 完成转发处理工作,通过核心交换板实现板间无阻塞交换,即一个板上输入的报 文经过寻路后可以象通过导线直连那样,被交换到另一个板上输出,实现包交换, 其整机吞吐量可以成倍扩充。线路板上有专用芯片完成二层、三层乃至四层的转 发处理工作,硬件实现使转发能够达到线速( 高速端口所连接线路的速率) ,达 到了电路交换那样的性能,使路由器不会成为网络中的瓶颈。另一方面,在组网 中,通过采用m p l s 技术,进行标签交换,可以在i p 网上实现面向连接的功能, 在连接沿途严用o o s 技术,提供电路交换水平的服务质量,满足电信级业务的需 要。 过去,交换概念一般限于时分复用电路交换,电路交换成本高、效率低, 很难胜任承载未来的宽带综合业务任务。传统路由器以存储转发为特征,被认为 是低速、无保证、高时延、大抖动,只能用于要求不高的业务。交换路由器的出 现使路由器的能力得到飞跃性提升,再加上生来具有的统计复用机制对网络效率 的充分优化,使i p 成为三网合一的平台的最佳选择,其自身也成为下一代综合 业务电信网络的最关键设备之一 高速交换路由器根据其交换容量,又可阱分为:千兆比交换路由器( g s r ) , 一般为几十g 到几百g ;千g 比特级交换路由器( t s r ) ,它具有几个t ( 1 0 0 0 g ) 以上的交换能力。 1 2 高速交换路由器的关键特性 高速交换路由器作为互联网的核心设备,在性能及稳定性上有很高的要求。 它区别于一般中低端路由器的关键特性包括以下几个方面。 1 高吞吐量、线速转发能力 这是o s r 的标志,其整机交换容量一般应在2 0 g 以上,单板处理能力至 少1 g b i t s ,支持o c - 3 ( 1 5 5 m b i f f s ) 到o c 一4 8 乃至o c 1 9 2 ( 1 0 g b i t s ) 端口的线 速转发。 2 高速端口 g s r 所能支持的端1 2 1 是衡量其能力高低的重要指标。g s r 位于核心层,具 有丰富的业务接口,一般需要支持p o s 口、a t m 口、1 0 m 1 0 0 m 快速以太网口 ( f e ) 、千兆以太网口( g e ) 。为了适应光通信技术的发展,充分利用传输带宽 资源,骨干网互连希望采用尽可能高速率的端口。以前的1 5 5m 、6 2 2 m 端口已 不能满足需求,目前o s r 一般都支持2 5 g p o s 端口,1 0 g p o s 端口的路由器也 已经推出,将成为主流。今后骨干网将以“i p + o p t i c a l 的i p o v e r d w d m 方式, 通过高速端口直接通过光层互连。 3 大路由表 g s r 位于核心层,需要知道全网的路由。路由表大小要比一般路由器高一 到两个数量级,一般应支持2 5 万条以上,有的可达到上百万条。相应要求其具 有很强的路由处理能力,应达到每秒处理3 0 0 0 条路由的水平。 4 良好的q o s 支持 今后的i p 网是三网合一的平台,承载数据业务的同时还要支持语音和视频 的业务,这些都对时延、抖动等指标有很高的要求,需要在数据流的沿途都有很 好的保证。o s r 作为数据流的交汇点,更要有很好的机制,保证对不同等级数 据流提供相应服务质量保证。目前,硬件转发的并行处理机制,已经可以做到路 由器内转发时延与i p 包的长度无关,解决了i p 包不定长带来的时延抖动问题。 因此,路由器所能支持的端口输出队列数等数字也是评价其性能的重要指标。 5 高司靠性 g s r 位于网络核心,稳定、可靠至关重要,要采取多种措施,使其在故障 发生时业务不中断,并能在线恢复。这不仅要求g s r 支持热备份,关键部件如 路由处理板、网板等都有主各板,还应支持热插拔,可以在系统上电的情况下拔 出和插入单板,以便在不停机的情况下恢复故障,或插入新的业务板。同时,还 要通过a p s 线路保护等技术,保证线路的可靠性。 6 可扩展性 为了适应不断增加的网络需求,需要不断提升核心路由器性能。g s r 投资 巨大,整机替换成本太高,需要能够通过软硬件升级的方式来增加功能提升性能。 g s r 的分布式结构,使得我们可以通过插入新的单板或对单板进行替换的方式 在原有设备基础上进行升级,很大程度上保证了可扩展性。 1 3 高速交换路由器的关键技术 1 分布交换式的体系结构 g s r 通过分布式处理结构保证单板处理性能,并通过无阻塞交换成倍提高 整机吞吐量。在g s r 系统中,一般包括:路由处理板、线路板、交换网板。g s r 抛弃了传统的共享总线方式,采用交换方式,每个线路板都连在交换网板的一个 端口上,各板间进行点到点通信,不相互干扰,实现无阻塞交换,充分保证整机 的吞吐量。 2 高性能芯片实现线速转发 硬件技术的突破,为高速转发创造了条件。过去认为,i p 地址查找路由表 采用的最大匹配方式,不如a t m 的v p i v c i 那样定长查找速度快,再加上对i p 报文的封装、解封装、校验和计算、报文分段重组等工作,使转发难以达到很高 线速。但随着硬件技术的发展,依靠芯片性能的提高和并行处理技术,高性能芯 片对i p 报文的转发处理能力已完全能够满足目前最高速端口的线速要求。 普遍采用的是a s i c ( a p p l i c a t i o n s p e c i f i ci n t e g r a t e dc i r c u i t s ) 技术,即应用 专用的集成电路。通信厂商根据实际需要,采用相应集成电路设计工具进行设计, 设计完成并验证后,交由专业芯片生产厂家批量生产。这样做,可以根据特定应 用进行专门优化,批量生产后可以降低成本,但生产使用后不能有任何修改,不 够灵活,难以适应不断出现的各种需求。 目前,网络处理器逐渐被越来越多的采用。网络处理器由专业芯片厂商设 计生产,属于通用芯片,它内部有多个处理器,可以实现多处理器多线程的并行 处理,同时还有功能强大的协处理器,完成如查表等标准化且耗时的功能。它提 供一个精简指令集,设备制造者通过微码编程实现各种协议和业务。这样既充分 利用了硬件的高性能,又保证了灵活性,可以通过修改微码升级软件快速满足各 种变化发展的业务需要,而不用更改替换任何硬件。目前比较多的网络处理器包 括:i n t e l 的i x p l 2 0 0 、c - p o r t 公司的c 5 d c p 、i b m 公司的r a m i e r 等。 3 m p l s 技术和流量工程 g s r 位于骨干网,流量汇集于此,带宽需求巨大,虽然目前带宽资源相对 丰富,但骨干网长途线路资源仍然十分宝贵和有限,必须优化配置,充分有效地 利用现有资源。其关键是通过路由器合理选择转发路径,使流量在网内均匀分布, 这就是流量工程。目前普遍使用的动态路由协议,只能根据线路的静态的优先级 选择路由,难以适应网络上不断变化的流量分布情况,很可能造成某处拥塞,某 处闲置的情况。需要有技术手段,根据网络状况通过人工或自动的方式引导流量, 普遍采用的就是m p l s 技术。 m p l s 技术的目的是建立从源到达目的i p 地址的连接l s p ,报文进入 l s p 后通过标签交换到达目的地。它原本是为了支持i po v e r a t m ,实现二者的 无缝融合而提出的,现在已被认为是i p 组网的重要手段。对于路由器来说,本 想利用m p l s 标签交换定长查找的特点,提高转发性能,但如前面所说,i p 地 址查表能力已经能够充分满足需要,现在更看重的是m p l s 提供的面向连接的 方式和多层标签栈所带来的灵活性。 i p 面向无连接,逐跳转发,难以有效控制。m p l s 面向连接,同对其提供 受限的显式路由方式,可以在l s p 的发起端指定l s p 所要经过的每一跳,并指 明此条l s p 所需要的带宽。这样,就可以在流量的起始处根据网络目前状况计 算得到一条最优路径,使流量在网络中均匀分配,同时保证l s p 所需带宽。为 了使一个路由器获得全网流量分布的信息,需要将网络中各链路的带宽使用情况 通知整个网络,这可以通过对链路状态路由协议o s p f 和i s i s 扩展来实现。在 通过路由协议传播的链路状态中,增加各链路的带宽使用情况的信息,路由器获 得全网链路状态后,使用c s p f 受限的最短路径算法,根据链路当前实际可 用带宽计算得到最优路径,用于建立l s p 。初期,也可以采用手工配置和网管离 线计算等方式实现。 这些技术还在不断发展中,g s r 通过采用这些技术,实现骨干网的流量工 程,对提供优质高效的网络起着重要作用。 第二章网络管理概述及交换路由器结构解析 2 1 网络管理功能 国际标准化组织在i s o i e c 7 4 9 8 4 文档中定义并描述了o s i 管理的术语和 概念,定义了网络管理的五大功能,为大家广泛认可。这五大管理功能是:配置 管理,故障管理,性能管理,安全管理及计费管理。 i 配置管理( c o n f i g u r a t i o nm a n a g e m e n t ) 是最基本的网络管理功能。 他扶着网络的建立,业务的展开,以及网络的配置,并由此建立管 理资源信息库( m a n a g e m e n ti n f o r m a t i o nb a s e ,简称m i b ) ,为其他网 络管理功能所用。包括四项功能。 i i 故障管理( f u a l tm a n a g e m e m ) 网络对于设备和传输介质的故障是 脆弱的,同时网终的故障类型也是多种多样的,硬件,软件和数据 都可以引发故障。而用户都希望有一个可靠稳定的计算机网络,因 此故障管理对于网络管理来说是十分重要的。它的目的就是迅速发 现和纠正网络故障,动态维护网络的有效性。其主要功能有告警监 测,故障定位,测试,业务恢复以及维护故障日志等。 i i i 性能管理( p e r f o r m a n c em a n a g e m e n t ) 它的目的是维护网络管理质 量( q u a l i t yo fs e r v i c e ,简称q o s ) 和网络运行效率。为此主要提供 性能监测功能,性能分析功能,以及性能管理控制功能。 i v 安全管理( s e c u r i t y m a n a g e m e m ) 网络中主要有以下几大安全问题: 网络数据的私有性,授权,访问控制。相应的网络安全管理应该包 括对授权机制,访问机制,加密和加密关键字的管理,另外还要维 l o 护和检查安全同志。 v 计费管理( a c c o u n t i n gm a n a g e m e n t ) 它的主要目的在于正确地计算 和收取用户使用网络服务的费用。分为四个模块:服务事件监测功 能、资费管理功能、服务管理功能、计费控制功能 其中性能管理又包括: 1 性能监测功能 对网络的性能数据进行连续的采集。网络中多个单元的偶尔或间歇 性的错误会导致服务质量的降低,并且这个问题难以通过故障管理 的方法监测出来,因此通过连续地采集性能数据,来监测网络的服 务质量。 2 性能分析功能 性能分析功能一是,要对检测到的性能数据进行统计和处理,获得 网络的性能指标,定期或在必要时形成性能报表;二是,要负责维 护性能数据库,存储网络的性能的历史数据;三是,要根据当前和 历史的数据对网络的性能进行分析,获得性能的变化趋势,分析制 约网络性能的瓶颈问题;四是,在网络性能异常时向网络管理员告 警,在特殊情况下,直接请求故障管理功能进行反应。 3 性能控制功能 性能管理控制功能包括监测网络中的业务量,优化网络资源的利 用,性能管理控制功能采集的数据也被用于支持它的网络管理功 能,如故障管理和配置管理。 本文中讨论的监测模块正是用于性能管理之中。 2 2 交换路由器平台解析 阿尔卡特公司开发了新一代的交换路由器a 7 6 7 0 系列,它的结构图如下: 图表2 - 1a 7 6 7 0 交换路由器 1 l 由图可以看出,a 7 6 7 0 系列交换路由器的结构包括两个层次; b ) 一个传输层,由媒体网关单元( m e d i ag a t e w a yu n i t ) 支持,主要负责i u c s 接口、t d m 交换之间的用户平面( u s e rp l a n e ) 的适配工作。 c ) 一个集中控制层,由承载挖制单元( b e a ;q rc o n t r o lu n i t ) 支持。这是一个 基于n e c t a r 系统的应用部件,主要负责设备管理,比如a t m 和s d h 的配置。 媒体网关单元和承载控制单元之间用一个l s n ( 本地子网) 连接; 承载控制单元包括了两台主机,一台处于激活状态,另一台作为热备份使 用。这两台主机负责配置管理,比如a t m 和s d h 配置、告警( a l a r m ) 服务和 监测( o b s e r v a t i o n ) 服务处理。同时,承载控制单元包含了若干对后端处理器 ( b e p ) ,负责a a l 2 路径配置、a l c a p 终端、a a l 通道和t d m 资源管理、指 定媒体网关单元资源控制等,最后,承载控制单元上还有若干个前端处理器 ( f e p ) ,实现信令网关功能,比如r a n a p 路由等。 媒体网关单元主要由控制及交换结构模块( c o n t r o l & s w i t c h i n gf a b r i c m o d u l e s ) 构成,可以看作编码格式转换板卡,负责从a t m 到t d m 的转换,它 也是监测功能具体要管理的对象。 图释: b c u :承载控制单元 m g u :媒体网关单元 b e p :后端处理器 图表2 2 内部结构 f e p :前端处理 c f a :控制及交换结构模块 p i l o t :主机 2 3n e c t a r 系统介绍 n e c t a r 是n e wc o n t r o la r c h i t e c t u r e 的缩写,该系统提供了一种有效的, 经济的开发通信产品的方式。n e c t a r 为支持增值通信应用 ( s u 2 a ,s g s n ,c d r a ) 提供了一个通用平台。 n e c t a r 通用平台包括: 软件包 硬件单元组件 2 3 1 n e c t a r 对软件组件的抽象 作为一个全新概念的开发平台,我们先介绍一下n e c t a r 提供的一种开发通 信软件的理念和方式。 n e c t a r 对软件组件做了如下的抽象化: s c = s o f t w a r ec o m p o n e n t 软件组件 一 包括可执行的代码 一 是一套实现一个或多个服务的过程( p r o c e d u r e s ) 是一软件生产、配置的单元,交付给目标平台 一个软件组件主要由以下两部分标识: s cn a m e ( 名称) 可执行代码文件名称 s c i = s o f t w a r ec o m p o n e n ti n s t a n c e 软件组件实例 在n e c t a r 平台上s c 可执行代码被实例化为一个s c i ,它: 定义了一个软件组件服务提供者 是平台主机上软件组件代码发布单元 当存在若干个软件组件实例时,它们都是是负载均衡单元 s c i m = s o f t w a r ec o m p o n e n ti n s t a n c em a t e r i a l i z a t i o n 软件组件实例 实现者 一 是软件组件实例代码执行单元 被称为n e c t a r 进程 与主机中一个软件组件实例的内存镜像相对应 也就是说,我们最终在平台上运行的是若干个实现者( s c l m ) ,这些实现 者提供了用户需要的服务。 2 3 2 n e c t a r 对s c i m 间通信的抽象 在n e c t a r 系统内,软件组件实现者之间的通信都是基于客户服务器 ( c l i e n t s e r v e r ) 模式的。由一个s c 实现服务( 完成“服务”代码编写) ,这 个服务由一个“服务器”软件组件实例( s c i ) 提供,其他若干个软件组件实例( s c i ) 可以接入并请求这个服务。 f a p = f u n c t i o n a la c c e s sp o i n t 功能接入点 它是c s 模式中,到某个“服务”的接入点。 一个“客户”软件组件实例( s c i ) 必须在“服务请求”中标识所请求服务 的f a p 名称。 f a p i = f u n c t i o n a la c c e s sp o i n ti n s t a n c e 功能接入点实例 它是到一个扮演“服务器”角色的软件组件实例的接入点 有可能多个软件组件实例( s c i ) 为同一个“服务”f a p 服务,那么这些软 件组件实例( s c i ) 由不同的功能接入点实例( f a p i ) 来标识。 n e c t a r 通信系统负责把发送到功能接入点( f a p ) 的“服务请求”路由到一 个功能接入点实例( f a p i ) 上。 p o r t ;n e c t a rc o m m u n i c a t i o ne n t i t y 通信实体 是主机上一个功能接入点实例( f a p i ) 的物理上的实现者,有点类似于计 算机在提供网络服务时候的端口。 路由到功能接入点实例( f a p i ) 的“服务请求”在物理上都由n e c t a r 发送 到某个端口上。 2 3 3 硬件结构 n e c t a r 平台是一个多主机的平台,这些标准的i t 主机由一个安全的本地 局域网( l o c a l a r e a n e t w o r k ,l s n ) 连接。 注释: l s n :本地子网 图表2 3n e c t a r 平台的硬件结构 s t a t i o n :主机 2 3 4 软件包 n e c t a r 平台的软件包也就是n e c t a r 平台能提供的各类服务,这早面重 点要提到的就是可用性服务( a v a i l a b i l i t ys y s t e m ) , a s :a v a i l a b i l i t ys e r v e r 可用性服务 a m :a v a i l a b i l i t ym a n a g e r 可用性管理 s m :s o f t w a r em a n a g e r 软件管理 h m :h a r d w a r em a n a g e r 硬件管理 g w :g a t e w a yc o m m u n i c a t i o ns y s t e mw i t ht h es w i t c h 网关通信系统 s 7 :s i g n a l i n gs y s t e m7 a d :a d m i n i s t r a t i o n 管理 、:j$7 s m genear;lcca,tte二ligl下ai d i g t a l v h a r d w a r e _ 图表2 4 n e c t a r 软件包 可用性服务里提供了一些与s c i m 有关的功能,它 - 支持在d i g i t a l 主机网络上的分布式应用 实现了应用程序的安全保障 提供了实时的分布式数据管理服务 一 提供了s c i m 之间的通信服务 - 提供了s c i m 的配置和保护机制 可用性服务被分为四个予系统: 一 n o s :n e c t a r 操作系统扩展 一d m :数据管理,负责分布式数据管理服务 c s :通信服务 x m a :u n i xm i d d l e w a r ea d m i n i s t r a t o r ,提供配配置和保护机制 s c l m 之间的通信方式有三种:数据报模式、请求,答复模式、会话模式。 数据报模式是单向的,发送数据后不管;请求,答复模式是一个请求对应一个应 答;会话模式则是在两个s c l m 之间建立一个会话,在这个会话关闭前,数据可 以一直在两个s c i m 之间连续传送。 现在我们就可以用下面这张图表来描述s c i m 的运行环境了: 图表2 - 5n e c t a r 软件的组织结构 注释: t h 1 :线程1 的简写 从图中我们可以看到,s c l m 有可能包含了多个线程( t h r e a d ) ,它运行在 n e c t a r 环境之上,可以调用n e c t a r 平台提供的各种a p i ,同时也根据需要 调用通信系统( c s ) 等提供的服务。我们的主要任务就是设计这样一个s c i m , 并合理的调用系统提供的服务,完成监测功能。 第三章监测模块顶层设计 前言 我们遵循由上至下的开发流程,即是从需求分析一 顶层设计一,详细设计 一 代码编写一 测试用例编写一 调试及测试。 1 6 3 1 需求分析 监测功能定义: 对网络的性能数据进行连续的采集。网络中多个单元的偶尔或间歇性的错误会导 致服务质量的降低,并且这个问题难以通过故障管理的方法监测出来,因此通过 连续地采集性能数据,来监测网络的服务质量。 监测模块需求总结: 一这个功能满足用户对一些指定的计数器值进行收集( 通过c o r b a 接口) 监测既能适用于预定义的对象,也能满足临时的请求 一关于以下对象的计数器值将被提交给用户: 设备层( 板卡,插槽) s d h 层( 端口,线路) a t m 层( 结点,端口) b r m c 层( a a l 2 路径,r n c ,节点) 承载控制单元上所有和监测机制有关的实体将受热备份的保护 3 2 特性描述 3 2 1 监测管理服务 n e c t a r 平台建议,监测机制分为三个相互独立又相互联系的部分: - n e c t a r 部分:包括监测代理。这个部分和操作系统以及应用程序连接,所 有的智能服务都包含在这个部分里。 - 监测本地代理部分:这是n e c l a r 里的概念。这个部分的作用是向监测“事 件源”部分隐藏n e c t a r 的存在。它对上层的应用负责。 - 监测“事件源”部分:这部分是监测的对象产生的地方,具体指的是媒体网 管单元( m g u ) 。 3 3 监测管理 3 3 1 监测功能描述 图表3 - 1 监测功能结构 1 8 监测功能允许用户通过图形用户界面提交特定的监测请求。这些请求会在 监测代理中生成工作订单,去收集计数器( c o u n t e r ) 和计量表( g a u g e ) 的数 值。( 计数器只有增加和复零的功能,而计量表能增加和减少) 所有这些操作将在一个安全的环境下进行:在初始化阶段,监测代理必须 声明它的域( d o m a i n ) 以及与n e c t a r 访问控制的接口,这将使得一个外部用 户在接下来的步骤中通过图形用户界面访问监测服务。 监测代理( o b s e r v a t i o na g e n t ) 在引导主机( p i l o ts t a t i o n ) 上运行。代理 是监测服务的“大脑”。 监测管理是通过c o r b a 接口来完成的,同时监测的返回结果将通过h t t p 协议发送给用户。 一个媒体网关单元的本地监测服务位于o a m & a t m 代理内,这个服务只在 引导主机上被实例化。它的主要功能是处理位于媒体网关单元内部的监测计数 器。 监测代理( o b s e r v a t i o na g e n t ) 和本地监测( l o c a lo b s e r v a t i o na g e n t ) 之间通过通信系统提供的会话( s e s s i o n ) 传递消息。 3 3 1 1 n e c t a r 提供的服务 以下功能实体将由n e c t a r 提供: 图形用户界面框架( g u if r a m e w o r k ) 图形用户界面框架提供对监测服务的访问控制,比如,用户只能在输入正 确的用户名和密码之后才能使用监测服务。 监测服务界面( o b s e r v a t i o ng u i ) 监测服务界面向用户提供所需的监测服务。 监测代理( 以及相关的日志文件管理)( o b s e r v a t i o na g e n t ) 监测代理提供以下服务: 完成用户要求的监测工作; 向应用程序隐藏“请求性”工作和“永久性”工作的内在属性。 一a p i s n e c t a r 同时也提供以下a p i : 一监测代理和本地监测之间的接口a p i 一解析x m l 配置文件的a p i 3 31 2 回顾u 中已存在的机制 目的是尽量减少对已存在的机制进行修改,尤其对媒体网关单元来说: 一监测的最小时间间隔为1 5 分钟 一计数器数值每隔一刻钟会被保存和复零 1 9 一计数器数值能通过两种方式获得: 当前1 5 分钟内的值:从最近的一次复零到当前时间的累计 或者过去的n 个1 5 分钟的值( 例如,对物理端口g = 9 6 ) 一除了每隔一刻钟的自动复位,没有别的可能让计数器清零 3 3 1 3 n e c t a r 平台上的监测类型 监测代理处理两种类型的监测工作: 口永久性( p e r m a n e n t ) 工作: 这种类型的监测工作在监测代理初始化完毕后就自然地被激活。永久性工 作有以下的特征: 一收集的时间间隔是1 5 分钟 一监测的持续时间为7 天。这意味着,收集的数值每7 天就会新数据被覆 盖。 口临时性( t e m p o r a r y ) 工作( ”o n d e m a n d ”监测) : 通过监测服务界面,用户可以定义一些临时的工作,选择需要的观察的计 数器。临时工作必须具有以下的特征: 一时间间隔可以是5 ,1 5 或者3 0 分钟:如果用户请求的时间问隔不在支 持的范围之内可能被拒绝( 比如m g u 的计数器只支持1 5 分钟及其倍数的时间 间隔) 一监钡4 的持续时间必须由用户指定,例如3 0 分钟,1 小时等等,该持续时 间必须是时间间隔的倍数。 一监铡的周期也由用户指定。比如,每隔6 小时,或一天启动一次监测。 一用户可以给出工作延迟启动的时间。这意味着,工作既能立刻被启动, 也能在一个指定的时间被唤醒启动,当然这个指定的时间必须参考周期和持续时 间。 3 3 1 4 n e c t a r 监测机制回顾 3 3 1 4 1 数据采集机制 针对监测服务,上层的监测代理设计了两个函数:f r e e z e c o u n t e r 和 g e t f r o z e n c o u n t e r 。当代理调用f r e e z e c o u n t e r 时,表示它要开始启动一个工 作( j o b ) ,然后它通过g e t f r o z e n c o u n t e r 函数将要监测的对象类名传递给本 地监测代理,并用返回值把对象中的计数器数值传递给监测服务界面。 我们定义了层( l a y e r ) 和对象( o b j e c t ) 的概念,层的概念主要是针对监 测服务的“事件源”,不同的“事件源”即是不同的层,在我们设计的这个监测 模块中,只需要定义一个层,那就是媒体网关单元层。 对象( 0 b j e c t ) 是若干个关系密切的计数器的组合体,比如一个名称为 a t m p o r t 的对象,可能就包括了若干个能体现a t m 端口性能的计数器,象 2 0 到达信元个数,错误信元个数之类。我们在划分这些对象的时候要十分小心,既 要方便查看,又要避免重复,因为对象的定义直接影响到了本地监测代理和上层 监测代理之间的数据流量的大小。 图表3 2n e c t a r 监测机制回顾 一些关键点回顾: 一 即使用户生成了一个时间间隔不为五分钟的工作,f r e e z e c o u n t e r s 和 g e t f r o z e n c o u n t e r s 的发出频率仍然是5 分钟。 一 所收集的数据将在监测代理层被处理 一 如果用户定义了应用子域中不支持的时间间隔( 例如,m g u 只支持1 5 分 钟的时间间隔) ,监测代理会发出拒绝。对各个层,x m l 文件中都定义了 支持的时间间隔。 一 f r e e z e c o u n t e r s :这是面向所有层的请求,比如,本地监测将处理x m l 文 件里定义的所有层中的所有计数器。 一 g e t f r o z e n c o u n t e r :这是面向某指定层的请求,对每个收到该请求的对象 实例,本地监测将负责处理所有相关的计数器。 在定义对象和层的时候,必须考虑最后两点,这样可以避免b c u m g u 接口上 数据流量过载。 3 3 1 4 2 n e c t a r 监测机制中如何对计数器实例化 如果本地监测保存了所有生成的计数器的一个副本,那它就必须保证正确的计数 器实例化过程。x m l 文件仅仅定义了与层、对象类有关的计数器组,和一个对 象实例并没有关系。所以只有功能子域可以告知本地监测需要生成多少个实例。 在实例化过程中,本地监测不和监测代理打交道,所以用户并不知道某个对象类 拥有多少实例。这是n e c t a r 机制的一个大缺陷:用户需要知道观察的对象的 实例,不单单是知道哪个类。 3 3 1 5 x m l 配置文件 3 3 1 5 1 o b s x m l 配置文件 监测代理通过配置文件o b s x m l 来了解不同的层( 1 a y e r ) 和域( 对象) 中相应 的计数器。这个文件在初始化的阶段被解析。 应用程序负责填写这个文件。在这个文件里,对象类和层类的声明格式如下: 叫c o u n t e r ( c o u n t e r 叫c o u n t e r 3 3 1 5 2p e r m a n e n t x m l 配置文件 这是一个记录“永久性”工作的配置文件。监测代理启动的时候会读八其中的数 据。 本地监测模块无权读这个文件。 3 3 1 5 3d d x m l 配置文件 监测代理利用d d x m l 配置文件来了解一些“即时请求”的工作。这些工作清单 也会被保存在x m l 文件中。 监测代理在初始化时会解析这个文件。 同样本地监测模块无权阅读这个文件。 3 3 1 6 本地监测代理功能描述 媒体网关单元本地监测:这部分位于承载控制单元( m g u ) 中专门负责管理 媒体网关单元的计数器观察工作, 由于现存机制的限制,这些本地监测将不会完全满足n e c t a r 机制的要求。 3 3 1 6 1 媒体网关单元本地监测( m g ul o c a lo b s ) 功能描述 3 3 1 6 1 1 媒体网关单元本地监澳j ( m g ul o c a lo b s ) 功能综述 目前,m g u 和n e c t a r 之间的机制还不是非常兼容。为了简化实现,用户不 得不接受一些限制。 与媒体网关单元本地监测( m g ul o c a lo b s ) 有关的功能结构如下图所示: 0 5 c o r t o b s 0 酣 蕊黼lj 一嘴甜 p 赋y t鲤要孽鬟l 彳n 。删岫 m 6 u s c c r t e r s g e tr e l a t e d u n h | s f r m l m g u 日日日日 巴墨e t o 瞻加l 荆 图表3 3m g u s 计数器监测服务功能结构, 媒体网关单元本地监钡t j ( m g ul o c a lo b s ) 提供以下服务: 只接受观察间隔时间为1 5 分钟的工作( 由监测代理筛选) ,原因是媒 体网关单元只能处理周期是1 5 的倍数的工作 保证和监测代理的所有通讯 不负责处理计数器值,这些数值在媒体网关单元上处理 为了保证媒体网关单元和监测代理之间机制上的兼容,不可避免的,用 户在使用上有一些限制。 3 3 1 6 1 2 媒体网关单元本地监测( m g ul o c a lo b s j 的层定义 在x m l 配置文件中,定义了媒体网关单元本地监测( m g ul o c a lo b s ) 处理的层。 每个层都对应着个通信系统会话( c ss e s s s i o n ) 和一个功能接
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
评论
0/150
提交评论