EMC SnapSure is an EMC  software feature that enables you to create and manage checkpoints, which are point-in-time, logical images of a Production File System (PFS).  Snapsure uses a copy on first modify principle. A PFS consists of blocks. When a block within the PFS is modified, a copy containing the block’s original contents is saved to a separate volume called the SavVol. Subsequent changes made to the same block in the PFS are not copied into the SavVol. The original blocks from the PFS in the SavVol and the unchanged PFS blocks remaining in the PFS are read by SnapSure according to a bitmap and blockmap data-racking structure. These blocks combine to provide a complete point-in-time image called a checkpoint (snapshot).

 Checkpoint (snapshots) types

A checkpoint reflects the state of PFS at the point-in-time the checkpoint is created. SnapSure supports two types of checkpoints:

• Read-only checkpoint
• Writeable checkpoint

SnapSure can maintain maximum of 96 read-only checkpoints and 16 writable checkpoints per PFS while allowing PFS applications continued access to realtime data.

 Key components of SnapSure

• Production File System (PFS)
• Snapshot (sometimes called checkpoint) – logical point-in-time view of data
• SavVol – Stores original data blocks to preserve the point in time view and holds modified blocks if a writeable snapshot is used
• Bitmap – identifies changesd data blocks in the PFS
• Blockmap – Records the address of data blocks in the SavVol
• Baseline Snapshot – read-only snapshot from which a writeable snapshot can be created.

Example with PFS, Bitmap, Blockmap and SavVol

Writes to PFS with snapshots

SnapSure example

Let’s break down what happened on example provided above:

1. There is a Snapshot (checkpoint) made on PFS.
2. User is changing data in PFS for blocks DB01, DB05, DB08
3. VNX is updating the Bitmap from 0 to 1 which indicates that this block was changed after snapshot  has been made
4. VNX is adding a row in Blockmap saying in which SavVol Block address, un-changed Data Block is held
5. VNX is putting original data (unchanged blocks) in SavVol

OK, that’s pretty simple and clear. Isn’t it? The fun starts when we have a second snapshot in the game.

SnapSure – second snapshot

1. When you create a second snapshot the Bitmap is zeroed and associated with second snapshot – remember only one bitmap per PFS
2. The Blockmap of first snapshot is preserved so we can retrieve the data from that snapshot later on (if needed)

Reads from PFS with snapshots

If we would like to read the oldest store data, it’s straight forwad, we read only from PFS (Production File System).

If we would like to read the data pointed to latest snapshot, VNX first read the bitmap, check what blocks has changed, and read unchanged data from PFS, changed data from SavVol (checking the location in Blockmap)

IF we would like to read the data from older snapshot (not the latest one!) we ignore the bitmap (because it only contains the information of changed data between right-now and latest snapshot. We start with this snapshot blockmap, and we read all blocks from SavVol that are pointed in blockmap. Later on we read from all newer blockmaps. If there is new value for already read block  we ignore them! We want to get the ‘oldest possible’ data counting from the snapshot we want to read from. Once we read from all Blockmaps we read remaining data from the PFS, because it will still be the same.

 SavVol Sizes

• Automatic SavVol sizes based on size of PFS
  • if PFS ≥ 20GB then SavVol = 20GB
  • if PFS < 20GB and PFS > 64MB then SavVol = PFS size
  • if PFS ≤ 64 MB then Savvol = 64 MB
• All snapshots of a PFS share the same SavVol
• A maximum SavVol size could be determined with manual SavVol creation.

SavVol Automatic Extension

Automatic extension is triggered by High Water Mark (HWM). This feature prevents inactivation of older snapshot. By default, the WHM is set to 90%, but this amount can be lowered if necessary. The maximum value of HWM is 99%, but anything higher than 90% is not recommended. Automatic extension can be manually disabled by setting the HWM to 0%.

If the SavVol was created using AVM, the SavVol space will be extended in 20GB increments until the capacity is below the HWM once more. If the SavVol was manually created, the automatic extension feature will extend the SavVol by 10% of the PFS. If there is no space left, and SavVol is 100% full, Snapsure will inactivate the oldest snapshots (beginning with writeable snapshots), untill enough space is reclaimed.

By default, SnapSure is not able to consume more than 20% of the space available to the VNX. This limit of 20% can be changed in /nas/sys/nas_param

SnapSure Additional Functions

• Schedule snapshot creation – quick tip. To nos schedule snapshot creation at 1 minute pass the hour- because that’s why the VNX is backing up its database and the snapshot creation can fail.
• Refresh snapshots – in other words, delete the selectedsnapshot and put the actual point-in-time situation of PFS on that place.
• Restore a PFS to a point-in-time. Nice feature is that we can restore single files.

One of the VNX Snapshot use cases is to promote a snapshot to be a standard LUn. To do that, the snapshot must be attached, and then the SMP (Snapshot Mount Point) can be migrated to another LUN.  IF a migrating SMP has any snapshots associated with it (for example Cascading Snapshots), all of them will be destroyed.

mount SMP to another host

Let’s discuss the case:

• Host1 is a production server running an application with PrimaryLUN1 provisioned.
• Host2 is a development server. This server must try a new version of the application on a copy of the production data
• The Administrator performs the following actions

1. Takes a snapshot ‘Snap2’ from the production PrimaryLUN1
2. Creates SMP for a snapshot from PrimaryLUN1
3. Provisiones SMP to Host2 (for example adds SMP to the storage group for Host2
4. Attaches Snap2 snapshot to SMP
5. Runs SCSI rescan on Host2
6. Creates a local drive on Host2

• At some point, SMP is snapped, and Snap2.1 is created

After some tiem of running development code on SMP, it is decided to promote it to an independent LUN. To do that, the Administrator performs the following actions:

1. Create a new LUN, ‘LUN temp’ that is the same size as PrimaryLUN1. The new LUN does not have to be a pool LUN, or be in the same pool. It can be any LUN that is supported by the VNX array
2. Starts a LUN migration session from ‘SMP Name’ to ‘LUN temp’
3. When migration completed coupe of things occure:
   1. SMP Name Snapshot Mount Point is deleted
   2. LUN temp is renamed to SNP Name and retains all the SCSI attributes of the Mount Point, including WWN and even HLU ID within the storage group
   3. Snap2.1 is destroyed

LUN migration of SMP

In this post I would describe in few sentences two technologies. One is VNX Snapshots and second is VNX SnapView Snapshot.

About Snapshots

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:

SnapView Snapshot vs VNX Snapshot – writes

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:

SnapView Snapshot vs VNX Snapshot – reads

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.

Snapshot granularity

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.

Snapshot Mount Point