Dell EMC PowerStore 2.0 – Part6, UNMAP Enhancements

So Far, we provided, an high level overview of the PowerStore 2.0 release, A deep dive into the DRE enhancements, NVMe Over FC integration with VMware, the PowerStore 500T platform
& the security enanchments.

As I’ve mentioned in previous posts, PowerStore OS 2.0 delivers a large performance increase for every model in the family.

The important thing to remember here is that this benefit comes from a simple SW update, non-disruptive, and completely free of charge for existing customers. And again, it becomes the baseline performance for new products shipping from the factory.

This post will be focusing on the UNMAP improvements in PowerStore 2.0.

UNAMP & VMFS

Starting from VMware vSphere 6.5, a long-forgotten feature called UNMAP appeared, which returns the virtual machine disk space to the disk array using VAAI. UNMAP is a command that allows a way to reclaim space from blocks that have already been written to after data that previously resided on those data blocks has been deleted.

VMFS5 and earlier file systems do not UNMAP free space automatically, but you can use the esxcli storage vmfs unmap command to reclaim space manually. When you use the command, be aware that it might send many UNMAP requests at a time. This action can lock some of the resources during the operation.

On VMFS6 datastores, ESXi supports the automatic asynchronous reclamation of free space. VMFS6 can run the UNMAP command to release free storage space in the background on thin-provisioned storage arrays that support UNMAP operations.

Asynchronous UNMAP processing has several advantages:

• UNMAP requests are sent at a constant rate, which helps to avoid any instant load on the backing array.
• Freed regions are batched and unmapped together.
• I/O performance of other workloads is not impacted by the UNMAP command.

VMware 6.7 U1 introduces support for automatic space reclamation with SCSI UNMAP support. Here it is also possible to quickly and automatically release and return blocks to storage without entering any commands.

In this version, the ESXi supports the UNMAP commands issued directly from a guest operating system to reclaim storage space.

Inside a virtual machine, storage space is freed when, for example, you delete files on the thin virtual disk. The guest operating system notifies VMFS about freed space by sending the UNMAP command. The UNMAP command sent from the guest operating system releases space within the VMFS datastore. The command then proceeds to the array, so that the array can reclaim the freed blocks of space.

In addition, UNMAP commands are issued during deletion of virtual machines and files from VMFS datastore and upon storage vmotions between datastores.

UNMAP & vVOLs

VMware vSphere Virtual Volumes (vVols) are used as the primary storage mechanism for virtual machines running on PowerStore X model appliances internal nodes and can be used by external ESXi hosts from either PowerStore X or T models. vVols is a new storage methodology that runs on top of existing storage protocols such as Fibre Channel and iSCSI, that allows administrators more granular control over virtual machines regarding performance, snapshots, and monitoring.

vVols are sub volumes at the array level. A virtual disk in a vVol world is a volume on the array. So, when deleting a file in a VM, the guest file system is actually issuing UNMAP directly to the storage array volume.

Also, when virtual machines are deleted, the associated virtual volumes are immediately deleted from the storage array

One of the most common use cases for vVols these days is vSphere with Tanzu, where each Kubernetes persistent volume is a virtual volume at the array level.

Persistent storage is presented through the VMware CSI driver, called CNS (Cloud Native Storage). CNS uses existing storage options for storage provisioning, in a new way. it uses first class disks instead of standard disks. FCD are just virtual disks, but in the API, they are 1st class objects–they can be created and exist independently of a VM. Which makes sense for something a container.

When a persistent volume is deleted, the corresponding virtual volume is immediately deleted from the storage array.

Compared to traditional workloads storage lifecycle, In Kubernetes, hundreds of pods and persistent volumes are created and destroyed every hour and this translates to a huge amount of UNMAP commands to reclaim the deleted volumes from the storage array.

More information on how Virtual Volumes and UNMAP primitive interact can be found here

In PowerStore 2.0, we have invested a lot of resources in order to improve UNMAP performance.

This latest performance increase was the result of a number of optimizations within the data path and overall architectural improvements.  It demonstrates our ongoing commitment to enhancing the capabilities of the PowerStore platform for our customers.

• Improved write path design
• Streamlined performance during “overwrites”
• More efficient garbage collection
• More efficient host IO prioritization
• More efficient background processes

How big is the difference? Real-world workloads can experience improvement of hundreds of percent compared to PowerStore 1.0

For example, an UNMAP process of 2TB VMFS datastore takes less then 30 seconds to complete in PowerStore 2.0.

Here you can see a demo of running UNMAP command in vSphere 7 on PowerStore 2.0.

Whether you run traditional workloads, virtualized workloads, or cloud native workloads, this capability shows the flexibility and investment protection PowerStore provides. As DELL continues to lead the adoption of new capabilities and technologies, your roadmap is in good hands with the adaptable PowerStore platform.

A guest post by Tomer Nahumi