vnx snapshots

1 VNX Snapshots White Paper

White Paper

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

VNX Snapshots


Copyright © 2012 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. Part Number H10858


Table of Contents

Executive summary ........................................................................................... 5

Audience ......................................................................................................... 5

VNX Snapshots Technical Overview ..................................................................... 6

What is new? .................................................................................................................... 6 How do Snapshots work? ................................................................................................ 6

Snapshot granularity ................................................................................................... 8

Snapshot Mount Point..................................................................................................... 9

VNX operations............................................................................................... 11

Create a Snap ................................................................................................................. 11 Create a Snapshot Mount Point .................................................................................... 13 Attach a Snap ................................................................................................................. 14

Branching (snap of a snap) ........................................................................................... 15 Copy a Snapshot........................................................................................................ 15 Snap of a Snapshot Mount Point ............................................................................. 17

Detach a Snapshot Mount Point............................................................................... 19 Detach a Snapshot Mount Point with Snapshots ................................................... 20

Destroy a Snapshot ....................................................................................................... 22

Consistency Groups ....................................................................................................... 23 Attach a Consistent Snapshot .................................................................................. 24 Branch a Consistent Snapshot ................................................................................. 27

Rules for Consistency Groups ................................................................................... 28 Restore............................................................................................................................ 28

Restore with SnapView Snapshots and VNX Snapshots ........................................ 29

Restore a LUN............................................................................................................. 29 Restore CGs ................................................................................................................ 31

Repurpose Snapshots ................................................................................................... 31

Migrations ...................................................................................................................... 32 Migration considerations .......................................................................................... 35

Limits .............................................................................................................................. 35

VNX Snapshot Auto-Delete ............................................................................... 36 Auto-Delete Thresholds ................................................................................................. 37 Pool Space Used Threshold .......................................................................................... 37

Snapshot Space Used Threshold ............................................................................. 38 Delete Eligibility ............................................................................................................. 39 Auto-Delete paused ....................................................................................................... 39


Snapshot Expiration ...................................................................................................... 40

CLI ................................................................................................................ 41

Create a Snapshot ......................................................................................................... 41 Copy a Snapshot ............................................................................................................ 42 Create a Snapshot Mount Point .................................................................................... 42

Attach a Snapshot ......................................................................................................... 43 Create a Cascading Snapshot ....................................................................................... 43 Detach a Snapshot ........................................................................................................ 44

Destroy a Snapshot ....................................................................................................... 44 List all VNX Snapshots for a LUN .................................................................................. 44 Create a Consistency Group .......................................................................................... 45

List Consistency Groups ................................................................................................ 45 Create a Consistent Snapshot ...................................................................................... 46 Attach a Consistent Snapshot ...................................................................................... 46

SnapCLI ......................................................................................................... 47 Flush buffers .................................................................................................................. 47 Create a Snapshot ......................................................................................................... 47

Attach a Snapshot ......................................................................................................... 47 Copy a Snap ................................................................................................................... 47 Consistency Groups ....................................................................................................... 48

Sample SnapCLI batch script ........................................................................................ 48

VNX Snapshots vs. SnapView terms .................................................................. 49

Terminology ................................................................................................... 50

Properties Detailed ......................................................................................... 51 Snapshot properties ...................................................................................................... 51

Snapshot Mount Point properties ................................................................................ 52 Additional pool properties ............................................................................................ 53


Executive summary VNX™ Snapshots is a new VNX software feature that creates point-in-time data copies. VNX Snapshots is used for data backups, software development and testing, repurposing, data validation, and local rapid restores. Unlike SnapView™ snapshots and clones, VNX snapshots do not consume large amounts of pool capacity. As a result, this feature is preferred for modern data management.

This white paper describes all VNX Snapshots operations in detail. Wherever possible, all aspects of the feature sets are presented visually. The paper provides straightforward instructions for common functional tasks. Most tasks are shown from the point of view of Unisphere™ (graphical user interface) and naviseccli (command line interface).

VNX Snapshots and SnapView will coexist on the same LUN. Furthermore, SnapView clones, which use a different technology from SnapView snapshots, will work with VNX Snapshots.

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.


VNX Snapshots Technical Overview

What is new?

VNX Snapshots is a new feature introduced in VNX for Block OE Release 32. It was created to improve on the existing SnapView Snapshot functionality by better integrating with pools. In fact, VNX Snapshots can only be used with pool LUNs.

LUNs that are created on physical RAID groups, also called RAID LUNs, support only SnapView Snapshots. This limitation exists because VNX Snapshots require pool space as part of the technology.

Note: SnapView Snapshots are compatible with pool LUNs. VNX Snapshots and SnapView Snapshots can coexist on the same pool LUN.

VNX Snapshots support 256 writeable snaps per pool LUN. It supports Branching, also called Snap of a Snap. 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, which is the hard limit.

Consistency Groups are also introduced in this release. Several pool LUNs can be combined into a Consistency Group and snapped concurrently.

How do 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 in 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.

Figure 1 compares the two technologies.


Figure 1: SnapView write vs. VNX Snapshot write

In Figure 1, the main difference between SnapView Snapshot and VNX Snapshot is evident. VNX Snapshot technology writes the new data to a 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 snapshot's data does not need to be constructed from two different places as shown in Figure 4

Figure 2: SnapView read vs. VNX Snapshot read


Snapshot granularity

Every VNX Snapshot has 8 KiB block granularity. This means that every write occupies at least 8 KiB on the pool. The distribution of the 8 KiB blocks within a 1 GiB slice is congruent with the normal thin write algorithm.

Consider the following example. A LUN is snapped with a few blocks of data. The new snapshot points at those blocks, just like the primary LUN.

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


Thick LUN consideration

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 8KiB blocks for each portion of the Thick LUN being written.

Note: Thick LUN remains to be classified as Thick in the CLI and GUI.

The Thick LUN remains in an indirect mode while it has VNX Snapshots. When the last snapshot of the Thick LUN is removed, the mode automatically converts to direct. The conversion to direct mode is not instantaneous, and is performed in the background. The conversion can be aborted by creating a new VNX Snapshot on the LUN.

VNX Snapshots are a part of the storage pool. A snapshot does not consume space from the pool, until the new data is written to the primary LUN or to the snapshot itself.

Snapshot Mount Point

Snapshot Mount Point (SMP) is a virtual 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.

Figure 5: What is a Snapshot Mount Point?


An SMP is created for snapshots of a specific LUN. This means that each SMP can be used only for snapshots of a single primary LUN.

To enable access to hosts, SMPs must be provisioned to storage groups just like any typical LUN.


VNX operations VNX Snapshots support the following operations.

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.

Figure 6: A pair of VNX Snapshots

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.

Figure 7: Create VNX Snapshots in Unisphere


2. Click Create Snapshot or right-click the primary LUN.

# To create snapshot in the CLI naviseccli snap -create -res 1 -name "cli_snap" -descr "snap created via CLI" # ^^^ # LUN ID

When a snapshot is first created, it is write-protected:

Figure 8: Unisphere view of the VNX Snapshot write protection

When you try to attach a snapshot that has the Allow Read/Write option disabled, Unisphere automatically enables it and displays a warning.

Figure 9: Unisphere VNX Snapshot Attach warning

If a Snapshot is attached from the CLI, then the -allowReadWrite property must be set to Yes. Therefore, you must manually modify it prior to an attach command.


Before creating a snapshot, use the SnapCLI utility to flush the host buffers. :: Windows SnapCLI flush -o G:

# To modify a snap in the CLI naviseccli snap -modify -id "cli_snap" -allowReadWrite yes

Create a Snapshot Mount Point

To create an SMP in Unisphere, use the Configure Snapshot Mount Point wizard located in Data Protection > Common Data Protection Tasks. The wizard is also available in the Wizards area on the right pane.

Figure 10: Unisphere Snapshot Mount Point creation wizard location

Alternatively, you can also create an SMP by right clicking on a LUN listed in the LUN tab under Storage > LUNs.

Figure 11: Unisphere right mouse click Snapshot Mount Point creation

Creating an SMP does not require any space from the pool.


Note: Each SMP is dedicated to a specific primary LUN. It is not possible to attach snapshots from two different primary LUNs to a single SMP. Therefore, a backup server that is backing up four different LUNs must have four different SMPs provisioned to back up the snapshots of those LUNs.

In Unisphere, you can provision the SMP to a host through either the wizard or the SMP create screen.

In the CLI, you can provision the SMP to a host by using the Storage Group command: # To create a Snapshot Mount Point in CLI naviseccli lun -create -type Snap -primaryLunName PrimaryLUN -sp B -l 60 \ -name SMP_name -allowInbandSnapAttach yes # ^^ SMP LUN ID!!! # When LUN ID is not provided at creation, VNX assigns one automatically. # in that case, it needs to be looked up in order # to provision the SMP to a storage group # To provision the SMP to a Storage Group naviseccli storagegroup -addhlu -gname "Storage Group 1" -hlu 60 -alu 60

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.


Figure 12: Attaching a Snapshot to a Snapshot Mount Point

Note: A SCSI rescan is not required for switching attached snapshots, that is, detaching one snapshot and attaching another to the same SMP. However, you must stop all I/O to the SMP and most importantly, flush the host buffers (using the SnapCLI utility).

Branching (snap of a snap)

There are two main ways to create a Snap of a Snap. One way is to create a simple copy of a Snapshot and another is to take a Snapshot of the attached Mount Point, for example, Cascading Snapshots.

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.


Figure 13: VNX Snapshot copy

Note: Only unattached snapshots can be copied. Attached snapshots are branched by snapping SMP, a process that is also called Cascading Snapshots.


Snap of a Snapshot Mount Point

A snapshot of an SMP still has the same Primary LUN property as the Mount Point (and as the attached snapshot. The primary LUN properties of snapshots and the mount points that they are attached to will never be different)

It is technically possible to attach a snapshot to an SMP that is not a part of a storage group. Therefore, it is possible to create a snapshot of such an SMP. The resulting snapshot will be slightly different from a regular snapshot copy. The source of this snapshot and the creation times will not be the same as the snapshot attached to the SMP.

Figure 14: VNX Snap of a Snap, aka Cascading Snapshots


The Source LUN property of the Cascading Snapshot has the name of the SMP. It is possible to create multiple snapshots at this level, and individually mount them.

Figure 15: VNX Snapshots, multiple levels

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..


Detach a Snapshot Mount Point

Detaching a snapshot from an SMP modifies these properties: Last Modified Date and Last Modified By. Detaching a snapshot from an SMP does not destroy the SMP by default, and the SMP stays provisioned to the host. Detaching is an asynchronous operation during which the SMP remains available, but the host I/O is queued at the array. After the detach operation completes, all queued I/O requests return a fail status to the host.

Figure 16: Detaching a VNX Snapshot


Detach a Snapshot Mount Point with Snapshots

Detaching a snapshot from an SMP is more complex when the SMP has a few of its own snapshots.

Figure 17: Detaching SMP with its own Snapshots

Figure 17 shows that as a result of Snap2 detaching from SMP1, the second level snapshots (Snap2.1 and Snap2.2) need to change:

• The Source LUN property to match a higher-level object, which is Primary LUN1.

• The Creation time to match Snap2 (original Snap attached to SMP1)

• The Last modify time to match the old Last modified time or Creation time (if Last modified was empty) or remains the same, if the snapshot had not been modified (as Snap2.2 has in Figure 17).


Similarly, a multilevel structure will change as shown in Figure 18.

Figure 18: Multi-level detaching SMP with its own Snapshots

Note: A detached SMP persists by default and is kept provisioned to the host. There is no degradation in the array performance during the detaching operation.

When users are about to detach an SMP, Unisphere displays a message asking users to stop I/O and flush the host buffers.

Figure 19: Unisphere Snapshot detach confirmation

EMC recommends flushing the buffers by using the SnapCLI utility on the host. For example:

:: Windows. flush the buffers for drive G: SnapCLI.exe flush -o G:


Destroy a Snapshot

Destroying (deleting) a snapshot reclaims space for reuse in the storage pool. Reclaim is not instant, and is done by an internal process. This internal process is throttled for better performance of the array and is not sequential, that means, more than one snapshot can be destroyed at one time. Multiple snapshot destructions start on the first-come-first-served basis. VNX is tuned to destroy up to 16 snapshots simultaneously on each Storage Processor (SP). Additional destruction requests are queued until a destruction thread becomes available.

When a snapshot is in the "Destroying" state, it is still counted towards the maximum number of snapshots. The snapshot name is changed to Destroying_<timestamp> before it is destroyed. This way, a user can re-create a snapshot called "Monday_Backup_Snapshot" immediately after executing a command to destroy the old snapshot . This is especially useful for SnapCLI-based scripts.

After the destruction command is accepted by the array, actual destruction may take different amounts of time to complete. The time difference is dependent on several factors such as the amount of data within a Snap, the SP CPU load, and the speed of the underlying disks within a pool.


Consistency Groups

A Consistency Group (CG) is an object that contains a list of primary LUNs or SMPs (but not both) that are treated as a single entity for taking snapshots.

A Consistent Snapshot is one snapshot of a collection of LUNs. When a snapshot of a CG is initiated, all writes to member LUNs are held until their snapshots have been created. Typically, CGs are used for LUNs that belong to the same application.

Note: Application-side consistency is achieved with AppSync product that integrates with VNX Snapshots and VNX Snapshot CGs.

CGs are intended to take write-order–consistent snapshots of a group of LUNs or SMPs. CGs have a name and description. CGs can contain any non-private pool-based LUNs, or SMPs.

Figure 20: VNX Snapshot Consistency Group

Figure 21: Unisphere view of a Consistency Group


Attach a Consistent Snapshot

Mounting an entire Consistent Snapshot requires the same number of SMPs as there are members in the CG.

Figure 22: Attaching a Consistent Snapshot

Note: A Consistent Snapshot may have different number of snapshots than a CG, if the CG’s members were modified after the snapshot was taken.

It is technically possible to attach a single snapshot from the Consistent Snapshot. The system checks the SMP's primary LUN to know which portion of the Consistent Snapshot to attach.


Figure 23: Attaching individual SMPs to a Consistent Snapshot

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.


Figure 24: SMPs that are members in a CG cannot be attached to different Consistent Snapshots


Branch a Consistent Snapshot

Consistent Snapshots can be branched just like regular snapshots.

Figure 25: Attaching a Copy of a Consistent Snapshot


Cascading Consistent Snapshots

To create a cascading Consistent Snapshot, a new CG must be created out of SMPs attached to a snapshot.

Figure 26: Attaching a Cascading Consistent Snapshot

Rules for Consistency Groups

The rules for CGs are:

• CGs must not contain a combination of primary LUNs and SMPs

• CGs must not contain multiple SMPs from the same primary LUN

• Any LUN/SMP can belong to only one CG

• SMPs that are members in a CG cannot be attached to different Consistent Snapshots

• Consistent Snapshots for RAID LUNs or a mix of RAID LUNs and Thick/Thin LUNs are only possible with SnapView snapshots (sessions)

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.


Restoring automatically creates a 'Restore point snapshot' to recover from unintentional data corruption. Although restoring is not instant, it is an online operation. While the LUN is being restored, its state shows as 'Initializing,' and is changed back to 'Ready' after the restore is complete.

Note: Restoring is also referred to as Protected Restore, because restoring does not change the snapshot. All its data is protected.

When restoring an SMP, the data from the source snapshot (the one being restored) is placed onto the snapshot attached to a Mount Point.

Note: Restoring can change the LUN size if the source snapshot was taken before the primary LUN expansion or shrinking.

Restore with SnapView Snapshots and VNX Snapshots

Since pool LUNs can have a combination of SnapView snapshots and VNX Snapshots, it is possible to restore from either a SnapView snapshot or a VNX Snapshot. Restore is supported for both cases.

• To restore a primary LUN from a VNX Snapshot, all SnapView snapshots (sessions) must be manually deleted (stopped).

• If the primary LUN is restored from a SnapView snapshot (session), VNX Snapshots are unaffected.

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.


Step 2

Flush the buffers for the drive by using SnapCLI.

Note: EMC recommends using SnapCLI for all other operating systems (if an appropriate binary exists). Use native operating system methods when SnapCLI binary is not available.

:: Windows SnapCLI flush -o G: :: 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 Microsoft DiskPart version 6.1.7601 Copyright (C) 1999-2008 Microsoft Corporation. On computer: WIN2K8 DISKPART> list disk


Disk ### Status Size Free Dyn Gpt -------- ------------- ------- ------- --- --- Disk 0 Online 465 GB 38 MB Disk 1 Online 10 GB 1024 KB DISKPART> select disk 1 Disk 1 is now the selected disk. DISKPART> offline disk DiskPart successfully offlined the selected disk. 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.


Migrations

One of the VNX Snapshot use cases is to promote a snapshot to be a typical LUN. To do that, the snapshot must be attached, and then the SMP 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.

Figure 29: Attached Snapshot before migration

Consider the example in Figure 29:

• 'Host 1' is a production server running an application with 'PrimaryLUN1' provisioned.

• 'Host 2' 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:

o Takes a snapshot 'Snap2' from the production 'PrimaryLUN1'

o Creates an SMP 'SMP Name' for snapshot from 'PrimaryLUN1'


o Provisions 'SMP Name' to 'Host 2' (for example adds 'SMP Name' to the storage group for 'Host 2')

o Attaches 'Snap2' snapshot to 'SMP Name'

o Runs SCSI rescan on 'Host 2'

o Creates a local drive on 'Host 2'

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

After some time of running development code on 'SMP Name', it is decided to promote it to an independent LUN

The Administrator performs the following actions:

• Creates 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.

• Starts a LUN migration session from 'SMP Name' to 'LUN Temp'

o Unisphere displays a warning message that the existing 'SMP Name' snapshots will be destroyed.

Figure 30: Unisphere LUN migration warning

o Administrator acknowledges the warning.


• The LUN migration runs for some time. The speed of migration depends on several factors such as the LUN priority, size of 'PrimaryLUN1', and array load.

• Migration completes and

o 'SMP Name' Snapshot Mount Point is deleted

o 'LUN Temp' is renamed to 'SMP Name' and retains all the SCSI attributes of the Mount Point, including WWN and even HLU ID within the storage group.

o 'Snap2.1' is destroyed

An internal process examines the blocks used for 'Snap2.1' and returns them to the pool

Figure 31: Migrating an attached Snapshot Mount Point to a new LUN

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.


Migration considerations

• When a primary LUN with SnapView snapshots is migrated to a RAID or pool LUN, all SnapView snapshots migrate to the destination LUN

• When a primary LUN or attached SMP with VNX Snapshots is migrated to a RAID or pool LUN, all VNX Snapshots are deleted (migration does not start if one of several of the underlying VNX Snapshots are attached or in use)

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.


VNX Snapshot Auto-Delete As stated earlier, VNX Snapshots use pool space and decrease the amount of user usable space in the pool. The mechanism to control unlimited snapshot growth was created, and dubbed 'Auto-Delete Management.'

The main goal of VNX Snapshot Auto-Management is not to let the snapshots take usable space away from pool LUNs. Auto-Delete is controlled by the Auto-Delete policy that can be set on each pool, pool LUN, CG, and VNX Snapshot. Every Auto-Delete policy has two sets of thresholds:

a. Pool Space Thresholds (low and high)

b. Snapshot Space Thresholds (low and high)

The Auto-Delete Pool policy is enabled by default. However, in can be easily disabled.

Note: Only Storage Pool Auto-Delete policy is enabled by default. The policy for Pool LUNs, Consistency Groups, and VNX Snapshots are disabled by default.

Figure 32: Unisphere Pool properties, showing Auto-Delete policy

The Auto-Delete policy can be enabled or disabled for the following objects:

• Pool

• LUN


• Snapshot (Regular or Consistent Snapshot)

• Consistency Group

• SMP

Whenever a high threshold is crossed, the VNX array starts an Auto-Delete process that scans the affected pools for Snapshots that are eligible for destruction based on the Auto-Delete policy of the pools, primary LUNs, SMPs, CGs, and snapshots.

Note: Attached snapshots are excluded from Auto-Delete regardless of other settings.

Disabling Auto-Delete at the pool level disables all Auto-Delete operations within the pool, regardless of the individual LUN/CG/snapshot settings (except for scanning for expired LUNs). Disabling Auto-Delete on a LUN, SMP, or CG, disables Auto-Delete on all snapshots created from it regardless of the individual snapshot settings.

Snapshots are Auto-Deleted one at a time, because the system does not have an ability to predict how many snapshots need to be deleted to reach the low threshold.

Auto-Delete Thresholds

Figure 33 shows Auto-Delete thresholds.

Figure 33: Storage Pool Auto-Delete Thresholds

Pool Space Used Threshold

Pool Space Used Threshold is a user configurable parameter that determines whether the system should monitor the space used in the


Pool and Auto-Delete snapshots if required. When enabled, the following thresholds are used for space monitoring. When disabled, the threshold values are retained by the system but the pool space used is not actively monitored.

Pool Space Used Threshold is enabled by default at the time of Pool creation.

There are two Pool Space Used Thresholds:

• Pool Space Used High Threshold: By default, it is set to 95% of the pool capacity. When the pool crosses the threshold, the Auto-Delete process is triggered. This process examines pool snapshots for destruction eligibility in order of age, oldest first. When eligible snapshots are found, the process starts deleting them one at a time.

• Pool Space Used Low Threshold: By default, it is set to 85% of the pool capacity. This threshold must be smaller than Pool Space Used High Threshold. When this threshold is crossed, it is an indication for the Auto-Delete process to stop looking for new snapshots eligible for deletion.

Snapshot Space Used Threshold

Snapshot Space Used Threshold is a user configurable parameter that determines whether the system should monitor the Snapshot space used in the pool and Auto-Delete Snapshots if required. When enabled, the following thresholds are used for space monitoring. When disabled, the threshold values are retained by the system but the snapshot space used is not actively monitored.

Snapshot Space Used Threshold is disabled by default at the time of pool creation.

There are two Snapshot Space Used Thresholds:

• Snapshot Space Used High Threshold: By default, it is set to 25% of the pool capacity. When the pool crosses the threshold, the Auto-Delete process is triggered. This process examines the pool snapshots for destruction eligibility in order of age, oldest first, and starts deleting them one at a time.

• Snapshot Space Used Low Threshold: By default, it is set to 20% of the pool capacity. This threshold must be smaller than Snapshot Space Used High Threshold. When this threshold is crossed, it is an indication for the Auto-Delete process to stop looking for new snapshots eligible for deletion.


Delete Eligibility

A busy snapshot is excluded from Auto-Delete or expiration destruction. A snapshot is busy when:

• It is attached to a SMP

• It is involved in a restore

The Auto-Delete settings can be set in multiple places. Use the following table for system rules.

Pool LUN VNX

Snapshot Auto-Delete behavior

On On On Snapshots are subject to destruction On On Off This snapshot is exempt from

destruction On Off On or Off Snapshots are exempt from

destruction Off On or Off On or Off All pool Snapshots are exempt from

destruction

Similar rules apply to Consistent Snapshots.

Note: If a Consistent Snapshot has member LUNs in multiple pools, Auto-Delete in any of those pools can delete that snapshot unless the snapshot or its Source CG are exempt.

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.


Figure 34: Unisphere Auto-Delete 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.


CLI Navisphere Secure Command Line Utility, naviseccli, is updated to include a new command 'snap' and extend existing 'lun' command for VNX Snapshots. [nasadmin@~]$ naviseccli -h SPA snap 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

A quick list of array maximums and total VNX Snapshot numbers is displayed with this command: [nasadmin@~]$ naviseccli -h SPA snap -feature -info Is VNX Snapshots Supported: True Max. Snapshots: 8192 Max. Snapshots Per Primary LU: 256 Max. CGs: 128 Max. Members Per CG: 64 Max. Snapshot Mount Points: 1024 Total Number of Snapshots: 42 Total Number of CGs: 3 Total Number of Snapshot Mount Points: 16

Instead of listing CLI commands, view the collection of commands that are helpful for everyday CLI use.

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 LOGICAL UNIT NUMBER 10 <== LOOK HERE Name: Primary_LUN1 Default Owner: SP B # Create a Snapshot, and allow it to be mounted read/write (default is no) [nasadmin@~]$ naviseccli -h SPA snap -create -res 10 -resType LUN -name \ Primary_LUN1_Snapshot -descr "The CLI made snapshot" -allowReadWrite yes # list a Snapshot [nasadmin@~]$ naviseccli -h SPA snap -list -id Primary_LUN1_Snapshot


Name: Primary_LUN1_Snapshot Description: The CLI made snapshot Creation time: 03/27/12 10:54:54 Source LUN(s): 10 Source CG: N/A State: Ready Allow Read/Write: Yes Modified: No Allow auto delete: Yes Expiration date: Never

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 [nasadmin@~]$ naviseccli -h SPA snap -list -id 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

Create a Snapshot Mount Point

An SMP is a 'LUN-like' object, and is created similar to a simple pool LUN.

The -allowInbandSnapAttach property is a security feature, that lets SnapCLI from the host to attach/detach snapshots to this mount point. [nasadmin@~]$ naviseccli -h SPA lun -create -type Snap -primaryLunName Primary_LUN1 \ -name PrimaryLUN1_SMP1 -allowInbandSnapAttach yes -sp B # list the SMP [nasadmin@~]$ naviseccli -h SPA lun -list -name PrimaryLUN1_SMP1 LOGICAL UNIT NUMBER 8155 <=== Note the LUN number Name: PrimaryLUN1_SMP1 UID: 60:06:01:60:13:40:2A:00:70:5C:2C:51:1E:78:E1:11 Current Owner: SP B Default Owner: SP B Allocation Owner: SP B User Capacity (Blocks): 20971520 User Capacity (GBs): 10.000 Consumed Capacity (Blocks): 8404992 Consumed Capacity (GBs): 4.008 Pool Name: Pool 0 Raid Type: r_5 Offset: 0 Auto-Assign Enabled: DISABLED


