“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

UCloud 全链路大规模网络连通性检测系统详解

  • 2019-10-30
  • 本文字数:5874 字

    阅读完需:约 19 分钟

UCloud全链路大规模网络连通性检测系统详解

虚拟网络排查问题困难,传统的 traceroute 等工具很难起到太大作用,大部分情况下都需要到宿主机、混合云网关上抓包来 troubleshooting,耗时又费力。有些场景中包的传送路径比较长(如跨域、混合云等),可能丢包的地方比较多,更增加了故障排查的难度。


为此,我们设计了一款支持全链路大规模的网络连通性内部检测系统 BigBrother。基于 TCP 报文的染色可将检测报文和用户流量区分开,能支持物理云和跨地域的复杂场景,还打造了完整的检测框架,帮助运维同事直接定位故障点,或一键判断虚拟网络是否存在问题。


BigBrother 上线后即用于云主机迁移前后的连通性验证,保证出现异常后可以及时告警回滚。从 8 月初至今历时两个月,共迁移 2000 多台主机,及时发现迁移异常近 10 起。


一、第一代网络连通性工具的不足

在设计 BigBrother 这前,我们也有第一代的网络连通性检查工具,原理就是通过 SSH 跳转到目标宿主机上,利用 ovs 的 packet out 命令将构造的报文发出去,最后在对端的宿主机上 tcpdump 该报文,从而验证两端的连通性。但是从它的原理就不难看出,这种检测方式有着很大的缺点:


  • 检测效率低下,无论是 ssh、packet out,还是 tcpdump 都无法支持大规模的快速检查;

  • 适应的场景有限,对于部分 dpdk、p4 网关类产品,无法通过 tcpdump 进行抓包判断。


因此做一款支持全链路大规模的连通性检测系统是非常有必要的,我们的目标就是让运维、NOC 的同学能够迅速发现并解决网络不通的问题,同时为我们的虚拟网络服务变更保驾护航。

二、BigBrother 的实现原理

BigBrother(下文简称 BB)一词源自乔治奥威尔的小说《1984》,将此检测系统命名为 BigBrother 寓意就是可以将全网资源连通情况都实时监控起来。整个 BB 检测系统由若干个组件配合完成,mafia 提供 console 进行创建及展示 task 的结果,minitrue 用于将用户传入的参数转化为注包的范围,telescreen 用于构造报文及收发报文。

1 Entrypoint 和 Endpoint

在具体介绍 BB 的原理前,我们先来看两个概念。在我们的虚拟网络中,每个实例(uhost、umem、udb 等)都是通过接入点来接入虚拟网络,接入点由两部分组成:


  • Entrypoint: inbound/outbound 报文都是经由 Entrypoint 进行接受和发送的。

  • Endpoint:连接实例的端点,Endpoint 为最接近实例的网元。


例如在公有云场景中,entrypoint 和 endpoint 都是 openvswitch,而在物理云场景中,entrypoint 是我们的物理云转发网关(vpcgw、hybridgw),endpoint 则是物理云主机的上联 ToR。


场景EntrypointEndpoint
公有云ovsovs
物理云vpcgw、hybridgwToR
托管云hcgw、cloudgwPE
跨域网关sdngwovs
公共服务ovsovs
CNATovsovs
托管云(UXR)UXRPE
跨域网关(UXR)UXRovs
CNAT(UXR)UXRovs


以上就是各种场景中的接入点说明,之所以要明确这两个概念,是因为在 BB 系统中,我们将 Entrypoint 作为注包点,向其发送 GRE 探测报文,同时将 Endpoint 作为采样点,Endpoint 会识别并镜像特殊的探测报文至 BB。

2 检测流程

检测方案如图所示,可分为两部分组成,在图中的流向分为橙色和紫色。



以橙色流向部分为例(SRC->DST):


1)BigBrother 模拟 DST 向 Endpoint 发送探测报文;


2)SRC 端 Entrypoint 收到该探测报文后转发给 Endpoint;


3)Endpoint 将该报文镜像至 BigBrother;


4)Endpoint 将报文正常转发至实例;


5)实例回复报文给 Endpoint;


