浅谈“双平面”冗余架构

浅谈"一网双平面"网络冗余架构

理论上来看：双平面架构的优势—冗余程度极高，可以实现高强度的互备分流效果。

如图所示，假设这是一个大型企业集团自己组建的广域骨干网络架构图，采用了双平面的架构部署。我们以该集团的北京公司为总部来看，如果我们将所有的分部都直接的与总部相连的话，那麽对于费用的需求是非常庞大的（例如：我们在各分部与总部之间都需要租用SDH专线或者是采用Internet VPN），在部署时对于技术的要求同样也是非常高的，而且长途的线路存在太多的不确定因素，为了防止网络出现问题，我们一般会采用双线冗余以确保稳定，那麽，稳定性是提高了，费用不也增大了吗？
我们拿双平面架构的拓扑图来分析，我们可以发现，我们只需要在总部与一些重要城市的分部之间构建我们企业自己的广域骨干网即可在提高稳定性的同时又保障费用不会增多的实现（可以利用分区域的思想，比如：这个企业可以根据自己在全国的业务区将全国的分部划入不同的业务区之中，最后在每个区域中挑选出一个重要的分公司来作为构建骨干网的支点来参与企业广域骨干网的构建即可），构建支点与支点之间的双平面骨干网络，那麽就可以极大的提高网络的稳定性。如图所示，我们在四个主要的分公司支点上构建企业的骨干网，以A、B两个平面来进行划分分析:我们可以将A、B两面承载于不同的运营商之中（不同运营商来承载的冗余程度非常高），以确保不会因为运营商某一方出现问题而造成我整个企业网络的瘫痪。A、B两个平面之间的连接就可以放到我们每个支点分公司的机房之内完成，这样也让公司内部人员对于线路的维护更容易一些。而对于没有构建骨干网的分公司而言，他们就可以采用就近连接的方式来接到企业的骨干网络之中（最好的连接方式是采用就近双线冗余的方式接入骨干网络之中，将分公司连接入A、B两平面不同的支点上，因为异地不同运营商的连接方式冗余程度最高），这样使得管理和成本都得到有效的控制。我们拿双平面架构的拓扑图来分析，我们可以发现，我们只需要在总部与一些重要城市的分部之间构建我们企业自己的广域骨干网即可在提高稳定性的同时又保障费用不会增多的实现（可以利用分区域的思想，比如：这个企业可以根据自己在全国的业务区将全国的分部划入不同的业务区之中，最后在每个区域中挑选出一个重要的分公司来作为构建骨干网的支点来参与企业广域骨干网的构建即可），构建支点与支点之间的双平面骨干网络，那麽就可以极大的提高网络的稳定性。如图所示，我们在四个主要的分公司支点上构建企业的骨干网，以A、B两个平面来进行划分分析:我们可以将A、B两面承载于不同的运营商之中（不同运营商来承载的冗余程度非常高），以确保不会因为运营商某一方出现问题而造成我整个企业网络的瘫痪。A、B两个平面之间的连接就可以放到我们每个支点分公司的机房之内完成，这样也让公司内部人员对于线路的维护更容易一些。而对于没有构建骨干网的分公司而言，他们就可以采用就近连接的方式来接到企业的骨干网络之中（最好的连接方式是采用就近双线冗余的方式接入骨干网络之中，将分公司连接入A、B两平面不同的支点上，因为异地不同运营商的连接方式冗余程度最高），这样使得管理和成本都得到有效的控制。
对于双平面架构，企业可以选择在不同的平面上来承载自己不同的流量。企业可以根据自己业务的需求来对业务划分不同的优先级，可以将自己最重要的生产流量单独承载于一个平面之上，其余等级的流量承载于另一平面之上，并且双面互相冗余，这样不仅使得流量的路径清晰固定，同时也防止了不会因为其中一个平面出现故障而影响到整个企业的运作。对于双平面架构，企业可以选择在不同的平面上来承载自己不同的流量。企业可以根据自己业务的需求来对业务划分不同的优先级，可以将自己最重要的生产流量单独承载于一个平面之上，其余等级的流量承载于另一平面之上，并且双面互相冗余，这样不仅使得流量的路径清晰固定，同时也防止了不会因为其中一个平面出现故障而影响到整个企业的运作。
对于企业以后有可能继续扩展的问题，只需要将新的分公司采用就近双线异地不同运营商冗余的方式接入企业骨干网之中即可。
4.双平面的架构部署更方便我们针对企业的流量实施QOS策略，我们将企业的不同流量承载于不同的平面之上，我们需要考虑的一个大问题是：当一个平面出现故障的时候，这个平面上的所有流量都将会切换到另一个平面之上，那麽切换过去之后会不会影响到另一个平面上正常的业务转发呢？这就要求我们在部署双平面架构时，根据不同等级的流量做不同的QOS策略，以确保当一个平面上网络出现故障时，企业所有的业务都承载于另一平面上且正常转发。这里我个人感觉：对于最低等级的流量，当网络某一平面出现故障，整体承载于一个平面之上时且网络负荷过大时，对于那些最低等级的流量就应该舍弃掉，以确保企业生产流量的正常转发。
技术实施上:我们以BGP的双平面冗余架构来进行分析。
各支点与支点之间如何构建骨干网络？
为了防止我们BGP所有设备处于同一个区域，一台设备出现故障会引起我们整个网络拓进行变更影响范围广的问题，我们对于BGP采用划区域的思想来应对。我们将A、B两个平面规划入不同的BGP区域之中，来实现A、B两区域之间的互备、提高网络的稳定性。我们之所以不采用对于一个城市划分为一个区域的方式来做，是因为成本太高（在运营商的网络中为我们划分区域）。A、B两平面内的所有设备之间是IBGP的邻居关系，两平面之间是EBGP的邻居关系，一般来说两个AS之间传递的流量会是非常大的，所以这样在两个平面之内的IBGP邻居关系之间我们采用运营商提供的专线，而两个平面的EBGP邻居关系是处于企业自己的机房之中的，那麽可以根据对于带宽的需求来增加带宽，就是由企业自己来完成的，从而避免了运营商的介入（运营商帮你提高带宽可是需要相应费用的）也可以节省相应费用。
分公司往分公司流量怎麽走？
在不同的平面内实施相应的策略，确保业务流量的来回路径必须是一致的。在整个双平面架构正常的情况下，不同业务流量承载于不同的平面之上，当某一平面出现故障之时，也得充分利用双平面的链路资源，避免备份业务对该平面承载的业务造成影响，所以必须确保故障平面上的流量仅在流量到达其备份链路所在地的另一平面上的骨干路由器上时才会切到非故障的一面上到达目的地。（切记：来回路径要一致）
简单配置：

