The more I talk with customers, the more I find that the technical details of how something works is much less important than the business outcome it achieves. When it comes to storage, most customers just want a device that will provide the capacity and performance they need, at a price they can afford–and it better not be too complicated. Pretty much any vendor trying to sell something will attempt to make their solution fit your needs even if they really don’t have the right products. It’s a fact of life, sell what you have. Along these lines, there has been a lot of back and forth between vendors about dedup vs. compression technology and which one solves customer problems best.
After snapshots and thin provisioning, data reduction technology in storage arrays has become a big focus in storage efficiency lately; and there are two primary methods of data reduction — compression and deduplication.
While EMC has been marketing compression technology for block and file data in Celerra, Unified, and Clariion storage systems, NetApp has been marketing deduplication as the technology of choice for block and file storage savings. But which one is the best choice? The short answer is.. it depends. Some data types benefit most from deduplication while others get better savings with compression.
Currently, EMC supports file compression on all EMC Celerra NS20, 40, 80, 120, 480, 960, VG2, and VG8 systems running DART 5.6.47.x+ and block compression on all CX4 based arrays running FLARE30.x+. In all cases, compression is enabled on a volume/LUN level with a simple check box and processing can be paused, resumed, and disabled completely, uncompressing the data if desired. Data is compressed out-of-band and has no impact on writes, with minimal overhead on reads. Any or all LUN(s) and/or Filesystem(s) can be compressed if desired even if they existed prior to upgrading the array to newer code levels.
With the release of OnTap 8.0.1, NetApp has added support for in-line compression within their FAS arrays. It is enabled per-FlexVol and as far as I have been able to determine, cannot be disabled later (I’m sure Vaughn or another NetApp representative will correct me if I’m wrong here.) Compression requires 64-bit aggregates which are new in OnTap 8, so FlexVols that existed prior to an upgrade to 8.x cannot be compressed without a data migration which could be disruptive. Since compression is inline, it creates overhead in the FAS controller and could impact performance of reads and writes to the data.
Vaughn Stewart, of NetApp, expertly blogged today about the new compression feature, including some of the caveats involved, and to me the most interesting part of the post was the following graphic he included showing the space savings of compression vs. dedup for various data types.
Image Credit: Vaughn Stewart, NetApp
The first thing that struck me was how much better compression performed over deduplication for all but one data type (Virtualization will usually fare well because in a typical environment there are many VMs with the same operating system files). In fact, according to NetApp, deduplication achieves very little savings, if any, for the majority of the data types here.
The light green bar indicates savings with both dedupe AND compression enabled on the same dataset. In 5 out of 9 cases, dedup adds ZERO savings over compression alone. I can’t help but wonder why anyone would enable dedup on those data types if they already had compression, since both features use storage array CPU resources to find and compress or dedup data. I am aware that in some cases, dedup can improve performance on NetApp systems due to dedup-aware cache, but I also believe that any performance gain is directly related to the amount of duplication in the data. Using this chart, virtualization is really the only place where dedup seems particularly effective and hence the only place where real performance gains would likely present themselves.
The challenge for NetApp customers will be getting their data into a configuration that supports compression due to the 64-bit aggregate requirement, lack of an easy and non-disruptive LUN migration feature (DataMotion appears to only support iSCSI and NFS and requires several additional licenses), and no way to convert an aggregate from 32-bit to 64-bit. Once compression has been enabled, if there is truly no way to disable it, any resulting performance impact will be very difficult to rectify.
On the other hand, any EMC customer with current maintenance can upgrade their NS or CX4 array to newer versions of DART or FLARE, and compression can be enabled on any existing data after the fact. If performance becomes an issue for a particular dataset once compressed, the data can be uncompressed later. Both operations are completely non-disruptive and run in the background. While block compression only works on LUNs in a virtual pool, as opposed to a traditional RAID group, enabling compression on a normal LUN will automatically migrate the LUN into a virtual pool, perform zero-page reclaim, followed by compression, and the entire process is completely non-disruptive to the application. Oh, and compressed data can still be tiered with FASTVP across SSD, FC, and SATA disk and/or benefit from up to 2TB of FASTCache.
I admit that there is a place for deduplication as well as compression in reducing the footprint of customer data. However, based on what I’ve seen in my career as an IT professional, and with my customers in my current role at EMC, there are more use cases for compression than there are for deduplication when it comes to primary data, whether SAN or NAS. Either way, if I was using a new technology for the first time on a particular data set, whether compression or deduplication, I would definitely want a backout plan in case the drawbacks outweight the benefits.
Like this:
Like Loading...
