【论】Trumpet: Timely and Precise Triggers in Data Centers

Trumpet: Timely and Precise Triggers in Data Centers

摘要

      监控基础架构需要从提供聚合输入的被动系统->人工操作员->支持编程控制的主动系统。Trumpet是一个利用CPU资源和终端主机可编程性的事件监控系统，以ms时间尺度监控每个数据包并报告事件。系统使用终端主机上的触发器有效地检测网络范围的事件，可以通过以全线速检查每个数据包来评估触发器，也可以扩展到每个终端主机数千个触发器，将数据包处理延迟限制在几毫秒。允许操作员描述新的网络事件，检测相关的突发和丢失。

1 简介

      商业网络监控工具（SNMP、NetFlow）以相对粗略的时间尺度（几秒到几分钟）产生高度聚合或采样的统计数据（例如，在每个端口操作的SNMP、基于采样的NetFlow），通常为用来为操作人员呈现整体网络的仪表板提供输入，并且需要人员解释其输出并初始化网络控制。

      监控系统需要更精确地检测事件（例如，瞬态拥塞和服务器负载不平衡）（检查每个数据包），在精细的时间尺度上（大约几毫秒），并且以可编程的方式（以便可以动态地确定事件集）。本文将监控基础设施从被动转为主动：不是向操作员提供聚合网络视图，相反，监控基础设施应该允许根据当前条件进行交互式地深入研讨，并且可以对预定义的、细粒度的针对整个结构范围的数据包事件（而不是单个链路或服务器）进行自动化应对。

      实现该目标的挑战就是需要沿着多个方面的扩展：端口数量、网络中的高聚合流量，以及数据中心网络将拥有更多的租户和服务。我们利用数据中心终端主机相对丰富的处理能力，使用强大的CPU监控所有数据包而不需要采样。

贡献。Trumpet：一个事件监控系统，用户在其中定义网络范围的事件，集中控制器在终端主机上安装触发器，数据中心规模的每包监控。Trumpet功效的关键在于对由软件交换机解复用的数据包内联的每包处理进行仔细优化。

      Trumpet的优势：（1）引入了一种简单的网络广泛事件定义语言，允许用户通过指定过滤器来定义网络范围的事件，以识别评估谓词的数据包集合，谓词计算结果为true时发生事件，用户可以设置谓词的时间和流量粒度。允许用户捕获许多事件：识别流是否触发其他流上的拥塞，何时服务主机的聚合流量超过阈值，当连接遇到数据包丢失时。

      （2）在端到端主机上扩展事件处理，在几毫秒的时间上检测事件。当接收到事件定义时，中央控制器安装与终端主机处事件相对应的触发器，触发器确定用户指定的事件是否发生在终端主机上，若发生在终端主机上，终端主机将触发器的输出发送到控制器，控制器从各个终端主机收集触发结果，以确定是否以通过网络满足事件定义。关键挑战是在软件交换机上不使用额外的CPU且能够以全线速支持数千个触发器，并且（a）没有丢包（b）没有丢失任何事件（c）数据包延迟不会超过数微秒。

      Trumpet在终端主机中分两个阶段处理数据包：匹配和分散阶段，匹配每个传入数据包并保持每个五元组流统计信息，对每个触发器的时间粒度运行的聚集测试和报告，收集每个触发器的统计信息，在触发器满足时报告。我们还设计并实现了一套算法和系统优化，包括缓存，以减少计算、预取和数据结构布局，以提高内存访问效率，谨慎使用虚拟内存，以及队列长度自适应调度技术窃取数据包处理的周期，在受到攻击时，会降级，在未来几年内自然扩展到可能部署在数据中心的高速NIC。

      （3）对各种工作负载和事件的Trumpet进行评估，我们评估了Trumpet在单核上运行4K触发器和（a）10G NIC上线速率的64字节数据包和（b）线速40G NIC上的650字节数据包。 Trumpet可以在不丢失数据包或丢失单个事件的情况下维持此工作负载。更一般地说，我们描述了可行的参数集或可行性区域，Trumpet完成每次扫描，永远不会丢失数据包。Trumpet可以在一个终端主机上匹配第一个触发器后的1ms内报告网络范围的事件，匹配复杂性与触发器的数量无关，因此可以将系统扩展到大量触发器。Trumpet在攻击下可以降级，通过适当选择参数（可以通过精确模型确定），它可以承受96％的数据包是DoS数据包的工作负载，但代价是无法监控大小小于128字节的流量。

      （4）使用了三种案例证明了Trumpet的表现力：（a）当流量中有一连串的丢失时，使用严密的控制回路来调节流量（b）自动识别导致瞬态拥塞的流程（c）使用网络范围事件检测组合体积超过阈值的服务。

      （5）准确地查看数据中心。NIC卸载可以节省终端主机的CPU，可以监控绕过虚拟机管理程序的流（使用SR-IOV和RDMA），将数据包或数据包头镜像到控制器（操作员或者脚本可以检查标头或内容）可以帮助深入研究由Trumpet触发的事件。这些方案可能需要在控制器上以高速率处理数据包。

