向汪要求更换时，汪及其上家汪2说卖出时磁盘就是seagate，信息不符是客户自己刷了磁盘的BIOS，所以不予保修和更换。并说现在现在的刷磁盘BIOS工具很多，客户自己很容易刷的。

购买时由于时间较紧，且也没有条件对每块磁盘做详细检测，同时考虑到汪是我一个朋友的朋友，秉着信任的角度就买了。没想到会出现这样的没有信誉的事情。

关于磁盘的BIOS，且不说客户的存储不是Netapp，再怎么刷不可能去刷成Netapp后再来更换，直接刷成自己想要的就行了。再说，虽然刷BIOS的工具很多，但那也是对专业人士而言，普通用户怎么可能会有相关的软硬件设备去刷BIOS，会刷firmware就很难得了。

被逼无奈，辗转找到的seagate的一个技术专家，通过磁盘标签上的SN号（并非从磁盘中抓取的），在seagate内部数据库中查到了以下信息：

表格中的信息说明SN为3KS10L3Q 的磁盘是2005年为专为Netapp生产的OEM磁盘，到2009年购买时，已过3年包换期。该信息与从磁盘中直接抓取的信息相同，说明磁盘从一开始就是Netapp的，不是后刷的。

但即使如此，汪的上家汪2仍然不认，仍然不想更换，竟然说“你让seagate签字盖章，说明磁盘本来就Netapp的”！

对于这样的公司，我真的是没有办法了。难道磁盘渠道商就这样，还是就汪2是这样？

从存储数百个 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 的持续演进是一个令人兴奋的发展过程。

FAS3050和FAS3050c是NetApp统一网络存储的FAS3000系列的产品，专为满足高端存储的应用需求而设计。FAS3000 系列系统非常适合用于企业应用基础设施，比如数据库、电子邮件/消息收发、主目录合并和灾难恢复解决方案。FAS3000系列通过对NFS、CIFS、HTTP、iSCSI、FCP等协议的支持，可同时满足NAS和SAN的构架。

FAS3000 系统进一步提高针对小数据卷的磁盘性能，使用 FlexVol 技术可以降低存储管理成本，将客户的存储利用率提高 50%。结合新的 SATA 存储选件，主要存储成本可以减少一半以上。

主要特点：

Ÿ 高可靠性，超过99.998%的数据可用性，减少了代价高昂的宕机时间，最大限度地保障了对关键数据的访问。FAS3050C可提供集群的双活动（Active-Active）配置支持。

Ÿ 高性能，在多用户多协议环境中提供了业界领先的吞吐量和响应时间。

Ÿ 高扩展性，实现了即时的可扩展性，能够在一套单一系统或是多Filer的配置环境中支持数千名用户和数千项事务处理以及数万亿字节的信息。

Ÿ 简单，易于安装、操作与升级。

Ÿ 灵活，利用现有的以太网或是光纤通道基础设施，能够同时满足 NAS、iSCSI SAN 以及光纤通道 SAN 等多方面的存储需求。

Ÿ 可同时支持FC硬盘和SATA硬盘，以满足不同应用的需求。

1.2、硬件特性

FAS3050和FAS3050c系统图示如下：

FAS3050系统包括：

Ÿ 2*2.8GHz Intel Xeon处理器，支持超线程功能

Ÿ 4GB DDR-DRAM系统内存

Ÿ 512MB NVRAM-5

Ÿ 远程管理模块（Remote LAN Module – 选配）

Ÿ 3个PCI-X扩展槽

Ÿ 内置4个10/100/1000Base-T千兆以太网接口，最多可提供12个千兆以太网接口

Ÿ 内置4个光纤通道（FC）接口，最多可提供10个FC接口

Ÿ 最多336个磁盘，支持FC硬盘和SATA硬盘混合使用

Ÿ 最多84TB的裸盘容量

Ÿ 最大单卷容量17.6TB

FAS3050c系统包括：

Ÿ 4x 2.8GHz Intel Xeon处理器，支持超线程功能

Ÿ 8GB DDR-DRAM系统内存

Ÿ 1GB NVRAM-5

Ÿ 远程管理模块（Remote LAN Module – 选配）

Ÿ 6个PCI-X扩展槽

Ÿ 内置8个10/100/1000Base-T千兆以太网接口，最多可提供24个千兆以太网接口

Ÿ 内置8个光纤通道（FC）接口，最多可提供20个FC接口

Ÿ 最多336个磁盘，支持FC硬盘和SATA硬盘混合使用

Ÿ 最多84TB的裸盘容量

Ÿ 最大单卷容量17.6TB

1.3、系统性能

表1：F3050和F3050c的性能

1.4、产品亮点

1.5、系统规格

1.6、系统环境规范

1.7、FAS3000系列 FC交换机支持－磁带/SAN

1.8、存储子系统规格

1.9、NETAPP系统机柜

1.10、法规

1.11、对FAS3000系统磁带机的支持

FC = 光纤通道；LVD = 低压差分；SE = 单端；SE 和 LVD 不能在适

FAS3020和FAS3020c是NetApp统一网络存储的FAS3000系列的产品，专为满足中高端存储的应用需求而设计。FAS3000 系列系统非常适合用于企业应用基础设施，比如数据库、电子邮件/消息收发、主目录合并和灾难恢复解决方案。FAS3000系列通过对NFS、CIFS、HTTP、iSCSI、FCP等协议的支持，可同时满足NAS和SAN的构架。

FAS3000 系统进一步提高针对小数据卷的磁盘性能，使用 FlexVol 技术可以降低存储管理成本，将客户的存储利用率提高 50%。结合新的 SATA 存储选件，主要存储成本可以减少一半以上。

主要特点：

Ÿ 高可靠性，超过99.998%的数据可用性，减少了代价高昂的宕机时间，最大限度地保障了对关键数据的访问。FAS3020C可提供集群的双活动（Active-Active）配置支持。

Ÿ 高性能，在多用户多协议环境中提供了业界领先的吞吐量和响应时间。

Ÿ 高扩展性，实现了即时的可扩展性，能够在一套单一系统或是多Filer的配置环境中支持数千名用户和数千项事务处理以及数万亿字节的信息。

Ÿ 简单，易于安装、操作与升级。

Ÿ 灵活，利用现有的以太网或是光纤通道基础设施，能够同时满足 NAS、iSCSI SAN 以及光纤通道 SAN 等多方面的存储需求。

Ÿ 可同时支持FC硬盘和SATA硬盘，以满足不同应用的需求。

1.2、硬件特性

FAS3020和FAS3020c系统图示如下：

FAS3020系统包括：

Ÿ 2.8GHz Intel Xeon处理器，支持超线程功能

Ÿ 2GB DDR-DRAM系统内存

Ÿ 512MB NVRAM-5

Ÿ 远程管理模块（Remote LAN Module – 选配）

Ÿ 3个PCI-X扩展槽

Ÿ 内置4个10/100/1000Base-T千兆以太网接口，最多可提供12个千兆以太网接口

Ÿ 内置4个光纤通道（FC）接口，最多可提供10个FC接口

Ÿ 最多168个磁盘，支持FC硬盘和SATA硬盘混合使用

Ÿ 最多50TB的裸盘容量

Ÿ 最大单卷容量17.6TB

FAS3020c系统包括：

Ÿ 2x 2.8GHz Intel Xeon处理器，支持超线程功能

Ÿ 4GB DDR-DRAM系统内存

Ÿ 1GB NVRAM-5

Ÿ 远程管理模块（Remote LAN Module – 选配）

Ÿ 6个PCI-X扩展槽

Ÿ 内置8个10/100/1000Base-T千兆以太网接口，最多可提供24个千兆以太网接口

Ÿ 内置8个光纤通道（FC）接口，最多可提供20个FC接口

Ÿ 最多168个磁盘，支持FC硬盘和SATA硬盘混合使用

Ÿ 最多50TB的裸盘容量

Ÿ 最大单卷容量17.6TB

1.3、系统性能

表1：F3020和F3020c的性能

1.4、产品亮点

1.5、系统规格

1.6、系统环境规范

1.7、FAS3000系列 FC交换机支持－磁带/SAN

1.8、存储子系统规格

1.9、NETAPP系统机柜

1.10、法规

1.11、对FAS3000系统磁带机的支持

FC = 光纤通道；LVD = 低压差分；SE = 单端；SE 和 LVD 不能在适配器上混用。

1.1.1 技术原理

网络数据管理协议（或简称为NDMP）是一种开放式标准，用于集中控制企业级数据管理。NDMP体系结构可使备份应用程序厂商在Network Appliance Filer和其他网络连接服务器上控制本机备份和恢复设备。NDMP最初由Network Appliance和Legato Systems公司联合开发设计，而今在性能方面已经获得了显著的增强，并被存储行业所广泛采用。NDMP的第三个修订版本已成为存储界开放式数据管理协议的先导，目前市场上有25种以上的NDMP兼容产品。现在，存储网络行业协会（SNIA）成立了一个工作组专门负责制定此协议标准。该工作组正处于制定协议第五版的最后阶段。如欲了解有关NDMP更多详情（包括协议规范），请访问http://www.ndmp.org。

NDMP的初衷是在任何备份软件应用与网络连接存储设备之间提供一种通用接口。这样，应用厂商就可以支持各种网络连接设备，而无需重新设计费用昂贵的编程逻辑。而且，网络连接存储设备厂商（如Network Appliance）还可以与任何NDMP兼容应用实现无缝协作。这样，当前可用的各种应用程序就可以通过NDMP来备份Network Appliance Filer了。

NDMP将备份和恢复操作的控制和数据流分成若干个独立的会话。这样可更灵活地配置用来保护Network Appliance Filer数据的环境。由于会话是独立的，所以它们可以从各个位置启动，并引导到不同的位置，从而更灵活地设计基于NDMP的拓扑。

由于Filer可以同时为UNIX®和Windows NT®/2000计算机提供数据，因此NDMP不仅可以确保在备份过程中保留UNIX与NT安全性和许可权限，同时还可确保恢复过程中的正确性。对于利用NFS或者CIFS安装环境的备份解决方案来说，这一点并不是必要的。如果通过安装NFS将文件从Network Appliance Filer备份到UNIX主机，则系统不会备份任何与此类文件相关的CIFS ACL。相反，通过安装CIFS而从Network Appliance Filer备份到Windows NT/2000主机上的文件将包括UNIX属性。

