NETapp Snapshot介绍 | 【存储部落】
A-A+

NETapp Snapshot介绍

2007年12月16日 网络存储 暂无评论 阅读 3,442 次

1.1.1 技术原理

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。

FIGURE

图 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)两种状态之间的转换过程,当一个数据块发生改动的时候,它的内容将会被写到新的磁盘位置上,其父数据结构必须转而映射到这块新的空间上。父数据结构的父数据结构也要映射到新的空间上来,直到数据块目录树的根部,也都必须如此。

FIGURE

图 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均被删除后的情况。

FIGURE

图 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以上。

给我留言

Copyright © 【存储部落】 保留所有权利.   Theme  Ality

用户登录 ⁄ 注册

分享到: