钟表

一首小诗~

钟表店里摆满了各种各样的钟表
每一个的时间都不一样
顾客问
怎么商品的时间不对也不调?
店主说
我这里每一个钟表呀
在世界上都有一个属于它的角落
它的时间是对的

 

TCP 长肥管道性能分析

先来说TCP 下载速度为什么这么慢?一文的答案:是因为接收端窗口太小。

这是一个典型「长肥管道」的问题。长,是说这个 TCP 连接的延迟很大,距离很长;肥,是说这个 TCP 连接的传输内容很多,尝试使用最大吞吐来传输内容,管道很粗,是肥。长肥管道的性能分析方法就是提示里面的《用 Wireshark 分析 TCP 吞吐瓶颈》介绍的,用此方法可以初步定位出来大部分的问题。

使用文中的方法打开 tcptrace 图,我们会看到这是一个典型的受接收端窗口限制的问题。

蓝色的线每次发送都受到绿色的线限制,即受到接收端窗口的影响

如果切换到 window scaling 图,会看到发送中的数据已经是和 window size 一样了。

window scaling 图

在这个问题中,我还加入了几个丢包。但是传输受到接收端的影响太大,丢包造成的影响倒是可以忽略不计了。如果把接收端的窗口扩大到很大,吞吐就会受到丢包的影响。(一般来说,如果丢包率到了千分之一,TCP 吞吐就会下降的很严重)。

类似问题另一个可以关注的地方是 TCP 的专家信息,Wireshark 会帮你分析接收端的窗口大小,如果接收端说自己的接收窗口已经是 0 了,请不要再继续发送了,我们可以在 Wireshark 中看到类似的提示。

Wireshark TCP 接收端窗口已满

其实我这次的抓包也有这些信息,只是为了不让这个问题太简单,我把所有的包接收端窗口改成最小为 1 了,所以读者没有看到这个提示,嘻嘻。

今年 Netflix 技术博客发布了一篇 debug 文章:Investigation of a Cross-regional Network Performance Issue。文中因为一个超时问题,最终定位到内核代码变更,导致接收端窗口大小不正确,影响了性能。我想说的是,原文在排查问题的时候,去看最近有哪些变更,定位到了内核问题。如果使用本文介绍的方法,排查思路是:请求超时 > 抓包确认 TCP 传输时间 > tcptrace 分析长肥管道传输性能问题 > 定位到接收端的窗口大小问题。这个思路按图索骥,更加 solid.

==计算机网络实用技术 目录==

这篇文章是计算机网络实用技术系列文章中的一篇,这个系列正在连载中,我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题,经过精心构造和编写,每个文件附带抓包文件,通过实战来学习网路分析。

如果本文对您有帮助,欢迎扫博客右侧二维码打赏支持,正是订阅者的支持,让我公开写这个系列成为可能,感谢!

没有链接的目录还没有写完,敬请期待……

  1. 序章
  2. 抓包技术以及技巧
  3. 理解网络的分层模型
  4. 数据是如何路由的
  5. 网络问题排查的思路和技巧
  6. 不可以用路由器?
  7. 网工闯了什么祸?
  8. 网络中的环路和防环技术
  9. 延迟增加了多少?
  10. TCP 延迟分析
  11. 重新认识 TCP 的握手和挥手
  12. 重新认识 TCP 的握手和挥手:答案和解析
  13. TCP 下载速度为什么这么慢?
  14. TCP 长肥管道性能分析
  15. 后记:学习网络的一点经验分享
与本博客的其他页面不同,本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
 

数据中心网络高可用技术之从服务器到网关:首跳冗余协议 VRRP

在前面的系列文章中,二层交换技术已经讨论的差不多了。我们现在知道了一个包经过交换机去往同子网下的其他主机都有哪些高可用技术。接下来,我们讨论下跨越子网的情况。

如果目标地址和自己不在同一个子网下,那么这个包就无法只经过二层网络到达目的地。必须经过三层路由。那么主机应该把这个包交给谁呢?回顾本系列开始的基础知识——如何在 IP 网络中将包送达到目的地,依赖的是所有参与三层路由的设备的路由表。在三层网络的视角下,我们的 Linux 服务器也是一个三层协议的参与者,服务器上也有一个路由表,只不过这个路由表很小,最核心的就是一条默认路由——如果不知道应该转发到哪里去,就转发给默认路由。

