《路由设计的优化》一1.2 可靠性

简介:

本节书摘来自异步社区《路由设计的优化》一书中的第1章,第1.2节,作者【美】Russ White , Don Slice , Alvaro Retana,更多章节内容可以访问云栖社区“异步社区”公众号查看

1.2 可靠性

路由设计的优化
可靠性和弹性是相辅相成的,弹性网络可以为网络应用提供更可靠、可稳定的运行平台,而检视一个高可靠性网络时,也必然能够发现其具备非常好的弹性能力。需要注意的是,不要将弹性能力与冗余性混为一谈,虽然冗余性能够在某些场合下提供很好的弹性能力,但是仅仅简单地在网络中部署冗余机制,是无法持续提高网络弹性能力的。

首先来看一下什么是可靠的网络,简单来说,可靠的网络就是能够为商业应用提供不间断运行的平台。那么商业应用的可靠运行又依赖于网络的哪些方面呢?当然是网络的可靠性和数据传送的及时性,换言之,可靠的网络必须能够在合理的时间内将网络所接受的每个数据包都正确无误地传送到目的地。这个定义包括以下4层意思。

并不是连接在网络上的所有设备发出的每个数据包都会被网络所接受。
并不是每个被网络所接受的数据包都需要进行传送。
被网络所接受的需要传送的数据包必须被快速传送。
被网络所接受的需要传送的数据包必须被稳定传送。
虽然有关QoS(Quality of Service,服务质量)的话题超出了本书写作范围,但是在进行网络设计时保持更高的视角来审视数据包传送问题仍然是十分必要的。

1.2.1 数据包传送的可靠性

如果网络的职责就是可靠地传送由连接在网络上的设备所发送的大量数据包所组成的数据,那么为何网络还会拒绝某些流量呢?原因在于这些网络设备所发送的聚合流量常常超出了网络能够处理的流量极限,比方说,某个房子前的街道通常都只有很少的车流,但如果某一天,其邻居在同一时刻都走出家门,同时坐进汽车,又都同时通过这条街道外出时,这条街道可能将无法处理这么大的聚合流量,此时,某些人就必须等待很长时间才能穿过这条街道,某些人则会放弃出行而回家呆着,因此可以说,该街道的宽度限制了从这所房子进入高速公路的流量。

从某种程度上来说,虽然所有的网络都有可能限制进入某个网络的流量,但通常限制发生点都位于网络边缘,例如,如果远程站点与网络边缘路由器之间是一条中速串行链路,那么该网络边缘就必然会被附加相应的流量接收策略,因为该远程站点无法向公司总部站点发送比这条中速串行链路所能承载的更高流量。

虽然从技术上来说,WFQ(Weighted Fair Queuing,加权公平队列)和LLQ(Low Latency Queuing,低时延队列)等QoS技术不属于包接纳控制策略,但是当网络中出现了此类限制因素时,这些技术可以决定允许哪些流量进入网络。

通常来说,在特定的时间和条件下,网络工程师可以确定网络将要承载多大的合法流量,从而据此来规划网络容量和制定相应的流量策略。通常需要在承载更多流量的网络能力与网络成本之间进行折中,而网络能力与网络成本之间的合理关系最终应取决于商业因素,而非网络设计因素。虽然可以采取一定的技术手段来限制网络中的非法流量,如阻塞某些应用协议或禁止访问某些服务器,但在实际应用中几乎没有人会单纯依靠这些技术手段来限制网络流量。

一旦网络接受了这些数据,就必须保证能够可靠地传送这些数。当然,对不同的应用来说,“可靠传送”的含义也有所不同。例如,对于语音和视频数据包来说,丢弃这些数据包比乱序传送或延时传送要好得多,而对于FTP(File Transit Protocol,文件传送协议)流来说,慢慢传送这些数据流则比丢弃这些数据流要好得多。

这是因为对VoIP(Voice over IP,IP语音)流来说,只要被丢弃的数据包足够少,使用者就不会有任何感觉。但是对FTP流来说,即便被丢弃的数据包很少,也会因传送速率过低而导致网络不可用,这是因为FTP使用的是TCP(Transmission Control Protocol,传输控制协议),而TCP控制数据传送速率的准则就是丢包的数量。

因而,在设计网络时必须仔细考虑的一个问题就是网络中的应用类型以及这些应用的流量属性,必须为这些不同的流量制定不同的边缘接纳控制策略,并考虑其他QoS问题。虽然本书不会展开讨论这些问题,而是将重点聚焦到路由设计上,但是,由于网络是一个系统,即便可以独立探讨不同的网络设计因素,但是在实际工作中必须全面考虑网络设计过程中遇到的所有问题。

1.2.2 数据包传送时间

在讨论数据包传送及时性的时候,首要考虑到的因素就是数据包穿越网络的总时延,即数据包从本端设备发出到被对端设备接收到所花费的时间。但是,该时延并不是解决数据包传送时间所要处理的唯一问题(即便有时是首要问题),在很多场合下,数据包穿越网络所产生的时延(即传播时延[propagation delay])并不是唯一最重要的问题,时延的一致性(即抖动[jitter])也是非常重要的。图1-1解释了数据包穿越网络时的时延与抖动之间的差异。
image

