Professional Documents
Culture Documents
Docu42148 White Paper VNX Snapshots
Docu42148 White Paper VNX Snapshots
Docu42148 White Paper VNX Snapshots
VNX Snapshots
Abstract
This white paper describes EMC VNX Snapshots.
The paper reviews and explains operations and
best practices for the feature, as well as limits and
functions.
July 2012
Audience
This paper is intended for EMC customers and EMC field personnel who
are familiar with VNX technology. The paper is intended to be used as a
main reference for VNX Snapshot technology.
Figure 3: VNX Snapshot pointing at the same blocks with the LUN at creation time
After a few moments, the primary LUN may receive an I/O that overwrites
block A. The first snapshot continues pointing to the original set of
blocks A, B, C, and D. After Snap2 is taken, it points to A`, B, C and D.
The next primary LUN I/O overwrites block D, and it now points to A`, B,
C, and D`.
Figure 4: VNX Snapshots point at unchanged blocks, Primary LUN is using new blocks
Create a Snap
Creating a snapshot does not consume any pool space. The space starts
being used when new writes to the primary LUN or the snapshot itseld
arrive. Snapshots have a granularity of 8 KiB, and thier blocks are
tracked just like the blocks in thin LUNs.
Every snapshot must have a primary LUN, and that property never
changes. A primary LUN cannot be deleted while it has snapshots. In
Unisphere, you can delete a LUN that has snapshots by selecting an
optional setting that deletes the snapshots first.
To create a snapshot:
1. In Unisphere, select Storage > LUNs.
naviseccli snap -create -res 1 -name "cli_snap" -descr "snap created via CLI"
# ^^^
# LUN ID
When you try to attach a snapshot that has the Allow Read/Write option
disabled, Unisphere automatically enables it and displays a warning.
Figure 11: Unisphere right mouse click Snapshot Mount Point creation
Creating an SMP does not require any space from the pool.
CLI guidelines
• Create the SMP on the same Storage Processor as the primary
LUN
• Set the -allowInbandSnapAttach parameter to "yes" to allow
SnapCLI host binary to attach the Snapshots (It is a security
feature. The Troubleshooting section provides more details.)
o This parameter can easily be modified at a later time.
• An SMP is added to a storage group just like a usual LUN.
Attach a Snap
Attaching is an asynchronous operation during which the SMP remains
available, but the I/O is queued. This means that that the host does not
have to rescan the SCSI bus to view the snapshot. The rescan is required
only to discover the SMP when it is first presented to the host.
Copy a Snapshot
A VNX Snapshot can be copied to another snapshot. The resulting
snapshot is a copy of the source except for the name. The -
allowReadWrite1 property is set to No on the copy.
The snapshot copy retains the source LUN properties and resides within
the same pool as the original snapshot. So, copying a snapshot
increases snapshot count by one.
1
This property is a security feature, preventing unauthorized mounting a snapshot for read/write operations.
Note: In Figure 14 and Figure 15, both SMPs may only be used for
Primary LUN1 Snaps. No other snapshots may be attached to them.
However, either SMP could be provisioned to any host..
However, when SMPs are also members of a CG, they can be attached to
only one consistent snapshot. Figure 24 displays a bad example that
does not work.
The main difference between Figure 24 and Figure 23 is that SMPs in
Figure 23 are not in a CG, and SMPs in Figure 24 are.
Restore
Snapshots can be used to restore a primary LUN or an SMP. In other
words, the data in the LUN will be changed to match the data in the
snapshot. The classic use case for this operation is when recovering
from data corruption.
Figure 27: Unisphere error on Snapshot restore due to the presence of a SnapView session
Restore a LUN
Certain prerequisite steps must be performed from the host operating
system for a successful LUN restoration. Operating Systems often have
cached metadata pertaining to the LUN's file system. Restore operations
tend to confuse memory maps unless the cache is cleared.
This affects most operating systems. The following is a sample
procedure to restore a LUN from a VNX Snapshot. Microsoft Windows
operating system is used as an example.
Step 1
Stop application access to the LUN. Optionally, you may need to flush
application buffers.
:: Optionally, one could flush a physical drive, when it is not a "drive letter"
:: Note, this command makes sense only when the drive is mounted,
:: e.g. has a drive letter assigned
SnapCLI flush -o \\.\PhysicalDrive1
Step 3
Unmount the drive. For some versions of Windows, unmounting refers to
removing the drive letter. Windows 2008 has an option to turn the drive
offline. This can be done either from Disk Management or from the CLI
(diskpart).
Note: Unmounting the drive guarantees that the host stops all I/O to the
LUN.
Figure 28: Windows 2008 Disk Manager -- switching a disk to offline mode
C:\>diskpart
DISKPART>
Step 4
Restore the LUN from Unisphere or by using naviseccli.
Note: SnapCLI does not allow restores for security reasons.
Step 5
Mount the drive (On Windows 7, assign a letter)
Restore CGs
When restoring a Consistent Snapshot to a CG, it is possible that the
member list of the current CG may be out of sync with the list of LUNs in
a Consistent Snapshot. This happens when a CG is extended with
additional members.
In this case, the array does not let users restore CG from a snapshot with
different CG members than the current member list. The CG must be
modified to match the member list of the snapshot, followed by another
restore attempt.
Repurpose Snapshots
Some snapshots may need to be repurposed for other use. For example,
when a primary LUN must be deleted, but one of its VNX Snapshots
need to be retained.
There are two ways to do that:
• Migrate the SMP to another LUN before deleting the primary LUN
• Detach a snapshot and then restore the primary LUN (from that
snapshot)
o The primary LUN may have a different HLU than SMP, or
may even be presented to another host. Make sure to
check where the data is provisioned.
o In addition, the primary LUN has a different WWN from the
SMP. So, if any of your tools or scripts are using the WWN
of the SMP/primary LUN, they must be updated.
Note: If any of the 'SMP Name' snapshots were attached, the LUN
migration would not have started. If 'SMP Name' had many unattached
snapshots, they would be deleted as a result of LUN migration.
Limits
• The maximum number of snapshots per primary LUN is 256. The
system displays an error if a user tries to create more snapshots.
The same error is displayed in the CLI.
• When a pool LUN has a VNX Snapshot and a SnapView Snapshot at
the same time, SnapView COFW takes priority over ROW. That
means that the "old" data is copied to the Reserve LUN Pool (RLP)
first, before the "changed" data is written. The data written is still
placed in the proper pool space, not within the pool LUN (as it
would have been if the LUN had not been a RAID group LUN.)
• A snapshot taken before primary LUN (thin LUN only) expansion
does not reflect the new size. Therefore, a restore from that
snapshot will restore primary LUN back into the old size.
• An Attached SMP can be expanded, but only if it is attached to a
snapshot and is associated with a Thin primary LUN. SMPs
associated with Thick LUNs cannot be expanded.
Auto-Delete Thresholds
Figure 33 shows Auto-Delete thresholds.
Auto-Delete paused
When Auto-Delete is unable to find enough eligible snapshots to delete
to be able to reach the Low Threshold, a warning is posted.
To resolve the warning, perform one or several of the following actions:
• Increase pool's capacity by adding more disks to it
• Manually delete snapshots
• Change configuration to allow more snapshots to be
automatically deleted
• Change thresholds
In some extreme cases, when deleting snapshots or failing to find
eligible Snaps to be deleted, the Auto-Delete process does not get
below the High Threshold. In that case, the Auto-Delete process stops
and posts an "Automatic Snapshot deletion paused" array error.
To correct the error, perform one or several of the same actions as with a
warning and make sure to manually restart the automatic deletion
feature in the Pool Properties dialog box. Optionally, an error condition
is lifted when Auto-Delete is completely disabled on a pool.
Snapshot Expiration
Every VNX Snapshot may have an optional expiration date. Expired
snapshots are destroyed at regular intervals. The VNX array scans for
expired snapshots once an hour (The Auto-Delete process does not
process destruction of expired snapshots. The destruction is handled by
another software layer.) When the expiration time is reached, the
snapshot may not be destroyed immediately. It is deleted by the
process started at the next running interval.
Setting an expiration date on a snapshot automatically disables Auto-
Delete. In CLI, the user must acknowledge a warning or overwrite it with -
o flag. In Unisphere, the user can set an expiration date only after Auto-
Delete is disabled (unchecked).
Similarly, enabling Auto-Delete for a snapshot automatically clears the
expiration timestamp for that snapshot and Unisphere displays a
warning.
Usage:
snap -create -res resource [-resType type][-name snapName][-descr description]
[{-keepFor keepFor|-allowAutoDelete {yes|no}}][-allowReadWrite {yes|no}][-o]
snap -destroy -id snapName [-o]
snap -list [{-id snapName|[-resType type][-res resource]}][{-brief|-detail}]
snap -modify -id snapName [-name newName][-descr description]
[{-keepFor keepFor|-allowAutoDelete {yes|no}}][-allowReadWrite {yes|no}]
snap -copy -id snapName [-name newName][-o]
snap -restore -id snapName [-bakName bakName][-res lunNumber][-o]
snap -attach -id snapName -res lunNumber
snap -detach -id snapName [-res lunNumber][-o]
snap -group -create -name cgName [-res lunNumber(s)][-descr description]
[-allowSnapAutoDelete {yes|no}]
snap -group -destroy -id cgName [-destroySnapshots]
snap -group -list [-id cgName][{-brief|-detail}]
snap -group -modify -id cgName [-name newName][-descr description]
[-allowSnapAutoDelete {yes|no}]
snap -group -addmember -id cgName -res lunNumber(s)
snap -group -rmmember -id cgName -res lunNumber(s)
snap -group -replmember -id cgName -res lunNumber(s)
snap -feature -info
Create a Snapshot
To create a snapshot, naviseccli requires the LUN ID, and not the LUN
name. Be sure to flush host buffers before creating a snapshot. See 7.1
Flush buffers for an example.
# Look up the LUN ID, if needed.
[nasadmin@~]$ naviseccli -h SPA lun -list -name Primary_LUN1 -default
# list a Snapshot
[nasadmin@~]$ naviseccli -h SPA snap -list -id Primary_LUN1_Snapshot
Copy a Snapshot
As explained earlier, a copy of a snapshot does not inherit two
properties:
• Name
• Allow Read/Write flag, which is set to 'No' by default
Creation time is inherited from the original snapshot.
[nasadmin@~]$ naviseccli -h SPA snap -copy -id Primary_LUN1_Snapshot \
-name Primary_LUN1_Snapshot_COPY
Name: Primary_LUN1_Snapshot_COPY
Description: The CLI made snapshot
Creation time: 03/27/12 10:54:54
Source LUN(s): 0
Source CG: N/A
State: Ready
Allow Read/Write: No <===== LOOK HERE. Allow Read/Write property is not copied!
Modified: No
Allow auto delete: Yes
Expiration date: Never
Attach a Snapshot
There are two ways to attach a snapshot:
1. Attach a snapshot to an SMP by sending a command to the SMP
2. Attach a snapshot to an SMP by sending the command to the
snapshot
# attach via the lun command
[nasadmin@~]$ naviseccli -h SPA lun -attach -l 8155 -snapName Primary_LUN1_Snapshot
# Note: in both cases 8155 is the LUN ID of the Snapshot Mount Point
If a snapshot does not allow read/write access, you will receive the
following error:
[nasadmin@~]$ naviseccli -h SPA snap -attach -id Primary_LUN1_Snapshot -res 8155
The properties of this snapshot do not allow it to be attached. Modify the snapshot
properties to allow it to be attached and retry the attach operation. (0x716d802e)
Name: PrimaryLUN1_Cascading_Snapshot1
Description:
Creation time: 03/27/12 12:54:21
Detach a Snapshot
There are two ways to detach a snapshot:
1. Detach a snapshot by sending a command to the snapshot
2. Detach a snapshot by sending the command to the SMP
To detach using a lun command, use the name of the SMP. There are no
warnings.
[nasadmin@~]$ naviseccli -h SPA navi lun -detach -name PrimaryLUN1_SMP1
Name: Primary_LUN1_Snapshot
Description: The CLI made snapshot
Creation time: 03/27/12 10:54:54
Last modify time: 03/27/12 13:01:09 <===== Time when detached
Last modified by: PrimaryLUN1_SMP1_COPY
Source LUN(s): 0
Source CG: N/A
Primary LUN(s): 0
State: Ready
Status: OK(0x0)
Allow Read/Write: Yes
Modified: Yes <===== Shows as modified, since it used to be attached
Attached LUN(s): <===== Nothing listed
Allow auto delete: Yes
Expiration date: Never
Destroy a Snapshot
[nasadmin@~]$ naviseccli -h SPA snap -destroy -id Primary_LUN1_Snapshot
Are you sure you want to perform this operation?(y/n): yes
Note: The 'getlun' command does not show the VNX Snapshot
information.
If the LUN is a part of a CG, use that CG name to find the list of all LUNs:
[~]$ naviseccli -h SPA snap -list -res CG_name
Name: 2012-02-10 14:45:18
Description:
Creation time: 02/10/12 14:45:24
Source LUN(s): 4,5
Source CG: CG_name
State: Ready
Allow Read/Write: Yes
Modified: No
Allow auto delete: Yes
Expiration date: Never
To list snapshots for a single LUN (that is not a member of a CG) specify
the LUN ID or name with -res option.
Name: USG-CG_mountpoints
Description:
Allow auto delete: Yes
Member LUN ID(s): 8081,8080
State: Ready
Flush buffers
Like ADMSNAP, SnapCLI must be used to flush disk buffers before
creating or detaching a VNX Snapshot. This is especially important in
Windows environments.
:: Windows
SnapCLI flush -o G:
Create a Snapshot
:: Windows
SnapCLI create -s SnapCLI_snap1 -o \\.\PhysicalDrive1
Attach a Snapshot
The following command attaches a snapshot to the first SMP available.
When there are many SMPs (that belong to the primary LUN), the first
available SMP is used (usually the one identified as the lower drive, e.g.
\\.\PhysicalDriveX).
:: Windows
SnapCLI attach -s SnapCLI_snap1 -f
Copy a Snap
An attached snapshot cannot be copied. Therefore, the request to copy
an attached snapshot will fail.
Consistency Groups
One main difference between SnapCLI and ADMSNAP is the introduction
of Consistency Groups support. When creating VNX Snapshots, you can
specify the name of Consistency Group (CG) along with a list of LUNs. If
the specified CG does not already exist, it is created containing the LUNs
specified as members.
Note: If the specified Consistency Group already exists, the existing
members of the CG are replaced with the LUNs specified as members.
The storage system maintains the CG and member LUNs persistently.
:: Windows
2
In here, besides LUNs, VNX Snapshots can be taken on a Consistency Group, or Attached Mount Point
3
Same as above
4
Same as above
5
GUI only allows whole numbers. CLI will accept decimal places.
6
GUI only allows whole numbers. CLI will accept decimal places.
7
GUI only allows whole numbers. CLI will accept decimal places.
8
GUI only allows whole numbers. CLI will accept decimal places.