思科运营商路由系统可以通过内嵌的可管理性,支持不间断的系统运行和服务灵活性。这种可管理性能够不断改进,满足路由技术和服务供应商的各种要求。
为多机架管理做好准备 在今天的服务供应商网络中,大部分核心路由器都是拥有大量接口,并且可以扩展到数千个的单机架系统。在管理这些路由器时,需要采集、处理和转发的数据的数量将与有效接口的数量成比例增长。
这种方式的扩展能力如何?假设有一台具有几百个接口的路由器,它的一个或者多个接口发生故障。这时,会生成一个或者一组警报,并将其发送到一个事件控制台。控制台将关联该警报,并通知操作人员。关联、通知,甚至故障的解决都可能在几秒钟或者几分钟之内完成。
现在设想一下将同样的接口设置成具有数千个通道化接口的中继时发生的情况。当一个或者多个接口发生故障时,大量的警报会被发送到事件控制台,从而迫使操作人员利用脚本语言——例如实际抽取报告语言(PERL)和工具命令语言(TCL)——分析警报,以确定故障的性质。尽管这种使用顶置脚本处理事件的常见做法变得越来越复杂和费时,但是它仍然很有效。故障会在可以接受的时间内被诊断和解决。
现在,设想一台具有数百个40Gbps插槽的Tb级多机架路由系统。它包含了几千个接口,可以为数万个客户提供支持。尽管比管理单独的、可以提供相同容量的组件简便得多,但是警报个数仍然会以指数形式迅速增长。事件管理系统能否通过扩展,支持这些负载?事件关联和响应能否以足够快的速度进行,以便为受到某个故障影响的客户保持不间断的服务和服务水平协议(SLA)?
随着多机架路由系统的出现,进行处理的时间和地点必须进行相应的改变。通过管理多个网络组件的组件管理系统(EMS)现在需要负责管理多个系统和逻辑组件。集成流程过去只需要将单个机箱的管理数据发送到北向运营支持系统(OSS)应用,而现在则必须从一个更加抽象的数据源中获得数据,再提供给这些应用。
长期以来,大型网络的操作人员一直期望和提倡将网络管理智能转移到网络本身。为了在多机架路由平台上保持不间断的系统运行,必须使用嵌入式、模块化的检测技术来自动执行运营、管理、维护和供应(OAM&P)任务。故障、配置、记帐、性能和安全(FCAPS)的管理必须符合业界标准,以提供与现有OSS应用(例如供应和计费)的集成,从而提高收入和降低运营成本。
Cisco CRS-1的可管理性 思科运营商路由系统(图1)是一个多机架路由平台,它建立在一个微内核、分布式、模块化的操作系统——Cisco IOS XR——的基础上。
图1 思科运营商路由系统
实现这种可管理性需要跟上高端路由技术的发展步伐。Cisco CRS-1根据多机架路由环境的要求设计了CRS-1的可管理性。在这种环境下,CRS-1的新型分布式、模块化架构不仅对可管理性提出了新的要求,而且还为管理流程带来了便利。
在这种微内核架构中,每个管理流程都具有全面的内存保护和故障隔离。通过将流程分配到不同的面板,管理面板既不会影响控制和数据面板上的流程,本身也不会受这些流程的影响。这种模块性不仅带来了更高的安全性,而且提供了在不影响路由控制功能或者网络流量的情况下修改管理流程的能力。
为了在一个分布式管理环境中保持性能,CRS-1分布式路由处理器架构可以在多个路由处理器之间平衡处理需求。在面临沉重的网络管理负载(例如数据采集或者警报处理)时,任务会被分配到任何可用的资源,以避免对关键任务造成不利的影响。为了支持OAM&P功能,闪存提供了永久存储,而硬盘资源可用于存储临时性的调制和诊断数据。
为了支持不间断的系统运行和灵活的管理服务,CRS-1具有三个关键的内嵌式管理功能:内嵌检测、内嵌接口、内嵌应用服务。
内嵌检测 路由器的检测和管理接口是其可管理性的两个最重要的方面。如果路由器没有合适的检测功能来提供信息和控制,操作人员和OSS应用就无法对其进行有效的管理。
Cisco CRS-1提供了远远超出简单的路由器检测的嵌入式FCAPS管理。通过执行很多以前由外部管理应用执行的管理任务,CRS-1能够以快于单机箱平台的速度响应事件和请求,并可以对数据进行整理,以帮助OSS系统扩展规模。
嵌入式故障管理
高度可扩展的多机架平台需要处理大量的流量和生成大量的警报,所以对现有的事件管理平台提出了独特的要求。
嵌入式CRS-1事件管理器支持自主的事件关联和过滤,以降低来自于数十万个接口的大量事件信息。由用户定义的过滤和关联规则可以支持很高的精确度,而事件关联功能可以自动地对像启动系统恢复任务这样的事件采取措施,例如保护交换机或者采用用户提供的TCL脚本。
例如,单个事件——例如线卡在线插拔(OIR)——可能会导致多个应用通信和接口故障警报。用户可以定义一个关联规则,将所有有关的事件连接到某个指定的根事件——假设它们都在设定的时间间隔内到达。因此,只有根事件会被转发,从而大大降低事件管理系统的警报负载。(用户仍然可以查询相关事件。)
事件管理器还支持一个由用户设置的警报缓存。一个外部管理系统或者操作人员可以组织或者查询缓存中的警报,以便分析状态或趋势。因为CRS-1的架构具有很高的可用性,缓存中的警报会进行校验,以防止警报在路由处理器进行故障切换或者流程重启时丢失。
嵌入式配置管理 尽管系统停机通常是由于网络以外的来源所导致的,但是它也有可能是由网络附近的来源——操作人员——所导致。因为多机架路由器的配置非常复杂,而且故障或者延迟可能会对客户服务造成严重的影响,所以需要一个嵌入式的、智能的配置流程来保持不间断的系统运行和迅速的实施。
内嵌的CRS-1配置管理器可以在启动、运行和OIR事件期间
优化路由器的配置流程。通过同时和批量在启动和OIR事件时分配和执行改动,平均修复时间(MTTR)将会最大限度地缩短。通过校验逐步进行的配置升级,配置管理器让CRS-1可以在正常运行过程中支持配置升级上载或者恢复。
为了解决大型边界网关协议(BGP)路由配置在多机架路由环境中带来的挑战,Cisco IOS XR软件还提供了一种新的路由策略语言(RPL),它能够将数千个BGP对等操作集中到一个或者多个紧凑的逻辑路由器配置中。
嵌入式记帐 记帐是网络管理在流量工程、计费和安全方面的一个不可或缺的重要组成部分。
为了支持嵌入式记帐管理,CRS-1提供了一个新版本的NetFlow——静态NetFlow。NetFlow是动态的,可以采集、汇聚和输出大量的数据进行分析,而静态NetFlow对分组流的处理方式与访问控制列表(ACL)类似,但是具有扩展字段,例如源和目的地的自主系统编号和多协议标签交换(MPLS)标签。利用静态NetFlow,可以定义一个具有扩展ACL的流量过滤器,以便跟踪某个特定数据流的分组和字节计数器。静态NetFlow计数器的存储和接收方式与可扩展标记语言(XML)或者简单网络管理协议(SNMP)计数器相同。
为了提高效率,静态NetFlow部署在CRS-1的硬件中(以微代码的形式),以便最大限度地降低对路由器的
CPU性能的影响。一旦计数器被采集,它们就将通过线卡数据接口,输出到外部采集器。这消除了对性能的负面影响,因为CRS-1可以在控制面板和数据面板之间提供完全的隔离。
嵌入式性能监控 在基于单机箱平台的大型网络中,性能监控和趋势分析很难实现。来自于为数众多的网络组件的大量可用数据通常会超出负责采集、存储、管理和处理数据的OSS性能监控组件的能力。这些数据还可能会对组件和采集器之间的网络流量造成严重的影响。通常,可以通过只针对平台中的特定目标——而不是分析整个网络的趋势——限制所采集的数据的容量。
因为多机架路由器的规模很大,传统的基于某个集中应用的数据轮询已经无法满足需要,而且效率极低。因此,CRS-1上的性能统计数据和计数器的采集是由内嵌的性能监视器执行的。
Cisco CRS-1的性能监控能力让操作人员可以定义所要采集的统计数据、采集的频率,以及内存中保存的样本总数。采集操作可以被设置为按需运行或者定期运行(用于分析趋势)。按需采集通常用于进行迅速的调试和诊断,例如查看利用率。无论是按需还是定期采集,数据采集都不会影响同时进行的其他采集流程。在采集阶段结束之后,数据可以被外部采集器轮询,或者输出到外部采集器。
CRS-1的性能监视器可以在所有支持的实体上,将本地的计数器与用户设置的阈值相比较,例如比较错误计数器和MPLS的接口、连接利用率。阈值条件被定义为对某个相对于阈值(使用百分比或者绝对值)的属性值的逻辑操作。阈值规则将在每次采集期间进行评估。一旦达到或者超过某个阈值条件或者标准,就会立即生成一个阈值超越警报(TCA)。范围操作功能让用户可以跟踪计数器在某个特定范围中的值(例如,
CPU利用率介于20%到60%之间),因而可以在系统性能超出预定范围时提供一个功能强大的通知机制。阈值重设规则指定了是否生成阈值通知——即使已经达到阈值条件。这避免了在某些情况下生成大量的阈值通知,例如在很短的时间或者间隔内阈值条件被反复超过。
搜集到的所有数据都会进行校验,以防止数据在路由处理器进行故障切换或者流程重启 时丢失。与其他事件一样,由嵌入式性能监视器生成的TCA可以像“嵌入式故障管理”部分介绍的那样,自动地对
关注天下网吧微信,了解网吧网咖经营管理,安装维护: