NETapp Snapshot介紹

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的每一個數位標誌。

 

 摘自：http://www.sansky.net/article/2007-12-16-netapp-snapshot.html