默认路由可以通过 ip route 命令来配置。

那么问题就出现了,这个 IP 只能配置一个,这不就成了一个单点故障了吗?

如何解决这个单点故障呢?既然静态的配置只能配置一个 IP,那么自然就想到我们可以使用动态配置。即这个默认网关 IP 是动态生成的。

从交换机的二层视角看,路由器和服务器是一样的

动态路由协议

一种方法就是让我们的服务器去运行动态路由协议(比如 OSPF,BGP),这种方法我们在四层负载均衡技术中见到过。这样,服务器就变成了一个动态路由协议的参与者,它不会在协议中参与数据转发,只参与控制面,只为了获取默认网关 IP。

这种方式缺点是配置复杂,带来了额外的计算成本,也给网络拓扑增加复杂度。当被作为默认网关的路由器故障时,需要的故障收敛时间也比较长。

ICMP Router Discovery Messages (动态路由发现)

RFC 1256 定义了一种基于 ICMP 的动态路由发现协议方法。简单来说,就是路由器会在 LAN 中不断广播自己的地址。这样,就可以配置多个路由器来一起广播自己的地址,每一个路由器的广播中会带有 preference level,这样,主机选择 preference level 最高的来作为自己的默认网关。新的主机在上线的时候,可以立即通过广播请求来询问路由器的地址。如果在使用的默认网关不再进行广播,就认为它挂了,去使用 preference level 下一级的路由器作为网关。

这种方法相比之下复杂度小一些,但是故障收敛时间也不小。

使用「动态」网关,每一个主机要独立判断当前网关的地址,所以收敛时间就不可避免地比较长。要想快速恢复,最好的方法还是静态配置,但是我们把静态配置的 IP 做成高可用的。

这里讨论一下 DHCP,很容易搞混。DHCP 不是一种动态生成网关地址的方式,在我们这篇文章讨论的上下文下,DHCP 也相当于是「静态配置」,只不过不需要在服务器主机上配置,而是在路由器上静态配置,主机通过询问路由器来获得这个静态配置。

DHCP 这种可以动态获取 IP 的方式,放在数据中心可太吓人了。数据中心网络的特点是,网络结构是确定的,主机数也是确定的,每一个服务器都应该有一个固定的 IP,而不是变来变去。所以,在数据中心网络基本上看不到 DHCP 协议。DHCP 用在园区网,办公网,家庭网络中,用于用户上网接入。

「高可用的网关」

我们现在需要设计一个高可用的默认网关。高可用最简单直观的方式是什么呢?active-backup. 所以我们使用两台路由器,一个作 Master,一台作 Backup。接下来我们只需要一种方式,能让 Master 在挂掉的时候快速切换到 Backup 就可以了。

怎么做到切换呢?网关和服务器在同一个子网,子网内的寻址方式是 MAC 地址。所以可以切换网关 IP 对应的 MAC 地址。但是这样太慢了,子网内所有的服务器都需要通过 ARP 发现 Backup 路由器的 MAC 地址才行。

怎么能更快呢?对咯,又是 Gratuitous ARP. 我们给两个路由器配置相同的 IP 地址、相同的 MAC 地址,正常情况下,询问网关 IP 对应的 MAC 地址的 ARP request 只有 Master 会响应,服务器感受不到 Backup 路由器的存在。一旦 Master 路由器挂了,Backup 路由器直接发一个 GARP 让交换机更新 MAC 地址对应的交换机端口,这样,发往网关 MAC 地址的流量就被交换机全部转发到了 Backup 路由器。服务器感知不到这个切换过程,切换是在路由器和交换机之间完成的。

设计好了切换过程,我们只剩下一个问题需要解决——何时切换。

切换其实是 Backup 路由器完成的,因为何时切换取决于 Backup 路由器何时发送出来这个 GARP 包。为了决定要不要切换,Backup 路由器需要知道 Master 路由器的状态。我们就需要一个协议能让路由器之间协商谁来做 Master,谁来做 Backup。

这个协议就是 VRRP(The Virtual Router Redundancy Protocol) 协议。

VRRP 示意图,交换机视角的 GARP 切换

VRRP

VRRP 是 IETF 定义的一个开放协议,标准化于 RFC 2338,发布于 1998 年。

2004 年,发布了 RFC 3768,VRRP v2, 主要添加了对 IPv6 的支持。

