《Internet 路由结构(第2版•修订版)》一第7章 冗余、对称和负载均衡7.1 冗余

简介:

本节书摘来自异步社区《Internet 路由结构(第2版•修订版)》一书中的第7章,第7.1节,作者【美】Sam Halabi,更多章节内容可以访问云栖社区“异步社区”公众号查看

第7章 冗余、对称和负载均衡

Internet 路由结构(第2版•修订版)
本章包括如下主题。

  • 冗余——链路故障发生时,通过备用路由来保障网络的稳定是路由架构中最为重要的设计目标之一。
  • 设置默认路由——配置默认路由是建立冗余连接的基本方法。存在多条默认路由时,就需要通过优先级来“排定座次”。
  • 对称——设置路由,确保流量及其反馈流量从同一点进出AS,这往往也是路由架构的设计目标之一。
  • 负载均衡——让多条链路同时分担流量,以获取最优的网络性能。
  • 具体的场景——针对冗余、对称及负载均衡,深入剖析了几个具有代表性的网络设计。还提供了在几个不同场景中,实现上述设计目标的属性配置示例。

要实施高吞吐量的Internet连接,冗余、对称和负载均衡是每个网络工程师必须面对的关键问题。Internet服务提供商(ISP)和其客户都需要对流量进出各自AS的过程充分加以控制。

要实现冗余,通常的做法是以多条电路接入一个或多个AS,进而得到多条传递流量的备用路径。对称是指从某个出口点流出AS的流量,(其反馈流量)还能从同点返回1。负载均衡是指在多条链路上合理分担流量的能力。要想将三者合而为一,以实现最为理想的路由选择解决方案,难度之大可想而知。

不可能事事都政由己出。在Internet上,对于穿越任何AS流量的操纵和控制掌握在多家提供商手中。沿途的任何提供商都能引导流量。多个实体间的协作才是均衡流量之道。

如何将冗余、对称和负载均衡发挥到极致,这对每个网络来说都是永恒的设计问题。然而,具体的解决方案则取决于每一特定网络的配置和需求。本章会在具体的网络配置背景下探讨此类共性设计问题。虽然读者不能照搬配置示例,但配置示例中所展现的共性问题和实施方法,仍然可以作为读者分析和设计路由选择需求时的参考模型。

在深入研究具体的网络场景之前,读者首先需要建立起某些关于冗余的基本概念,并熟悉相关定义。

1作者的表达太过随意,让我们来打个比方,比如说AS内某用户ping某个Internet站点,ICMP的echo request数据包从AS的A点流出,其反馈流量,即该Internet站点的echo reply数据包也应从A点返回,这样才算流量对称。因此,译者在括号内添加了“反馈流量”。——译者注

7.1 冗余

Internet 路由结构(第2版•修订版)
尽管无论哪家公司或提供商都不愿意自己的网络中断,不过网络连通性问题总是会因这样或那样的原因纷至沓来。连通性问题取决于诸多因素。一条接入Internet的链路会涉及路由器、CSU/DSU、电源、电缆连接、物理接入线路以及众多运维人员——每个因素对链路的影响都各不相同。任何时候,人为失误、软硬件故障或自然灾害(比如恶劣的天气或电力中断)都有可能会导致网络中断。

正因如此,对网络来说,冗余是不可或缺的。然而,最为关键的是必须在冗余和对称之间找到平衡。在网络设计方面,冗余和对称似乎是天生的冤家:网络的冗余程度越高,流量的进出点就越不可预测。若某客户有多条连接——一条接入San Francisco POP(呈现点),另一条接入New York POP——从San Francisco“出发”的流量,(其反馈流量)很可能会从New York“回家”1。要是再新增一条到Dallas POP的链路,肯定会让网络连通性更为可靠,但也同样给流量对称制造了更多的麻烦。因此,网络管理员在实施路由策略时必须权衡取舍。

7.1.1 地理限制方面的压力

除了可靠性因素之外,地理方面的压力也迫使公司必须实现网络冗余。许多现代化的公司都是那种国际性、全国性或跨国性的大公司。这些公司的自治系统是跨越多个不同物理位置的逻辑实体。对于一个拥有跨越多个地点AS的公司来说,既可以从单提供商购买服务,也可以从位于不同区域的不同提供商购买服务。如图7-1所示,AS1位于San Francisco的办事处连接到ISP1的San Francisco POP,New York办事处连接到ISP2的New York POP。在这种情况下,访问Internet的流量可以就近选择POP,采用较短路径抵达目的地。

对于一个网络来说,冗余指的是除了主用链路以外,还有一条“后路”也能传递进进出出的流量,这会转化成需要保存在路由表中的额外路由信息。为了避免额外的路由开销,默认路由正是给自己网络留“后路”的实用工具。主链路故障时,默认路由可以为我们的网络开启后路(备用路由)。下一节会定义默认路由的方方面面,并展示如何在最简单的路由场景中应用默认路由。


fbdeabc8211f2c174f492654c88fc708e6ca4055

7.1.2 设置默认路由

按默认路由转发流量是一项非常强大的技术,既能将路由器必须学习的路由条数降至最低,又能在发生故障或连通性中断时为网络提供冗余。Cisco把默认路径称为最后求助网关(gateway of last resort)。理解默认路由如何运作非常重要。默认路由配置得当,可以省心省力;可一旦配置有误,则会让网络工程师深陷泥潭。

根据定义,默认路由是IP转发表中的一条路由,一旦数据包目的网络无法与路由条目匹配,路由器就启用之2。换言之,路由器在依仗IP转发表中的精确路由条目无法转发数据包时,默认路由就成了最后一根救命稻草。

动态学得的默认路由
众所周知,默认路由往往以网络/掩码组合0.0.0.0/0.0.0.0来表示(也可以0/0来表示)。默认路由可以在路由器之间以动态通告的方式来交换。任何系统只要通告这种路由,就是向其他系统表明:“我是你们的最后求助网关”。图7-2所示为默认路由的动态通告。

动态默认路由(0/0)既能通过BGP也能通过IGP学得,这取决于网域间所运行的路由协议。出于冗余并尽量避免潜在故障的目的,应该从多个源接收默认路由。在BGP中,可为默认路由赋予本地优先值,以令主备用默认路由分别具有不同的优先级。若主用默认路由失效,备用默认路由会取而代之。


e4dc12edb46964cab5a65f022577520ab0aeb9e2

图7-2左例所示为单台路由器通过两条链路将AS1和AS2互连。若AS1只愿意从AS2接收最少量的路由,那么AS1可以只接受默认路由0/0。在本例中,AS1从两条链路学得0/0,并为从主用链路学到的0/0路由设置了本地优先值100,为备用链路学得的0/0路由设置了本地优先值50。正常情况下,这台路由器的最后求助网关一定会被设置为1.1.1.1。

在多路由器的场景中(如图7-2右例所示),只要AS1内运行了IBGP,上述行为也同样适用——利用在IBGP路由器间交换的本地优先值,来确定主备用链路。

提示:
请参见第12章的“动态学得的默认路由”一节。
静态设置的默认路由
为了避免不可预料的流量转发行为,许多网络管理员都会选择对动态学得的默认路由进行过滤。因此,对AS来说,可以静态设置属于自己的默认路由0/0。通过静态的方式设置默认路由可以更好地控制路由选择的行为,原因是管理员可以亲手定义自己的最后求助网关,而不是任由外部实体强行设定。

提示:
请参见第12章的“静态设置的默认路由”一节。
管理员可以设置静态默认路由令其指向:

  • 下一跳网关的IP地址;
  • 一个特定的路由器接口;
  • 一个网络号。

图7-3所示为前两种情况。左图所示为路由器将自己的默认路由0/0指向IP地址1.1.1.1,右图所示为路由器将自己的默认路由0/0指向以太网接口。对于后一种情况,路由器还需额外的操作,以推断出应将流量转发给以太网段上的具体设备(下一跳路由器)。这样的操作往往是:路由器以发送ARP(地址解析协议)数据包的方式,来确定下一跳路由器的物理地址。


5b074775d5c01d0e0fe3af1db5a030dc87facced

