是一个介绍如何利用思科先进技术解决客户难题的栏目。每期聚焦一个技术热点或应用场景，邀请资深思科技术专家深入浅出地介绍，为读者提供实用性强的建议。

　　在上一期 《 思享家 | 网工历险记 》中我们为拯救网工们的头发，祭出了个大杀器 —— 基于意图的主动运维系统，并小试牛刀，轻松解决了网工们头疼的 “ 幽灵丢包 ” 问题。具体来讲，这个架构长得这个样子：

　　左半部分下方是由自动化引擎构成的自动化层，它依据一定策略从复杂的多云基础架构中收集足够的现场数据供给它的上一层 —— 由洞见引擎构成的洞见层，后者对数据进行处理、分析和判断，辅助人类做出正确的决策（ 我们称为 “ 意图 ” ）。这些意图可能是对数据收集策略的调整，也可能是直接实现某个主动运维的目标，总之在形成后都会被发送给下面的自动化层，它们被转换为具体的执行策略，由自动化引擎驱动执行，并同时继续收集数据反馈给洞见层完成状态监控，从而最终形成一个不断自我优化的闭环。“ 幽灵丢包 ” 问题就是通过自动化层的 AppDynamics Agent 探针收集了大量数据，在洞见层的洞见引擎 AppDynamics 对这些数据分析出应用结构和结构内每一层应用体验的定量化指标，最终找到导致端到端体验恶化的精确位置（ 即 “ 诊断意图 ” ），再交给自动化层的自动化引擎 ACI APIC 控制器进行底层精细化监测和诊断，从而最终抓获幽灵丢包元凶。

　　其实我们看到这个例子中 ACI APIC 的故障诊断工具箱内还是传统的端口计数、差错统计、Traceroute 等，但有了洞见层明确的诊断意图加持，立刻功力倍增，瞬间搞定了传统要几天才能解决的难题。如果能把自动化层收集数据的手段进一步升级，比如引入大数据收集手段；把洞见层处理和分析数据的手段升级为大数据分布式处理、机器学习和人工智能，那会是一幅什么图景呢？不用凭空想象，因为这就是 Cisco 智能主动运维系统 Nexus Insights 。

　　我们就从 Nexus Insights 的自动化层如何实现大数据收集策略开始。

　　自动化层为什么要加持大数据呢？我们常常把网络流量比喻为道路交通（ 在英语里甚至是同一个词 Traffic ），那发现网络异常就相当于交警检查交通违章。传统收集数据的手段往往是一个收集器轮流采集网络节点数据，或者发出探测包沿线探测（ 比如 ping、traceroute 等），这就好比交警轮流到路口检查闯红灯和超速，或者骑着摩托在路上巡逻，撞见了就抓、撞不见也没什么办法。在网络世界中也一样，在收集器轮询的空隙、探测包之间的间隔以及探测包没能覆盖的路径上，到处都有可能存在导致用户体验恶化的瞬断、丢包，突发拥塞、延迟和抖动，也就像没能亲临现场的警察漏掉交通违章一样被收集器漏掉了。这种由收集器方发起的数据收集模式被称为 “ 拉取 ”（ Pull ）。

　

　　更高效的数据收集方式一定是 “ 推送 ”（ Push ）而非 “ 拉取 ”（ Pull ）。想象一下不靠交警亲临，而是所有车辆和路口都设置摄像头，并实时主动对外报告交通状态会是一种什么场面？必然是任何违章都逃不过法眼。所以必须要想办法让每一个用户数据包（ 车辆摄像头 ）、每一个网络交换机（ 路口摄像头 ）都向外报告，这种利用带内数据包和带内网络设备主动推送（ Push ）的数据收集手段，又称为带内网络遥测（ In-band Network Telemetry，INT ）。当然代价就是数据量相当大（ 所谓 “ 大数据 ” ），但我们因此获得的是全时全场景信息，能为洞见层提供全真的场景重现。

　　云基础架构单端口已经演进到了 400G ，要想不影响业务数据流而又逐包的实现全场景重现，就必须依靠设备的硬件转发芯片。也就是说，无论厂商宣传的软件网管平台多么酷炫，它的交换机的硬件决定了这个舞台的天花板。因此着名的交换机、路由器和 NIC 硬件开源标准组织 P4（ p4.org ）对数据平面 INT 做了功能定义和分类：

　

　　没耐心看完本技术宅絮叨的小伙伴记住上面这三幅图就可以点赞回家了 （ 手动狗头 ），但要想洞察各厂数据中心交换机内部玄机，还是需要耐心看完本文。