Auto-Trespass Enabled: DISABLED Current State: Ready Status: OK(0x0) Is Faulted: false Is Transitioning: false Current Operation: None Current Operation State: N/A Current Operation Status: N/A Current Operation Percent Completed: 0 Is Pool LUN: Yes Is Thin LUN: Yes Is Private: No Is Compressed: No Tiering Policy: Auto Tier Initial Tier: Highest Available Tier Distribution: Performance: 100.00%

After the SMP is created, it could be added to a Storage Group, similar to a typical LUN: [nasadmin@~]$ naviseccli -h SPA storagegroup -addhlu -gname "Storage Group 1" \ -hlu 50 -alu 8155

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 # attach via the snap command [nasadmin@~]$ naviseccli -h SPA snap -attach -id Primary_LUN1_Snapshot -res 8155 # 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) # To modify the Read/Write flag use this command: [nasadmin@~]$ naviseccli -h SPA snap -modify -id Primary_LUN1_Snapshot \ -allowReadWrite yes # And repeat attach [nasadmin@~]$ naviseccli -h SPA snap -attach -id Primary_LUN1_Snapshot -res 8155

Create a Cascading Snapshot

Cascading snapshot is a snapshot of an attached SMP. [nasadmin@~]$ naviseccli -h SPA snap -create -res 8155 \ -name PrimaryLUN1_Cascading_Snapshot1 # list the result [nasadmin@~]$ naviseccli -h SPA snap -list -id PrimaryLUN1_Cascading_Snapshot1 -detail Name: PrimaryLUN1_Cascading_Snapshot1 Description: Creation time: 03/27/12 12:54:21


Last modify time: Never Last modified by: N/A Source LUN(s): 8155 <===== LUN ID of the SMP (aka PrimaryLUN1_SMP1) Source CG: N/A Primary LUN(s): 10 <===== LUN ID of the Primary LUN (aka Primary_LUN1) State: Ready Status: OK(0x0) Allow Read/Write: No <===== We didn't specify -allowReadWrite flag at creation Modified: No Attached LUN(s): Allow auto delete: Yes Expiration date: Never

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

However, when sending the detach command to a snapshot itself, there are warnings: [nasadmin@~]$ naviseccli -h SPA snap -detach -id Primary_LUN1_Snapshot WARNING : Attempting to detach a snapshot mount point that has snapshots. The snapshots of the mount point will be inherited by the source of the snapshot being detached. Snapshot mount point: 8154 Are you sure you want to perform this operation?(y/n): yes [nasadmin@~]$ naviseccli -h SPA snap -list -id Primary_LUN1_Snapshot -detail 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

List all VNX Snapshots for a LUN

Check whether the LUN belongs to a CG. [~]$ naviseccli -h SPA lun -list -l 4 -belongsToCG LOGICAL UNIT NUMBER 4 Name: LB_LUN Consistency Group: USG-CG [~]$ naviseccli -h SPA lun -list -l 12 -belongsToCG


LOGICAL UNIT NUMBER 12 Name: LB_LUN Consistency Group: N/A

Note: The 'getlun' command does not show the VNX Snapshot information.

[~]$ naviseccli -h SPA getlun 4 | egrep -i "group|snap" RAIDGroup ID: N/A

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 Name: Backup Snapshot:2012-02-14 04:28:21 Description: Creation time: 02/14/12 16:28:23 Source LUN(s): 4,5 Source CG: CG_name State: Ready Allow Read/Write: No 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.

Create a Consistency Group

To create a CG with two member LUNs, use this command: [~]$ naviseccli -h SPA snap -group -create -name "CG_name" -res 4,5 -descr "CG group1"

List Consistency Groups

To list all CGs on the array, use this command: [~]$ naviseccli -h SPA snap -group -list Name: CG_name Description: Allow auto delete: Yes Member LUN ID(s): 4, 5 State: Ready Name: USG-CG_mountpoints Description: Allow auto delete: Yes Member LUN ID(s): 8081,8080 State: Ready


Create a Consistent Snapshot

To snap a Consistent Snapshot, use the command: [~]$ naviseccli -h SPA snap -create -res CG_Name -name Consistent_Snap

Note: When creating a Consistent Snapshot on a CG that has only SMP members, all the SMPs must be attached.

Otherwise, the following error is displayed: [~]$ naviseccli -h SPA snap -create -res CG_Name -name Consistent_Snap The snapshot of the consistency group cannot be created because some members of the group are unattached snapshot mount points. Attach all members of the consistency group and retry the operation. (0x716d8063)

Attach a Consistent Snapshot

CLI does not allow attaching a Consistent Snapshot to multiple SMPs in one command. It is only possible to attach a Consistent Snapshot to every SMP one by one. [~]$ naviseccli -h SPA lun -attach -name SMP1 -snapName Consistent_Snap [~]$ naviseccli -h SPA lun -attach -name SMP2 -snapName Consistent_Snap [~]$ naviseccli -h SPA lun -list -showOnly Snap -attachedSnapshot LOGICAL UNIT NUMBER 504 Name: SMP1 Attached Snapshot: Consistent_Snap LOGICAL UNIT NUMBER 503 Name: SMP2 Attached Snapshot: Consistent_Snap


SnapCLI SnapCLI is the utility used on the host to manage snapshots and their attachments to the SMPs. It does in-band (FC or iSCSI) communication with the array and thus does not require an IP connection to the Storage Processor (SP).