2010 年,发布了 RFC 5798,VRRP v3,主要添加了抢占模式,object tracking(追踪链路状态),sub-second timers.

VRRP 不是解决这个问题的唯一协议。这类协议的统称叫做 FSRP(First-hop redundancy protocol, 第一跳冗余协议)。比如:

  • Hot Standby Router Protocol (HSRP),思科专有协议。VRRP 大部分都是借鉴了 HSRP。
  • Common Address Redundancy Protocol (CARP),patent-free(VRRP 和 HSRP 都不是)。

VRRP 核心工作方式

VRRP 协议是路由器和路由器之间的协议,多个路由器合作来提供一个 Virtual IP 和一个 Virtual MAC,来给其他的 Host 作为默认网关。Host 不需要知道 VRRP 的存在,只需要静态配置默认网关地址即可。

VRRP 的核心工作方式就是,多个路由器选举出来一个 Master,其他的成为 Backup。Master 每秒广播自己的信息,表示自己健康。如果 Backup 3s (准确地说是 3s + Skew time) 没有收到来自 Master 广播包,就重新选举出来一个 Master。新 Master 发 GARP 指示交换机切换,并且开始承担转发流量的工作。

VRRP 协议只有一种包,结构如下:

VRRP 基于 IP Multicast 协议,广播的目标地址是 224.0.0.18,Master 路由器要定时广播上面这个结构的包,Src IP 设置为自己,IP 层的 TTL 设置为 255,如果不是 255,会被其他的路由器丢弃,但是这个 TTL 没有含义的,因为这个广播包不会被转发,其他的人收到这个包要么自己内部处理,要么丢弃。

VRRP 协议的参与者有三种状态:Initial, Master, Backup.

Initial 状态是刚启动的时候进入的,启动后如果 Priority(VRRP 配置项,可以在路由器上配置)是 255,直接成为 Master,否则成为 Backup。

Master 状态下,要负责以下几件事:

  • 回应对网关 IP 的 ARP request (一定要回应 Virtual MAC 地址,不要回应 Master 自己的物理 MAC 地址,不然的话正常情况下网络能通,但是发生选举切换之后,客户端还是用物理 MAC 地址访问,就挂了,相当于埋雷);
  • 目标地址是网关虚拟 MAC 地址的,进行三层转发;
  • 定时广播 VRRP 包;
  • 如果收到别人广播的 VRRP 包:
    • 如果对方的 Priority 更高(如果 Priority 相同,比较 IP 地址谁高),转入 Backup 状态;
    • 如果自己的 Priority 更高,丢弃(让他看看谁才是老大);
  • 如果收到 shutdown 信号,广播 VRRP 包并且把自己的 Priority 设置为 0,意思是本 Master 不再继续当 Master 了,请立即开始选举。这样,能让预期的维护降低 downtime;

Backup 状态下,要负责以下几件事情:

  • 如果收到了发给 Virtual IP 或者 Virtual MAC 的包,直接忽略;
  • 设置定时器,如果收到来自 Master 的广播包,重置定时器;如果定时器达到倒计时时间,成为 Master,开始广播 VRRP 包。

选举过程非常简单,基本上就是比 Priority,默认是 100,如果 Priority 相同,就比 IP 地址。

这里可能有一个问题,假设我们有 4 个路由器在子网内组成一个虚拟网关,现在 Master 挂了,那么 3 个 Backup 同时成为 Master 开始广播,虽然最终只会有一个 Master 存在,但是会短暂地造成 MAC flapping 问题。这个问题在协议中是通过加入 Skew_time 开解决的:

  • Backup 倒计时的时间是 (3 * Advertisement_Interval) + Skew_time;
  • 其中 Skew_time 的计算方式是:( (256 - Priority) / 256 );

这样,谁的优先级高,谁就会先发送。

部署结构

VRRP 本质上是一个主备方案,我们在这个系列开头就讨论过主备方案的坏处:备份意味着浪费资源。

有什么办法把资源都利用起来呢?其实到了三层上,我们可以看作是「客户端-服务器」架构了,Host 是客户端,默认网关是 Gateway。那么就可以用使用「负载均衡」的思想。

对于两个路由器 A 和 B,我们可以设置两组 VRRP,第一组 A 为 Master,第二组 B 为 Master。在子网所有的 Host 中,一半的 Host 使用第一组的 Virtual IP 作为 Default Gateway,另一半的 Host 使用第二组 VRRP 的 Virtual IP 作为 Default Gateway。这样,就可以实现「负载均衡」了,并且在任何一个路由器挂的情况下,另一个路由器会承担起两组 VRRP 的转发责任。

VRRP 负载均衡部署方式

实验

实验使用的拓扑图如下:

三个路由器运行 OSPF 路由,在 R1 上有一个 1.1.1.1 主机,R2 和 R3 都可以提供去往 1.1.1.1 的路由,并且 R2 和 R3 组成一个 VRRP,提供的虚拟默认网关地址是 192.168.1.1。我们在 ubuntu-1 上配置好静态默认网关,以达到在 R2 和 R3 之间任意一路由器挂掉都不影响从 ubuntu-1 到 1.1.1.1 的路线。

VRRP 实验

路由器的配置如下:

在 ubuntu-1 主机上 ping 1.1.1.1,然后挂掉当前的 Master R2 可以看到一共丢了 4 个包。

R3 显示从 Backup 成为 Master:

Until next time!

数据中心网络高可用技术系列

  1. 数据中心网络高可用技术:序
  2. 数据中心网络高可用技术之从服务器到交换机:active-backup
  3. 数据中心网络高可用技术之从服务器到交换机:balance-tlb 和 balance-alb
  4. 数据中心网络高可用技术之从服务器到交换机:链路聚合 (balance-xor, balance-rr, broadcast)
  5. 数据中心网络高可用技术之从服务器到交换机:802.3 ad
  6. 数据中心网络高可用技术之从交换机到交换机:MLAG, 堆叠技术
  7. 数据中心网络高可用技术之从服务器到网关:VRRP
 

数据中心网络高可用技术之从交换机到交换机:MLAG, 堆叠技术

上一篇文章结束对链路聚合的讨论之后,我们发现一个问题——我们只能用多条线连接到同一个 switch 上面,这样万一这个交换机挂了,连接这个这个交换机的机器(通常是一个 Rack)就一起消失了。

MLAG 技术

MLAG(Multi-Chassis Link Aggregation) 可以提供跨设备的链路聚合功能。

思科模块化交换机

Multi-Chassis 这个词很有意思,为什么叫做 Chassis (机箱)而不叫座 Multi-Switch LAG 呢?因为这个功能不仅仅是运行在 Switch 上,还记得在理解网络的分层模型中说的吗?二层和三层设备的界限已经越来越模糊了,三层设备也可以有这个功能。

现在的网络设备都是模块化的,一个机箱上面可以根据自己的需求插不同的线卡,卡上面甚至还能装不同的模块,满足不同的需求。机箱可以认为是网络设备单元,以「机箱」来说,意思就是运行于不同网络设备之间的功能。

MLAG 是一个设备的 feature,而不是协议,所以在不同厂商的产品中,MLAG,Peer Link 等术语会有所不同。

多交换机 MLAG

对于客户端 Linux 来说,不知道对端是两个设备,在 Linux 的视角下,自己的多条线路连接的就是同一个设备。

在交换机侧,就需要跨设备完成 LACP 信息的同步,两个交换机设备之间需要协调好,A 的 3号端口 和 B 的 3号端口是同一个链路聚合组(LAG)。所以两个交换机之间需要一条线,来沟通控制面的信息。这条线就叫做 Peer Link。在 Peer Link 上如何传输控制信息,取决于不同厂商对于 MLAG 的实现。某些厂商的设备使用 ICCP (Inter-Control Center Communications Protocol) 来进行不同的机箱之间的连接。

这样,就可以完成从服务器到交换机的高可用了,服务器网卡、网线、交换机接口、交换机系统、交换机整机,任意一个地方出现问题,都有冗余路线,不会对服务造成太大影响。

数据中心广泛使用的就是 MLAG。

堆叠技术

在交换机之间的高可用,还有一种技术,就是交换机堆叠。这个功能在不同的厂商里也是不同的名字,比如华为的 istack,思科的 StackWise.

简单来说,这个功能可以让多个交换机虚拟成一个。只有一个主操作系统在运行,其他的交换机就像主交换机扩展出来的板卡一样。堆叠之后只有一个管理 IP 和 MAC 地址,只需要登录一个系统进行配置操作。

4个交换机完成堆叠之后,相当于一个交换机有了 4 倍的端口

