浅谈存储重删压缩之三netapp的逆袭

Posted 2020-10-22

浅谈存储重删压缩之三netapp的优化

摘要：上一期我们回顾了HDS硬盘压缩以及EMC在老架构上改进的设计，本期我们主要来看看命运多舛的Netapp如何更新自己的重删压缩。

谢谢大家的关注和支持，欢迎转载，转载请注明出处。

欢迎大家关注“new_storage”

 

Netapp重删压缩的历史

Netapp实现重删压缩很早，造2010年之前，netapp的NAS设备已经具备了重删压缩的能力。当时全球市场一直将重心放在HDD存储，而netapp实现重删压缩也很能理解，当时有很多温冷数据存储在netapp上，所以重删压缩是一个增加附加值的功能。但是很遗憾，这个功能并没有帮助netapp获取多少市场，而是统一存储这种架构在2010~2014年在全球大行其到，成为中端存储的标志倒是让人非常意外。

Netapp ONTAP 8.3之前的实现

                   

Netapp老的压缩实现是以压缩率优先的原则，因此压缩的压缩作用域设置为32KB，然后会进行压缩，如果压缩率低于25%也就是压缩出来的块依然大于24K就会放弃压缩。压缩最小可以压缩到4kB。对于不可压缩的块在后台压缩中进行继续压缩。对于小于32KB的IO，在线压缩会跳过他。

同时，netapp支持后处理的压缩。

对于重删的实现，netapp老版本只支持后重删，只是会在数据实时下盘时候就进行了指纹的计算，然后加入到记录指纹的一个日志文件。

等到后台重删被触发后则启动重删流程。然后执行跟传统重删一样的操作，指纹查找，有重复则进行逐字节比对，然后进行数据删除的操作。

Netapp老版本限制较多：

1，         压缩必须和重删一起使用，不能单独使用压缩功能

2，         只有使用了后压缩以及重删，才能开启在线压缩。

3，         同一台存储内，最多8个卷同时开启重删或者压缩

从这三个限制可以看出，netapp对于压缩重删的性能是非常保守的。而且在白皮书中也指出了这一点。

Netapp指出，在1个LUN重删时对性能影响《15%，但是8个LUN同时开启重删时影响则为15%~50%。

对于在线处理的压缩而言，如果系统负载在50%以下，开启压缩CPU利用率会上升约20%，对于大于50%以上业务压力的系统，netapp不建议使用在线压缩功能。

      后压缩和后重删机制对于SSD为主的全闪存存储来说不知道是否会带来过量的写入而导致SSD快速磨穿，这个问题还有待验证。

新版本快速优化

Netapp新版本主要的优化在压缩，抛弃了原有的压缩架构，因为原有的压缩主要用于文件系统，压缩域比较大，需要多个数据块进行合并压缩。合并压缩意味着每个快需要等待多个快合并在一起才能去压缩。

Netapp的san存储块大小是4KB，因此在新版本netapp压缩以4KB为单位，压缩成1K~4KB的小块。压缩效果还是有个预判机制，压缩率》50%才会压缩，否则不压缩。这个改动使得压缩效率提升了很多，但是同样的压缩率很低。

为了改善压缩率，netapp在该版本新增了一个功能，国内叫做压紧。将多个小块合并成一个4KB的块来存储。这个操作很有效，毕竟每个快的元数据只存储一个地址和偏移量，压紧不会增加任何元数据的开销，只是需要刷新一下原来的元数据即可。

这么简单的一个操作解决了大量空洞的问题，同时还提升了资源利用率。但是由于netapp压缩机制本身简化带来的压缩率下降（压缩域太小），所以netapp本身的压缩时牺牲了压缩率，提升了性能。可取之处就是压紧的处理。压紧过程还会处理一些之前没有做压缩处理的块，因此压紧还有一定性能开销，按照netapp的说法大概在5%左右。

Netapp的重删改动比较大，主要在于元数据指纹的存储机制以及改成了支持在线处理和后处理两种。

重删的粒度和原来一样还是4KB，但是存储机制已经变化了。

1，                所有指纹数据仅仅在缓存中存储一份，不做持久化，不需要考虑镜像什么的，在重启和升级过程中，指纹会被丢弃。这么做的原因就是相对于牺牲性能，我们宁愿牺牲重删率。那么我们就可以大幅降低因为指纹和盘的交互以及指纹持久化带来的内存开销，镜像开销等等。所以对于希望实现重删的国产厂商，我的建议是：重删的指纹不需要持久化，不需要镜像，如果是升级或者重启，建议还是存到硬盘上一份，但是不需要实时下盘。只需要在掉电和重启等操作时下盘即可。Netapp当前并未做重启升级以及掉电时候的指纹保护，我觉得这一点并不好。

2，                指纹按照热度进行淘汰，一旦指纹空间满了，就采用最简单的LRU算法进行淘汰。这也是一个保持指纹查找高效的方式，可以保证指纹全内存。这个也是值得学习的。

当然上述两个对于指纹的改造其实还有一个提前需要解耦的东西。很多厂商在实现重删的时候讲引用计数和指纹在一起存储，就需要进行解耦才能更好的实现。

这也让我们需要反思后续的数据结构设计需要将数据按照持久化级别进行分离，而不是按照数据的关联性进行合并。随时保持架构的灵活性。

当然，netapp其实可以做的再好一点，比如说将指纹表最热部分缓存一份到L1 Cache,并且改变数据结构为hash，对性能的影响会更小，其他的全量指纹则放在L2 Cache再用B树存储来节省空间。这样可以让重删更加灵活，如果业务压力大则只在L1 Cache进行查找。

题外话，当前客户对于重删还是有很多顾虑，很多人认为重删会导致数据丢失的风险。所以我们不可避免的都需要做逐字节比对，在这种情况下，netapp给我们做了一个很好的表率，那就是我们使用弱哈希，节省指纹表空间，扩大指纹数。这个也是可取之处。使用强哈希不做比对的厂商未来根本没法在市场上被接受。

Netapp全闪存卷土重来

在2015年之前在SAN领域netapp就是一个落后者，在全市场领域更完全是个失败者。但是通过2016/2017年的持续优化，竟然翻身了，非常让人不可思议。

其实他只做对了一件事，将压缩重删实现了，同时开启后性能下降在可控范围内（5%~20%）。就这么一条，就让netapp如今在全闪存市场逆势上扬。

所以重删压缩不做或者做不好，未来将会走向泥潭。

重删压缩是个锦上添花的东西，绝对不是雪中送碳。IT市场的写标能力是技术的天敌。此外技术的市场化也是需要很长的孕育，至少在中国区接受重删压缩就可以少配容量的事情还需要很长时间。

谢谢大家的关注和支持，欢迎转载，转载请注明出处。

欢迎大家关注“new_storage”