6)Endpoint 收到该回复报文后进行 GRE 封装,然后镜像至 BigBrother;


7)Endpoint 将报文正常转发至 Entrypoint;


8)SRC Entrypoint 将回复报文发送至 DST Entrypoint;


9)DST Entrypoint 收到回复报文后发送给 Endpoint;


10)DST Endpoint 将回复报文镜像至 Bigbrother。


至此,单边的检测结束。在检测过程中,BigBrother 发送了 1 个探测报文,共收到了 3 个采样报文,通过分析这 3 个采样点可以确认 SRC->DST 方向是否通信正常。


反之亦然,紫色部分原理相同。全部检测结束后,BigBrother 共可以收到 6 个探测报文,如果 6 个报文均收到则表示连通性正常。

3 探测报文设计

上文中介绍了 BB 的检测流程,下面我们再来看下探测报文及转发面的设计实现。公有云和混合云的设计存在很多不同。公有云转发面需要在全局 hook 点(table_1),分别 hook 探测报文的 request 和 response,然后进行染色、镜像至 BB 等步骤。而混合云转发面则需要 ToR、PE 交换机开启 ERSPAN 功能,将染色的报文镜像至 BB 即可。


整体数据包交互如下图所示:



而一个合格的探测报文首先应该具备以下特征:


  • 染色信息与主机、OS 无关;

  • ovs2.3、ovs2.6 版本(现网主要版本)可以识别并处理此种染色信息。


因此我们详细比较了如下两种候选方案。


1)icmp + tos 方案


第一种方案以 icmp 报文为载体,使用 tos 对 icmp_request 进行染色,采集时将此 tos 的 icmp 报文镜像至 BB 即可。


cookie=0x20008,table=1,priority=40000,metadata=0x1,icmp,icmp_type=8,icmp_code=0,nw_tos=0x40 actions=Send_BB(),Learn(),Back_0()
复制代码


对于 hook icmp_request 的 flow 可以简化为如下逻辑:action 部分主要由三部分组成:


  • Send_BB() 将报文镜像给 BB;

  • Learn() 通过 icmp_request 报文学习到一条用于匹配 icmp_reply 报文的 flow,该条 flow 的主要动作包括:染色、镜像至 BB;


# 1. 􏲌􏳳REG3 􏱛64200# (global hook) reg3 load:64200->NXM_NX_REG3[], # 2. learn action learn(table=31,idle_timeout=2,hard_timeout=4,priority=30000,dl_type=0x0800,ip_proto=1,icmp_type=0,icmp_code=0,NXM_OF_IP_SRC[]=NXM_OF_IP_DST[],NXM_OF_IP_DST[ ]=NXM_OF_IP_SRC[],Stain(),Send_BB()),# 3. REG3 0load:0->NXM_NX_REG3[] 
复制代码


  • Back_0() 将该报文送回 table_0,进行常规的转发操作。


对于 hook icmp_reply 的 flow 可以简化为如下逻辑:


cookie=0x20008,table=1,priority=40000,metadata=0x1,icmp,icmp_type=0,icmp_code=0,nw_tos=0x40
复制代码


action 部分主要由四部分组成:


  • Save(in_port, tun_src) 将报文中的 in_port 和 tun_src 保存下来;

  • Resubmit(table=31) 跳转至 table31,匹配 icmp_request learn 生成的 flow;

  • Restore(in_port, tun_src) 恢复 in_port 和 tun_src;

  • Back_0() 将该报文送回 table_0,进行常规的转发操作。


以上讨论的是公有云侧 ovs 的染色及镜像方法,而混合云侧就需要交换机 ERSPAN 来进行支持,为了使 ERSPAN 规则可以镜像 tos 染色报文,需要 GRE 外层 Ip Header 中的 tos 继承 overlay Ip Header 中标记的 tos,所以需要全网对 GRE 隧道设置继承内层 tos 的隧道属性,执行命令如下:


ovs-vsctl set in <gre_iface_name> options:tos=inherit
复制代码


此种方案虽然可以实现染色及镜像的功能,但是 hook 点预埋的 flow 过于复杂,不容易维护,最关键的一点在于,混合云网络中,该方案无法支持 learn flow,所以无法对反向的流量进行染色。


