BigBrother:UCloud 全链路大规模网络连通性检测系统详解(下)

阅读数:143 2019 年 11 月 7 日 23:13

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

4 各场景下探测报文的生命周期

BB 被设计为支持多种网络场景,能应对物理云和跨域互通的网络复杂性。这章节我们以探测物理云和跨域为例,详细分析下 BB 探测报文的生命周期。

  • 物理云

公有云互通物理云场景下,探测报文生命周期如下:

公有云—> 物理云

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

1)BigBrother 向公有云宿主机发送探测报文

2)ovs 收到报文后镜像至 BigBrother
3)ovs 将报文送至实例
4)实例回应报文
5)ovs 将回应报文镜像至 BigBrother
6)物理云核心交换机收到报文,并发送给汇聚交换机
7)8)9)10)物理云汇聚交换机发送报文给 vpcgw,vpcgw 处理报文后回送至汇聚交换机
11)在物理云汇聚交换机配置 ERSPAN,将报文镜像至 BigBrother。

物理云—> 公有云

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

1)BigBrother 向 vpcgw 发送探测报文
2)3)vpcgw 处理报文后回送至汇聚交换机
4)在物理云汇聚交换机配置 ERSPAN,将报文镜像至 BigBrother
5)汇聚交换机将报文送至 phost 的上联 Tor
6)Tor 将报文送至 phost
7)phost 回应报文
8)在 phost 的上联 Tor 配置 ERSPAN,将报文镜像至 BigBrother
9)报文送至公有云宿主机 ovs
10)ovs 收到报文后镜像至 BigBrother

  • 跨域网关

公有云跨域互通场景下,探测报文生命周期如下:

本地域—> 地域 B

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

1)BigBrother 向本域主机发送探测报文

2)ovs 收到报文后镜像至 BigBrother
3)ovs 将报文送至实例
4)实例回应报文
5)ovs 将回应报文镜像至 BigBrother
6)ovs 将报文送至 sdngw
7)sdngw 将报文镜像至 BigBrother

地域 B—> 本地域

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

1)BigBrother 向本域 sdngw 发送探测报文
2)sdngw 收到报文后镜像至 BigBrother
3)sdngw 将报文送至对端 sdngw 进行转发
4)本域 sdngw 收到对端回应报文
5)sdngw 将回应报文镜像至 BigBrother
6)sdngw 将报文送至本地域宿主机
7)ovs 将报文镜像至 BigBrother

三、Bigbrother 服务框架

整个 BB 检测系统由若干个组件配合完成,minitrue 用于将用户传入的参数转化为注包的范围,telescreen 用于构造报文及收发报文。

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

1 服务框架图

API: FE 服务对外提供的 HTTP 接口,用于创建任务和查询任务进度;
Logic:业务处理层,⽤于分析⼊参并将其转换为若干源⽬主机对放入 Disruptor 中;
Disruptor:此组件为开源高性能队列;
Sender:将 Disruptor 中 pop 的数据组装成 GRE packet,并发送给 EntryPoint;
Receiver:接收从 EndPoint 上报的 GRE packet;
Analysis:将接收的报⽂存入内存中,同时对报文进⾏分析。

2 Task 的执行及结果分析

1)task
上文中我们详细介绍了 BB 探测报文的设计和生命周期,但是我们还有一个问题需要解决:提高 BB 的并发能力。按照上文的介绍,每次 BB 只能执行一次探测,顺序执行才能保证检测结果的准确性,所以我们设计利用 TCP 报头中的序列号来提高并发。

以下是一个 TCP 报文的首部结构:

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

其中 32 位的 Seq 序列号就是我们要利用的,在 BB 探测过程中每个 Seq 序列号都唯⼀标识⼀个 pair 对,然后我们将 Seq 序列号分成了两部分:

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

  • Task_id:⽤于标识一个 Task,由于仅有 5 位,所以每次同时进⾏的 Task 不能超过 32 个 ;
  • Pair_id:用于标识在一个 Task 内,待检测的一个 pair 对。

因此,我们可以将 BB 并发的任务数提高到了 32 个,而每个任务支持最大的检测 pair 对数可以达到 2 的 27 次方,相当于每个任务都可以支持一个容量为 10000 台云主机的 VPC 进行 Full Mesh 检测,足以覆盖现有用户的网络规模。

