大家都知道，存储系统的容量正在以惊人的速度增长。在过去的 10 年里，NetApp 提供的存储系统容量从数十 GB 发展到数百 TB，足足翻了 10,000 倍！但是，多数企业发现它们对存储的需求甚至增长得更快，– 除了存储所有这些数据的磁盘或磁带的成本外，– 数据中心空间和电源也变得越来越昂贵。因此，它们的重要目标之一就是尽可能高效地使用存储。

从存储数百个 Snapshot 副本仅需极少磁盘空间的独特的 Snapshot™ 技术，到允许系统管理员在运行时扩展和设定卷的 FlexVol®技术，NetApp 一直是高效利用存储的行业先锋.

五月份，NetApp 宣布了一种新的重复数据删除技术，能够大大提高指定磁盘空间可存储的数据量：高级单实例存储 (A-SIS) 重复数据删除。NetApp NearStore® R200 和 NearStore on FAS 系统均可使用该技术（免费！）

重复数据删除能以单个共享数据块为参考寻找相同的数据块并将其替换，从而提高效率。相同的数据块可能属于多个不同的文件或 LUN，或者可能重复出现在同一个文件中。A-SIS 重复数据删除是 NetApp WAFL 文件系统不可或缺的一部分，该系统管理 NetApp FAS 系统上所有存储。因此，不管您运行何种应用程序或如何访问数据，重复数据删除都在”后台”运行，并且开销很低。至于用户能节约多少空间，则取决于数据集和它所包含的重复数据删除量。

A-SIS 重复数据删除如何运作

实质上，A-SIS 重复数据删除采用老式的计算机科学技术-参考计算。以前，WAFL 仅跟踪数据块是否在使用。借助 A-SIS 重复数据删除，它还能跟踪有多少在使用。在目前的实施中，不同文件或同一文件中的单个 WAFL 块可参考多达 256 次。文件并不”知道”它们之间在共享数据-WAFL 内的簿记会在后台管理这些细节。

WAFL 如何确定哪两块可以共享？答案是 WAFL 会为每块计算出”指纹”，这是块数据的哈希。具有相同指纹的两个块即可用于共享。

在卷上启用 A-SIS 重复数据删除后，它会为备份卷中所有正在使用的块计算出一个指纹数据库（此过程称为”收集”）。完成初步设置后，卷即可用于重复数据删除。

为了不减缓普通文件操作，副本搜索将作为一个单独的批次处理来完成。由于文件系统会在正常使用过程中进行更新，WAFL 将创建描述其数据块更改的日志。该日志不断累积，直到出现以下某种情况：

 管理员发布 sis start 命令
 sis config 计划中指定的下一次发生
 日志更改超出了预定的阈值

这些事件中的任何一件都会触发重复数据删除过程。启动重复数据删除过程后，A-SIS 会使用变更块的指纹作为密钥来给日志排序，然后将排好序的列表与指纹数据库文件合并。一旦两个列表中出现相同的指纹，则可能有两个相同的块可折叠成一个。这种情况下，WAFL 会弃用其中一个块，并用另一个块的参考将其替换。因为文件系统时刻在变，除非两个块确实仍在使用并且含有相同的数据，否则我们当然可采取这一步骤。

A-SIS 重复数据删除实施利用了 WAFL 的某些特殊功能，从而使重复数据删除的成本降到最小。NetApp 很早以前就发现，要确保存储在磁盘上的数据的完整性，应该采用皮带与吊带式 (belt-and-suspenders) 方法。（事实上，最好有几双吊带。）因此，磁盘上的每个数据块都通过校验和得到保护。

A-SIS 使用该校验和作为它的指纹。由于无论如何都会计算指纹，相当于”无消耗”，因此不会给系统增加任何负担。且由于 WAFL 绝对不会覆盖正在使用的数据块，因此在闲置数据块之前，”指纹”将保持有效。A-SIS 重复数据删除与 WAFL 的紧密集成也意味着更改日志是一种高效的操作。其结果是 A-SIS 重复数据删除可用于广泛的工作负荷，而不仅是用于备份，其它重复数据删除实施的情况也是如此。

