EMC VNXe3200 Unified Snapshots

Transcription

1 White Paper Abstract This white paper reviews and explains the various operations, limitations, and best practices supported by the Unified Snapshots feature on the VNXe3200 system. July 2015

2 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. VMware and VMware View are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. All other trademarks used herein are the property of their respective owners. Part Number H

3 Table of Contents Executive Summary... 5 Audience... 5 Terminology... 6 Unified Snapshots Overview... 8 Redirect on Write... 8 LUN Groups... 9 LUN Group Considerations Snapshot Use Cases Local Protection Repurposing Snapshot Scheduling Snapshot Auto-Delete Delete Eligibility Auto-Delete Thresholds Snapshot Expiration Snapshot Invalidation Which of the actions in step 4 above is taken depends on the source resource. Table 2 below shows the pool full behavior for each storage resource type: Unified Snapshots Operations Block Snapshot Operations Creating Snapshots Block Snapshot Host Access Attaching and Detaching Snapshots Restoring Snapshots Copying Snapshots Deleting Snapshots File Snapshot Operations Creating Snapshots File Snapshot Host Access Restoring Snapshots Copying Snapshots Deleting Snapshots Limits Best Practices Interoperability LUN and File System Expansion FAST Cache and FAST VP

4 File Deduplication and Compression SMB File-Level Retention (FLR) UFS VNXe VSS HW Provider Conclusion References

5 Executive Summary EMC recognizes data protection and management as critical business functions. IT organizations continuously evaluate the latest technologies and solutions available to protect their data. While evaluating technologies and solutions to protect data, customers appreciate using simple methods to restore their data in the event of data loss. Having the ability to easily manage, protect, and restore data from the storage array allows IT organizations to better invest limited resources. EMC introduced the Unified Snapshots software on the VNXe3200 system. The VNXe3200 system is built with a unified architecture, offering both block and file capabilities from the same enclosure. The Unified Snapshots feature enables the creation and management of snapshots for both block and file storage resources. Snapshots use the same storage pool as their storage resources, removing the need to carve out separate storage pool space for snapshots. Unified Snapshots uses Redirect on Write technology (ROW), which was first introduced with VNX Snapshots. The VNXe3200 system includes LUN Groups, which provide the ability to group multiple LUNs together. The same snapshot operations for LUNs are supported with LUN Groups allowing a consistent snapshot across multiple LUNs. Unified Snapshots also provides the ability to schedule automatic creation of snapshots, and Auto- Delete options to enable the system to delete snapshots based on configurable policies. Unified Snapshots operations can be performed easily within Unisphere, providing the ability to easily manage and protect data. This whitepaper describes the different Unified Snapshots operations in detail. Audience This white paper is intended for EMC customers, partners, and employees who want to understand how to leverage Unified Snapshots on the VNXe3200 system. 5

6 Terminology Application Consistency Ensures all incoming I/O for a given application is quiesced while a snapshot is being taken. Application Consistency makes sure that the application can restart from the point in time when a snapshot was taken. This differs from Crash Consistency because I/O is quiesced at the host, instead of being quiesced at the array. Block Storage Resources LUNs, LUN Groups and VMware VMFS Datastores. Common Internet File System (CIFS) An access protocol that allows users to access files and folders from Windows hosts located on a network. User authentication is maintained through Active Directory and file access is determined by directory access controls. Crash Consistent Snapshot A point in time copy of data. A crash consistent snapshot addresses only the data level; it is not aware of the underlying application(s). Deduplication The process used to compress redundant data, allowing space to be saved on a storage resource. When multiple files have identical data, the storage resource stores only one copy of the data, and shares that data between the multiple files. File Storage Resources File Systems (NFS, CIFS) and VMware NFS datastores. Logical Unit Number (LUN) A logical unit of storage created in a pool. A LUN can be either a thick LUN or a thin LUN. LUN Group A collection of LUNs which are grouped together. Snapshot operations on a LUN Group affect all the LUNs contained in the group, providing ease of management and crash consistency if the LUNs are dependent on each other. Network File System (NFS) An access protocol that allows users to access files and folders from Linux/UNIX hosts located on a network. Network-Attached Storage (NAS) File-based storage for a wide range of clients and applications that access storage over network connections. Protocol-specific file systems are located and managed on the storage system, which transfers data to hosts over TCP/IP using either the CIFS or NFS file sharing protocol. Redirect on Write (ROW) The technology behind Unified Snapshots. After a snapshot is taken, new writes to the primary storage are redirected and written to a new location within the storage pool. Share A named, mountable instance of file-level storage, accessible through a file system or VMware NFS Datastore. Each share is accessible through the protocol (NFS or CIFS) defined for the file system where it resides. Snapshot A point-in-time copy of data stored on the storage system. 6

7 Storage Processor (SP) A hardware component that provides the processing resources to perform storage operations such as creating, managing, and monitoring storage resources. Storage Pool A group of disk drives used for configuring LUNs, Datastores, and File Systems (thick and thin). Drives may only be a member of one pool. Storage Resource An addressable and configurable storage instance associated with a specific quantity of storage. LUNs and File Systems constitute a storage resource. Unisphere A web-based management environment used to create storage resources, configure and schedule protection for stored data, and manage and monitor other storage operations. Thick Storage Resources Type of storage resource in which physical space is allocated upon creation and is equal to the user capacity seen by the hosts. Thin Storage Resources Type of storage resource where physical space is allocated on-demand and can be less than the user capacity seen by the hosts. Unisphere CLI (UEMCLI) The command line interface for managing VNXe3200 systems. 7

8 Unified Snapshots Overview With the introduction of the Unified Snapshots technology, the VNXe3200 storage system allows you to take snapshots of both block and file storage resources using a common snapshot technology. With the VNXe3200 system, a storage pool can be used to create both block and file storage resources (LUNs, file systems, and VMware datastores) from the same storage pool. When a snapshot is created on that storage resource, the snapshot also becomes part of the storage pool. Unified Snapshots operations that are common to block and file storage resources include: create, delete, copy, and restore. Snapshots for block-level storage resources have the option to attach and detach a snapshot to a host, which can be used to provide access of snapshot data to a host. Snapshots for file-level storage resources can be one of the following types: read-only or writable. Read-only snapshots can be used to restore data. Writable snapshots can be shared to provide full access to the snapshot data. Unified Snapshots also provide the ability to schedule a snapshot s creation and expiration. Scheduled snapshots are used to create periodic point in-time copies of data. Snapshots can be automatically deleted based on storage pool capacity thresholds and expiration dates. Throughout this paper, demonstrations of the various snapshot operations will be described using Unisphere. If preferred, these operations can also be performed using Unisphere CLI (UEMCLI) and SnapCLI. Redirect on Write Unified Snapshots uses Redirect on Write (ROW) technology. After a snapshot is taken, new writes to the LUN, file system, or their snapshots are redirected and written to a new location within the storage pool. New data is written to a new block while the old data remains in place. This is more efficient than copy on write (COW) or copy on first write (COFW) because no data needs to be moved from one place to another. Figure 1: Redirect on Write In Figure 1, the source LUN has data pointing to locations A, B, C, and D. When a snapshot of the LUN is taken, the snapshot s pointers also point to those locations. 8

9 When a user modifies the data in location D after a snapshot is taken, the new data is simply written to a new location, D. Similarly, if the snapshot is attached to a host, and the data in location A is modified by that host, the data is written to a new location A. The pointers for the snapshot are updated with the new location. The blocks required for writes after a snapshot is created are allocated from the same storage pool where the storage resource is created. With Unified Snapshots there is no need to pre-configure protection storage. The functionality of Redirect on Write also applies to File Systems. In a thick LUN or file system, space is allocated as soon as the storage resource is created. The resource is in direct mode as there is a direct association between the pointers to the storage resource and the location of the storage resource. Immediately after it is taken, the snapshot of the storage resource also points to the same location. As writes are written to the snapshot, the thick storage resource transitions to indirect mode, where the pointers point to different locations as space is needed. The thick LUN or file system remains in indirect mode as long as it has a snapshot. When the last snapshot of the thick LUN or file system is removed, it automatically reverts to direct mode. The indirect mode to direct mode conversion is a background process. Indirect mode is not applicable to thin LUNs or file systems. For a thin LUN or file system, space is never directly allocated, it is always allocated as new writes are written. LUN Groups The VNXe3200 system introduces the concept of LUN Groups. A LUN Group is a collection of one or more LUNs and is used to preserve consistency. The Unified Snapshots operations supported for a LUN can also be executed on a LUN Group. LUN Groups can be used to group together a set of LUNs that belong to the same application. With Unified Snapshots, LUN Groups are able to provide crash consistency. Unified Snapshots provide the ability to take point-in-time snapshots of all the LUNs in a group, instead of taking an individual snapshot of each LUN at varying points in time. When the snapshot of a LUN Group is taken, all writes to the LUNs within that LUN Group are held until their snapshots have been created. The most common use case for LUN Groups is for maintaining crash consistency among LUNs. For example, a database application which has a Data LUN and a Log LUN can be placed in a LUN Group (Figure 2). In this example, the information in both the Data and Log LUNs are dependent on each other and a LUN group can be used to perform operations on the LUNs together. 9

10 LUN Group Considerations Figure 2: LUN Group While operations that can be performed on LUNs can also be performed on LUN Groups, there are some factors which should be considered with LUN Groups: LUN Groups can consist of LUNs from different storage pools. The space required for snapshots of each LUN is consumed from the same storage pool associated with each individual LUN. When adding a LUN to a LUN Group: o A LUN that has existing snapshots cannot be added to a LUN Group. All snapshots of the LUN must be deleted before adding the LUN to the LUN Group. o A LUN group with existing snapshots cannot add new LUNs. o The snapshot schedule of the LUN will be overwritten by the schedule of the LUN group. When removing a LUN from a LUN Group: o Snapshots of the LUN Group must be deleted before the LUN can be removed. The same rule applies to deleting a LUN that is the member of a LUN Group. o A LUN removed from a LUN group will have its snapshot schedule removed. Snapshot Use Cases Unified Snapshots is a powerful tool that can be used for various applications and use cases. The primary use cases are for local protection of storage and for repurposing. Local Protection Snapshots can be used for creating periodical point-in-time copies of data. Unified Snapshots provide the ability to restore data from a point-in-time in the event of a data loss or corruption of data which is being accessed by a host. Snapshots provide local protection; data can be restored directly from the storage array. Snapshots can also be used for backups by providing snapshot access to a backup server. In Figure 3, a LUN is scheduled for snapshots to be taken daily. Snapshots are taken on Monday, Tuesday, and Wednesday. If the data on the LUN is accidently deleted on 10

11 Thursday, a restore operation can be performed from the snapshot taken on Wednesday. Therefore, Unified Snapshots provide the ability to restore data locally. Repurposing Figure 3: Nightly Backup Snapshots can be used for repurposing of data, by providing access to copies of data to different teams or hosts for independent processing. Snapshots can be leveraged in a test and development environment where snapshots of data are used for testing without affecting the data used for development. An example of this is testing a new application setting or patching a host. For example, a company is testing a new application setting (Figure 4). A snapshot of the data is taken on Monday and given to the QA team. The QA engineers have a copy of the data, in the form of a snapshot, to perform their testing. Meanwhile the development team continues to work on the storage resource itself and take nightly snapshots for local protection. 11

12 Snapshot Scheduling Figure 4: Repurposing Snapshot schedules for a LUN or file system can be assigned both while creating a snapshot and after the LUN or file system has been created. During the LUN or file system creation process there is a step named Configure Snapshot Schedule (Figure 5). The snapshot schedule may be chosen from a group of predefined and usercreated snapshot schedules. Also, new schedules can be created. Figure 5: Configure Snapshot Schedule 12

13 There are three predefined snapshot schedules: Default Protection: Every day at 04:00, keep for 2 days A snapshot is taken at 04:00 every day and that snapshot will expire after 2 days. Less Protection: Every day at 04:00, keep for 1 day A snapshot is taken at 04:00 every day and that snapshot will expire after 1 day. More Protection: Every day at 04:00, keep for 7 days A snapshot is taken at 04:00 every day and that snapshot will expire after 7 days. In addition to the predefined snapshot schedules, new schedules can be created using the Customize Schedule option (Figure 5). The customize schedule option provides the ability to assign a name to the new schedule, and has the default protection parameters selected. The schedule can be modified in the Modify Schedule Rule window (Figure 6). Figure 6: Modify Schedule Rule While scheduling snapshots, there are various parameters which can be configured. The parameters for snapshot frequency and time depend on the type of rule chosen: Every Specified Number of Hours: The frequency is set to take a snapshot regularly after a specified number of hours. The time chosen decides the number of minutes after the hour the snapshot should be taken. For example, take a snapshot every 2 hours and 30 minutes. 13

14 Every Day: The frequency is set to take a snapshot at specified hours in a day (maximum 2). The time chosen decides the number of minutes after the hour the snapshot should be taken. For example: Take a snapshot at 02:30 and 12:30. Every Specified Number of Days: The frequency is set to take a snapshot after a specified number of days. The time decides at what time during the day the snapshot should be taken. For example, take a snapshot every 2 days at 12:00. On Selected Days: The frequency is set to take a snapshot on specified days of the week. The time decides at what time during the day the snapshot should be taken. For example, take a snapshot every Tuesday and Wednesday at 12:00. On the Specified Day of Every Month: The frequency is set to take a snapshot every nth day of the month. The time decides at what time during the day the snapshot should be taken. For example, take a snapshot every 5 th of the month at 12:00. The Auto-Delete Policy determines when the VNXe3200 system will automatically delete snapshots. The following Auto-Delete Policy options are explained in further detail in the Snapshot Auto-Delete section. Pool Auto-Delete Threshold Setting: The snapshot will be part of an Auto-Delete operation based on storage pool threshold settings. Expiration Value: An expiration time or date is assigned to the snapshot. The expiration time can be a maximum of 24 hours or 365 days. Do Not Configure Automatic Deletion: The snapshot is not included in Auto-Delete operations. The Access Type (file-based storage only) decides whether the file snapshot will be a Hidden.ckpt folder (read-only snapshot) or Shares (writable snapshot). The access types are further explained in the File Snapshot Operations section. The customized snapshot schedule can also be modified and viewed on the Settings > More Configuration > Snapshot Schedules page in Unisphere (Figure 7). Here you can view all the system-defined and user-defined snapshot schedules. You can determine if a snapshot schedule is associated with a storage resource by viewing the In Use column. If a user-defined snapshot schedule is in use, it cannot be deleted. The system-defined snapshot schedules can never be deleted. Figure 7: Snapshot Schedules 14

15 Note: The same snapshot schedules can be used for both block and file storage resources on your VNXe3200 system. Snapshot Auto-Delete Unified Snapshots provide the ability to automatically delete snapshots. The main goal of Auto-Delete is to manage pool space automatically, so that snapshots do not consume space when they are no longer needed. As snapshots consume usable capacity from a storage pool, it is important to balance protection needs with user space. Snapshot Auto-Delete can be configured to delete snapshots based on the space utilized in the pool or by expiration time. Delete Eligibility Auto-Delete can be enabled for snapshots of: LUNs, LUN Groups, file systems, and VMware datastores. When a storage pool or storage resource is being created, the Auto-Delete settings can be configured when assigning a snapshot schedule to a storage resource. The Auto-Delete settings can also be modified after a pool or storage resource has been created. To view or modify the auto-delete option, navigate to the details page of your storage resource, click the Snapshot tab, select the snapshot to modify, and click Details. In the Auto-Delete tab, you can review and modify the settings (Figure 8). Figure 8: Auto-Delete If a snapshot is configured with the default Auto-Delete option of Pool auto-delete threshold setting (Figure 8), the settings of the pool are used to decide when Auto- Delete is initiated for a snapshot (Figure 9). By default, only the total pool space threshold option is enabled, and Auto-Delete state is idle, which means it is not 15

16 currently deleting any snapshots. The Auto-Delete settings can be modified based on business needs in the storage pool details page. Auto-Delete Thresholds Pool Space Used Threshold Figure 9: Storage Pool Thresholds The Pool Space Used Threshold is a user-configurable parameter that determines whether the system should monitor the space used in a storage pool, and delete snapshots if required. This threshold is enabled by default and the following is actively monitored: Pool Space Used High Threshold: When the pool crosses this threshold, the Auto- Delete process is triggered. This process examines pool snapshots for destruction eligibility in order of age, with the oldest first. When eligible snapshots are found, the system deletes them one at a time. By default, the threshold is set to 95% of the pool s capacity. Pool Space Used Low Threshold: When this threshold is crossed, the Auto-Delete process will stop looking for new snapshots to delete. By default, the threshold is set to 85% of the pool s capacity. It must be set smaller than the Pool Space Used High Threshold. Snapshot Space Used Threshold The Snapshot Space Used Threshold is a user-configurable parameter that determines whether the system should monitor the snapshot space used in a storage pool and delete snapshots if required. This threshold is disabled by default. When disabled, threshold values are retained by the system but snapshot space is not actively monitored. When enabled, the following thresholds are actively monitored: Snapshot Space Used High Threshold: When the snapshot consumed space crosses this threshold, the Auto-Delete process is triggered. This process examines pool snapshots for deletion eligibility in order of age, oldest first. When 16

17 eligible snapshots are found, the system deletes them one at a time. By default, the threshold is set to 25% of the pool s capacity. Snapshot Space Used Low Threshold: When this threshold is crossed, the Auto- Delete process will stop looking for new snapshots to delete. By default, the threshold is set to 20% of the pool s capacity. It must be set smaller than Snapshot Space Used High Threshold. The total Used Space and the Snapshot Size Used in a pool can be monitored under the Utilization tab of the Storage Pool Details (Figure 10). Figure 10: Used Space and Snapshot Size Used Note: If a snapshot is attached it will not be deleted during the Auto-Delete operation. For a snapshot to be subject to the Auto-Delete process, the Auto-Delete option must be enabled at both the pool level and snapshot level (Table 1). Table 1: Auto-Delete Behavior Pool Snapshot Auto-Delete Behavior ON ON Snapshot is subject to Auto-Delete ON OFF Snapshot is exempt from Auto-Delete OFF ON All snapshots in the pool are exempt from Auto-Delete OFF OFF All snapshots in the pool are exempt from Auto-Delete When the storage pool capacity exceeds the system defined pool threshold of 85%, a pop-up appears in Unisphere (Figure 11). This is a warning alert to expand the storage pool or delete any storage resources or snapshots which are no longer being used in the storage pool. 17

18 Figure 11: Warning Message If additional storage resources are configured on the storage pool, a sequence of alerts appears, in order to warn you to take corrective action (Figure 12). Once the Pool Space Used High Threshold is exceeded, the storage pool is set to a degraded state. If a storage pool is in a degraded state, the health check will fail, preventing system upgrades. Figure 12: Alerts after Thresholds are exceeded Once the Pool Space Used High Threshold is reached, the system begins the Auto- Delete process. If additional snapshots cannot be deleted automatically to free enough space, an alert appears in Unisphere (Figure 13). 18

19 Figure 13: Alert when Auto-Delete is paused The Auto-Delete status of the pool is changed to System Paused. To recover from this state, you can expand the pool, delete snapshots or storage resources, or change the thresholds and click Resume Auto-Delete (Figure 14). Snapshot Expiration Figure 14: Resume Auto-Delete Snapshots can be configured with an expiration value, which pre-determines when they will be deleted. However, when the expiration value of a snapshot is reached, the snapshot may not be destroyed immediately. The system scans for expired snapshots once an hour and runs a deletion process which deletes eligible snapshots during this scan. The name of a snapshot that is eligible for deletion is affixed with Destroying, to show that the snapshot is being deleted. Figure 15 shows that the expiration value for a snapshot can be set in the Auto-Delete tab of the snapshot details. The minimum expiration value for a snapshot is 1 hour. Once a snapshot is configured with an expiration value, the date and time when the snapshot will expire is shown. 19

20 Figure 15: Snapshot Expiration Setting an expiration value on a snapshot excludes it from the Auto-Delete process. Expired snapshots are not deleted while they are attached or involved in a restore. Snapshot Invalidation Because of the thin nature of snapshots, it is possible encounter a pool out of space condition as a result of writing data to a LUN or file system that has snapshots, even if the LUN or file system itself is thick. Consider the following example: 1. A user creates a 100GB thick LUN on a pool that has 150GB of available space. 2. The user takes a snapshot of the thick LUN. Because the snapshot will preserve the current point-in-time view of the LUN and new writes will be redirected to a new location in the pool, it is possible for the thick LUN and its snapshot to consume a total of 200GB if the LUN is completely overwritten after taking the snapshot. Because the LUN has the potential to require 200GB from a 150GB pool, the pool is oversubscribed and an out of space condition is possible. 3. Suppose threshold based auto-deletion is not configured for the snapshot. If hosts eventually overwrite 50GB of the LUN while the snapshot still exists, the pool will be out of space. 100GB snapped thick LUN + 50GB redirected writes to the thick LUN = 150GB, the size of the pool. 4. The pool cannot continue to redirect new writes for snapped blocks that have not yet been overwritten since the snapshot was taken. This is because there is no free space remaining in the pool to put this new data while preserving the snapped blocks. Therefore, the snapshot and new writes to the source LUN can no longer coexist. The system must either A) Fail new writes to the LUN that would cause new allocations, or B) Invalidate, or destroy, all snapshots associated with the source LUN in order to free up space for new writes. Which of the actions in step 4 above is taken depends on the source resource. Table 2 - Pool Out of Space Behavior below shows the pool full behavior for each storage resource type: Thick Thin LUN Invalidate snapshots Fail IO UFS32 File System Invalidate snapshots Invalidate Snapshots UFS64 File System Invalidate snapshots Fail IO Table 2 - Pool Out of Space Behavior 20

21 Unified Snapshots Operations Unified Snapshots leverages ROW technology for both block and file storage resources on the VNXe3200 system. Snapshot operations such as create, delete, copy, and restore can be performed for both block and file storage resources. Attach and detach operations can be used to provide host access to block snapshots. File snapshots can be accessed through the hidden read-only.ckpt folder (Previous Versions) or through a share of the snapshot. We will look at the Unified Snapshots operations and their differences in the following sections. Block Snapshot Operations Block snapshot operations on the VNXe3200 system can be performed on LUNs, LUN Groups, and VMware VMFS datastores. LUNs will be used as an example while describing the block snapshot operations. Creating Snapshots Once a snapshot of a LUN is created, a point-in-time copy of the data of the LUN is made. Immediately after a snapshot is created no space is allocated to the snapshot, yet space will be allocated to the snapshot as new data is written. The space required for the snapshot is allocated from the same storage pool from which the LUN was created. Snapshots can be created for both thick and thin LUNs. Once a snapshot of a LUN is created, performance may be impacted on the newly written or snapped area of the LUN. Depending on the workload, the first snapshot of a LUN may have a performance impact, but performance will not be impacted as additional snapshots are created. Performance will recover after the last snapshot is deleted. To create a snapshot, select a block storage resource and click on Details. In the Snapshots tab, you can you use Create Snapshot to create a snapshot of the storage resource (Figure 16). When creating a snap, you have to assign a name, a brief description (optional), and configure the Auto-Delete policy. The default name for a snapshot is Date_Time (ex _ ). The default option for the Auto-Delete policy is Pool autodelete threshold setting. Details of the Auto-Delete policy are explained in the Snapshot Auto-Delete section. 21

22 Figure 16: Create Snapshot You can view the created snapshots from the Snapshots tab in the storage resource details page. A snapshot has various properties associated with it, including: Name: The snapshot can be assigned a name when it is being created. The default name is the Date_Time of when the snapshot was created (ex _ ). The name of the snapshot is unique across the system. The name of the snapshot can be modified. Taken: This represents the date and time when the snapshot was taken (ex :13 ). Taken By: This provides information on which user took the snapshot or if the snapshot was taken by a scheduled operation or restore operation. State: This represents the state of the snapshot. The possible states are: Ready, Initializing, Offline, and Destroying. Attached: This represents whether the snapshot has been attached to a host. When a snapshot is initially created the default state is No. The state will change to Yes if a snapshot is attached to a host. Modified: This represents whether the snapshot has been changed. When a snapshot is initially created, the default state is No. The state will change to Yes after a snapshot is attached to a host. Last Writable Time: This represents the last time the snapshot was modified. You can review the properties of a snapshot by selecting a snapshot and clicking Details (Figure 17). 22

23 Figure 17: Snapshot Properties Note: When a snapshot is initially created, the Attached and Modified values are set to No. The snapshot becomes modified after it is attached to a host. Block Snapshot Host Access During the creation of a LUN, host access can be configured. There are four different options for host access: No Access The host will not have access to the LUN or snapshots. LUN The host will only have access to the LUN. Snapshot The host will only have access to snapshots. LUN and Snapshot The host will have access to both the LUN and snapshots. Figure 18 shows the available host access options that can be selected in the LUN Wizard while creating a LUN. The host access options can also be modified from the Host Access tab in the details page of a block storage resource. Figure 18: Configure Host Access 23

24 If a LUN is provided with Snapshot or LUN and Snapshot access, the host sees the container used to present the created snapshot. To the host, this container looks like a snapshot of the LUN. However, the container can only be accessed after a snapshot is created and attached. This implementation allows a snapshot to be attached and detached later without requiring a rescan on the host. If a host has access to both LUN and the snapshot, only the LUN can be accessed. The host access settings can also be changed after the block storage resource has been created. The access settings can be modified by using the Modify Access option under the Host Access tab in the storage resource s details page. The Access Details option in the General tab in the storage resource s details page will also provide the details of hosts that have access to the LUN. For a LUN Group, the host access policy assigned will apply to all the LUNs within the LUN Group. Host access can be configured or changed for the member LUNs in a LUN Group after the LUN Group is created. If a LUN is removed from the LUN Group, it retains the host access settings of the LUN Group. If a LUN is added to a LUN Group, it will retain its own host access settings. Attaching and Detaching Snapshots After a snapshot of a LUN has been created, it can be attached to a host. Only one snapshot of a block storage resource can be attached to a host at a time. Once a snapshot is attached, the Attached State and the Modified State of the snapshot are changed to Yes. To attach a snapshot, select a block storage resource and click on Details. In the Snapshots tab, you can use the Attach Snapshot option to attach a snapshot to a host. Hosts which have access to the snapshot of the block storage resource can access the snapshot after it is attached. During the attach operation, Unisphere provides users the option to create a copy of the snapshot. This option is enabled by default and if applied, a copy of the snapshot will be taken before the host is attached (Figure 19). The copy can be used as a recovery snapshot to discard any changes made to the snapshot while the snapshot is attached. 24

25 Figure 19: Attach Snapshot Note: After a snapshot is attached, the Attached and Modified states are changed to Yes. The detach option can be used to remove host access to a snapshot. When a snapshot is detached from the host, the Attached State changes to No and the Last Writable timestamp is updated to reflect the time when the snapshot was detached. Storage is not returned to the pool after a snapshot is detached; it is only returned after the snapshot is deleted. To detach a snapshot, select a block storage resource and click on Details. In the Snapshots tab, you can you use the Detach Snapshot option to detach a snapshot from a host. Note: Only one snapshot of a storage resource can be attached to a host. Hence, snapshots which are not being used should be detached. Restoring Snapshots The snapshot restore operation provides the ability to revert a snapshot back to the point-in-time when the snapshot was taken. The restore option is only available for a LUN that is not currently attached to a host. For a LUN Group, the restore operation is enacted on all LUN Group members. To restore data from a snapshot, select a block storage resource and click on Details. In the Snapshots tab, select a snapshot and use the Restore Snapshot option to restore from the snapshot (Figure 20). 25

26 Figure 20: Restore Snapshot To prevent unintentional data loss, the system automatically creates a backup snapshot before initiating the restore. The new snapshot will have a default name starting with BackupSnapshot, followed by the timestamp when the restore operation was performed. This name can be modified. After the data is restored, additional changes can be made. If data is accidently deleted, the backup snapshot can be used to restore data back to the point when the backup snapshot was created. You can review the properties of a backup snapshot by selecting a snapshot and clicking Details. Figure 21 shows the details of the backup snapshot that was created automatically during the restore process. Since this snapshot was created during the restore operation, the Taken By attribute is set to Snapshot Restore. 26

27 Copying Snapshots Figure 21: Snapshot Restore Details Snapshots can be duplicated to provide the same point-in-time copy of data to multiple hosts. The copy will contain the same data as the original snapshot, except with a unique name. Attached and detached snapshots can be used to create copies. Detached Snapshots Copy of a detached snapshot will be the source LUN. Attached Snapshots Copy of an attached snapshot will be the snapshot. A copy of an attached snapshot is also known as a hierarchical snapshot. There is a maximum of two levels of hierarchy with block snapshots. Hierarchical snapshots provide the ability to create a snapshot even when an attached snapshot is being modified. Hierarchical snapshots can be used for repurposing data. To copy a snapshot, select a block storage resource and click Details. In the Snapshots tab, select a snapshot and use the Copy Snapshot option to create a copy of the snapshot (Figure 22). A single copy or multiple copies can be created during the copy operation. The default name is Date_Time if a single copy is created. If multiple copies are created, the default name will be Date_Time_Number. The starting number and number of copies can be chosen. Figure 22: Copy Snapshots The copy snapshot retains the properties of the source snapshot. A maximum of 256 copies of a single snapshot can be created. If the snapshot used to create a copy is detached, the source of the copy snapshot is the source LUN. The source of the Detached_Copy snapshot, Marketing, is the source LUN (Figure 23). 27

28 Figure 23: Copy of Detached Snapshot If the snapshot used to create a copy is attached, the snapshot serves as the source. In Figure 24, the Marketing_Snapshot snapshot is attached and used to create a copy. The source of the Attached_Copy snapshot is Marketing_Snapshot instead of the source LUN. Deleting Snapshots Figure 24: Copy of Attached Snapshot Deleting a snapshot will reclaim space from a storage pool so it can be reused. Snapshot deletion is an internal background process that is handled on a first-come, first-served basis. The VNXe3200 system can delete up to 16 snapshots simultaneously. Delete requests over this limit are queued until a thread becomes available. While a snapshot is being deleted, the state of the snapshot changes to "Destroying" and the snapshot s name is prepended with Destroying_<timestamp>. In this state, the snapshot is still counted towards the snapshot limit. However, its original name may be reused at this time. Deleting a snapshot may generate a large amount of background I/O, as old blocks of data (which are unique to that snapshot) are removed and the free space is reclaimed. The amount of workload generated on the Storage Processor and the pools is proportional to the number of simultaneous deletions. The amount of time a deletion takes to complete depends on the amount of unique data on that snapshot. As a result, it is recommended to plan snapshot deletions during periods of light system activity. The following scenarios may affect how long the snapshot delete processing takes, and the overall impact to system performance. Pools which contain a large number of NL-SAS drives: When a snapshot is deleted, the I/O associated with the snapshot s deletion can end up on the NL- SAS drives. Ideally, pools which make extensive use of snapshots should be comprised of Flash and SAS drives. Large number of snapshots being deleted at the same time: This can be caused by deleting snaps using a script, having a common expiration time set on many 28

29 snaps, or by reliance on the Auto-Delete feature. To remedy this, stagger the deletions by adding delay into the script or pace the snapshot expiration times. Snapshot deletion overlapping with FAST VP relocation windows: It is advised to start the snapshot deletions after the FAST VP relocation window has ended. Frequent creation and deletion of snapshots: The greater the frequency of snapshot operations, the higher the background I/O will be to delete them. Reducing the frequency of snapshots and their subsequent deletions will reduce the background I/O load on the pool. Snapshots with thick LUNs and file systems: A mode conversion from thick to thin happens when the final snapshot of a thick LUN or file system is deleted. It is advised to keep at least one snapshot of the Thick LUN or file system remaining if you plan on using snapshots on that storage resource again. Alternatively, consider using a thin LUN, for its avoidance of this mode conversion. File Snapshot Operations File snapshot operations on the VNXe3200 system can be performed on file systems (NFS and CIFS) and VMware NFS datastores. The snapshot operations supported are: create, delete, restore, and copy. File Systems can have two types of snapshots based on access type: Read Only A read-only snapshot is a read-only point-in-time view of its associated production file system. A read-only snapshot can be shared with network clients by using traditional network file sharing protocols (CIFS and NFS). Business applications that require access to point-in-time views of data, but not real-time data, can take advantage of a read-only snapshot. On the VNXe3200 system, read-only snapshots are identified with an access type of Hidden.ckpt folder (read-only). Writable A writable snapshot is a read/write point-in-time view of its associated production file system. A writable snapshot can be shared with network clients by using traditional network file sharing protocols. However, unlike a read-only snapshot, a writable snapshot can be modified (written to) by network clients so that it no longer reflects a point-in-time view of the production file system. A share has to be created using the writable snapshot before writing to it. Testing environments used for software patch testing and configuration changes will benefit from writable snapshots. After the changes are stabilized, the changes can then be propagated to the production file system. On the VNXe3200 system, writable snapshots are identified with an access type of Shares. The CIFS file system is used as a reference in the following sections to describe the various snapshot operations. The same operations can be applied to NFS file systems and VMware NFS datastores. Creating Snapshots Once a snapshot of a file system is created, it creates a point in time copy of data of the file system. Immediately after a snapshot is created there is no space allocated to the snapshot. Space will be allocated to the snapshot as new data is written to the 29

30 snapshot. The space required for a snapshot is allocated from the same storage pool the production file system was created on. Snapshots can be created for both thick and thin file systems. Once a snapshot of a thick file system is created, it behaves like a thin file system until the last snapshot is deleted. Depending on the workload, the first snapshot created of a thick file system will have an impact on performance. The performance will not be impacted as additional snapshots are created. Performance will recover after the last snapshot is deleted. To create a snapshot, select a file storage resource and click on Details. In the Snapshots tab you can you use the Create Snapshot option to create a snapshot of the file system. When creating a snapshot, you have to assign a name, a brief description (optional), and configure the Auto-Delete policy. The default name for a snapshot is Date_Time (ex _ ). The default option for the Auto-Delete policy is Pool auto-delete threshold setting. Details of the Auto-Delete policy are explained in the Snapshot Auto-Delete section. When a snapshot is created for a file system, the access type can be chosen to be either a Hidden.ckpt folder (read-only) or Shares (Figure 25). Figure 25: Create File System Snapshot File system snapshots will have the following attributes: Name: The snapshot can be assigned a name when it is being created. The default name is the Date_Time of when the snapshot was created (ex _ ). The name of the snapshot is unique across the system. The name of a file system snapshot cannot be modified once created. Taken By: This provides information on which user took the snapshot or if the snapshot was taken by a scheduled operation or restore operation. 30

31 Taken: This represents the date and time when the snapshot was taken (example: :13). State: This represents the state of the snapshot. The possible states are: Ready, Initializing, Offline, and Destroying. Shared: This represents whether the snapshot is shared. This will always remain No for read-only snapshots but is modified to Yes for writable snapshots when a share is created using the snapshot. Access Type: This represents the access type of the snapshot. The two options are: Hidden.ckpt folder (read-only) and Shares. Modified: This represents whether or not the snapshot has been changed. When a snapshot is initially created, the default state is No. It will remain No for readonly snapshots, and modified to Yes for writable snapshots when a share is created using the snapshot and the share is written to. Last Writable: This represents the last time the snapshot was able to be written to. You can view the details of the snapshot by selecting the snapshot and clicking on Details. The snapshot details section has two tabs: the General tab, where the details of the snapshot can be viewed, and the Auto-Delete tab, which has options for the snapshot s Auto-Delete policy (Figure 26). File Snapshot Host Access Figure 26: File System Snapshot Details Read-only snapshots are accessed based on the type of share configured. For CIFS shares, the snapshots can be accessed via the Windows operating environment: With Windows 7 and later, browse to the share, right-click the folder, select Properties, and view the Previous Versions tab (Figure 27). The Date modified parameter corresponds to the time when the snapshot was taken. You can select 31

32 the snapshot and use the Open and Copy options to access data from the snapshot. This leverages the Windows Volume Shadow Copy Service (VSS) feature. The restore operation can be used to restore data to a previous version. With older versions of Windows, enter \.ckpt in to the Address Bar, after the name of the share, to open the hidden snapshot folders. Windows VSS can also be used. Figure 27: Windows Previous Versions For NFS shares, read-only checkpoints can be accessed through the root of the file system on a UNIX host. Once the NFS share is mounted, you can list the snapshots by running the command ls a. You can access the files in the snapshot by navigating to the folder starting with.ckpt (Figure 28). Figure 28: Viewing NFS Snapshots in Linux Writable snapshots can be accessed by creating shares using snapshots. When a share is created using writable snapshots, the modified state of the snapshot changes to Yes. Writable snapshots cannot be accessed through Windows VSS. To create a share using a writable snapshot, you should have a file system snapshot created with an access type of shares. Navigate to the file system details page, and in the Shares tab, click Add Share to create a share. 32

33 When creating a share there are two options: File System: Creates a share for the file system. Snapshot: Creates a share for a writable snapshot (Figure 29). Figure 29: Creating a Share Using Snapshot The Local Path may be left blank, which will mount the share to the root directory. If specifying a Local Path, ensure that the complete path, including the subdirectory, is provided and the directory existed in the file system when the snapshot was taken. In Figure 30, dir1 is a directory created on the file system before the snapshot was taken. Figure 30: Share Local Path 33

34 After the share is created, select the share and click Details to view the information about the share. In Figure 31, the Share Source is Share_Snapshot, which is the name of the writable snapshot that was used to create the share, and the details of the export paths are provided. After a share using a snapshot is created, the shared state of the snapshot will be modified to Yes. Restoring Snapshots Figure 31: Share Details The snapshot restore operation provides the ability to revert a snapshot back to the point-in-time when the snapshot was taken. Only file system snapshots which have not been used to create shares can be used for restore operations. This is because a shared file system snapshot may no longer reflect the point-in-time data of the file system. Windows VSS can also be used to restore from snapshots. To restore data from a snapshot, select a file storage resource and click on Details. In the Snapshots tab, select a valid snapshot and click on Restore. To prevent unintentional data loss, the system will automatically create a backup snapshot before initiating the restore. After the data is restored, additional changes can be made. If data is accidently deleted, the backup snapshot can be used to restore data back to the point when the backup snapshot was created. You can review the properties of a backup snapshot by selecting a snapshot and clicking on Details. The default name of the backup snapshot is BackupSnapshot_<timestamp>, with the timestamp referring to the time when the restore operation was performed. The Taken By parameter of the backup snapshot is set to Snapshot Restore and Access Type is modified to Shares. All other parameters remain identical to the snapshot that was used for restore (Figure 32). 34

