谈谈存储重删压缩的实现-EMC,HDS篇

摘要：上一期咱们谈到了重删压缩的基本概念以及在存储系统中的价值，可是实现重删压缩是一个任重而道远的工做，不少厂商在这条路上没有熬到黎明。不少国际大厂也在上面载过跟头。那么实现重删压缩到底有哪些难度，又会对存储架构带来什么冲击。本期咱们浅浅的谈一下。

更多内容，请关注公众号“new_storage”

1. 从几则八卦看重删压缩实现难度

 

Netapp：有一款全闪存叫作FlashRay，计划支持重删压缩，并且是变长重删，netapp历时4年开发，结果却迟迟没法Ga，最终整个产品被裁，包括产品总裁也扫地出门跳槽到了Pure Storage。无奈之下，netapp只好本身在FAS上进行改造。FlashRay也成了一个活在PPT里面的产品。

 

Cisco:思科想拥有整个数据中心架构人尽可知，存储一直是思科最大的缺陷。2013年，全闪存最火的年代，思科终于下重手4.15亿美金收购Whiptail，可是很快2年后，因为大量的技术问题思科放弃了这款产品也退出了存储领域。

 

EMC：xtremIo做为2013年EMC巨资收购的产品如今已经即将销声匿迹，在EMC都是整盘存储计划里面，它已经被边缘化，EMC VMAX和Unity正在补齐重删压缩快速的崛起。

从上述几个例子能够看出，实现重删压缩同时保障性能以及稳定性有多难。仔细数一下业界的starup全闪存公司，可以作到可靠性、性能、效率三者都有所保障的只有pure一家，其他都是存储大厂。

一个全闪存只要重删压缩实现了、性能冲击小、可靠性有保证就是成功了，不能去奢求太多。这就是我对过去十年全闪存市场的认知。

重删压缩实现的难度

重删压缩实现难度很大，主要不是因为重删压缩算法的问题，而是如何最小化性能损失，最大化数据缩减比的问题。时至今日，咱们看到HDS、HPE的重删性能冲击超过50%，EMC高端全闪存至今不具有重删能力，足可看出难度。

因为重删压缩带来的数据长度是可变的，甚至会被重删掉，对架构的冲击不言而喻。之前以COW架构起家的EMC/HPE/HDS纷纷卡在这道坎上。

咱们回顾一下重删压缩的几个问题

1， ROW架构相对于COW架构带来的高级软件移植、集群管理等

2， 压缩后变长的数据组合与分配的问题

3， 重删压缩带来的元数据空间和指纹空间增大，从而影响性能

4， 垃圾回收问题

不用ROW，照样实如今线压缩，硬盘实现压缩，HDS独一家

在咱们闷头寻找解决方案去实现一个新的存储软件架构来实现压缩重删的时候，咱们能够质疑一下咱们的命题。不实现ROW架构是否能够实现压缩重删。

答案是确定的。

好比说，咱们将咱们的压缩功能在盘上实现。这就是HDS的应对之道。

 

HDS 虽然出售了硬盘业务，可是日立硬盘的部分技术仍是继承了下来，2015年推出的FMD DC2中实现了在线压缩功能。可是因为压缩后总共能够对上层提供的容量是不肯定的，所以HDS作了以下底层改造。

1， 使用FMD的RAID组只能用于Pool一级，不能直接做为LUN对主机提供业务。用户来设定数据缩减比，来决定POOL能够对外呈现的容量。通常这个比例为1.5~2:1.

 

2， 必须实时监控数据的使用比例，一旦超出某个阈值就会进行告警。HDS默认是70%进行警告，80%启动耗尽预警，90%启动即将耗尽紧急预警。三级警告机制，催促客户进行扩容或者删除部分数据。

 

HDS的实现很是简洁明了，对原有的架构几乎 任何冲击，带来的性能影响也很是小。在最新一代的VSP F800存储上，咱们能够看到他的表现，开启压缩后性能降低不超过5%。真实一个很是天才的实现方案。

硬件加速减小性能损耗

HDS这种直接从盘上解决问题的方案不是谁家均可以模仿，毕竟没家存储厂商的能力都不同，不少厂商都没有硬件能力，更别说本身造盘了。

  

HPE的硬件实力也是杠杠的，既然ROW我实现的比较差，我能够用我赖以成名的ASIC来帮帮忙，HPE就采用了ASIC来进行了重删数据计算和指纹比对。不过因为ROW这个课题太难，即便用了ASIC HPE表现也是很艰难。