哪些类型的环境较使用适合 A-SIS？

首先，您的数据应是使用了很长时间。如果您想马上更改数据，则努力寻找重复数据意义不大。系统还应具有 CPU 剩余空间。更改日志和指纹匹配是为效率而设计的，但都要耗用 CPU。如果您的系统长时间处于高 CPU 利用率，则重复数据删除带来的额外负载将是致命一击。

节约磁盘空间的其它方法

NetApp 提供了许多其它可更加高效地使用磁盘空间的方法，它们各具优缺点。不必仅选择一个；因为它们大部分都可以结合使用。

Snapshot 副本

从一开始，WAFL 就允许通过 Snapshot 技术共享数据块。由于文件会随时改变，您可使用 Snapshot 副本捕获该文件的多个版本，并且存储成本仅与版本之间的更改量相对应。

无论作为本身的功能，还是作为诸如 SnapVault[R] 和 SnapMirror[R] 之类的应用程序的基础，Snapshot 副本都已证明了其价值。在 WAFL 中，就性能而言它们没有问题。它们的主要限制是它们只能在同一文件的不同版本之间提供块共享，这与在不同文件之间共享重复块的 A-SIS 不一样。

有时，如果您未使用过 NetApp 存储，您会发现 Snapshot 副本的 NetApp”纯增量”方法在所有主要的存储供应商中独树一帜，并且是我们的 SnapVault 和 SnapMirror 产品背后的基本技术，也是它们成功的主要原因。

压缩

在将数据写入磁盘之前进行压缩是一种节约空间的好方法。很多算法（如 gzip）可将文件压缩到一半或更小，即使没有可供共享的重复数据也能做到。压缩的缺点是它需要耗用大量 CPU 资源。而且，有些类型的数据（如映像）已经过压缩，不能得到这种优势。由于 A-SIS 重复数据删除可将数据的数百份副本压缩成一份，在拥有很多副本的环境中这可能比压缩节约远远更多的空间。

NetApp 目前在 Decru[R] 和 VTL 产品中提供了压缩功能。

内容寻址存储 (CAS)

尽管内容寻址存储的实施方法常常很不一样，但它在概念上与 A-SIS 重复数据删除相似。数据的”斑点”经过哈希处理后，哈希值将用于对其进行识别。对于指定哈希值的数据只会存储一个副本。一个文件可能包含许多斑点。

从某种意义上说，CAS 比 A-SIS 重复数据删除更灵活，因为 CAS 斑点不必是整个文件系统块。但是，在某个很重要的方面，CAS 却不够灵活。借助 A-SIS 重复删除功能，WAFL 可使用指纹作为密钥来共享块，但其基本数据结构仍然不变并且该共享是隐蔽的。（当然，您可随时关闭 A-SIS 重复数据删除功能。） 反之，在大多数 CAS 实施中，始终是通过哈希值来找到斑点。这就使它很难获得较高的性能，因此 CAS 通常是用于大部分为写入操作的归档应用程序，而不是需要对电子发现和数据恢复等即时读取作出快速反应的应用程序。

CAS 有一个方面有时会引起争议，即如果两个斑点具有相同的哈希密钥，则将其视为相同。如果两个不同的斑点碰巧具有相同的哈希值，那么数据就会丢失。这叫做”哈希冲突”或”误判”。有些统计数据可以很好地说明这种情形极不可能出现，但许多人还是不以为然。A-SIS 重复数据删除因此采取了一种保守的方法，只有块的内容（不单单是指纹）相同时才会共享块。在删除作为副本的块之前，A-SIS 逐个字节进行了比较以确保该数据确实相同。

总结

A-SIS 重复数据删除利用 WAFL 的独有特征来节省磁盘空间，同时保持较低系统开销。在许多环境中，可以大量地节约空间。即使在主目录环境等主存储应用程序中，A-SIS 重复数据删除也经常可以节约大量空间。