一个系统还可以根据从另一个系统学到的网络号来设置自己的默认路由。图7-4所示为AS1从AS2动态学到路由192.213.0.0/16。若AS1将自己的默认路由指向192.213.0.0/16,那么网络192.213.0.0/16便会自动成为AS1的最后求助网关。该方法利用递归路由查找去发现下一跳网关的IP地址。在本例中,经过递归路由查找,AS1确定网络(路由)192.213.0.0/16学自下一跳1.1.1.1,流量也会被相应地转发到下一跳网关1.1.1.1。


c6828507b6e461dad2d42c6143b244d8d4cc5ce2

如果默认路由所指向的网络消失,默认路由也会自动消失,这一点十分重要。对于Cisco的实现来说,静态定义的默认路由存在的依据是,其所指向的路由条目必须存在。例如,若默认路由指向了某个网络号,但该网络已不可访问(与该网络相关的路由在路由表中消失),那么这条默认路由也会从IP路由表中消失。这一行为在配置了多条默认路由的情况下必不可少——可让一条默认路由作为主用,另一条作为备用,主用路由一旦失效,备用路由取而代之。

选择“默认路由所指向的网络”时,应尽量选择靠近Internet的上游网络(离本AS越远越好),因为这样的网络能够反映出:本AS到NAP或其他提供商之间互连的整条链路(而非局部)的状况。若为本方提供服务的AS只有单条链路通往NAP,这一点就非常重要。如图7-4所示,AS1在设置默认路由时,可以选择将其指向前缀128.213.11.0/24或超网192.213.0.0/16。将默认路由指向128.213.11.0/24,只能令默认路由本身依赖于部分环节(从AS1到AS2),而非直到NAP的所有环节(从AS1直到AS3)的稳定性。若AS2和AS3之间的链路故障,AS1仍然会向AS2发送流量,而不会遵循备用默认路由将流量发送给其他提供商(假定AS1还连接到了其他提供商)。更为合理的选择是,将默认路由指向超网192.213.0.0/16,原因是这一超网的存在能够更全面反映出从本AS到NAP的整条链路,而不再对任何中间环节有所依赖。

选择“默认路由所指向的网络” 3时,应尽量避免选择精确的子网。子网的翻动可能会造成本方路由表中的默认路由“时有时无”。最好将默认路由指向能够全面反映出提供商整体稳定性(而非特定链路稳定性)的主要聚合网络或超网。

可以同时配置多条静态默认路由。其中一个方法就是,设置多条静态默认路由,令它们分别指向多个不同的网络(出于稳定性的考虑,应尽量指向聚合网络),并利用BGP本地优先属性为学到的聚合网络设定不同的优先级。这种做法适用于单台路由器通过多条链路连接提供商,或AS内多台边界路由器运行IBGP的场景。图7-5所示为这两种场景。以上两种场景也与图7-4所示的场景类似,唯一的差别就在于,客户(AS1)是手动设置自己的默认路由,而不依赖于提供商通告默认路由0/0。在本例中,客户(AS1)会为从上下两条链路学到的路由128.213.0.0/16分别设置本地优先值100和50。这样的话,上下两条链路分别为主备用链路,若主用链路故障,下面那条链路会取而代之。


e27fb0277e995a802310a595cd4af0df05e70765

设置静态默认路由的另一种方法需要使用Cisco距离参数(如第6章中的表6-1所述)来建立优先级。由于路由器之间不会交换距离参数,因此这种方法只适用于单台路由器通过多链路连接提供商的场景。

若为两条静态默认路由分别赋予不同的距离值,路由器会优选距离值较低的那条路由。若距离值较低的那条路由失效,路由器会选择使用另外一条默认路由。若为两条静态默认路由配置了相同的距离值,根据由网络设备的底层交换模型所提供的机制,流量会在两条默认路径上负载均衡。

图7-6所示为设置多条静态路由时,距离参数的运用。AS1通过2条链路接入AS2,并自行手动设置指向AS2的默认静态路由。AS1通过将两条静态默认路由的距离值分别设置为50和60,从而分别选定了主备用链路。如果主用链路发生故障,流量会切换到备用链路。


0e6177203425c30e9a095caf7647c2913a4c2395