IBM收购TMS后苦于他没有重删压缩功能，采用本身的SVC存储虚拟化网关做为机头来组合成的产品Flashsystem V9000,可是很遗憾SVC的压缩继承自HDD时代，IBM的SVC CPU能力也有限，开启压缩后性能降低极大。IBM所以加入了压缩加速卡，大幅减小了CPU损耗。

EMC VMAX秉承的理念一直是老树发新芽，将原来用于远程复制链路传输时压缩的硬件加速卡用于当前的存储数据压缩，也算发挥余热了。

EMC VMAX软件巧手设计

EMC VMAX的传统资源分配方案是基于HyperVolume,在十几年前已经实现了RAID2.0架构，良好数据管理结构为不少功能实现打好了良好的架构基础。

 

先将物理硬盘切成多个小disk，称之为Hyper Volumes，而后再用Hyper Volumes组成RAID，建立主机可见的LUN。

 

在传统VMAX上，全部的LUN默认的track size都是128KB，就是说最小的资源分配单元是128KB。

在压缩需求须要实现后，EMC只作了一个很小的改动就搞定了。

1， 将之前的一个盘切成16个hyper volume的模式作了改变，改为了切分为64个，而后针对每一个hypervolume组设置不一样的track size，16K、32K\48K一直到72K不等，每一个不一样的track size默认准备一个hypervolume的LUN组，64K默认准备2个，其余的都设置为128KB。

2， 因为软件架构设计的下盘IO大小为128K,因此数据在压缩后只会比128k小，从8KB到128K不等，大多数都是在72K如下。按照压缩后的块大小挑选对应的hypervolume组进行下盘。若是某个规格的hypervolume用完了，就从默认的剩余hypervolume组里面取一个出来，将track size改为对应的块大小便可。

 

这个两个动做执行后，超级完美的避免了压缩后块大小不一致带来的数据拼接问题，由于数据拼接带来的性能损耗在容量增加之后很是可怕，可能会带来50%以上的额外cpu消耗和时延成倍的增长。

到此还不算完，EMC更精巧的还在后面。因为VMAX主要承载客户关键业务，性能的稳定性是第一须要保障的，所以EMC推出了Activity Based Compression (ABC) 机制。简单来讲就是热数据不压缩，直接下盘，直接读取，不用通过压缩和解压缩流程。这个思路咱们你们都能想到，可是EMC不同得是，将本身分层存储（FAST）的热点计算功能直接完彻底全的继承了过来，根本不用添加额外的大的改动。

 

业务开始运行的时候全部数据都被压缩，在运行一段时间后，启动热点识别和标记热点，今后以后凡是热数据的写入和读取将不会通过压缩和解压缩流程。同时按照最著名的28原则，热数据量被强制锁定为LUN空间的20%。对总体的数据缩减率没有太大的影响。这个就意味着在很长一段时间内大部分的数据读写都是不压缩的。性能获得了大大的保障。根据EMC的最佳实践显示，开启压缩在数据库场景IOPS降低大概只有10%左右，CPU利用率也仅仅多耗了7%，固然CPU消耗主要是因为硬件压缩的卸载缘由。

 

因为EMC的压缩热点识别须要一个过程，而且热数据被设定为LUN的20%，因此使用EMC的压缩功能压缩率会从一开始持续的降低。由于一开始全部数据都会被压缩，后续不少数据被标记为热数据，不断地从压缩区释放出来变成非压缩数据。因此买了EMC VMAX存储的客户要作好压缩率持续降低的苦。

 

不过总的来讲EMC的架构师很是的牛逼，在不推翻原有架构的状况下，快速简单的实现了一个性能良好，压缩比不错的在线压缩功能，而且规避了大量压缩的性能陷阱（容量增加、数据合并），是很值得咱们中国存储厂商学习的。

可是EMC的方案也有缺点，那就是实现全局重删很差实现，由于当前数据按照压缩后的数据块大小进行分离，后续若是想实现全局重删则须要进行频繁的数据搬移。若是仅仅实现LUN级别的重删，EMC可能会很快推出，可是估计重删比颇有限，由于每一个重删的做用域过小了。

其余厂商既然可以在主流全闪存市场分一杯羹，也有其独特的实现，咱们下一篇再来讨论其余厂商的实现方式。