比如借助 NetApp Snapshot 技术，A-SIS 重复数据删除机制一定会为将来开发新颖的新应用程序（如克隆文件）奠定基础。WAFL 的持续演进是一个令人兴奋的发展过程。

• 乱谈七家存储厂商 (0)
• 中国市场07年第2季出货量达5148.3TB (0)
• 快照技术原理深入讨论 (1)
• 容灾备份解决方案 (9)
• 借NetApp统一存储 中国国际广播电台加快转型 (0)
• UIT电信数据容灾解决方案 (0)
• UIT BA1800集群NAS存储产品介绍 (0)
• Network Appliance收购Topio (0)
• Netapp技术资料：统一存储介绍 (0)
• Netapp软件介绍-SnapMirror (0)

从物理服务器转变为整合的虚拟化基础设施具有不可否认的 IT 优势。但是，快速迁移到 VMware 使灾难恢复 (DR) 的传统方法过时了，也增加了 DR 实施的复杂性。

用于 VMware® Virtual Infrastructure 3 (VI3) 的 DR 要求您的所有 VM（虚拟机）都需要定期复制到远程站点，从而消耗了大量的存储和网络带宽。通过在 VMware 主存储系统上使用 NetApp 重复数据删除，可以大大减少您的主存储环境中的数据量。数据量的减少会使得您的下游基础设施的优势不断加强，从而减少复制所需的带宽以及 DR 站点上所需的存储。

使用重复数据删除所节约的成本可以使 DR 在成本可能会受到控制的情况下变得切实可行。例如，有个客户曾报告在重复删除其 VMware Virtual Desktop Infrastructure (VDI) 环境之后，为其桌面提供 DR 所需的存储和带宽变得很少了，并且为其 VDI 环境和 VI3 环境添加 DR 切实可行。

在本文中，我将探讨通过 VMware DR 实施重复数据删除所需要采取的措施。我还将讨论利用您的 DR 环境中的复制数据用于 DR 测试及其它目的的情况。

在主 VMware 环境中实施重复数据删除

由于 VMware 环境中的每个虚拟机都要求为其操作系统采用专用的存储，因此会出现大量的重复数据。您可能有很多 VM 安装了同一个操作系统和应用程序。

如果 100 个 VM 运行同一个操作系统，且每个虚拟机需要 10GB 至 20GB 的存储空间，即 1TB 至 2TB 的存储空间专用于同一数据的几乎相同的拷贝。应用 NetApp 重复数据删除可以有效消除此冗余。

概括地说，如果将 X 个虚拟机指定给一个存储卷，在重复数据删除后，您所需的操作系统存储空间量将是非重复数据删除环境下所需存储空间量的 1/X。很显然，所获得的实际结果将取决于卷中有多少个 VM 和这些 VM 相似程度。

实际上，客户在 ESX VI3 环境通常可以节省 50% 或更多的空间，某些情况下存储空间节省可高达 90%。这是对整个 VMware 存储环境（包括应用程序数据，而不仅仅是操作系统）进行重复数据删除。在 VDI 环境下，客户通常可节省高达 90% 的存储空间。

NetApp 重复数据删除的另一个优点是它不仅可以在主存储设备上运行，还可以在任何现有的 NetApp 卷上运行。即使您的 VMware 基础设施建设很完善，也可以运行重复数据删除并节省大量存储空间。只需提供重复数据删除许可证（免费）和目标存储系统上的 NearStore® 许可证即可进行操作。

灾难恢复配置

虽然主存储环境中的存储空间使用量得到减少本身已经是一个重大益处，但是在使用 NetApp SnapMirror® 实施灾难恢复时，从重复数据删除中获得的真正收益更加明显。因为重复数据删除大大减少了必须复制的数据量，从而减少了 DR 位置所需的空间和站点间所需的网络带宽。进行重复数据删除以后，您也许可以配置 DR 以尽可能低的速度进行链接，将更容易和更快速地让您的 DR 环境维持运转。

