Using EMC snapshot example

试验环境为EMC CX500, IBM P610. 主要是对之前一些不清楚的snapshot特性进行验证。

在EMC的术语里, snapview包含两个部分: snapshot和clone.

snapshot是source LUN的point in time (PIT)copy. 而clone或snapcopy是source LUN的full copy.

通过测试，我们得出了一下的结论。

1)     snapshot cache LUN

snapshot cache LUN新的名称叫做reserved LUN pool, 与snapshot cache LUN不同，reserved LUN pool还用于SANcopy和异步的MirrorView.

由于snapshot利用的是copy on first write(CoW),。因此snapshot target LUN并不需要和source LUN具有同样的大小。snapshot cache的尺寸，根据经验值，通常为source LUN的20%。

snaoshot cache LUN必须在SPA和SPB上都分配。因为source LUN使用的snapshot cache LUN必须在同一个SP上。

2)     snapshot cache LUN的数量

每一个source LUN都需要且只需要1个snapshot cache LUN，而无论你对source LUN做多少个snapshot.

例如，你对1个source LUN做8个snapshot, 这时你只需要一个snapshot cache LUN.

但是，你如果需要对另外一个source LUN做snapshot时，你就需要配置另外一个snapshot cache LUN, 否则报错如下：

 

3)     snapshot recovery

这是一个应该慎用的特性。snapshot recovery是指利用snapshot copy, 将source LUN恢复成take snapshot时的那个状态。在做这个过程之前，必须保证source LUN是不可被操作系统读写的。例如，对于AIX而言，必须保证VG是varyoff的状态。

4)     snapshot session

简而言之，snapshot session启动的时间就是开始照快照的时间, 尽管这时snapshot并没有被activate。因此，快照记录的数据的状态实际上是session启动时的状态，而不是snapshot被激活时间的那个状态。(通过测试，已经证实。由于主机有限，可以将source LUN和snapshot映射到同一台主机，但在import快照时必须先chdev –l hdisk# -a pv=clear, chdev –l hdisk# -a pv=yes, 然后recreatevg)snapshot被activate的时间其实是可以被快照主机访问的时间，也就是从此时起，对快照的修改也会被记录。快照被激活时必须选择一个inactive的session. 一个session可以包含多个snapshot.

5)     session的类型

有三种，缺省类型，consistent和persistent.

persistent是在发生path failover时，snapshot也可以同时切换到available的路径上。而consistent是保持session中的所有snapshot都保持在session start时的一致映像。

The SnapView driver will delay any I/O requests to the set of source LUNs until the session has started on all LUNs (thus preserving the point-in-time restartable copy on the entire set of LUNs).

其实还是没有仔细看书，EMC SnapView for Navisphere - ADMINISTRATOR’S GUIDE中说到：

Each SP has its own reserved LUN pool, and before starting a session,

the reserved LUN pool must contain at least one LUN for each source

LUN that will be starting a session. ……Multiple sessions of a single source

LUN will share the same reserved LUN or LUNs.

 

A SnapView session is a point-in-time copy of a source LUN. The session keeps track of how the source LUN looks at a particular point in time.

 

After you start a SnapView session and as the production server writes to the source LUN(s), the software stores a copy of the original data in the reserved LUN pool in chunks. This copy is referred to as copy-on-first-write and occurs only once, which is when the server first modifies a data chunk on the source LUN(s). A secondary server can then activate (map) a snapshot to the SnapView session. The snapshot views the original source LUN data chunks that have been modified since you started the session from the reserved LUN pool and unmodified data chunks from the source LUN(s).

A snapshot is a virtual LUN and when activated, it allows a secondary server to view a SnapView session. An active snapshot is a composite of a source LUN and reserved LUN data that lasts until you destroy the snapshot. You can create a snapshot before or after you start a session; however, the snapshot has no use until a secondary server activates it to a session.

If the storage system loses power while the session is running, and the session is not running in persistent mode, the session is lost and the snapshot becomes inactive. If the session is running in persistent mode, both the session and snapshot would survive the storagesystem power failure. Note: Unless you have additional software that supports same host access, you must assign the snapshot to a storage group other than the storage group that holds the source LUN(s). You also must assign multiple snapshots of the same source LUN(s), to different storage groups. For information on software that supports same host access, refer to the “Prerequisites for setting up snapshots” on page 2-13.