2 TRUMPET案例

      现代数据中心需要实时、细粒度、精确的监控，以满足各种控制系统的需求。

当今监控系统的问题。事件通常根据网络丢弃、延迟或提供的数据包来定义，可以在拓扑范围内从特定流量到流量聚合（例如，到服务的所有网络流量），在时间范围内从极端短到长的事件。

      传统监控系统在较大的时间尺度上提供网络的粗粒度视图，不足以捕获事件或在精细时间尺度上捕获事件。SNMP每隔几分钟提供一个端口计数器，过于粗糙；OpenFlow为聚合流提供计数器，每隔几秒报告更新的计数器；sFlow使用分组采样，不能捕获瞬态时间（瞬态分组丢失），不能跟踪连接状态（拥塞窗口），不能正确地估计链路负载。

此外，今天的监控系统无法很好地扩展到具有更高容量和更高利用率的大型网络。更高的连接速度和更大的标度意味着需要监控更多的数据包，更高的网络利用率需要更及时的事件回报，因为延迟的终端报告会影响更多的流量。不幸的是，更高的利用率也减少了用于监控的网络资源。网络监控系统的精度会受到更高的规模和利用率的影响，从而对实现服务水平目标和高利用率的目标产生不利影响，特别是在数据中心网络中。

数据中心需要精确，精细的时间尺度事件监控。数据中心需要新型的事件监控功能，以捕获各种网络错误行为（例如，错误配置，瞬态循环，异常，丢弃）以及作为网络管理决策的输入（例如，流量工程，负载平衡，VM迁移）。我们在此处描述了一些示例，并在第3节中列出了更多示例。

识别由交通突发引起的损失。流量突发在数据中心中很常见，可以提高应用程序性能。例如，NIC offloading [31]分批发送数据包以减少处理开销，分布式文件系统批量读写以最大化磁盘吞吐量。但是，突发流量可能会在穿过浅缓冲交换机时造成损失[51]，这会显着影响应用性能。为了提高性能，可能需要检测丢失的分组（例如，通过重传）和突发中的分组（例如，通过跟踪分组时间戳），并识别它们的相关性（例如，通过关联分组序列号）。使用数据包采样或流量级计数器无法进行所有这些检测。

找出拥塞的根本原因。瞬态网络拥塞（例如，incast [8]）很难诊断。例如，MapReduce减速器可能会看到由网络拥塞引起的显着性能下降，即使其聚合门需求可能远低于交换机容量。这是因为另一个应用程序通过同一个交换机发送的数据可以触发瞬态输入损失，从而增加了减速器的处理时间，从而增加了作业完成时间。这种结果通常是在短时间尺度（10毫秒）内短暂的流量突发造成的。在今天的交换机（粒度> 1s）的聚合计数器上可能无法检测到这种情况。为了诊断这种行为，重要的是识别具有高损耗的TCP流并将它们与经历瓶颈的重击者相关联。

监控服务器负载平衡和负载突发。维护不同应用程序的服务级别协议（SLA）需要在云服务中进行仔细的配置和负载平衡[44]，因为不完美的负载平衡和短请求突发可能导致长尾延迟[28,26]。跟踪服务负载的一种好方法是监控网络流量[5]。如果我们能够在短时间内识别出卷异常，我们就可以确定服务器之间的低效负载平衡，在某些服务器上提供问题或DDoS攻击。例如，运营商可以查询长尾延迟是否是因为服务看到突发请求，或者超过50％的服务VM因DDoS攻击而看到流量激增。

Trumpet。这些事件检测超出了当今部署系统的能力。在本文中，我们考虑了监控系统设计空间中的一个质的不同点。我们要问：监控系统是否存在可以在几毫秒内检测和报告事件的设计，其中事件检测是精确的，因为系统处理每个数据包（而不是比如采样），以及事件规范可以灵活（允许一系列空间和时间范围的事件定义）？这种监控系统对于在流量异常的及时报告，细粒度流量调度，调步，流量工程，VM迁移和网络重新配置等毫秒时间尺度的自动诊断和控制特别有用。

