Towards In-network Acceleration of Erasure Coding（SOSR2020）参考计算分流

什么网内
switch

怎么网内加速传输的过程中加速是否会减少数据量的传输
减少了数据量的传输，在switch上做了计算
io占用变少了
修复率增高
中间出现问题的时候没有中断流量的传输

加速到什么程度，解决的是吞吐量的problem
跟流水线比了吗
没有跟流水线比较

在分布式存储系统中，擦除编码（EC）是一项关键技术，可实现比数据复制更低的存储开销并具有更高的容错能力。 EC可以通过从幸存的计算机中下载奇偶校验数据来重建丢失的数据。
存在的问题：EC请求端IO多路复用，导致数据重建速度大大降低。
在本文中，我们介绍了NetEC，这是一种新颖的网络内加速系统，可将EC完全卸载到可编程switch ASIC。
NetEC通过switch上的下载流聚合来防止对网络I / O进行复用，从而显着提高了重建速度。
NetEC解决了三个关键挑战：

• 复杂EC操作的计算分流
  计算分流。 RS代码依赖于Galois字段（GF）算术（请参阅§2和§4.1）。 为了将GF计算完全转移到表达能力较低的switch ASIC，我们设计了一种RS code engine，将GF矢量点积—>表查找和部分XOR和更新。
  所有到达的数据包都对提取的有效载荷执行GF乘法，并更新缓冲的部分XOR和。 重建完成后，码结果封装为有效载荷。
  （分片计算）
  结合流水线，把流水线的工作+上网络中计算（利用了谁的计算能力）
  可以做个比较

• 多个下载流的速率同步

• 深度有效负载检查/组装。

我们在硬件可编程交换机上实施NetEC。评估显示，与HDFS-EC相比，NetEC显着提高了2.7x-9.0x的重建速度，并消除了CPU开销，并且开关内存使用率较低。

introduction

许多大型分布式存储系统正在过渡到擦除编码（EC）[1、10、11]，以提供高可用性，并且其存储开销比数据复制要低得多。里德-所罗门（RS）码[23]是EC最受欢迎的选择之一。 RS（k，r）码将k个数据单位编码为r个奇偶校验单位。 RS（k，r）从（k + r）个数据单位中的任何k个重建原始k个单位，因此可以容忍任何r个故障。例如，RS（10,4）可以容忍任何情况。许多大型分布式存储系统正在过渡到擦除编码（EC）[1、10、11]，以提供高可用性，并且存储开销比数据复制要低得多。里德-所罗门（RS）码[23]是EC最受欢迎的选择之一。 RS（k，r）码将k个数据单位编码为r个奇偶校验单位。 RS（k，r）从（k + r）个数据单位中的任何k个重建原始k个单位，因此可以容忍任何r个故障。例如，RS（10,4）可以承受1.4倍的存储成本来承受任何4次故障，而基于复制的系统则需要3倍的存储成本才能达到相似的可用性。但是，正如许多先前的文献[11、24、30]所揭示的那样，EC在存储成本与额外的性能开销之间进行权衡。特别是，低重建率是最重要的问题之一，受到学术界和工业界的高度重视[11，21，24，30]。
重建速度

低重建率背后的根本问题是
proportionate goodup。
这在所有基于终端主机的当前系统中都是不可避免的。
重建RS（k，r）中的一个数据块需要从其他节点下载k个块。
NIC网络接口控制

接收器侧的可用网络I / O（通常是NIC容量）通过k个下载数据流进行多路复用，因此有效的重建吞吐量不大于可用网络I / O的1 / k。
如图1a所示，三个彩色数据流共享可用的NIC带宽，实际的重建吞吐量（磁盘写入速度）仅为网络I / O的三分之一。
只要在包括FPGA或SmartNIC在内的终端主机上进行处理，就无法完全解决比例吞吐量问题，因为它们需要NIC才能连接到网络。
解决吞吐量问题
因此，我们诉诸于网络内计算范例来解决成比例的吞吐问题。 在可编程交换机上，数据流到达不同的接口，进行汇总并转发到另一个接口。 没有共享带宽。 在图1b中，计算（灰色框）从CPU移到了网络，重建的数据（黑色）能够充分利用NIC上可用的全部带宽，因此我们可以获得更高的磁盘写入率。 与图1a相比，较宽的黑线表示重构速度有所提高。 网络内计算的另一个好处是可以减轻繁重的工作量
EC的CPU利用率。 在重建期间，CPU必须检查所有k个下载流中的每个字节。 存储设备浪费了许多CPU内核进行重建，从而导致高昂的资本支出[12]。 网络内计算完全消除了额外的CPU使用量（请参阅第6.3节）。
实验
我们使用9台服务器构建存储集群，每台服务器具有两个12核Xeon E5-2650v3 CPU，64GB内存，40Gbps NIC，1TB HDD和400GB SSD。 服务器直接与运行NetEC和标准L2转发模块的Barefoot Tofino可编程交换机连接。 我们建立了三个测试平台：RS（3,2），RS（6,3）和复制，并测量NetEC重建率，资源使用率和其他基准。

