BigBrother：UCloud 全链路大规模网络连通性检测系统详解（下）

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

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

• 物理云

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

公有云—> 物理云

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

2）ovs 收到报文后镜像至 BigBrother

3）ovs 将报文送至实例

4）实例回应报文

5）ovs 将回应报文镜像至 BigBrother

6）物理云核心交换机收到报文，并发送给汇聚交换机

7）8）9）10）物理云汇聚交换机发送报文给 vpcgw，vpcgw 处理报文后回送至汇聚交换机

11）在物理云汇聚交换机配置 ERSPAN，将报文镜像至 BigBrother。

物理云—> 公有云

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

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

2）ovs 收到报文后镜像至 BigBrother

3）ovs 将报文送至实例

4）实例回应报文

5）ovs 将回应报文镜像至 BigBrother

6）ovs 将报文送至 sdngw

7）sdngw 将报文镜像至 BigBrother

地域 B—> 本地域

1）BigBrother 向本域 sdngw 发送探测报文

2）sdngw 收到报文后镜像至 BigBrother

3）sdngw 将报文送至对端 sdngw 进行转发

4）本域 sdngw 收到对端回应报文

5）sdngw 将回应报文镜像至 BigBrother

6）sdngw 将报文送至本地域宿主机

7）ovs 将报文镜像至 BigBrother

三、Bigbrother 服务框架

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

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 报文的首部结构：

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

• Task_id：⽤于标识一个 Task，由于仅有 5 位，所以每次同时进⾏的 Task 不能超过 32 个 ；

• Pair_id：用于标识在一个 Task 内，待检测的一个 pair 对。

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

2）task 的执行

当运维同学在 mafia（任务控制台）上点击创建一个 BB task 进行连通性检查时，会经历以下几个过程：

• 请求发送给 minitrue 服务，根据输入的参数来确定探测范围；

• minitrue 将计算得到的探测范围以源、目节点列表的形式发送给 telescreen 服务；

• telescreen 构建 Gre 报文，并放入高性能队列中进行发包；同时，telescreen 会监听网卡获取镜像报文回来的报文并存入内存；

• minitrue 的分析程序定时获取 telescreen 的收包结果并进行分析；

• 最后运维同学可以在 mafia 上看到最终的探测结果。

3）task 的结果分析

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

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

我们再回顾下第二章中 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>

上图 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 快速精准验证变更。

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

四、投入使用和未来计划

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

• 同时，我们对 BigBrother 后续版本也有着一定的规划，例如：

• 除了对连通性的检测外，还需要有平均时延，最大时延对、丢包率的检测；

• 打算基于 BigBrother 构建针对指定用户的内网全天候监控。

本文转载自公众号 UCloud 技术（ID：ucloud_tech）。

原文链接：

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