Everflow 阅读报告
文献名：Packet-Level Telemetry in Large Datacenter Networks
（Zhu Y, Kang N, Cao J, et al. Packet-level telemetry in large datacenter networks[C]//ACM SIGCOMM Computer Communication Review. ACM, 2015, 45(4): 479-491.）
作者：Yibo Zhu、Nanxi Kang、Jiaxin Cao、Albert Greenberg、Guohan Lu、Ratul Mahajan、Dave Maltz、Lihua Yuan、Ming Zhang、Ben Y. Zhao、Haitao Zheng
关键字：Datacenter network; failure detection; probe
引言：
在复杂网络中去排查故障是一件很困难的事，要做到及时的解决故障，需要做到：
- 在大规模的网络流量中识别出受影响的报文。
- 穿过多个网络组件去追踪它们。
- 分析流量轨迹中的故障模式。
- 测试并确定潜在的故障原因。
Everflow 就是一个大型网络中基于报文级别的遥测系统，使用商用交换机所具有的“match and mirror”功能来追踪特定的报文。它将抓取到的报文送到分析服务器，并且发出“guided probes”来测试并确定潜在的故障。 它的特点在于它是报文级别的，粒度细，并且随着数据中心实时运行，对当前的一小部分报文进行追踪，可以实时检测到故障。另外当操作员发现某些故障时，也可以对Everflow进行配置，注入探针报文去定位这些故障。
对于Silent packet drop、Silent blackhole、Inflated end-to-end latency、Loops from buggy middlebox routing、Load imbalance和Protocol bugs等一些问题，传统的工具是很难检测到故障或者很难定位到故障的，但是这些问题Everflow都可以发现，并且能够将这些问题定位到某个路由器或者某条链路。
另外，它所需占用的资源在数据中心尺度来看是很小的，基本可以不予考虑。
Everflow架构：
Everflow主要由四个部分组成：controller、analyzer、storage和reshuffler。在这之上，多个Everflow application与Controller进行交互，利用Everflow提供的信息来诊断网络故障。
Reshuffler：
Reshuffler负责将追踪的报文进行镜像，然后送到Analyzer。其中主要的问题是数据中心的流量巨大，不可能追踪所有的报文，只能有选择的进行追踪。需要使用下面一些措施。
在交换机上进行匹配和镜像。商用的数据中心交换机可以预定义匹配规则， 并对匹配报文执行确定的操作，且不改变原报文的转发行为。 Everflow利用这一点来减少追踪的负载， 用三种匹配规则来处理DCN（DataCenter Network）的通常故障。 第一，由于数据中心流的大小分布十分不均匀， 所以以TCP报文的SYN、FIN和RST部分来进行匹配， 随机在n个踪迹中选择一个踪迹进行追踪。 第二，某一些问题可能需要追踪特定应用的特定端口的报文， 或者两个服务器之间的报文， 所以这里在这样的报文中加入一个特殊的“debug bit”， 交换机将对这样的报文进行追踪。第三，对一些协议报文（例如BGP、PFC和RDMA）， 它们在网络中是属于很小的一部分，但是又十分重要， 所以Everflow会追踪所有这些的协议报文。
Switch-based reshuffler。我们需要一个低花费的策略来reshuffle这些追踪流量。为了实现这个策略，首先在HMux（hardware Mux）中定义一个VIP（virtual IP），配置所有交换机将踪迹报文转发到VIP，当一个踪迹报文到达HMux，HMux依据报文的五元组将报文重定向到一个DIP（direct IP，它就对应一个分析服务器）。这样就保证了同一五元组的报文只会被重定向到相同的DIP。
Analyzers：
分析器。由分布式服务器组组成，每台服务器处理一部分“tracing traffic”。 每一个分析器保持着两个状态：追踪报文和计数器。
追踪报文。分析器保持着一个报文踪迹表，表中保存了同一个报文（由五元组和IPID定义）的镜像链。它保存原报文的一份全拷贝，一系列的逐跳信息，逐跳信息包括报文被镜像的交换机IP地址、时间戳、TTL、源MAC地址和DSCP/ECN。当在一秒以内不再有新的报文，就认为一条踪迹结束。
在一条结束的报文踪迹中，分析器会检查它是否有循环或丢包问题。当相同的设备在一条踪迹中出现多次时，就认为出现了循环。当一条踪迹的最后一跳与所期望的最后一跳不同时，就认为发生了丢包。
由于需要追踪的报文的数量十分巨大，为了减小存储压力，每一个分析器只会将 异常行为、设置了调试位（例guided probes）或者协议相关报文（例PFC和BGP）的踪迹信息写入存储单元。对剩下的踪迹，分析器会将它们以类型的区别聚合到计数列表，并每隔10秒写入存储单元。最后controller还会将每个分析器的计数合并到一起。
链路负载计数器。对每条链路，分析器会计算出链路的总负载（报文数、比特数和flow数）。另外它还可以对指定前缀的流量或指定的内部流量来进行更细粒度的统计，这个操作可以通过controller来动态增减。
延迟计数器。分析器通过“guided probes”来计算每一条链路的延迟。
镜像报文丢包计数。镜像报文也有可能会发生丢包，如下图5所示，当踪迹包含S2却不包含S1时，明显表示从S1镜像出来的报文发生了丢失。在实际部署中镜像报文丢失率很低，通过将镜像报文避开拥塞链路就能很好的解决这个问题。
Storage：
这里使用了SCOPE数据库，它是一个可扩展的分布式数据处理系统。数据用表的形式进行存储。这里将报文踪迹按行进行存储，每一行存储一条报文踪迹。
Controller APIs：
Everflow applications通过一些API来与控制器进行交互，通过这些API，应用可以查询报文踪迹、添加细粒度的负载计数器、触发guided probes以及选定踪迹添加调试bit。
它有GetTrace()、GetCounter()、AddCounter()、RemoveCounter()、Probe()以及EnableDbg()、DisableDbg() 这样一些操作函数。
guided probing。由于故障的发生可能有多种原因，被动的追踪报文可能不足以确定这些的原因，这时就需要重新注入报文来判断故障。这种能够在任意交换机上注入任意报文的能力，就叫做guided probing。
如上图（a），虽然追踪到了这个丢包，但是我们不能确定这个丢包是随机的还是持续的，通过guided probing，我们将报文p的复制注入到S2（如图b），确定丢包是随机的还是持续的。更进一步，可以设置探针报文为不同的五元组，测试丢包是随机的，还是针对某个特定的五元组。
如上图（a），当使用被动追踪中去测量链路延迟时（也就是正常的追踪），可能由于追踪报文的两次返回所经过的路径不同，造成测量不正确。guided probing不仅可以注入报文，还可以指定报文经过的路径，通过这一特点，设置探针报文经过S1 -> S2 -> S1，这样报文就会经过S1两次，这两次的时间间隔就是链路延迟的两倍。
故障排查：
Latency profiler。当两个服务器之间的延迟变得很高时，为了去查询问题的原因，首先，对两个服务器之间的TCP SYN报文的debug bit进行标志，追踪这些报文，就可以路径上所经过的网络设备。然后，注入guided probes去测量逐跳延迟。有了这些信息，就能快速定位到发生问题的网络设备。
Packet drop debugger。发生丢包的原因可能有很多，例如拥塞、软件bug或者配置错误，这就需要调试器对发生丢包的踪迹进行检查。对于一个遭到丢弃的报文p，通过最后抓取到p的交换机Sn，可以推断出p所期望的下一跳。这样，调试器就会注入guided probes到Sn，确定丢包是否是持续的，确定丢包是否有固定模式（例如特定的五元组）。
Loop debugger。循环在数据中心网络中并不常见，但是它一旦出现，就将消耗大量的资源。当一个循环被检测到时（踪迹上相同设备出现两次），首先调试器注入guided probes去测试循环是不是持续的，如果循环是持续的，它会将循环路径上的设备进行上报，于是操作员就可以禁用设备上的端口来打破循环。在这期间调试器会持续注入guided probes，直到循环消失。
ECMP profiler。在数据中心网络中，交换机会用ECMP（等价路由）来切分流量到下一跳。但可能由于不好的哈希函数或者路由问题，会造成链路拥塞。对每一个交换机，ECMP profiler将会它的链路总负载。当检测到不均衡的负载划分时，它会启动更加细粒度的负载计数器来排查，检测这样的不均衡的负载划分是对所有的流还是特定前缀的流。这些信息可以帮助操作员快速的检测并定位故障。
RoCEv2-based RDMA debugger。RoCEv2-based RDMA（Remote DirectMemoryAccess）是一个新兴协议，它对网络的延迟要求非常的高。在数据中心网络中，有时由于NIC的一些软件bug，使得RDMA达不到理想的性能，但是NIC是由第三方厂商所提供的，不能得到其中的代码，于是就需要用调试器来处理这个问题。调试器追踪关于RDMA的所有控制报文，这些信息不仅能够观察到RDMA流的实际行为，也能调试第三方的代码问题。
（文章中第七部分提到了一些这些问题在实际中的一些处理的例子）