规划：
R1-R8构建企业双平面骨干网；
R1、R2代表企业总部北京公司；
R3、R4代表企业分部成都分公司；
R5、R6代表企业分部深圳分公司；
R7、R8代表企业分部上海分公司；
R9代表企业分部西安分公司: R9有回环地址100.9.9.9代表生产流量专属、有回环地址100.100.100.100代表业务流量专属；
R10代表企业分部东莞分公司: R10有回环地址100.10.10.10代表生产流量专属、有回环地址200.200.200.200代表业务流量专属。
要求:
1.西安分公司到东莞分公司的业务流量走A平面;
2.西安分公司到东莞分公司的生产流量走B平面;
3.在网络线路出现故障时，两种不同的流量依然走不同的平面最终切换到达目的地;
4.在网络线路恢复正常的时候，两种流量按照最初的规划到达正常转发到达目的地。
对与BGP AS的划分，A平面处于BGP的AS 200之中，B平面处于BGP的AS 100之中，西安分公司位于AS 1之中，东莞分公司位于AS 2之中。
1.BGP可是超大型的网络协议，那麽他的路由条目可是一个特别庞大的数字，在这里我们可以借助BGP的community属性，来为业务和办公的路由打上一个类似于tag的标记，这样也方便我们后期实行对BGP选路的策略实施。
1>先利用前缀列表抓取路由:

2>利用route-map为路由打上标记；切记-邻居之间一定要开启传递BGP社团属性的开关，否则他自己收到可以识别,但是他不传递。

2.最初的设定（业务流量走A面、生产流量走B面）：
西安节点的路由表:
东莞节点的路由表:
3.当西安节点连接B面的线路出向故障时:
西安的路由表（切换至A面）：

那麽当西安去往东莞的生产流量进入ISP时，因为B面依然存在所以他应该正常的回到B面最终到达目的地，他就要从BJ-A回到B面。
在BJ-A上利用community-list来抓去我们做过标记的路由：