图 1) 在具有 DR 复制的 VMware 环境应用重复数据删除。

如要配置 DR，首先请在存储数据的主 VMware 存储环境中对所有卷执行重复数据删除。然后在 DR 站点的主卷和目标卷之间创建 SnapMirror 关系。

与许多其他复制解决方案不同，SnapMirror 不要求目标配置与源配置完全一样。如果需要，您可以在 DR 站点中使用不同的 NetApp 存储系统和价格较低的磁盘（如 SATA 磁盘，而不是光纤通道磁盘）。

当 SnapMirror 第一次运行时，它会将每个源卷与其目标卷同步。此过程通常是 SnapMirror 实施时最耗带宽的部分，但是因为源卷都已执行重复数据删除，因此要传输的数据量会比实际量少很多。此方法是以下用户的理想之选：链接速度慢、没有足够带宽执行初始同步但可以管理此后出现的增量更新。

请注意，因为重复数据删除在卷级起作用，所以您必须使用 Volume SnapMirror 来获得最大收益。Volume SnapMirror 在整个卷上执行，因此您的镜像始终与源卷有相同的重复数据删除级别，还可节省空间、减少带宽利用以及加速镜像更新过程。

一旦完成初始同步，您就可以配置 SnapMirror 按计划运行，让 DR 站点内容始终保持最新。在每次迭代时，SnapMirror 仅传送已更改的数据块，因此它能更有效地利用网络带宽。您将需要在主站点定期运行重复数据删除。根据您的特定需求，可在以下时间运行重复数据删除：

 按指定的时间表
 卷中有 20% 的新数据时自动运行
 在需要时手动运行（例如，在安装大的修补程序以后）

使用 SnapMirror 后，无论主卷上有什么更改，都会自动反映到辅助卷上，因此不需要在您的 DR 站点运行重复数据删除。由于辅助卷是镜像，它们从主卷”继承”重复数据删除状态。

利用 DR 环境

获得 DR 站点的所有数据并通过 SnapMirror 定期更新后，并不意味着事情到此结束。NetApp 还可以利用 DR 站点存储的数据进行 DR 测试、开发或各种其他用途。

图 2) 在 DR 站点利用 FlexClone® 可将复制的数据用于多种用途。

在典型的 DR 测试环境中，在测试开始前必须将用于测试的所有数据复制到另一组磁盘。这意味着您需要两倍的存储空间，并且在开始测试前的复制操作也很耗时间。

借助 NetApp FlexClone 技术，您可以使任意或所有 DR 卷都成为具有空间效益的可写克隆；只在更改克隆卷时才会占用额外的空间。这些 FlexClone 卷便于您及时捕捉 DR 数据在固定时间点的静态视图，而不用中断进行中的 SnapMirror 更新，也不需要大容量的额外存储。

使用 FlexClone，您可以将进行 DR 测试的时间从 24 小时或更长时间降到几个小时，这是因为该过程快速、可靠、高效且无需使用密集资源。也可以通过类似方式对应用程序开发工作、数据挖掘、修补程序测试等使用 FlexClone。

DR 站点代表大量的资源投资。借助 FlexClone，您可以利用这些资源执行其他任务，而不会负面影响 DR 就绪。通过简化 DR 测试，FlexClone 使它更容易符合公司规定的 DR 测试需求以确保 DR 就绪。

总结

将 NetApp 重复数据删除应用到主 VMware 存储会在主基础设施和 DR 基础设施中产生巨大收益。在典型环境中，可以将主存储需求减少 40% 至 60%。此节省模式会将 DR 站点所需的存储以及 DR 所需的带宽减少相应的数量，使 DR 速度更快、更有效率。您可以使用 NetApp FlexClone 来利用 DR 站点的数据进行 DR 测试、应用程序测试/开发或其他活动，以便最大化资源利用。

