摘要：上一期我们谈到了重删压缩的基本概念以及在存储系统中的价值，但是实现重删压缩是一个任重而道远的工作，很多厂商在这条路上没有熬到黎明。很多国际大厂也在上面载过跟头。那么实现重删压缩到底有哪些难度，又会对存储架构带来什么冲击。本期我们浅浅的谈一下。
更多内容，请关注公众号“new_storage”
从几则八卦看重删压缩实现难度
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可能会很快推出，但是估计重删比很有限，因为每个重删的作用域太小了。
其他厂商既然能够在主流全闪存市场分一杯羹，也有其独特的实现，我们下一篇再来讨论其他厂商的实现方式。