柳江网站建设,小程序平台登陆,免费申请的网站,html做调查问卷网站虚拟网络排查问题困难#xff0c;传统的traceroute等工具很难起到太大作用#xff0c;大部分情况下都需要到宿主机、混合云网关上抓包来troubleshooting#xff0c;耗时又费力。有些场景中包的传送路径比较长(如跨域、混合云等)#xff0c;可能丢包的地方比较多#xff0c… 虚拟网络排查问题困难传统的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)可以将全网资源连通情况都实时监控起来整个BB检测系统由若干个组件配合完成mafia提供console进行创建及展示task的结果minitrue用于将用户传入的参数转化为注包的范围telescreen用于构造报文及收发报文。1Entrypoint和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公共服务ovsovsCNATovsovs托管云(UXR)UXRPE跨域网关(UXR)UXRovsCNAT(UXR)UXRovs以上就是各种场景中的接入点说明之所以要明确这两个概念是因为在BB系统中我们将Entrypoint作为注包点向其发送GRE探测报文同时将Endpoint作为采样点Endpoint会识别并镜像特殊的探测报文至BB。2检测流程检测方案如图所示可分为两部分组成在图中的流向分为橙色和紫色。以橙色流向部分为例(SRC-DST)1)BigBrother模拟DST向Endpoint发送探测报文2)SRC端Entrypoint收到该探测报文后转发给Endpoint3)Endpoint将该报文镜像至BigBrother4)Endpoint将报文正常转发至实例5)实例回复报文给Endpoint6)Endpoint收到该回复报文后进行GRE封装然后镜像至BigBrother7)Endpoint将报文正常转发至Entrypoint8)SRC Entrypoint将回复报文发送至DST Entrypoint9)DST Entrypoint收到回复报文后发送给Endpoint10)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即可。cookie0x20008,table1,priority40000,metadata0x1,icmp,icmp_type8,icmp_code0,nw_tos0x40 actionsSend_BB(),Learn(),Back_0()对于hook icmp_request的flow可以简化为如下逻辑action部分主要由三部分组成Send_BB() 将报文镜像给BBLearn() 通过icmp_request报文学习到一条用于匹配icmp_reply报文的flow该条flow的主要动作包括染色、镜像至BB# 1. ??REG3 ?64200# (global hook) reg3 load:64200-NXM_NX_REG3[], # 2. learn action learn(table31,idle_timeout2,hard_timeout4,priority30000,dl_type0x0800,ip_proto1,icmp_type0,icmp_code0,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可以简化为如下逻辑cookie0x20008,table1,priority40000,metadata0x1,icmp,icmp_type0,icmp_code0,nw_tos0x40action部分主要由四部分组成•Save(in_port, tun_src) 将报文中的in_port和tun_src保存下来•Resubmit(table31) 跳转至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 options:tosinherit此种方案虽然可以实现染色及镜像的功能但是hook点预埋的flow过于复杂不容易维护最关键的一点在于混合云网络中该方案无法支持 learn flow所以无法对反向的流量进行染色。2)tcp方案第二种方案以tcp报文为载体使用特定的端口作为染色条件采集时将此源目端口的tcp报文镜像至BB即可。cookie0x20008,table1,priority40000,tcp,metadata0x1,tp_src[port],tp_dst[port] actionsSend_BB(),Back_0()对于hook tcp_request的flow可以简化为如下逻辑action部分主要由两部分组成•Send_BB() 将报文镜像给BB•Back_0() 将该报文送回table_0进行常规的转发操作。以上两种方案进行对比不难看出第一种方案依赖较多并且适用场景受限所以BB采用的是第二种方案。但是tcp方案也有一定的缺陷如何选择染色的port并且要与用户的流量区分开来这是一个难点。经过我们几次踩坑后分析最后决定使用tcp源目port11来进行染色(目前已告知用户会使用TCP 端口11进行扫描详见文档)报文如下图所示。4各场景下探测报文的生命周期BB被设计为支持多种网络场景能应对物理云和跨域互通的网络复杂性。这章节我们以探测物理云和跨域为例详细分析下BB探测报文的生命周期。物理云公有云互通物理云场景下探测报文生命周期如下公有云— 物理云1)BigBrother向公有云宿主机发送探测报文2)ovs收到报文后镜像至BigBrother3)ovs将报文送至实例4)实例回应报文5)ovs将回应报文镜像至BigBrother6)物理云核心交换机收到报文并发送给汇聚交换机7)8)9)10)物理云汇聚交换机发送报文给vpcgwvpcgw处理报文后回送至汇聚交换机11)在物理云汇聚交换机配置ERSPAN将报文镜像至BigBrother。物理云— 公有云1)BigBrother向vpcgw发送探测报文2)3)vpcgw处理报文后回送至汇聚交换机4)在物理云汇聚交换机配置ERSPAN将报文镜像至BigBrother5)汇聚交换机将报文送至phost的上联Tor6)Tor将报文送至phost7)phost回应报文8)在phost的上联Tor配置ERSPAN将报文镜像至BigBrother9)报文送至公有云宿主机ovs10)ovs收到报文后镜像至BigBrother跨域网关公有云跨域互通场景下探测报文生命周期如下本地域— 地域B1)BigBrother 向本域主机发送探测报文2)ovs收到报文后镜像至BigBrother3)ovs将报文送至实例4)实例回应报文5)ovs将回应报文镜像至BigBrother6)ovs将报文送至sdngw7)sdngw将报文镜像至BigBrother地域B— 本地域1)BigBrother 向本域sdngw发送探测报文2)sdngw收到报文后镜像至BigBrother3)sdngw将报文送至对端sdngw进行转发4)本域sdngw收到对端回应报文5)sdngw将回应报文镜像至BigBrother6)sdngw将报文送至本地域宿主机7)ovs将报文镜像至BigBrother三、Bigbrother服务框架整个BB检测系统由若干个组件配合完成minitrue用于将用户传入的参数转化为注包的范围telescreen用于构造报文及收发报文。1服务框架图APIFE服务对外提供的HTTP接口用于创建任务和查询任务进度Logic业务处理层⽤于分析⼊参并将其转换为若干源⽬主机对放入Disruptor中Disruptor此组件为开源高性能队列Sender将Disruptor中pop的数据组装成GRE packet并发送给EntryPointReceiver接收从EndPoint上报的GRE packetAnalysis将接收的报⽂存入内存中同时对报文进⾏分析。2Task的执行及结果分析 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.16010.8.17.169)的双向连通性。我们再回顾下第二章中BigBrother检测的流程图首先BigBrother会模拟10.9.88.160向10.8.17.169的宿主机上发送探测报文报文的内容为。如果10.8.17.169 —10.9.88.160 单向连通性正常的话BigBrother最终会收到3个报文(1)nw_dst10.8.17.169(2)nw_dst10.9.88.160(3) nw_dst10.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 技术。更多云实践和技术干货欢迎关注“UCloud技术”