NDMP允许运行NDMP兼容应用程序的备份服务器直接备份和恢复多个Filer。软件应用程序使用NDMP向Filer发送请求，以调用备份和恢复进程。在备份操作过程中，有关已备份文件的信息将从Filer发送到基于备份服务器运行的软件应用中。此时，实际文件将从Filer发送到其中一个位置（三个可能位置）：

1. 直接连接到Filer的磁带设备，也称为直接连接模式

2. 与同一品牌的其他存储设备相连接的磁带设备，也称为Filer到Filer模式

3. 连接到备份服务器的磁带设备，也称为Filer到服务器模式

另外，NDMP还可用于在两个Filer之间传输数据，进行数据复制，而根本无需使用磁带。这种情况通常称为磁盘到磁盘复制。当前，该操作通过运行于独立系统（引导Filer之间的数据流传输）上的小型应用进行控制。实际数据则仅从源Filer传输到目标位置，而无需通过运行控制器应用程序的系统。 NDMPcopy可用于磁盘到磁盘的备份和数据移植。如想下载Solaris™和HP-UX NDMPcopy源代码，请访问NDMP.org网站。

NDMP－直接连接

在直接连接和本地模式中，备份服务器通过LAN上的NDMP来指示Filer开始备份。随后，Filer通过光纤通道或SCSI将备份中的数据发送到与其直接连接的磁带设备中。在备份过程中，通过LAN上的NDMP，将写入磁带的文件和目录相关信息传输到备份服务器中，然后编制索引，进行维护。对于恢复操作，备份服务器使用LAN上的NDMP来指示Filer开始恢复文件。系统从与磁带设备进行本地连接的Filer中读取数据，并对其进行存储。在备份和恢复过程中，备份服务器从不接收写入磁带或从中读取的实际数据。因此，该模式通常称为“不通过LAN”的备份。

图 37：NDMP－直接连接

优点：

Ÿ 在所有NDMP模式中性能最佳

缺点：

Ÿ SCSI或光纤通道规范限制了Filer与磁带机之间的距离。

Ÿ Filer上运行的Data ONTAP版本必须支持磁带机。

Ÿ SCSI连接的磁带机必须专用于单个Filer。

NDMP－光纤通道SAN连接

光纤通道SAN模式也是一种直接连接模式，并且与其具有相同的优点和缺点。该模式与支持动态磁带机共享的软件应用程序联用，可在与SAN连接的所有Filer之间共享磁带机。这样可以降低管理和运营成本。此外，由于每个Filer都可以使用更多磁带机来进行备份和恢复操作，因此也显著提高了性能。
 

NDMP－Filer到Filer

在Filer到Filer模式中，通常指的是“三路”，即备份服务器使用LAN上的NDMP，通过同一网络或专用备份网络，指示Filer A将数据开始备份到与Filer B相连接的磁带设备中。在备份过程中，通过LAN上的NDMP，将写入磁带的文件和目录相关信息传输到备份服务器中，然后编制索引，进行维护。

图 38：NDMP－Filer到Filer

优点：

Ÿ 在多个Filer之间共享价格昂贵的磁带设备

Ÿ SCSI或光纤通道不再限制源Filer与磁带设备之间的距离

缺点：

Ÿ Filer之间的备份性能高低取决于网络带宽

Ÿ 可能需要额外的网络基础设施来提高性能

Ÿ 在Filer上运行的Data ONTAP版本必须支持磁带机

NDMP－Filer到服务器

在Filer到服务器模式中，通常指的是远程应用，即备份服务器使用LAN上的NDMP来指示Filer A将数据开始备份到与备份服务器相连接的磁带设备中。在备份过程中，通过LAN上的NDMP，将写入磁带的文件和目录相关信息传输到备份服务器中，然后编制索引，进行维护。

图 39：NDMP－Filer到服务器

优点：

Ÿ 在NDMP与非NDMP备份之间可共享价格昂贵的磁带设备

Ÿ 磁带设备支持不再依赖于Filer上运行的Data ONTAP版本

Ÿ SCSI或光纤通道规范不再限制源Filer与磁带设备之间的距离

缺点：

Ÿ 显著提高了备份服务器的资源要求

Ÿ 可能需要额外的网络基础设施来提高性能

NDMP－Filer到磁带库

从概念上讲，Filer到磁带库模式与Filer到Filer模式极为相似。在该模式中，备份服务器使用LAN上的NDMP来指示FilerA将数据开始备份到与网络直接连接的磁带机上。在备份过程中，通过LAN上的NDMP，将写入磁带的文件和目录相关信息传输到备份服务器中，然后编制索引，进行维护。

图 40：NDMP－Filer到磁带库

优点：

Ÿ 简化了安装和配置

Ÿ 无需额外软件即可提供动态磁带机共享

Ÿ 磁带设备支持不再依赖于Filer上运行的Data ONTAP版本

缺点：

Ÿ Filer之间的备份性能高低将取决于网络带宽

Ÿ 可能需要额外的网络基础设施来提高性能

Ÿ 由于处理TCP/IP而略微增加了CPU的使用率

1.1.2 技术特点

作为NDMP协议的共同创始者，NetApp的存储设备提供了业界最为完善的NDMP支持，支持版本从V2，V3到V4。并且可以兼容主要的支持NDMP协议的磁带设备。

NetApp的NDMP备份可以实现LAN Free的备份，备份产生的数据流量经由磁带设备和Filer存储设备之间的专网（GE或FC）传输。从NDMP备份服务器到Filer存储设备的NDMP控制数据流流量非常小，对前端的网络环境没有影响。

在SAN的应用环境中，传统的备份是需要在主机侧安装备份软件代理，如果需要减少备份对运行性能的影响，还需要在主机上增加1个单独的HBA卡构建专用的备份SAN。这样的方式不仅成本高昂，而且网络实现非常复杂。这种备份是LAN Free的备份，但是需要在主机册运行备份的代理，会占用一定的主机资源。NetApp的备份技术在SAN的环境中还可以通过在Filer上的快照，SnapDrive和NDMP的集成，可以实现通过Filer直接对SAN中的数据实施基于NDMP的备份，不仅可以实现LAN Free的备份，同时也可以实现Server Free的备份，减少对主机的资源消耗。从而进一步提升主机的工作效率。

1.1.3 技术优势

完整的NDMP技术方案，支持从直连，Filer到Filer，Filer到服务器。

NDMP和Filer的紧密集成，包括Snapshot快照，SnapRestore快照恢复，基于Qtree的备份。

1.1.4 系统要求

Ÿ NetApp的FAS900；FAS200；NearStore R200系列统一网络存储产品均支持NDMP协议和六种NDMP的使用方式。

Ÿ 系统软件版本DataOnTap 6.3以上。

SnapShot是WAFL文件系统“任意位置写入”功能带来的一项突出优势。 一份SnapShot是文件系统的在线只读拷贝。创建文件系统的一份SnapShot仅仅需要几秒种的时间，并且除非原始文件被删除或者更改，数据快照并不占用额外的磁盘空间。这种只有当数据块发生改动时才进行数据块复制的技术被称作“copy-on-write”，只有修改活动文件系统中的数据块并写入磁盘中新的位置时，SnapShot才会占用额外的磁盘空间。

用户可以采用SnapShot作为数据的在线备份，以备将来进行数据恢复时使用。用户也可以方便的把SnapShot快照备份到磁带上。无需将Filer系统下线，用户管理员就可以将最近的SnapShot快照备份到离线存储系统中。

图 28：Snapshot的创建

图 ( a )是简化了的文件系统结构，在顶部以树状结构指向其下的数据块。图 ( b )显示了SnapShot快照复制了根结构以及数据块指向关系。图 ( c )数据块C发生了更新，这样文件系统指向新的数据块C’，而在此之前创建的SnapShot仍然指向原来的数据块C。

该图展示了SnapShot是如何工作的。WAFL文件系统本身就可以理解成数据块树状结构，其根部的数据结构描述了inode文件信息。这份inode文件信息则包含了对文件系统中所有inode的描述，它包含诸如空闲块图和空闲inode图等元数据信息。图a也可以视为整个文件系统的概貌图，其上部展现的就是根数据结构。WAFL通过复制根数据结构创建新的数据拷贝SnapShot。因为根数据结构只有128B，并且不需要在硬盘上复制其它数据块，一个新的SnapShot几乎不耗费额外的磁盘存储空间，除非用户修改或者删除文件系统中的数据。

Filer可以对一个卷组创建最多255个SnapShot快照。SnapShot快照可以通过手动或者人为预先定制策略的方式来自动创建。每一个SnapSHot快照可以保存的时间取决于文件系统变动的频度。在众多应用环境中，文件系统中的大部分数据并不是每天都在变化，比如一个使用10MB大小Home Directory的用户，其数据通常每天只变动100到500KB。当文件变动缓慢的时候，SnapShot可以在线保存数天甚至数周，直到它们消耗的磁盘空间过多以至用户无法接受。而另外一些文件系统中的数据则在经常不停的变动，比如CAD应用环境下，需要经常覆盖写入许多大尺寸的文件，甚至可能一两天内就会更新整个文件系统的存储内容。在此类环境下，可能只有保存数小时SnapShot的空间。

用户对SnapShot的访问方式

文件系统中含有包含SnapShot数据快照的子目录，允许用户自行访问稍早些时候创建的SnapShot数据快照。假设一个用户从文件系统中意外删除掉一个名为foo的文件，现在需要利用SnapShot来对其加以恢复。则可以在UNIX/NFS客户端执行以下操作：