NetEC显着提高了重建速率并减少了链路使用量。 在图3中，每个条形表示总网络吞吐量或重建速率。
我们首先在复制测试平台上运行NetEC。 所有流量穿越整个NetEC处理管道。 图3a和图3b中的左侧条显示了NetEC的处理产生的吞吐量开销可忽略不计。
为什么可以忽略？

请注意，由于网络和NetEC标头，重建速率略低于网络吞吐量。
图3a显示了HDD和1GbE设置的结果。在RS（3,2）（中间的条）中，HDFS-EC消耗1.0 Gb / s的网络吞吐量，但仅实现0.31Gb / s的重建吞吐量，因为NIC容量由三个下载流复用。 NetEC消耗0.9 Gb / s的网络吞吐量，并达到0.8 Gb / s的重建吞吐量，与HDFS-EC相比提高了2.7倍。在RS（6,3）中，由于NIC被更多的下载流所分割，因此改进甚至更高（9.0x）。图3b显示了SSD和40GbE设置的结果，其中
Java套接字I / O成为瓶颈。一个Java socket的吞吐量不能超过4 Gbps，而多个套接字可以实现更大的聚合吞吐量。 NetEC现在通过分割寄存器使用量来支持两个并发的重构流程，达到8 Gb / s的重构吞吐量（图3b中的中和右图）。它已经以9.3 Gb / s的网络使用率饱和了我们SSD的写入速度（1 GB / s）。另一方面，HDFS-EC利用多个socket 进行下载，并实现了4Gb / s的重构吞吐量。传统的吞吐量明显的高于netec。

CPU利用率。我们启用HDFS-EC中的Intel ISA-L [4]以实现更高的重建速率，并且不限制HDFS的CPU内核使用率，因此它可以抓取尽可能多的内核，从而使利用率超过100％。图3c显示了在HDD上以其最高写入速度（180 MB / s）进行重建时的CPU利用率。 CPU利用率可以高达350％，并且在重建SSD时甚至可以更高。请注意，复制还为事务性操作带来了适度的CPU开销[16]，但是NetEC消除了EC的其他计算开销。
动态内存使用率。我们通过定期拉出记录最近到达的数据包和最新的左（汇总）数据包的序列号的数据平面元数据来测量单个重建任务的缓冲区使用情况。
这两个值之间的差异反映了当前的实际缓冲区消耗。图4a展示了正常情况下（低于50KB）switch memory 的消耗很低，而可编程开关ASIC通常具有50MB至100MB的SRAM存储器。速率限制是在时间3s引入的，我们发现缓冲区使用率略有增加，然后下降。当速率受到限制时，发送方发送的数据要高于接收方可以接收的数据，因此传输中的数据包会增加，从而导致缓冲区使用率增加。一段时间后，平均缓冲区使用率会降低，因为降低的速率会导致链路的BDP较小。
速率控制。 为了测量速率控制效果，我们使用Linux tc来调整幸存节点之一的可用输入带宽。 评估是在1GbE HDD设置下进行的。 图4b显示，当一个节点进行速率限制时，其他节点几乎立即做出响应。 在大约19秒的速率限制后，所有节点的发送速率保持相等。 数据包丢失。 对于数据包丢失，我们将复制用作基准，并使用相同的最终主机TCP设置将NetEC与之进行比较。 我们手动引入两次三秒钟的随机数据包丢失，丢失百分比不同。 如图4c所示，面对数据包丢失，我们看到NetEC的行为与复制类似。 由于数据包丢失率恒定，因此吞吐量降低了，但流量没有.