3 在Trumpet中定义事件

      Trumpet的用户使用匹配动作语言的变体定义事件，为表达事件而不是动作而定制，此语言中的事件由两个元素定义：数据包筛选器和谓词。数据包筛选器从进入、遍历或者离开由Trumpet监视的数据中心（或其中一部分）的所有分组中定义特定事件的分组集合。过滤器在适当的包头字段上使用通配符、区间或者前缀来表达。如果一个数据包匹配了多个过滤器，则它属于每个相应事件的数据包集，谓词只是一个布尔公式，它检查在数据包过滤器定义的数据包集上定义的条件，当谓词评估为真时，事件已经发生。谓词通常定义在每个数据包变量上表示的某些聚合函数上，用户可以为聚合指定时空粒度。

事件定义语言的元素。Trumpet中的每个数据包都与几个变量相关联，表1显示了文本讨论的用例变量，添加新的变量很容易。

      谓词可以根据对这些变量的数学和逻辑运算以及这些变量的聚合函数（max，min，avg，count，sum，stddev）来定义。要指定执行聚合的粒度，用户可以指定（a）要评估谓词的time_interval以及（b）指定如何打包数据包的flow_granularity，以便聚合函数计算在最后一个time_interval内的每个桶内的数据包集合。

      flow_granularity可以采用诸如五元组之类的值或包字段上的任何聚合（例如，srcip，dstip和srcip/24）。图1显示了两个计算不同flow_granularity的四个流量的例子。在srcip，dstip粒度，前两个流被一起打包，第三个流在单独的桶中。在srcip/24粒度下，前三个流被一起打包，flow_granularity规范使事件描述更加简洁。要在服务中查找繁琐的VM对，运营商可以以srcip，dstip的粒度定义事件，而无需明确标识实际IP地址。在某些情况下，可能事先不知道这些IP地址：例如，数据中心内部服务的所有用户。下面给出了具有不同flow_granularity的事件定义的附加示例。

示例事件定义。表2给出了一些事件定义的示例，基于第2节中的讨论。

第一个示例是查找将一批数据包发送到机架的重型击球员流（比如10.0.128.0/24）。 Trumpet的用户将IP块定义为过滤器，定义一个谓词，该谓词收集总字节数并在10 ms时间间隔内检查总和是否超过阈值（例如125 KB作为1G链路容量的10％），展示5元组。请注意，此事件定义以一个范围表示（例如10.0.128.0/24），并且可以标记其行为与谓词匹配的任何5元组流。

第二个示例检测服务器使用给定IP块（例如10.0.128.0/24）的任何服务流中的大量相关的丢失突发。用户定义一个谓词，该谓词计算is_lost和is_burst [31]同时为真的数据包数，并检查计数何时超过阈值（谓词如表2所示）。具有多个流上的flow_granularity定义的事件可用于coflow调度[9]，指导SDN规则放置[41]并估计FlowGroups对速率限制的需求[33]。

表中的下一个事件检测TCP连接何时出现拥塞。此事件跟踪当前和上一个时期的两个方向上的所有TCP流的seq，ack和dup变量。它使用连接另一端的ack和dup计算当前时期中的acked字节的大小，并根据ack和seq将其与上一个时期中的未完成字节进行比较。类似事件可用于在短时间内检测违反带宽分配策略[4]，调试TCP拥塞控制算法的新变体，并检测无响应的VM到ECN标记和RTT延迟。

稍微不同的示例（表2中的第四个）检测分布式服务上是否存在负载峰值（由IP地址块10.0.128.0/24定义）。在此示例中，如果此IP块内10毫秒时间间隔内所有目标服务器的流量总量超过此阈值，则谓词的计算结果为true。对于此事件，flow_granularity为dstIP / 24，不再是五元组了。

除上述示例之外，Trumpet还可以用于其他管理任务，例如：（a）通过计算任何源和目标之间的总数据包丢失来诊断两个服务的VM之间的可达性问题（类似的查询可以找到黑洞[23,58]和中间盒中的瞬态连接问题[47]）和（b）通过检查特定源IP / 24中是否有任何服务器集合来查找租户的流行服务依赖性将每秒超过10GB的流量发送到目标IP / 24（服务IP范围）中的一组服务器（例如，将其VM迁移到同一机架[27]或将负载平衡规则放在ToR上时非常有用）。

4 TRUMPET概述

Trumpet旨在支持数千个动态实例化的并发事件，这些事件可能导致每个主机上有数千个触发器。例如，主机可以运行50个不同租户的VM，每个VM与10个服务器通信。为了支持不同的管理任务（例如，帐户管理，异常检测，调试等），我们可能需要在10个不同的每个数据包变量（例如，表1中）和不同的时间间隔和谓词上定义触发器。

Trumpet由两个组件组成（图2）：控制器上的Trumpet事件管理器（TEM）和每个终端主机上的Trumpet Packet Monitor（TPM）。

