Ask the Expert: Block Deduplication and FAST Suite Tiering in the New VNX

This discussion is now open. We look forward to a fun interactive and informative discussion.

Regards,

Mark

Block Deduplication is an excellent feature to help control the data footprint within the storage environment. Can you provide best practices to enable the feature on these new systems?

whole LUN does not move, slices move. In the new platform slices got much smaller, 256MB versus 1G in the older VNX.

In FAST VP how does data moves between different tiers.

Does whole LUN moves from one tier to another tier.

Secondly what are the improvements in Fast VP in new VNX.

Should we expect a performance hit with the new Fast VP granularity, since there are obviously more slices to analyze?

Will FAST Cache be aware of the fact that data is deduplicated? I mean: what data will eventually be cached: the whole data block or is it being deduped in FAST Cache as well? With MCx CPU performance shouldn't be an issue for now.

The new MCx code now uses all available cores and since the new VNXs also have more cores, and 4x more performance, the number of slices can easily be 4x as many. I truly believe that chances are that this will be even smaller in the future.

Multicore Cache and Multicore FAST Cache are Block Deduplication aware, which means only single copies of data from a pool can end up in Multicore Cache or Multicore FAST Cache.

If 5 LUNs all had the same 8 KB block in Multicore Cache and Multicore FAST Cache, when these 8KB blocks are deduplicated, only a single instance of each will be left in each cache. With this said, Multicore Cache still promotes data in 64 KB blocks.

As RRR mentioned, with the use of more CPU cores for processing, the performance impact seen from FAST VP would be minimized. The FAST VP code also spreads out the statistics gathering and analysis processes of FAST VP so the processes for each pool do not run all at the same time.

A question from another forum:

Dedupe seems to be only available for thin luns.  Is it on the roadmap to have thick luns be eligible for dedupe?

Block Deduplication can be enabled on Thick or Thin LUNs within a pool, but the LUN will become thin when Deduplication is enabled. This is to take advantage of the space savings feature of Thin, and ability to release slices back to the pool when a slice no longer contains data.

More information on Block Deduplication can be found in the Deduplication and Compression White Paper found here: https://support.emc.com/docu48711_White-Paper:-EMC-VNX-Deduplication-and-Compression-VNX5400,-VNX5600,-VNX5800,-VNX7600,-and-VNX8000-Maximizing-Effective-Capacity-Utilization.pdf

Hi

Posibly a bit off topic,   what improvements have you made to Analyzer for the VNX2 ?  In particular Ild really like to be able to see more metrics on Pool LUNs such as SP and FASTCache usage per POOL LUN.

Thanks

I think block-deduped LUNs are all assigned to one SP which has the FSL and Deduplication container. (Am I right?)

If so, one of the SPs could be super busy and it would cause a performance problem.

Don't we have to be careful about that? The limitation of 1PB Deduplication container is set for that purpose?

Check out the VNX video on Unisphere Analyzer that talks about the changes: Video Link : 6161

very few changes to Navi Analyzer, that tool has not changed  in more than a decade. Look at performance tools that have been developed for VMAX (SPA and now Unisphere for VMAX). So many metrics, very nice export options (UPV/BTP). Analyzer is so 1990's (thank god you include it now in base package). VNX Monitoring and Reporting has a long way to go.

Why so little focus on developing a more robust performance analysis tool ?

P.9 of the white paper says "A 246MB slice may be freed back to the pool". The next-gen VNX started using 256MB slice for FAST VP. How come this slice size (246MB) is different from that of FAST VP? (or is it just a typo?)