浅谈重复数据删除生存指南之一

【IT专家网独家文章】编者提示：这是生存指南4部分内容中的第一部分，在这一部分，我们将要介绍重复数据删除解决方案中部署的技术和实施策略：

● 第一部分将关注重复数据删除的基本定位——独立设备、VTL解决方案或者是主机软件。

● 第二部分将讨论实施重复数据删除的时机。这涉及到在线处理(in-line processing)和后处理(post-processing)之间的比较。

● 第三部分将涉及标准化和密封式(siloed)重复数据删除技术之间的比较，探索使用单个供应商提供的包含所有辅助数据的相同的解决方案的好处，并比较其与部署独特的适用各种数据类型的重复数据删除技术之间的区别。

● 第四部分将讨论性能问题。很多重复数据删除技术供应商宣称，高速系统几乎是不可能实现的，我们将要探索如何对这一宣称作出解释。

重复数据删除市场上最初出现的产品都是基于特定系统的，关注的焦点在于提高磁盘到磁盘备份解决方案的价值，同时使组织对磁带的依赖性降到最低。

随着重复数据删除技术的不断普及，少量的主存储器供应商已经开始尝试将这项技术作为一种附加功能添加到其产品中，尤其是在虚拟磁带库(VTL)中。备份软件厂商也正往其解决方案中添加这一功能。如今，可用的重复数据删除技术很多，IT经理们可以有很多选择，然而，新的问题在于：在哪里部署重复数据删除过程最合适呢?

当你在阅读这篇文章时，要记住，重复数据删除技术的核心焦点是辅助存储器而不是主存储器，包括归档和备份。还要注意，重复数据的构造可能并不是非常明显。例如，Oracle数据库可以有多种备份方法：使用内置RMAN实用工具;使用企业备份软件应用程序;或者是使用Oracle专用的备份实用工具。这几种方法中，每种方法都要创建自己的数据集。由于这些数据集都是同一个Oracle数据库的备份，每一个数据集中的数据从本质上来说是一样的。

通用重复数据删除系统

包括Data Domain和Quantum在内的几家厂商都提供了不与特定的虚拟磁带库或备份设备相关联的重复数据删除产品。这些设备可以称为通用重复数据删除系统。

使用通用重复数据删除存储系统得好处在于，它的设计就是为了删除重复数据的。这种设计带来的好处是，这些系统具有数据源中立的特点，也就是意味着，源备份数据可以来自多个不同的应用程序，包括备份软件、应用程序工具、归档应用程序、或者是直接来自用户。

通用型系统提供了多种数据访问协议(NFS、CIFS或是磁带仿真)，而且还提供了多种不同类型的物理连接(以太网或光纤通道)。在真实的数据中心中，存在很多不同的备份数据源，数据源中立能够带来显而易见的好处。

尽管在通用系统中，数据输入可以来自多个不同的源，但是，重复数据删除过程却是对所有源都起作用的。例如，管理员可以通过备份应用程序将微软的SQL环境备份到一个通用型重复数据删除系统上。然后，同样的数据可以被放入SQL DBA的重复数据删除系统。之后，通过使用VMware备份工具，该数据还可能作为VMware镜像的一部分被获取，并转移到重复数据删除系统上。

在以上讲述的例子中，所有的数据都是相似的，而且在存储数据之前，来自每一个源的冗余的部分都会被删除。注意，这个例子是针对每天都有微小变化的文件。这种多保护模式在当今的数据中心中并不少见，因此，在一周或一个月内节省的空间是让人震惊的。

通常，通用型重复数据删除系统具有在线重复数据删除的能力，因为一般来说，这是最有效率的处理方式。理想情况下，重复数据删除系统还应该具备辨别长度可变的数据部分的能力，从而提供最有效的重复数据删除效果。例如，它应该能够只鉴别和存储数据库中那些发生改变的数据部分，而不是在每个备份上重新存储整个文件。

最后，包含复制功能的通用重复数据删除系统为用户提供了将备份数据复制到远程站点的最佳方法。利用重复数据删除技术，重复数据删除系统只需要通过网络复制新的数据片段就可以了。

最有效率的系统将是那种能够在多个站点之间通过在线处理重复数据删除进行复制的系统。到目前为止，Data Domain是最符合这个要求的。此外，在线重复数据删除系统能够在系统刚开始接收数据的时候就启动复制过程。这与虚拟磁带库系统不同，后者通常是使用后处理方式的重复数据删除，因此复制过程开始之前会存在一定时间的延迟，从而使得灾难恢复数据存在一定的风险。

虚拟磁带库解决方案

虚拟磁带库解决方案的提供商，如FalconStor(也是EMC和Sun的供应商)、NetApp和Sepaton通常会认证一系列的备份应用程序，但是对数据源或数据目标系统来说，它们并不是中立的。