• 企业数据信息安全解决方案 (1)
• VMware公司推出虚拟装置新版认证与销售计划 (0)
• Netapp软件介绍-SnapMirror (0)
• NETapp WAFL 文件系统 (0)
• NetApp A-SIS重复数据删除技术[转] (0)
• 重复数据删除的经济性[转] (0)
• 网格式 重复数据删除备份系统 (0)
• CAS技术及产品介绍-10 (0)
• security gateway appliances for VMware (0)
• CAS技术及产品介绍-9 (0)

虽然VTL结合磁带有相辅相成的效果，但在实际应用中，却面临性能、可用容量限制与节能等四大问题。

VTL的性能限制

单论顺序访问速度，其实当前的高速磁带机传输速率并不逊于磁盘阵列，而大型的磁带柜还能通过多个读写头执行多数据流并行备份（Multiple concurrent backup sessions），成倍增加了写入速度。但限制就在于磁带只能顺序读取，如果要还原特定的档案而不是要还原整卷磁带，就必须从头倒带卷到特定位置，非常耗费时间。

相比之下，VTL实际上就是个磁盘阵列，由于磁盘属于可随机读写的媒体，可随时读取磁盘区中的任意位置，还原特定数据的速度远高于磁带。更大的优势在于VTL可模拟任意数量的读写头，因此执行多数据流并行备份时，不会受到读写头数量的限制。一套VTL可同时连接多部备份服务器，同时执行多组备份程序大幅缩短备份时间。

但在底层，VTL是通过软件将磁盘阵列挂载到前端服务器上的LUN仿真成磁带格式，在多个备份数据流同时工作的情况下，很可能会发生多个数据流同时写入同一个控制器或同一个LUN，导致磁盘阵列负担不平衡而造成性能瓶颈。

另外，由于VTL是完全仿真磁带，而内建硬件压缩已经是磁带机的标准功能，因此VTL仿真出来的虚拟磁带也必须具备对应的压缩功能。但问题在于VTL提供的压缩功能多半是利用软件方式完成，非常占用VTL处理器资源，以致严重影响VTL的备份效率。

磁带转存作业占用备份服务器资源

在VTL结合磁带的架构下，VTL是居于缓冲的角色，数据最终还是要转存到后端的磁带上。但关键在于要如何执行转存磁带的作业。

传统的作法都是由前端备份服务器的备份软件，来执行将数据从VTL转存到磁带的作业。具体方法有几种：一种是先把数据从VTL还原到备份服务器上，然后再转存到磁带设备上；另一种则是通过备份软件的磁带复制（clone）功能。在备份软件看来，VTL仿真出来的磁带和磁带没什么不同，因此可事先在VTL上设定与磁带相同规格的虚拟磁带，然后再以磁带复制功能，将VTL中的数据转到磁带上。

无论哪种方式，都需通过前端的备份服务器执行，因此会占用备份服务器的作业时间与处理资源，当备份服务器执行VTL转存磁带作业时，就没办法执行原来的正常备份工作。

但当前企业的数据量都很大，对备份服务器被占用均十分敏感，不见得能允许备份服务器花很多时间去执行转存磁带作业。

容量瓶颈

如前所述，由于VTL是作为磁带的缓冲，显而易见的，如果VTL的容量越大，则留存在VTL磁盘中的备份数据也越多，因此在需要还原数据时，能够降低从最后端的磁带中寻找数据的机率，从而大幅提高还原效率。

虽然多数VTL产品都预留有扩充容量的准备，但比起可通过购买新磁带无限扩充容量的磁带设备，VTL容量仍是相当有限，因此一般的作法是通过政策设定，只在VTL中保留1个月内的备份数据，超过时限的数据就转存{}到磁带，以把VTL的空间让给新的数据。

但对许多要求每天均执行全备份的用户来说，这样的标准仍不易达成，要让VTL保留最近1个月份的数据，将需要非常大的磁盘空间，因此用户不是被迫为VTL购买极大的容量，就是只能在VTL上保留更少天数的数据，以致必须更频繁的执行转存磁带作用。

