互联网技术详解-运维工程师的福音—网络可视化方案(一)

【发布时间：2021-01-28】

对于网络工程师来说，网络可视化是个时常都要接触的话题；毕竟，能看见的东西才更容易管理。但网络的可视化并非一蹴而就，伴随网络复杂度提升和网络管理要求的升级，可视化才渐渐从无到有、从少到多、从简到精。

网络可视化缘起何处？网络可视化经历了几个阶段？目前流行的网络可视化解决方案有什么？各自特点如何？网络可视化未来发展趋势如何？面对这一系列问题，本次我们将分为用三篇文章的篇幅为您详细解读网络可视化的来龙去脉、过去和未来。

作为本系列的第一篇，我们将着重解读网络可视化的1.0和2.0时代。

网工们的呐喊——网络可视化之缘起

上图是网工们在日常工作中经常遇到的问题，每一种问题的解决都可以用费时费力来概括。因此，网工们的诉求也就跃然纸上：将端到端的流量路径做可视化监控，将出现的问题和告警实时的投入大屏，能基于此快速的分析出具体问题原因并给出解决建议。

网络运营者需要这一整套方案，该方案能在帮助运维的同时，节约了人力物力和最宝贵的时间，让网络真正的智能起来。

说了这么多，如何落地才是网工们真正关心的事情吧。

网络可视化的1.0时代——简单，但远未完美

我们在传统运维中已经采用了CLI，SNMP、和Syslog等技术收集设备参数（如下图），下发具体配置，更有许多网管软件也基于此做了简单的可视化界面：

这里我们可将其视为可视化1.0方案（其中还包括像Netstream和Sflow等流采样技术），这套方案虽然解决了基本的运维需求，但其采样和配置的时效性比较差（分钟级），批量采集还会加大设备的CPU负担，还有就是流量可视化仅能做到单机上报简单的统计，端到端的路径可视没有技术支撑，详细问题的分析和定位需求没有得到真正解决。

故而可视化2.0的方案在大家的呼唤下，来到了我们身边，相关代表技术为INT和GRPC

网络可视化的2.0时代——INT，可视化的全新解

INT（In-band Network Telemetry，带内遥测）是一项从设备上实时采集数据平面信息的网络监控技术，真正解决了流量端到端的可视，达到对网络设备的性能及网络运行情况进行实时监控的和问题快速定位的目的。

具体INT是如何实现流量可视的呢？首先我们来看如下这张经典的三层数据中心网络拓扑图，其中接入设备（Leaf）用6850表示，汇聚设备（Spine）用9820表示，核心设备（Super-Spine）用125X表示，上述设备均能支持INT能力。现在有一条流量送ServerA向ServerD袭来，此时INT是如何应对的呢？

第一步：头节点流量复制

原始报文进入6850时，根据交换机的配置，流量将进行采样并复制出一份报文送给交换机相关模块，被复制报文正常转发，业务不受影响；
交换机把复制报文添加一个INT HDR，回送给Ingress PIPE，让报文重新走一遍转发流程（即报文入端口将保持不变）；
复制报文重新进入转发流程后，交换机相应模块会逻辑匹配到INT HDR，动作为添加INT Metadata字段；
镜像报文根据目的地址从接入设备（6850）出去后，将携带INT HDR和INT Metadata字段；

第二步：中间节点叠加

由于复制报文经过中间节点时已经带上了INT HDR，中间节点通过匹配INT HDR字段，识别其为INT报文，经过中间节点设备时会增加MD/TS字段，
由于复制报文的IP和MAC头将保持不变，且设备转发规则不变，所以复制流量将follow原始流量路径，做到真正的1:1端到端信息采集（时延buffer等细粒度统计）

第三步：尾节点叠加

当复制报文（携带INT HDR和整个路径的METADATA）到达尾节点进入Ingress逻辑后，尾节点将会为其打上最后一跳芯片的Timestamp；
当复制报文到达Egress逻辑时，根据配置，复制流量将会送回交换机相应模块，且其动作为DROP，该报文不会再转发出去；
交换机模块会对复制报文的内容进行重组，把报文中的Timestamp等信息转换为统一的METADATA封装，再根据配置，将重组报文的目的地址写为远端收集器的IP后，将该报文送回交换机的Ingress逻辑转发至收集器

讲了INT整个的流程，相信大家能够记住其中的特性关键字：复制且不影响现网流量；端到端的流量详细信息采集；粒度细化到报文；能将经过各设备的时延和端口丢包情况等现网运维密切关心的参数进行收集上报。