　　在用户的实际业务数据包内嵌入监控信息，即所谓 Embed（ 嵌入 ）方式，就好比在路上跑的所有车都加上摄像头，是最直接的收集路径状态的方法。但路径信息要想都嵌入进去，势必会因为附加的延迟、MTU 甚至安全问题而不能被用户接受，于是分化出两种解决方案：直接对用户数据包动手，但不碰负载，而是只动包头的封装，当然包头字段也只够嵌入监控信令或指令，这称为 eMbed instruct（X）ions（ MX ）；另一个方案是完全不触碰用户数据包，而是仅将用户数据包头单独复制而形成一个新数据包，由于这个包的包头和用户数据包头一样，因此可以和用户数据流并驾齐驱，同时它每经过一跳，就把相应的信息以一段段 Metadata 的方式挂在包头后面，就像火车车皮，越走挂的越多，最后到终点把所有 Metadata 卸下来封装到隧道内发给收集器，这称为 eMbed Data（MD）。MD 不是在用户车内装摄像头，而更像是让狗仔队跟踪，一路走一路拍。

　　小伙伴们肯定关心哪一个最好用，可惜工程上没有完美的技术，它们各有优缺点。MX 的优点是非常轻量化，无须附加流量就能够无抽样的监测每一个用户数据包，但包头字段能携带的信息很有限，只能附加一些信令或指令，因而需要整个网络系统与之配合才能实现相应功能，灵活性和扩展性受限。

　　MD 能携带大量信息，所以功能扩展强大，但工程上也有很多问题，比如要用多高的频率复制用户数据包头呢？1:1 复制相当于把网上负载增加一倍，太稀疏的抽样又导致不能反映用户数据流瞬间的真实情况，相当于狗仔队跟丢了。另外携带信息的效率也是问题，网络异常发生的位置和时间非常随机，如果很长时间没有变化，而每一个包都携带着大量完全没什么变化的状态就显得非常浪费，而一些异常突然发生却不一定刚好有数据包经过，会耽误信息的收集，所以要想全面收集信息，硬件资源投入就非常巨大，这同时也带来的第三个问题，即硬件实现难度。当前主流商业芯片厂商只在非常高端的芯片上做了部分实现，但即便是这样，为了平衡成本和复杂度，在需要最复杂操作的入口和出口交换机还是无法全硬件化完成，全时全景信息捕捉很容易造成资源过载，很多厂商不建议全时开启，致使 MD 功能名存实亡。

　　Cisco 的工程实现要比 P4 的标准分类早很多，比如早在第一代 ACI 开始就已经广泛部署的 Atomic Counter 其实就是一种 MX 的实现。利用 VXLAN 发明者和自研 ASIC 转发芯片的优势，Cisco 在 VXLAN 封装的头部设置了特殊的比特位用于传递 MX 的信令，又借助 Nexus 系列交换机在整体硬件设计上的优势实现了硬件化的 PTP（ 高精度时间同步协议 ）和皮秒级时间戳封装能力，使得用户进行正常业务流传输的同时，就在极为精确的测量所有端到端路径上每一个包的延迟、抖动和丢包，并把信息按每 30 秒为届进行汇集，报告给自动化引擎（ SDN控制器APIC ），整个过程在 ASIC 上实现，用户毫无感知，像是运行在 ACI 上的用户业务流与生自带的特性一样。某大型知名互联网平台就是利用这个特性，密切监控其最关键的数十个端到端数据流健康状态（ 主要是Proxy/LoadBalancer ），只要延迟、抖动和丢包数超过阈值，就会在 ACI 控制器对应的应用健康分值上减去相应分数（ 对，因为 ACI 控制器有这样的应用健康分值核算功能，其实它也是一个很好的洞见引擎 ）。

　　在 MD 方面，Cisco 两年前就在其 Nexus 3000 系列 400G 平台上以纯硬件方式实现了完整的 MD 功能，MD 功能不再名存实亡。而一些用户广泛使用的商业芯片，预计要到 2022 年左右开始才能提供类似全硬件实现的功能。但无论采用 MD 的哪种选择，端到端交换机的产品形态都会是单芯片 12.8T 以上、端口带宽 400G 的平台，这在近几年内对绝大部分企业的柜顶接入交换机都不太可能成为现实。

　　那么问题来了，如果用户需求超出了 MX/Atomic Counter 规定的功能（ 比如需要知道具体的丢包、延迟的位置和原因 ），而普通企业又无法短期内端到端部署能提供更详细信息的 MD 方式，有没有一种功能强大但同时又足够轻量化、性价比高到能端到端部署的带内遥测方案呢？

　　答案就在下期 —— INT XD。