IBM存储重删压缩技术之三 从落后到领先

题记：上文我们谈到了IBM V系列全闪存压缩实现后性能不太好的情况，其实他还有一个缺点就是不支持重删，在虚拟化、云化数据中心里面很受制，被XtremIO、Pure等场景持续攻击。终于IBM进行新的实现，来应对这种变化。我们这篇文章就来看看IBM的反击之道。

解决方案宗师又出奇招

2016年4月份，IBM一口气发布了三款全闪存产品，其中我最关心的是IBMFlashsystem A9000/A9000R。

这两款产品是基于IBM收购的软件定义存储XIV的软件架构，整合Flashsystem构造而来。就是因为是两款产品构造而来，所以实现的特别快，不然单独开发一个独立架构的产品，估计不知道等到何年何月。

A9000系列保持了和V9000系列一致的方式，为了对外呈现为一个产品而不是多个产品的组合，用了一个大铁罩子罩起来。相对于V9000时代需要在flashsystem存储外额外加上两个服务器，A9000需要额外加上三个服务器。称之为Grid Controller。

服务器的配置也非常豪华（2颗2650 V4的CPU以及384GB缓存以及2块400Gb SSD以及2块SAS盘），这个单控制器的配置能力已经超越了XtremIO的单控配置了。其中SSD用于掉电内存保护，SAS盘用于安装操作系统。

我比较奇怪的是为什么不用两块SSD同时装操作系统也做掉电保护刷盘呢？

当然，他还提供了一个低配的选型，不过低配估计性能也会有所下降。最终A9000最大配置可以对外提供1.1TB的缓存，以及12块闪存盘。这个让人很不爽，我整了这么大的规模，结果最后只有12块盘的容量。

IBM A9000R就是一个可以扩展的A9000，由于可以扩展，因此前端的服务器资源利用率比之前A9000高一点，可以2个节点对一个存储节点。多个节点之间用InfiniBand进行互联。

他的扩展是一个线性的过程，一旦达到一个柜子也就到了扩张的极限，这也是XIV硬件设计的原则，在A9000也得到了保持。最终就是一个整柜就是一套存储。

初始配置为4个Gird+2个Flashsystem，然后按照2 Gird+1个Flashsystem的方式进行扩展，扩展到12个Grid+6个flashsystem就结束。

IBM A系列的重删压缩压缩实现

A系列相对于上一个版本的V系列最大的变化有两个：

1，硬件整个更高了，更大了

2，实现了软件重删功能

在A9000里面，数据缩减的流程如下图所示：

Pattern matching and removal（特征匹配重删）：我理解就是一个最基本的全零或者全1的数据重删，类似于以前thin中实现的一样，当然不排除IBM有更高级的实现，但是IBM在这里也是语焉不详，我个人理解应该没有什么太过特殊的实现，仅仅是个针对全闪存技术的市场包装。

IBM说了可以针对这个特征进行设置，我个人理解未来这个东西还是比较有用的，可以根据典型的业务特征进行设置，比如说Office里面重复率最多的数据块、数据库里面重复率高的数据块、虚拟化场景等，可以未来随着业务积累以及现在各种的学习机制，提升重删的效率。不过就是看IBM自己的特征库更新的计划以及方式，如果是一个机器学习的程序在后台，通过对全球的销售设备数据指纹进行统计和分类，然后再去刷新这个知名指纹库还是非常有效的。

Data deduplication：IBM的数据在第一步特征匹配的时候就会进行指纹计算，如果第一步并不是一个特殊数据，就会进入数据重删环节。IBM的数据指纹全部在内存中进行存储，这受益于IBM增配了这么多高配的服务器。

数据一旦被查找到重删，整个数据结构就会发生变化，数据地址会被删除，而附加了一个独立的数据索引hash，并且这个索引指向数据的hash存储的地址。

数据的hash全部存储在内存中，使用一个独立的结构来存储，称之为“端（segment）”，每个段里面可以包含一些数据hash，也可以包含一个到其他段的hash引用。段里面也存储其他引用他hash值得其他段的列表。每个段都独立的分配在一个控制器里面，因此在进行数据检索匹配时会优先检索本地的段，一旦这个段中没有找到对应的数据，才会通过引用进行其他段的检索。

