COW:
1)原卷數據是A~G。此卷Metedata像指針一樣指向這些數據。
2)當做快照時,重新復制一份Metedata,並且也指向這些A~G數據。
3)當有數據要寫入到源卷時(下圖寫入D'),寫入到D的原位置之前,需要把D拷貝出放到一個新位置。然后修改快照的Metedata的其中一個指針指向拷貝出的位置[D](圖中是Snapshot data的存儲位置)。同時,把D’寫入到D原來的位置。

此方式可以看出,源卷的Metedata的是沒有變化的。對原卷是連續的數據,多次快照,多次寫之后還是 連續的數據,因此讀性能或者對單個位置的多次寫性能都不會有很大的影響。
但是, 快照的數據是非連續的,如數據ABCEFG還是在源卷的位置,是連續數據。而數據D在存儲的其他位置,非連續。 如果多次快照,不同位置的多次讀寫后,快照的數據可能就比較混亂。造成對快照的讀寫延時較大。

COW最大的問題是對寫性能有影響。第一次修改原卷,需要復制數據,因此需要多一次讀寫的數據塊遷移過程。這個就比較要命,應用需要等待時間比較長。但原卷數據的布局沒有任何改變,因此對讀性能沒有任何影響。
ROW在傳統存儲情況下最大的問題是對讀性能影響比較大。ROW寫的時候性能基本沒有損耗,只是修改指針,實現效率很高。但多次讀寫后,原卷的數據就分散到各個地方,對於連續讀寫的性能不如COW。這種方式比較適合Write-Intensive(寫密集)類型的存儲系統
但是,在分布式存儲的情況下,ROW的連續讀寫的性能會比COW差嗎? 就不一定了。正常情況下,讀寫性能的瓶頸一般是在磁盤上。分布式存儲情況下,業務層看到連續存儲,實際上是分布在不同的服務器的不同硬盤中,數據越是分散,系統性能越高。而ROW把原數據打散之后,對性能反而有好處。
因此,整體情況下ROW基本上是對讀寫性能影響較小,因此是業界發展方向。
下圖是幾個廠家的快照實現方式:
目前分布式存儲比較流行,華為有個FusionStorage數據,說是無限次快照,而且0性能下降,vSAN快照10%~30%的性能下降。從上面的分析來看,就知道兩個場景的實現方法了。
快照另外一個非常重要的特性是快照一致性組(Consistency Group),這個功能就是支持多個LUN或者叫卷volume同時做快照,保證數據的一致性。
如果采用陣列的快照來做數據庫的備份,必須所有的LUN都是一個時間點的才行,這樣數據庫恢復的時候才能起來,否則數據庫必須回滾到某一個一致的時間點,意味數據的丟失。比較完美的做法就是在主 機安裝一個快照的agent,最好是多路徑軟件具備這個功能,在高端存儲要做快照的時候,對主機的快照agent說,別動, 要照相了。主機agent接受到攝影師的命令后,把ORACEL主機緩存的內容flush一下到陳列來,然后hold住,陣列也盡快把cache的內容 flush到硬盤里,ORACLE用到的所有硬盤一塊喊”茄子“,攝像師一按快門,一幅完美的快照就產生了。
一致性組除了保證照相的時候一致性外,還有恢復的時候要一致性恢復。這塊的實現的重要性就不如照相的時候重要,可以人工選擇同一時間的LUN快照恢復就可以了。最重要的是照相的時候必須要一致,而且這個人工干不了。