加载中…
个人资料
  • 博客等级:
  • 博客积分:
  • 博客访问:
  • 关注人气:
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
正文 字体大小:

城域网高可靠性部署

(2011-09-05 09:41:16)
标签:

城域网

高可靠

it

分类: 应用实践

文/陆宇翔

传统的高可靠性技术研究,通常是仅针对一个具体的故障点研究备份、切换方案。这类方案可将故障检测、切换时间大幅缩短,但是由于城域网的组网形式复杂、业务多样,一两项技术不足以解决城域网中可能发生的所有故障,需要多种技术配合使用以弥补彼此的缺点,而这些技术相互配合所产生的效果会随组网形式和业务的不同而不同。因此,高可靠性城域网的设计需要建立在对网络结构和业务类型有充分了解的前提下,有针对性地部署各项技术,从而提高网络整体的高可靠性指标。

1 城域网的业务模式

作为运营网络,城域网的主要用途是为运营商在城域范围内为专线客户提供接入、为各项电信业务以及电信增值业务提供管道,在IP业务快速发展的今天,主流的城域网建设中越来越倾向于加强承载网对于包分业务的转发能力,基于MPLS发展起来的二层隧道技术和基于Mac-in-Mac发展起来的PBB技术在现在的城域网建设中被广泛应用。

1.1 三种网络服务模型

根据一般城域网的业务需求,目前比较常用网络服务模型有E-line和E-LAN模型,以及后来在两者基础上衍生发展出的E-Tree模型。如表1所示。

E-line模型是典型的点到点业务模型,由两个严格对应的接口和一条映射规则组成。这是一种典型的“管道”模式。这种模型下,系统级的高可靠性往往不能仅依赖于隧道技术本身,而需要大量周边技术配合故障检测、业务恢复。

http://www.h3c.com.cn/res/201104/14/20110414_1175265_image001_711493_30008_0.jpg图1 E-line模型示意图

E-LAN模型是典型的多点到多点业务模型,由两个以上接口和一套相应的映射规则组成。由于提供了多个接口完全互连,这种模型理论上为高可靠性部署提供了一些便利,可以在周边设备配合较少的情况下,仅依靠自身提供的能力实现故障检测、业务恢复。

http://www.h3c.com.cn/res/201104/14/20110414_1175266_image002_711493_30008_0.jpg图2 E-LAN模型示意图

E-Tree模型其实是上述两种业务模型的融合模式,在早期的城域网设计中甚至没有提到这样的业务模型,但是由于后期涌现的一类应用需求,为了简化CE设备的复杂度,这类模型也成为了正式的讨论话题。在高可靠性部署方面,这种杂凑模型同时具备了上述两种模型的优点和缺点,而决定优缺点和复杂度的因素在于不同厂商的实现方式和实际网络部署方式。

http://www.h3c.com.cn/res/201104/14/20110414_1175267_image003_711493_30008_0.png图3 E-Tree模型示意图

2 高可靠性部署所面临的问题

目前大多数城域网的高可靠性设计都集中在城域网内部,主要是靠路由、MPLS、BGP等协议和诸如BFD、OAM等检测技术来提高系统级的收敛能力。这些技术的部署实际上跟做一张IP承载网没有什么本质上的区别。但是作为一张承载网络,需要将基于业务的端到端收敛作为最终设计目标,需要针对业务提供端到端的高可靠性,这必须考虑到业务类型的不同。

从接入用户的角度看,可以把主流的城域网业务类型分成三类:路由型接入、交换型接入和终端型接入。由于这三种业务类型具有各自的特点,所以在高可靠性部署方面也存在各自不同的问题。

2.1 路由型接入用户

路由型接入用户主要是指采用路由器等具备三层转发和路由计算能力的设备做CE接入的用户,通常一些大企业接入分支机构或者是中小企业总部分支互连都可以被划入这类用户中。

这类用户往往拥有一套庞大而复杂的网络,接入点多,内网路由表规模很大,如果使用传统的L3VPN,虽然从一定程度上可以实现端到端可靠性的需要,但其会增加私网管理的复杂度,私网庞大的路由表会对汇聚节点上的PE设备造成相当大的压力,且路由协议的收敛速度离高可靠性的要求还相去甚远。

如果采用城域网提供二层隧道接入,向用户提供透明的隧道业务,可以避免庞大的私网路由表给城域网设备带来太大的压力。而且路由型接入用户采用路由器作为CE设备,隧道内MAC地址的数量也相对有限,不会对PE设备表项产生太大压力。但此技术方式,PE和CE设备之间,几乎没有什么交互,在故障检测、收敛等方面略显乏力。如果仅在城域网内部UNI到UNI实现冗余备份提高可靠性,需要重点关注加快故障检测速度、减少倒换收敛时间,部署相关技术提高这些指标。但是如果要提供CE到CE或者是承载业务端到端的高可靠性,则会出现故障无法感知或感知时间长、业务无法平滑切换、一次故障(公网私网)二次收敛、环路或单通等问题,需要根据业务需求有针对性的做规划设计,通过不同技术手段的配合协同,才能达到目标。

2.2 交换型接入用户

交换型接入用户的网络规模较路由型用户小,通常是一些小型分支由没有三层能力的交换设备接入。

由于交换型接入用户的终端设备通过二层设备直接接入城域网,整网MAC地址数量会很大。如果在城域网汇聚设备上,都是这种用户,私网MAC表项可能需要以10k计。如此规模的MAC表项在故障倒换过程中所产生的表项删除、重学习、迁移等工作,对于设备和网络而言,都是很大的考验。如何提高MAC迁移效率,减少故障中发生MAC表项迁移就成了网络规划中影响高可靠性指标的重要工作。

同时在私网部分,如何感知故障、如何切换仍然是设计的核心,而且相对路由型接入用户而言,交换型接入用户的高可靠性需要更多城域网PE设备所能够提供的能力,如是否支持BPDU-tunnel等。

2.3 终端型接入用户

终端型接入用户在网络结构上和交换型接入用户比较相似,由业务终端直接接入城域网UNI接口,从成本因素和系统复杂度的角度出发,这些终端设备大多只具备很弱的二层功能。相对于交换型接入用户,终端型接入用户在CE侧能够提供的保护措施更少,这意味着城域网侧需要承担更多的冗余保护工作。比如一些终端只提供一个上连接口,这无疑会增加系统单点故障的风险;再比如一些终端虽然能够提供多个接口,但是只能实现简单的主备或者接口聚合一类的功能,不能支持像STP这样较为复杂的交换协议或BFD这样复杂度更高的协议,只能感知一些简单的直接的故障并提供有限的保护措施。

这些特点都导致了在城域网设计建设过程中,要针对这类接入用户做特别的考虑,来实现对这部分业务的高可靠性保护,而根据经验,往往这类业务对可靠性的要求还特别地高。

3 高可靠性部署

3.1 接入网部分

由于城域网业务多种多样,为了适应不同业务的不同需求,城域网接入网部分的组网形式也呈现出多种形态,主要包括以QinQ技术为核心大二层模式、MPLS到边缘模式、以及MAC-in-MAC接入VPLS汇聚等,无论哪种模式,都各有利弊。其中二层接入+MPLS汇聚是比较常见的模式,它的优点在于能够广泛适应各种业务的需求,且比较容易部署各种冗余备份技术,收敛指标好。下面就以这种模式为例,介绍一下接入网部分如何实现高可靠性部署。

一般来说,在网络结构简单,设备数量有限的网络中,部署二层冗余备份技术在收敛指标、部署管理的复杂度、网络的可复制/扩展性方面比部署三层冗余技术都有明显的优势。但是当网络规模扩大以后,二层冗余技术就会显得力不从心,效率明显下降,管理成本也呈几何级数增长。在二层接入+MPLS汇聚模式下,由于MPLS将多个二层接入网隔离开来,限制了二层网络的规模和复杂度,让二层冗余技术能够在接入层充分发挥收敛速度快的长处,并将复杂的汇聚核心部分的冗余备份交给路由和MPLS去完成。此外,由于城域网接入层往往是故障多发区,在故障发生时由二层冗余技术屏蔽故障对于三层网络的影响,减轻网络振荡给整网设备带来的压力,保护网络的核心部分。

在城域网内部做高可靠性部署,常见的冗余技术有STP/MSTP、RRPP、链路聚合等,常见的检测技术包括以太网OAM、DLDP、CFD等,规划网络时重点明确流量的主要路径、备份路径、阻塞点/节点、故障探测手段。如图4所示

http://www.h3c.com.cn/res/201104/14/20110414_1175268_image004_711493_30008_0.png图4 二层网络可靠性规划

再来看看业务端到端的高可靠性部署。

   路由型接入用户

这类用户由于主要依靠路由协议提供冗余保护,而城域网中部署的二层隧道技术对于当前几种主流的路由协议大多又都是透明的,所以几乎不需要对网络做额外的变更即可实现端到端的冗余保护。如果业务对可靠性要求较高,CE侧可部署诸如BFD之类的检测技术,加快故障检测和私网路由的收敛,但这就存在配合的问题。

如果BFD检测超时时间设置短于城域网二层故障收敛时间,在城域网发生故障收敛的时候,BFD会感知这个故障,然后通知私网侧路由重新计算,引发私网的路由收敛。由于城域网中二层收敛技术的收敛速度本身比较快,BFD发现短时间内网络恢复后,私网路由重新计算,再一次引发路由收敛。这样,本来很快就能恢复的业务,反而由于两次收敛而长时间中断。所以部署城域网的时候,通过理论论证和在网测试明确地获得某业务路径上,故障发生时二层收敛可能产生的最大中断时间是相当有必要的,这个时间是私网侧部署BFD检测时间的重要依据。

   交换型接入用户