SnapCLI is similar to the ADMSNAP utility in SnapView. Both provide the same level of security in that they can only manage snapshots of LUNs that they have access to, based on the primary LUNs or existing SMPs exposed to the host. In other words, the array administrator sets up the primary LUNs and/or SMPs and puts them in the host storage group and then the host administrator may use SnapCLI to manage snapshot creation, destruction, attach and detach for those LUNs only.

Note: To run SnapCLI, run the SnapCLI command from its installation folder, or modify the PATH to include the SnapCLI path. The default path in Windows is C:\Program Files\EMC\Unisphere SnapCLI

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 :: Or address by the drive letter SnapCLI create -s SnapCLI_snap2 -o G:

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

Note: When the -f option is supplied, VNX changes the -allowReadWrite property to "Yes" while the snapshot stays attached.

Copy a Snap

An attached snapshot cannot be copied. Therefore, the request to copy an attached snapshot will fail.


When a snapshot is not attached, it can be copied. You must specify both the name of the Snap to be created and the name of the Snap to be snapped. :: Windows SnapCLI copy -s SnapCLI_snap1_copy -b SnapCLI_snap1 -o G:

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 :: Create a Consistent Snapshot, and a Consistency group (if it doesn't exist) SnapCLI create -s Consistent_Snap -o T:,R: -c CG_name

Sample SnapCLI batch script

Note: SnapCLI does not support storagegroup commands. Therefore, all necessary SMPs must be provisioned to the hosts before SnapCLI can mount any snapshots. SMPs are not required for snapshot creation.

:: Windows @echo off :: Create one snap echo "Creating a snapshot for drive M:" SnapCLI create -s SnapCLI_snap_m -o M: :: Create a Consistent Snap :: and a Consistency group (if it doesn't exist) SnapCLI create -s Consistent_Snap -o T:,R: -c CG_name :: Attach a single snap :: (requires 1 mount point already provisioned to the host) SnapCLI attach -s SnapCLI_snap_m -f :: Attach a Consistent Snapshot :: (requires as many mount points as number of LUNs in the CG) SnapCLI attach -s Consistent_Snap -f


VNX Snapshots vs. SnapView terms The following table shows the consolidated difference between VNX Snapshots and SnapView terminology.

VNX Snapshot Definition SnapView

Snapshot Point-in-time copy of a LUN2 Session

Create Take a point-in-time copy of a LUN3 Start

Attach Connect a snapshot to Snapshot Mount Point

Activate

Detach Disconnect from a Snapshot Mount Point Deactivate

Primary LUN LUN4 from which the snapshot is taken Source LUN

Snapshot Mount Point

An object that is exposed to the host through a storage group

Snapshot

Restore Change a LUN data to a specific point-in-time copy

Rollback

Delete Delete a snapshot Stop

Copy Create an identical copy of a Snapshot -- N/A --

Consistency Group

Persistent grouping of primary LUNs or Mount Points

-- N/A --

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


Terminology • Consistency Group—an object that contains a list of primary

LUNs or Snapshot Mount Points (but not both) that are treated as a single entity for taking snapshots.

• Consistent Snapshot—a point-in-time copy of a Consistency Group.

• Copy on First Write (COFW)—the technology behind SnapView Snapshots. After a snapshot is taken, new writes to the primary LUNs are delayed to enable copying old blocks to the special reserve LUN within the Reserve LUN Pool.

• Logical Unit Number (LUN)—is the identifying number of a SCSI or an iSCSI object that processes SCSI commands. The LUN is the last part of the SCSI address for a SCSI object. The LUN is an ID for the logical unit, but the term is often used to refer to the logical unit itself.

• Mount Point, Snapshot Mount Point (SMP)—a virtual LUN-like container. It is used to "emulate" a typical LUN, but provide the ability for hosts to write to snapshots and to change snapshots without changing LUN properties such as WWN, and often without the need to rescan SCSI bus on the client.

• Redirect on Write (ROW)—the technology behind VNX Snapshots. After a snapshot is taken, new writes to the primary LUN are redirected (written) to a new location within a storage pool.

• Storage processor (SP)—a hardware component that provides the processing resources to perform storage operations such as creating, managing, and monitoring storage resources.

• Unisphere—a web-based management environment to create storage resources, configure and schedule protection for stored data, and manage and monitor other storage operations on VNX and VNXe systems.


Properties Detailed

Snapshot properties

Every snapshot has the following properties:

Snapshot property

Description User editable?

Value range

Name Unique user friendly name. This name can be used to identify the snapshot in management commands. The array will generate a unique name if it is not supplied during the time of snapshot creation.

Yes ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 255

Description User-created description. Yes ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 255

Creation Time The time when the snapshot was created

Timestamp

Last Modify Time

The time when the snapshot was last detached from an SMP

Timestamp or the word "Never"

Last Modified By

The field is blank until the first snapshot is detached. After it is detached, the field is updated with the name of the SMP that the snapshot was attached to.

ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 64

Primary LUN Name of the source that is used to create the Snapshot.

ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 64

State Object state from the array's point of view.

• Initializing • Ready • Faulted


Snapshot property


Value range

• Offline • Destroying

Allow Read/Write

An indicator whether the Snapshot may be attached to an SMP or not. The default setting is “No”.

Yes Yes/No

Modified An indicator that the snapshot is or had previously been attached to an SMP.

Yes/No

Source LUNs The SMP that the Snapshot is currently attached to.

List

Allow auto delete

An indicator whether or not this Snapshot participates in auto-delete.

Yes Yes/No

Expiration Date

The date/time that the snapshot will get automatically deleted (Time of day of destruction may be approximate). The default is “Never” expiring.

Yes Timestamp

Snapshot Mount Point properties

Every SMP has the following properties:

SMP property Description User

editable? Value range

Name Unique user friendly name Yes ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 64

LOGICAL UNIT NUMBER

ID of the SMP. The array assigns a unique LUN ID to the SMP. This can be set in the GUI or CLI only at the time of creation.

Yes Shared with all LUN types (starts high similar to SnapView Snapshot LUNs)

User Capacity Size of the attached snapshot. One of: • Primary LUN size if never

attached


SMP property Description User editable?

Value range

• Current attached snapshot size

• Last attached size if unattached.

LUN Type Field indicating that the LUN is VNX SMP

Snapshot Attach LUN

State Details Details about the current state, if any

ASCII

WWN World Wide Name Current Owner

SP that currently owns the LUN

SPA, SPB.

Default Owner

SP that owns the LUN by default

Yes SPA, SPB

Auto Assign Enabled

An indicator if the LUN should participate in auto assignment

SPA, SPB

Allocation SP Set by the array (derived from the primary LUN)

SPA, SPB

Auto Delete Indicator whether or not snapshots of this SMP participate in auto-delete. The default setting is “Yes”.

Yes Yes/No

Active Operation

Set by the array • Expanding • Shrinking • Attaching • Detaching

Attached Snapshot

User-friendly name of the snapshot attached to the SMP.

Maximum length: 255

Statistics Same as traditional LUNs, DLUs and TLUs

Allow Inband Snap Attach

Setting to enable or disable attach from host-based SnapCLI.

Yes • Enabled • Disabled

Additional pool properties

VNX Snapshots adds the following pool properties:

Pool

property Description User

editable? Value range


Pool property


Value range

Primary Capacity Used

The total amount of storage that is consumed from this pool for data written to all the primary LUNs in the pool

Total primary capacity

Snapshot Capacity Used

The total amount of storage that is consumed from this pool for data written to all the snapshots in the pool

Total snapshot capacity

Metadata Capacity

The total amount of storage that is allocated from this pool to store metadata for the LUNs and Snapshots in the pool

Total overhead capacity

Primary Subscribed Capacity

The total amount of user data that can be written to all of the LUNs in the pool

Total primary subscription

Snapshot Subscribed Capacity

The total amount of space that all snapshots currently consume and what they would consume if all the primary LUNs’ data was overwritten

Total snapshot subscription

Metadata Subscribed Capacity

The total amount of metadata storage that is required to support writing to the entire contents of all the LUNs in the pool

Total overhead subscription

Auto-Delete Pool Full Threshold Enabled

Indicator that the system should check the pool full high water mark for auto-delete. (Default: TRUE)

Yes On/Off

Auto-Delete Pool Full High Water Mark

Pool percentage full that will trigger snapshot auto-deletion in the pool. Shown as a pool percentage full and also a size for convenience. (Default: 95%)

Yes 0.01 - 99%5

Auto-Delete Pool percentage full at which Yes 0 - 98.00%6

5 GUI only allows whole numbers. CLI will accept decimal places. 6 GUI only allows whole numbers. CLI will accept decimal places.


Pool property


Value range

Pool Full Low Water Mark

auto-delete will stop snapshot auto-deletion in the pool. This value must be less than the high water mark. (Default: 85%)

Auto-Delete Pool Full State

The state of the pool full auto-delete process for this pool The “Auto-delete Pool Full State” and “Auto-Delete Snap Used State” states will be aggregated into a single state for reporting using the GUI. Separate states for each will be reported via the CLI.

• Idle • Running • Could not

Reach LWM • System Paused • Failed

Auto-Delete Snapshot Space Used Threshold Enabled

Indicator that the system should check the snapshot space used high water mark for auto-delete. (Default: FALSE)

Yes On/Off

Auto-Delete Snapshot Space Used High Water Mark

Total percentage snapshot space used in the pool that will trigger snapshot auto-deletion in the pool. Shown as a pool percentage full and also a size for convenience. (Default: 25%)

Yes 0.01 - 99.00% 7

Auto-Delete Snapshot Space Used Low Water Mark

Total percentage snapshot space used in the pool that will stop snapshot auto-deletion in the pool. This value must be less than the high water mark. Shown as a pool percentage full and also a size for convenience. (Default: 20%)

Yes 0 - 98.00%8

Auto-Delete Snap Used State

The state of the Snapshot Space Used auto-delete process for this pool

• Idle • Running • Could not

7 GUI only allows whole numbers. CLI will accept decimal places. 8 GUI only allows whole numbers. CLI will accept decimal places.


Pool property


Value range

The “Auto-delete Pool Full State” and “Auto-Delete Snap Used State” states will be aggregated into a single state for reporting using the GUI. Separate states for each will be reported using the CLI.

Reach LWM • System Paused • Failed

vnx snapshots

Technology

snapshot mount point

emc vnx snapshots

snapshot auto

consistent snapshot

snapshot granularity

snapview snapshots

vnx operations

emc corporation trademarks