2)tcp 方案


第二种方案以 tcp 报文为载体,使用特定的端口作为染色条件,采集时将此源目端口的 tcp 报文镜像至 BB 即可。


cookie=0x20008,table=1,priority=40000,tcp,metadata=0x1,tp_src=[port],tp_dst=[port] actions=Send_BB(),Back_0()
复制代码


对于 hook tcp_request 的 flow 可以简化为如下逻辑:


action 部分主要由两部分组成:


  • Send_BB() 将报文镜像给 BB;

  • Back_0() 将该报文送回 table_0,进行常规的转发操作。


以上两种方案进行对比不难看出,第一种方案依赖较多并且适用场景受限,所以 BB 采用的是第二种方案。但是 tcp 方案也有一定的缺陷,如何选择染色的 port 并且要与用户的流量区分开来,这是一个难点。经过我们几次踩坑后分析,最后决定使用 tcp 源目 port=11 来进行染色(目前已告知用户会使用 TCP 端口 11 进行扫描,详见文档),报文如下图所示。


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 构建针对指定用户的内网全天候监控。


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


原文链接


https://mp.weixin.qq.com/s?__biz=MzUwOTA1NDg4NQ==&mid=2247486229&idx=1&sn=87d8e042775d607d869e58c0e2f8f39e&chksm=f91951dfce6ed8c95684b519306444f62699f2b0005f6c4f2152e68fbe48fae323d2e5c269eb&scene=27#wechat_redirect


2019-10-30 08:001424

评论

发布
暂无评论
发现更多内容

基于低代码/无代码工具构建应用程序

高端章鱼哥

低代码 无代码 应用程序

MySQL索引,为什么索引会失效呢?

程序员万金游

MySQL Java'

基于Vue前端框架构建BI应用程序

互联网工科生

Vue 低代码 BI 分析工具

一文学会List函数排序操作,20秒即可完成!

SoFlu软件机器人

“云渲染”,电影特效背后的技术

Finovy Cloud

云计算 渲染 云渲染

SAST工具编译命令捕获及参数处理实现

maijun

C++的基类和派生类构造函数

攻城狮Wayne

华为云828营销季火热进行中,3大热门产品助力中小企业云上成长

平平无奇爱好科技

IAM携手华为,创新科技解锁空净新标准

新消费日报

dapp去中心化系统开发、数字钱包多签名钱包软件开发

西安链酷科技

【华为云828企业节上福利】软件开发工具升级版免费套餐重磅上线

平平无奇爱好科技

北京 深圳 上海 武汉 西安 成都本地 DAPP系统开发公司详解

西安链酷科技

博睿数据当选粤港澳大湾区金融创新研究院理事会单位,助力金融科技创新发展

博睿数据

博睿数据

nft卡牌链游开发

西安链酷科技

哈希游戏开发、哈希尾数、单双竞猜游戏开发

西安链酷科技

“创新机制+明星项目”组合拳| Leap Launchpad引领Web3金融风潮

EOSdreamer111

“创新机制+明星项目”组合拳| Leap Launchpad引领Web3金融服务新风潮

威廉META

“创新机制+明星项目”组合拳| Leap Launchpad引领Web3金融服务新风潮2

鳄鱼视界

VS Code 的 launch.json 进行高效代码调试:配置和原理解析

麦田的守望者

3DCAT携手华为,打造XR虚拟仿真实训实时云渲染解决方案

3DCAT实时渲染

虚拟仿真 实时渲染 CLOUDXR

物联网时序数据库 IoTDB 荣获清华校友三创大赛总决赛最高奖

Apache IoTDB

易点天下受邀参与华为云印度尼西亚CXO-Camp 共探产业数字化转型新路径

新消费日报

“创新机制+明星项目”组合拳| Leap Launchpad引领Web3金融服务新风潮

股市老人

LeetCode题解:7. 整数反转,数组反转,JavaScript,详细注释

Lee Chen

JavaScript LeetCode

UCloud全链路大规模网络连通性检测系统详解_服务革新_徐欢_InfoQ精选文章