% ls -lu .Snapshot/*/foo

-rw-r–r– 1 hitz 16787 Jun 16 15:00 .Snapshot/hourly.0/foo

-rw-r–r– 1 hitz 16744 Jun 16 12:00 .Snapshot/hourly.1/foo

-rw-r–r– 1 hitz 16811 Jun 16 10:00 .Snapshot/hourly.2/foo

采用-U选项查看三份SnapShot数据快照，用ls命令可以显示文件foo的创建时间，要恢复foo文件，用户只需将foo不同时期的快照版本复制回当前工作目录即可。

% cp .snapshot/hourly.0/foo .

将.snapshot / hourly.0中的文件列表，将显示创建hourly.0数据快照时包含的所有文件。

.snapshot目录是隐藏目录。 如果.snapshot目录可见，可以使用find命令找到更多符合要求的数据快照副本。但是类似强制删除目录的命令，如rm –rf对SnapShot快照目录无效，因为SnapShot文件是只读文件，所以不能删除。

Windows用户则可以在窗口中看到一个名为~snapshot的文件夹，如下图所示：

图 29：Snapshot

能否理解WAFL文件系统是由root inode引导的数据块树状结构是能否理解SnapShot的关键。由此，要对这种数据块树状结构创建副本，即创建SnapShot，WAFL只需复制root inode。

图 30：WAFL通过复制描述inode文件的root inode建立一张SnapShot快照，WAFL通过在新的磁盘位置上写入新的数据来避免改变数据块。

图中(a)显示了文件系统树状结构图，为简便起见，只示意出了root inode，没有描绘出inode和间接数据块。

图中(b)显示了WAFL如何通过对root inode做一个完全相同的拷贝来建立新的SnapShot快照。这个复制而成的inode就是代表SnapShot数据块树状结构的root inode，和实际文件系统的root inode结构相同。当创建了SnapShot的inode之后，它所指向的数据块与实际文件系统root inode所指向的数据块完全一致。所以除了inode本身占用的空间之外，新建的SnapShot并不会占用额外的空间。

图中(c)显示了当一个用户修改数据块D时，文件系统中发生的变化。 WAFL在数据块D’上面写入新的数据，并将活动文件系统指向新的数据块。而SnapShot仍然指向原有的未经修改的数据块D。随着活动文件系统中的文件越来越多的被加以修改，SnapShot中所包含的活动文件系统不再使用的数据块也就越来越多。文件变动的频度决定了SnapShot可以在磁盘上保留的时间长短，以免耗费过多的磁盘空间。

如果将WAFL的SnapShot数据快照与IBM TransArc Episode文件系统中所采用的fileset clones文件集克隆铲平加以比较，会立即得到有利于证明WAFL SnapShot性能优异的结果。在IBM TransArc Episode这种UNIX兼容文件系统中，如果执行数据快照类的功能，会带来十分可观的磁盘读写I/O，并且会消耗大量的磁盘空间。例如，一个10GB的Episode文件系统中，为描述磁盘中每一个4KB的数据块，所有的inode会耗用320MB的磁盘存储空间。在这种性能指标下，如果需要通过复制inode的方式创建SnapShot数据快照，将会产生320MB的磁盘I/O请求，并且消耗320MB的磁盘空间，试想一下，如果我们需要创建10个这样的SnapShot数据快照，则意味着即使活动文件系统中的数据没有发生任何改变，也要消耗掉几近1/3的磁盘空间（320MBX10约合3.125GB）。

与之对比的是，WAFL文件系统中的情况则截然不同。如上所述，WAFL可以迅捷的创建SnapShot数据快照并且只占用极小的硬盘存储空间，即复制root inode所耗用的空间。举个例子，为防范系统非正常停机，WAFL需要每隔几秒种就对文件系统创建一个一致点，即内部的SnapShot。

为更加有效说明WAFL中的这种SnapShot特性，下图展示了上图(b)到(c)两种状态之间的转换过程，当一个数据块发生改动的时候，它的内容将会被写到新的磁盘位置上，其父数据结构必须转而映射到这块新的空间上。父数据结构的父数据结构也要映射到新的空间上来，直到数据块目录树的根部，也都必须如此。

图 31：数据块发生改动的时候

如果WAFL像我们描述的为每一个NFS请求写入如此多的数据块，它的效率将会十分低下。但WAFL的做法与之不同，它事先收集数百个与此类似的请求，然后再一个写入周期中统一完成。在写入周期中，WAFL为所有这些请求一并分配磁盘空间并且执行磁盘写入计划。

在期间写事件，WAFL为了所有高速缓存中的肮脏的数据分配盘空间并且为需要的盘我与O.确定时间，作为结果一般修改块，诸如间接的块并且阻塞在inode文件中，仅仅代替被写一次每写事件一次每NFS要求。这种操作方式带来的结果就是一些常规的操作，如间接数据块和inode中的数据块只在每一个写入周期中发生一次，而不是每次NFS请求的时候都会发生。

数据块图文件（ Block-Map File）

大多数文件系统使用位图的方式，即对每一块磁盘块使用1个数位，来标注空闲数据块。如果该数位被使用了，那么意味着这个数据块是在被使用。这种机制在WAFL中并不适用，因为多个SnapShot可以同时指向一个数据块。WAFL的数据块图文件可以对每一个数据块采用32个数位来描述其路径。第0个数位记录了活动文件系统对数据块的映射，第1 个数位记录了第1个SnapShot对数据块的映射，以此类推 。如果一个数据块的块图文件中的任意一个数位被标注，则代表它已经被使用。

下图展示了一个典型的数据块图路径生命周期，在t1时刻，数据块图路径未加使用，证明该数据块目前还是可用的。在t2时刻，WAFl分配了磁盘空间，在该数据块上存储了文件数据。在t3、t4时刻，WAFL创建了SnapShot快照。在t5时刻，该数据块被从活动文件系统中删掉了，这可能是由于包含该数据块的文件被删除了，或者数据被更新，新的内容被写到了磁盘新的位置上。除非创建新的SnapShot数据快照，该数据块将不能被再次使用。而t8时刻则显示了所有的SnapShot均被删除后的情况。

图 32：数据块图路径生命周期

关于创建SnapShot的更多解释

向磁盘中写如一份SnapShot数据快照的难点在于如何才能避免阻碍将发生的NFS请求，具体来说，新产生的NFS请求可能会需要更新缓存中的数据（这些数据是SnapShot的一部分）而这些数据在存入磁盘之前又恰恰是不能更改的。一种比较简单的解决方法就是延缓响应NFS请求，写入SnapShot，然后继续响应NFS请求。但是，写入SnapShot需要1秒左右的时间，对NFS请求来说，这种延迟已经是太长了，由此会带来性能的问题。

WAFL中保持SnapShot快照数据自一致的技术是在高速缓存中将所有更改过的数据标明为IN_SNAPSHOT。 在创建SnapSHot数据快照期间的规则则是标注了IN_SNAPSHOT的数据不可被修改，而未标记的数据则不能被写入到磁盘。NFS请求可以读出所有的文件系统数据，并且可以修改未标注IN_SNAPSHOT记号的数据。而那些需要修改IN_SNAPSHOT数据的请求则必须被延缓。

为了避免阻碍NFS要求，WAFL必须尽可能迅速的处理IN_SNAPSHOT数据。 为此，WAFL执行下列的步骤：

(1)为所有包含IN_SNAPSHOT数据块的文件分配盘空间。

WAFL在两个位置高速缓存inode数据：核心inode数据保存在专有inode缓存中，在磁盘缓冲中保存inode文件。当WAFL结束对某文件分配空间后，它将新近更新的inode信息从inode缓存复制到相应的inode文件磁盘缓冲中去。并且清除核心inode数据上的IN_SNAPSHOT标记。当此步完成后，所有常规文件的数据块上均不带有IN_SNAPSHOT标记，并且大多数的NFS操作不会受到任何阻碍。因为该项操作不需要磁盘I/O，它可以很快完成。

(2)更新块图文件。对每一个块图路径而言，WAFL将会把代表活动文件系统的数位标注复制成代表新SnapShot的数位标注。

(3)将所有标注了IN_SnapShot的磁盘缓存信息写入到它们新近被分配的磁盘空间中去。当某一特定的磁盘缓存被清空后，WAFL就可以启动响应等着修改该缓存的NFS请求。

(4)复制root inode，创建代表新的SnapShot的inode，并且取消root inode上面的IN_SnapShot标注。新SnapShot数据快照的inode尚不可写入磁盘，直到SnapShot中所有其它数据已经被写入。这条规则必须遵循，以免带来不可预料的SnapShot不一致情况。

一旦写入了新的SnapShot数据快照inode，高速缓存中将不再包含任何IN_SNAPSHOT标注，那些被暂缓的NFS请求也可以继续处理。在正常的负载状况下，WAFL在少于1秒的时间中执行这四个步骤。 步骤( 1 )一般地能在几百分之一秒中完成，当WAFL完成这项操作后，只有很少的NFS操作将会延迟。

删除一份SnapShot数据快照也极为容易。 WAFL可以简便地清除代表SnapShot快照的root inode，并且清除在块图路径中代表SnapShot的每一个数位标志。

1.1.2 系统要求

Ÿ NetApp的FAS900；F800；FAS200；NearStore R200系列统一网络存储产品均支持SnapShot功能。

Ÿ 系统软件版本DataOnTap 5.0以上。

Ÿ 硬盘区块验证系统 (Block-level checksum)，当有一颗硬盘故障时，RAID系统可保护资料不会流失，但是硬盘无故障时，如果某个硬盘的区块 (Block) 资料有错误时，RAID将无法侦测与更正，此时读取的的资料将会错误。WAFL内建硬盘区块验证系统 (Block-level checksum) 功能，在RAID所写入资料的Block都会加写checksum在每颗硬盘上，每次读取资料时都会同时检查checksum值。若检查不符时，就会利用RAID的Parity将该Block进行修复与更正，如此所读出的资料就可得到正确性的保障了。（专利申请中）

Ÿ 硬盘扇区检查系统 (Disk scrubbing)，每周WAFL会自动自我扫描检查每颗有资料的硬盘所有区块，检查的周期与时间长度亦可自行调整，于所定的时间内未完成时，也会在下次检查时继续未完成的部分。如此可以提早剔除将会故障的扇区，提供更安全、稳定的硬盘环境，更进一步降低风险。

Ÿ 文件系统线上检查系统 (Online File System Check)，一般的文件系统检查都必须在离线状态下才能进行（例如 fsck 和 scandisk），不仅需要漫长的等待时间，更造成服务的中断，文件系统容量越大时，服务停顿的时间就越长。为避免任何可能造成文件系统错误的因素，同时避免因着检查而让服务中断，WAFL具有独步全球的线上进行文件系统检查的能力，进行检查时仍可正常提供资料服务，达到同时兼顾安全、不带来服务停顿的效果。

1.1.1 增强型RAID4+

RAID技术原来分为RAID 1到RAID 5 等几级。最常使用的是RAID 1，3和5。

RAID 0，过去一些人使用其来指磁盘条带化，它基本上是没有校验盘的RAID 4机制。由于磁盘条带之间没有数据冗余，使用RAID这个名词容易引起误解。

RAID 1是简单的磁盘镜像。所有数据在两个单独的盘上重复存在。RAID 1十分安全，但加倍了磁盘存储的成本。

RAID 3是与RAID 4类似，在每组盘中使用单一的校验盘，但是RAID 3中条带划分较小，使得每一个操作都要跨越阵列中所有的磁盘。例如，一个块数据中的第一个字节可能在第一个盘上，第二个字节在第二个盘上，诸如此类。 RAID 3经常处于磁头同步状态以减少等待时间，RAID 3适于单一大文件以高数据率进行读写的应用，诸如超级计算机和图形图像处理。 对于多用户并行发起众多互不相关磁盘操作的应用则不适宜。作为对比， RAID 4盘组中的每一个数据盘都可以同时满足一个单独用户的请求。

RAID 5与RAID 4类似，但与RAID 4拥有独立校验盘不同，RAID 5在阵列中所有磁盘上存储校验信息。RAID 5的主要的优势在于它可以防止校验盘本身成为读写瓶颈。主要的缺点是不能方便的将一块新磁盘添加到现有的RAID组中。如果要向已有的磁盘组中加入新盘，必须加入一个新的磁盘组。如果一个RAID 5盘组采用8个盘构成，那么新加磁盘必须以8个为一组，一次性添加。

NetApp Filer使用WAFL Optimized intelligent RAID 4(增强型RAID 4) 提供硬盘保护机制。传统的RAID 4、 RAID 5中对文件系统的结构与应用考虑的并不是很多。NetApp采用的增强型RAID4与以上介绍的WAFL文件系统结合非常紧密，并经过了专门的优化。通过同时优化文件系统与RAID机制，NetApp RAID在提供RAID保护机制的同时，没有带来类似RAID 5的性能损耗。 同时，RAID结构可以迅速、简便的加以动态扩充。

通过增强型RAID 4，如果一块磁盘上的一个数据块损坏，盘组中的校验盘将重新计算该数据块上的数据。并且该数据块将被映射到磁盘中新的位置上。如果某个磁盘整体损坏，校验盘能防止任何数据丢失。当替换损坏的磁盘时，校验盘被将自动重新计算其内容。

增强型RAID 4阵列在同一个盘组中使用一个磁盘作为校验盘，其它作为数据盘。 每个磁盘均划分为4KB大小的数据块。一道磁盘条带包括每个数据磁盘的一个数据块和校验盘的数据块。条带中任意一个数据块的数据丢失，均能通过校验计算重新得出。

图 5：增强型RAID 4 磁盘布局

以上图片数字展示了Filer中的增强型RAID4阵列中的条带是如何划分的。我们可以通过简单的数学运算模拟RAID机制。如：

校验数据 数据1 数据2 数据3

12 3 7 2

如果数据盘之一失败，例如“数据2”，数据然能通过简单的算术计算重建：

数据2 = 校验数据－数据1－数据3

= 12 － 3 － 2

= 7

实际上，RAID系统中不是采用加减运算，而是采用异或运算来实现RAID功能。 但是如果一个条带中出现两处错误，则无法用这种方法重新计算出所有数据。需要依靠下文介绍的NetApp专利技术—RAID DP。

1.1.2 消除校验盘瓶颈

面向UNIX和Windows等操作系统的RAID外围设备厂商较少采用RAID 4，因为在通用文件系统下，RAID4校验盘容易成为瓶颈。但是WAFL文件系统利用其灵活的“任意位置写入文件布局”特性，继承了RAID 4固有的优势，并且避免了其校验盘瓶颈，最大限度的发挥了RAID 4的效率。

WAFL不同于通用文件系统的一个例子是，伯克利快速文件系统（FFS）设计中专门为一次写入一个文件做了优化。结果是可以为不同的文件把数据块散布到磁盘的不同位置上。 下图左半部显示了FFS如何为不相关的三个文件分配RAID阵列空间。当例子中每块数据盘仅仅写入2次时，校验盘要做6次写入。 更重要的是，校验数据写入分布过于分散，导致磁盘寻道时间消耗。

图 6：伯克利快速文件系统（FFS）和 WAFL文件系统写入空间分配特点

由于通用文件系统，如上图所示的FFS，并不是专门为RAID 4文件布局设计的，它趋向于散布写入数据盘，引发校验盘的过度寻址操作，从而带来瓶颈。

而 WAFL文件系统的设计方式确保能够最大限度地减少校验盘寻址操作。 上图右半部对比显示了WAFL如何分配同样的数据块，从而使得RAID 4更加有效。 WAFL总是把相关的数据块写到彼此邻近的条带中，消除校验盘上的长时间寻址操作。只要可能，WAFL也把多重数据块写到同样的条带中，从而进一步减少校验盘上的阻塞。FFS在上图左半部中使用六道独立的条带，因此致使六个校验盘块需要更新。 上图右半部中，WAFL使用仅仅3道条带，即只有三个校验块需要更新。从而大大提高了RAID性能，消除了校验盘瓶颈。

1.1.3 RAID DP

传统的单一奇偶校验RAID技术，能为单个故障磁盘驱动器提供保护。需要警告的是，在重建故障磁盘时必须确保不能发生其他磁盘故障，而且不能在读操作过程中出现不可修复的误码。如果在重建过程中出现上面任何一种事件，那么保留在RAID阵列或卷中的部分或所有数据就可能会丢失。随着现代更大的磁盘存储介质的出现，由于磁盘容量显著增加，而误码率仍是原来的水平，这就使得出现不可修复的误码的可能性相当高。因此，传统的单一奇偶校验RAID保护数据的方法已经超出了其保护极限。更高一级的RAID数据保护已经发展到RAID双奇偶校验，也称作RAID DP，它可以应用于整个网络应用数据存储产品线。

从DATAONTAP™ 6.5版开始，NetApp推出了双奇偶校验RAID，叫做RAID DP。本文给出RAID DP的概览和RAID DP如何在各种磁盘故障情况下动态提高数据的容错性。其他所涉及的关键领域包括RAID DP的费用是（它是免费的）、特殊硬件要求（无），以及如何将现存的RAID4卷升级到RAID DP（非常容易）。这里将借助对双磁盘故障的恢复情形来说明RAID DP如何做到允许卷既能不间断地提供数据，又能同时对两块故障磁盘上损失的数据进行重建。

在最基本的层面上，RAID DP为卷中的每个RAID组增加了第二个奇偶校验磁盘。 RAID组是建立卷的基本结构。每一个传统的NetApp RAID4组都有一些数据磁盘和一个奇偶校验磁盘，而一个卷通常会包括一个或多个RAID4组。 而RAID4卷上的奇偶校验磁盘则通过RAID4组上的磁盘对行奇偶校验进行存储，额外的RAID DP奇偶校验磁盘则通过RAID DP组上的磁盘存储对角线上的奇偶校验。 通过RAID DP上的这两个奇偶校验条，（一个传统的水平奇偶校验和一个对角线奇偶校验，即使同一RAID 组上的两个磁盘发生故障时也能得到数据保护。

在RAID DP中，仍然使用了传统的RAID4水平奇偶校验结构，并且这种结构已成为RAID DP结构的子集 换句话说，RAID DP并没有改变RAID4在NetApp存储上的工作方式。数据通过每一行的奇偶校验计算被写入水平行，并被视作双奇偶校验中的行，这个同样的过程仍会保留到RAID DP中。实际上，如果是单一磁盘故障，或是从坏数据块中的读取错误，或者出现误码，那么RAID4的行奇偶校验方法就是进行数据恢复的唯一手段，无需采用RAID DP。在这种情况下，RAID DP的对角线奇偶校验组件仅仅是行奇偶校验组件周围的保护层。

RAID4水平行奇偶校验

下列图表说明了在传统NetApp RAID4解决方案中使用水平行奇偶校验的方法，也是您了解RAID DP和双奇偶校验的第一步。

图 7：RAID4水平行奇偶校验

图表代表了传统的RAID4 组，使用包括4个数据磁盘（前4列，标注为“D”）和一列奇偶校验磁盘（最后一列，标注为“P”）的单向奇偶校验。上面图表中的行显示了实施传统NetApp RAID4时使用的标准4KB块。 上面图表中的第二行在每个4KB 块和行中数据的奇偶校验计算中添加了一些样例数据，随后存储在奇偶校验磁盘上相应的块中。 在这种情况下，计算奇偶校验的方式是向每个水平块中添加值，然后将这些值的和存储为奇偶校验值（3 + 1 + 2 + 3 = 9）。实际上，奇偶校验是通过专门的OR（XOR）过程进行计算，但其它情况也与此例非常相似。如果需要从单一故障中重建数据，则产生奇偶校验的过程将与此相反。 例如，当RAID4 恢复上面第一列的数据值3时，如果第一个磁盘发生故障，就会从奇偶校验中存储的值中减去剩余磁盘上的值（ 9- 3 – 2 – 1 = 3）。 这个通过单一奇偶校验RAID重建的例子，应该有助于从概念上理解为什么能够对单一磁盘故障提供数据保护。

添加RAID DP双奇偶校验条

下表将一个以蓝色阴影块表示的对角线奇偶校验条和一个在第六列中以“DP”表示的第二个奇偶校验磁盘添加到前面的RAID4 组中。这表示RAID DP结构是RAID4水平行奇偶校验解决方案的超集。

图 8：RAID DP双奇偶校验条

在这个例子中对角线奇偶校验条通过相加的方法计算，并且存储在第二个奇偶校验磁盘上，而不是上面所说的实际使用的XOR（1 + 2 + 2 + 7 = 12）。此时，需要注意的最重要的问题是，对角线奇偶校验条包括一个来自行奇偶校验的元素作为其对角线奇偶校验和的一部分。RAID DP将把最初在RAID4结构中的磁盘（包括数据和行奇偶校验磁盘）视作相同的磁盘。下一个图表为每个块加入了余下的数据，并且建立了相应的行和对角线奇偶校验条。

图 9：RAID DP

从上图可以明显看出，在RAID DP中，对角线奇偶校验条都在行奇偶校验结构的边缘。在这个例子中，对于RAID DP对双磁盘故障进行恢复的能力，有两种重要情况可能不是很明显。第一种情况是，每一个对角线条会错过唯一的一个磁盘，但是每个对角线错过的磁盘都不一样。第二种情况的结果是，在第二个对角线奇偶校验磁盘上会产生或存储一个没有得到奇偶校验的对角线条。 在这个例子中，被遗漏的对角线条是白色的块。在之后的重建例子中会明显的看出，遗漏一个对角线条不会影响RAID DP在双磁盘故障中恢复所有数据的能力。

值得重视的是，在本例中介绍的许多同样的RAID DP对角线奇偶校验都是真实的存储情况；其中涉及到在RAID组中的许多磁盘上，以及通过 RAID4组水平写入成数百万的数据行。并且，通过上面较小的例子我们很容易地例证了RAID DP，而且不管RAID 组中的有多少磁盘，对于大尺寸的RAID组，其恢复情况也与此相同。

由于RAID DP可以通过两种方式对双磁盘故障进行所有数据的恢复：一种是使用数学原理并进行证明，另一种则是简单地通过双磁盘故障并随后进行恢复。 本文将使用后面的方法来证明RAID DP的双奇偶校验保护的概念。使用数学原理和证明的方法，超出了本文对RAID DP的叙述范围，但我们在另外一篇文章中单独进行了描述，而且即将在NetApp的外部网站上发布。

RAID DP的重建

我们使用最近的图表开始介绍双磁盘故障。假定在发生双磁盘故障时，RAID组运行正常。在下表中，第一、二列中的所有数据都丢失了。

图 10：RAID DP的重建（1）

当发生双磁盘故障之后，RAID DP首先会寻找一个链来开始重建。在本例中，我们用蓝色的对角线奇偶校验条来显示其所发现的链。不要忘记，当在RAID4下为单一磁盘故障重建数据时，只有在丢失的元素不超过一个时，这种情况才会发生。记住这一点之后，我们可以看到上图中蓝色对角线条中只丢失了五个块中的一个。借助五个元素中仍然存在的四个，RAID DP能够获得所需的全部信息，来重建蓝色丢失块中的数据。接下来的图表反映了这些数据被恢复到空闲的磁盘上。

图 11：RAID DP的重建（2）

从丢失的蓝色对角线块中重建数据时，使用了前面介绍的算法（12 – 7 – 2 – 2 = 1）。现在，丢失的蓝色对角线信息已经被重建，恢复过程从使用对角线奇偶校验转换至使用水平行奇偶校验。特别是，蓝色对角线之后的顶端的行重建了丢失的对角线块，而没有足够的信息从行奇偶校验中重建单个丢失的水平块(9 – 3 – 2 – 1 = 3)。这种情况出现在下列图表中。

图 12：RAID DP的重建（3）

RAID DP接下来继续处于同样的链中，以决定是否能够重建其他的对角线条。上面左方的块被行奇偶校验重建，使得RAID DP现在能够重建灰色对角线条中相对的对角线块，如下图所示。

图 13：RAID DP的重建（4）

再一次，当RAID DP恢复了对角线条中相对的对角线块后，它就有了足够的行奇偶校验信息，来重建第一列中丢失的水平块，接下来的图表中例证了这个情况。

图 14：RAID DP的重建（5）

与我们前面所注意到的一样，白色对角线条没有被存储，现存的链中也没有额外的对角线块能够重建。RAID DP将开始寻找新的链以开始重建对角线并且，基于这个例子，决定了其能够重建黄色对角线条中丢失的数据，如下图所示。

图 15：RAID DP的重建（6）

在RAID DP重建了丢失的对角线块之后，这个过程再次从行奇偶校验转换至重建丢失的水平块。当黄色对角线中丢失的对角线块被重建后，可以得到足够的信息重建行奇偶校验中丢失的水平块，由下图可以明显看出。

图 16：RAID DP的重建（7）

水平行中丢失的块被重建之后，重建转换回对角线奇偶校验以创建丢失的对角线块。RAID DP能够继续处于当前的对角线链中如下图所示。

图 17：RAID DP的重建（8）

同样，在对角线块恢复之后，因为有足够的信息重建一个水平块信息，这一过程将会转换回行奇偶校验。接下来是双磁盘故障情况的最后一个图表，通过RAID DP所有的数据都被重建了。

图 18：RAID DP的重建（9）

RAID DP卷的性能可以与RAID4相媲美。每种类型的RAID的读操作几乎一样。RAID DP的写操作性能要比RAID4慢2%到3%。造成性能微小差距的原因是RAID DP卷上的第二个对角线奇偶校验磁盘会出现额外的写操作。 相对于RAID4，运行RAID DP时CPU的利用率并无明显差别。
 

1.1.4 SyncMirror

信息是公司最宝贵的资产，因此确保信息的安全和可用性是优先考虑的重要任务。为了最大程度体现信息的价值，必须保持信息始终是最新的，以便向决策者提供开展业务所需的知识，提高运营效率，加强客户关系，发掘新的市场机遇。如果无法访问最新的信息，组织就无法根据当今经济发展的要求迅速应变，从而在竞争中处于十分不利的局面。

NetApp SyncMirror 确保您的数据在任何时候都可用并且是最新的。SyncMirror 通过联机维护两个数据副本，保护您的数据不受到任何类型的硬件故障包括三磁盘故障的影响。在与 NetApp Clustered Failover 高可用性解决方案一起使用时，SyncMirror 使您可以获得最高的数据可用性，这一程度的数据库可用性以前只能通过大型机体系结构才能获得。此外，NetApp 解决方案易于管理并经济合算，提供无与伦比的投资回报率。

具有完全冗余性的最高的数据可用性

SyncMirror 在您的镜像数据的两个副本之间保持严格的物理分隔。在出现无论是由磁盘问题、缆线断线还是主机总线适配器 (HBA)引而发的故障时，SyncMirror 都可以即时访问镜像的数据，而操作员不必干扰或中断客户端应用程序的运行。业务连续性得以确保，并且您可以找到造成问题的原因并解决问题，而不必中断您的运营，避免代价高昂的停机时间。

特点

优点

同步复制

确保数据副本始终是最新的并且可用于您的本地数据中心。

透明的操作

使所有应用程序都可以访问同步复制的数据，而不需要编程或更改系统。

与 Clustered Failover 集成

通过自动故障转移提供完全硬件冗余性，以提供最高的数据可用性。

表 2：SyncMirror的特点和优点

灵活、高效并易于使用

SyncMirror 与 Data ONTAP™无缝集成。您管理镜像数据 方式可以和管理 Filer 上其它数据的方式相同。 除了提供最高的数据可用性之外，SyncMirror 还使您可以通过简单的命令分离数据副本，以便镜像的数据可由其它应用程序使用。 这向您提供了使用最新生产数据进行备份、应用程序测试和数据查找的绝佳的解决方案。您可以使用镜像的数据执行这些后台任务，而不会影响您的生产环境并同时提高工作效率。

图 19：SyncMirror 与 Clustered Failover

将 SyncMirror 与 Clustered Failover 配置中的 Filer 一起使用来复制数据，可提供最高的数据可用性、完全冗余性和自动故障切换功能。

技术优点

Ÿ 最高的数据可用性

Ÿ 完全冗余性

Ÿ 最新的镜像

Ÿ 自动故障切换

Ÿ 对应用程序是透明的

Ÿ 灵活且简便

图 20：SyncMirror 与单个 Filer

将 SyncMirror 与单个 Filer 一起使用来复制数据，可以用最新的镜像创建冗余的存储子系统，从而提供高数据可用性。

1.1.2 系统要求

对于RAID-DP，需要如下的配置：

Ÿ FAS900 ；FAS200；R200；F800系列硬件平台

Ÿ Data ONTAP™ 6.5 及更高版本

对于SyncMirror，需要至少如下的配置：

Ÿ FAS900 系列硬件平台

Ÿ Data ONTAP™ 6.5 及更高版本

Ÿ SyncMirror软件

NetApp的文件系统名为WAFL，是专为Filer系统而设计的。WAFL是”Write Anywhere File Layout”，即”任意位置写入文件布局”的缩写。WAFL文件系统和Filer的整合式RAID管理采用一体化设计，以避免大多数带有RAID管理机制的文件系统所固有的性能问题。

网络化存储实际应用中的三个基本要求决定了需要为NetApp Filer设计全新的文件系统：

文件系统应该更加有效地操控RAID机制

增加新的硬盘时，文件系统应该能够相应的动态增长

文件系统应该不需要做消耗大量时间的一致性检查

在这些基本要求之上，引申出了支持数据快照(Snapshot)的要求。

NetApp于1995年5月提出专利申请，在1998年10月获得专利（专利号码：5,819,292），题目为《Method For Maintaining Consistent States of A File System and For Creating User-Accessible Read-Only Copies of A File System》，前半部分就是有关WAFL的内容，后半部分则关于数据快照(Snapshot)技术。另一项专利于1995年6月申请，在1998年9月获得专利（专利号码：5,948,110），题目为《Method For Providing Parity In a RAID Subsystem Using Non-Volatile Memory》，这就是如何利用NVRAM来加速RAID，并保护RAID数据的一致性。WAFL采用有电池保护的NVRAM（非易失性内存）来担任其日志(journal)，并藉由consistency points提供文件系统一致性(consistent) 的保证，在非正常断电或关机时，重新开机后可在2分钟内开始提供服务，不需要执行文件系统检查，也不用担心文件系统会损毁。WAFL结合NVRAM、RAID、Snapshot的设计难度极高，故从1992年至今仍未有其它厂商可以做到。

WAFL的主要特点及其所带来的优势包括：

永远一致性的文件系统：任何时刻文件系统均处于一致性的状态，即使遇到非正常断电或不正常关机后，也不需执行硬盘检查，即可在复电后2分钟内迅速提供服务。

具电池保护的NVRAM日志：利用存取速度较硬盘快一千倍的内存，担任文件系统的日志，同时保护metadata及data的交易纪录，并加速写入的效率和反应时间、保证文件系统的一致性、保证写入的交易不会因断电而流失。

内建智能型最佳化的RAID磁盘阵列管理系统：配合NVRAM日志功能，藉由硬盘区块的配置最佳化，可将大量的随机写入转为少量的循序写入，真正达到平行写入 (Stripe Write) 并减少磁头移动的次数和磁头移动的距离的目的，加速文件存取和搜寻的速度。

能增长的文件系统：不需其它软件的协助，就可直接实时动态线上扩增文件系统容量且立刻能使用新增加的容量。每次可只增加一块硬盘或多块硬盘的方式来扩增，完全不需要停机，也不需要等待时间。另外也可在不扩增容量的前提下，动态线上提高文件数量的上限，完全不需要停机，也不需要等待时间，也不影响系统运作效率。

瞬间快照备份 (Snapshot)：使用不需要移动硬盘区块的WAFL专利技术，可瞬间备份整个文件系统，每个volume可有255份快照，每个使用者都有自己专属的一个快照目录，可自行恢复只属于自己在任一快照时间点的资料，完全不需系统管理人员的协助。每个快照备份皆是完整的文件系统备份 (Full File System Backup)，不论已有多少份数的备份，系统运作效率皆不受影响。

WAFL作为专门为网络文件访问而优化的UNIX兼容文件系统。在某些方面，其磁盘格式类似于其它UNIX文件系统，如伯克利快速文件系统（Berkeley Fast File System，以下简称FFS）和IBM TransArc Episode文件系统，相似之处包括：

WAFL是基于数据块的，使用没有片段的4KB大小数据块

WAFL使用inodes来描述其文件

WAFL文件系统中，目录是格式特殊的文件

像IBM TransArc Episode文件系统一样，WAFL使用文件来储存元数据（Meta Data）。WAFL三个最重要的元数据文件是：

inode文件，包含文件系统所有的inode

块图文件，用以识别空闲块

inode图文件，用以识别空闲inode。

这里采用”图”而不是”位图”的称谓，因为这些文件采用多于1位（bit）对每一个路径加以描述。

其中，每一个WAFL inode包含16个块指针，用以表明哪一个数据块属于该文件。不同于伯克利快速文件系统，一个WAFL inode的所有块指针指向的是相同层次上的数据块。这样，对于小于64KB的文件，inode使用16个块指针指向文件数据块；大于64MB的文件，inode使用块指针指向间接数据块，间接数据块再指向实际的文件数据块。较大文件的inode指向更多的间接数据块。对于十分小的文件，数据储存在inode本身。

简单的，可以把WAFL理解为数据块树型结构，在树的根部是root inode，root inode是用以描述inode文件的特殊inode。inode文件包含描述系统中其它文件的inode，包括块图和inode图文件。WAFL文件系统数据块树型结构的树叶是所有文件的数据块。如下图所示：

图：WAFL的树型结构示例图

图中显示，文件由不同的数据块组成。较大的文件在inode和实际数据块之间存在额外的间接层次。WAFL要启动的话，必须要找到该树型结构的根部，所以对于WAFL（任意位置写入文件布局）来讲，root inode是个例外，它必须处于硬盘上的固定位置以便WAFL定位。使用文件来保存元数据的方式带来的好处有：

允许在硬盘上任何地方写入元数据块。这就是WAFL名称的起源。与FFS类似，WAFL在其写入分配策略上有着完全的灵活性，数据块不是被永久地分配到固定的磁盘位置上。WAFL利用了这种灵活性来优化Filer的RAID性能。WAFL可以事先规划对同一RAID条带进行多重写入的时间，这样当仅仅更新RAID某一硬盘条带中某一数据块时，就不会对整个写入性能带来损耗。在有关RAID的章节中，详细描述了WAFL采用的旨在有效利用增强型RAID4的写分配策略。

使文件系统的增长变得十分容易。当增加新的硬盘时，Filer可以自动增加元数据文件的大小。如果系统的缺省值稍小，管理员也可以手动增加文件系统中的inode。允许元数据块在硬盘上任何地方写入。这种方式使得SnapShot数据快照功能成为可能。要使SnapShot可以工作，WAFL必须可以把新的数据，包括元数据写入到新的硬盘空间上，而不是覆盖原有数据。如果WAFL在磁盘上固定的位置存储元数据，这项功能就不可能实现。

1、批次动态条带化读写算法

WAFL文件系统中采用批次动态条带化读写算法。在UNIX或者Windows文件服务器中，写入性能尤其重要，因为它必须直接面对硬盘(或非易失性内存)，而读操作尚可以面对UNIX/Windows客户端和服务器的高速缓存。这就使得UNIX或者Windows客户端和服务器的硬盘写操作要比读操作多5－10倍。如Ousterhout机构的一项观测证明，当服务器端和客户端高速缓存增大的情况下，对写入操作的响应主导了I/O子系统的处理过程。其影响是NFS服务器上的磁盘写操作可能比读操作多5倍（相关内容见于Ousterhout 89报告）。

这种需求特点，激发了WAFL在最初的设计中，即最大限度的发挥了写入分配策略的灵活性。WAFL文件系统中，通过批次动态条带化读写算法的三种机制，保证了这种灵活性的实现：

Ÿ WAFL能把文件系统的任何数据块(除包含root inode的数据块外)写到磁盘中的任何位置上。而在FFS中，诸如inode、位图和元数据被保存在磁盘中的固定位置上，这就妨碍了文件系统写入性能。例如，对某一新近更新的文件，不能将它的数据块和inode在磁盘上的紧邻位置加以存储。而WAFL则相反，它可以在磁盘上的任何地方加以写入，从而创造性的优化了写入性能。

Ÿ WAFL能把数据块按任何顺序写到磁盘中。与之对应的，FFS仅能把数据块按确定的顺序写到磁盘中，在中断之后可以通过fsck恢复文件系统的一致性。因为WAFL文件系统的映像文件只有在写入一致点信息时才会改变，所以WAFL能按任何顺序写入数据块。

Ÿ WAFL能在单一写入周期内为多个NFS操作同时分配盘空间。而FFS需要为NFS请求一一分配空间。WAFL在确定文件系统一致点之前可以收集数百个NFS请求，在一致点（consistency points）时刻立即为其分配空间。这种延缓分配写入空间的机制通过从应答处理的过程中去除磁盘分配时间，大大改进了NFS操作的等待时间。对于那些在到达磁盘前即被删除的数据块而言，这种方式也避免了时间的浪费。

这些特性赋予了WAFL文件系统特别灵活的写入策略。为众多写入同时分配空间的能力使其更加智能化，允许将数据快以任何顺序写入到任何地方的能力又确保了这种策略适用于多种环境。概要地讲：

Ÿ WAFL通过将多数据块写入到同一条带中的方式，大大提高了RAID的效率与性能

Ÿ WAFL通过将相关的块写入到相近的位置而大大缩短了寻道时间

Ÿ WAFL通过将顺序的块放置在RAID阵列中某个单一磁盘上的方式，减少了大文件读出时的磁头冲突

在通常的文件系统下，优化写分配是很困难的，因为以上这些目标之间经常冲突，而WAFL则可以很好的解决所有问题。

2、NVRAM

为在磁盘上保存完整的文件系统一致性版本，WAFL文件系统至少每10秒会生成一个内部数据快照SnapShot，称为一个一致点(consistency point)。当时Filer启动时，WAFL总是使用时间最近的一致点版本，这意味着即使发生掉电或者其它严重系统错误后，系统再次投入正常运转也无需耗时的文件系统检查工作。Filer在仅仅1到2分钟的时间内即可正常启动，而这段时间也主要是花费在磁盘定位和内存检查上。

这种特性是由于Filer使用了由电池支持的NVRAM（非易失性内存）来避免丢失最近一致点之后可能发生的任何NFS与CIFS请求。其工作示意图如下：

图：NVRAM工作示意图

NVRAM是带有电池的独特内存，即使切断电源，仍然可以存储数据。在不正常停机之后，WAFL重演所有”日志”以防丢失。日志类似于线上交易处理(OLTP) 数据库系统的Log记录。WAFL采用内存，而不是硬盘来保存日志，因为比硬盘快一千倍，提供极高的响应速度。即使有大量的交易，响应速度也不会变慢。当使用者的写入要求送到NVRAM并完成时，马上可以接受下一笔的写入要求，又可同时保护metadata及data的交易纪录。当NVRAM收集这些写入要求到达某种条件时，WAFL会先经过计算并整理过后再批次写入到硬盘。其工作情况大体如下：

Ÿ 当Filer正常关闭时，NVRAM不包含任何未处理的NFS请求，它被自动关闭以延长其电池寿命。

Ÿ 在正常系统关闭规程下，文件管理器先关闭NFS与CIFS服务，将所有缓存中的操作写入磁盘，然后关闭NVRAM。

Ÿ 在系统掉电或者其它非正常状况下，系统将会自动重现保存在NVRAM中，但是尚未转存到磁盘上的NFS与CIFS请求。

如上所述，WAFL通过创建内部SnapShot来避免系统在不正常停机后对文件系统进行检查，这种特殊的SnapShot叫做一致点，每过几秒钟就会自动创建一次。不同于其它SnapShot快照的是，一个一致点没有名字，而且不能通过NFS协议访问它。同于其它SnapShot快照的是，一致点是整个文件系统的一个完全自一致的映像。当WAFL重新启动时，它简单地回放为最近的一致点。即使单一分区中包含20GB或者超过20GB的数据，这项特性依然使得Filer可以在1到2分钟的时间内重启。

在一致点之间，WAFL也在把数据写到磁盘中，但是它仅仅写到不使用的块中，如此呈现的数据块树型结构的最近一致点仍然是完全不变的。在两个一致点之间，WAFL需要处理数百或者成千上万的NFS请求，因所以磁盘上面的文件系统映像在数秒内会保持不变，直到WAFL写入新的一致点。磁盘上面的文件系统映像也会自动更新。虽然这项技术在UNIX文件系统中比较少见的，但它在数据库领域是比较常见的。但即使在数据库领域，像WAFL这样在同一时刻的一致点中写入如此多的操作也是比较少见的。

WAFL实际上把NVRAM划分成为两份独立的日志报告。当一份日志写满，WAFL转换到另一份日志，并且开始写一致点，将与第一份日志的差异安全地记录到硬盘上。即使日志没有写满，WAFL每10秒也要写一次新的一致点，以防止硬盘中存储的文件系统映像太过陈旧。

利用NVRAM记录NFS请求的方式比传统的利用NVRAM为磁盘做读写缓存的方式有很多好处。NetApp Filer使用NVRAM来存储未提交NFS请求的方式则与其它一些UNIX产品十分不同：

Ÿ 其它操作系统把NVRAM作为磁盘缓存，并在磁盘层加以使用时，包含的是关键的文件系统一致性数据。如果NVRAM发生故障，即使采用fsck也无法恢复系统状态。

Ÿ WAFL使用NVRAM作为文件系统的遍历来源，而不是需要利用硬盘来加以更新的高速缓存。WAFL对NVRAM空间的使用是非常有效的，例如，要求文件系统创建一个文件的请求仅需使用数百个字节即可描述。而实际的文件创建操作则可能包含着众多的数据块改变。因为WAFL使用NVRAM记录操作的遍历信息，而不是操作结果本身，这就使可以在Filer NVRAM日志文件中执行得数千个操作。

我们来对以上两种机制做一下比较。其它厂商利用硬盘当作日志，只能保障硬盘区块的运作，不能确保网络文件系统交易的安全与完整性，当遭遇网络暂时中断或系统宕机，恢复联机与运作后，中断的网络文件系统交易已经流失。不仅速度无法与NVRAM匹敌，也无法同时保护metadata及data的交易纪录不会流失。

两种不同方式的对比示意图如下：

图：NVRAM与其它厂商技术方式的对比

第一种，是处理NFS请求并将其结果写入磁盘缓存，第二种，是NetApp NVRAM采用的，对那些需要重演的请求，记录下其日志信息。举例来比较，如果从一个目录移动一个文件到另一个目录，文件系统必须更新内容以及来源、目标目录的inode。在FFS中，每一个块是8 KB，这项操作将使用到32 KB的高速缓存空间。而WAFL仅使用大约150个字节空间，简单的记录下需要对该信息执行更名操作。WAFL可以在每MB的NVRAM中记录多于千项操作。

记录NFS请求的最终优势是它大大提高了NFS响应时间。为了响应NFS请求，没有NVRAM的文件系统必须更新它的内存数据结构、为新数据分配磁盘空间，但是它们只是把修改后的数据复制到NVRAM中，而不是磁盘中。相比之下，WAFL能更迅速准确的响应NFS请求，因为它只需要更新其内存数据结构并且记录访问要求，而不需要为新数据分配磁盘空间，也不需要把修改后的数据复制到NVRAM中。

第一是接口部分，包括网络接口(GbE-Fiber/Copper, TCP/IP Offload Engine) 和光纤接口(2Gb-Fibre Channel)。
第二是通讯协议部分，包括File Protocol (NFS, CIFS, HTTP, DAFS) 和Block Protocol (FCP, iSCSI)。
第三是文件系统WAFL和整合式RAID磁盘阵列系统(Integrated RAID Manager)。

图：Data ONTAP原理图

Data ONTAP的基本构成图如上。包含一系列紧密连接的处理模块，用以响应NFS、CIFS和HTTP请求。访问请求起始于网卡，通过网络协议层和文件系统，最终发起硬盘I/O请求。当文件系统完成该对请求的响应，会向网络层发送应答信息。

与大多数UNIX系统一样，DataONTAP的网络层协议栈最早起源于Berkeley源码，并针对Filer文件系统访问优化的需要进行了代码优化。Filer支持TCP/IP (包括UDP )协议，同时也支持其它种类的协议。在图中顶端，管理层以类UNIX命令行的方式支持对下面各层的监控和调度。除图中展示的各个模块之外，DataONTAP通过精炼的多任务实时微核系统（micro kernel）提供诸如进程创建、内存分配、消息传递和中断处理等基本服务。Data ONTAP是Network Appliance公司研发的一个具有多项独家知识产权的软件产品。其通过结合专利的文件系统WAFL和微核的设计，对网络数据访问提供优化的存储服务。

每个企业都需要保护其至关重要的数据，而直接从主存储器备份到磁盘上则是一种传统的数据备份方法。采用这种方法的一个主要问题在于，它必须在非高峰时间进行以保证在线主存储器的工作不受影响。而且数据的增量以及磁盘备份时间的紧缩更加重了这一问题，从而使全球企业的处境更糟。

从磁盘中恢复数据又引发了另一难题：当您的所有应用程序和业务都处于下线状态时，数据恢复将既费力又耗时。

NearStore™ R200是NetApp公司用于在线备份和存档的经济高效、快速读取的存储系统。使用 NetApp NearStore 程序的数据保护结构因直接备份到磁盘而解决了上述问题。通过在应用存储器和磁盘库之间插入经济、易用的磁盘存储器，NearStore™极大程度地在两步备份操作配置中完善和改良了既有的磁盘备份程序。

NearStore™是近线存储，在主存储器和磁盘库之间以每兆计费的形式快速读取数据。很多种主存储器的数据可以通过本地或者广域网络备份或存档至NearStore™中。几乎任何一种主存储器上的数据都可以备份至 NearStore™服务器（UNIX/Windows 等）；RAID和JBOD存储器；桌上型和笔记本电脑；以及NetApp文件管理器上。NetApp SnapVault软件和NearStore™的组合提供了功能强大、无与伦比的NetApp存储备份方案。

图：三层存储构架

解决方案的主要特点是：

改进和加速数据备份

直接备份到NearStore™，然后再备份到磁盘增强了数据保护管理功能，也改进了主存储器和磁盘库的性能。直接备份到 NearStore™同直接备份到磁盘相比速度更快，占用应用程序服务器CPU更小的空间。而且，还通过简化从NearStore 到磁盘的备份提高生产率，并因不采用主存储器而扩大了传统备份窗口。

象 SnapVault 一样利用增量程序块传输将数据备份至 NearStore 的软件还有其它一些好处。低的网络带宽占用率使远程系统备份几乎可以在所有WAN上进行。另外，这些解决方案在NearStore上可以更有效地备份数据。

这些性能和管理功能的改进更加降低了对数据备份资源的要求和成本。

数据恢复更迅速

故障后数据恢复是企业的一个重要任务。使用NearStore，较高的生产量和快速的数据存取使得数据恢复比从磁盘恢复速度更快。另外，通过保存在 NearStore上备份的数据，您可以经常恢复单独文件，而不必重新安装整个备份的数据。使用 NearStore 您可以在几分钟后重新开始企业业务，从而减少突发事件所带来的影响。

在线存档

NetApp NearStore 使得在线存储不常读取的数据成为可能。它还以比高端磁盘和光学系统更低的成本提供更快的数据读取服务。具备 NetApp 的简捷和可靠性能，NearStore以最低的管理成本提供了强大的存档功能。NearStore 是 e-mail存档尤其突出的解决方案，同时它还可以存储医学和卫星图片、MCAD 绘图、整合芯片设计和主目录等。现在您可以让您所有的有用数据上线了。

易于安装和管理

NearStore R200 可以装配到现有的数据存储结构中，其配置从8TB 直到 96TB。同 NetApp DataFabricTM Manager 的整合使得其对100TB 系统管理更简便、直接和高效。

1.2、硬件特性

NearStore R200系统使用和FAS960相同的机头。NearStore 的系统结构如下所示。

96TB的系统配置图示：

48TB的系统图示：

16TB和8TB的系统图示：

NearStore 200系统包括：

Ÿ 2x 2.2GHz Intel Pentium 4处理器

Ÿ 6GB DDR-DRAM系统内存

Ÿ 256 MB NVRAM-4

Ÿ 远程控制卡（Remote Management Card – 标配）

Ÿ 9 PCI-X 100扩展槽，提供6套PCI-X 100总线

Ÿ 最多6块GbE卡或10/100/1000b-T卡

Ÿ 最多4块双口GbE卡或10/100/1000b-T卡

Ÿ 最多6块DAFS卡

Ÿ 最多2块双SAN连接卡

Ÿ 最多336块 ATA磁盘

Ÿ 最多96TB的裸盘容量

Ÿ 最大单卷容量16TB

1.3、产品亮点

驱动器和系统容量均采用 Network Appliance 惯用的每吉字节 (GB) 等于 1,048,576,000 字节来说明。行业标准是每 GB 等于 1,000,000,000 字节。要计算等同行业标准的容量，请用 NetApp 规格乘以 1.049。

1.4、系统规格

适用于为进行磁盘架连接只用 SCSI 主机总线适配器配置的基本系统。

1.5、系统环境规范

1.6、NearStore R200系列用于存储和磁带设备的SAN连接的FC交换机支持

1.7、NETAPP系统机柜

1.8、法规

1.9、对NearStore R200系统磁带机的支持

接口类型：FC 或 FC-AL = 光纤通道；LVD = 低压差动；HVD = 高压差动；SE = 单端；SE 和 LVD 不能在适配器上混用。

1.10、每个SCSI通道建议使用的磁带机最大数量

今天的全球性企业需要在发生自然或人为灾难、操作员出错或是技术和应用出现故障的情况下，保护数据并快速进行恢复。它们还需要一个有效的方式将数据发布到远程位置。如果没有有效的数据保护和发布策略，运作过程可能会被迫中断，导致数百万美元的收入损失。

NetApp SnapMirror 软件具有强大的功能，而且易于使用和管理，它满足了当前的全球性企业对灾难恢复和数据分布解决方案的需要。通过在 LAN 或 WAN 上高速复制数据，SnapMirror 软件将尽可能地为关键应用程序提供最高的数据可用性和最快的恢复速度。

SnapMirror 技术将数据镜像到一个或多个网络 Filer 上。 SnapMirror 不断地更新镜像数据，以确保数据是最新的，并且能够用于进行灾难恢复、减少磁带备份、发布只读数据、在非生产性 Filer 上进行测试、执行联机数据迁移等等。如果您的企业分布在不同的地点，而所有地点都需要访问培训录像和 CAD 工具等相同的数据集，SnapMirror 可以将同一数据发布到所有地点。通过自动更新这些数据，并支持对镜像数据的本地访问方式，SnapMirror 可以大大提高员工的工作效率。

节省宝贵的网络带宽

NetApp SnapMirror 软件具有许多节省带宽的功能，可以降低数据复制和灾难恢复的基础设施成本。您可以先用磁带执行一次整卷数据传输，然后再用那些磁带在远程位置装入数据。之后，您只需要通过网络对新的数据块和更改的块进行增量更新。由于只需复制所有 Filer 数据的一小部分，SnapMirror 大大降低了对网络带宽的需求。此外，SnapMirror 在数据传输过程中会设置检查点。如果系统出现故障，传输会从最近的检查点重新开始。SnapMirror 还会执行智能的重新同步过程，这样，在从镜像损坏的状态或不同步的状态进行恢复时，无需传输整卷数据。如果在应用程序测试期间修改了镜像副本上的数据，可以将生产系统上的新数据块和更改的数据块复制到镜像副本，使镜像副本快速实现与生产数据的重新同步。

灵活的配置

NetApp SnapMirror 可以方便地部署到任何具有足够的带宽来处理数据传输的网络基础设施中。它能够支持多种传输方式（FC 和 IP），这一点确保可以更好地利用现有设备，并且还因能够实现路径间的容错而提高了可用性。

SnapMirror 允许客户选择适当的同步级别（同步、半同步和异步），从而实现了较高的灾难恢复保护级别。例如，如果选择“同步”选项的话，远程站点的复制数据将始终是最新的，并能在发生故障后随时提供。这一方式简化了灾难恢复过程，降低了系统宕机时间。而“半同步”允许客户根据站点的需要，确定有多少 I/O 操作可以失去同步，或者是复制站点可以在多长时间内与数据源失去同步。而“异步”选项则允许您根据需要（每分钟、每小时或每天）任意安排传输过程。您可以设置最适合每一站点的频率。时间安排很容易修改，而且修改后可以立即生效。您还可以为源系统和镜像系统选择不同的 Filer 配置。源系统可以是具有 6TB 存储空间的集群 Filer，它将 2TB 的关键数据镜像到另一种型号的 Filer 上。此外，得益于级联和多跃点镜像方式，NetApp SnapMirror 目标卷可以作为其他目标的源卷，而且每个“镜像对”都可以有自己的时间安排以满足各个站点的特定需求。如果需要远距离复制数据，级联镜像是非常理想的解决方案。例如，如果是从纽约将数据复制到巴黎、罗马和伦敦，您可以将数据从纽约复制到伦敦，然后使用低成本链接将数据从伦敦复制到巴黎和罗马。

图：SnapMirror：级联方式的配置

使用 SnapMirror，可以将数据高效和经济合算地复制到远程站点，以便进行灾难恢复或数据分布。

易于使用，经济合算

用户在几分钟内就可以设置好 SnapMirror，并能通过易于使用的 DataFabric® Manager (DFM) 图形用户界面进行管理和操作。Filer 支持 SnapMirror 软件，您不需要再安装其他软件。通过内置的 SNMP 支持功能，可以方便地与 SNMP 框架进行集成。

2 技术特点

快速数据复制和容错—将主站点发生故障的宕机成本降至最低。

访问镜像数据—减少磁带备份，让您在灾难恢复上的投资物超所值。

卷或 Qtree 复制—镜像选定的数据集，大大降低了对网络基础设施的要求。

选择复制过程的同步级别—采用一个产品即可控制复制的频率（异步、同步或准同步）。

更有效地利用网络—降低了数据复制和灾难恢复的成本。

设置简便—几乎不需要增加 IT 资源；可以经常测试灾难恢复计划。

SnapMirror可以用于：

灾难恢复—将数据镜像到远程位置以实现容错。

 数据分布—使用级联或多跃点镜像方式，将数据集发送到世界各地。

远程数据访问—应用程序能够以只读模式访问镜像数据。

联机数据迁移—将数据迁移导致的宕机时间减到最少。

数据复制—使用镜像数据可以进行隔离测试。

同步的数据复制—保证各站点间关键数据的一致性。

负载均衡—通过访问镜像数据，在更多的客户端之间分摊负载。

实现一致的数据保护—使用 SnapLock™ 软件，能够在 Worm 卷之间实现完全一致的复制。

3 技术优势

NetApp的SnapMirror支持多种复制方式，用于适应不同的容灾环境，包括：同步，准同步，异步。异步方式的复制对于距离没有限制。

SnapMirror支持多种网络环境，用于适应不同的容灾环境，包括：IP接口和FC接口。

SnapMirror支持多种拓扑方式的复制，包括：1对多；多对1；级联复制等。

SnapMirror支持对多种数据的复制，包括：基于卷的复制，基于qtree的复制，支持对NAS / SAN /iSCSI中的数据复制。

SnapMirror只传输变化的数据块，可以大大节省网络带宽和减轻Filer的负载。

4 系统要求

NetApp的FAS900；F800；FAS200；NearStore R200系列统一网络存储产品均支持SnapMirror功能。

 同步SnapMirror要求源Filer和目标Filer必须采用相同大小和转速的磁盘。

在FAS系列和NearStore系列产品之间必须部署异步的SnapMirror功能。

FAS250只能实施基于IP端口的SnapMirror。

系统软件版本DataOnTap 6.5.1以上。

Snapshot：实用程序用于进行联机备份，

SnapMirror：软件用于进行自动化复制，

SnapRestore： 软件用于进行快速恢复，

SnapVault：用于进行集中的异构企业存储联机备份。

用户还可以从多种磁带 SAN 和符合 NDMP 的第三方磁带备份解决方案中进行选择。不管选择了什么样的方法或配置，NetApp Filer 都会为所有数据保护操作提供优化的处理能力和性能。

备份解决方案
Network Appliance 提供一套独特的解决方案，这套解决方案可以显著降低保护和恢复关键任务数据所产生的操作成本和宕机时间：

· Snapshot技术，用于日常联机备份。系统管理员全天都可以执行备份，而不是只能在晚上或周末进行备份。只要从 Snapshot 目录复制所需的文件，用户或管理员就可以恢复意外删除的文件。

· SnapMirror软件，用于自动化的文件系统或配额树复制。SnapMirror 可以传输全天增加的更新内容，以在另外一个 Filer 或另外一个站点保存整个文件系统或配额树的镜像，从而确保不会因电源故障或自然灾害而丢失数据。镜像的副本还可用于执行磁带备份。

· SnapRestore软件，用于将单个文件或整个文件系统快速恢复为以前某个状态。只需几秒钟，SnapRestore 便可以将单个文件或整个文件系统恢复为以前存储的 Snapshot 副本。如果数据库被损坏，或者如果由于病毒、应用程序或用户错误导致数据被破坏，则可以使用该恢复机制。

· SnapVault?软件，用于对异构企业存储环境进行基于磁盘的扩展集中备份。通过将多个 Snapshot 存储到 SnapVault 辅助系统（NetApp Filer 或 NearStore 设备），企业可以联机保留数月的备份，以便于进行快速恢复。SnapVault 还使用户能够选择备份哪些数据集、备份的频率以及备份的保留时间。

· Dump 软件，用于备份到磁带。符合 NetApp BSD 的 dump 命令是 Data ONTAP 操作系统中的一个本机命令，可用于将 Filer 数据备份到磁带。该命令可用于备份目录、配额树和整个卷，可以通过命令行、脚本或支持 NDMP 的应用程序调用该命令。

· Restore软件，用于从磁盘进行恢复。NetApp restore 是 Data ONTAP 操作系统中的一个本机命令，可用于从使用 dump 命令创建的磁带恢复数据。Restore 命令可用于恢复单个文件、目录、配额树或整个卷。可以通过命令行、脚本或支持 NDMP 的应用程序调用该命令。

· 网络数据管理协议(NDMP) – 一个简单高速的开放式协议
磁带为保护公司数据提供了多种额外的备选方法。标准的转储和恢复实用程序可用于将 Filer 数据复制到磁带，而 Network Appliance 第三方备份合作伙伴提供了不同的全功能、高性能的备份选择。这些备份解决方案使用 NDMP 同时实现简单的操作和卓越的性能。基于 NDMP 的解决方案使您可以集中管理和控制备份，选择在本地或通过网络进行备份，并提供对混合服务器环境（UNIX? 和 Windows NT?）的支持，同时对现有的备份策略进行投资保护。

· 开放式存储网络(OSN) 的先河
NetApp 的策略是提供业界最好的存储网络产品解决方案。我们致力于研究完整的技术以及这些技术中深入的专业知识。我们洞悉存储网络对客户的价值，并且本身已拥有强大的实力，我们坚信这些将使 NetApp 成为业界领袖。对于 NetApp 和我们的客户来说，这是令人激动的一步前进，因为我们已经成为客户今天以及未来选择的关键解决方案的一部分。

o 光纤通道磁带 SAN。体现光纤的性能、灵活性和安全性的最新技术。这些解决方案可以实现磁带资源的最佳利用。

o 千兆位以太网磁带 SAN。利用现有的基础设施并能够在规模和带宽方面进行调节，这些都是实现较低成本和方便实施的因素。

详细内容请点击下载。

[download=34]

Ø 以计算机为核心

Ø 存储是计算机的外设

Ø 无所谓存储系统，只有存储子系统

存储系统三要素

Ø存储介质(storage): 磁盘, 磁带, 光盘

Ø传输通路(wiring): SCSI, FC, 网络

Ø存储管理(filing): 文件系统, RAID管理, 存储资源管理(SRM), 虚拟化(Virtualization)

应用系统进行I/O存取的模式

文件级传输：应用系统的I/O逻辑请求，它是文管系统的输入。是应用系统要对存储做什么的逻辑请求。文管系统决定数据（包括META数据）在磁盘上的存放格式和位置，这种格式和位置又决定磁头的移动方式。

块级传输：应用系统的I/O物理请求，它是文管系统的输出。是怎么对存储操作的数据块请求。 RAID控制使文管系统看到一个大逻辑盘。 它不管磁盘格式。

完成PPT内容请点击下载

2007年第2季度存储系统整体市场存储出货量为5148.3TB，相比上季度增长了5.1%，市场价值为13.7亿元，相比上季度增长了10.5%，本季度高端存储出货量有所增加。与去年同期相比，存储出货量增长了26.2%，市场价值增长了23.4%，存储市场已经进入高速发展期,预计今后三个季度仍将保持20%以上的同比增长率.

厂商格局

EMC市场增长显著,本季度以24.7%的存储出货量超越IBM,排在存储出货量的首位置,IBM和HP分别以23.7%和22.4%的市场分额排在存储出货量的第二第三位.Netapp,增长显著,超越HDS成为存储出货量排名第五.

从市场价值上来看,EMC以显著的增长排在首位,占市场分额的24.7%,IBM和HP分别以23.6%和22.1%的市场份额排在第二和第三.

技术趋势

存储软件将越来越成为存储产品销售的重要影响因素，存储硬件厂商不应只单一的发展硬件产品，应将更多的资源投入在存储软件的研发上。有实力的存储厂商可考虑收购小的存储软件开发商来壮大自己的实力。

存储产品在使用中很难脱离服务器独立存在，行业客户在选择相应的整体解决方案时，更倾向于选择服务器和存储可以自身整合的产品。专业存储企业的产品类型过于单一，其产品对其他企业的服务器和软件产品依赖较多，存储厂商应向全面和整合发展。

用户需求

电子邮件归档、NAS管理和广域网优化等将是新兴的存储市场，厂商应予以关注。