在现代网络中,网络流量监控对于网络管理员来说至关重要。网络流量监控提供的功能远远超过传统的连接监控。流量监控收集并分析有关网络流量的数据,例如流量来源和目的地、流量类型以及网络中的流量数据量。
网络流数据通常从各种网络设备(例如服务器、路由器、交换机和防火墙)收集。这些设备监控并记录通过设备的流量,捕获源和目标 IP 地址、端口号、协议类型和时间戳等详细信息。这些数据可让您全面了解网络活动,并有助于分析基础架构内的通信模式。通过了解网络中正在发生的事情,您可以轻松理解以下内容:
VPP 中的 flowprobe 插件旨在提供实时流量分析和监控功能,默认是基于IPFIX(Internet Protocol Flow Information Export)协议。此插件一直缺少维护,目前并不能很好工作。
在 vpp-dev 邮箱中,介绍了一款新的简单网络流量采集插件:sFlow (Simple Network Management Protocol Flow Monitoring)插件。该插件实现了随机数据包采样和接口遥测流功能,支持在 Linux 平台上进行标准的 sFlow 导出。此监控机制产生的开销极小,即使在高负载条件下,也能实现详细的实时流量分析,并允许查看数据包头部中的任意字段。如果 VPP 的 linux-cp 插件正在运行,则接口将自动映射到相应的 Linux tap 端口。
IPFIX(Internet Protocol Flow Information eXport)和 sFlow(simple Flow)是两种广泛使用的网络流量监控协议,它们各自具备独特的优势和应用场景。IPFIX 主要侧重于标准化的流量信息收集和导出,适用于需要详细记录和分析网络流量的应用场景。它能够提供从第 3 层到第 7 层的深入流量分析,包括完整的五元组信息(源地址、目的地址、源端口、目的端口、协议类型),并且支持灵活的数据采集和导出格式。相比之下,sFlow 则更为轻量级,它的设计目的是在对系统性能影响较小的情况下提供实时的流量监控。sFlow 通过对网络数据包进行采样,并将采样结果汇总后导出,从而实现实时监控和基本的流量统计。此外,sFlow 的实现较为简单,易于部署,并且支持从第 2 层到第 4 层的流量监测。总的来说,IPFIX 更适合需要详细流量分析和合规性的应用场景,而 sFlow 则更适合需要快速部署且对实时性要求较高的环境。
本章节内容翻译sflow vpp介绍博文1 部分内容,感兴趣的可以点击文末阅读原文。
相关信息链接: 1、vpp-dev邮箱链接: https://lists.fd.io/g/vpp-dev/topic/108806641#msg25090 2、sflow vpp介绍博文1 : https://ipng.ch/s/articles/2024/09/08/vpp-with-sflow-part-1/ 3、sflow vpp介绍博文2: https://ipng.ch/s/articles/2024/10/06/vpp-with-sflow-part-2/ 4、vpp插件PR: https://gerrit.fd.io/r/c/vpp/+/41680
sFlow 标准提供了从第 2 层到第 7 层的实时流量模式可见性,并且开销极小。即使在高流量环境下,它也能支持计费、故障排查和亚秒级的 DDoS 缓解等控制应用。这一标准已在 ASIC 和软件交换机上广泛实施超过十年,多数流量分析工具均支持 sFlow,并且有开源解决方案可供选择。
VPP 的 '向量包' 数据路径特别适合 sFlow 关键性能路径所需的 1:N 随机数据包采样。在典型的采样率(例如 1:5000)下,整个向量通常会在一步中被跳过。我们使用无锁/无等待的 FIFO(先进先出)队列将样本传递给主线程以进行导出,确保数据路径工作线程中的抖动最小。即使在更高的采样率设置下,该解决方案依然稳健且表现良好。例如,当 VPP 测试交换机配置为转发:L3转发每秒 1099 万个数据包,L2层每秒 1489 万个数据包, 并在 1:1000 的采样率下进行 sFlow 采样时,持续转发性能仅下降到:L3层转发每秒 982 万个数据包,L2层转发每秒 1396 万个数据包。可见性能几乎可以忽略不计。
sFlow协议:
该协议的维护由 [sFlow.org] 联盟执行,该联盟是 sFlow 协议规范的权威来源。sFlow 的当前版本是 v5。sFlow(采样流的缩写)在以太网层工作,检查通过设备物理网络接口的每 N 个数据报中的 1 个(通常为 1:1000 或 1:10000)。在设备上,sFlow 代理执行以下步骤:
最后,代理会通过网络将样本和其他信息作为 UDP 数据报发送到 sFlow 收集器以进行进一步处理。
sFlow 经过专门设计,充分利用了数据包采样的统计特性,可以使用统计采样理论进行建模。这意味着 sFlow 流量监控系统将始终产生统计上可量化的测量结果。
sFlow:Netlink PSAMPLE:
sFlow 旨在成为采样设备的一种非常轻量的操作。它通常可以在硬件中完成,但也存在几种软件实现。我认为一个非常聪明的做法是将采样器与代理的其余部分分离。Linux 内核有一个称为 [ PSAMPLE ] 的数据包采样 API,它允许生产者将样本发送到某个组,然后允许消费者订阅某个组的样本。PSAMPLE API 在幕后使用 [ NetLink ]。这里的想法是,一些sFlow Agent(特别是 VPP 插件)将从物理网络接口定期采样并生成 Netlink 消息。然后,其他一些程序(特别是 VPP 之外的程序)可以使用这些消息并进一步处理它们,创建带有 sFlow 样本和计数器以及其他信息的 UDP 数据包,并将它们发送到 网络上其他位置的sFlow Collector 。
有一个名为 [ psampletest ] 的实用工具,它可以订阅这些 PSAMPLE netlink 组并检索样本。我第一次使用这些东西时,并不知道这个实用工具的存在,并且一直收到错误。事实证明,有一个内核模块需要加载:modprobe psample并且psampletest很有帮助地为您完成了这项工作 [ ref ],因此请确保已加载并添加了该模块,/etc/modules否则您将像我一样花费大量时间。
该设计旨在最小化减轻 VPP 数据平面的负担,将所有繁重的工作移至外部处理。该插件将在 VPP 中创建一个名为 sflow 的业务node节点,此节点插入在 device-input 之后。换句话说,如果启用,该插件将获取从输入提供程序(例如 dpdk-input 或 rdma-input)读取的所有数据包的副本。该插件的主要职责是处理数据包。如果没有选择进行采样,则直接将数据包传递到下一个节点,通常是 ethernet-input。几乎所有重要的操作都在 node.c 文件中实现。
每个至少拥有一个接口的worker工作线程都会创建一个 FIFO(先进先出队列),并将它所服务的已启用接口上的样本入队到该 FIFO 中。主线程中运行的一个process node节点会周期性地从这些 FIFO 中出队(这种设计和HQOS功能框架有点像,每个worker单独创建一个fifo队列,避免锁竞争)。如果 FIFO 已满,工作线程会丢弃样本,以确保:(a)主线程不会因样本过多而过载;(b)即使在高负载下,单个工作线程和接口也不会挤占其他接口和工作线程的资源。
你可以在运行时更改采样率,但需要注意,这是一个全局变量,适用于所有工作线程,而不是特定接口。这意味着:
关键在于,每 N 个数据包中将有一个被选中进行采样。大概处理逻辑如下:
如果当前工作线程中处理的样本过多,则丢弃该样本,并增加错误计数器。这可以防止主线程因过多样本而受到影响。
本文只是简单简单介绍了一下sFlow插件的基本情况和实现架构图,应该会对基于vpp定制化开发一些高性能监控功能有一定的借鉴意义。后续我们将搭建环境,从源码来分析具体实现细节,感兴趣可以持续关注此公众号。
本文分享自 DPDK VPP源码分析 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!