《路由设计的优化》一1.3 可靠性和弹性-阿里云开发者社区

开发者社区> 开发与运维> 正文

《路由设计的优化》一1.3 可靠性和弹性

简介:

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

1.3 可靠性和弹性

路由设计的优化
如果网络不转发网络设备之间的数据,那么应用程序就无法正常运行;如果网络宕机,那么应用程序就无法工作。因此,如果网络应用依赖于网络设备之间的连通性,那么网络就必须足够可靠(reliable),虽然这是显而易见的道理,但如果深入分析这个概念,大家会在表象之下发现很多非常复杂的东西。

既然可靠性很重要,那么如何构造可靠的网络呢?最明显的答案就是尽可能减少网络变更的次数,网络的变更次数越少,网络就越稳定,越可靠。

但是变更又是网络所不能避免的,网络规模越大,网络(至少某些网络组件)发生变更或出现故障的可能性就越大。例如,假定网络中的设备每5年变更一次(如果每次变更或故障时间为1小时,那么正常运行时间将达到99.99997%),如果网络只有5台设备,那么平均每年只有1台设备出现变更或故障,但是如果网络拥有500台设备,那么平均每年将有100台设备出现变更或故障,也就是平均每3天就会出现一次设备变更或故障。图1-3解释了多台设备出现多次变更所带来的复合影响。

很明显,即使网络设备的可靠性非常高,但是只要网络大到一定的规模,那么网络将不可避免地处于经常性的变动状态,变更的原因可能是设备故障,也可能是网络优化调整。

image

因此,尽管可以通过减少网络变更和故障发生率来提高网络的可靠性,但是网络变更始终存在,通过部署可靠性更高的网络设备以及各种高可靠性机制,可以减少特定时间窗口内网络出现变动的次数,因而需要围绕各种可能发生的变更因素进行网络设计,这就是所谓的网络弹性(resiliency)。

网络弹性是网络保证不间断运行状态下适配网络变更(因配置出现变化或者网络出现故障而引起的网络变更)的能力。一旦确定了网络在特定时间窗口内所能处理的变更次数,就可以在网络设计过程中引入适当的弹性机制,以应对已确定的网络所能处理的变更等级,从而设计出可靠的网络。

1.3.1 定义网络故障

图1-3给出的结果令人感到惊讶,随着网络规模的增大,无论网络设备的可靠性有多高,因网络设备变更或网络设备故障引起的网络变更次数都将不断增大。不过,网络组件的变更或故障是不是就等同于网络故障呢?

回顾前面谈到的构造可靠网络的设计目标,只要网络能够将网络边缘接收到的绝大多数数据包及时传送到目的端,就可以认为该网络处于工作状态。如果网络中的某条链路出现故障,那么该网络能否继续及时地传送数据包呢?

从应用的角度来看,只要做到了以下几点,即使网络中的某条链路出现故障,仍然可以认为网络处于运行状态。

网络拥有其他可选路径(如与故障路径并行的第二路径),而且可以通过该可选路径继续及时地传送数据包。
受网络变更或故障影响的应用程序或用户群对该网络的首要设计目标影响不大(例如,对一个主要提供金融业务的网络来说,无法访问某台游戏服务器是无关痛痒的),而且网络可以及时传送从网络边缘接收到的绝大多数数据包。
因此,网络故障的定义与部署在网络中的应用及其功能相关,从更宽泛的角度来看,网络故障的定义与网络设计息息相关。对网络中运行的每种应用程序来说,网络设计人员要考虑以下问题。

该业务不可用的代价是什么?
对该应用程序来说,是不是某些特定网段比网络的其他部分更重要?
为保证该应用程序的正常运行,是否需要特定链路都必须可用?
例如,电子邮件通常是企业员工之间最主要的通信方式,如果电子邮件系统中断5分钟,一般会是给大家带来一定的工作不便。但是,如果电子邮件系统中断5小时,那么就很可能会给企业造成大量的经济损失。因此,定义网络中运行的每种应用程序的服务级别(基于最大宕机时间的容限)是网络设计工作中非常重要的环节。

每种应用程序都可能会包含需要可靠连接的服务器或主机。仍然以电子邮件为例,当电子邮件服务器与网络之间的连接不可用时,在同一时刻与网络失去连接的每个用户都会遭受相同的后果:电子邮件服务不可用!

对某些时延敏感型应用来说,虽然网络并没有出现传统意义上的故障,但这些应用实际上已经失效—即使没有丢包或者只有少量丢包。例如,当网络中某条链路出现故障时,如果网络没能快速适应拓扑结构发生的变化,使得少量数据包被丢弃或出现较大的时延,那么将会导致大范围的语音呼叫复位现象。

还有某些应用属于时延敏感型应用,如依赖汇率或价格快速变动的金融交易型应用,特别是那些大批量、高速金融交易模型,如大型股票和金融证券交易操作。

除了传统意义上的网络故障,还应考虑网络故障对某些特殊应用的数据包传送的及时性会产生哪些影响,此时应逐一分析网络中的每种应用和主机(或主机类型)的特性,并分别为其制定相应的故障定义。如果没有这些故障定义,那么就无法定义哪些故障是“网络故障”,也就无法精确地度量网络的正常运行时间(uptime)和宕机时间(downtime),也就是无法度量网络中运行的各种应用的可用性,如此一来,所谓的5个9可靠性(将在随后的“平均故障间隔时间”一节详细讨论)也就毫无意义了。

1.3.2 网络恢复时间

虽然有关各种网络应用的不同网络可用性需求的讨论已经超出了本书写作范围,但是网络组件发生变更或故障后的网络恢复时间却是本书后续讨论的重点内容。如果某个网络每年才出现一次故障,但每次故障恢复时间都长达三个星期,那么该网络的正常运行时间也很差。

网络恢复包含多个等级,每个等级都有相应的时间。

网络从故障状态恢复到正常运行状态所花费的时间。例如,当某条链路出现故障时,路由协议中涉及该链路的路由都会失效,那么路由协议为调整网络中去往该故障链路的路径所花费的时间就属于这类时间,本书将在后续内容中深入探讨这方面的问题。
网络故障排查所花费的时间以及修复因网络组件发生变更或故障而引起的网络故障(网络无法自动修复这些故障)所花费的时间。当网络设备或链路出现故障后,需要花费多长时间才能完成故障排查和故障修复呢?该时间是网络可管理性以及其他许多问题的基本构成因素。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章