堆叠之后逻辑上就是一个交换机,所以服务器可以直接连接到多个物理交换机,从逻辑上看,交换机侧也是同一个了。

交换机堆叠连接服务器

堆叠也能实现故障快速切换,在正常情况下也能充分利用线路的带宽,配置简单。但是和 MLAG 相比,稳定性上来说 MLAG 更高,因为堆叠交换机只有一个控制面,如果主交换机出现故障,比如堆叠失效,整个堆叠集群都会出错。MLAG 的故障域更小,交换机坏也就坏一台。这也带来很多维护便利,从升级维护上说,MLAG 可以让我们一台一台地操作交换机升级而不影响服务,堆叠就会更加麻烦一些。从部署上,MLAG 不受距离显示,堆叠的话,两个交换机距离越远,出错的概率越大。

说起来,思科还有一个 VDC 技术(Virtual Device Context), 支持把一个设备虚拟成多个。这些技术又是把一个物理设备拆成多个又是把多个合成一个的,可真有意思。

这个系列的二层技术介绍的差不多了,我们下一篇就开始聊三层技术。

Until next time!

数据中心网络高可用技术系列

  1. 数据中心网络高可用技术:序
  2. 数据中心网络高可用技术之从服务器到交换机:active-backup
  3. 数据中心网络高可用技术之从服务器到交换机:balance-tlb 和 balance-alb
  4. 数据中心网络高可用技术之从服务器到交换机:链路聚合 (balance-xor, balance-rr, broadcast)
  5. 数据中心网络高可用技术之从服务器到交换机:802.3 ad
  6. 数据中心网络高可用技术之从交换机到交换机:MLAG, 堆叠技术
  7. 数据中心网络高可用技术之从服务器到网关:VRRP
 

TCP 下载速度为什么这么慢?

最近,某团队在上线一个 AI 训练服务,运行在美国。AI 训练需要从另一个服务加载一些数据,数据因为欧洲国家的规定必须存储在欧洲,在美国的训练集群只能按需去加载欧洲的数据。

在训练的时候, 这个团队发现美国的客户端去读取欧洲的数据效率很低,美国欧洲购买的带宽是 10MiB/s,但是实际运行,数据的加载速度只有 KB 级别。导致训练时间都花在了数据加载上。AI 团队刚刚采购了昂贵的英伟达 A100 显卡,这数据加载这么慢,显卡都闲着,眼看着钱都打水漂了呀。

这个团队听说隔壁组有个新来的同事小张(就是你!)经常在一个叫卡瓦邦噶!的博客上学习网络知识,现在已经学成一个网络大神了,说不定他能解决这个问题呢!

这个团队找到小张,小张听说之后眉头一皱,觉得事情并不简单,要求这个团队在美国机房的客户端侧测试一下 TCP 的传输速率

测试方法是,使用 iperf 软件测试带宽速度(可以理解为就是模拟 TCP 传输,使用一个连接,传输一个大文件,测试传输速度),并且在客户端机器上进行抓包。传输方向是欧洲向美国传输,抓包是在欧洲(TCP 的发送端)。

不一会,AI 团队发来了抓包数据。

小张兴奋地打开了 Wireshark……

请下载如下的文件并分析网络下载达不到带宽瓶颈的原因。

如果没有头绪的话,可以打开这个提示

==计算机网络实用技术 目录==

这篇文章是计算机网络实用技术系列文章中的一篇,这个系列正在连载中,我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题,经过精心构造和编写,每个文件附带抓包文件,通过实战来学习网路分析。

如果本文对您有帮助,欢迎扫博客右侧二维码打赏支持,正是订阅者的支持,让我公开写这个系列成为可能,感谢!

没有链接的目录还没有写完,敬请期待……

  1. 序章
  2. 抓包技术以及技巧
  3. 理解网络的分层模型
  4. 数据是如何路由的
  5. 网络问题排查的思路和技巧
  6. 不可以用路由器?
  7. 网工闯了什么祸?
  8. 网络中的环路和防环技术
  9. 延迟增加了多少?
  10. TCP 延迟分析
  11. 重新认识 TCP 的握手和挥手
  12. 重新认识 TCP 的握手和挥手:答案和解析
  13. TCP 下载速度为什么这么慢?
  14. TCP 长肥管道性能分析
  15. 后记:学习网络的一点经验分享
与本博客的其他页面不同,本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。