上次在分析重复数据删除分块流程的文章中，我们认为可变分块技术，也就是说根据数据的内容来分配块的边界，是相当好的技术。不过，随着重复数据删除不局限于备份设备（比如磁
上次在分析重复数据删除分块流程的文章中，我们认为可变分块技术，也就是说根据数据的内容来分配块的边界，是相当好的技术。不过，随着重复数据删除不局限于备份设备（比如磁带，或其他备份应用程序专用格式的数据），进入备份应用程序和主存储，固定分块重复数据删除的优势开始变得明显。
固定分块重复数据删除的主要优势在于占用较少的CPU资源。固定分块系统不需要CPU开销来检查数据并判断数据块的边界。它们只要将数据分解成数据块，就像其他文件系统那样。实际上，一些主存储重复数据删除，比如NetApp的产品，使用的正是底层文件系统的块。
较低的开销同时还意味着较低的延迟性。数据块边界的计算过程需要一些时间。虽然厂商们已经在尽量减少这个时间并声称这种时间开销是可以忽略的，但是这个过程和时间确实存在，对于主存储重复数据删除系统来说可能是个问题。
不过，对于备份应用程序来说，这问题要简单许多。备份应用程序只是将数据流发送给某处的一个磁带驱动器。由于它们只是向少数大型文件执行大型顺序写入请求，因此每个请求发生数毫秒的延迟对于它们来说还不会有什么大的影响。对于传统备份应用程序，比如NetBackup或Networker来说，吞吐量才是最重要的，延迟性的重要性低一些。
主存储应用程序，即使是简单的应用程序，比如托管用户的主目录，对延迟性也非常敏感。此外，主存储应用环境不是像备份应用程序那样将数据写入到少数大型文件，而是有数百万个各种大小的文件。由于每个文件都从一个新的数据块开始，因此数据插入或其他有可能带来块重整的修改只影响一个文件的数据。每个新文件都会重新调整流程。
基于软件的重复数据删除软件--尤其是那些在源服务器端进行重复数据删除操作的应用程序，比如Avamar、PureDisk或Asigra的Cloud Backup--也会使用文件开头和结尾来判断它们的块边界。这些应用程序首先判断哪些文件已经发生修改，比如传统的增量型备份，然后开始在每个文件上进行分块操作。
如果备份目标端的重复数据删除引擎知道磁带的格式或将Tarball这样的文件（也就是你的备份应用程序写入数据的文件）整合在一起，那么使用文件边界可以优化备份目标端的固定块分块流程。重复数据删除引擎可以在Tarball内判断每个文件的开头和结尾，并根据这些边界对数据块进行重新调整。内容感知功能同时也可以让备份设备看到索引标志，并为备份应用程序插入到Tarball的数据编写目录以防止它们遭到分块。
不过，固定块系统可能在某些数据上会水土不服。我知道一位Data Domain用户使用Exchange备份来测试赛门铁克的PureDisk重复数据删除。他们当时在Data Domain上根据给定容量的存储保存40个Exchange服务器备份，但是他们无法在同样的存储容量下保存4个被PureDisk执行重复数据删除的Exchange备份数据。Exchange数据是由小量大型数据库文件组成的，而这些文件会在备份之间发生内部改变。对于PureDisk的重复数据删除引擎来说，这是最糟糕的情况。现在，如果你使用固定块重复数据删除引擎，而数据块的大小比数据库页面还小，那么情况也很糟糕。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