用户将事件描述（第3节）提交给TEM，TEM将静态分析这些描述并执行以下操作序列。首先，根据过滤器描述和网络拓扑，它确定哪些终端主机应该监视事件。其次，它为每个终端主机生成触发器，并在每个主机的TPM上安装触发器。触发器是事件描述的自定义版本，包括流和时间粒度的过滤器和谓词。但是，触发器中的谓词可能与相应事件定义中的谓词略有不同，因为事件描述可能描述网络范围的事件，而触发器捕获主机本地事件。第三，TEM从主机TPM收集触发满意度报告。当触发谓词的计算结果为true时，TPM会生成满意度报告。对于每个满足的触发器，TEM可以轮询为同一事件运行触发器的其他TPM，以便确定是否满足网络范围的谓词。

      Trumpet设计中的一个重要架构问题是放置监控功能（TPM）的位置。Trumpet因各种原因选择终端主机，其他选择可能不具有表现力或及时性。在使用交换机测量功能的网络数据包检查中，缺乏根据每个数据包变量描述事件的灵活性;例如，由于交换机看到的汇总流量高于终端主机，因此很难以单个数据包的粒度查看丢失，突发或RTT等变量。或者，将所有数据包发送到控制器以评估事件描述将导致显着高的开销，并且可能无法及时检测。

Trumpet的TPM监视虚拟机管理程序中的数据包，其中软件交换机将数据包从NIC传递到VM，反之亦然。此选择利用了终端主机的可编程性，虚拟机管理程序对进入和离开托管虚拟机的流量的可见性，以及新CPU快速（例如，使用直接数据I / O [30]）检查所有数据包的能力。精细的时间尺度。最后，Trumpet捎带了将CPU资源专用于软件交换机中的分组交换的趋势[24]：软件交换机通常在将数据包发送到VM之前对单个核中的每个数据包运行所有处理，因为跨数据库镜像数据包的成本很高由于数据复制和同步开销[14]。出于完全相同的原因，并且因为它需要对进入或离开主机的所有流量的完全可见性，TPM与该核心上的软件交换机位于同一位置。这种趋势基于现代服务器中核心数量的增加.

Trumpet专为使用软件数据包解复用的数据中心而设计，利用其可编程性支持复杂事件描述，可扩展到新要求，以及处理负载峰值的资源弹性。但是，Trumpet也可以在数据中心以两种方式使用，其中NIC直接将流量传输到不同的VM（例如，使用内核旁路，SR-IOV或接收端缩放）。第一个是镜像到管理程序的流量。新的NIC允许将流量镜像到管理程序可读的单独队列，使用Trumpet可以评估触发器谓词。虽然这会产生两次处理数据包的CPU开销（在虚拟机管理程序和虚拟机中），但这仍然保留了减少虚拟机数据包延迟的目标。此外，由于触发器评估不在数据包处理路径上，因此Trumpet不受数据包延迟的限制，因此可能不需要专用内核。我们已经使用7.2节中的镜像功能评估了Trumpet。第二个是网卡卸载。随着FPGA（例如Smart-NIC [17]）和NIC网络处理器[6]的出现，Trumpet可以将一些事件处理卸载到NIC。前面例如，它可以卸载触发过滤器，以便有选择地将数据包头发送给管理程序。随着NIC功能的发展，Trumpet可能能够评估NIC内更简单的谓词，让CPU内核可以自由执行更复杂的处理任务（例如，了解多个流程之间的相关性），我们的一些技术将继续有用。

Trumpet还依赖于能够检查IP和TCP的数据包报头，因此报头加密可能会降低Trumpet的表现力。

TPM和TEM的设计都存在重大挑战。在接下来的两节中，我们将介绍这些组件的设计，更加强调TPM上精确及时的测量所带来的系统和扩展挑战。我们还讨论了TEM的设计，但是使用例如[45,58]的技术完全设计高度可扩展的TEM超出了本文的范围。

5 TPM（Trumpet Packet monitor）

      Trumpet的主要挑战是Trumpet数据包监视器（TPM）的设计。 TPM受到物理接口总速率限制：（a）确定数据包匹配哪个触发器的过滤器，（b）更新与触发器谓词关联的每个数据包变量的统计信息，以及（c）在指定的时间粒度评估谓词，这可以是低至10毫秒。对于10G NIC，在最坏情况（小数据包）速率为14.8 Mpps时，这些计算必须适合平均每个数据包少于70ns的预算。

5.1设计挑战

需要两阶段处理。我们的事件定义限制了可能设计的空间。当收到数据包时，我们无法执行上述所有三个步骤。具体而言，检查谓词的步骤必须以指定的时间粒度执行。例如，谓词（10ms内流量的#packets低于10）只能在10ms间隔结束时进行评估。因此，TPM必须包括两个阶段：每个数据包发生的计算（第一阶段），以及在谓词评估粒度（第二阶段）发生的另一个阶段。现在，如果我们针对几毫秒的精细时标，我们就不能依赖OS CPU调度器来管理两个阶段的处理，因为调度延迟会导致超过上面讨论的每个数据包预算。因此，Trumpet运用在专用于软件切换的核心上，仔细管理后面描述的两个阶段。

稻草人的方法。为了说明TPM设计中的挑战，考虑两种不同的稻草人设计：（a）后匹配，其中阶段1简单地记录数据包报头的历史，第二阶段匹配数据包到触发器，计算每个数据包变量和评估谓词，以及（b）匹配优先，其中第一阶段将每个传入数据包与其触发器匹配并更新统计信息，第二阶段简单地评估谓词。

这两种极端都没有表现出色。使用4096个触发器，每个触发器仅以10ms的时间粒度计算来自IP地址前缀的数据包的数量，两个操作在完全10G数据包速率为14.8 Mbps时丢弃20％的数据包。服务器上如此高的数据包速率在NFV应用[16]、更高带宽链路和某些数据中心应用[36]中很常见。监控系统不会导致发往服务和应用的数据包丢失，并且数据包丢失也会降低监控系统本身的功效，因此我们认为这些解决方案是不可接受的。此外，这些稻草人解决方案并未实现我们的事件定义的完整表达：例如，他们不跟踪需要保持每流状态的损失和爆发（第3节）。修改它们会增加复杂性，这可能会导致线路速率损失更高。

设计要求。这些结果和稻草人设计有助于确定TPM设计的若干要求。首先，即使使用最先进的匹配实现，匹配优先和后匹配都会导致丢失，因为将数据包与过滤器匹配的开销通常超过可用于处理单个数据包的70ns预算10G NIC上的14.8 Mpps 64字节数据包。这表明需要更有效的每包处理（第一阶段）。我们还强制要求系统在DoS攻击下应该优雅地降级，因为攻击可以破坏对云提供商的监控和攻击并不罕见[39]。此外，对于匹配优先，处理数据包的任何延迟都会增加排队延迟以处理后续数据包：理想情况下，监控系统应该施加小而有限的延迟。

其次，我们观察到匹配优先比后续匹配更差，因为它导致TLB高3倍，缓存未命中高30％（后匹配表现出更多的局部性，因为它一次执行所有与数据包相关的操作）。因此，高速缓存和TLB效率是能够将触发处理扩展到全线速的关键设计要求。

5.2我们的方法

在Trumpet中，TPM将监视功能分为以下两个阶段：（a）匹配和分散，其中即将到来的数据包与5元组流（允许最精细的flow_granularity规范）匹配，每个数据包计数存储/每个流的其他统计信息（这会分散流的统计数据），以及（b）以指定的触发时间粒度运行的收集测试和报告，将统计信息收集到正确的flow_granularity，评估谓词并报告给谓词评估为true时的TEM。

以这种方式对处理进行分区使Trumpet能够满足前一个子部分中讨论的要求：

•正如我们在下面讨论的那样，这种分区允许设计促进缓存和TLB效率的数据结构，正如我们上面讨论的那样，这是至关重要的。为了表现。此外，两个阶段之间的CPU开销的平衡允许有效的分组处理，而不具有良好的表达能力：在第一阶段，我们可以通过缓存查找来最小化匹配开销。

•通过协同调度这些阶段（避免同步开销）可以实现小而有界的延迟：第二阶段是队列自适应的，仅在NIC队列为空时运行。

•每个5元组流的匹配和分散允许我们跟踪每个流统计信息，例如丢失和突发，并将其与收集测试和报告阶段分开，让我们计算一次统计数据并在匹配相同流的多个触发器之间共享这些统计信息，但流量粒度不同。

•此分区还可以对系统中的两个处理机器人进行本地化：数据包处理和收集统计信息。正如我们稍后讨论的那样，这使我们能够为系统设计安全措施，以便在保持统计数据收集的保真度的同时完全避免数据丢失。

5.3 Trumpet Trumpet中的数据结构

使用四种数据结构（图3）：一个流表，用于存储流的每个数据包变量的统计信息，一个触发器存储库包含所有触发器，一个用于快速匹配的触发器索引，以及一个针对DoS攻击回弹快速匹配的过滤器表。我们稍后将详细描述后两种数据结构。