IBM的重删还有一个有别于其他厂商的方式就是他的匹配虽然也是按照8KB的定长进行重删匹配，但是它支持基于4kB对其的滑动检索，来提升重删率。如下图所示。

在处理完成重删后，会进入压缩流程，压缩流程和我们系列第一篇文章的分析一样，整个流程没有任何的变化，进行对应的压缩操作。

重删压缩的效果

由于A系列具备在线重删压缩的效果，并且采用大量的硬件来保障性能和处理过程对于性能的影响，因此效果是实现的非常不错。

宣传非常的激进。

我个人理解上述数据是一个中位值，linux的虚机达到9：1的重删压缩比也是很让人惊讶的，数据库4：1也是超出想象，大多数厂商其实都在2：1左右。VDI 48：1并不出奇，在全克隆场景下，可以很轻松的达到。

IBM针对不同场景，使用测试工作做了一组测试，当然这个并不是一个是用于所有场景的测试结果，但是对于评判和参考还是非常有意义的。国产厂商如果想判断自己和IBM之间的差距，可以采用同样的用例进行测试，大概就可以得到一个相对能力评估。

VDI场景缩减率

VDI场景下，重删是缩减率的利器，压缩仅能达到2：1左右，添加重删后缩减率快速提升，全克隆场景可以达到50：1。

VSI虚拟化场景

虚拟化场景下，跟虚拟化平台软件相关性比较大，不同的平台差异极大。KVM&window场景缩减率整体只有2：1，而KVM&linux场景可以达到10：1.

数据库场景

数据库场景如大家判断的一样，重删并没有任何左右，一般在数据库场景都不建议开启全闪存存储的重删压缩功能。压缩开启后在4~6：1

如何评估数据缩减率

为了更好的评估重删压缩，IBM也提供了重删压缩的评估工具，IBM data reductionestimator tool。当然IBM也建议大家先去EvaluatorGroup提供的web版评估工具上去了解数据缩减在不同场景下的预期效果。

超级乐观的Evaluator Group

Evaluator Group的数据缩减评估工具地址是

https://www.evaluatorgroup.com/data-reduction-estimator/。这个评估工具比较简单上手客户易操作，不需要任何验证。

场景化的缩减比非常高，应该是一个最理想状态可达的值。比如说数据库3：1，服务器虚拟化6：1，vdi 10：1，用户文件都能达到5：1.

使用这个工具可以生产一个简单的报告做的还是比较渲的，不过如果要基于这个做数据缩减评估，所有的数据缩减比建议都要重新设置，毕竟每家的实现都不一样。而且这里的值都是一个基于最佳算法的理想值，在存储这里很难实现。

比如说重删，最佳重删比一定是在变长重删场景才是最好的，但是出于性能考虑没有人愿意在自己的生产存储上贸然去实现变长重删。

IBM自己的评估流程

IBM之前的评估工具只能评估压缩场景，在A系列具备重删能力之后，工具也相应做了升级。

1，针对只适合压缩的场景，使用原有的流程，仅考虑压缩，比较高效。比如说DB场景

2，针对重删的场景，需要进行一个完整的扫描，耗时比较常，大概效率是单核8小时扫描1TB数据，并且支持并行扫描和限流。毕竟不能让扫描任务影响生产。

3，扫描完成后需要进入一个合并计算的过程

计算元数据需要占据的容量

对于缩减率低于25%的卷进行排除，建议不做数据缩减

最终得出一个靠谱的数据缩减率评估（IBM给出的误差是5%），同时呢还会列出不适合重删压缩的LUN.

总结

在推出A系列后，IBM算是正式补齐了压缩重删，在和业界主流厂商的竞争总不再处于劣势。性能和数据缩减比都在业界前列。

但是比较遗憾的是，IBM公司缩减硬件投资，导致无法单独开发一个存储系统而是采用组合的方式，用大量的硬件资源来抵消软件系统带来的开销，最终整个方案成本较高，在很多项目中其实无法满足客户的需求。

所以IBM的A系列也不见得是一个利器，顶多只能算是IBM的一个完整的产品，具备了所有能力，如果不做降成本的操作，这个方案将难以为继。

谢谢支持，欢迎大家转载，并注明出处。