由于私网侧也采用二层冗余技术,在一定程度上和城域网二层隧道部署中所采用的冗余保护技术产生冲突,并集中表现为本地环路和远端环路,如图5所示。这种环路几乎不可避免,因此用户接口上往往会采用BPDU tunnel方式透传CE侧发出的二层协议报文,通过私网侧运行STP协议检测冗余链路,阻塞备份端口的方法部分解决了环路的问题,但是对隧道故障的感知速度仍然达不到理想状态。

http://www.h3c.com.cn/res/201104/14/20110414_1175269_image005_711493_30008_0.png图5 本地环路示意图

http://www.h3c.com.cn/res/201104/14/20110414_1175270_image006_711493_30008_0.png图6 远端环路示意图

和路由型接入用户类似,交换型接入用户也可以通过BFD联动或是一些具备快速检测机制的二层冗余协议(如RRPP)来加快设备对隧道故障的感知。采用这些机制虽然加快了故障感知,降低了临时环路的产生,但是也会引入网络二次收敛的问题(类似于路由型接入用户部署BFD的情况)。针对这一类问题,可以尝试在部署相关特性时,使用快检测缓收敛的方针,即采用较小的hello timer间隔,保证能在第一时间感知路径恢复;采用较大的hello超时时间,避免由于城域网内部收敛而产生的瞬间中断引发私网路径的重复收敛。

   终端型接入用户

对于终端型接入用户而言,可靠性部署就需要因地制宜,针对不同形式的终端采取不同的高可靠性保护手段。

比如针对只能提供一个上连接口的终端,由于其故障风险主要集中在这条上连链路上,可以考虑就近加装一台具备保护功能的交换机,缩短单链路长度,降低故障风险;然后再通过这台交换机提供的冗余保护特性多链路上行接入城域网,通过备份链路保护故障风险高的长链路。

而一些具备多接口的终端型用户,则更需要根据其能够提供的冗余保护能力来定制组网方案,比如具备主备功能的终端,可以双上行到两台设备上,只要保证这两个端口之间二层透明可达,MAC地址及相关表项可以及时迁移即可实现冗余备份;如果终端可以做端口聚合,可以将聚合链路连接到城域网的一台接入交换机上,实现链路间的冗余备份,若担心接入交换机可能引发的单点故障,还可以在接入交换机上部署IRF技术,跨设备聚合,提供接入设备间的冗余备份。

3.2 核心网部分

目前,城域网的核心大多都是基于IP MPLS技术构建的。收敛指标更多取决于路由收敛速度和标签重分发速度,为了优化网络收敛指标,可以采取以下几种手段:

  用二层收敛替代三层收敛

主要是指采用链路聚合的方式加强链路的可靠性。虽然主流的路由协议本身具备感知拓扑变化并自动收敛的能力,但往往会因为一处拓扑发生了变化而引起整网路由的收敛,继而又引发MPLS LSP重新收敛,导致整个网络两次重新计算路由,这会对整网的稳定性带来很大的影响。大型的网络中,由于链路数量多,即使较低的故障率也可能导致网络总是处于振荡之中。如果采用聚合链路替代独立链路,不仅可以避免由于单链路故障而引发的路由重计算,由于聚合链路的收敛速度远高于路由收敛,还能大大得提高网络的故障收敛指标。

  提高设备自身的可靠性

虽然大多数核心网采取双节点的方式提供节点级的冗余保护,但是从维护整网稳定性的角度触发,每个单一节点的稳定仍然是需要重点考虑的。而且处于成本的考虑,现在城域网更多地引入了负载分担的设计,两个节点各自承担一部分流量,并互为备份,把流量引至备份节点还会引发带宽争夺等问题。所以加强单一节点自身的可靠性也应该作为网络规划的一个重要原则。常见的手段有双主控双电源、跨板聚合等方式。值得一提的是,为了避免设备在主备倒换时发生路由重收敛和流量路径切换,建议在关键节点部署具备GR能力的设备。

  使用虚拟化技术提升可靠性级别

如前文所述,通过增加冗余链路、冗余节点,采用mesh结构或局部mesh结构等方式来提供网络的可靠性的同时,会极大的增加网络的复杂度,增加网络管理和故障定位的代价。由于存在了大量链路节点,将使故障隐患点数量成倍增长,在三层网络中,一旦出现备份链路故障和恢复,会引起整网路由收敛。

采用IRF虚拟化技术将两个互为备份的节点整合虚拟化成为一个系统,可以极大的优化网络中的冗余结构,在提供同等级别的可靠性保证前提下,降低网络的复杂度。而且由于堆叠设备在逻辑上是一台设备,堆叠组中的单一设备故障也不会改变整个网络的逻辑拓扑,所以也就不会引发整网路由的重新收敛。

结束语

城域网的高可靠性部署的代价很高,它不但会增加网络的建网成本,后期维护管理的成本也高于那些没有专门规划可靠性的城域网。因此我们需要根据实际情况和需求,从网络规划和设计的角度出发,构建一个最优的网络。只有基于这个前提,才有可能构建最可靠和最实用的网络。贪大求多的堆砌特性,却没有合理的规划部署,不仅是毫无裨益的,反而会带来更多的问题。

0

阅读 收藏 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 产品答疑

新浪公司 版权所有