流表是一个哈希表，键入流的5元组，对于每个流，只保留与流匹配的触发器所需的统计信息（图3）。因此，例如，如果流仅匹配其谓词在体积（有效载荷大小）方面被排除的单个触发器，则流表不跟踪其他每个数据包变量（丢失和突发，往返时间，拥塞窗口等）。变量可以在触发器之间共享，TEM根据触发器安装时的事件描述的静态分析告诉TPM要跟踪哪些变量。流表保持足够的内存来存储大多数每个数据包的统计信息，但有些（如丢失和突发指示符）存储在动态分配的数据结构中。最后，TPM维护一个静态分配的溢出池来处理散列冲突。触发器存储库不仅包含触发器的定义和状态，还跟踪与每个触发器匹配的5元组流的列表。在后面的部分中，我们将讨论如何优化这些数据结构的布局以提高缓存效率.

5.4阶段1：匹配和分散

在此阶段，算法1在每个数据包上运行。它在流表中查找数据包的5元组并更新每个数据包的统计信息。如果查找失败，我们使用匹配算法（第11-14行）将数据包与一个或多个触发器匹配（流通常可以匹配多个触发器）。

使用元组搜索快速触发匹配。将数据包标头与触发器过滤器匹配是与通配符规则进行多维匹配的实例。为此，我们基于元组搜索算法[52]构建了一个触发器索引，该算法也用于Open vSwitch [46]。元组搜索算法使用这些通配符过滤器中仅存在有限数量的模式的观察（例如，对于IP前缀仅有32个前缀长度）。触发器索引由多个哈希表组成，每个模式一个，每个哈希表存储过滤器和每个过滤器的相应触发器。在每个散列表中搜索涉及屏蔽数据包标头字段以匹配散列表的模式（例如，对于在/ 24前缀上定义的表，我们屏蔽掉IP地址的低8位），然后散列结果以获得匹配的触发。元组搜索内存使用量与触发器数量成线性关系，其更新时间是不变的。

性能优化。由于数据包处理会带来有限的时间预算，因此我们使用多种优化来减少计算并提高缓存效率。为了提高性能，软件交换机通常会从NIC读取一批数据包。当我们处理这个批处理时，我们使用两种形式的缓存预取来减少数据包处理延迟：（1）预取包标头到L1缓存（行2-3）和（2）预取流表条目（第4-7行）。已经观察到数据中心应用程序在同一个流上生成一个数据包突发[31]，因此我们缓存最后一个流表查找的结果（第5,9行）。为了最大限度地减少TLB未命中的影响，我们将流表存储在大页面中。在第7节中，我们证明了每个优化对于Trumpet的性能至关重要。

5.5阶段2：收集，测试和报告

此阶段将流表条目中的所有统计信息收集到为每个触发器指定的flow_granularity（重新调用流表以5元组粒度存储统计信息，但可以定义触发器更粗糙的流粒度，如dstIP / 24）。然后，它评估谓词，并将所有评估为true的谓词报告给TEM。

最简单的实现在一次触发扫描中运行整个阶段，可能导致大的数据包延迟甚至数据包丢失，因为在此阶段正在进行时，数据包可能会在NIC中排队或丢弃。调度此阶段是Trumpet设计的一个棘手问题。

从高层次来看，我们的实施工作如下。时间被划分为大小为T的时期，这是所有触发器的时间粒度的最大公因子。 Trumpet支持小到10毫秒的T.在每个流表条目中，我们对统计数据进行双重缓冲（如卷，丢失，突发等）：一个缓冲区收集奇数编号的时期的统计数据，另一个缓冲区收集偶数编号的时期。在第i个时代，我们收集了第i-1周期的统计数据。因此，双缓冲使我们能够灵活地将触发扫描与数据包处理交错。

我们以队列自适应方式安排此聚集扫描（算法2）。当NIC队列为空时，我们运行有限时间的扫描步骤（算法3）。由于Trumpet的精心设计，它始终能够保持领先于传入的数据包，因此这些扫描永远不会被匮乏（第7节）。该界限确定了测量系统施加的延迟，并且可以进行配置。在我们的实验中，我们可以将延迟限制在10μs以内（图4）。每次调用此算法都会从触发器存储库中处理一些触发器（算法3中的第4-5行）。此处理基本上从流条目中收集所有统计信息（回想一下，每个触发条目都有一个匹配的流条目列表）。

一旦处理了触发器的所有流，谓词计算结果为true就报告给TEM（算法3中的第14-18行）。但是，在处理触发器时，可能会超出处理限制：在这种情况下，我们保存扫描状态（第10行），并在NIC队列下一个空时恢复扫描。对于每个触发器，在扫描步骤期间，不是在处理每个流之后计算运行时间（这可能是很大的，~100个周期），我们仅计算估计的经过时间超过预算的一小部分时的实际经过时间（第7-13行）。估计值基于到目前为止为此触发器处理的流的数量。

