In this post I would describe in few sentences two technologies. One is VNX Snapshots and second is VNX SnapView Snapshot.
Snapshot is a technology that gives you the possibility of creating point-in-time data “copies”. It’s important to understand that snpashot itself doesn’t copy the data right away, it cannot be used as a backup! But It (using different approches, like vnx snapshots, snapview, netapp snapshots etc.) gives you the possibility to preserve the data in given point-in-time, so after a while you have the possibility to roll-back to the exact situation while snapshot was taken.
Quick introduction to VNX Snapshots
VNX snapshots is a feature created to improve on the exisiting SnapVie Snapshot technology by better intergrating with pools. VNX Snapshots can only be used with pool LUNs.
LUNs created on physical RAID groups, also called classic LUNs support only SnapView Snapshots. This restriction will be easy to understand one we describe a difference between those two.
Another restriction is that VNX SnapView Snapshots and VNX Snapshot cannot coexist on the same pool LUN!
VNX Snapshot support 256 writeable snaps per pool LUN. IT supports Branching (sometimes called Snap of a Snap). A Snap of a Snap hirearchy cannot exceed 10 levels. There are no restrictions to the number of branches, as long as the total number of snapshots for a given primary LUN is within 256.
How Snapshots work
VNX Snapshots use redirect on write (ROW) technology. ROW redirects new writes destined for the primary LUN to a new location in the storage pool .Such an implementation is different from copy on first write (COFW) used with SnapView, where the writes to the primary LUN are held until the original data is copied to the reserved LUN pool to preserve a snapshot.
I have found a nice picture that help you see the difference between those two:
VNX Snapshot technology writes the new data to the new area within a pool, without the need to read/write to the old data block. This improves the overall performance compared to SnapView.
Similarly, during a read from a snapshot, the snapshots’s data is not constructed from two different places – look at another picture:
If the host read from a snapshot within the VNX Snapshot snap mount point will grab data from snapped data, while within SanpView Snapshot part of data are read from Source LUN (data that has not been overwriten), and old data are read from Reserve LUN pool.
Every VNX Snapshot has 8 kB block granularity. This means that every write occupies at least 8 KB on the pool. The distribution of the 8 kB blocks within a 256 MB slice is congruent with the normal thin write algorithm.
Snapshots and Thick LUNs
When a VNX Snapshot is created on a Thick LUN, portions of its address space are changed to indirect mode. In other words, when writes come in to the Snapped Thick LUN, the LUN starts converting address mapping from direct to 8KB blocks for each portion of the Thick LUN being written. The Thick LUN remains in and indirect mode while it has VNX Snapshots. When the last snapshot of the Thick LUN is removed, the mode automatically reverts to direct.
Snapshot Mount Point
Snapshot Mount Point (SMP) is a LUN-like container. It is used to emulate a typical LUN, but provides the ability for the host to write to snapshots and to change snapshots without the need to rescan the SCSI bus on the client. A SMP is created for snapshots of a specific LUN. This means that each XMP can be used only for snapshots of a single primary LUN. To enable access to hosts, SMPs must be provisioned to the storage groups just like a typical LUN.