读者需要理解:如果一条路由与路由器接口相关联,在接口故障之后,这条路由也一定会失效。例如,默认情况下,用来封装接口的Cisco HDLC协议会在链路上交换KEEPALIVE消息。在指定时间间隔内,如果没有收到KEEPALIVE消息,接口的线协议会down。路由器也会删除相应的路由条目。话又说回来,对于像帧中继或ATM这样的虚电路,路由器之间并不交换KEEPALIVE消息。这也就是说,如果虚电路故障,接口仍会处于激活状态,相关的路由条目也就不会失效。

1作者的表达极为不严谨,“反馈流量”是必须要加的,否则就形成了环路。——译者注
2原文是“By definition, a default route is a route in the IP forwarding table that is used if a routing entry for a destination does not exist.”译者认为,作者的文字表达能力太差,如果不懂何为默认路由的读者,读完这段文字后估计还是一头雾水,故译文酌改。另外,IP转发表和IP路由表是不是一回事,还很难说。因为,IP路由表属于控制层面,而转发表则应属于数据层面。这里就姑且将IP转发表看作是IP路由表吧。——译者注
3原文是“Default network”,作者的文字表达能力实在令人“赞叹”。——译者注

相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
6月前
|
存储 负载均衡 网络协议
企业实战(13)LVS负载均衡DR(直接路由)模式实战详解(二)
企业实战(13)LVS负载均衡DR(直接路由)模式实战详解(二)
105 0
|
7月前
|
存储 负载均衡 网络协议
LVS负载均衡群集—DR直接路由
LVS负载均衡群集—DR直接路由
65 0
|
负载均衡 Java API
Spring Cloud Gateway整合Nacos实现服务路由及集群负载均衡
我们都知道Spring Cloud Gateway是一个基于Spring Boot、Spring WebFlux、Project Reactor构建的高性能网关,旨在提供简单、高效的API路由。
Spring Cloud Gateway整合Nacos实现服务路由及集群负载均衡
|
负载均衡 算法 网络安全
LVS负载均衡群集——DR直接路由模式(下)
一、 LVS-DR 工作原理 1.1 LVS-DR数据包流向分析 (1)客户端发送请求到Director Server (负载均衡器),请求的数据报文(源IP是CIP,目标IP是VIP)到达内核空间。
181 0
|
缓存 负载均衡 网络协议
LVS负载均衡群集——DR直接路由模式(上)
一、 LVS-DR 工作原理 1.1 LVS-DR数据包流向分析 (1)客户端发送请求到Director Server (负载均衡器),请求的数据报文(源IP是CIP,目标IP是VIP)到达内核空间。
182 0
|
负载均衡 网络协议 调度
LVS负载均衡群集—DR直接路由模式(越是不顺的时候,越要沉住气)(二)
LVS负载均衡群集—DR直接路由模式(越是不顺的时候,越要沉住气)(二)
111 0
LVS负载均衡群集—DR直接路由模式(越是不顺的时候,越要沉住气)(二)
|
负载均衡 网络协议 前端开发
LVS负载均衡群集—DR直接路由模式(越是不顺的时候,越要沉住气)(一)
LVS负载均衡群集—DR直接路由模式(越是不顺的时候,越要沉住气)(一)
133 0
LVS负载均衡群集—DR直接路由模式(越是不顺的时候,越要沉住气)(一)
|
负载均衡 Kubernetes 前端开发
负载均衡和路由 | 学习笔记
快速学习负载均衡和路由
246 0
负载均衡和路由 | 学习笔记
|
运维 负载均衡 算法
从负载均衡到路由,微服务应用现场一键到位
本文基于常见的服务调用场景,以 Ribbon 负载均衡组件为例,展示了微服务洞察能力能够在关键的位置为我们还原与记录丰富的现场信息,使得原有的黑盒场景能够便捷直观地被观测到,在微服务架构下,类似的不便观测的重要场景还有非常多,都可以借助微服务洞察能力来监测或是在异常时辅助排查。
从负载均衡到路由,微服务应用现场一键到位
|
负载均衡 Cloud Native Java
从负载均衡到路由,微服务应用现场一键到位
微服务引擎MSE面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持Nacos/ZooKeeper/Eureka)、云原生网关(原生支持Ingress/Envoy)、微服务治理(原生支持Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。
从负载均衡到路由,微服务应用现场一键到位