我们的方法假设我们可以在一个时期（10ms）内完成所有触发器的扫描：在第7.2节中，我们认为我们可以在一个内核上为4K触发器实现这一目标，即10G NIC，即使在DoS攻击下全线速率下也能实现小数据包，并表明删除我们的一些优化（下面讨论）可能导致未完成的扫描。我们还证明，在许多情况下，在至少一个当前CPU中不能维持较短的纪元持续时间。

性能优化。我们懒洋洋地重置计数器并删除旧流量。在每个流表条目中，我们存储重置条目时的纪元号。然后，当我们在触发扫描期间更新条目或读取其数据时，如果存储的纪元号与当前不匹配，我们重置统计数据（算法1中的第15-16行）。

Trumpet还为此阶段整合了几种内存优化。触发条目连续存储在存储器中以便于硬件高速缓存预取。我们将触发器存储库存储在一个巨大的页面中，以减少TLB未命中并存储与分块链表[43]中的触发器匹配的流条目列表，以改善访问位置。每个块包含64个流条目，这些条目从预先分配的大页面分配，同样用于TLB效率。对于具有许多流的触发器，与以较高内存使用量为代价的流链接列表相比，分块减少了指针查找的成本。

我们的最终优化包括以所需的流量粒度有效地收集统计数据。例如，为了支持触发器，该触发器报告来自任何源IP（源IP的流粒度）的主机（A）的流量是否大于阈值，我们必须跟踪流中每个源IP的数据包的有效载荷。我们可以使用每个触发器的哈希表来跟踪它，但这会增加内存和查找开销。相反，我们动态地实例化一个新实例触发器：当来自源IP X的数据包与具有过滤器dstIP = A的触发器匹配时，我们使用过滤器srcIP = X和dstIP = A创建新的触发器。

5.6 DoS下的优雅降级

对于Trumpet来说，强大的DoS攻击非常重要，这些攻击旨在耗尽监控系统中的资源，导致数据包丢失或阻止触发扫描完成（这会阻止事件的准确检测）。 Trumpet中昂贵的步骤是在匹配和分散阶段匹配触发器的新流，并在收集测试和报告阶段根据其流列表更新触发器。

我们假设攻击者知道系统的设计。要通过触发尽可能多的匹配操作来攻击系统，攻击者应该为每个流发送一个最小大小的数据包。这样，扫描可能无法完成，因此可能无法正确报告触发器报告。为了缓解这种情况，当我们检测到未完成的扫描时，我们会设置一个DoS阈值：仅对过滤表中字节大小超过此阈值的流调用匹配，如果它们发送的字节数较少，则流将从流表中删除当流量表中的新流量与它们发生冲突时触发阈值，或者触发器在扫描时读取它们。可以通过分析每个数据包处理操作和每个匹配操作的成本来预测DoS阈值（第6节）。这种设计的代价是不监控非常小的流量：我们在第7节中量化了这种权衡。

5.7 总结

Trumpet平衡了几个相互冲突的目标：事件表达能力，严格的处理和延迟预算，以及有效的核心使用。它通过仔细划分两个阶段的触发器处理（匹配-分散和收集-测试-报告）来实现这一目的，以保持每个数据包处理的数据访问位置，有效保持每个流量统计，并每个周期访问触发器信息一次。为了使匹配和分散阶段有效，Trumpet使用元组搜索匹配，NIC轮询（DPDK），批处理数据包，缓存预取，大页面（更少的TLB未命中）和缓存最后一个流条目。为了最小化收集测试和报告期间的处理延迟，我们提出了一种队列自适应多步扫描。我们使用延迟重置（将更少的数据带入缓存），以线性方式访问数据（利用缓存预取），更少检查时间，分块流条目（更少的指针跳转）来优化扫描以在查询时间间隔内完成并使用大页面（更少的TLB未命中）。虽然其中一些是众所周知的，但其他一些如自适应扫描，我们的两阶段分区以及我们的DDoS弹性方法都是新颖的。而且，这些技术的结合对于实现相互冲突的目标至关重要。最后，我们对缓存和TLB效果以及数据结构设计的经验可以为未来快速数据包处理工作提供信息。

6. TRUMPET EVENT MANAGER

Trumpet Event Manager（TEM）将网络范围的事件转换为主机上的触发器，从主机收集满意的触发器和统计数据，并报告网络范围的事件。图5显示了使用示例的详细过程：考虑一个事件，该事件表示为两个主机上服务接收的总流量的谓词，如果该数量超过10Mbps的阈值，则谓词为真。在步骤1中，TEM静态分析事件描述以确定触发谓词，根据服务IP地址定义的事件过滤器以及IP地址到主机的映射，找到要安装触发器的主机。然后，它在触发器之间划分阈值并在步骤2中安装它们。例如，我们将每个主机的阈值设置为事件阈值的一半（5Mbps）。如果两个主机触发器均未超过5Mbps，则其总和不能大于10Mbps。在步骤3中，主机上的TPM测量流量并向TEM发送触发坐标消息，指定在收集测试和报告阶段评估触发时的事件和时期。