VTL需持续运行，难以节电

VTL相较于磁带设备虽有性能与可靠性上的优势，但就当前越来越受重视的电力消耗方面来看，却是处于劣势。

磁带柜、自动上带机之类的磁带设备内部主要组件都是机械装置，机械手臂、磁带运输、磁带机磁头等部件，都只有在实际工作时才会被驱动，平时处在待命状态下消耗的功率极低；而且多数企业都只有在下班等离峰时间才会启动磁带设备执行备份，因此磁带设备一天中几乎只有8到10多个小时会全功率运转。

相比下VTL的磁盘阵列就必须维持不间断的运作，尤其像是控制器与风扇等组件的供电都是不能中断的，虽然也可以平时把VTL关机，待要备份／还原时再行开机，但一来重新启动需要时间，二来又会牵涉到前端备份服务器的设置；原先设置好的VTL在关机后就会从备份服务器的备份装置中脱机，VTL重新启动后，还须在备份服务器上重新设定，十分麻烦。

转载地址：http://www.dostor.com/i/n/2007-12-21/0006137537.shtml

• VTL存储技术及产品市场分析 (0)
• 重复数据删除的经济性[转] (0)

有关 Web 字符编码的问题，已经是老生常谈。今天看到 一峰 兄弟和 Lunatic Sun 不谋而合的谈到有关 UTF-8 的使用现状，也谈谈我的看法。

上图是 Google 根据近年 Web 页面编码趋势的一个总结。我很欣喜的看到 UTF-8 编码已经成为了主流，而犹如 一峰 兄弟所言，让人堪忧的是中文字符编码还是呈现很平稳的趋势，这说明目前 UTF-8 编码并没有在中文网站中推广开来。

究其原因，本人认为会有如下几点：

第一，中文编码（无论是 GBK、GB2312、GB18030 等）都变成了“传统”，毕竟这是 中文 的编码。开发者不愿意在字符编码这块花太多的心思。

第二，由于早期项目的原因，不得不继续使用 GBK 等中文编码。

我曾经就遇到过这样的一个项目，当时我很奇怪他们为什么不用 UTF-8，因为他们面对的客户不仅仅是国内用户。而解决这一方案的办法就只能是使用非常劳累的手段，但这是指标不治本的办法。虽然最后，在本人的一再坚持下，最后还是转成了 UTF-8 编码，但相信国内还有很多项目都会碰到类似的问题。

第三，开发工具方面的支持，尤其是国内的一些产品。从根本上说，除了基本的思想意识以外，还有就是开发工具的问题。或许有一天，开发者相关的开发工具都默认的就是 Unicode 的话，这样转换的成本就会非常的低。

第四（感谢小马补充），流量大、文字多的中文站点通常都会使用 GB2312，原因很简单，页面下载量会比 UTF-8 小（GBK 编码只需要两个字节，而 Unicode 需要三个或者以上）。

那么，我经常使用的些主要的中文站点，目前在使用什么编码呢？下面是一个不完全的列表，供大家参考一下（以页面 meta 标签的 Content-type 为准）。

1. 淘宝 - GB2312
2. 支付宝 - GB2312
3. 口碑 - GBK
4. 中国雅虎 - GB2312
5. 163 - GB2312
6. 新浪 - GB2312
7. 搜狐 - GB2312
8. 豆瓣 - UTF-8
9. Yupoo - UTF-8
10. 谷歌 - UTF-8
11. ...

从上述的站点看来，目前国内一般门户类型的站点基本上都是 GBK 等编码，而类似 豆瓣、Yupoo 这样的新兴 “Web2.0 式站点”已经开始尝试 UTF-8 。在我看来，Unicode 在中文站点的推广，任重而道远。

那么接下来，在您以后的项目中，您会选择什么字符编码？

另，有关字符编码方面的知识，一峰 兄弟的相关文章，很受用。

Gracecode.com | Permalink | Trackback | Wap | Rss | 1 comments

This post is password protected. To view it please enter your password below:

Password: