Comments
Description
Transcript
EMC VNX Snapshots
White Paper EMC 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. March 2015 EMC VNX Snapshots White Paper 1 Copyright © 2015 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.3 EMC VNX Snapshots White Paper 2 Table of Contents Executive summary .............................................................................. 5 Audience ............................................................................................. 5 Terminology ........................................................................................ 6 VNX Snapshots Technical Overview ...................................................... 7 How Snapshots work ................................................................................... 7 Snapshot granularity ............................................................................... 9 Snapshot Mount Point ............................................................................... 10 VNX operations.................................................................................. 11 Create a Snap ............................................................................................ 11 Create a Snap with AppSync ...................................................................... 13 Create a Snapshot Mount Point ................................................................. 13 Attach a Snapshot ..................................................................................... 15 Branching (snap of a snap)........................................................................ 15 Copy a Snapshot ................................................................................... 16 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 ............................................................... 25 Branch a Consistent Snapshot .............................................................. 28 Rules for Consistency Groups ................................................................ 29 Restore...................................................................................................... 29 Restore with SnapView Snapshots and VNX Snapshots ......................... 30 Restore a LUN ........................................................................................ 31 Restore CGs........................................................................................... 33 Repurpose Snapshots ............................................................................... 33 Migrations ................................................................................................. 33 Migration considerations ...................................................................... 37 Limits ........................................................................................................ 37 Interoperability with other VNX features .................................................... 37 VNX Snapshot Auto-Delete ................................................................. 38 Auto-Delete Thresholds ............................................................................. 40 Pool Space Used Threshold ....................................................................... 40 Snapshot Space Used Threshold ........................................................... 41 EMC VNX Snapshots White Paper 3 Delete Eligibility ........................................................................................ 41 Auto-Delete paused................................................................................... 42 Snapshot Expiration .................................................................................. 42 CLI .................................................................................................... 43 Create a Snapshot ..................................................................................... 44 Copy a Snapshot ....................................................................................... 44 Create a Snapshot Mount Point ................................................................. 45 Attach a Snapshot ..................................................................................... 46 Create a Cascading Snapshot .................................................................... 46 Detach a Snapshot .................................................................................... 47 Destroy a Snapshot ................................................................................... 47 List all VNX Snapshots for a LUN ................................................................ 47 Create a Consistency Group ....................................................................... 48 List Consistency Groups ............................................................................ 48 Create a Consistent Snapshot ................................................................... 49 Attach a Consistent Snapshot ................................................................... 49 SnapCLI............................................................................................. 49 Flush buffers ............................................................................................. 50 Create a Snapshot ..................................................................................... 50 Attach a Snapshot ..................................................................................... 50 Copy a Snap .............................................................................................. 50 Consistency Groups................................................................................... 50 Sample SnapCLI batch script ..................................................................... 51 VNX Snapshots vs. SnapView terms ................................................... 52 Properties Detailed ............................................................................ 53 Snapshot properties.................................................................................. 53 Snapshot Mount Point properties .............................................................. 54 Additional pool properties ......................................................................... 56 EMC VNX Snapshots White Paper 4 Executive summary VNX™ Snapshots is a 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 (GUI) and naviseccli command line interface (CLI). You can also manage your VNX snapshots using EMC AppSync, software that provides application consistent snapshots for Microsoft Exchange and SQL Server, and provides crash-consistency for VMware VMFS datastores. The AppSync GUI allows you to manage, configure, catalogue, and schedule your VNX snapshots. 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 Snapshots technology. EMC VNX Snapshots White Paper 5 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. EMC VNX Snapshots White Paper 6 VNX Snapshots Technical Overview VNX Snapshots is a 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 Classic LUNs, support only SnapView Snapshots. This restriction 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. A Snap of a Snap hierarchy 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, which is the hard limit. Consistency Groups are also supported with this feature. Several pool LUNs can be combined into a Consistency Group and snapped concurrently. 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 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. EMC VNX Snapshots White Paper 7 Figure 1: SnapView write vs. VNX Snapshot write Figure 1 illustrates the main difference between SnapView Snapshots and VNX Snapshots. 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 is not constructed from two different places as shown in Figure 4. Figure 2: SnapView read vs. VNX Snapshot read EMC VNX Snapshots White Paper 8 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 (1GB in VNX OE for Block R32) 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 EMC VNX Snapshots White Paper 9 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 8 KB 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 reverts to direct. The process of reverting to direct mode is not instantaneous, and is performed in the background. The process 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 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? EMC VNX Snapshots White Paper 10 A 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 to the snapshot itself arrive. Snapshots have a granularity of 8 KB, and their 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. Figure 6: A pair of VNX Snapshots Before creating a snapshot, use the SnapCLI utility to flush the host buffers. :: Windows SnapCLI flush -o G: To create a snapshot: 1. In Unisphere, select Storage > LUNs. EMC VNX Snapshots White Paper 11 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. EMC VNX Snapshots White Paper 12 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. # To modify a snap in the CLI naviseccli snap -modify -id "cli_snap" -allowReadWrite yes Create a Snap with AppSync You can also create VNX Snapshots using EMC AppSync. The AppSync user interface allows you to create a service plan that allows you to manage your snapshots. For more information, refer to EMC AppSync Installation and Administration Guide located at https://support.emc.com/products/25364_AppSync Create a Snapshot Mount Point To create a 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 a SMP by right clicking on a LUN listed in the LUN tab under Storage > LUNs. EMC VNX Snapshots White Paper 13 Figure 11: Unisphere right mouse click Snapshot Mount Point creation Creating a 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 EMC VNX Snapshots White Paper 14 Set the -allowInbandSnapAttach parameter to "yes" to allow SnapCLI host binary to attach the Snapshots (It is a security feature) o This parameter can easily be modified at a later time. A SMP is added to a storage group just like a usual LUN. Attach a Snapshot 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. EMC VNX Snapshots White Paper 15 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 the snapshot count for a given production LUN by one. Figure 13: VNX Snapshot copy Note: Only unattached snapshots can be copied. Attached snapshots are branched by snapping the SMP, a process that is also called Cascading Snapshots. 1 This property is a security feature, preventing unauthorized mounting a snapshot for read/write operations. EMC VNX Snapshots White Paper 16 Snap of a Snapshot Mount Point A snapshot of a 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 a SMP that is not a part of a storage group. Therefore, it is possible to create a snapshot of such a 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 EMC VNX Snapshots White Paper 17 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. EMC VNX Snapshots White Paper 18 Detach a Snapshot Mount Point Detaching a snapshot from a SMP modifies these properties: Last Modified Date and Last Modified By. Detaching a snapshot from a SMP does not destroy the SMP by default, and the SMP remains 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 EMC VNX Snapshots White Paper 19 Detach a Snapshot Mount Point with Snapshots Detaching a snapshot from a SMP is more complex when the SMP has 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 is empty) or remains the same, if the snapshot had not been modified (as Snap2.2 has in Figure 17). EMC VNX Snapshots White Paper 20 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 a 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: EMC VNX Snapshots White Paper 21 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. This means that more than one snapshot can be destroyed at one time. Multiple snapshot destructions start on a firstcome-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 recreate a snapshot called, for example, "Monday_Backup_Snapshot" immediately after executing a command to destroy the old snapshot with the same name. This is especially useful for SnapCLI-based scripts. Destroying a VNX Snapshot may generate a large amount of background I/O as old blocks of data (which are unique to that snap) are removed and the free space is reclaimed for the Pool. The amount of workload generated on the SP and Pools is proportional to the number of simultaneous deletions. The amount of time these deletions take to complete depends on the amount of unique data on the snap. EMC recommends snapshot deletions during periods of light load. Other factors that may impact the performance of VNX Snapshots are: Pools which contain a large proportion of NL-SAS drives (in terms of capacity). The old data will tend to be moved to the lowest tier drives and when the Snaps are deleted, the I/O associated with snap deletion can end up on the NL-SAS drives, which are relatively slow for that type of I/O. Pools which make extensive use of VNX Snapshots should ideally be using only Flash and SAS drives. Monitor the drives in the Pool and the SP Utilization to ensure that the Pool is not being overloaded. Large numbers of VNX Snaps being deleted at the same time. Too much concurrent load can be caused by deleting snaps using a script, having a common expiration time set on many snaps, or by reliance on Auto-delete functionality. When not using Consistency Groups, stagger the deletions over the course of the day or weekend, by script delay or staggered snap expiration times. Do not rely on Auto-Delete as the primary deletion strategy since it is not a proactive way to manage pool space or to manage the timing and impact of the snap deletion load. Overlapping snapshot deletions with FAST-VP relocation windows. It is better to start the deletions after the FAST-VP relocation window has ended. VNX Snaps being created and deleted frequently. The greater the frequency of snaps, the higher the background I/O will be to delete them. Reducing the EMC VNX Snapshots White Paper 22 frequency of VNX Snaps and their subsequent deletions will reduce the background I/O load on the Pool. VNX Snapshots with thick LUNs. A mode conversion (similar to converting from thin to thick) will be triggered when the last snap is deleted. It is preferable to make sure that there is always at least one snap remaining on the Thick LUN if you plan on using snaps again. Alternatively, use Thin LUNs instead. 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. A CG is primarily designed for LUNs that belong to the same application. Consistency Groups are not designed with the purpose of conducting an action on multiple unrelated snaps for administrative purposes (specifically detach/destroy). Using this process on unrelated LUNs in a single consistency group can result in triggering a high level of background I/O load on the pool. For a CG, it is recommended that the number of IOPS provided by the slowest drives in the pool should be equal to the number of IOPS required by the host application. This ensures the host application is not impacted if a part of the CG becomes inactive and the data is moved down to the lowest tier. Note: Application-aware consistency is achieved with AppSync product that integrates with VNX Snapshots and VNX Snapshot CGs. CGs 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 demonstrates the concept of Consistency Groups. EMC VNX Snapshots White Paper 23 Figure 20: VNX Snapshot Consistency Group Figure 21: Unisphere view of a Consistency Group EMC VNX Snapshots White Paper 24 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 a 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. EMC VNX Snapshots White Paper 25 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. EMC VNX Snapshots White Paper 26 Figure 24: SMPs that are members in a CG cannot be attached to different Consistent Snapshots EMC VNX Snapshots White Paper 27 Branch a Consistent Snapshot Consistent Snapshots can be branched just like regular snapshots. Figure 25: Attaching a Copy of a Consistent Snapshot EMC VNX Snapshots White Paper 28 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 cannot contain a combination of primary LUNs and SMPs CGs cannot 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 Classic 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 a 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 EMC VNX Snapshots White Paper 29 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. Although restoring is not instant, it is an online operation, in the sense that the earlier point-in-time data is immediately available, even while the restore operation occurs in the background. The user only needs to perform an initial flush of the host buffers before starting the process (just as you do when creating a snapshot), and then the rest of the process is completely host transparent. 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 Restore Point snapshot. All its data is protected so that the user can return to the point-in-time of the source data if needed. When restoring a 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. EMC AppSync restores consistency groups and LUNs using a copy that is catalogued during the execution of the snapshot. 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 EMC VNX Snapshots White Paper 30 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 2012 has an option to turn the drive offline. This can be done either from Disk Manager or from the CLI (diskpart). Note: Unmounting the drive guarantees that the host stops all I/O to the LUN. EMC VNX Snapshots White Paper 31 Figure 28: Windows Server 2012 Disk Manager -- switching a disk to offline mode C:\>diskpart Microsoft DiskPart version 6.2.9200 Copyright (C) 1999-2012 Microsoft Corporation. On computer: WIN2K12 DISKPART> list disk Disk ### -------Disk 0 Disk 1 Status ------------Online Online Size ------100 GB 10 GB Free ------38 MB 1024 KB Dyn --- Gpt --- DISKPART> select disk 1 Disk 1 is now the selected disk. DISKPART> offline disk DiskPart successfully offlined the selected disk. DISKPART> Step 4 Initiate the restore operation for the LUN from Unisphere or by using naviseccli. EMC VNX Snapshots White Paper 32 Note: SnapCLI does not allow restores for security reasons. Step 5 Mount the drive (On Windows 7/8, assign a letter). The mount can happen immediately after starting the restore operation. There is no need to wait for the operation to finish. Restore CGs When restoring a Consistent Snapshot to a CG, it is possible that the LUN 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 LUN 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 standard 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. EMC VNX Snapshots White Paper 33 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 a 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: EMC VNX Snapshots White Paper 34 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. EMC VNX Snapshots White Paper 35 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. EMC VNX Snapshots White Paper 36 Migration considerations When a primary LUN with SnapView snapshots is migrated to a Classic 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 the 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. Interoperability with other VNX features VNX Snapshots are fully supported when used with other VNX features. When using VNX Snapshots with block deduplication, please note the following: VNX Snapshots cannot be taken on a LUN while the LUN is in the enabling or disabling state of deduplication. This is due to the fact that the LUN is either migrating into or out of the deduplication container. If the creation of a VNX Snapshot is initiated while a LUN is in either state, an error message will appear. VNX Snapshots of a LUN that exist prior to enabling or disabling deduplication will be destroyed when the operation completes. All VNX Snapshot Mount Points associated with VNX Snapshots of a LUN must be deleted before deduplication can be enabled or EMC VNX Snapshots White Paper 37 disabled on the LUN. If deduplication is enabled or disabled on a LUN with SMPs, an error message will appear. For more information on Deduplication, see the white paper titled EMC VNX Deduplication and Compression, located on EMC Online Support. 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 named, 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 policies for Pool LUNs, Consistency Groups, and VNX Snapshots are disabled by default. EMC VNX Snapshots White Paper 38 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 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. EMC VNX Snapshots White Paper 39 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 thresholds below 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 EMC VNX Snapshots White Paper 40 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 thresholds listed below 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 AutoDelete 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 On On On On VNX Snapshot On Off On Off On or Off Off On or Off On or Off Auto-Delete behavior Snapshots are subject to destruction This snapshot is exempt from destruction Snapshots are exempt from destruction All pool Snapshots are exempt from destruction EMC VNX Snapshots White Paper 41 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 is 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 AutoDelete. 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 AutoDelete is disabled (unchecked). EMC VNX Snapshots White Paper 42 Similarly, enabling Auto-Delete for a snapshot automatically clears the expiration timestamp for that snapshot and Unisphere displays a warning. CLI Unisphere Secure Command Line Utility, naviseccli, includes the 'snap' command, and also options in the 'lun' command for VNX Snapshots. [nasadmin@~]$ naviseccli -h SPA snap Usage: snap -create -res resource [-resType type][-name snapName][-descr description] [{-keepFor number{h|d|m|y}|-allowAutoDelete {yes|no}}][-allowReadWrite {yes|no}] [-ignoreMigrationCheck][-ignoreDeduplicationCheck] snap -destroy -id snapName [-o] snap -list [{-id snapName|[-resType type][-res resource]}][{-brief|-detail}] snap -modify -id snapName [-name newName][-descr description] [{-keepFor number{h|d|m|y}|-allowAutoDelete {yes|no}}][-allowReadWrite {yes|no}] snap -copy -id snapName [-name newName][-ignoreMigrationCheck] [-ignoreDeduplicationCheck] 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: 32000 Max. Snapshots Per Primary LU: 256 Max. CGs: 256 Max. Members Per CG: 64 Max. Snapshot Mount Points: 4000 Total Number of Snapshots: 42 Total Number of CGs: 3 Total Number of Snapshot Mount Points: 16 Note: This command was run on a VNX8000. The maximum number of Snapshots and maximum number of Snapshot Mount Points per VNX vary by model. Please see the white paper titled Introduction to the EMC VNX2 series located on EMC Online Support for more information. Instead of listing CLI commands, view the collection of commands that are helpful for everyday CLI use. EMC VNX Snapshots White Paper 43 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 0 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 Name: Primary_LUN1 Default Owner: SP B <== LOOK HERE # 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 EMC VNX Snapshots White Paper 44 Create a Snapshot Mount Point A 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 can 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 EMC VNX Snapshots White Paper 45 Attach a Snapshot There are two ways to attach a snapshot: 1. Attach a snapshot to a SMP by sending a command to the SMP 2. Attach a snapshot to a 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 EMC VNX Snapshots White Paper 46 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. EMC VNX Snapshots White Paper 47 [~]$ 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 EMC VNX Snapshots White Paper 48 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 uses 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 (ADMSNAP is not used with VNX Snapshots). 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 EMC VNX Snapshots White Paper 49 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 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. EMC VNX Snapshots White Paper 50 :: 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 EMC VNX Snapshots White Paper 51 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-intime 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 -- In this context, besides LUNs, VNX Snapshots can be taken on a Consistency Group, or Attached Mount Point Same as above 4 Same as above 2 3 EMC VNX Snapshots White Paper 52 Properties Detailed Snapshot properties Every snapshot has the following properties: Snapshot property Name Description Description 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. User-created description Creation Time The time when the snapshot was created Last Modify The time when the snapshot Time was last detached from a SMP Last Modified The field is blank until the By first snapshot is detached. After it is detached, the field is updated with the name of the SMP that the snapshot was attached to. Primary LUN Name of the source that is used to create the Snapshot State Object state from the array's point of view User editable? Yes Yes Value range ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 255 ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 255 Timestamp Timestamp or the word "Never" ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 64 ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 64 Initializing Ready Faulted EMC VNX Snapshots White Paper 53 Snapshot property Allow Read/Write Modified Source LUNs Allow auto delete Expiration Date Description An indicator whether the Snapshot may be attached to a SMP or not. The default setting is No An indicator that the snapshot is or had previously been attached to a SMP The SMP that the Snapshot is currently attached to An indicator whether or not this Snapshot participates in auto-delete The date/time that the snapshot will get automatically deleted (Time of day of destruction may be approximate). The default is Never expiring. User editable? Value range Offline Destroying Yes/No Yes Yes/No List Yes Yes/No Yes Timestamp Snapshot Mount Point properties Every SMP has the following properties: SMP property Name Description Unique user friendly name LOGICAL UNIT ID of the SMP. The array NUMBER assigns a unique LUN ID to the SMP. This can be set in the GUI or CLI only at the time of creation. User Capacity Size of the attached snapshot. Will be set to one of: User editable? Yes Yes Value range ASCII, all printable characters (0x20 to 0x7E) with no leading or trailing spaces. Maximum length: 64 Shared with all LUN types (starts high similar to SnapView Snapshot LUNs) EMC VNX Snapshots White Paper 54 SMP property Description User editable? Value range LUN Type State Details WWN Current Owner Default Owner Auto Assign Enabled Allocation SP Auto Delete Active Operation Attached Snapshot Statistics Allow Inband Snap Attach Primary LUN size if never attached Current attached snapshot size Last attached size if unattached Field indicating that the LUN is VNX SMP Details about the current state, if any World Wide Name SP that currently owns the LUN SP that owns the LUN by default An indicator if the LUN should participate in auto assignment Set by the array (derived from the primary LUN) Indicator whether or not snapshots of this SMP participate in auto-delete. The default setting is Yes. Set by the array User-friendly name of the snapshot attached to the SMP Same as Classic LUNs, Thick LUNs, and Thin LUNs Setting to enable or disable attaching mountpoint from host-based SnapCLI Snapshot Attach LUN ASCII SPA, SPB. Yes SPA, SPB SPA, SPB SPA, SPB Yes Yes/No Expanding Shrinking Attaching Detaching Maximum length: 255 Yes Enabled Disabled EMC VNX Snapshots White Paper 55 Additional pool properties VNX Snapshots adds the following pool properties: Pool property Primary Capacity Used Snapshot Capacity Used Description User editable? The total amount of storage that is consumed from this pool for data written to all the primary LUNs in the pool. The total amount of storage that is consumed from this pool for data written to all the snapshots in the pool. The total amount of storage that is allocated from this pool to store metadata for the LUNs and Snapshots in the pool. Primary The total amount of user data Subscribed that can be written to all of Capacity the LUNs in the pool. Snapshot The total amount of space Subscribed that all snapshots currently Capacity consume and what they would consume if all the primary LUNs’ data was overwritten. Metadata The total amount of metadata Subscribed storage that is required to Capacity support writing to the entire contents of all the LUNs in the pool. Auto-Delete Indicator that the system Pool Full should check the pool full Threshold high water mark for autoEnabled delete. (Default: TRUE) Auto-Delete Pool percentage full that will Pool Full High trigger snapshot autoWater Mark deletion in the pool. Shown as a pool percentage full and Total primary capacity Total snapshot capacity Metadata Capacity 5 Value range Total overhead capacity Total primary subscription Total snapshot subscription Total overhead subscription Yes On/Off Yes 0.01 - 99%5 GUI only allows whole numbers. CLI will accept decimal places. EMC VNX Snapshots White Paper 56 Pool property Auto-Delete Pool Full Low Water Mark Auto-Delete Pool Full State Auto-Delete Snapshot Space Used Threshold Enabled Auto-Delete Snapshot Space Used High Water Mark Auto-Delete Snapshot Space Used Low Water Mark Description also a size for convenience. (Default: 95%) Pool percentage full at which auto-delete will stop snapshot auto-deletion in the pool. This value must be less than the high water mark. (Default: 85%) 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. Indicator that the system should check the snapshot space used high water mark for auto-delete. (Default: FALSE) Total percentage snapshot space used in the pool that will trigger snapshot autodeletion in the pool. Shown as a pool percentage full and also a size for convenience. (Default: 25%) Total percentage snapshot space used in the pool that will stop snapshot autodeletion 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%) User editable? Yes Value range 0 - 98.00%6 Idle Running Could not Reach LWM System Paused Failed Yes On/Off Yes 0.01 - 99.00%7 Yes 0 - 98.00%8 GUI only allows whole numbers. CLI will accept decimal places. GUI only allows whole numbers. CLI will accept decimal places. 8 GUI only allows whole numbers. CLI will accept decimal places. 6 7 EMC VNX Snapshots White Paper 57 Pool property Auto-Delete Snap Used State Description User editable? Value range The state of the Snapshot Space Used 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 using the CLI. Idle Running Could not Reach LWM System Paused Failed EMC VNX Snapshots White Paper 58