35 Copying Snapshots Figure 32: Backup Snapshot Details Snapshots can be duplicated, where the copy will contain the same data as the original snapshot. Snapshot copies can be taken for both read-only and writable snapshots. Copies of snapshots can be created to provide point-in-time copy of data to multiple clients or users. On a copy of a read-only snapshot (.ckpt), only the name and access type are modified. Name: Represents the name assigned when a copy is created Access Type: The access type of a copy snapshot is changed to Shares On a copy of a writable snapshot, the parameters that are changed depend on whether or not a share has already been created using that snapshot. If a share has not yet been created for a writable snapshot, only the name of the copied snapshot is modified. Name: Represents the name assigned when a copy is created If a share was already created using the writable snapshot, the copy is referred to as a hierarchical snapshot. The following parameters are changed when a copy is created: Name: Represents the name assigned when a copy is created Source: The snapshot that was used to create the copy A hierarchical snapshot will provide the ability to create a copy of snapshot which is used to create a share. Figure 33 shows an example of a hierarchical snapshot where the snapshot Share_Snapshot is used to create a share and also used to create a snapshot. Copying Share_Snapshot will create a point-in-time copy of the snapshot and the source of the snapshot will be set to Share_Snapshot instead of the source file system. 35

36 Figure 33: Hierarchical Snapshot Note: A maximum of 10 levels of hierarchy is supported for writable snapshots that are shared. Deleting Snapshots The snapshot delete operation for file storage resources works identically to the delete operation on block storage resources. More details are provided in the Deleting Snapshots section. Limits Table 3 displays the numerical limits for Unified Snapshots on the VNXe3200 system. Table 3: Unified Snapshots Limits Name Limit Maximum LUN Snapshots per Array 1000 Maximum Snapshots per LUN 256 Maximum Block Snapshot Level 2 Maximum File System Snapshots per Array 250 Maximum Snapshots per File System 96 Maximum File Snapshot Level 10 Maximum User File Systems + Snapshots per Array 500 Best Practices Best practices when using Unified Snapshots include: It is recommended to use thin (default) LUNs and file systems if snapshots are going to be enabled. Snapshot creation will have lower performance impact on a thin storage resource as compared to a thick LUN or file system. Thin LUNs and file systems also improve space efficiency. Plan snapshot deletions to occur during non-peak times. If snapshots have to be deleted during peak hours, reduce the number of concurrent snapshot deletions. On a thick storage resource, do not delete the final snapshot if additional snapshots will be taken in the future. Place LUNs that depend on each other into a LUN Group in order to maintain crash consistency. Perform snapshot operations on the LUN Group. Auto-Delete policies should be configured on your storage resources to have the system automatically delete snapshots which are no longer needed. This mitigates the potential of reaching threshold limits that prevent new snapshots 36

37 from being created. The default Auto-Delete policy is based on pool auto-delete threshold settings. Refer to the EMC VNXe3200 Best Practices for Performance - Applied Best Practices Guide for more information. Interoperability Unified Snapshots is designed to work with the other VNXe3200 features. This integration enables easy management and the ability to utilize the features with snapshots created on the VNXe3200 system. LUN and File System Expansion Expansion of thick and thin storage resources with snapshots is supported. Any snapshot taken after the expansion will reflect the newer size. During the restore operation, data will only be restored to the size of the LUN when the snapshot was taken. FAST Cache and FAST VP Unified Snapshots is fully compatible with FAST Cache and FAST VP. The changes to a LUN with a snapshot are written to a new location in the same pool. These new blocks will have the same tiering policy and initial allocation rules as the source storage resource. This also applies to changes made to writable snapshots. New blocks can be promoted and relocated in the same manner as regular storage resource blocks. For more information, refer to the Introduction to the EMC VNXe3200 FAST Suite white paper on EMC Online Support. File Deduplication and Compression Snapshots are supported on file systems that have compression and deduplication enabled. For more information, refer to the EMC VNXe3200 File Deduplication and Compression white paper on EMC Online Support. SMB 3.0 Snapshots are supported with SMB 3.0 features such as Continuous Availability (CA) and protocol encryption. File-Level Retention (FLR) File-Level Retention is a software feature that can be used to protect files from modification or deletion until a specified retention date. It is commonly used when regulations require maintaining data for a certain period of time. FLR is configured per file system, but snapshots of the file system are also supported by FLR. For more information, refer to the Using a VNXe System with CIFS File Systems white paper on EMC Online Support. 37

38 UFS64 UFS64 is limited to VMware NFS datastores and does not support any array-level data services such as Unified Snapshots. If snapshots are required, VM-level snapshots can be created in vsphere. VNXe VSS HW Provider The VNXe VSS HW Provider runs as a Windows service and provides the interface between the Microsoft Volume Shadow Copy Service (VSS) and VNXe3200 system. The VNXe VSS HW Provider enables VSS requestor applications, such as VSS-enabled backup applications, to make snapshots of VNXe LUNs. The VNXe VSS HW provider can be used to create application consistent snapshots for block storage resource in windows. For more information, refer to the EMC VNXe Series Using a VNXe system with Fibre Channel or iscsi LUNs guide on EMC Online Support. Snapshots can be taken by VSS-enabled backup applications. You can review the properties of a snapshot by selecting a snapshot and clicking Details (Figure 34). When the snapshot is taken by the VSS provider, the Taken By value for the snapshot will show EXTERNAL_VSS. Figure 34: Snapshot Created by VSS VSS helps in creating and managing snapshots for Windows servers on local block resources. The File Server Remote VSS Protocol (FSRVP) is a remote procedure call (RPC)-based protocol that is used for creating shadow copies of file shares on a remote computer. This protocol facilitates the backup applications' tasks in performing application-consistent backup and restore of VSS-aware applications storing data on network file shares. EMC VNXe3200 supports the ability for FSRVP to also create snapshots for file systems. 38