特别需要指出的是，虚拟磁带库解决方案是仿真磁带库。因此，只有那些对磁带库具有特定支持的应用程序才能使用虚拟磁带库，这使得应用程序本身受到限制，难以取得更大的发展。

在数据中心中流行使用的很多工具通常是将数据装入磁盘，而并不支持磁带协议。很多数据保护工具并不支持将数据复制到虚拟磁带库中。

带重复数据删除功能的虚拟磁带库解决方案的局限大部分来自系统管理复杂性的增加以及在线处理与后处理的优劣之争上。通常来说，新增的虚拟磁带管理需要在磁盘上仿真磁带，因此对已经很复杂的环境来说不异于又增加了更多的复杂性。

对持续的日常管理来说，后处理方式进一步增加了其复杂性，而且这种方式对重复数据删除和复制(或是创建灾难恢复副本)的时间会有负面影响。后处理方式同时还需要增加额外的磁盘容量来充当重复数据删除的“着陆区”。

最终，更多的容量意味着需要管理更多的磁盘，消耗更多的电源和制冷成本，占据更多的空间，当然，还需要购买更多的设备。如果使用低效率的后处理重复数据删除方式，在现有的虚拟磁带库产品中还不如不增加重复数据删除功能。

基于软件的重复数据删除和单实例存储

正如人们所期望的，备份软件厂商目前正在其功能集中增加重复数据删除功能。此外，备份软件厂商，如CommVault正在使用一种数据缩减技术，也即众所周知的单实例技术，在备份主机接收数据并开始文件层次的比较时发挥作用。

尽管这种方法很明显会降低备份过程引发的某些存储要求，但是它不能解决网络带宽的需求问题，也不能解决类似数据的多个副本的问题(只有那些通过特定应用程序运行的数据才需要检验是否存在冗余)。

单实例存储并不能解决备份存储中存在的另一个大问题：那些定期发生轻微变动的文件。

在单实例存储中，那些不需要每天变化的离散文件通常被排除在备份的实例之外。然而，在所有的备份传送策略中，那些无变化的文件并不是问题所在，那些每天变化一点的大型文件才是真正的问题所在。

数据库，VMware镜像和Exchange存储通常每天都会发生轻微变化。一个文件层次的单实例对照能够看到不同文件之间的变化，但不能显示同一文件之间的轻微变化。这意味着，整个文件必须要重新存储，与真正的重复数据删除技术相比，这会导致贫乏的数据缩减效果。很明显，如果没有数据块级别的缩减，就不可能节省空间，特别是对那种超大型的数据库文件来说，更不可能节省空间了。

单实例存储另一大无法解决的挑战在于，相似的数据集中通常存在多个备份源。例如，备份管理员可能会使用备份软件的Exchange模块来备份Exchange;而Exchange管理员可能同时还使用另一单独的工具来备份Exchange存储。在这个备份过程中不存在数据缩减，因为一个备份软件不能看到由另一个独立的备份工具创建的备份。

在这两种情况中(频繁且小规模变化的应用程序及多个备份源的情况)，基于块级的重复数据删除系统会识别冗余的数据块，从而即便是备份源不同(可能来自备份应用程序或是Exchange)，也能够减少存储负担。

那些使用单实例存储技术的软件供应商声称这种方式是最适合存储恢复的方式。言外之意是，重复数据删除系统存在一些恢复性能方面的问题。然而，虽然一些厂商的重复数据删除系统中有可能已经存在一些恢复性能问题，但是只要系统的架构设计得当，那么重复数据删除过程应该就不会给性能造成很大的影响。

在真实世界的数据中心中，在通过通用型数据删除系统进行恢复的过程，备份后数据和源服务器之间存在太多的其它瓶颈，这些是问题所在。如果恢复的性能需求超过了从磁盘恢复的能力，那么就需要考虑其它的高可靠性解决方案，例如集群技术或活动目标等。(活动目标是一种备份目标应用程序，可以像正常的文件系统一样被浏览和阅读访问。)

最后，单实例存储方法的前提假设是所有数据类型的所有备份、归档及其它数据管理功能都使用单一软件应用程序。这个假设并不实际。虽然很多备份软件厂商确实提供了备份以外的某种形式的附加组件，但是这些附加模块的功能性有所不同，而且实际上大部分客户在归档和备份上是分别使用不同的解决方案，在特定平台(如VMware)上使用特定应用程序。此外，软件制造商为一个针对唯一的数据库或操作系统的模块所投入的时间和成本也是有限的。

小结

数据源中立、协议/连接性中立、数据类型中立，通用型重复数据删除系统所具备的这三种性能使其成为备份存储和归档数据存储的最佳工具。注意：不要受备份软件中内置的重复数据删除系统模块特定功能的限制，也不要受虚拟磁带库中单磁带协议的限制。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友