利用route-map来调整weight值,改变BJ-A去往DG的办公路由走B面：

切记：BGP的weight属性是不传递的，所以我们只能在自己的in方向上调用策略。
此时，对于A平面上去往DG的生产流量，或是对于A平面上去往XA的生产流量（当DG连接B面的线路出现故障时），我们要确保都能在公网中切换到B面上最终到达目的地，所以在A面上所有的骨干路由器上我们都要做相同的策略。
如果XA和DG连接B面的线路同时出现了故障，那麽在公网中是无法切回到B面最终到达目的地的，因为B面上学到的路由是来自于A面的。同样的，如果XA节点或DG节点连接A面的线路出向故障的话，我们也得确保公司的业务流量通过B面进入公网切回到A面到达目的地，我们也可以用同样的方法根据BGP的选路原则用同样的方法调整路径。
测试:
当XA连接B面的线路故障时:
当XA连接B面的线路恢复正常时:
对于BGP的双平面，我们必须熟悉BGP的属性以及记住他的选路原则。只有清楚的了解BGP每个属性的作用、作用范围、以及其选路规则的先后顺序，我们才能很好的控制BGP的路由优选路径以及实施我们的策略。
总结：对于BGP的双平面架构冗余，我们通过实验可以清楚的发现他的高强度冗余性以及他相较于单平面分流的优势，他可以保证网络在一个很好的状态下转发不同业务的流量，同时也保证了当公司网络或是部分运营商的网络出现故障时仍然不影响公司各种业务的通信。

浅谈“双平面”冗余架构相关推荐

《浅谈整车SOA架构》终篇：整车SOA系统设计
<浅谈整车SOA架构>终篇:整车SOA系统设计参考链接: 1.https://zhuanlan.zhihu.com/p/330973653 2.<浅谈整车SOA架构>第1篇: ...
[原创] 浅谈ETL系统架构如何测试？
[原创] 浅谈ETL系统架构如何测试? 来新公司已入职3个月时间,由于公司所处于互联网基金行业,基金天然固有特点,基金业务复杂,基金数据信息众多,基金经理众多等,所以大家可想一下,基民要想赚钱真不容易 ...
浅谈秒杀系统架构设计
秒杀是电子商务网站常见的一种营销手段. 原则不要整个系统宕机. 即使系统故障,也不要将错误数据展示出来. 尽量保持公平公正. 实现效果秒杀开始前,抢购按钮为活动未开始. 秒杀开始时,抢购按钮可以点 ...
JAVA如何输出六角形,浅谈 Java 六边形架构
原标题:浅谈 Java 六边形架构 dzone.com/articles/demonstration-of-hexagonal-architecture-in-java 六边形架构首先是一种设计模式, ...
浅谈工业网络架构及安全
浅谈工控网络架构及安全前言一.工控网络 1.工业网络词汇扫盲 2.工控网络架构 3.工业网络常见通信协议 Modbus OPC 二.工控安全前言长期以来,传统工业系统的设备专有性与天然隔离性使 ...
浅谈对IT架构师的理解
写此文章来源于到新公司的感触,我在新单位任职解决方案架构师职位,到了新公司碰到新同事大多以一种"异样"的眼光看着我,或者发出一些声音,比如:"哇,架构师啊..." ...
浅谈Java三层架构
1. 设计思想: 高内聚,低耦合. 2. 优点结构明确,开发人员只需关注其中某一层即可: 降低层与层之间的依赖,即低耦合性: 可以方便快捷地用新的实现替换原有的层次实现: 后期维护时,降低维护成本和 ...
浅谈：服务架构进化论
1.原始分布式时代一直以来,我可能和大多数的人认知一样,认为我们的服务架构的源头是单体架构,其实不然,早在单体系统盛行之前,我们的前辈们就已经探索过使用多个独立的分布式服务共同完成一个大型的系统的实 ...
一致先验分布后验分布_浅谈Loki分布式架构中的一致性哈希
云原生小白看到上面蓝色字了么?关注下吧! Loki在分布式部署的模式下,保存Ingester服务的状态主要有3个渠道,分别是etcd.consul和基于gossip协议的memberlist.不管L ...

浅谈“双平面”冗余架构

浅谈“双平面”冗余架构相关推荐

最新文章

热门文章