在步骤4中，在接收到针对事件的第一满意度报告时，TEM轮询其他主机在该时期的数量的本地值。对于我们的示例，TPM可能已发送满意值7Mbps，因此TEM要求其他TPM的值检查其值是否高于3Mbps。在步骤5中，TPM在完成阶段2之后响应控制器轮询，此时它们可以从分组处理中窃取循环; TPM允许触发器保留几个上一个时期的历史来回答民意调查。最后在步骤6中，TEM在接收到所有轮询响应之后评估该事件。为此，TEM依赖于​​时间同步的测量时期;对于TEM，PTP [29]的同步精度应该足够。

网络范围的查询。为聚合函数划分网络宽阈值的方法可以适应多种聚合函数。例如，可以设计触发器的阈值，以限制任何凸函数上的误差，对于分布式主机的平均数量或他们的标准偏差[18]。除此之外，Trumpet还可以支持其他类型的网络范围查询。例如：a）从许多事件中收集统计信息：要查找租户中50％的VM（或一定数量的VM）是否收到超过阈值的流量，我们会在Trumpet中为每个VM添加事件，每周期收集他们的触发满意度（true的数量）并报告超过50％的相关事件是否发生。 b）根据事件向下钻取：TEM可以有条件地安装事件，例如，仅在发生另一个事件（例如，丢失）时才安装重型击球手检测事件。 c）估算网络范围的统计数据：我们可以通过在标准偏差（std <stdold  - ε和std> stdold +ε）上定义两个事件来监控具有有界误差ε的一组VM的交通量标准偏差，并相应地更新它们如果它们中的一个满意。d）相对谓词：通过将平均值和标准差的估计值提供给另一个事件，我们可以检测到超过平均值超过k×标准差的异常值VM。

40G及以上。虽然Trumpet只需要一个核心来处理10G链路上的14.8Mpps小数据包，或者40G链路上的全线速650字节数据包，100G和/或更小的数据包大小，但可能需要多个核心。为了避免核心间同步，TEM在每个核心上运行独立的TPM，并将它们视为独立的实体。在TEM处遇到一些同步化开销，但这很小，因为只有在满足一个触发器时才会发生这种情况。假设来自流的所有数据包通常由同一核处理，这可确保TPM可以正确保持流的状态。我们在第7.1节中的网络用例说明了这种能力。还可以在每个具有多个TPM的主机上设计local-TEM，其在主机本身执行类似的聚合，同时具有最小的同步开销：这可以减少轮询开销并加速TEM处的事件检测。

DoS弹性。 TEM允许操作员设置DoS阈值，使得不处理大小低于该阈值的流。这减少了匹配开销，允许Trumpet在DoS攻击下优雅地降级。 TEM使用一组已定义的触发器（公式1），终端主机系统配置中的TPM处理成本，根据脱机配置的模型计算阈值。Trumpet处理成本包括：a）数据包处理和检查过滤表，TP  b）匹配，TM  c）更新流表，TU  d）扫描，TS。目标是找到最大阈值，使每小时的总处理时间T低于1秒。我们可以通过在实验中查找CPU的空闲时间来找到T -TP，该实验仅转发具有未通过DoS阈值的最小数据包的流量。每个流的匹配开销（Match（#pattersns））是#filter pattern的线性函数，其系数可以离线计算。类似地，我们计算每个流统计信息更新的最大时间（更新）以及基于流（扫描）离线更新触发器的时间.等式中的因子1.5。 4是因为扫描可以在多个步骤中运行，而新流可能到达。因此，触发器可以保留上一个纪元和当前纪元的两个流的流条目。因此，扫描过程平均每个触发可以处理50％以上的条目。我们在第7.2节中评估了模型的准确性.

TEM可伸缩性和TPM性能。正如我们在第7节中所示，TEM每个核心每秒可以处理近16M的触发满意度报告。如果有必要，我们可以通过在不同服务器上分割事件或者通过根据每个主机上触发满意度的历史不均等地划分阈值来减少轮询的频率来进一步缩放TEM [10]。为避免在终端主机上延迟数据包，TPM使用非阻塞套接字。为减少轮询响应延迟，TPM批量套接字读写和轮询处理。如果需要，TEM可以（留待将来的工作）通过切片事件过滤器来减少TPM开销，以最小化匹配的触发模式的数量，并通过时间多路复用触发器（通过（un）安装它们随着时间的推移）。