下一步我们来详细了解一下INT具体的报文格式，让大家更深入的了解该项技术能做到什么. INT报文主要有三块：INT HDR、MD和TS，下面我们先来介绍一下INT HDR和MD的格式。

INT HDR格式：

报文头部详细字段解释：

MD格式：

报文头部详细字段解释：

讲了格式，大家可能会考虑下一步：INT报文如何封装的呢？

他包括如下两种形式，在UDP/TCP头部后添加（INT HDR和MD）或在帧尾添加封装（TS），如下图：

第一种：INT HDR和MD（METADATA）封装：

第二种：TS封装（全称Timestamp，包含节点的Ingress时间戳和Egress时间戳）：

讲到这，大家应该对INT有了详细的了解，那么我们再来介绍可视化2.0的第二个关键技术gRPC。

网络可视化的2.0时代——gPRC，高效，强大，但仍有进化空间

文章伊始，我们介绍了传统网络的网络管理技术，也介绍了这些技术的瓶颈，诸如实时性统计效果不佳，传递信息颗粒度不够，频繁采集使CPU占用率增高等。

面对上图这样的情况，我们不禁感慨：要是他们有基于gRPC的telemetry，查看图中红圈圈就能get到真相，客户的投诉不都可以规避了吗？！

Ok，我觉得现在大家初步get到了gRPC的作用，那么我现在来详细介绍一下gRPC是啥吧：

gRPC（Google Remote Procedure Call，Google远程过程调用），基于HTTP 2.0传输层协议承载的高性能开源软件框架；通信双方可以基于该软件框架进行二次开发。

gRPC使设备能通过推模式（Push Mode）周期性的主动向采集器上送设备的被订阅数据源（例如：接口流量统计、CPU或内存数据等信息），相对传统拉模式（Pull Mode）的一问一答式交互，提供了更实时更高速的数据采集功能。

gRPC的协议栈分层和优点如下图所示：

从图中可以看出，gRPC层是承载在HTTP2.0层之上的，该层定义了RPC的协议交互格式。公共RPC方法定义在公共proto文件中，例如grpc_dialout.proto。

讲到gRPC就不得讲他使用的高效Protocol Buffers编码，该编码方式与XML、JSON编码类似，不同之处在于Protocol Buffers是一种二进制编码，性能更高。例如下图：

理解了协议，下面我们来看看gRPC有哪些工作模式：

gRPC分为Dial-in 模式和Dial-out 模式，如下图：

Dial-in 模式：设备作为gRPC 服务器，采集器作为gRPC 客户端。由采集器主动向设备发起gRPC 连接并订阅需要采集的数据信息。Dial-in 模式适用于小规模网络和采集器需要向设备下发配置的场景。

Dial-out 模式：设备作为gRPC 客户端，采集器作为gRPC 服务器。设备主动和采集器建立gRPC 连接，将设备上配置的订阅数据推送给采集器。Dial-out 模式适用于网络设备较多的情况下向采集器提供设备数据信息

注：H3C为Dial-in模式和Dial-out模式分别提供了proto文件。

讲到此，大家应该已经get到了gRPC这种先进的管道技术的优势，但可视化管控的需求是靠设备提供关键采样参数落地的。所以H3C基于常年的网络实践，为客户量身打造了一整套的参数，帮助客户有效的运维，下面给出一些关键的采样信息模板以供参考。

其中包括运维关心的统计和告警信息的周期性采样和事件触发上报，各主要表项信息的汇总诸如路由，ACL等，各接口的丢包信息和buffer大小等，甚至包括RDMA的相关参数信息，如图中PFC统计等。

两大关键技术点INT和gRPC已经介绍完毕，估计大家此时可能会好奇一件事：可视化2.0到底是怎么实现的呢？他的全景图是怎样的呢？

在此新华三提供了一整套可视化2.0的解决方案，如下图：

基于新一代的Telemetry技术，通过订阅/通知的机制（gRPC）将设备的关键信息高效传递给采集器，采集器进行汇总后发送给SNA Center进行再分析和呈现，实现真正的网络内在可视，让客户用着安心，让现网问题无所遁形。再加上整网INT功能，使业务流量也能做到端到端的路径队列可视。这里尤其要说的是像现阶段的热点应用如：RDMA无损网络RoCE，新华三也在设备侧落地了相关参数（如下图），保障业务端到端的业务可管可视可控。