当然,不同的网络应用对传播时延的敏感度不一样:

由于用户不可能知道流式音频连接中某个数据包的发送时间,因而此时的传播时延就不那么重要,但流式音频数据包的抖动却会严重劣化音频质量;
当用户通过终端程序与远程主机进行交互时,虽然一般不会在意数据流中数据包的抖动,但是如果传播时延过大,可能会让用户感到网速太慢甚至不可用;
只要网络的传播时延较小或适度,那么VoIP就能工作得很好,但是必须保证抖动指标足够小,以允许接收端能够以恒定速率缓冲并回放所接收到的数据包。

1.2.3 时延和抖动预算

要想确定网络为满足各种应用所允许的最大传播时延和抖动指标,就必须仔细分析每种流量的类型并确定每种应用流量的时延和抖动预算,虽然QoS问题不是本书的讨论重点,本书也不会深入讨论如何确定时延和抖动预算,但在实际工作中认真做好这项工作却是非常必要的。

1.2.4 网络设计对时延和抖动预算的影响

由于本书的重点是讨论三层网络的设计(包括路由协议),因而在考虑QoS问题时,需要解决的问题是:

网络设计(特别是在路由协议部署方面)会对网络的QoS造成哪些影响?

更准确地说,应该考虑以下问题:

某些场合下,路由及路由系统的设计会影响网络的QoS;
拓扑结构以及网络拓扑结构的设计会决定网络中任意两点之间的路径长度,从而会影响传播时延及抖动;
路由协议负责在网络中传送数据流量,在网络各节点之间沿着正确的路径传送数据流量(流量工程[traffic engineering],即TE)是进行网络优化的重要因素;
网络的可靠性会影响网络为各种应用程序提供所需服务等级的能力。如果网络不可靠,那么就无法可靠地传送数据包或者无法在容许的传播时延及抖动预算下可靠地传送数据包。
例如,分析对比数据流穿越网络中每条路径时的时延和抖动预算以及这些路径的最大时延和抖动是非常有意义的(如图1-2所示)。

image

主机A通过路由器C和路由器D到达主机B的路径是一条轻载的中速链路,而通过路由器E和路由器F的路径则是一条重载的高速链路。虽然沿着路由器E和路由器F这条路径传送数据包的时延应该较低,但由于该链路是重载链路,因而抖动或数据包传送时间的变化值可能更大。与此相对,虽然沿着路由器C和路由器D这条路径传送数据包的时延虽然较高,但由于该链路是轻载链路,因而抖动相对较小。

在理解了这些与网络物理设计和拓扑结构设计相关的影响因素之后,就可以与网络中运行的各种应用程序的需求进行比对,在满足这些应用程序的网络传送要求的情况下,制定最有效的设计方案,包括各种QoS技术(不在本书讨论范围之内),以确保满足各种CoS(Class of Service,服务等级)。

Cisco Press发行了两本非常有价值的QoS参考读物,分别是由Tim Szigeti与Christina编著的End-to-End QoS Network Design和由Wendell Odom与Michael Cavanaugh编著的Cisco QOS Exam Certification Guide。

相关文章
|
16天前
|
监控 负载均衡 网络协议
OSPF在大型网络中的应用:高效路由与可扩展性
OSPF在大型网络中的应用:高效路由与可扩展性
77 1
|
4月前
|
运维 负载均衡 监控
确保网络设计中的冗余和高可用性
【8月更文挑战第24天】
260 0
|
5月前
软件复用问题之度量组件的可靠性,如何解决
软件复用问题之度量组件的可靠性,如何解决
|
5月前
|
机器学习/深度学习 自然语言处理 数据挖掘
RouteLLM:高效LLM路由框架,可以动态选择优化成本与响应质量的平衡
新框架提出智能路由选择在强弱语言模型间,利用用户偏好的学习来预测强模型胜率,基于成本阈值做决策。在大规模LLMs部署中,该方法显著降低成本而不牺牲响应质量。研究显示,经过矩阵分解和BERT等技术训练的路由器在多个基准上提升性能,降低强模型调用,提高APGR。通过数据增强,如MMLU和GPT-4评审数据,路由器在GSM8K、MMLU等测试中展现出色的性能提升和成本效率。未来将测试更多模型组合以验证迁移学习能力。该框架为LLMs部署提供了成本-性能优化的解决方案。
155 2
|
5月前
|
存储 数据中心 开发者
交易链路设计原则&模式问题之协调者在系统中的知名度对开发的影响如何解决
交易链路设计原则&模式问题之协调者在系统中的知名度对开发的影响如何解决
|
5月前
稳定性摸排问题之怎么确定目标如何解决
稳定性摸排问题之怎么确定目标如何解决
|
5月前
|
设计模式 存储 Java
代码优化设计问题之解耦策略路由和策略实现的依赖问题如何解决
代码优化设计问题之解耦策略路由和策略实现的依赖问题如何解决
|
6月前
|
消息中间件 中间件
中间件消息降低系统复杂性
【6月更文挑战第9天】
31 4
|
消息中间件 存储 数据可视化
【结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性】
【结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性】
130 1
|
7月前
|
监控 负载均衡 网络协议