数据重删和压缩技术的应用

1、 数据重删和压缩技术的应用架构师技术联盟 微信号 ICT_Architect功能介绍 分析和交流行业最前沿技术，分享云计算、存储、服务器、数据中心、网络、软件定义和虚拟化等相关知识，旨在知识交流、开放共享和共同进步。 重删和压缩技术是最有效节约存储空间的热门技术，目前普遍应用在主存、闪存、备份软件和数据传输软件中，但数据重删和压缩技术区别是什么，在主存储和闪存中是如何实现的？这就是今天需要我们一起探讨、解答的问题。 下面的内容将会革命性和创造性的改变你原来为了腾出多余空间，而费尽周折手工操作的方式。重删压缩技术区别和联系 数据重删一般采用Hash算法，根据块计算出Hash值，根据Hash值得重

2、复情况判断是否有重复数据。而数据压缩是一种字节级的数据缩减技术，其思想是采用编码技术，常用的如Huffman编码等，将较长的数据用较短的、经过编码的格式来表示，以此达到减少数据大小的目。 从效果上来看，可以认为重复数据删除是一种基于“数据块”的压缩，而数据压缩是一种基于“字节”的重复数据删除。从应用上来看，重删和压缩通常会配合起来一起使用。如在备份场景中，为了提高数据的缩减效率，在数据经过重删之后会对唯一数据块再执行一次压缩。这样，数据的缩减效果就是重删和压缩效果的叠加。主存储重删和压缩技术 为了更好的讨论主存储系统的重删和压缩技术，我们引入备份存储为参照来进行分析。重删和压缩功能在备份场景上

3、的应用中首先取得了成功，这个需求就被自然而然地迁移到了主存储场景上。 但因为主存储场景中的IO模型与备份场景中的IO模型存在非常明显的差异，这就导致了主存储场景和备份场景中，重删在架构上存在比较大的区别。下面将从几个不同的方面来说明这些差异对重删架构带来的影响。 IO大小不同 在备份场景中，备份任务通常都是以备份流的形式进入系统，这是的IO都是比较大的，一般都是MB级别；但在主存储场景中，以虚拟桌面(Virtual Desktop Infrasture, VDI)为例，IO大小通常都是几十KB，以832KB的IO为主。 IO模式不同 在备份场景中，备份任务都是以顺序写、顺序读为主；但在主存储场

4、景中，存在较大比例的随机读写，VDI场景中就存在大概约30%的随机读写。此外，备份场景中，对已经备份的数据，基本上没有覆盖写操作，但在主存储场景中，覆盖写比例比较大，笔者所在团队曾经做过针对VDI场景下的覆盖写统计，在VDI场景下，运行时大约90%的IO存在覆盖写。 性能要求不同 在备份场景中，系统追求的是高带宽，需要在更短的时间窗口内完成备份任务，对时延的要求相对不高；但在主存储场景，系统追求高IOPS和低时延，如果在IO的下盘路径中增加重删的处理，则可能会增大IO的响应时延。 特性要求不同 在备份场景中，重删是一个必备特性；但在主存储场景中，重删，包括压缩是一个可选特性。相应的，定位不同，

5、系统分配给重删的计算资源、内存资源等也就会不同。在备份场景中，绝大部分的计算资源都分配给重删进行分块和压缩，但在主存储场景中，重删会更多的让渡于其他特性，这样分配给重删的资源注定很有限。 基于以上的差异，发现主存储场景和备份场景中重删方案存在如下明显差异，下面我们站在重删技术上，来分析下重删技术在不同场景的差异。 重删时刻的不同 为了避免对生产环境的性能产生影响，大部分厂商都会采用后处理的方式进行重删，这和备份场景中的在线重删方式明显不同。 分块方式不同 由于在主存储场景中，IO通常较小，并且所操作的逻辑块地址LBA比较离散，不是严格连续的，所以不适合进行变长分块。变长分块在这种较大数据量、连

6、续的数据时可以发挥较好的分块效果，能将两次备份之间不同数据产生的影响降到最低，但这种效果的前提是可以用来切分的数据较多，并且需要较多的计算资源。 在主存储场景中，IO比较小，并且比较离散，如果为了实现变长重删，就需要将这些离散IO周围的数据补齐，如果这些待补齐的地址上没有被写过数据，则可以直接补0；如果是写过数据，则需要把这些数据读上来，补充完整之后再执行变长分块。同时，这些操作都要发生在写的IO流程中，将显著增加系统的读写压力。此外，由于主存储中，IO的覆盖写比例较高，如果都采用这样的方式，每次覆盖写都需要经历这些复杂的流程，同时还涉及到对原来已经写入的系统元数据的修改(如LUN的元数据)，

7、这些操作在主存储设备中，代价都是很大的，自然对系统性能影响可能也会比较明显。 查重方式不同 在备份设备中，因为数据具有较强的局部性，一般会采用抽样的方式，用少量甚至一个分块的指纹代表一个大块，通常这些大块都是MB规模。但在主存储场景中，IO的连续性不是很强，通常不会采用抽样，或者采用很少块组织起来进行抽样的方式。主存储重删实现方式 EMC的VNX/VNX2以及Netapp的FAS系列都支持重删(后处理的定长)功能，这里以Netapp的FAS系列中的重删压缩为例进行简单的介绍。数据按照4KB进行实时分块并计算指纹，并将指纹保存到更改日志文件中，数据同时写入磁盘中。如果用户配置了在线压缩功能，则数

8、据在下盘之前将会被先压缩。根据后处理设置的系统空闲时间，当到达指定的时刻时，系统启动重删功能，此时将对更改日志文件中的指纹进行排序，并根据更改日志文件生成指纹数据库。根据指纹库进行比对查重。对指纹相同的数据块执行逐字节比对，如果数据块完全相同，则执行后续的操作，否则不做处理。对于重复的块依次执行如下操作。更改数据块指针、更改数据块引用计数、释放数据块存储空间，对重复块不做任何处理。 Netapp的FAS既可以支持配置成在线压缩，也可以配置成后处理压缩，也可以配置成在线压缩和后处理压缩同时开启。闪存的重删和压缩技术 在全闪存领域，重删和压缩的使用呈现出一片欣欣向荣的景象。重删从传统阵列中的一个可

9、选特性，变成全闪存阵列中的一个必备和门槛特性。在全闪存阵列中，SSD磁盘中的Flash颗粒有寿命的限制，而重删特性的加入正好可以减少主机需要写入的次数和数据量，以此达到延长SSD的使用时间，保护用户投入价值。 既然闪存场景中，重删变的尤为重要，我们下面以EMC的XtremIO中的重删为基础，介绍重删在全闪存阵列中的实现方法。主机数据在进入存储系统时将被按照固定大小8KB进行分块，同时利用强Hash函数SHA1计算数据块的指纹。指纹按照对应的规则打散，在查重时，按照相同的规则，将指纹发送到对应的节点上进行查重，如果为新块，则将该新块发送到对应的节点上，操作成功之后返回主机写成功；如果是重复块，则

10、增加引用计数。目标节点接收到数据之后写入Cache中并进行压缩，当Cache中缓存的数据达到刷盘水位要求时，将数据按照指纹的分布规则写入对应的存储空间中。 XtremIO重删技术有几个主要特点：主机数据是在写入Cache之前完成重删压缩操作，为先重删后压缩。采用强Hash计算指纹。重删后的新数据按照数据的指纹，直接打散到对应的存储空间的单盘上进行保存，没有中间的全局的映射层。不进行全局的垃圾回收，依赖单盘自身的垃圾回收功能。 下面将以XtremIO和Purestorage为基础，介绍重删在全闪存阵列中的几类重要技术和常用方法。 在线重删 在全闪存中一定会采用在线的方式实现重删功能，包括压缩功能

11、。主要的因为还是SSD盘存在寿命限制。在第一部分介绍重删基础时已经说过，如果后处理，数据需要先写到磁盘上，在空闲时再将数据读上来进行重删，之后再写入存储空间中，这样相比在线处理增加了一次写操作，也就增加了SSD盘的磨损，缩短了其使用寿命。所以，全闪存阵列中采用在线的方式实现重删压缩，在这一点上，所有的友商都是一致的。 分块大小 XtremIO在推出的初期，使用的分块大小为4KB，当其下一代产品推出时，XtremIO顶着被人诟病的压力，采用破坏性升级的方式将分块大小强行升级为8KB，也反映出Xtremio在分块大小上的演变过程。同时，Purestoarge也号称支持512B32KB的“变长”重删

12、，但实质上这里的变长重删并不是备份领域中的字节级的变长，而是4KB整数倍的变长。另外，HP在其3PAR中提出使用16KB的分块。可见，在重删分块大小上各个厂商都有自己的想法。 元数据的管理 在XtremIO中，系统采用两阶段元数据的方式实现重删，第一阶段是LBA到指纹的映射关系；第二阶段是指纹到物理块地址之间的映射关系。 弱Hash加逐字节对比 XtremIO的重删采用了强Hash函数计算指纹，查重的过程中只比较指纹而不进行逐字节对比；但在Purestorage的实现中，它使用了弱Hash并采用了逐字节对比的方式实现重删。 这里简单解释一下强Hash和弱Hash的区别。强弱Hash是一个相对的

13、概念，强Hash是指发生Hash冲突的概率非常低(Hash冲突是指数据不同但计算出的Hash值相同)，弱Hash是指发生Hash冲突的概率相对要高一些，但也不是绝对的高。 在Purestorage中，数据先经过弱Hash进行比较，如果弱Hash不同，则数据一定不同；弱Hash相同，则需要将对应的数据读上来进行逐字节对比，以此来确认数据是否真的是相同的。除Purestorage之外，HP的3PAR也使用了弱Hash加逐字节对比的方法实现重删。 Scale-out与Scale-up 在全闪存阵列中，XtremIO可以实现双控级的Scale-out，并宣称能达到线性的性能提升，目前最多支持8个双控也就是16控的扩展，并实现全局的重删。但与XtremIO不同，Purestorage依然在双控的方向上耕耘，只支持Scal