第一页
编者按：这是我们探讨重复数据删除技术和重复数据删除解决方案执行策略“四部曲”的第一篇：
第一篇：将谈论重复数据删除技术的基础应用——独立设备、VTL解决方案或者主机软件。
第二篇：将谈论重复数据删除技术的两种方式，这主要涉及in-line和post-processing两种重复数据删除方式。（http://article.pchome.net/content-696159.html）
第三篇：将谈论统一的重复数据删除和独立的重复数据删除、采用单一厂商覆盖所有次要数据解决方案的好处、以及采用针对不同类型数据的定制重复数据解决方案的好处。
第四篇：将谈论重复数据删除技术的性能问题。许多重复数据删除产品提供商宣称他们的系统具有惊人的处理速度，我们将探讨如何理解这些说法。
重复数据删除市场最早出现的一些产品是基于某些特定的系统，这些系统主要是减小企业机构对磁带的依赖程度的同时，提升磁盘到磁盘备份解决方案的性能。
随着重复数据删除解决方案在用户中逐渐普及，许多大型存储厂商则开始将重复数据删除技术作为一项产品增值功能提供给用户，而且大多是新增到VTL产品中。之后，备份软件厂商也跟着效仿这种做法。现在，IT经理们可以选择的重复数据删除解决方案琳琅满目，可是却出现一个新问题：究竟将重复数据删除技术应用到哪些方面才是最佳做法？
在你阅读本文的时候，切记重复数据删除技术主要是针对二级存储的——归档和备份，而不是针对主存储。还要记住一点，冗余数据的构成并非显而易见的。例如，一个Oracle数据库的备份方法有很多种——可以使用内嵌的RMAN；也可以使用企业备份软件应用；或者使用Oracle专门的备份工具，每种方法都会产生一个数据组。因为这些数据组是同一个Oracle数据库的备份，所以每个数据组中的数据实际上是一样。
通用的重复数据删除系统
包括Data Domain和昆腾在内的多家存储厂商都推出了自己的重复数据删除系统，这些系统并不是与某个特定的VTL或者备份应用相兼容，而是一种通用的重复数据删除系统。
采用通用重复数据删除系统的好处就在于它是针对重复删除的数据设计的。因此，这些系统对数据来源是“一视同仁”的，也就是说，备份源数据可以是来自多种应用的，例如备份软件、应用设备、归档应用或者直接来自用户。
通用系统提供了多个数据访问协议（NFS、CIFS或者磁带仿真）以及多种物理连接（以太网或者光纤通道）。在物理数据中心里有很多种来源的备份数据，因此系统对数据来源“一视同仁”显然是具有一定优势的。
虽然输入数据可能有不同来源，但是在通用系统中重复数据删除流程却是适用于所有数据的。例如，系统管理者可能会通过备份应用将Microsoft SQL环境备份到通用重复数据删除系统中。然后，用户可能会使用一款VMware备份工具将其作为一个VMware镜像获取，将数据迁移到重复数据删除系统中。
在以上的例子中，所有数据都是类似的，不同来源的冗余数据在保存之前就被删除掉了。请注意，这个例子主要是那些一天之内变动很小的文件。在目前的数据中心里，这种多重保护功能并不常见，所以想要在一周或者一个月之内节省下空间是不太容易的。
第二页
一般来说，通用重复数据删除系统可以进行in-line重复数据删除操作，因为这是效率最高的方法。而且在理想状态下，重复数据删除系统应该可以识别不同长度的数据组来选择最有效的重复数据删除策略。例如，重复数据删除系统可以提取并且只保存数据库中发生改变的数据组，而不是对整个数据库进行备份。
而且，具备复制功能的通用重复数据删除系统提供了将数据备份到远程站点的最佳解决方案。重复数据删除系统只需要复制网络中的新数据。
最高效的系统可以进行重复数据删除复制、in-line重复数据删除以及多站点之间的重复数据删除。到目前为止存储厂商中Data Domain做到了以上三点。除此之外，in-line重复数据删除可以在系统开始接收数据的时候就启动复制流程。这与VTL系统有所不同，VTL系统通常采用的是post-process重复数据删除，因此在复制流程开始之前会有一个延迟的时间，这也提高了灾难恢复数据的风险。
VTL解决方案
飞康（FalconStor）、NetApp和Sepaton等VTL解决方案提供商通常会认证一系列备份应用，但是他们在数据来源和目标设备方面却不是一视同仁的。
VTL解决方案仿效的是磁带库。因此，只有支持磁带库的应用才能使用VTL，这本身就具有一定的局限性。
目前数据中心常用的设备会将数据传输到磁盘中，而且不支持磁带协议。许多数据保护功能不支持将数据复制到VTL的操作。
目前VTL解决方案在重复数据删除方面的局限性大多集中在附加的管理复杂性和in-line与post-process的争论上。总的来说，附加的虚拟磁带管理需要在磁盘上模拟磁带，这让已经就很复杂的环境更加复杂。
Post-processing还使未来日常管理工作变得更加复杂，而且对重复数据删除的时间和复制时间有负面的影响。Post-processing还需求有额外的磁盘空间来支持重复数据删除技术。
最后，更多的空间就意味着需要管理更多的磁盘、更多的能源支持、冷却设备、当然还需要更多的占地空间、购买更多磁盘。到目前为止，厂商大多是通过使用较低效的post-processing重复数据删除方式向现有的VTL产品中增加重复数据删除功能。
基于软件的重复数据删除技术和单实例
备份软件厂商开始向他们现有的功能特性中增加重复数据删除功能。除此之外，CommVault等备份软件厂商开始使用单实例等数据缩减技术，这项技术可以在备份主机接收到数据并进行文件级的比较时启动这项功能。
虽然这种方法消除了备份流程对存储空间的要求，但是却无法解决房网络带宽问题，也不能解决同样数据产生多个副本的问题（只有在某些特定应用中运行的数据才能进行冗余比较）。
单实例存储不能解决备份存储的其他问题——一段时间内变动很小的文件。
有了单实例存储，那些每天没有变化的文件被剥离备份流程。然而，在任何备份策略中，不发生变化的文件都不会成为问题，有问题的往往是那些每天都会有小变动的大型文件。
第三页
一般数据库、VMware镜像、Exchange存储每天的变动都很小。基于文件的单实例对比将把这些变动识别为不同的文件，而不是有变化同一文件。也就是说，所有这些文件都必须再保存一次。这与真正的重复数据删除技术相比数据缩减效果就差很多。显然，如果没有基于块的数据缩减就无法节约空间，尤其是对数据库文件来说，这些文件一般来说都很大。
单实例存储无法解决的另一个难题就是同一个数据组往往有多个备份来源。例如，备份管理者可能会使用备份软件的Exchange模块来对Exchange进行备份；Exchange管理者也可以用别的工具来备份Exchange保存文件。这时候不会发生数据删除，因为备份软件不能识别独立独立工具产生的备份文件。
在两种情况下（经常有小变动的应用和多个备份来源），一个以块层级运行的重复数据删除系统可以识别冗余数据块，减少备份来源不同可能带来的影响。
使用这种单实例技术的软件供应商认为，这种存储方法更适合于恢复，也就是说，重复数据删除系统在恢复方面存在性能问题。虽然一些软件提供商的重复数据删除系统存在性能问题，但是当系统配合何时的架构，那么性能问题对重复数据删除流程就不会有太大影响。
在现实世界的数据中心中，备份数据和源服务器之间存储其他瓶颈使得从通用重复数据删除系统的恢复成为一个问题。如果恢复性能需求超出了从磁盘恢复的能力范围，可以考虑使用其他例如集群或者主动目标等高可用解决方案。（主动目标是可以被浏览或者向正常文件系统一样读取的备份目标）
最后，使用单实例存储的做法大多是将一个软件应用用于所有备份、归档和其他数据管理功能。这是不实际的做法。虽然许多备份软件提供商除了备份之外还提供了其他一些附加组件，但是这些附加模块的功能性也是千差万别的。实际上大多数用户采用的是备份和归档分离的解决方案，以及针对某个特定平台（例如VMware）的应用。而且一家软件开发商在针对一个特定数据库或者操作系统的模块开发项目上的资金投入也不尽相同。
总结
通用重复数据删除系统对数据来源、协议、互连性以及数据类型一视同仁的特点使它成为存储备份和归档数据的最佳工具。谨记一点：不要只局限于备份软件内嵌的某个特定重复数据删除模式，或者只局限于VTL中只支持磁带的协议。
网友评论