2)task 的执行
当运维同学在 mafia(任务控制台)上点击创建一个 BB task 进行连通性检查时,会经历以下几个过程:

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

  • 请求发送给 minitrue 服务,根据输入的参数来确定探测范围;
  • minitrue 将计算得到的探测范围以源、目节点列表的形式发送给 telescreen 服务;
  • telescreen 构建 Gre 报文,并放入高性能队列中进行发包;同时,telescreen 会监听网卡获取镜像报文回来的报文并存入内存;
  • minitrue 的分析程序定时获取 telescreen 的收包结果并进行分析;
  • 最后运维同学可以在 mafia 上看到最终的探测结果。

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

3)task 的结果分析
task 执行结束后,运维同学可以在 mafia 查看到最后的检测报告,包括发送的总 pair 数、收到的 pair 数、成功以及失败的数量。同时,检测失败的源目详细信息也会展示出来,最终以 bitmap 的方式呈现出来,0 表示没有收到报文,1 表示收到报文。

我们以下图的结果为例,解释其含义。图中是检测 ip pair(10.9.88.160<—>10.8.17.169) 的双向连通性。

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

我们再回顾下第二章中 BigBrother 检测的流程图,首先 BigBrother 会模拟 10.9.88.160 向 10.8.17.169 的宿主机上发送探测报文,报文的内容为 < flag=SYN, nw_src=10.9.88.160, nw_dst=10.8.17.169>。如果 10.8.17.169 —>10.9.88.160 单向连通性正常的话,BigBrother 最终会收到 3 个报文:
(1)< flag=SYN, nw_src=10.9.88.160,

nw_dst=10.8.17.169>

(2)< flag=ACK, nw_src=10.8.17.169,

nw_dst=10.9.88.160>

(3)< flag=ACK, nw_src=10.8.17.169,

nw_dst= 10.9.88.160>

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

上图 bitmap 后三位的结果为 111,表示这 3 个报文都收到了,即 10.8.17.169 —>10.9.88.160 单向的连通性正常。

反之亦然,前三位则表示 10.9.88.160 —> 10.8.17.169 单向的连通性情况,结果为 100,(2)(3) 报文没有收到,即表示 10.9.88.160 —> 10.8.17.169 单向的连通性异常,虚机 10.9.88.160 没有回复报文,可以断定虚机内部异常或虚机内部存在 iptables 规则将探测报文过滤。

3 基于活跃 flow 的连通性检查

上文我们提到,运维同学可以在 mafia 上创建 BB task 来进行连通性的检查,通过传入 mac、子网 id、VPC id 来确定检测的范围,进而进行全量验证。但是大多数场景中,我们不需要进行全互联检查,这样不仅浪费时间而且还会对控制面造成一定的压力。我们仅需要针对指定范围内的活跃 flow 验证连通性即可,所以我们又引入了活跃 flow 检测的服务——river。river 是虚拟网络亿级别活跃流的分析系统,借助这个系统 BB 可以拿到用户的活跃通信源目,类似于缓存里的热点数据,这样可以让 BB 快速精准验证变更。

BigBrother:UCloud全链路大规模网络连通性检测系统详解(下)

与上文全量 BB 探测的区别在于,minitrue 无须自己计算源、目节点列表,只需指定范围后向 river 获取活跃列表,然后通过常规的检测流程将列表传送给 telescreen 进行发包即可。

四、投入使用和未来计划

BigBrother 上线后就参与到了资源整合项目中,用于云主机迁移前后的连通性验证,保证出现异常后可以及时告警回滚。从 8 月初至今历时两个月,共迁移 2000 多台主机,及时发现迁移异常近 10 起。

  • 同时,我们对 BigBrother 后续版本也有着一定的规划,例如:
    除了对连通性的检测外,还需要有平均时延,最大时延对、丢包率的检测;
  • 打算基于 BigBrother 构建针对指定用户的内网全天候监控。

本文转载自公众号 UCloud 技术(ID:ucloud_tech)。

原文链接:

https://mp.weixin.qq.com/s/M46d-Vync6M272dsGEg_tQ

评论

发布