FOSDEM 2023|向第三方分发多播频道:OSS 和虚拟化 SR-IOV 的案例研究

直播频道通常作为传输流通过 UDP 或 RTP 多播传送。通常情况下,此类流必须通过专用的 L2 以太网链路移交给第三方进行进一步处理或分发。实际上,为了确保网络隔离,需要在两个 VLAN 之间复制组播流(具有可选处理),这是由昂贵且专有的硬件设备(例如 DCM)执行的操作。本文将探索使用标准 PC 和 OSS(例如 DVBlast)的选项。为了更好的隔离,演讲者还将探索使用 Linux/KVM 的软件虚拟化和一些网卡的 SR-IOV 功能。

来源:FOSDEM 2023
主讲人:Christophe Massiot
内容整理:王寒

背景

我作为广播从业者有很长一段时间了,我创办了一家名为 easy tools 的公司,公司的目标之一就是分发线性频道,包括我们创造的和卫星接收的国外的或来自数据中心的频道,我们要将这些频道发送到世界各地或者发送到网络运营商那里。这样做的重点之一在于如何将多个频道分发给别人。

图片

我知道一个线性频道:UDP/RTP 组播的 MPEG-TS,通常把 7TS 包放在一个 UDP 帧里就结束了。关于如何扩展这种流,例如你在巴黎的数据中心购买了交叉连接,运营商可以提供你的流到你分发到地方。所以出于安全考虑,你会希望每个源的每个操作都有不同的 VLAN。所以问题的关键是你如何对一个多功能 VLAN 源进行切割到不同的目的地。

纯网络的方案

下图所示是一个基于交换机的纯网络解决方案。

图片

它有一个称为多播服务反射的功能,但不是非常泛用,因为很多交换机不适配,也不能处理一些复杂用例。例如有的供应商需要 RTP 有的不需要,而这种方案不能添加或删除 RTP,一些运营商还希望拥有特定的 pid、特定的服务 IDS、不同的服务名称等,这是做不到的。

广播方案

广播解决方案,最流行的是我们所说的 dcm。这是一个非常受欢迎的品牌,最初是由思科,现在是一家名为 Cinemedia 的公司。这是一种硬件服务,里面有电子设备。

图片

所有这些工作都可以转换,甚至可以运输,有很多功能,当然它也非常昂贵。

DVBlast

图片

我们有一个开源替代方案被称为 DVBlast,这实际上是我 15 年前可能会做的事情。我已经做了很多关于这个的讨论,但在这两种情况下也有帮助。最初它被编写为 dvb demax。所以如果你有一个卫星卡或 dtt 卡,你想得到一个转发器并将每个频道拆分为一个多播地址。这是 DVBlast 的最初目标。但实际上,使用 dash d 选项,您也可以从多播通道读取。在参数中,您还可以说出要读取它的接口的 IP 地址。所以基本上,它从特定的 VLAN 对象读取多重流。你可以选择打开或关闭 RTP,重定义 PID、SID、服务名称等。

图片

我想补充一点东西。您可能希望在一台服务器上运行数百个电视节目,但出于某种原因,我想进行一些虚拟化。为什么虚拟化?因为我有不同的客户,每个客户都有不同的频道,他们中的一些人在做成人内容,一些人在做儿童内容。也许我不想在同一台服务器上混合使用,且因为服务器价格很贵,我没有钱拥有多台服务器。因此,对于客户端隔离是必需的。此外,我的一些客户可以直接访问 vm,因为这是我销售的服务。所以再一次,我不希望他们看到流的潜在竞争对手。所以我用了 PROXMOX,基于 KVM 的发行版,它有非常好的前景。在 PROXMOX 中你将作为桥梁连接交换机和客户,还可以模拟网络。

图片

对于不连续问题,Virtio 重新排序数据包,UDP 数据包顺序无法保证,但媒体行业依赖于此。因为如果你没有 RTP,你绝对不可能重新排序你的 UDP 传输字符串。所以我必须找到一个解决方案。

图片

我发现第一个方案是使用另一个驱动程序。它也是虚拟系统的驱动程序设计。存在的问题是需要增加 30% 的 CPU 占用,这需要优化。因此需要探究其他的方案。

其中一个叫做 SR-IOV,这是一些网卡的功能,而不是所有的网络。而一些网络中的那个功能在正常安装中为网卡所拥有的主机。有某种由 virturizer 处理的软件开关。每个虚拟机有虚拟接口。在 SR-IOV 安装时,网卡将创建新的 PCI 设备,所以它是一个不同的 PCI 设备。对于这个 PCI 设备,英特尔上有一个名为 VT-d 的功能,您在 AMD 上拥有设备,允许您将 PCI 设备专用于虚拟机。这样做,虚拟机直接与 PCI 设备对话,而无需任何东西通过主机。

图片

在我的用例中,我使用了英特尔卡。但是,如果使用不同的卡片,可能会有所不同。并非所有卡片都具有相同的功能。所以使用 SR-IOV,需要主板、CPU、BIOS 和网卡的支持。配置、使用、工作流程如下图所示。

图片
图片

虽然看起来方便管理和创建,但是实际上投入使用还是有点早,如果达到上限需要重启 VM,目前看来还不实用。

第一个应变方法是将他们都放在混合模式下:

  • VM接收所有数据包
  • 提高CPU使用率
  • 增加网络适配器的负载
图片

另一个方案是 vlan_mirror:

  • 将所有流量从 VLAN 发送到 VM
  • 一个 VLAN 只能发送到一个 VM
  • 鼓励源的 VLAN 隔离
图片

第三种方案是 virtio:

  • 恢复到 virtio 进行接收
  • 网桥包括 IGMP 侦听以减少负载
  • RX 上无数据包反转
  • 如果不能使用 vlan_mirror,则没有其他解决方案

如果从另一个 VM 接收多播:

  • 使用 SR-IOV 发送的数据包不会回送到 vlan_mirro r或 virtio
  • 解决方法:将一个 VF 的所有出口流量镜像到另一个 V F的输入
图片

结论

如本案例研究所示,事实证明,将这些技术与多播一起使用是很困难的。

  • 虚拟化环境中的组播绝非易事。
  • 这是多年工作的总结,对生产有副作用。

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

发表回复

登录后才能评论